¿Cómo maneja Gutenberg las traducciones en Reaccionar?

En el repositorio GitHub de Gutenberg puede ver la fuente del paquete i18n que se usa. En esta fuente, verás que Jed se importa (línea 4 de gutenberg / packages / i18n / src / index.js) y luego se usa para la mayoría de las tareas de traducción bajo el capó.

Jed introduce el "Gettext Style i18n para aplicaciones modernas de JavaScript" (o al menos así lo dice en su sitio).

Su pregunta es para los archivos .po. Jed explica en su sitio:

  

Hay bastantes convertidores de .po a .json disponibles por ahí. Los archivos .po de Gettext son una salida estándar de la mayoría de las empresas de traducción decentes, ya que es un estándar antiguo.

     

Actualmente utilizo: po2json

     

Sin embargo, me gustaría agregar esta funcionalidad a un módulo Jed separado en una versión futura.

Sin embargo, esto no parece aplicarse aquí.

Resulta que, además de las excavaciones, se utiliza setLocaleData( data: Object, domain: string ) para pasar las traducciones, :

$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 ) siendo más o menos un envoltorio para get_translations_for_domain( $domain ) ) a>

Parece que WordPress recupera los datos de traducción a través de PHP y luego los pasa a Jed. El propio Jed no parece cargar ningún archivo de traducción.

El paquete también explica cómo generar el archivo .pot que contiene el paquete. cadenas localizadas.

  

El paquete también incluye un script pot-to-php que se usa para generar archivos php que contienen los mensajes listados en un archivo .pot. Esto es útil para engañar al descubrimiento de cadenas de traducción de WordPress.org, ya que en este momento, WordPress.org no es capaz de analizar cadenas directamente desde archivos JavaScript.

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

Al menos por ahora, siempre que no haya un mejor proceso automatizado, sugeriría no generar archivos .pot de JS en absoluto.

Como @kero explica en su respuesta ahora mismo, las traducciones de GB se pasan como una especie de matriz de blob desde el archivo .mo a JS. Este flujo de trabajo interrumpirá todos los complementos de alteración de localización que se basan en el filtrado de los resultados de __ y asociados. Un mejor flujo de trabajo será tener una generación explícita de la matriz de blob a partir de cadenas que se traducen con __ llamadas, similar a cómo haría la traducción JS en un contexto que no sea GB. Esto también solucionará el problema de generar archivos .pot.

Lo que falta aquí es un proceso automatizado que se ejecutará sobre los archivos JS y producirá el código PHP relevante, que a su vez puede ser analizado por herramientas como poedit.