Adapt Jetpack to use WordPress JS i18n, fix Gutenberg block i18n.

[zinigor]

Changes proposed in this Pull Request:

• Adapts JSON language files to be usable in WordPress client-side i18n.
• Rebuilds JSON language files.
• Adds a mechanism to integrate POT files that result from block building into jetpack-strings.php. The whole PHP file generation pipeline now consists of one i18n-calypso run, one msgcat run, and one msgexec run that executes a bash script for every translation.
• Paves the way for legacy i18n support and makes initial steps to move towards wp.i18n.

Testing instructions:

Currently blocks don't have any strings translated yet in the JSON files because the strings themselves are not present in the code. After merging this code we should be able to re-run language builds and get translated strings in blocks.

• Make sure the existing i18n works properly, including existing wp-admin Settings translations.

Proposed changelog entry for your changes:

• Adapted existing Jetpack translations to be used in WordPress i18n mechanisms.

[jetpackbot]

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Scheduled Jetpack release: February 5, 2019.
Scheduled code freeze: January 29, 2019

Generated by 🚫 dangerJS against 021a130

[jeherve]

I tried to test this, but could not get it to work. Maybe I did not test well.

---

• I seem to get the following error when I run yarn build-languages, afer deleting the existing language files in languages/json to start from scratch.

./tools/msgexec-callback.sh: line 20: conditional binary operator expected

In the end, my jetpack-strings.php file was empty for some reason. Should I have tested somehow differently?

• Should we clean up the 2 .pot files in the build folder to make sure they do not get shipped?
• Would there be a way for us not to commit all those json files, but instead only commit them on built branches?

[zinigor]

Thanks for trying to test, the updated version should be testable for you because I made it compatible with older bash versions. The incompatibility was the reason why your jetpack-strings.php file ended up empty.

Unfortunately, we'll have to commit the JSON files because they both change their name, and change their data format - existing Jetpack translations that are in master will not get picked up by the new system.

[jeherve]

It seems to work well for me now, and I like the approach of this. I have rebased the PR so it can be merged.

@zinigor What would you think about deleting the pot files before shipping, with something like this:

diff --git a/gulpfile.babel.js b/gulpfile.babel.js
index 5f7ee321a..c64537c73 100644
--- a/gulpfile.babel.js
+++ b/gulpfile.babel.js
@@ -196,6 +196,15 @@ gulp.task( 'languages:cleanup', function( done ) {
 				} );
 				done();
 			} );
+
+			log( 'Cleaning up POT files.' );
+			del( [
+				'_inc/build/blocks/*.pot',
+				'./_inc/build/jetpack-strings.pot',
+				'./_inc/build/merged-strings.pot',
+			] ).then( function() {
+				done();
+			} );
 		}
 	);
 } );

[jeherve]

For some reason we seem to have less strings here now than in the old jetpack-strings.php file:
https://github.com/Automattic/jetpack/blob/branch-7.0/_inc/jetpack-strings.php#L724

On my end, and that seems even weirder: if I run yarn build-languages on this branch locally, my jetpack-strings.php file only contains 633 lines.

What could explain all those differences?

[zinigor]

We have several strings in the old jetpack-strings.php file that are repeated several times, for example strings like "At A Glance" or "Connected" can be seen used two or three times. The new POT merging method using msgcat merges these into entries that are only used once. I didn't compare the diff string by string, but I'm betting that this is the reason.

[jeherve]

This seems to work well. I'll merge, and put this to good use today :)

[jeherve]

Cherry-picked to branch-7.0 in 7c224ea

[jeherve]

Here is the first run in the release branch: 0c16a17

It seems the strings from the blocks disappeared from the jetpack-strings.php file. I tried running yarn build-languages again after building the blocks from Automattic/wp-calypso#30303, but that did not help for some reason.

I did, however, notice this error during the run:

[18:16:24] Starting 'languages:phpize'...
[18:16:24] msgexec: warning: Locale charset "ASCII" is different from

[18:16:24]                   input file charset "UTF-8".
                  Output of 'msgexec' might be incorrect.
                  Possible workarounds are:
                  - Set LC_ALL to a locale with encoding UTF-8.
                  - Convert the translation catalog to ASCII using 'msgconv',
                    then apply 'msgexec',
                    then convert back to UTF-8 using 'msgconv'.

[jeherve]

After some chat, we managed to get the strings in 19d5f61.

We're going to need #11258 as well.