Comment Gutenberg gère-t-il les traductions dans React?

Je traversais le code source de Gutenberg, par exemple ce et ne peut pas comprendre comment ils traitent les traductions ...

Ils importent cela import { __ } from '@wordpress/i18n', puis dans le code source, ils l'utilisent speak( __( 'Block settings closed' ) );.

Quelqu'un peut-il me dire comment ils gèrent ces traductions dans ReactJS pour être collectées dans un fichier .po normal?

Je suppose qu'ils ont un processus de construction qui parcourt tous les fichiers, y compris JS et les recueille, mais pas sûr.

Dans le référentiel GitHub de Gutenberg, vous pouvez voir la source du package i18n utilisé. Dans cette source, vous verrez Jed importé (ligne 4 de gutenberg / packages / i18n / src / index.js) puis utilisé pour la plupart des tâches de traduction sous le capot.

Jed présente le "Gettext Style i18n pour les applications JavaScript modernes" (ou du moins, il est dit sur leur site).

Votre question concerne les fichiers .po. Jed explique sur leur site:

Il existe de nombreux convertisseurs .po en .json disponibles. Les fichiers Gettext .po sont la sortie standard de la plupart des sociétés de traduction décentes, car il s'agit d'une ancienne norme.

J'utilise actuellement: po2json

Cependant, j'aimerais ajouter cette fonctionnalité à un module Jed distinct dans une future version.

Cependant, cela ne semble pas s'appliquer ici.

Il s'avère que creuser davantage setLocaleData( data: Object, domain: string )est utilisé pour passer les traductions, de la manière suivante :

$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 )étant plus ou moins un wrapper pour get_translations_for_domain( $domain ))

Il semble donc que WordPress récupère les données de traduction via PHP, puis les transmet à Jed. Jed lui-même ne semble charger aucun fichier de traduction.

Le fichier Lisezmoi du package explique également comment générer correctement le fichier .pot contenant les chaînes localisées.

Le package comprend également un pot-to-phpscript utilisé pour générer un fichier php contenant les messages répertoriés dans un fichier .pot. Cela est utile pour tromper la découverte des chaînes de traduction de WordPress.org car pour le moment, WordPress.org n'est pas capable d'analyser les chaînes directement à partir de fichiers JavaScript.

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

Au moins pour l'instant, tant qu'il n'y a pas de meilleur processus automatisé, je suggère de ne pas générer de fichiers .pot à partir de JS.

Comme @kero l'explique dans sa réponse en ce moment, les traductions GB sont passées comme une sorte de tableau d'objets blob du fichier .mo dans JS. Ce flux de travail interrompra tous les plug-ins de falsification de localisation qui reposent sur le filtrage des résultats __et des associés. Un meilleur flux de travail sera d'avoir une génération explicite du tableau d'objets blob à partir de chaînes en cours de traduction avec des __appels, de la même manière que vous feriez une traduction JS dans un contexte non GB. Cela résoudra également le problème de génération de fichiers .pot.

Ce qui manque ici, c'est un processus automatisé qui s'exécutera sur les fichiers JS et produira le code PHP pertinent, qui à son tour peut être analysé par des outils comme poedit.