Ako prekladať Joomlu a spol

Ako píšem inde, už dávnejšie udržiavam si vlastný preklad redakčného systému Joomla!, ktorý som nedávno predhodil verejnosti. Vždy pri preklade však myslím na to, aká je škoda, že Joomla! nepoužíva systém gettext, ale tie svoje súbory INI. Tak som sa to rozhodol zmeniť.

Teda, aby som bol úplne presný, nemením spôsob akým je Joomla! lokalizovaná. Len mením spôsob akým spravujem preklady. Pri údržbe súborov INI som narážal na niekoľko problémov. Asi za najväčší z nich považujem to, že nie je jednoduché zistiť, čo sa pri vydaní novej verzie zmenilo. Medzi ďalšie z nich patrí, že je problematické udržiavať konzistentný (napr. pomenovávať veci rovnako) preklad v takom množstve súborov (v základnej inštalácii ich je viac ako 130).

Úvodné reči

Predstavenie systému gettext

Systém gettext je poskytuje balík nástrojov, ktoré sú určené na internacionalizáciu (pripravenosť programu pre prácu v rôznych národných prostrediach) a lokalizáciu (schopnosť pracovať v národnom prostredí) programov. Je to štandardný intenacionalizačný a lokalizačný nástroj väčšiny GNU programov. Tieto vlastnosti však v Joomle nevyužijem, čo však využijem, je jeho formát súborov s prekladom, označovaných ako súbory PO (Portable Object) a POT (PO Template). Súbory PO obsahujú katalógy správ, a to v originálnom i cieľovom jazyku, a súbory POT zase slúžia na distribúciu aktuálneho stavu textových reťazcov v programe. Oba súbory majú v podstate rovnaký formát, len súbor POT neobsahuje preložené reťazce.

Za najväčšiu výhodu pri použití tohoto formátu, oproti formátu INI v Joomle, považujem fakt, že poskytujú prekladateľom jednoduchý spôsob aktualizácie, ktorý je založený na automatickom zlúčení existujúcich prekladov s novými. Po takomto zlúčení sú zachované preklady reťazcov, ktorých originál sa nezmenil, bez zmeny. V prípade zmeny pôvodného reťazca, je tento buď pridaný ako nepreložený, alebo (ak sa to podarí) je do zmeneného reťazca pridaný pôvodný preklad a preklad je označený ako nepresný. Reťazce, ktoré sa v novej verzii nevyskytujú, sú označené za zastarané.

Pre správu prekladov vo formáte PO existuje viacero programov, za všetky spomeniem POEdit, Lokalize, či GTranslator, alebo ktorýkoľvek obyčajný textový editor.

Ako je to v Joomle?

Súbory pre preklad Joomly majú príponu INI, ale nepoužívajú žiadne sekcie. Sú to vlastne prosté súbory vo formáte:

IDENTIFIKÁTOR=reťazec

Každý komponent, modul, či zásuvný modul má svoj vlastný súbor s textovými reťazcami, čoho výsledkom je kvantum súborov v adresároch /language/jazyk (pre stránku) a /administrator/language/jazyk (pre administráciu). Tento model adresárov rešpektujú aj všetky dobre napísané rozšírenia. Ak autori Joomly (alebo rozšírenia) v novej verzii zmenia textové reťazce, táto zmena sa prejaví (väčšinou) v príslušnom súbore INI, a to tak, že starý reťazec zmizne a nahradí ho nový. Aby som to ako prekladateľ postrehol musím si udržiavať dve verzie súborov INI a potom pátrať po rozdieloch, čo nemusí byť vždy jednoduché, aj vzhľadom na počet lokalizačných súborov. A o prechode na verziu 1.6 ani nehovorím...

Ako ďalší problém tohoto riešenia vnímam, že často prekladám rovnaké reťazce na viacerých miestach (čo v mojom prípade vedie k tomu, že ich málokedy preložím celkom rovnako), a tak mám prácu často zdvojenú. Avšak pravdou je aj to, že takto možno rovnaký anglický text preložiť inak, podľa aktuálneho  kontextu.

Vlastne hneď od začiatku som si pripravil niekoľko skriptov v BASHi, pomocou ktorých som ako-tak sledoval zmeny v týchto súboroch. Avšak vzhľadom ku komplexnosti úlohy, uspokojil som sa so sledovaním toho, či nejaký reťazce pribudol alebo ubudol, nie už to, či sa nejaký text zmenil. Tento môj systém môže viesť (a vedie) k tomu, že sa preklady pomaly a isto od originálov odlišujú.

Hľadanie riešenia

So spomínaným riešením v BASHi som spokojný nebol, preto som hľadal riešenie, ktoré by mi umožnilo efektívnu správu prekladu s ohľadom najmä na:

• sledovanie zmien,
• aktualizáciu prekladov,
• konzistenciu prekladov.

Ako už asi tušíte, moje úvahy sa začali uberať smerom k formátu gettext. Jeho vlastnosti umožňujú splniť moje požiadavky, možno s jedinou výnimkou, a to nemožnosť spravovať rôzne preklady rovnakého originálu. Ostáva už len drobnosť, a to ako dostať súbory INI do súboru PO(T) a hlavne aj späť!

Moje prvé pokusy sa obrátili smerom k sade nástrojov translate-toolkit, ktoráp oskytuje veľa nástrojov na konverziu rôznych lokalizačných formátov do formátu PO a späť. Ako prvý ma zaujal program ini2po, ale skončil som skôr ako som začal, pretože mi zahlásil chybu, že súbor INI nemá žiadnu sekciu a nenašiel som voľbu, ktorou umožniť spracovanie súboru INI bez sekcií. Ale táto sada nástrojov mi vnukla nápad, napísať si vlastný konvertor INI -> PO a späť.

V podstate som mal dve cesty:

• spojiť všetky súbory INI do jedného, pričom použiť meno súboru ako názov sekcie, alebo
• priamo konvertovať súbory INI do súboru PO.

Keďže ma prvá možnosť napadla priamo pri písaní tohoto článku, svoje riešenie som založil na druhej možnosti.

Výsledok

Výsledkom mojej snahy je modul v jazyku Python, ktorý dokáže konvertovať adresár so súbormi INI do formátu PO (presnejšie POT) a samozrejme, dokáže zo súboru PO vygenerovať naspäť adresár s preloženými súbormi INI. Uvedený modul som sa rozhodol zverejniť pod licenciou GPL-2, takže ho môžete slobodne používať. V časti na stiahnutie sú k dispozícii i dva ukážkové skripty, ktoré majú slúžiť ako príklad na konverziu jedným i druhým smerom. A to nie len na základnú súbory Joomla, ale vlastne na akýkoľvek adresár, do ktorého umiestnite príslušné lokalizačné súbory.

Pokusný preklad Joomla! 1.6 hlási kopu chýb, kvôli zmenenému formátu komentárov v lokalizačných súboroch, ktorý nezvláda ConfiObj, ale funguje...

Uvedený modul i príklady by mali byť platformovo nezávislý a pre svoju funkčnosť vyžaduje moduly ConfigObj a polib, ale keďže nemám k dispozícii Windows s Pythonom, tak som všetko skúšal iba na Linuxe...