Novemberi beszámoló

Zolnai Tamás, 2012. december 4.

    Elérkezett a november vége, és ezzel együtt a hónapok óta végzett munkám ezen szakasza is a végéhez közeleg. Ebben a hónapban került be ugyanis a központi ágba a lokalizációs projektem eredménye, és most derült ki igazán, mennyire felel meg a vele szemben támasztott elvárásoknak. Azonban még mielőtt belemerülnék a felmerülő problémák ecsetelésébe, hadd írjam le milyen további tevékenységek előzték meg a végleges megoldást.
    A hónap elején a po fájlokon alapuló lokalizáció még nem volt teljes. A grafikus felület döntő része már a megfelelő nyelven jelent meg, azonban a súgó teljes egészében kívül maradt a honosítás hatókörén. A megfelelő program (helpex) már készen állt arra, hogy feldolgozza a súgó xml fájljait, de a hatékonyság érdekében változtatnom kellett rajta. Valójában részben az eredeti megoldáshoz tértem vissza, mivel a legújabb változtatások mintegy melléktermékeként rengeteg felesleges fájlolvasási művelet került bele a feldolgozó algoritmusba.
    Miután sikerült az egész rendszerbe bevezetni a po fájlok használatát, elérkezett az ideje a tesztelésnek. A po fájlok használatának két jól elkülöníthető része van. Egyrészről azokba gyűjtjük ki a lefordítani kívánt szövegeket, másrészről többnyelvű fordítás esetén ezekből nyerjük ki a fordításokat. Ezen két feladatnak megfelelően két fajta teszteléssel éltem.
    Az eredeti szöveg kinyerése eddig közvetett módon történt egy sdf fájl közbeiktatásával. A végeredmény mégis po fájlok gyűjteménye volt, amit az új megoldástól is várunk. Ebben az esetben elég egyszerű dolgunk lenne, hiszen csak a végeredményt kellene összehasonlítani. Azonban a saját po fájl formátumot megvalósító osztályok megírásakor kisebb változtatásokat vezettünk be a régi formátumhoz képest. A régi po fájlok megalkotási módja információveszteséggel járt, így kétséges volt, hogy önmagukban elegendőek a forráskódban található szövegek azonosítására. Továbbá több helyen duplán tárolódtak bizonyos adatok, melyeket mellőztünk az új megoldásban.
    A tesztelés tehát nem csak egyszerű összehasonlításból állt, hanem tartalmazott egyfajta konverziót is a két formátum között. A nagy mennyiségű tesztadatra való tekintettel ezt egy külön programmal valósítottam meg, mellyel sikerült kiszűrni a hibákat. Valójában itt csak néhány elírásra leltem a po fájlok fejlécében. Ez a teszt azonban a későbbiekben még további hasznos segítséget nyújt.
    A tesztelés másik területe a fordítások forrásfájlokba való beírása. Itt sokkal nagyobb volt az egyezés a két végeredmény között, így felhasználhattam a git által nyújtott lehetőségeket. Egy patchbe gyűjtöttem bele az új lokalizáció hozta változásokat. Azonban itt sem volt ilyen egyszerű a dolog. Egyrészről a qtz kód – amiről egyelőre annyit, hogy egy pszeudonyelv, mely a fordítókat segíti – megváltozott, így a hozzá tartozó sorok is változtak. Másrészről a régi és az új lokalizációhoz alapul vett forrásfájlok sem egyeztek meg teljesen, mivel a régi a központi ágban futott, míg az új a fejlesztőiben. Mindenesetre egy újabb program segítségével sikerült megtalálni a tényleges különbségeket. Itt olyan hibákat találtam, hogy az új megoldás nem dolgozta fel a readme-t, mivel annak po fájlja egy könyvtárral feljebb került, nem készült el az összes qtz-hez tartozó forrásfájl, illetve valahol a fájlok feldolgozásának sorrendje nem volt megfelelő. Ezen problémák megoldása nem igazán programozói tudást igényelt, sokkal inkább makefile-ok írásában való jártasságot.
    Ezek a tesztek ugyan nem fedtek fel igazán nagy problémákat, mégis hasznosak voltak, hiszen így bizonyossá vált a megírt algoritmusok helyessége. A további tesztesetek azonban alapvető feltevésbeli hibákat is felszínre hoztak.
   Ahogy már említettem a po fájlok megváltoztak, ez azonban szükségessé tette a régi po fájlok átalakítását új formájukra. Erre is elkészült már a program (renewpo). Készítésekor azonban nem elég megalapozott feltevésekre hagyatkoztam, így működésében alapvető hibák derültek ki a tesztelés során. A renewpo a po->sdf konverziót megvalósító po2lo programot felhasználva a régi típusú po fájlok információit egyetlen nagy sdf fájlba gyűjti össze, majd ez alapján készíti el az új po-kat. Felmerülhet a kérdés, hogy miért nem közvetlenül hajtjuk végre a konverziót. Ennek oka, hogy a régi po->sdf és az sdf->új po konverziók tesztelt és így megbízható forráskódra épülnek, másrészről a régi po-k, ahogy már említettem, nem tartalmaznak minden információt. A po2lo program működésének félreértése vezetett olyan problémához, hogy több po fájlból hiányoztak egyes bejegyzések, illetve a fejlécben található forrásmegjelölés is hibásan lett feltüntetve.
    Végül is eredményesen zárult a tesztelés, így a projekt elkészült időre. A központi ágban azonban további tesztek vártak az új lokalizációra. A LibreOffice saját tesztelő rendszere, a Tinderbox minden nyelvre és több platformra is lefuttatta az új rendszert és napokig adta ki magából a legkülönbözőbb hibaüzeneteket. A legtöbb hiba nem a program helyességével volt kapcsolatos, hanem sokkal inkább platformfüggő megoldások használatával. Ilyen hiba volt például, hogy a renewpo olyan programkönyvtárt használ, mely a Windows alatt nem létezik, továbbá felhasználtam olyan C++ nyújtotta lehetőségeket, melyeket néhány régebbi fordító nem tesz lehetővé, illetve olyan külső programkönyvtárat használtam, mely alap esetben nem felelt meg a LibreOffice által támasztott elvárásoknak.
    Ekkor látszott meg igazán mennyire jól működik a LibreOffice csapata. A hét elején én magam nem nagyon tudtam hibajavítással foglalkozni, de néhány fejlesztő megoldotta a főleg platformfüggetlenséggel kapcsolatos problémákat. A hét közepére magam is csatlakoztam és éppen jó időben, mivel pont egy programhelyességbeli hiba tűnt fel, melyet egy külső programozó jóval nehezebben oldott volna meg.
    Elmulasztottam jobban kifejteni mi is az a qtz nyelv, de ezt most pótolom, annál is inkább mert további teendőim is ezzel kapcsolatosak. Ezt a nyelvet az olvasó által bizonyára ismert Timár András vezette be a LibreOffice-ba, a fordítók munkájának megkönnyítése érdekében. A qtz valójában egy kódot jelent, mellyel meg lehet találni a fordítandó szövegek helyét a programon belül. El lehet készíteni egy qtz nyelvű build-et, ami annyit tesz, hogy a grafikus felület feliratai mellett megjelenik azok kódja, így a fordító jobban be tudja azonosítani a felirat célját és értelmét.
    Ez a qtz nyelv azonban sajátos helyet foglal el a nyelvek között. A kódok hasonlóan kerülnek be a forrásfájlokba, mint a valódi nyelvek fordításai, de a qtz önálló po fájlokkal nem rendelkezik. Maga a qtz kód az adott szöveg bizonyos adatai alapján generálódik le, így bármely nyelv po fájljait alapul véve ugyanazt a kódot kapjuk. Éppen ezt használjuk fel, és a qtz-t egy másik nyelv po fájljaiból nyerjük ki, attól függően, hogy melyik áll rendelkezésre. Ez a sajátos helyzet okozza a problémát, amit még csak részlegesen oldottunk meg. A grafikus felületen igen, de a súgóban és a telepítőben még nem.
    Tehát elkészültek az új po fájlok és a rendszer tudja is kezelni őket. Azonban a po fájlokba kerülő fordítások még hibát okozhatnak a build-elés során. A LibreOffice fordítása döntő részben a Pootle webes felületen keresztül történik, ami rengeteg hibát felfed, de sokszor jó fordításokat is hibásnak jelöl. Éppen ezért a jobb hibajelzés érdekében magam is megírtam egy új tesztet a Pootle által használt Translate Toolkit szoftvercsomagba, melyet el is küldtem patch formájában a fejlesztők számára. A teszt a súgóhoz tartozó fordításokban keresi meg azokat, melyekben valamely xml tag-nek nincs meg a nyitó/záró párja. Ilyen hiba esetén a fordítás nem kerül be a forrásfájlba, mivel az build-elési hibát okozna.
    Összefoglalva: végre sikerült megszabadulni az sdf fájloktól és áttértünk teljes mértékben a po fájlokra. Ugyan még van néhány kisebb fejleszteni való az új rendszeren, mégis úgy tűnik, életképes megoldást hoztunk létre. Így lassan új, ismeretlen területek felé veszem az irányt. Úgy hallom a Base környéke még szinte érintetlen terület.

Címkék: , ,

Itt lehet hozzászólni !