[wp-trac] [WordPress Trac] #63944: load_script_textdomain doesn't use plugin's DomainPath for translation lookup

[WordPress Trac]

#63944: load_script_textdomain doesn't use plugin's DomainPath for translation
lookup
--------------------------+-----------------------------
 Reporter:  jsnajdr       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  I18N          |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 When `load_script_textdomain` looks up translations for a script, it
 doesn't use the plugin's `DomainPath` header value. That's an unjustified
 difference between how PHP and JS translations are looked up.

 The current workflow is that translations for a script are declared with:
 ```php
 wp_set_script_translations( 'my-script', 'my-domain', $optional_path );
 ```
 If I omit the `$optional_path`, translations are looked up only in the
 "global" `wp-content/languages/plugins` directory. No "local" plugin path
 is looked at.

 I need to declare the local path explicitly if I want it to be used:
 ```php
 wp_set_script_translations( 'my-script', 'my-domain', plugin_dir_path(
 __FILE__ ) . 'languages' );
 ```

 The expected behavior, however, is that I can:
 1. Call `wp_set_script_translations` without the `$path` argument;
 2. Declare `DomainPath: /languages` in the plugin main file;
 3. Get the translations looked up in plugin's `./languages` subfolder.

 This is how PHP translations work, when calling `__()`, in a plugin's PHP
 file.

 @swissspidy If I understand correctly, respecting `DomainPath` is a quite
 recent addition, from 6.8 earlier this year. And this bug looks like an
 omission?

 Fixing this would probably solve also #54797, or at least a big part of
 it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63944>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform