Tegyük fel, hogy minden adott a lehető legjobb szoftver-lokalizációs projekthez: nyitott, segítőkész fejlesztő csapat, egy modern fordítástámogató eszköz, pénz, paripa, fegyver, a királylány keze, no meg egy aranyhal. Hogyan fognál hozzá?

Nemrég egy ismerősömmel ebédeltem, aki a csapatával most vágott bele az általuk fejlesztett-forgalmazott szoftver fordításába. Mivel már néhány év eltelt, mióta legutóbb ilyen helyzetre folyamatot és fordítási környezetet hoztam létre, felidéztem korábbi élményeimet és azok tanulságait a témában. És ha már így alakult, megírtam.

Terminológiát mindenek előtt! – időben és prioritásban is

Most már egészen biztos, hogy nem múlt el nyomtalanul az elmúlt bő évtized, amit fordítóirodák környezetében töltöttem. Így adódhatott, hogy már-már zsigeri válaszként tört fel bennem, hogy először is legyen terminológia. Nem amolyan, majd-fordítás-közben-töltögetjük-a-TB-t-alibiből típusú, hanem előre összerakott, átgondolt, minden résztvevő által elfogadott fajta. Hogy a fordítás közben bővíteni, módosítani érdemes, azt talán mondanom sem kell.

Sőt, nyilván az lenne a terminológiák csúcsa, ha már a technikai szövegíróknak is rendelkezésére állna legalább a forrásnyelven. Mégiscsak hasznos, ha a témaspecifikus kifejezések, szavak egységesen vannak kezelve, és nem egy help vagy manual írásakor próbálja kiélni kreatív énjét egy író, és viszi a susnyásba az olvasót a rengeteg szinonima alkalmazásával.

Alaposan felkészült nyelvi szakemberek

Talán még a 2016-os memoQfesten mesélt Oleksandr Pysaryuk arról, hogyan készítette és építette fel fordítói csapatát a szoftverük lokalizálására. Egy kulcsfontosságú eleme volt a felkészítésnek, hogy a fordítók és lektorok a kiválasztást követően egy néhány napos tréningen vesznek részt, aminek kereteiben alaposan megismerik a fordítandó szoftvert. A tréning végén pedig egy teszten kell bizonyítaniuk, hogy valóban elsajátították a szoftver használatát, és csak azt követően kezdhetnek a fordításon is dolgozni. (A felkészüléssel töltött időre pedig napi díjat kapnak – a teszt eredményétől függetlenül. Erre hagyok időt…)

Annyira tetszett az ötlet, hogy azóta többször megpróbáltam én is eladni, de nem kerültem még olyan helyzetbe, hogy egyszere legyen jelen az érdeklődés, a megfelelő anyagi és időbeli keret. Hátha legközelebb.

Mindenki mumusa, az a bizonyos „nyelvi fájl”

A fejlesztők izgulnak, mert nem a mindennapi munkafolyamatuk része, no meg ki tudja, milyen állapotban érkezik majd vissza az az export, működni fog-e utána a program. Egy egységsugarú fordítóiroda projektmenedzsere pedig instant frászt kap, ha po, json vagy hovatovább többnyelvű xml-re kér valaki ajánlatot.

Igazából a fejlesztési környezetből érkező „nyelvi fájlokkal” nem a kiterjesztésük a legnagyobb gond. Elismerem, rémisztően hathat egy-egy ilyen egzotikus fájlformátum a docx-ek és pdf-ek által uralt környezetben, de inkább örüljünk, ha ilyesmit kapunk a Word-fájlba erőszakolt programkódok vagy Excelbe faragott komplett honlapok helyett. Illetve nem túlzok, amikor azt állítom, hogy egy közepesen tehetséges junior lokalizációs mérnök – vagy az már inkább technikus, esetleg mérnök inas? – néhány perc körbeszaglászás, egy kávé és 5 perc guglizás után is képes akár csonk nélkül beimádkozni ezeket a fájlokat is tetszőleges CAT toolba. Még ha kézzel is ír hozzá RegEx-szűrőt.

Ami nagyobb baj, hogy ezek a fájlok végtelen nyelven képesek hordozni a fordításokat, de a fordítók munkáját segítő plusz infókat csak a legritkább esetben tartalmaznak. Néha látni KEY, ID vagy számunkra hasonlóan semmitmondó nevű mezőket a forrásnyelvi szövegen túl, de mennyire menő lenne, ha egy szegmens körül megjelenne például, hogy melyik funkcióhoz, modulhoz, felülethez tartozik, milyen kontextusban fordul elő?!

Vessünk csak egy pillantást a többnyelvű fájltípusok szűrőire memoQ-ban, mi mindent képesek kezelni:

Kontextus, komment, karakterkorlát és még mennyi minden?! Tehát a lehetőség adott, csak nem élünk vele (általában). A szoftverfejlesztő nem fogja tudni, hogy ennyi minden kezelésére képesek a modern fordítástámogató eszközök. Honnan is tudhatná?! Ő örül, hogy talált valamilyen export formátumot, amire a fordító(iroda) is rábólint. Kommunikáljunk hát, Béláim!

