Jak přeložit soubory .po Drupalu pomocí AI

Většina lidí si spojuje soubory .po s WordPress, ale formát gettext předchází WordPress o desetiletí a pohání překlad rozhraní v celém open-source světě. Drupal je jedním z jeho největších uživatelů. Pokud provozujete vícejazyčný web na Drupalu, každá položka menu, popis pole, chybová zpráva a řetězec modulu prochází soubory .po přesně tak, jako ve WordPressu, jen s jiným dialektem zástupných symbolů a jiným pracovním postupem importu. A stejně jako ve WordPressu, jakmile váš web přeroste hrstku řetězců, ruční překlad těchto souborů se stává úzkým hrdlem.

Tento průvodce se zaměřuje na to, jak překládat soubory po Drupalu pomocí AI, aniž by se porušilo to, co dělá Drupal Drupalem. Projdeme si překladový systém Drupalu, odkud řetězce skutečně pocházejí, syntaxi zástupných symbolů, která se liší od WordPressu a musí být absolutně zachována, a kompletní smyčku exportu, překladu a opětovného importu včetně příkazů drush, které ji činí opakovatelnou.

Jak funguje překladový systém Drupalu

Drupal zpracovává překlad rozhraní prostřednictvím základního modulu locale (někdy v moderním Drupalu nazývaného „Interface Translation“). Jakmile je povolen, spravuje databázovou tabulku zdrojových řetězců a jejich překladů pro každý jazyk a dokáže tyto překlady importovat a exportovat jako standardní soubory gettext .po.

Administrační rozhraní se nachází na /admin/config/regional/translate. Odtud můžete vyhledávat nepřeložené řetězce, upravovat je přímo a, což je klíčové, importovat soubor .po pro hromadné načtení překladů nebo exportovat aktuální stav do souboru .po pro offline úpravy. Tento cyklus export/úprava/import je pracovní postup, který optimalizujeme.

Na rozdíl od WordPressu, kde každý plugin a téma dodává své vlastní soubory .po a .mo do adresáře languages/, Drupal centralizuje řetězce rozhraní ve své databázi a s .po zachází jako s výměnným formátem. Exportujete, pracujete na souboru a importujete jej zpět. Krok kompilace .mo, který WordPress vyžaduje, je zpracováván interně.

Odkud řetězce pocházejí

Řetězce Drupalu pocházejí ze tří míst a kompletní překlad musí pokrýt všechna z nich:

• Jádro (Core) dodává tisíce přeložitelných řetězců pro administrátorské rozhraní, formuláře a systémové zprávy.
• Moduly Contrib (Views, Webform, Commerce a ostatní) registrují každý své vlastní řetězce pomocí funkce t().
• Témata (Themes) přispívají šablonovými řetězci, popisky regionů a popisy nastavení tématu.

Když exportujete z /admin/config/regional/translate, můžete rozsah exportu omezit na přeložené, nepřeložené nebo všechny řetězce. Pro čerstvou překladovou pasáž vám export pouze nepřeložených řetězců poskytne cílený soubor .po s přesně tou prací, která zbývá.

Praktický důsledek této třízdrojové struktury: vaše překladatelská práce není nikdy skutečně „hotová“. Pokaždé, když přidáte modul contrib, povolíte novou funkci nebo aktualizujete jádro Drupalu, objeví se v tabulkách locale nová dávka nepřeložených položek msgid. Proto týmy Drupalu považují překlad spíše za opakující se proces než za jednorázový úkol spuštění. Stejná smyčka exportu, překladu a opětovného importu běží při každém nasazení, které se dotkne modulů, a čím rychlejší je tato smyčka, tím méně překladatelského dluhu se hromadí mezi vydáními.

Je také třeba poznamenat, že Drupal dokáže automaticky stahovat komunitní překlady z localize.drupal.org pro jádro a populární moduly contrib. Ty pokrývají běžné řetězce, ale zřídka pokrývají vaše vlastní moduly, vaše téma nebo projektově specifické fráze, které váš web skutečně používá. Mezera mezi komunitním překladem a plně lokalizovaným webem je přesně ta práce, kterou AI rychle uzavře.

