[wp-trac] [WordPress Trac] #57079: Translation Related Question/Bug

[WordPress Trac]

#57079: Translation Related Question/Bug
--------------------------+-----------------------------------
 Reporter:  jacobd91      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  I18N          |     Version:  6.0.3
 Severity:  major         |  Resolution:
 Keywords:                |     Focuses:  docs, administration
--------------------------+-----------------------------------
Changes (by sabernhardt):

 * focuses:  docs, administration, performance, coding-standards => docs,
     administration


Old description:

> To whom it may concern
>
> **Part I**
>
> I am a developer for W3TC and recently diagnosed an issue with our plugin
> under WP6.0.3/PHP8.1 regarding the use of an
> admin_print_scripts-{$hook_suffix} not applying under non-english
> translation due to our plugin's topmost menu page via add_menu_page
> containing a translated $menu_title parameter. This resulted in the
> hook's $page_type parameter under get_plugin_page_hookname being
> translated, thereby not allowing our JS/CSS to print as expected
>
> Under es_ES translation:
> Expected: page hook = performance_page_w3tc_extensions
> Received: page hook = actuacion_page_w3tc_extensions
>
> I determined 2 solutions
> 1. Remove the translation from the add_menu_page resulting in the topmost
> menu item remaining in English which isn't preferred
> {{{#!php
> <?php
>                 add_menu_page(
>                         __( 'Performance', 'w3-total-cache' ),
>                         __( 'Performance', 'w3-total-cache' ),
>                         apply_filters(
>                                 'w3tc_capability_menu_w3tc_dashboard',
>                                 $base_capability
>                         ),
>                         'w3tc_dashboard',
>                         '',
>                         'none'
>                 );
> }}}
>
> 2. Apply translations to our $hook_suffix in each use of
> admin_print_scripts-{$hook_suffix} which is preferred but seems "hackish"
> {{{#!php
> <?php
> add_action( 'admin_print_scripts-' . sanitize_title( __( 'performance',
> 'w3-total-cache' ) ) . '_page_w3tc_extensions', array(
> '\W3TC\Extension_CloudFlare_Page', 'admin_print_scripts_w3tc_extensions'
> ) );
> }}}
>

> I reviewed documentation and other sources for notes or solutions for
> this issue but found sparse documentation and found few other parties
> experiencing this issue. My question is whether this behavior is
> intended/expected and/or if there is a better solution than the 2 I
> outlined?
>
> **Part II**
>
> Additionally with regard to applying translations I discovered that the
> user's locale/language setting (added in WP 4.7) wasn't applying for our
> plugin if the core language setting was set to non-english with our
> translation files automatically copied to wp-content/languages/plugins.
> My solution to this also felt "hackish" in that we reset the global $l10n
> and $l10n_unloaded variables before applying our load_plugin_textdomain.
> I attempted various other solutions I found during my research but non
> resolved the issue despite documentation seeming fairly straightforward
> and simple. My question here is whether the default behavior when
> applying translations to a plugin via load_plugin_textdomain takes the
> user's locale/language setting into account and/or if additional code is
> required for it to apply? Additionally the documentation for
> internationalizing themes/plugins doesn't appear to mention or reference
> the user locale/language setting so perhaps this needs to be updated?
>
> Via init hook:
> {{{#!php
> <?php
>                 // Load W3TC textdomain for translations.
>                 $this->reset_l10n();
>                 load_plugin_textdomain( W3TC_TEXT_DOMAIN, false, dirname(
> plugin_basename( __FILE__ ) ) . '/languages' );
> }}}
>
> Thanks!

New description:

 To whom it may concern

 **Part I**

 I am a developer for W3TC and recently diagnosed an issue with our plugin
 under WP6.0.3/PHP8.1 regarding the use of an
 `admin_print_scripts-{$hook_suffix}` not applying under non-english
 translation due to our plugin's topmost menu page via `add_menu_page`
 containing a translated `$menu_title` parameter. This resulted in the
 hook's `$page_type` parameter under `get_plugin_page_hookname` being
 translated, thereby not allowing our JS/CSS to print as expected

 Under `es_ES` translation:
 Expected: page hook = `performance_page_w3tc_extensions`
 Received: page hook = `actuacion_page_w3tc_extensions`

 I determined 2 solutions
 1. Remove the translation from the `add_menu_page` resulting in the
 topmost menu item remaining in English which isn't preferred
 {{{#!php
 <?php
                 add_menu_page(
                         __( 'Performance', 'w3-total-cache' ),
                         __( 'Performance', 'w3-total-cache' ),
                         apply_filters(
                                 'w3tc_capability_menu_w3tc_dashboard',
                                 $base_capability
                         ),
                         'w3tc_dashboard',
                         '',
                         'none'
                 );
 }}}

 2. Apply translations to our `$hook_suffix` in each use of
 `admin_print_scripts-{$hook_suffix}` which is preferred but seems
 "hackish"
 {{{#!php
 <?php
 add_action( 'admin_print_scripts-' . sanitize_title( __( 'performance',
 'w3-total-cache' ) ) . '_page_w3tc_extensions', array(
 '\W3TC\Extension_CloudFlare_Page', 'admin_print_scripts_w3tc_extensions' )
 );
 }}}


 I reviewed documentation and other sources for notes or solutions for this
 issue but found sparse documentation and found few other parties
 experiencing this issue. My question is whether this behavior is
 intended/expected and/or if there is a better solution than the 2 I
 outlined?

 **Part II**

 Additionally with regard to applying translations I discovered that the
 user's locale/language setting (added in WP 4.7) wasn't applying for our
 plugin if the core language setting was set to non-english with our
 translation files automatically copied to `wp-content/languages/plugins`.
 My solution to this also felt "hackish" in that we reset the global
 `$l10n` and `$l10n_unloaded` variables before applying our
 `load_plugin_textdomain`. I attempted various other solutions I found
 during my research but non resolved the issue despite documentation
 seeming fairly straightforward and simple. My question here is whether the
 default behavior when applying translations to a plugin via
 `load_plugin_textdomain` takes the user's locale/language setting into
 account and/or if additional code is required for it to apply?
 Additionally the documentation for internationalizing themes/plugins
 doesn't appear to mention or reference the user locale/language setting so
 perhaps this needs to be updated?

 Via init hook:
 {{{#!php
 <?php
                 // Load W3TC textdomain for translations.
                 $this->reset_l10n();
                 load_plugin_textdomain( W3TC_TEXT_DOMAIN, false, dirname(
 plugin_basename( __FILE__ ) ) . '/languages' );
 }}}

 Thanks!

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57079#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform