[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        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Description changed by dd32:

Old description:

> 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.

New description:

 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#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform