k:blog

egy héten belül megjelenik a suse linux 10.1. pontosabban május 11-én. jelenleg rc4 állapotban van, de a kód már nem nagyon fog változni, csak indokolt esetben. ilyenkor például már lokalizációs változásokat nem fogadnak be, ezért bevallom már az rc3-at sem néztem át kellő alapossággal, hiszen az rc2 óta nem frissülnek pl. a yast javításaim sem.

most a teljes figyelem az sled/sles páros fele fordul. illetve igazából a sled fele, mert nem tartom valószínűleg, hogy valaki egy enterprise servert lokalizálva kívánna használni… jelenleg ez nem túl életszerű. ennek ellenére a fordítások elkészültek és már a kódban vannak.

sokszor beszéltem már a lokalizációról, de ha jól emlékszem a teljes folyamatot sosem mondtam el és most, hogy egy release után vagyunk ismét, talán érdemes számot vetni a dolgok mikéntjéről.

hát akkor jöjjön a pőre igazság. a linux megjelenések a novellnél hivatalosan a következő nyelveken jelennek meg: angol, német, spanyol, olasz, portugál és francia. ezek a hivatalosan támogatott nyelvek. ez azt jelenti, hogy ezek lokalizációját a novell központilag végzi. vagyis elküldi egy fordító irodának, akik a po állományokat szépen lefordítják.

ezt követően léteznek a külsősök által támogatott nyelvek. ezeket nincs értelme felsorolni, mert rengetege ilyen van. ezeket hobbiból, elhivatottságból külsős emberek, úgynevezett volunteerek végzik.

a lokalizáció során több fordítási kör (round) van, amikor is egy rövid határidőn belül, ami rendszerint a 3 nap és a 2 hét időintervallum közé esik lehetőség van fordításokat beküldeni, amit a subversionbe téve az autobuild mechanizmuson keresztül a termékbe kerül. ebben az időszakban rengeteg fordítani való keletkezik, ráadásul ennek eredményét, nem a következő, hanem az azutáni buildben lehet látni csak, amikor is már egy másik fordítási körön kell dolgozni. ez fajta eltolás nagyon rossz, ugyanis ha egy buildben hibát találsz, akkor először meg kell nézni, hogy az általad egyszer már beküldött (célszerűen az előző) fordítások között nincs-e már javítva, különben feleslegesen jelented be a bugot…

a fordítási ciklusoknál az történik, hogy a subversionben lévő állományokat kiteszik egy nyilvános ftp szerverre a fordítóknak, hogy abból dolgozzanak, és addig a fejlesztők a subverionbe nem commitolhatnak, hogy ne legyen elcsúszás a verziók között. ezért is olyan rövidek a fordítási körök.

nekem ez a fajta munkatempó nagyon nem jött be, egyszerűen sokkal több visszajelzést és javítási lehetőséget szerettem volna, hogy azonnal reagálni tudjak. ezért is szereztem be egy subversion elérést, amit azért kaphattam, mert a novellnél dolgozom. a többi külsős fordítónak erre sajnos esélye nincs (bár karllal beszélgetve a következő vagy az azt követő verziónál teljesen másképp lesz).

ezért reggelente azzal kezdek, hogy megnézem van-e változás a subversionben, és azt áttöltöm a saját cvsünkbe. erre rázúdul a kbabel és megmutatja, hol mennyit kell fordítani. átnézem a teljes lefordítandó részt és amit kapásból tudok azt le is fordítom. amennyiben a fordítás egésze nem sok, vagyis egy óra alatt elvégezhető, akkor azt elkészítem, ha erre nincs lehetőség, akkor elküldöm shirokumának fordításra. ezt követően visszaküldöm a fordítást e-mailen dublinba és düsseldorfba antjenak és karlnak, akik remélhetően hamar commitolják, ami nem mindig történik meg aznap, de többnyire.

visszaküldés előtt azonban még egyszer belenézek a subversionbe, hogy ami fordításra került az időközben nem változott-e újra. amennyiben igen, akkor átvezetem a változást, amennyiben nem, akkor mehet a commit. miután commitálták az állományokat akkor újra belenézek a subversionbe, hogy összehasonlítsam a mi cvsünkben és a kinti subversionben lévő állományt, és ha a kettő egyezik, akkor van részemről rendben a commit. a kód beta1 és rc2 közötti stádiumában ezt minden nap meg kell tenni, így kerül a leggyorsabban a fordítás a kódba és így lehet gyorsan javítani a hibát.

mondok egy példát. van egy gnome applet a tálcán, amely arra hivatott, hogy be lehessen állítani a képernyő felbontást, frekvenciát, színmélységet, illetve előre beállított értéket (ez hívja meg egyébként a sax2-t). ez soha nem volt lokalizálva, semmilyen nyelvre. küldtem egy bugreportot és a fejlesztő pedig beletette a kódba a lehetőséget és megérkezett a po állomány. de nem tudtuk, hogy melyik ez, és az üzenetek hol jelennek meg, ezért mikor azt kellett lefordítani, hogy displays settings, akkor az ember rávágta, hogy az adatok megjelenítése, pedig ez nem más, mint a képernyő beállítása. ez viszont csak akkor derül ki, amikor a build elkészül. ezért van szükség sokkal több fordítási ciklusra.

természetesen a fordítások alkalmával mindig találkozom furcsaságokkal, ilyenkor azoknak utána kell járni, esetleg végig verni a rendszeren, hogy mindenhol azonos elnevezés kerüljön felhasználásra, azonban ez nem mindig egyszerű feladat. gyakran érzem szélmalomharcnak az egészet.

ezzel a módszerrel azonban nagyfokú lokalizáltságot lehet elérni. sokkal jobbat, mint a hivatalosan támogatott nyelveknél. érdekes nem? szinte hihetetlen, pedig így van. belenézve a teljes lokalizációs adatbázisba a magyar és a cseh nyelv a két 100%-osan lokalizált nyelv. a cseheknek egyébként nem olyan nehéz, hiszen a suse egyik fejlesztő központja prágában van, és egy fordítani való állomány megjelenésével egy időben commitálják a fejlesztők a cseh fordítást is… (hát igen, ez nem túl fair :), azonban stanislavval olyan jó kapcsolat alakult ki, hogy nekem commitálással egy időben e-mailben elküldi a fordítani valót, mert tudja, hogy én is a 101%-ra hajtok.

a hivatalos nyelvekre történő lokalizáció rendkívül nehézkes. ha egy fejlesztő a határidő után talál meg még valamit, akkor ezekre ők már nem tudnak reagálni, mert az ütemtervet tartani kell. azonban a teljesen partizánelven működő lokalizációk, mint a cseh és a magyar hihetetlenül jól tud ezekre reagálni, mi több már ezt el is várják.

hogy mikor lesz 100% minden? nem lesz ilyen. mindig lehet benne találni reszelni valót, de talán az a fontos, hogy mindig is reszelni fogjuk és mindig jobb lesz…