Zástupné symboly Drupalu nejsou zástupnými symboly WordPressu

Zde je nejdůležitější věc, kterou je třeba pochopit, než pošlete jakýkoli soubor .po Drupalu AI překladači: Drupal nepoužívá zástupné symboly typu printf %s a %1$s, které dominují ve WordPressu. Funkce t() Drupalu používá tři odlišné předpony zástupných symbolů, každou s jiným chováním pro escapování:

• @variable — hodnota je HTML-escapovaná, bezpečný výchozí stav pro text dodaný uživatelem.
• %variable — hodnota je escapovaná a zabalená do <em> zvýraznění.
• :placeholder — používá se pro atributy URL, prochází sanitizací URL.

Typický zdrojový řetězec Drupalu vypadá v exportovaném souboru .po takto:

#: 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 ""

Pokud překladatel změní @count na @cuenta, nahradí @name přeloženým slovem pro „jméno“ nebo vloží mezeru, čímž se @count změní na @ count, zástupný symbol se již neshoduje s tím, co předává volání t(). Drupal pak vytiskne na stránku doslovný token @count místo skutečného čísla. Překlad vypadá hotový, ale web je viditelně rozbitý.

Jedná se o stejnou třídu chyby, která se vyskytuje u řetězců WordPress %s, a obecný princip podrobně popisujeme v článku jak překládat soubory PO bez narušení proměnných kódu. Specifikum Drupalu je jednoduše to, že existují tři styly zástupných symbolů místo jednoho, a překladatelský nástroj je musí všechny rozpoznat.

Proč zde selhávají obecné překladače

Vložte ten řetězec node.module do spotřebitelského strojového překladače a často se vám stane, že @count bude zkomolen, %date vázané na <em> bude lokalizováno na jiný token nebo se pluralizační formy zhroutí do jedné. Žádný z těchto nástrojů nebyl vytvořen s ohledem na sémantiku gettext. Překládají text; nechápou, že @count je smlouva s kódem aplikace.

Překladová pipeline s podporou gettext a funkcí Syntax Locking zachází s @variable, %variable a :placeholder jako s neměnnými tokeny. Před překladem jsou uzamčeny a po překladu obnoveny, takže okolní věta je přeložena, zatímco zástupné symboly projdou nedotčeny. Stejné uzamčení pokrývá WordPress %s a %1$s, i18next {{name}} a inline HTML, což je důvod, proč jediný nástroj může sloužit projektu Drupal, Symfony nebo Laravel stejně snadno jako WordPressu. Pluralizační formy Drupalu prostřednictvím msgid_plural jsou zachovány jako pluralizační formy, spíše než zploštěny, což je důležité, protože jazyky Drupalu mohou mít kdekoli od jedné do šesti pluralizačních variant.

Je zde také jemnější režim selhání, který stojí za zmínku. Řetězce Drupalu často obsahují inline značky a odkazy uvnitř přeložitelného textu, například Read the <a href=":url">documentation</a>, kde :url je zástupný symbol a značky <a> musí přežít. Překladač, který nerozumí struktuře, může přeložit atribut href, vypustit uzavírací značku nebo lokalizovat název zástupného symbolu. Context-Aware AI, která čte celý řetězec jako jednotku, v kombinaci s uzamykáním tokenů, zachovává jak značky, tak kontrakt :url neporušené, zatímco překládá pouze lidsky čitelný text „documentation“ mezi nimi.

Smyčka export-překlad-opětovný import

Opakovatelný pracovní postup má tři fáze a drush umožňuje skriptování exportu a importu, takže nemusíte pokaždé proklikávat administrátorské rozhraní.

Krok 1: Exportujte soubor PO

Exportovat můžete z UI na /admin/config/regional/translate výběrem jazyka a rozsahu exportu, nebo to udělat z příkazového řádku. Modul locale zpřístupňuje export prostřednictvím překladových služeb Drupalu a většina týmů ho skriptuje. Typické vyvolání drush pro spuštění importu překladu (opak, který použijeme ve třetím kroku) vypadá takto:

