WakaLang
| 开发者 |
noricku
wakalab |
|---|---|
| 更新时间 | 2026年9月15日 12:19 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
标签
下载
详情介绍:
/en/about/ and /ja/about/, then helps you connect translated posts, terms, menus, navigation blocks, SEO metadata, and hreflang output.
The free plugin is complete for manual multilingual publishing and makes no external network calls.
Free features
- Register the languages your site offers (code, locale, names, URL prefix, default).
- URL-prefix routing: every page is reachable under each language prefix (
/en/…,/ja/…), with the prefix as the single source of truth for the active language. - A language switcher with automatic header/footer placement, an editor block, the
[wakalang_switcher]shortcode, and thewakalang_language_switcher()template function — with optional flags rendered as Unicode emoji (no external requests). hreflangalternate links (and an optionalx-default) for translated content. Ifx_default_urlis left empty, WakaLang derives it from the current page's default-language URL.- Internal links, menu links, the site/home link, and block-theme (FSE) navigation all keep the current language's URL prefix.
- Link posts, pages, and taxonomy terms into translation groups from a post or term editor, and create draft translations.
- Archive, search, RSS/Atom feeds, and the core
wp-sitemap.xmlare scoped to the current language. - Translate taxonomy terms (category, tag, custom taxonomy) with per-language name and slug.
- Manage a per-translation SEO title and meta description, handed to WordPress core and to Yoast / Rank Math (their own meta is never touched).
- Translate the site title, tagline, date/time display format, week start day, logo, and site icon per language.
- Optionally show a small "this page is also available in English" bar to visitors whose browser language differs from the page — the visitor's own browser decides (JavaScript), so automatic redirects are never used and page caching keeps working. Off by default.
- Every page's
<html lang>and, for a right-to-left language,dir="rtl"are guaranteed directly from the language registry — independent of whether a language pack is installed. - Review translation coverage, maintenance checks, FAQ, troubleshooting, support routes, and system information inside wp-admin.
安装:
- In WordPress, go to Plugins → Add New, search for WakaLang, install it, and activate it.
- To install from a ZIP, go to Plugins → Add New → Upload Plugin, upload the WakaLang ZIP, install it, and activate it.
- Go to WakaLang → Languages to register your languages and set a default.
- Go to WakaLang → Settings and choose a header or footer language switcher position, or add the block/shortcode where you want it manually.
- Open WakaLang → Guide for setup steps, usage notes, FAQ, troubleshooting, support routes, and system information.
屏幕截图:
常见问题:
After installing, what should I do first?
Add your languages under WakaLang → Languages, set the default language, choose switcher placement under WakaLang → Settings, then assign languages and translation groups in the post or page editor.
What should I do if settings are not reflected?
Flush rewrite rules from WakaLang → Tools, clear page/object/CDN caches, and confirm you are viewing a URL with the expected language prefix.
My translations lost their language after moving the site. What happened?
Language assignments and translation groups are stored in a WakaLang database table, so a WordPress export (WXR) does not carry them. Move the content first, then use WakaLang → Tools → Import and export translation relationships on the old site to download the relationships and on the new site to import them. Objects are matched by post type and slug (never by ID), a preview reports what would happen before anything is written, and rows that cannot be matched are listed with a reason.
Why is my theme or plugin interface text still in English?
WakaLang translates your content, URLs, and the site's core "face" fields (site title, tagline, date/time display, logo, and site icon). It does not scan or translate the gettext strings built into themes and plugins (button labels, widget titles, form messages). Install a WordPress language pack for each language under Settings → General to translate those automatically. For strings without an official translation, hand-edit them with a dedicated string-translation plugin such as Loco Translate — a complementary tool that WakaLang never installs or changes for you. WakaLang and Loco Translate share the work rather than duplicating it.
Can I use WakaLang with my theme or cache plugin?
Yes in normal setups. If root browser-language detection is enabled, exclude the bare site root (/) from full-page caching, host cache, and CDN cache, or turn that detection off in WakaLang → Settings. Prefixed URLs such as /en/ and /ja/ remain safe to cache normally because the URL prefix is the language source of truth. Clear caches after changing URL, menu, or switcher settings.
What is the difference between Free and Pro?
WakaLang Free is complete for manual multilingual publishing. WakaLang Pro is a separate add-on for licensed AI-assisted translation workflows and is not bundled in the free WordPress.org plugin.
Where can I get support?
Use the WordPress.org support forum for WakaLang Free. Do not post license keys, API keys, account details, payment information, or refund requests in public forum threads; use the Pro support route shown inside the plugin when applicable.
Does WakaLang Free send my content anywhere?
No. WakaLang Free makes no external network calls, does not use a CDN, does not include telemetry, and does not perform license checks.
Does WakaLang support right-to-left (RTL) languages like Arabic and Hebrew?
Yes. Every page's <html> tag gets a lang attribute and, for a right-to-left language, dir="rtl", guaranteed directly from your configured language registry rather than from WordPress's own installed language packs — so it is correct even before you install that language's translation files. This covers WCAG success criteria 3.1.1 (Language of Page) and 3.1.2 (Language of Parts) for the language-of-page/switcher parts of your site. The language switcher also marks each right-to-left language's link with dir="rtl".
What does WakaLang intentionally not do?
To stay lightweight, WakaLang does not include a visual front-end translation editor, a full theme/plugin string-scanning panel, media/attachment translation, translated or shared slugs, per-language domains or subdomains, WooCommerce or page-builder specific integrations, translation-agency workflows, multisite language networks, or a visitor-facing machine-translation widget. The URL prefix stays the source of truth for the current language, WordPress slugs stay canonical, and no translation credits are sold.
Is WakaLang actually lightweight?
The additional database queries, autoload option payload, and TTFB impact WakaLang adds to a front-end page load are measured with a reproducible script and published at https://github.com/my-biz-dev/wakalang/blob/main/docs/benchmarks/frontend-performance.md — run it yourself against the project's local verification stack to confirm the numbers. For hosting recommendations (a persistent object cache, page-cache interaction) see https://github.com/my-biz-dev/wakalang/blob/main/docs/performance.md.
更新日志:
- Add a public API compatibility policy (Issue #723):
docs/COMPATIBILITY_POLICY.mddefines hooks / REST / Abilities / GraphQL / WP-CLI as versioned public API (semver, two-minor deprecation via_deprecated_hook(), Abilities schema rules). New stable hooks:wakalang_root_language_detected,wakalang_language_url_prefix,wakalang_language_switcher_items,wakalang_translation_unlinked,wakalang_settings_schema.wakalang_hreflang_entriesis now stable (wakalang_canonical_urlalready was, Issue #711). Track A pins the surface intests/Fixtures/public-api-snapshot.json. WakaLang Pro cancels automation jobs on unlink; WPGraphQLurlPrefixuses the public prefix filter. - Split three oversized Pro translation classes while keeping their public constructors, methods, and hooks (Issue #738):
AiTranslationPage→ controller / view / CSV exporter / job diagnostics;TranslationCoordinator→ kind translators over a shared pipeline;ReviewRepository→ staging / guards / decisions. Dedicated Track A tests coverProviderRequestSupport,BlockStructureValidator, glossary and translation-memory schema helpers, and table-driven auto-translation policy gates.
- Add a Settings "Content schema" tab (Issue #717): for every translatable post type the detected post meta keys and the registered block types' string attributes are listed with copy / translate-manually / ignore policy selects, stored in the non-autoload
wakalang_content_schemaoption and resolved byContentSchemaRegistryas a fourth sibling source — code declarations (thewakalang_content_schemafilter andwpml-config.xml) still win any conflict by the most-restrictive rule, and secret/auth keys stay locked to ignore in the UI. The same declarations are exposed as thecontent_schemakey onwakalang/get-settings/wakalang/update-settingsand aswp wakalang settings get --field=content_schema/--content_schema=<json>. - Add a Tools "Menu sync" panel (Issue #716): generate a same-hierarchy nav menu per target language from a default-language menu, with each item re-pointed at its translation-group member (the front-end fallback policy governs links with no translation), custom links prefix-swapped under the localizer's exclusion policy, labels copied through the new
wakalang_menu_sync_labelfilter (the Pro AI hook-in), and hand-edited labels preserved on re-runs (the sync only relabels items whose label still matches what it last wrote). Re-runs apply a diff (add / delete / re-parent / reorder, keyed by a source-item marker meta) without touching items the user created inside a generated menu; a dry-run preview reports the changes before anything is written (PRG, per-user report), generated menus are proposed for the source menu's theme locations via the per-language MenuLocations store, and block themes get the same operation overwp_navigationposts with results registered for the front-endNavigationRefslanguage swap. - Add an opt-in, non-forced language suggestion banner (Issue #710): a cache-safe front-end script offers a link to another language's published translation of the current page when the visitor's browser language differs, with per-language message overrides in the Tools string-translations store and a session-cookie dismissal. Off by default; the server makes no visitor-dependent decisions, so prefixed URLs stay fully page-cacheable.
- Add a per-language
banner_messageoverride to the Tools String translations panel. - Add a Free, AI-free translation structure check (Issue #715): heading outline, link count/href set, image count, Gutenberg block-type sequence, and code-block count are compared on save and stored as
_wakalang_structure_checkpost meta. The Translation Hub, Gutenberg sidebar, and classic meta box show a warning (never a publish block) such as "1 missing link"; Hub CSV adds a Structure column per language. WakaLang Pro's QA Engine is not used. - Split
Plugin::boot()into per-request-typeBootstrap\{Core,Frontend,Admin,Cli,Abilities}Registrarclasses (Issue #721): admin/CLI/abilities-only services are no longer generated on a plain front-end render (a front boot drops from 110 to 63 loadedWakaLang\classes), and the shared services admin, CLI and the abilities surfaces consume are built once through a memoisedBootstrap\Containerexposed byPlugin::container(). The boot sequence is behaviour-preserving; every hook still registers exactly as before. - Add a static-state reset seam (Issue #721): classes holding request-scoped statics (
HomeUrlFilter,LinkFilter,PostsCacheInvalidator,Options,SettingsSchema, and Pro'sChunkResumeStore) exposereset_for_tests(), andWakaLang\Testing\StateResetclears them in every test'sset_up()so Track B results can no longer depend on class statics leaking across tests.
- Add Pro translation QA rules for HTML balance, link targets, cross-chunk terminology, Japanese register, and repeated sentences, plus a filterable site QA report, CSV export, and Site Health metrics.
- Add Translation Hub AI selection, estimate, and explicit enqueue actions, including review-only bulk SEO and slug candidates across the Hub, WP-CLI, and Abilities API.
- Add a bilingual, saved-response Pro sales demo for structure protection, glossary correction, human review, and incremental translation (Issue #766).
- Reduce front-end query overhead without a persistent object cache by priming a generation-guarded translation target map and avoiding duplicate URL reverse lookups.
- Backfill source_language_code and record AI-reviewed status.
- Add Gutenberg translation sidebar.
- Address code review findings for flaky test tracking.
- Guarantee each language's
<html lang>/dirdirectly from the language registry (not the installed language pack), add adir="rtl"to right-to-left language switcher links, and add a Multilingual Doctor check for language attribute misconfiguration.
- Add per-language/provider AI usage breakdown with CSV export.
- Refresh plugin screenshots.
- Add language filter to taxonomy term list tables.
- Memoize UrlResolver::resolve_for_language() per request.
- Batch translation graph priming for REST post collections.
- Stabilize admin site-health and permissions specs.
- Add translation coverage dashboard widget.
- Scope dashboard widget by allow-list and fix broken empty-state link.
- Keep core sitemap alive alongside an SEO plugin.
- Translation Exchange (Pro) can now include excerpt, per-translation SEO title/meta description and slugs in an export via opt-in checkboxes, and taxonomy term names as a separate unit type; imports apply the new fields, hold slugs for explicit manual application, and keep title/content-only files working unchanged (Issue #466).
- Language switcher links now point at the clean translation URLs, matching the hreflang alternates; the preferred-language cookie is written by a small front-end script on click instead of a query-parameter redirect hop (Issue #633). The server-side
?wakalang_switch_language=flow is kept for backward compatibility.
- Prevent WP 7.1 handle_404 false positive on sitemap requests.
- Send 200 explicitly and tighten pre_handle_404 test coverage.
- Declare WordPress 7.1 compatibility.
- Add bulk approve/reject to Translation Review queue.
- Add translationGroupId field and own i18n catalog.
- Bump minimum Free version to 0.3.1 for TranslationGraphBuilder.
- Suppress nonce-verification false positives in Pro admin pages.
- Guard adapter package against Pro declarations.
- Move SEO consistency observation off front-end requests.
- Reject a redirected or empty head in the consistency scan.
- Speed up the Translation Hub and translation coverage report on large sites.
- Cap default-language assignment to a bounded batch per call.
- Batch translation group lookups in the post list table.
- Restore quality threshold baseline.
- Memoize merged settings and schema defaults.
- Resolve 404 fallback target via bare permalink.
- Add bulk language assignment to the post list.
- Add edit, enable/disable, and reorder to the Languages page.
- Add term translation search and draft creation (#442).
- Show source-change diffs and add bulk needs-update resolution.
- Add bulk translation-draft creation to the Translation Hub.
- Add confirm-before-destructive-action and notice dismissal.
- Add versioned DB migrations.
- Resolve menu items via known object id instead of URL reverse lookup.
- Fall back to a display name when no flag emoji resolves.
- Detect and recover from a missing translations table.
- Remove residual WakaLang data.
- Verify critical write results.
- Localize GFMR and CLI notices.
- Add site-to-site export and import of translation relationships, so language assignments and translation groups survive a WordPress (WXR) content move.
- Add cross-language 404 fallback resolution.