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
windowpropiedad como JSON cargado a travéswp_add_inline_scriptde PHP y luego lo recupera en el lado Reaccionar y se lo pasa a Jed? ... y Jed hace más magia?windowpropiedad, pero sí. PHP recupera los valores y los pasa a JS a través dewp_add_inline_scriptAl 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.
fuente
pot-to-phpscript utilizado para generar un archivo php que contiene los mensajes enumerados en un archivo .pot. Esto es útil para engañar al descubrimiento de cadenas de traducción de WordPress.org "