Handle i18n strings deployed from barista

[manzoorwanijk]

Barista deploys JS assets along with translations to languages/event_espresso-translations-js.php file. We now need to wire up these translation files with the build system in this repo.

[tn3rb]

We now need to wire up these translation files with the build system in this repo.

What process were you following or intending to follow for this?

Reason I ask is because that languages/event_espresso-translations-js.php file does not appear to be formatted in any way that can be used by the functions for passing translations to our JS. I'm not even sure what's that file's purpose is supposed to be, since I can't find any references to how it is to be used.

In our tools/deploy.sh script we are using the following:

npx pot-to-php $JS_I18N_FILE $PHP_I18N_FILE event_espresso

to generate the languages/event_espresso-translations-js.php file, but that appears to be an older way of doing things, as WP has removed that from their own build process (see: https://github.com/WordPress/gutenberg/pull/12559/files#diff-1fd37fc9e500c15377cb5f8e26de0c0eL101)

None of the current official (and unofficial) documentation I could find, such as:

• https://developer.wordpress.org/apis/handbook/internationalization/#internationalizing-javascript

• https://developer.wordpress.org/block-editor/developers/internationalization/

• https://pascalbirchler.com/internationalization-in-wordpress-5-0/ <-- article by swissspidy

reference using pot-to-php so I'm wondering what examples you were following.

As well, all of the above documentation states that:

WordPress requires one translation file per script handle, with each file only containing strings relevant for that script

but the languages/event_espresso-translations-js.php file is just one long list of translations, seemingly for every string from every relevant package and domain for that repo.

From what I have read, the process is as follows (assuming WP-CLI is installed):

• Create Translation File: using WP-CLI run wp i18n make-pot to generate a .pot file (we alreay have this and can skip this step for now)

• Convert to JSON: run the wp i18n make-json command which:

  • extracts all JS strings from the regular PO translation files

  • saves them to individual JSON files

  • this needs to happen for EACH language that requires translation

• Register Translations for Scripts: call wp_set_script_translations() for each registered script that requires translation and provide the path to the JSON files generated in the previous step

[tn3rb]

AHA! Figured out what that npx pot-to-php function is for.

from: https://github.com/WordPress/gutenberg/tree/a1bc317086fca7602f03fcf88ea0c1de514656c3/packages/i18n#build

The package also includes a pot-to-php script used to generate a php files containing the messages listed in a .pot file. This is useful to trick WordPress.org translation strings discovery since at the moment, WordPress.org is not capable of parsing strings directly from JavaScript files.

so not sure if we need this at all, since we will likely have to build all of our POT files ourselves and won't be relying on WordPress.org.

Another problem is that the entries created by that function look something like:

#: languages/event_espresso-translations-js.php:1145
msgid "Price Calculator for Ticket: %s"
msgstr ""

which is associating that translation with the languages/event_espresso-translations-js.php file, whereas we need to associate that with the corresponding script/package/domain that the original string belongs to (in this case, it's likely the TPC package).

[manzoorwanijk]

What process were you following or intending to follow for this?

The reason for converting it to a .php file was that our build system should already be handling i18n strings from PHP files. So, the strings added to languages/event_espresso-translations-js.php file, will also be picked up by that build system.

languages/event_espresso-translations-js.php file does not appear to be formatted in any way that can be used by the functions for passing translations to our JS.

All translations from server-side are passed to JS via DOM data. When the translation files are loaded by the plugin, then we convert those translation into JED format (e.g. see core/services/assets/JedLocaleData.php). So the whole purpose of this approach is to let the current build system pick those i18n strings from the PHP file as it does for any other PHP files that use i18n functions.

that appears to be an older way of doing things, as WP has removed that from their own build process

That's true, but the problem is that there is no gettext parser for TypeScript yet. For this reason WP CLI make-pot can't handle TypeScript. I have given a link to GB issue here

From what I have read, the process is as follows (assuming WP-CLI is installed):

As I said, it doesn't support TS yet.

[manzoorwanijk]

since we will likely have to build all of our POT files ourselves and won't be relying on WordPress.org

That description of the script on GB is misleading. It's not only for wordpress.org, rather it is for all the get text parsers for PHP. For example, if EE hires a translator who uses POEdit, POEdit can scan all the PHP files for i18n strings and they can be translated easily. It's just one use case of adding strings to a php file.

Why I preferred this route? Reasons for merging/combining the JS i18n string with PHP

• We already translate or have translated many of those strings in PHP, so we can reuse those translations and avoid duplication.
• Translations will be kinda centralized, otherwise we will have to separately manage translations for JS.
• We won't need to change anything in our build/deployment workflow as it already scans PHP files for i18n strings.

we need to associate that with the corresponding script/package/domain that the original string belongs to

That's the only drawback of this approach that I can see. In fact, it's not really a drawback because we are going to commit languages/event_espresso-translations-js.php file and it contains the reference to the original JS source, so a translator can easily refer to this file if needed.

[tn3rb]

That description of the script on GB is misleading. It's not only for wordpress.org, rather it is for all the get text parsers for PHP

ahh ok... my bad.

I'll still need to make some changes to the server side assets registration in order to handle the translations better than what is happening now

[manzoorwanijk]

I'll still need to make some changes to the server side assets registration in order to handle the translations better than what is happening now

That doesn't change because of the new translation php file, right?

[tn3rb]

no... i'm primarily trying to untangle what's going on in EventEspresso\core\services\assets\I18nRegistry

[manzoorwanijk]

Build machine already takes care of this.