¿Cómo maneja Gutenberg las traducciones en React?

Estaba revisando el código fuente de Gutenberg, por ejemplo, esto y no puedo entender cómo manejan las traducciones ...

Importan esto import { __ } from '@wordpress/i18n'y luego en el código fuente lo usan speak( __( 'Block settings closed' ) );.

¿Alguien puede decirme cómo gestionan estas traducciones dentro de ReactJS para que se recopilen en un archivo .po normal?

Supongo que tienen un proceso de compilación que pasa por todos los archivos, incluido JS y los recopila, pero no estoy seguro.

En el repositorio GitHub de Gutenberg puede ver la fuente del paquete i18n que se utiliza. En esta fuente, verá 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.

Jed presenta el "Estilo Gettext i18n para aplicaciones JavaScript modernas" (o al menos eso dice en su sitio).

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

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

Actualmente uso: 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 la excavación adicional setLocaleData( data: Object, domain: string )se usa para pasar las traducciones, de la siguiente manera :

$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 una envoltura para get_translations_for_domain( $domain ))

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

El archivo Léame del paquete también explica cómo generar correctamente el archivo .pot que contiene las cadenas localizadas.

El paquete también incluye una pot-to-phpsecuencia de comandos utilizada para generar archivos php que contienen los mensajes enumerados 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, mientras no haya un mejor proceso automatizado, sugeriría no generar archivos .pot a partir de JS.

Como @kero explica en su respuesta en este momento, las traducciones de GB se pasan como una especie de conjunto de blobs del archivo .mo a JS. Este flujo de trabajo romperá todos los complementos de manipulación de localización que dependen del filtrado de los resultados __y asociados. Un mejor flujo de trabajo será tener una generación explícita de la matriz de blobs a partir de cadenas que se traducen con __llamadas, de forma similar a cómo haría la traducción JS en un contexto que no sea GB. Esto también resolverá el problema de generar archivos .pot.

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