Selle seeria esimeses artiklis tekitas mõningat vastukaja mu väide, et tarkvara eestindamine polegi tõlketöö, vaid arendustöö. Jah, eks ta tegelikult selline piiripealne asi ole, kuid mõned asjaolud kallutavad seda päris kõvasti just arenduse poole. Ma juba rääkisin sellest, et kasutajaliidese tõlkimine on paratamatult ka kasutajaliidese disainimine. Tõlkijale tuleb tohutult kasuks kogemus tarkvara kasutatavuse teemas. Mis on kasutajale mugav ja miks? Mis võib häirida ja miks? Need ei ole keeleküsimused, kuigi keel ühe kasutajaliidese komponendina mõjutab vastuseid nendele küsimustele.
On aga veel mõned asjaolud, mis teevad kasutajaliidese tõlkimisest rohkem arendus- kui tõlketöö. Nendeks on tõlgitud kasutajaliidese staatus ning tarkvara arendamise praktika tänapäeval.
Kui jätta kõrvale “emme, vaata, ma teen arvutiga ise asju!” tõlkijad (keda on ka uskumatult palju), masstööna toimetamata toortõlkeid tegevad bürood jms, teeme me seda tööd ikkagi selle pärast, et tulemust kasutataks. Et inimesed eestikeelset kasutajaliidest kasutaks, peab see olema parem kui originaal. Jah, just nimelt. Olgem ausad, mitte ükski ingliskeelse liidese kasutaja ei hakka keelt vahetama, kui inglise keeles on midagi arusaamatut, lihtsalt bugist, võib olla ka häirivat jms. Eesti keele puhul käib see liigutus väga kähku ära. Selleks, et tõlgitud kasutajaliides saaks olla parem kui originaal, peab tõlkija tõepoolest hästi tõlgitavat rakendust teadma. Iga stringi kohta peab sul olema täiesti selge pilt mida see tähendab, kus ja mis olukorras ta liideses esineb jms. Kogemus näitab, et selleks ei piisa ei lihtsalt tekstist, rakenduse dokumentatsioonist ega ka rakenduse kasutamise võimalusest. Ning me jõuame teise teemani …
Tarkvara arendamine tänapäeval tähendab eelkõige kiirust. Kiirus tähendab keskendumist olulisimale ning selle kiireimale realiseerimisele. Ei kuulu nende olulisimate asjade hulka ei 700 000 valdajaga keel, ega ka tõlkimine üleüldiselt. See tähendab seda, et üks tõlkija peab käepäraste vahenditega vaatama ise kuidas ta hakkama saab. Arendaja on selle peale mõeldud minimaalselt ning sinu kontekstiinfoga varustamine on tema prioriteetide tabelis kuskil seal, kuhu tegelikult kunagi ei jõuta. Sa pead üldjuhul ise vaeva nägema ning see tähendab tihti lähtekoodi lugemist (kui lähtekood on olemas), Internetist standardite otsimist, nende tõlgendamist jpm sellist. Sealjuures pole haruldane leida, et tegelikult on juba ingliskeelne tekst jama.
Kui veab, vastab arendaja su küsimustele (kui neid pole palju ja ta isegi vastuseid teab), kuid tõlkija ettepanekutele reageeriv arendaja on pigem haruldus või on ta lihtsalt õnnelik, et keegi üldse ta tarkvara kasutab. Ettepanekud aga tulevad paratamatult. Ma ei ole näinud veel ühtegi vähegi suuremat tarkvara projekti, mille kood ei vajaks parandusi, et see üldse mõistlikult eesti keelde tõlgitav oleks. Me oleme isegi oma keelega heas olukorras. Meil on mure peamiselt oma käänetega ja need probleemid on üldjuhul arendajatele selgeks tehtavad (kui tal vähegi on aimu muudest keeltest peale inglise). Kuid me võime ainult rõõmsad olla, et meil pole nt inglise keele oskajale täiesti arusaamatut jama mitmuse vormidega. Et need parandused ka tehtud saaks, peab tõlkija tegema arendaja elu maksimaalselt lihtsaks ning avatud tarkvara puhul tähendab see ise paranduste tegemist. Jah, see tähendab koodi kirjutamist. Suletud tarkvara puhul seda luksust muidugi pole, kuid ka sel juhul on arenduse kogemus suur pluss – sa oskad seletada mida, miks ja kuidas täpselt teha tuleb.
Lõpuks tuleb arvestada ka sellega, et arenduse kiirus tähendab muuhulgas ka seda, et uued versioonid tarkvarast ilmuvad kiiresti. Vähe on selliseid rakendusi, mille võib pärast tõlke valmimist ka unustada. Palju tavalisem on see, et juba paari kuu pärast on tõlge poolik ja näeb välja sama sitt kui … sitt tõlge. Kui tahta, et hea tõlge ka heaks tõlkeks jääks, peab tõlkija arendusega kaasas käima.