Hogyan fordítsuk le a Drupal .po fájljait AI segítségével
A legtöbben a .po fájlokat a WordPress-szel társítják, de a gettext formátum évtizedekkel megelőzi a WordPress-t, és az egész nyílt forráskódú világban az interfész fordítását szolgálja. A Drupal az egyik legnagyobb felhasználója. Ha többnyelvű Drupal webhelyet üzemeltet, minden menücímke, mezőleírás, hibaüzenet és modul string .po fájlokon keresztül áramlik, pontosan úgy, mint a WordPress-ben, csak más placeholder dialektussal és más importálási munkafolyamattal. És akárcsak a WordPress esetében, abban a pillanatban, amikor a webhelye túlnő néhány stringen, ezen fájlok kézi fordítása szűk keresztmetszetté válik.
Ez az útmutató arról szól, hogyan kell lefordítani a Drupal po fájlokat AI segítségével anélkül, hogy megtörné azokat a dolgokat, amelyek a Drupal-t Drupal-lé teszik. Végigmegyünk a Drupal fordítási rendszerén, azon, honnan származnak valójában a stringek, a placeholder szintaxison, amely eltér a WordPress-től, és amit feltétlenül meg kell őrizni, valamint a teljes exportálási, fordítási és újraimportálási körön, beleértve a drush parancsokat is, amelyek ismételhetővé teszik azt.
Hogyan működik a Drupal fordítási rendszere
A Drupal az interfész fordítást a core locale modulon keresztül kezeli (néha „Interfész Fordítás”-nak nevezik a modern Drupalban). Engedélyezés után kezeli a forrás stringek és azok fordításainak adatbázistáblázatát nyelvenként, és importálhatja és exportálhatja ezeket a fordításokat standard gettext .po fájlként.
Az admin felület a /admin/config/regional/translate címen található. Innen kereshet nem lefordított stringeket, szerkesztheti őket azonnal, és ami a legfontosabb, importálhat egy .po fájlt a fordítások tömeges betöltéséhez, vagy exportálhatja az aktuális állapotot egy .po fájlba offline szerkesztéshez. Ez az exportálási/szerkesztési/importálási ciklus az a munkafolyamat, amelyet optimalizálunk.
A WordPress-szel ellentétben, ahol minden plugin és téma saját .po és .mo fájlokat szállít egy languages/ könyvtárban, a Drupal központosítja az interfész stringeket az adatbázisában, és a .po-t tekinti csereformátumnak. Exportálja, dolgozik a fájllal, majd importálja vissza. A WordPress által megkövetelt fordított .mo lépést belsőleg kezelik.
Honnan származnak a stringek
A Drupal stringek három helyről származnak, és a teljes fordításnak mindegyiket le kell fednie:
- Core ezer fordítható stringet szállít az admin UI-hoz, űrlapokhoz és rendszerüzenetekhez.
- Contrib modulok (Views, Webform, Commerce és a többi) mindegyike regisztrálja saját stringjeit a
t()függvényen keresztül. - Témák hozzájárulnak sablon stringekkel, régiócímkékkel és téma-beállítás leírásokkal.
Amikor exportál a /admin/config/regional/translate helyről, korlátozhatja az exportot fordított, lefordítatlan vagy összes stringre. Egy friss fordítási körhöz, csak a lefordítatlan stringek exportálása fókuszált .po fájlt eredményez, pontosan a hátralévő munkával.
Ennek a háromforrású struktúrának a gyakorlati következménye: a fordítási munkája soha nem igazán „kész”. Minden alkalommal, amikor hozzáad egy contrib modult, engedélyez egy új funkciót, vagy frissíti a Drupal core-t, friss adag lefordítatlan msgid bejegyzés jelenik meg a locale táblákban. Ezért kezelik a Drupal csapatok a fordítást ismétlődő folyamatként, nem pedig egyszeri bevezetési feladatként. Ugyanaz az exportálási, fordítási, újraimportálási ciklus fut minden olyan telepítésnél, amely modulokat érint, és minél gyorsabb ez a ciklus, annál kevesebb fordítási adósság halmozódik fel a kiadások között.
Érdemes megjegyezni azt is, hogy a Drupal automatikusan letöltheti a közösség által hozzájárult fordításokat a localize.drupal.org oldalról a core és népszerű contrib modulok számára. Ezek lefedik az általános stringeket, de ritkán fedik le az egyedi moduljait, témáját vagy a webhelye által ténylegesen használt projekt-specifikus megfogalmazást. A közösségi fordítás és a teljesen lokalizált webhely közötti hiányosságot pontosan az AI fordítási passz zárja be gyorsan.
A Drupal placeholder-ei nem WordPress placeholder-ek
Íme a legfontosabb dolog, amit meg kell érteni, mielőtt bármilyen Drupal .po fájlt elküld egy AI fordítónak: A Drupal nem a printf stílusú %s és %1$s placeholder-eket használja, amelyek a WordPress-t uralják. A Drupal t() függvénye három különböző placeholder előtagot használ, mindegyik különböző escape viselkedéssel:
@variable— az érték HTML-escape-elt, biztonságos alapértelmezés a felhasználó által bevitt szöveghez.%variable— az érték escape-elt és<em>kiemelő jelölésbe van csomagolva.:placeholder— URL attribútumokhoz használatos, URL tisztításon megy keresztül.
Egy tipikus Drupal forrás string így néz ki az exportált .po fájlban:
#: 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 ""
Ha egy fordító az @count-ot @cuenta-ra változtatja, az @name-t lecseréli a „név” fordított szavára, vagy szóközt szúr be, így az @count @ count-tá válik, a placeholder már nem egyezik azzal, amit a t() hívás átad. A Drupal ekkor az @count literális tokent nyomtatja ki az oldalra az aktuális szám helyett. A fordítás késznek tűnik, de a webhely láthatóan hibás.
Ez ugyanaz a hibatípus, ami a WordPress %s stringeket is érinti, és az általános elvet részletesen tárgyaljuk a Hogyan fordítsunk PO fájlokat a kódváltozók megsértése nélkül című cikkben. A Drupal csavarja egyszerűen az, hogy egy helyett három placeholder stílus létezik, és egy fordítóeszköznek mindegyiket fel kell ismernie.
Miért hibáznak itt az általános fordítók
Illessze be azt a node.module stringet egy fogyasztói gépi fordító dobozba, és gyakran előfordul, hogy az @count elrontódik, az <em>-hez kötött %date egy másik tokenné lokalizálódik, vagy a többes számú formák egybeolvadnak. Ezen eszközök egyike sem készült a gettext szemantikát szem előtt tartva. Szöveget fordítanak; nem értik, hogy az @count egy szerződés az alkalmazáskóddal.
A gettext-tudatos fordítási folyamat a Syntax Locking-gal kezelve az @variable, %variable és :placeholder tokeneket megváltoztathatatlan tokenként kezeli. Fordítás előtt zárolva vannak, utána visszaállítva, így a környező mondat lefordítódik, miközözben a placeholder-ek érintetlenül maradnak. Ugyanez a zárolás vonatkozik a WordPress %s és %1$s, i18next {{name}} és beágyazott HTML elemekre, ezért egyetlen eszköz szolgálhatja ki a Drupal, Symfony vagy Laravel projektet ugyanolyan könnyedén, mint egy WordPress projektet. A Drupal többes számú formái a msgid_plural segítségével többes számú formákként maradnak meg, nem pedig lapítottan, ami azért fontos, mert a Drupal nyelveknek egytől hatig terjedő többes számú variánsa lehet.
Van egy finomabb hibamód is, amit érdemes megemlíteni. A Drupal stringek gyakran beágyazott jelöléseket és linkeket tartalmaznak a fordítható szövegben, mint például Read the <a href=":url">documentation</a>, ahol a :url egy placeholder, és az <a> tageknek meg kell maradniuk. Egy olyan fordító, amely nem érti a struktúrát, lefordíthatja az href attribútumot, elhagyhatja a záró taget, vagy lokalizálhatja a placeholder nevét. A Context-Aware AI, amely egységként olvassa az egész stringet, token zárolással kombinálva, sértetlenül tartja mind a jelölést, mind a :url szerződést, miközben csak az emberi olvasásra szánt „documentation” szöveget fordítja le.
Az exportálási, fordítási, újraimportálási ciklus
Az ismételhető munkafolyamatnak három szakasza van, és a drush szkriptelhetővé teszi az exportálást és importálást, így nem kell minden alkalommal végigkattintgatni az admin UI-t.
1. lépés: A PO fájl exportálása
Exportálhatja az UI-ról a /admin/config/regional/translate címen, kiválasztva egy nyelvet és egy exportálási hatókört, vagy megteheti parancssorból. A locale modul a Drupal fordítási szolgáltatásain keresztül teszi lehetővé az exportálást, és a legtöbb csapat szkripteli ezt. Egy tipikus drush hívás a fordítási import elindításához (a fordítottja, amit a harmadik lépésben használunk) így néz ki:
# 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
Az exportálás oldalán az admin export űrlap hozza létre a .po fájlt; sok csapat beépíti a locale export szolgáltatást egy kis egyedi Drush parancsba a teljes automatizálás érdekében. Akárhogyan is, egy standard gettext .po fájlt kap, amely tartalmazza a lefordítatlan msgid bejegyzéseit.
2. lépés: A fájl lefordítása
Ez az a szakasz, ahol az AI órákig tartó kézi szerkesztést vált fel. Töltse fel az exportált .po fájlt egy felhőalapú fordítóba, válassza ki a célnyelvet, és hagyja, hogy feldolgozza. Mivel a nagy Drupal webhelyek .po fájljai rutinszerűen meghaladják a 10 MB-ot, miután a core, contrib és a témák kombinálva vannak, itt a Smart Batching számít: a fájl darabokra van vágva, lefordítva és újra összeállítva anélkül, hogy kézzel felosztaná vagy mérethatárokba ütközne. Az eredmény egy komplett .po fájl, minden msgstr kitöltve és minden @count, %date és :url placeholder pontosan ott, ahol elkezdődött.
3. lépés: Újraimportálás a Drupalba
Importálja vissza a lefordított fájlt a /admin/config/regional/translate címen keresztül vagy a fent bemutatott drush locale:import paranccsal, majd építse újra a gyorsítótárat. A Drupal egyesíti a fordításokat a locale tábláiba, és a stringek azonnal megjelennek a webhelyen. Futtassa újra a ciklust, amikor modult ad hozzá vagy frissíti a core-t, mivel mindegyik új, lefordítatlan stringeket hoz magával.
Egy importálási részlet, amit helyesen kell beállítani: a --override flag szabályozza, hogy a beérkező fordítások felülírják-e a meglévőket. Használja a --override=all beállítást, ha azt szeretné, hogy az AI által lefordított fájl legyen az irányadó, vagy egy konzervatívabb beállítást, ha kézzel finomhangolt bizonyos stringeket a Drupal UI-ban, amelyeket nem szeretne felülírni. A legtöbb automatizált folyamat esetében a .po fájl igazságforrásként való kezelése és mindent felülírása kiszámíthatóvá teszi a rendszert: a verziókezelésben lévő fájl az, amit a webhely mutat, pont.
Több célnyelvvel rendelkező többnyelvű webhelyek esetében a ciklus nyelvenként egyszer fut. Exportálja a lefordítatlan halmazt, fordítsa le németre, importálja; exportálja újra, fordítsa le spanyolra, importálja; és így tovább. Mivel minden nyelv egy független .po fájl, párhuzamosan futtathatja őket, és egy felhőalapú fordító, amely egyszerre dolgozza fel őket, a korábbi egyhetes vállalkozói munkát egy délutáni feladattá alakítja.
A Drupal PO egy a több formátum közül
Érdemes megjegyezni, hogy a gettext .po nem az egyetlen módja annak, ahogyan a Drupal kezeli a fordítást. A konfigurációs és tartalom entitások XLIFF formátumban is cserélhetők, ami az a szabvány, amelyre a Translation Management Tool (TMGMT) modul támaszkodik a professzionális fordítói munkafolyamatokhoz. Ha a Drupal lokalizációja XLIFF-en keresztül fut, nem pedig interfész .po fájlokon keresztül, a placeholder-megőrzési elvek azonosak, de a fájlstruktúra eltér, és ezt az utat tárgyaljuk a XLIFF fájlok fordítása Drupal, Symfony és Angular számára című cikkben.
Az interfész fordítási réteg esetében azonban a .po marad a „munkásló”. Az exportálás, AI-fordítás, újraimportálás ciklus egy többnapos kézi munkát néhány perces feldolgozássá alakít, és amíg az Ön által használt eszköz valóban megérti a gettext placeholder-eket, az @variable szerződései sértetlenek maradnak, és a Drupal webhelye minden szállított nyelven sértetlen marad.
Készen áll a Drupal
.pofájljainak lefordítására anélkül, hogy egyetlen@variable-t is megtörne? Próbálja ki ingyen a SimplePoTranslate-et — nincs szükség hitelkártyára. Az ingyenes szint kezeli a standard gettext.poés.potfájlokat teljes Syntax Locking-gal, így a Drupal placeholder-ei pontosan úgy haladnak át, ahogy a kód elvárja.