[wp-trac] [WordPress Trac] #60999: Issues with new i18n logic when handling translation files (MO/PHP)

[WordPress Trac]

#60999: Issues with new i18n logic when handling translation files (MO/PHP)
--------------------------+-----------------------------
 Reporter:  fengyintseng  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  I18N          |    Version:  6.5
 Severity:  critical      |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 Hi,

 Recently I am translating a plugin (also its Pro version). It works fine
 in v6.4.3 when I placed the MO files under path /wp-
 content/languages/plugins/.

 This Tuesday my site was upgraded to v6.5 and all the translations are set
 back to the old ones.
 Found a new file "xxxxx-zh_TW.l10n.php" generated under /wp-
 content/languages/plugins/ (and also corresponding PO/MO files),
 apparently the new translations are from this PHP file now.

 (below please find the issues identified during my experiments)

 **Step 1**
 I tried to re-generated the PHP file according to the PO file I uploaded
 to the path with below command:
 {{{
 wp i18n make-php .
 }}}

 With old method (before 6.5), if I upload the MO file which includes only
 the translated strings, the translated strings will be reflected
 successfully on Front and Back ends without affecting the untranslated
 parts.

 After I generate the PHP file according to the PO file, as the PO file
 includes all the strings (translated & un-translated), the un-translated
 strings will be treated as BLANK/EMPTY and unable to be displayed on Front
 and Back ends (no placeholder either).

 This issue seems already identified in 6.5-RC3 but it can be replicated in
 6.5 official release as well.

 **Step 2**
 Referring to the article "https://make.wordpress.org/core/2024/02/27/i18n-
 improvements-6-5-performant-translations/", use below filter to customize
 the behavior to use MO file instead of PHP file.

 {{{#!php
 <?php
 add_filter(
         'translation_file_format',
         static function () {
                 return 'mo';
         }
 );
 }}}

 By this way, I should be able to avoid the empty string issue addressed in
 #1; However, the MO file that I uploaded will also be overwritten by the
 generated MO file based on old translations (from translate.wordpress.org)
 periodically. Apart from that, I found system still use the strings from
 PHP file instead of the MO file in the folder.

 So it won't solve the problem. And there is issue with the functionality
 of translation_file_format.

 **Step 3**
 Friend suggests me to customize the translation file path, it will be
 entitled with highest priority for system to decide which translation
 files to serve.

 So I refer to below documents:
 * https://developer.wordpress.org/reference/hooks/load_textdomain_mofile/
 * https://developer.wordpress.org/reference/hooks/load_translation_file/

 Use below filter to specify the translation file path for the specified
 plugin.

 {{{#!php
 <?php
 add_filter( 'load_translation_file', 'my_custom_translation_file', 10, 2
 );

 /*
  * Replace 'textdomain' with your plugin's textdomain. e.g. 'hello-dolly'.
  * Define your filename, such as: yourtranslationfile-en_GB.mo
  * Define the location, for example: wp-content/languages/textdomain
 /yourtranslationfile-en_GB.mo
 */
 function my_custom_translation_file( $mofile, $domain ) {
   if ( 'plugin_name' === $domain ) {
     $mofile = WP_CONTENT_DIR . '/my-languages/plugin_name-' . get_locale()
 . '.mo';
   }
   return $mofile;
 }
 }}}

 However, whenever there is MO file (or PHP file) exists under /wp-
 content/languages/plugins/ it will use that file first, even though the
 translated strings are already in the MO file under new path /wp-content
 /my-languages/.

 With this filter, it will use the translated strings of the MO file under
 /wp-content/my-languages/ as supplement (a fallback) when those strings
 are not existed in the MO file under /wp-content/languages/plugins/.

 It looks like the old logic for path priority is no longer applicable in
 version higher than 6.5

 -

 The identified issues will affect all the users that used their own
 translation files on their sites that are already upgraded to 6.5.

 Please help check and kindly let me know if I missed anything.

 Thanks.

 Best regards,
 Feng

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