Jak Gutenberg obsługuje tłumaczenia w React?

Przeglądałem kod źródłowy Gutenberga, na przykład dla tego i nie rozumiem, jak radzą sobie z tłumaczeniami ...

Importują to, import { __ } from '@wordpress/i18n'a następnie wykorzystują to w kodzie źródłowym speak( __( 'Block settings closed' ) );.

Czy ktoś może mi powiedzieć, w jaki sposób zarządza tłumaczeniami w ReactJS, które mają być gromadzone w normalnym pliku .po?

Podejrzewam, że mają jakiś proces kompilacji, który przechodzi przez wszystkie pliki, w tym JS i zbiera je, ale nie jestem pewien.

W repozytorium GitHub Gutenberga można zobaczyć źródło używanego pakietu i18n. W tym źródle zobaczysz Jeda importowanego (wiersz 4 gutenberg / packages / i18n / src / index.js), a następnie wykorzystywanego do większości zadań tłumaczeniowych pod maską.

Jed wprowadza „Gettext Style i18n dla nowoczesnych aplikacji JavaScript” (a przynajmniej tak napisano na ich stronie).

Twoje pytanie dotyczy plików .po. Jed wyjaśnia na swojej stronie:

Istnieje wiele dostępnych konwerterów .po na .json. Pliki .po Gettext są standardowym wyjściem większości porządnych firm tłumaczeniowych, ponieważ są starym standardem.

Obecnie używam: po2json

Chciałbym jednak dodać tę funkcję do osobnego modułu Jed w przyszłej wersji.

Nie wydaje się to jednak mieć tutaj zastosowania.

Okazuje się, że dalsze kopanie setLocaleData( data: Object, domain: string )służy do przekazywania tłumaczeń w następujący sposób :

$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 )mniej więcej opakowanie get_translations_for_domain( $domain ))

Wygląda więc na to, że WordPress pobiera dane tłumaczenia przez PHP, a następnie przekazuje je Jed. Sam Jed wydaje się nie ładować żadnych plików tłumaczeń.

Plik Readme pakietu wyjaśnia również, jak prawidłowo wygenerować plik .pot zawierający zlokalizowane ciągi.

Pakiet zawiera również pot-to-phpskrypt używany do generowania plików php zawierających komunikaty wymienione w pliku .pot. Jest to przydatne, aby oszukać wykrywanie ciągów tłumaczeń WordPress.org, ponieważ w tej chwili WordPress.org nie jest w stanie analizować ciągów bezpośrednio z plików JavaScript.

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

Przynajmniej na razie, dopóki nie ma lepszego zautomatyzowanego procesu, sugerowałbym, aby w ogóle nie generować plików .pot z JS.

Jak wyjaśnia @kero w swojej odpowiedzi, tłumaczenia GB są przekazywane jako rodzaj tablicy obiektów blob z pliku .mo do JS. Ten przepływ pracy spowoduje uszkodzenie wszystkich wtyczek naruszających lokalizację, które polegają na filtrowaniu wyników __i powiązań. Lepszym przepływem pracy będzie jawne generowanie tablicy obiektów blob z ciągów tłumaczonych za pomocą __wywołań, podobnie jak w przypadku tłumaczenia JS w kontekście innym niż GB. To rozwiąże również problem generowania plików .pot.

Brakuje tutaj zautomatyzowanego procesu, który będzie działał na plikach JS i generował odpowiedni kod PHP, który z kolei może być analizowany za pomocą narzędzi takich jak poedit.