Make WordPress Core

Opened 11 months ago

Last modified 11 months ago

#57079 new defect (bug)

Translation Related Question/Bug

Reported by: jacobd91's profile jacobd91 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: major Version: 6.0.3
Component: I18N Keywords:
Focuses: docs, administration Cc:

Description (last modified by sabernhardt)

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
                            __( 'Performance', 'w3-total-cache' ),
                            __( 'Performance', 'w3-total-cache' ),
  1. Apply translations to our $hook_suffix in each use of admin_print_scripts-{$hook_suffix} which is preferred but seems "hackish"
    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:

                // Load W3TC textdomain for translations.
                load_plugin_textdomain( W3TC_TEXT_DOMAIN, false, dirname( plugin_basename( __FILE__ ) ) . '/languages' );


Change History (2)

#1 @sabernhardt
11 months ago

  • Description modified (diff)
  • Focuses performance coding-standards removed

#2 @SergeyBiryukov
11 months ago

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

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

Note: See TracTickets for help on using tickets.