Jak przetłumaczyć pliki .po Drupal za pomocą AI

Większość ludzi kojarzy pliki .po z WordPress, ale format gettext poprzedza WordPress o dziesięciolecia i zasila tłumaczenie interfejsów w całym świecie open-source. Drupal jest jednym z jego największych użytkowników. Jeśli prowadzisz wielojęzyczną witrynę Drupal, każda etykieta menu, opis pola, komunikat o błędzie i ciąg modułu przepływa przez pliki .po dokładnie tak samo jak w WordPress, tylko z innym dialektem symboli zastępczych i innym przepływem pracy importu. I tak samo jak w WordPress, w momencie gdy Twoja witryna rozrośnie się poza garstkę ciągów, ręczne tłumaczenie tych plików staje się wąskim gardłem.

Ten przewodnik dotyczy tego, jak tłumaczyć pliki po Drupal za pomocą AI, nie psując rzeczy, które czynią Drupal Drupallem. Przejdziemy przez system tłumaczeń Drupal, skąd faktycznie pochodzą ciągi, składnię symboli zastępczych, która różni się od WordPress i absolutnie musi zostać zachowana, a także pełną pętlę eksportu, tłumaczenia i ponownego importu, w tym komendy drush, które czynią ją powtarzalną.

Jak działa system tłumaczeń Drupal

Drupal obsługuje tłumaczenie interfejsu za pośrednictwem podstawowego modułu locale (czasami nazywanego w nowoczesnym Drupalu „Tłumaczeniem interfejsu”). Po włączeniu zarządza tabelą bazy danych ciągów źródłowych i ich tłumaczeń dla każdego języka, a także może importować i eksportować te tłumaczenia jako standardowe pliki gettext .po.

Interfejs administracyjny znajduje się pod adresem /admin/config/regional/translate. Stamtąd możesz wyszukiwać nieprzetłumaczone ciągi, edytować je w miejscu, a co najważniejsze, importować plik .po w celu masowego ładowania tłumaczeń lub eksportować bieżący stan do pliku .po w celu edycji offline. Ten cykl eksportu/edycji/importu to przepływ pracy, który optymalizujemy.

W przeciwieństwie do WordPress, gdzie każda wtyczka i motyw dostarcza własne pliki .po i .mo w katalogu languages/, Drupal centralizuje ciągi interfejsu w swojej bazie danych i traktuje .po jako format wymiany. Eksportujesz, pracujesz nad plikiem i importujesz go z powrotem. Krok kompilacji .mo, wymagany przez WordPress, jest obsługiwany wewnętrznie.

Skąd pochodzą ciągi

Ciągi Drupal pochodzą z trzech miejsc, a kompletne tłumaczenie musi obejmować wszystkie z nich:

• Rdzeń (Core) zawiera tysiące ciągów do tłumaczenia dla interfejsu administracyjnego, formularzy i komunikatów systemowych.
• Moduły contrib (Views, Webform, Commerce i pozostałe) rejestrują własne ciągi za pośrednictwem funkcji t().
• Motywy (Themes) dostarczają ciągi szablonów, etykiety regionów i opisy ustawień motywu.

Podczas eksportu z /admin/config/regional/translate możesz ograniczyć eksport do ciągów przetłumaczonych, nieprzetłumaczonych lub wszystkich. Dla świeżej partii tłumaczeń, eksportowanie tylko nieprzetłumaczonych ciągów daje Ci skoncentrowany plik .po z dokładnie tym, co pozostało do zrobienia.

Praktyczna konsekwencja tej trójźródłowej struktury: Twoja praca tłumaczeniowa nigdy nie jest tak naprawdę „skończona”. Za każdym razem, gdy dodajesz moduł contrib, włączasz nową funkcję lub aktualizujesz rdzeń Drupal, w tabelach locale pojawia się nowa partia nieprzetłumaczonych wpisów msgid. Dlatego zespoły Drupal traktują tłumaczenie jako powtarzający się proces, a nie jednorazowe zadanie uruchamiania. Ta sama pętla eksportu, tłumaczenia i ponownego importu działa przy każdym wdrożeniu, które dotyka modułów, a im szybsza jest ta pętla, tym mniej długu tłumaczeniowego gromadzi się między wydaniami.

Warto również zauważyć, że Drupal może automatycznie pobierać tłumaczenia od społeczności z localize.drupal.org dla rdzenia i popularnych modułów contrib. Pokrywają one typowe ciągi, ale rzadko obejmują Twoje niestandardowe moduły, Twój motyw lub specyficzne dla projektu sformułowania, których faktycznie używa Twoja witryna. Luka między tłumaczeniem społecznościowym a w pełni zlokalizowaną witryną to dokładnie ta praca, którą szybko zamyka przejście AI.