Ha megvan a kontextus, a komment, a karakterkorlát és még a két nap tréninget sem sajnáltuk, akkor már csak el kell képzelnie a fordítónak, hogy milyen felületen is fog megjelenni végül a célnyelvi szöveg…

Előnézet – köznyelven: preview

Valószínűleg én is erős vakarózásba kezdenék, ha a fenti fájlformátumok vonatkozásában kellene valamilyen élő(szerű) előnézetet varázsolnom egy CAT toolban, de a HTML és PDF preview-k korszakát éljük, és ne felejtsük el, hogy épp szoftverfejlesztő csapattal dolgozunk együtt, akikkel közös érdekünk, hogy bitang jó legyen a fordítás.

Csak hogy valamilyen konkrét megoldást is adjak: a fapados verzió az, ha legalább kép, PDF formájában látja az aktuálisan megdolgozott szoftverrészletet a nyelvi szakember a forrásnyelven. (Tréningekhez, útmutatókhoz, helpekhez ezek egyébként is rendelkezésre állnak – jobb esetben.)

QA – avagy az automatizált minőség-ellenőrzés

A terminusok helyes használata, tag-ek babusgatása, karakterkorlát, véletlenül duplán leütött szóközök, ezekre mind képes figyelmeztetni bennünket a QA – ha hagyjuk neki. Fájdalmasan sokszor láttam már alapértelmezetten értékeken hagyott QA-t fordítási projektekben, a forrásfájl formátumától függetlenül. Kár kihagyni egy ilyen ziccert.

Vizuális ellenőrzés

Ezt a lépést a DTP-s munkák világából hozom, ahol „annyira közelről” nézi a szerkesztést végző a dokumentumot, hogy olyan alap dolgok nem fognak feltűnni neki idővel, mint az oldalszámozás hiánya a páros oldalakon.

Itt annyival komplikáltabb a helyzet, hogy esetleg egy mondat fordítása három-négy-öt szegmensbe kerül, és lesz benne mondjuk 6–8 tag is, amivel együtt fordítási környezetben nézve senki sem fogja tudni megjósolni, hogyan is fest majd a végeredmény a felületen, ahova szánták. Erre lehetne használni a szoftverfejlesztők egyik teszt környezetét/rendszerét, ahol új funkciókat, modulokat szokták próbálgatni. Akkor már igazán lehetne célnyelvi teszt is, ahol a szakavatott szem rögtön kiszúrja a rosszul tört mondatot vagy a szóközzé vált tagek helyét, egy-egy kimaradt félkövérítést. Nagyon gyors folyamat az ilyen ellenőrzés, és elképesztő hibákat lehet kiszűrni, amit már csak a végfelhasználó látott volna és nem kitörő örömmel.

Felhasználói visszajelzések kezelése

Egy magára valamit adó, nemzetközi babérokra áhítozó szoftverfejlesztő cégnek kiemelt figyelmet kell szentelnie az ún. ügyfélélményre a bankkártyaadatok bekérését követően is, szerintem. És ennek bizony része, sőt a (fordítási) minőségbiztosítás fontos eleme is, hogy lehetőséget biztosít arra, hogy a felhasználók az esetleges fordítási tévesztéseket, elütéseket jelezni tudják. És az sem árt, ha a jelzés jogosságának ellenőrzésére egy átgondolt folyamat áll rendelkezésre, amiben legalább egy pontot helyet kap egy nyelvész is. No meg aztán a döntésről kommunikálni is illik később a júzer felé.

Illetve ott van még az implementálás kérdésköre is, hogy csak a szoftverben történik-e meg, mikor, hogyan, vagy érdemes a fordítási memóriákat, terminológiát is frissíteni.

Felhasználói leírások, helpek és egyéb anyagok

Nem tartozik szorosan a tárgyhoz, de a teljes képhez hozzá tartoznak ezek, az addicionális dokumentumok is. Tudom, a minden anyag minden nyelvre fordítása úri huncutságnak számít, és nem is feltétlen kifizetődő, de nem biztos, hogy hosszasan fenntartható állapot és remény, hogy a support úgyis olyan jól ismeri a terméket, hogy bármilyen nyelvű is a képernyőkép, arról meg tudja állapítani, hogy mi a gond, amiről a ticket szól. Ezt saját tapasztalataim alapján is meg tudom erősíteni: hiába töltöttem az elmúlt évtizedben több időt a memoQ-kal, mint bármely más kapcsolatom ápolásával, a világból ki lehet kergetni egy jó kis német screenshottal – hiába tudom még ma is elmondani németül, hogy hol lakom és nincs kész a házi feladatom.

Ez idő szerint a fentieknél jobb, ügyesebb kereteket nem tudnék teremteni egy lokalizációs projekthez. Ha a Kedves Olvasó igen, ne rejtse véka alá, örömmel meghallgatok minden jobbítási ötletet. Ha pedig valamely lépés implementálásával akadnának gondok, tudod, hol találsz. 😉