In che modo Gutenberg gestisce le traduzioni in React?

Stavo esaminando il codice sorgente di Gutenberg, per esempio questo e non riesco a capire come gestiscono le traduzioni ...

Lo importano import { __ } from '@wordpress/i18n'e quindi nel codice sorgente lo usano speak( __( 'Block settings closed' ) );.

Qualcuno può dirmi come gestiscono queste traduzioni all'interno di ReactJS per essere raccolte in un normale file .po?

Suppongo che abbiano un processo di compilazione che attraversa tutti i file, incluso JS e li raccoglie, ma non ne sono sicuro.

Nel repository GitHub di Gutenberg puoi vedere l'origine del pacchetto i18n che viene utilizzato. In questa fonte, vedrai Jed essere importato (riga 4 di gutenberg / pacchetti / i18n / src / index.js) e quindi utilizzato per la maggior parte delle attività di traduzione sotto il cofano.

Jed introduce il "Gettext Style i18n per le moderne app JavaScript" (o almeno così dice sul loro sito).

La tua domanda riguarda i file .po. Jed spiega sul loro sito:

Ci sono alcuni convertitori disponibili da .po a .json. I file .po di Gettext sono prodotti standard dalla maggior parte delle aziende di traduzione decenti, in quanto si tratta di un vecchio standard.

Attualmente uso: po2json

Tuttavia, vorrei aggiungere questa funzionalità a un modulo Jed separato in una versione futura.

Tuttavia, questo non sembra applicarsi qui.

Ulteriori scoperte risultano, setLocaleData( data: Object, domain: string )viene utilizzato per passare le traduzioni, in un modo simile :

$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 )essere più o meno un wrapper per get_translations_for_domain( $domain ))

Quindi sembra che WordPress recuperi i dati di traduzione tramite PHP e li passi a Jed. Jed non sembra caricare alcun file di traduzione.

Il file Leggimi del pacchetto spiega anche come generare correttamente il file .pot contenente le stringhe localizzate.

Il pacchetto include anche uno pot-to-phpscript utilizzato per generare un file php contenente i messaggi elencati in un file .pot. Questo è utile per ingannare la scoperta delle stringhe di traduzione di WordPress.org poiché al momento WordPress.org non è in grado di analizzare le stringhe direttamente dai file JavaScript.

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

Almeno per ora, fintanto che non esiste un processo automatizzato migliore, suggerirei di non generare affatto file .pot da JS.

Come spiega @kero nella sua risposta in questo momento, le traduzioni GB vengono passate come una sorta di array BLOB dal file .mo in JS. Questo flusso di lavoro interromperà tutti i plug-in di manomissione della localizzazione che si basano sul filtraggio dei risultati __e dei relativi associati. Un flusso di lavoro migliore sarà avere una generazione esplicita dell'array BLOB dalle stringhe tradotte con le __chiamate, in modo simile a come si farebbe con la traduzione JS in un contesto non GB. Questo risolverà anche il problema della generazione di file .pot.

Ciò che manca qui è un processo automatizzato che verrà eseguito su file JS e produrrà il relativo codice PHP, che a sua volta può essere analizzato da strumenti come Poedit.