[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:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------
Changes (by swissspidy):

 * keywords:   => reporter-feedback
 * severity:  critical => normal


Comment:

 Hi there and welcome to WordPress Trac!

 > 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

 That means WordPress downloaded new translations from WordPress.org and
 added the new files.

 It sounds like you previously manually edited the files in that folder,
 which is risky because WordPress could simply override them during an
 update. If you customize translations, you should do so via
 translate.WordPress.org.

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

 There was an issue with empty strings in the `wp i18n make-php` command.
 Use `wp cli update --nightly` to get the latest version, and then run `wp
 i18n make-php` again.

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

 That's why putting your custom translations there is not a good idea. You
 should contribute your translations on translate.WordPress.org :-)

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

 If you use the filter like this, WordPress will always use the MO file,
 not the PHP file. Are you saying this is not the case for you?

 > Use below filter to specify the translation file path for the specified
 plugin.
 > 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/.

 Hmm that doesn't sound right. This filter should work perfectly. Where did
 you put it? It might be running too late.

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