Как Гутенберг обрабатывает переводы в React?

Я просматривал исходный код Гутенберга, например, для этого и не могу понять, как они обрабатывают переводы ...

Они импортируют это import { __ } from '@wordpress/i18n'и затем используют в исходном коде speak( __( 'Block settings closed' ) );.

Кто-нибудь может сказать мне, как они управляют этими переводами в ReactJS, которые собираются в обычный файл .po?

Я предполагаю, что у них есть некоторый процесс сборки, который просматривает все файлы, включая JS, и собирает их, но не уверен.

В GitHub-репозитории Gutenberg вы можете увидеть исходный код используемого пакета i18n. В этом источнике вы увидите, как Джед импортируется (строка 4 из gutenberg / packages / i18n / src / index.js), а затем используется для большинства задач перевода под капотом.

Джед представляет «Gettext Style i18n для современных приложений JavaScript» (или, по крайней мере, так говорится на их сайте).

Ваш вопрос к файлам .po. Джед объясняет на их сайте:

Существует довольно много доступных конвертеров .po в .json. Файлы Getpoxt .po являются стандартным выходом большинства приличных переводческих компаний, так как это старый стандарт.

Я в настоящее время использую: po2json

Тем не менее, я хотел бы добавить эту функциональность в отдельный модуль Jed в будущей версии.

Тем не менее, это, кажется, не применяется здесь.

Получается, что дальнейшее копание setLocaleData( data: Object, domain: string )используется для передачи переводов таким образом :

$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 )будучи более или менее оберткой для get_translations_for_domain( $domain ))

Похоже, WordPress извлекает данные перевода через PHP и затем передает их Jed. Сам Джед, похоже, не загружает никаких файлов перевода.

В файле readme также объясняется, как правильно создать файл .pot, содержащий локализованные строки.

Пакет также включает в себя pot-to-phpсценарий, используемый для создания файлов php, содержащих сообщения, перечисленные в файле .pot. Это полезно, чтобы обмануть обнаружение строк перевода WordPress.org, так как в настоящее время WordPress.org не может анализировать строки непосредственно из файлов JavaScript.

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

По крайней мере, пока нет лучшего автоматизированного процесса, я бы предложил вообще не генерировать файлы .pot из JS.

Как объясняет @kero в своем ответе, переводы из GB передаются в виде своего рода BLOB-массива из файла .mo в JS. Этот рабочий процесс сломает все плагины для несанкционированного доступа, которые полагаются на фильтрацию результатов __и партнеров. Лучшим рабочим процессом будет явное генерирование массива BLOB-объектов из строк, переводимых с помощью __вызовов, аналогично тому, как вы выполняли бы JS-перевод в контексте без GB. Это также решит проблему создания файлов .pot.

Чего здесь не хватает, так это какого-то автоматизированного процесса, который запускает файлы JS и генерирует соответствующий код PHP, который, в свою очередь, может быть проанализирован такими инструментами, как poedit.