# 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

Pro stranu exportu generuje administrativní exportní formulář soubor .po; mnoho týmů obaluje službu locale exportu do malého vlastního příkazu Drush pro plnou automatizaci. Ať tak či onak, skončíte se standardním souborem gettext .po obsahujícím vaše nepřeložené položky msgid.

Krok 2: Přeložte soubor

Toto je fáze, kde AI nahrazuje hodiny ručních úprav. Nahrajte exportovaný soubor .po do cloudového překladače, vyberte cílový jazyk a nechte jej zpracovat. Protože soubory .po Drupalu pro velký web běžně překračují 10MB, jakmile se zkombinují jádro, contrib moduly a témata, Smart Batching je zde důležité: soubor je rozdělen, přeložen a znovu sestaven, aniž byste jej museli ručně dělit nebo narážet na limity velikosti. Výstupem je kompletní soubor .po s každým msgstr vyplněným a každým zástupným symbolem @count, %date a :url přesně tam, kde začal.

Krok 3: Opětovný import do Drupalu

Importujte přeložený soubor zpět prostřednictvím /admin/config/regional/translate nebo pomocí příkazu drush locale:import zobrazeného výše a poté přestavte cache. Drupal sloučí překlady do svých tabulek locale a řetězce se okamžitě objeví na celém webu. Opakujte smyčku vždy, když přidáte modul nebo aktualizujete jádro, protože každý přináší nové nepřeložené řetězce.

Jeden detail importu, který je třeba správně nastavit: příznak --override určuje, zda příchozí překlady nahradí stávající. Použijte --override=all, pokud chcete, aby byl soubor přeložený AI autoritativní, nebo konzervativnější nastavení, pokud jste některé řetězce v UI Drupalu ručně upravili a nechcete je přepsat. Pro většinu automatizovaných pipeline platí, že považování souboru .po za zdroj pravdy a přepsání všeho udržuje systém předvídatelný: soubor v řízení verzí je to, co web ukazuje, tečka.

Pro vícejazyčné weby s několika cílovými jazyky běží smyčka jednou pro každý jazyk. Exportujte nepřeloženou sadu, přeložte ji do němčiny, importujte; znovu exportujte, přeložte do španělštiny, importujte; a tak dále. Protože každý jazyk je nezávislý soubor .po, můžete je spouštět paralelně a cloudový překladač, který je zpracovává současně, změní to, co dříve trvalo týden práce dodavatele, na odpoledne.

PO Drupalu je jedním z několika formátů

Stojí za zmínku, že gettext .po není jediný způsob, jak Drupal zpracovává překlad. Konfigurace a obsahové entity mohou být také vyměňovány jako XLIFF, což je standard, na který se modul Translation Management Tool (TMGMT) spoléhá pro pracovní postupy profesionálních překladatelských dodavatelů. Pokud vaše lokalizace Drupalu probíhá prostřednictvím XLIFF namísto rozhraní .po souborů, principy zachování zástupných symbolů jsou identické, ale struktura souboru se liší, a tuto cestu pokrýváme v článku překlad souborů XLIFF pro Drupal, Symfony a Angular.

Pro vrstvu překladu rozhraní však .po zůstává tahounem. Smyčka export, AI překlad, opětovný import mění vícedenní ruční práci na několik minut zpracování, a pokud nástroj, který používáte, skutečně rozumí zástupným symbolům gettext, vaše kontrakty @variable zůstanou nedotčené a váš web Drupal zůstane funkční v každém jazyce, který dodáte.

Jste připraveni přeložit své soubory .po Drupalu, aniž byste porušili jediný @variable? Vyzkoušejte SimplePoTranslate zdarma — není vyžadována kreditní karta. Bezplatná úroveň zpracovává standardní soubory gettext .po a .pot s plným Syntax Locking, takže vaše zástupné symboly Drupalu projdou přesně tak, jak očekává kód.