Como Gutenberg lida com traduções no React?

10

Eu estava passando pelo código-fonte de Gutenberg, por exemplo this e não conseguem entender como eles lidar com traduções ...

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

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

Suponho que eles tenham algum processo de criação que passe por todos os arquivos, incluindo o JS, e os colete, mas não tenho certeza.

    
por Bologer 22.08.2018 / 07:47

2 respostas

6

Na Gutenberg você pode ver a fonte do pacote de i18n que é usado. Nesta fonte, você verá Jed se importado (linha 4 do gutenberg / packages / i18n / src / index.js) e, em seguida, sendo usado para a maioria das tarefas de tradução sob o capô.

Jed introduz o "i18n Gettext Estilo de Aplicativos JavaScript Modern" (ou pelo menos assim diz em seu site).

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

  

Existem alguns conversores disponíveis de .po para .json por aí. Os arquivos .po do Gettext são a saída padrão das empresas de tradução mais decentes, já que é um padrão antigo.

     

Eu uso atualmente: 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.

Além disso escavação despeja, setLocaleData( data: Object, domain: string ) é usado para passar as traduções, de uma maneira como :

$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 dispositivo de moldagem paraget_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 parece não carregar nenhum arquivo de tradução.

readme do pacote também explica como gerar corretamente o arquivo .pot contendo o strings localizadas.

  

O pacote também inclui um script pot-to-php 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, já que 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
    
por kero 22.08.2018 / 08:07
2

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

Como o @kero explica em sua resposta agora, as traduções do GB estão sendo passadas como uma espécie de matriz de blob do arquivo .mo para o JS. Este fluxo de trabalho irá quebrar todos os plugins de adulteração de localização que dependem da filtragem dos resultados de __ e associados. Um fluxo de trabalho melhor será ter uma geração explícita do array blob de strings sendo traduzida com __ chamadas, semelhante a como você faria a conversão de JS em um contexto não GB. Isso também resolverá o problema de gerar arquivos .pot.

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

    
por Mark Kaplun 22.08.2018 / 08:41