I18N: Add translation support for script modules

[manzoorwanijk]

Summary

Adds translation support for script modules (WP_Script_Modules), so strings using __() from @wordpress/i18n inside script modules are translated at runtime.

Script modules (ES modules registered via wp_register_script_module()) currently have no mechanism to load i18n translation data. This affects the new admin pages in WordPress 7.0+ that are built as script modules, including Connectors and Fonts, where strings remain in English regardless of the site language.

Trac ticket: https://core.trac.wordpress.org/ticket/65015

Changes

Runtime

• WP_Script_Modules::print_script_module_translations() — iterates every enqueued script module (and its dependencies), looks up the {locale}-{md5(relative-path)}.json chunk for each, and emits an inline <script> that calls wp.i18n.setLocaleData() with the loaded translations.
• Hooked at priority 11 on admin_print_footer_scripts (after classic scripts load wp-i18n at priority 10) and priority 21 on wp_footer (after wp_print_footer_scripts at priority 20), so the inline data is available before deferred ES modules execute.
• load_script_module_textdomain( $id, $domain, $path ) — new function in l10n.php, mirrors load_script_textdomain() but reads the module's source URL from WP_Script_Modules. Both functions now share a private helper to avoid duplicating the path-resolution logic.
• WP_Script_Modules::get_registered( $id ) — public accessor for a registered module's data, used by the loader.
• The existing load_script_textdomain_relative_path filter now receives a third argument, $is_module, so callers can distinguish script modules from classic scripts.

Public override API (optional)

• wp_set_script_module_translations( $id, $domain, $path ) and the underlying WP_Script_Modules::set_translations() exist only as overrides, for modules whose text domain is not 'default' or whose translation files live outside the standard location (for example, plugin modules registering their own text domain). Core and most plugin modules do not need to call this — translations are loaded automatically.

Tests

New integration tests in wpScriptModules.php covering:

• Auto-detection: print_script_module_translations() loads and prints translations for an enqueued module without any explicit registration.
• Dependency handling: translations are also printed for static/dynamic dependencies of enqueued modules.
• Override path: set_translations() correctly overrides the auto-detected text domain.
• The is_module argument passed to the load_script_textdomain_relative_path filter.

Tests use the pre_load_script_translations filter to supply mock translation data, so no fixture JSON files are needed.

Related

Gutenberg companion PR: WordPress/gutenberg#77214 — adds a polyfill of the same API for the Gutenberg plugin on WP versions before this change lands.

Test plan

Automated

npm run test:php -- --group script-modules

Manual

Real language packs already ship JSON translation chunks for the Connectors script module files — for example Spanish (es_ES) has them translated. So end-to-end verification doesn't need any mocked data:

1. Install and activate Spanish:

   Via WP-CLI:

   wp core language install es_ES
   wp site switch-language es_ES

   Or via the admin UI: switch the site language in Settings > General, then visit Dashboard > Updates (/wp-admin/update-core.php) and click "Update translations" to ensure the latest language pack is installed.

2. Visit Settings > Connectors (/wp-admin/options-connectors.php).

3. Expected: heading shows "Conectores", subtitle "Todas tus claves de API y credenciales…", buttons show "Instalar", connector descriptions show "Generación de texto con Claude.", etc.

4. View page source and search for wp-script-module-translation-data- — inline <script> tags with IDs like wp-script-module-translation-data-wp/routes/connectors-home/content should appear after the classic scripts.

Some locales may not have these strings translated yet and will render in English — that's the expected fallback. Any locale whose language pack includes the chunks will render translated without any configuration.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.6
Used for: Implementation, tests, and PR description were authored with AI assistance; reviewed and tested by me.

Before	After

[github-actions]

Hi @manzoorwanijk! 👋

Thank you for your contribution to WordPress! 💖

It looks like this is your first pull request to wordpress-develop. Here are a few things to be aware of that may help you out!

No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description.

Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making.

More information about how GitHub pull requests can be used to contribute to WordPress can be found in the Core Handbook.

Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook.

If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook.

The Developer Hub also documents the various coding standards that are followed:

• PHP Coding Standards
• CSS Coding Standards
• HTML Coding Standards
• JavaScript Coding Standards
• Accessibility Coding Standards
• Inline Documentation Standards

Thank you,
The WordPress Project

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props manzoorwanijk, westonruter, mukesh27, jsnajdr, jonsurrell, peterwilsoncc.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[mukeshpanchal27]

Thanks for the PR! Can you expose which AI tool do you use in PR?

## Use of AI Tools

<!--
You are free to use artificial intelligence (AI) tooling to contribute, but you must disclose what tooling you are using and to what extent a pull request has been authored by AI. It is your responsibility to review and take responsibility for what AI generates. See the WordPress AI Guidelines: <https://make.wordpress.org/ai/handbook/ai-guidelines/>.

Example disclosure:

AI assistance: Yes
Tool(s): GitHub Copilot, ChatGPT
Model(s): GPT-5.1
Used for: Initial code skeleton and test suggestions; final implementation and tests were reviewed and edited by me.
-->

[manzoorwanijk]

