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