Translation Related Question/Bug

[jacobd91]

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
                   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
   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
                // Load W3TC textdomain for translations.
                $this->reset_l10n();
                load_plugin_textdomain( W3TC_TEXT_DOMAIN, false, dirname( plugin_basename( __FILE__ ) ) . '/languages' );

Thanks!

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the report.

Just noting that we're already tracking the first issue in #18857.

[swissspidy]

Duplicate of #18857.

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?

It does, but you need to wait for the user to be fully set up in WordPress. So if you load translations before init, this won't be the case.