Como o Gutenberg lida com traduções no React?

Eu estava atravessando o código fonte de Gutenberg, por exemplo desta e não consegue entender como eles lidam com traduções ...

Eles importam isso import { __ } from '@wordpress/i18n'e, em seguida, no código-fonte, eles usam isso speak( __( 'Block settings closed' ) );.

Alguém pode me dizer como eles gerenciam essas traduções no ReactJS para serem coletadas em um arquivo .po normal?

Suponho que eles tenham algum processo de compilação que percorre todos os arquivos, incluindo JS e os coleta, mas não tenho certeza.

No repositório GitHub do Gutenberg, você pode ver a fonte do pacote i18n usado. Nesta fonte, você verá o Jed sendo importado (linha 4 do gutenberg / packages / i18n / src / index.js) e sendo usado na maioria das tarefas de tradução.

Jed apresenta o "Gettext Style i18n para aplicativos modernos de JavaScript" (ou pelo menos assim diz em seu site).

Sua pergunta é para os arquivos .po. Jed explica em seu site:

Existem alguns conversores .po para .json disponíveis no mercado. Os arquivos .po da Gettext são saída padrão da maioria das empresas de tradução decentes, pois é um padrão antigo.

Atualmente, uso: po2json

No entanto, gostaria de adicionar essa funcionalidade a um módulo Jed separado em uma versão futura.

No entanto, isso não parece se aplicar aqui.

Mais escavações setLocaleData( data: Object, domain: string )são usadas para passar as traduções, da seguinte maneira :

$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 )sendo mais ou menos um invólucro para get_translations_for_domain( $domain ))

Parece que o WordPress recupera os dados de tradução via PHP e os passa para Jed. O próprio Jed não parece carregar nenhum arquivo de tradução.

O leia-me do pacote também explica como gerar corretamente o arquivo .pot que contém as seqüências localizadas.

O pacote também inclui um pot-to-phpscript usado para gerar arquivos php contendo as mensagens listadas em um arquivo .pot. Isso é útil para enganar a descoberta de strings de tradução do WordPress.org, pois, no momento, o WordPress.org não é capaz de analisar strings diretamente de arquivos JavaScript.

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

Pelo menos por enquanto, desde que não exista um processo automatizado melhor, sugiro não gerar arquivos .pot a partir de JS.

Como o @kero explica em sua resposta agora, as traduções do GB estão sendo passadas como uma espécie de array de blob do arquivo .mo para o JS. Esse fluxo de trabalho interromperá todos os plugins de violação de localização que dependem da filtragem dos resultados __e associados. Um fluxo de trabalho melhor será ter uma geração explícita da matriz de blob a partir de cadeias sendo traduzidas com __chamadas, semelhante à maneira como você faria a tradução JS em um contexto que não seja GB. Isso também resolverá o problema de gerar arquivos .pot.

O que está faltando aqui é algum processo automatizado que executará arquivos JS e produzirá o código PHP relevante, que por sua vez pode ser analisado por ferramentas como poedit.