Symbole zastępcze Drupal to nie symbole zastępcze WordPress

Oto najważniejsza rzecz, którą należy zrozumieć przed wysłaniem jakiegokolwiek pliku .po Drupal do tłumacza AI: Drupal nie używa symboli zastępczych w stylu printf %s i %1$s, które dominują w WordPress. Funkcja t() Drupal używa trzech różnych prefiksów symboli zastępczych, każdy z innym zachowaniem ucieczki:

• @variable — wartość jest ucieknięta z HTML, bezpieczny domyślny dla tekstu wprowadzonego przez użytkownika.
• %variable — wartość jest ucieknięta i opakowana w znacznik podkreślenia <em>.
• :placeholder — używane dla atrybutów URL, przepuszczane przez sanitację URL.

Typowy ciąg źródłowy Drupal wygląda tak w wyeksportowanym pliku .po:

#: core/modules/node/node.module
msgid "@count comments"
msgid_plural "@count comments"
msgstr[0] ""
msgstr[1] ""

#: core/modules/user/user.module
msgid "Welcome @name, you last logged in on %date."
msgstr ""

Jeśli tłumacz zmieni @count na @cuenta, zastąpi @name przetłumaczonym słowem oznaczającym „name” lub wstawi spację, zmieniając @count na @ count, symbol zastępczy przestaje pasować do tego, co przekazuje wywołanie t(). Drupal wyświetli wtedy dosłowny token @count na stronie zamiast rzeczywistej liczby. Tłumaczenie wygląda na gotowe, ale witryna jest widocznie uszkodzona.

Jest to ta sama klasa błędów, która występuje w ciągach %s WordPress, a ogólną zasadę omawiamy szczegółowo w jak tłumaczyć pliki PO bez łamania zmiennych kodu. Specyfika Drupal polega po prostu na tym, że istnieją trzy style symboli zastępczych zamiast jednego, a narzędzie do tłumaczenia musi rozpoznawać wszystkie z nich.

Dlaczego ogólne tłumacze zawodzą w tym miejscu

Wklej ten ciąg node.module do ogólnego narzędzia do tłumaczenia maszynowego, a często otrzymasz zniekształcone @count, %date z <em> przetłumaczone na inny token, lub formy liczby mnogiej sprowadzone do jednej. Żadne z tych narzędzi nie zostało zbudowane z myślą o semantyce gettext. Tłumaczą one tekst; nie rozumieją, że @count to umowa z kodem aplikacji.

Potok tłumaczeniowy świadomy gettext z Blokadą Składni traktuje @variable, %variable i :placeholder jako niezmienne tokeny. Są one blokowane przed tłumaczeniem i przywracane po nim, dzięki czemu otaczające zdanie jest tłumaczone, podczas gdy symbole zastępcze przechodzą nienaruszone. Ta sama blokada obejmuje %s i %1$s WordPress, {{name}} i18next oraz wbudowany HTML, dlatego jedno narzędzie może służyć projektowi Drupal, Symfony lub Laravel tak samo łatwo jak projektowi WordPress. Formy liczby mnogiej Drupal za pośrednictwem msgid_plural są zachowywane jako formy liczby mnogiej, a nie spłaszczane, co ma znaczenie, ponieważ języki Drupal mogą mieć od jednej do sześciu wariantów liczby mnogiej.

Warto również wspomnieć o subtelniejszym trybie awarii. Ciągi Drupal często zawierają wbudowane znaczniki i linki w tekście do przetłumaczenia, takie jak Read the <a href=":url">documentation</a>, gdzie :url jest symbolem zastępczym, a tagi <a> muszą pozostać nienaruszone. Tłumacz, który nie rozumie struktury, może przetłumaczyć atrybut href, usunąć tag zamykający lub zlokalizować nazwę symbolu zastępczego. AI świadome kontekstu, które odczytuje cały ciąg jako jedną jednostkę, w połączeniu z blokowaniem tokenów, zachowuje zarówno znaczniki, jak i umowę :url w nienaruszonym stanie, tłumacząc jedynie czytelny dla człowieka tekst „documentation” pomiędzy nimi.

Pętla eksportu, tłumaczenia, ponownego importu

Powtarzalny przepływ pracy ma trzy etapy, a drush sprawia, że eksport i import są możliwe do zautomatyzowania, dzięki czemu nie musisz za każdym razem klikać w interfejsie administracyjnym.

Krok 1: Eksport pliku PO

Możesz eksportować z interfejsu użytkownika pod adresem /admin/config/regional/translate, wybierając język i zakres eksportu, lub zrobić to z wiersza poleceń. Moduł locale udostępnia eksport za pośrednictwem usług tłumaczeniowych Drupal, a większość zespołów to skryptuje. Typowe wywołanie drush w celu wywołania importu tłumaczenia (odwrotność, którą używamy w kroku trzecim) wygląda tak:

# Re-import a translated PO file for Spanish, overwriting customized strings
drush locale:import es /var/www/translations/es-untranslated.po \
  --type=customized --override=all

# Rebuild caches so the new strings render immediately
drush cache:rebuild

Jeśli chodzi o eksport, formularz eksportu administratora generuje plik .po; wiele zespołów owija usługę eksportu locale w małą niestandardową komendę Drush dla pełnej automatyzacji. Tak czy inaczej, otrzymujesz standardowy plik gettext .po zawierający Twoje nieprzetłumaczone wpisy msgid.

Krok 2: Tłumaczenie pliku

To jest etap, na którym AI zastępuje godziny ręcznej edycji. Prześlij wyeksportowany plik .po do tłumacza w chmurze, wybierz język docelowy i pozwól mu przetworzyć. Ponieważ pliki .po Drupal dla dużej witryny rutynowo przekraczają 10MB po połączeniu rdzenia, modułów contrib i motywów, Inteligentne Grupowanie ma tu znaczenie: plik jest dzielony na fragmenty, tłumaczony i ponownie składany bez ręcznego dzielenia go lub napotykania ograniczeń rozmiaru. Wynikiem jest kompletny plik .po z każdym wypełnionym msgstr oraz każdym symbolem zastępczym @count, %date i :url dokładnie tam, gdzie się zaczynał.

Krok 3: Ponowny import do Drupal

Zaimportuj przetłumaczony plik z powrotem przez /admin/config/regional/translate lub za pomocą komendy drush locale:import pokazanej powyżej, a następnie przebuduj pamięć podręczną. Drupal łączy tłumaczenia z tabelami locale, a ciągi pojawiają się na całej stronie natychmiast. Uruchom pętlę ponownie za każdym razem, gdy dodasz moduł lub zaktualizujesz rdzeń, ponieważ każdy z nich wprowadza nowe, nieprzetłumaczone ciągi.

Jeden szczegół importu, który należy dobrze zrozumieć: flaga --override kontroluje, czy przychodzące tłumaczenia zastępują istniejące. Użyj --override=all, gdy chcesz, aby plik przetłumaczony przez AI był autorytatywny, lub bardziej konserwatywnego ustawienia, jeśli ręcznie dostroiłeś pewne ciągi w interfejsie użytkownika Drupal, których nie chcesz nadpisywać. W większości zautomatyzowanych procesów, traktowanie pliku .po jako źródła prawdy i nadpisywanie wszystkiego sprawia, że system jest przewidywalny: plik w kontroli wersji to to, co pokazuje witryna, kropka.

Dla witryn wielojęzycznych z kilkoma językami docelowymi pętla działa raz dla każdego języka. Eksportuj zestaw nieprzetłumaczony, przetłumacz na niemiecki, zaimportuj; eksportuj ponownie, przetłumacz na hiszpański, zaimportuj; i tak dalej. Ponieważ każdy język to niezależny plik .po, możesz uruchamiać je równolegle, a tłumacz w chmurze przetwarzający je równocześnie zamienia to, co kiedyś było tygodniem pracy kontrahenta, w jedno popołudnie.

PO Drupal to jeden z kilku formatów

Warto zauważyć, że gettext .po to nie jedyny sposób, w jaki Drupal obsługuje tłumaczenie. Jednostki konfiguracyjne i treściowe mogą być również wymieniane jako XLIFF, co jest standardem, na którym opiera się moduł Translation Management Tool (TMGMT) dla profesjonalnych przepływów pracy z dostawcami tłumaczeń. Jeśli Twoja lokalizacja Drupal odbywa się za pośrednictwem XLIFF, a nie plików interfejsu .po, zasady zachowania symboli zastępczych są identyczne, ale struktura pliku się różni, i omawiamy tę ścieżkę w tłumaczeniu plików XLIFF dla Drupal, Symfony i Angular.

Jednak dla warstwy tłumaczenia interfejsu .po pozostaje podstawowym narzędziem. Pętla eksportu, tłumaczenia AI i ponownego importu zamienia wielodniową, ręczną pracę w kilka minut przetwarzania, a dopóki używane narzędzie naprawdę rozumie symbole zastępcze gettext, Twoje kontrakty @variable pozostają nienaruszone, a Twoja witryna Drupal pozostaje nienaruszona w każdym języku, który dostarczasz.

Gotowy do tłumaczenia plików .po Drupal bez łamania ani jednego @variable? Wypróbuj SimplePoTranslate za darmo — karta kredytowa nie jest wymagana. Darmowy plan obsługuje standardowe pliki gettext .po i .pot z pełną Blokadą Składni, więc Twoje symbole zastępcze Drupal przechodzą dokładnie tak, jak oczekuje kod.