Vtyjkyuk

I was going through the source code of Gutenberg, for e.g. this and cannot understand how they handle translations...

They do import this import __ from '@wordpress/i18n' and then in the source code they use this speak( __( 'Block settings closed' ) );.

Can anybody tell me how they manage these translations within ReactJS to be collected in a normal .po file?

I suppose they have some build process which goes through all of the files, including JS and collects them, but now sure.

In the Gutenberg's GitHub repository you can see the source of the i18n package that is used. In this source, you'll see Jed getting imported (line 4 of gutenberg/packages/i18n/src/index.js) and then being used for most of the translation tasks under the hood.

Jed introduces the "Gettext Style i18n for Modern JavaScript Apps" (or at least so it says on their site).

Your question is for the .po files. Jed explains on their site:

There are quite a few available .po to .json converters out there. Gettext .po files are standard output from most decent translation companies, as it's an old standard.

I currently use: po2json

However, I'd like to add this functionality to a separate Jed module in a future version.

However, this does not seem to apply here.

Further digging turns out, setLocaleData( data: Object, domain: string ) is used to pass the translations, in a manner like so:

$locale_data = gutenberg_get_jed_locale_data( 'gutenberg' );
wp_add_inline_script(
 'wp-i18n',
 'wp.i18n.setLocaleData( ' . json_encode( $locale_data ) . ' );'
);

(gutenberg_get_jed_locale_data( $domain ) being more or less a wrapper for get_translations_for_domain( $domain ) )

So it seems WordPress retrieves the translation data via PHP and then passes it to Jed. Jed itself does not seem to load any translation files.

The package's readme also explains how to properly generate the .pot file containing the localized strings.

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.

npx pot-to-php languages/myplugin.pot languages/myplugin-translations.php text-domain

At least for now, as long as there is no better automated process, I would suggest not to generate .pot files from JS at all.

As @kero explains in his answer right now GB translations are being passed as a kind of blob array from the .mo file into JS. This workflow will break all localization tampering plugins which rely on filtering the results of __ and associates. A better workflow will be to have an explicit generation of the blob array from strings being translated with __ calls, similar to how you would do JS translation in non GB context. This will also solve the issue of generating .pot files.

What is missing here is some automated process that will run over JS files and produce he relevant PHP code, which in turn can be analyzed by tools like poedit.