Loads the translation data for a given script module ID and text domain.
Description
Works like load_script_textdomain() but for script modules registered via wp_register_script_module().
Parameters
$idstringrequired- The script module identifier.
$domainstringoptional- Text domain. Default
'default'.Default:
'default' $pathstringoptional- The full file path to the directory containing translation files.
Default:
''
Source
function load_script_module_textdomain( string $id, string $domain = 'default', string $path = '' ) {
$module = wp_script_modules()->get_registered( $id );
if ( null === $module ) {
return false;
}
$src = $module['src'];
// Ensure src is an absolute URL for path resolution.
if ( ! preg_match( '|^(https?:)?//|', $src ) ) {
$src = site_url( $src );
}
return _load_script_textdomain_from_src( $id, $src, $domain, $path, true );
}
Changelog
| Version | Description |
|---|---|
| 7.0.0 | Introduced. |
Be careful when passing a custom $path to this function (or to WP_Script_Modules::set_translations(), which calls it internally). The official naming convention for script module IDs uses a namespaced format with a slash, e.g. ‘@my-plugin/my-module’ (see the 6.7 Script Modules dev note on make.wordpress.org).
When $path is provided, the translation filename is built as:
$file_base . ‘-‘ . $id . ‘.json’
If your module ID contains a slash — which is the RECOMMENDED format
— this produces a filename like:
my-plugin-pt_BR-@my-plugin/my-module.json
The slash is not escaped, so PHP treats everything before it as a subdirectory. In practice, this means a manually specified $path will silently fail to find your translations unless you create a very unusual nested folder structure matching this exact string, which is not something any translation tool generates.
The safe approach: leave $path empty (”) and let WordPress auto-resolve translations from the module’s registered src URL instead. That fallback path (in _load_script_textdomain_from_src() ) builds the filename from an MD5 hash of the script’s relative path rather than the raw module ID, so it works correctly regardless of slashes in your module ID:
wp_register_script_module( ‘@my-plugin/my-module’, ‘build/module.js’, array(), ‘1.0.0’ );
add_action( ‘init’, function () {
wp_script_modules() ->set_translations( ‘@my-plugin/my-module’, ‘my-plugin’ );
// No custom $path — WordPress resolves the translation file
// location from the module’s src and locale automatically.
} );
Only pass a custom $path if your module ID has no slashes, or if you’ve verified the resulting filename actually matches a file you control.