Wie geht Gutenberg mit Übersetzungen in React um?

Ich wollte durch den Quellcode von Gutenberg, für zB dies und kann nicht verstehen , wie sie Übersetzungen handhaben ...

Sie importieren dies import { __ } from '@wordpress/i18n'und verwenden es dann im Quellcode speak( __( 'Block settings closed' ) );.

Kann mir jemand sagen, wie sie diese Übersetzungen in ReactJS verwalten, um sie in einer normalen .po-Datei zu sammeln?

Ich nehme an, sie haben einen Erstellungsprozess, der alle Dateien, einschließlich JS, durchläuft und sie sammelt, aber nicht sicher ist.

Im GitHub-Repository von Gutenberg sehen Sie die Quelle des verwendeten i18n-Pakets. In dieser Quelle wird Jed importiert (Zeile 4 von gutenberg / packages / i18n / src / index.js) und dann für die meisten Übersetzungsaufgaben unter der Haube verwendet.

Jed stellt den "Gettext Style i18n für moderne JavaScript-Apps" vor (oder zumindest so heißt es auf ihrer Website).

Ihre Frage ist für die .po-Dateien. Jed erklärt auf ihrer Website:

Es gibt eine ganze Reihe von .po to .json-Konvertern. Gettext .po-Dateien sind Standardausgaben der meisten anständigen Übersetzungsunternehmen, da es sich um einen alten Standard handelt.

Ich benutze derzeit: po2json

Ich möchte diese Funktionalität jedoch in einer zukünftigen Version einem separaten Jed-Modul hinzufügen.

Dies scheint hier jedoch nicht zuzutreffen.

Weiteres Graben stellt sich heraus, setLocaleData( data: Object, domain: string )wird verwendet, um die Übersetzungen auf folgende Weise weiterzugeben :

$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 )mehr oder weniger ein Wrapper für get_translations_for_domain( $domain ))

Es scheint also, dass WordPress die Übersetzungsdaten über PHP abruft und sie dann an Jed weitergibt. Jed selbst scheint keine Übersetzungsdateien zu laden.

In der Readme-Datei des Pakets wird auch erläutert, wie die .pot-Datei mit den lokalisierten Zeichenfolgen ordnungsgemäß generiert wird.

Das Paket enthält auch ein pot-to-phpSkript zum Generieren von PHP-Dateien, die die in einer .pot-Datei aufgelisteten Nachrichten enthalten. Dies ist nützlich, um die Erkennung von WordPress.org-Übersetzungszeichenfolgen auszutricksen, da WordPress.org derzeit nicht in der Lage ist, Zeichenfolgen direkt aus JavaScript-Dateien zu analysieren.

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

Zumindest für den Moment würde ich empfehlen, keine POT-Dateien aus JS zu generieren, solange es keinen besseren automatisierten Prozess gibt.

Wie @kero in seiner Antwort erklärt, werden GB-Übersetzungen derzeit als eine Art Blob-Array aus der .mo-Datei an JS übergeben. Dieser Workflow unterbricht alle Plugins zur Manipulation der Lokalisierung, die auf dem Filtern der Ergebnisse __und der zugehörigen Elemente beruhen . Ein besserer Workflow besteht darin, das Blob-Array explizit aus Zeichenfolgen zu generieren, die mit __Aufrufen übersetzt werden, ähnlich wie Sie eine JS-Übersetzung in einem Nicht-GB-Kontext durchführen würden. Dadurch wird auch das Problem der Generierung von .pot-Dateien gelöst.

Was hier fehlt, ist ein automatisierter Prozess, der über JS-Dateien läuft und den relevanten PHP-Code erzeugt, der wiederum mit Tools wie poedit analysiert werden kann.