Thanks for the PR! Can you expose which AI tool do you use in PR?

Updated. Thanks

[westonruter]

I can confirm the changes currently fix the issue at least for some of the strings.

Before:

After:

I suppose the other strings are coming from the textdomain of the connector plugin and aren't provided yet? Or they haven't been translated for Spanish yet period?

[manzoorwanijk]

I can confirm the changes currently fix the issue at least for some of the strings.

Thank you for testing this.

I suppose the other strings are coming from the textdomain of the connector plugin and aren't provided yet? Or they haven't been translated for Spanish yet period?

The remaining untranslated strings come from a couple of different places:

1. Other script modules. Strings like the connector descriptions and the "Install the AI plugin" card come from additional script modules (@wordpress/connectors and @wordpress/boot), not the wp/routes/connectors-home/content module. The test mu-plugin's filter only intercepts translation loading for that one module ID, so translations for other modules pass through and try to load from real language pack JSON files - which don't exist yet for trunk strings. Once the companion Gutenberg PR (#77214) lands, the generated code will call wp_set_script_module_translations() for those modules too, and they'll pick up translations from real language packs the same way.

2. PHP-side strings passed via script_module_data. A few strings (e.g., the connector descriptions) are rendered PHP-side in connectors.php and passed to the module as data - those already use __() and work if translations exist in the language pack. For trunk/alpha the newer strings probably aren't in the Spanish language pack yet.

You can confirm (1) by extending the mu-plugin's filter to intercept additional module IDs like @wordpress/connectors with the same mock structure - those strings should then render in Spanish too.

[westonruter]

Shall I commit this?

[jsnajdr]

Does this address https://core.trac.wordpress.org/ticket/60234?

Only partially: to really implement translations API for script modules, it must not depend on classic scripts. This is only an intermediate step.

[jsnajdr]

Shall I commit this?

I'm happy with this PR except one little thing: I suggested merging the textdomain and translations_path fields directly into the ScriptModule structure, without the translations intermediate object. For symmetry with WP_Dependency object used by WP_Scripts. The same thing should have the same name.

But it's not a blocker.

Honestly I got lost in the vast number of review comments, can't find the suggestion now.

[manzoorwanijk]

Honestly I got lost in the vast number of review comments, can't find the suggestion now.

It was in the first comment in this review - #11543 (review)

[jsnajdr]

It was in the first comment in this review

This link doesn't work for me, but Cursor found the comment using GH tools:

My suggestion was to make this ScriptModule structure as close as possible to WP_Dependency used by WP_Script. If there are common fields, let's name them the same way.

That would mean that there are textdomain and translations_path fields directly on the ScriptModule object, not in a translations subfield.

Can't find in the web UI, but here it is. Did you resolve this somehow?

[westonruter]

@jsnajdr:

My suggestion was to make this ScriptModule structure as close as possible to WP_Dependency used by WP_Script. If there are common fields, let's name them the same way.

That would mean that there are textdomain and translations_path fields directly on the ScriptModule object, not in a translations subfield.

So for this:

wordpress-develop/src/wp-includes/class-wp-script-modules.php

Lines 16 to 23 in 374a234

	* @phpstan-type ScriptModule array{
	* src: string,
	* version: string|false|null,
	* dependencies: array<int, array{ id: string, import: 'static'|'dynamic' }>,
	* in_footer: bool,
	* fetchpriority: 'auto'|'low'|'high',
	* translations?: array{ textdomain: string, path: string },
	* }

You're suggesting to get rid of translations, and to move textdomain and translations_path keys to the root?

  * @phpstan-type ScriptModule array{ 
  *     src: string, 
  *     version: string|false|null, 
  *     dependencies: array<int, array{ id: string, import: 'static'|'dynamic' }>, 
  *     in_footer: bool, 
  *     fetchpriority: 'auto'|'low'|'high', 
  *     textdomain?: string,
  *     translations_path?: string,
  * } 

[manzoorwanijk]

Can't find in the web UI, but here it is. Did you resolve this somehow?

You can see the changes in f8bd260 and e5b32e7

[jsnajdr]

You're suggesting to get rid of translations, and to move textdomain and translations_path keys to the root?

Yes, because that's what WP_Dependency for classic scripts also does.

You can see the changes in f8bd260 and e5b32e7

After these commits there is no longer the completely separate $this->translations registry, it's merged into $this->registered, but still as a nested object. My suggestion was to flatten it further.

It's not particularly important, just something that apparently fell through the cracks.

[manzoorwanijk]

After these commits there is no longer the completely separate $this->translations registry, it's merged into $this->registered, but still as a nested object. My suggestion was to flatten it further.

Ah, missed that nuance - flattened them in 89a25ea. textdomain and translations_path now sit directly on the registered entry, matching WP_Dependency's shape. Thanks for the patient nudge 🙂

[jsnajdr]

Thank you, IMO this is now ready to ship. It will be a very valuable 7.0 fix.

[westonruter]

I'm committing now.

[westonruter]

Committed in r62278 (93d77a2).

[westonruter]

Follow up: #11690

See Trac comment: https://core.trac.wordpress.org/ticket/65015#comment:47