Kodėl atviri duomenys ir vertimas – tai ne taip paprasta, kaip atrodo
Jei kada nors bandei dirbti su atvirais duomenimis – tarkime, parsisiuntei kažkokį CSV failą iš Europos Sąjungos duomenų portalo arba radai įdomų tyrimą iš Brazilijos ar Japonijos – greičiausiai susidūrei su ta pačia problema. Duomenys yra, jie laisvi, juos galima naudoti, bet… jie ne ta kalba. Arba aprašymai ne ta kalba. Arba metodologijos dokumentas, kuris paaiškintų, ką tie stulpeliai iš tikrųjų reiškia – irgi ne ta kalba.
Ir čia daugelis žmonių tiesiog sustoja. Arba bando kažkaip susidoroti su Google Translate, įklijuodami tekstą gabalais, prarasdami kontekstą ir galiausiai gaudami vertimą, kuris techniškai teisingas, bet praktiškai nenaudingas.
Aš pats ilgą laiką dariau lygiai taip pat. Kol nesupratau, kad darbas su automatiniais vertėjais – tai įgūdis, kurį reikia išmokti. Tai nėra tiesiog „įklijuoji tekstą, gauni vertimą”. Yra tam tikra logika, tam tikri metodai, kurie padaro šį procesą daug efektyvesnį. Ir apie tai šiame straipsnyje ir kalbėsiu.
Kokie vertėjai iš tikrųjų verti dėmesio
Pradėkime nuo pagrindų – nuo pačių įrankių. Rinkoje jų yra nemažai, bet ne visi vienodai tinkami darbui su atvirų duomenų kontekstu.
DeepL – šiuo metu tikriausiai geriausias pasirinkimas, jei kalba eina apie europietiškas kalbas. Jis ypač gerai susidoroja su techniniais tekstais, išlaiko struktūrą ir kontekstą geriau nei konkurentai. Nemokama versija leidžia versti iki 500 000 simbolių per mėnesį, o tai daugumai žmonių, dirbančių su atvirais duomenimis, turėtų pakakti. Mokama versija – DeepL Pro – prideda API prieigą, kuri labai praverčia, jei nori automatizuoti procesus.
Google Translate – vis dar naudingas, ypač kai reikia greitai suprasti, apie ką apskritai yra tekstas. Jo stiprybė – milžiniškas kalbų skaičius. Jei dirbi su azijietiškomis kalbomis arba mažiau paplitusiomis kalbomis, Google Translate dažnai yra vienintelis realus pasirinkimas. Tačiau techninių terminų vertimas čia silpnesnis.
Microsoft Translator – nepakankamai įvertintas įrankis. Jis turi gerą API, integruojasi su daugeliu Microsoft produktų ir gana gerai veikia su dokumentais. Jei jau naudoji Microsoft ekosistemą – verta išbandyti.
LibreTranslate – atvirojo kodo alternatyva, kurią gali paleisti savo serveryje. Tai ypač svarbu, jei dirbi su jautriais duomenimis arba organizacija turi griežtus duomenų privatumo reikalavimus. Kokybė prastesnė nei DeepL, bet tai kaina už privatumą ir kontrolę.
Praktinis patarimas: nenaudok tik vieno vertėjo. Kai susiduriu su svarbiu tekstu, kurį reikia suprasti tiksliai, visada patikrinu bent dviem vertėjais. Skirtingi įrankiai daro skirtingas klaidas, ir tai, ką vienas supainioja, kitas dažnai supranta teisingai.
Atvirų duomenų tipai ir kaip prie jų prieiti
Prieš kalbant apie vertimo strategijas, verta suprasti, su kokiais tekstais apskritai tenka dirbti. Atviri duomenys – tai ne tik lentelės su skaičiais. Tai visas ekosistema, kurioje yra labai skirtingo tipo turinys.
Pirmiausia – metaduomenys. Tai aprašymai, kurie paaiškina, kas yra duomenų rinkinyje. Paprastai jie trumpi, bet labai svarbūs – jei neteisingai suprasi metaduomenis, visi tavo tolimesni darbai bus paremti klaidingu supratimu. Čia vertimas turi būti tikslus.
Antra – metodologiniai dokumentai. Kaip buvo renkami duomenys? Kokie buvo kriterijai? Kokios išimtys? Šie dokumentai dažnai būna ilgi ir pilni specifinės terminijos. Čia automatinis vertimas gali padėti suprasti bendrą vaizdą, bet detalėms reikia papildomo dėmesio.
Trečia – licencijų tekstai. Tai galbūt svarbiausia kategorija, kurią žmonės dažniausiai ignoruoja. Prieš naudodamas atvirų duomenų rinkinį, turi suprasti, kokiomis sąlygomis jis prieinamas. Creative Commons licencijos yra standartizuotos ir jų vertimai dažniausiai patikimi, bet kai kurios organizacijos naudoja savo licencijas, ir čia reikia būti ypač atidžiam.
Ketvirta – stulpelių pavadinimai ir kategorijų aprašymai pačiuose duomenyse. Tai gali skambėti trivialiai, bet kai turi CSV failą su 50 stulpelių, kurių pavadinimai yra sutrumpinimai originalia kalba – tai rimta problema.
Geri šaltiniai, kur rasti atvirų duomenų:
- data.europa.eu – Europos Sąjungos oficialus atviras duomenų portalas, turintis dešimtis tūkstančių rinkinių
- data.gov – JAV federalinių duomenų portalas
- ourworldindata.org – puikus šaltinis globalių duomenų, dažnai jau su gerais aprašymais anglų kalba
- Wikidata – struktūrizuotų atvirų duomenų bazė, kurioje daug kas jau versta į daugelį kalbų
- Lietuvos atvirų duomenų portalas (data.gov.lt) – jei dirbi su lietuviškais duomenimis ir reikia versti į kitas kalbas
Kaip paruošti tekstą vertimui – tai tikrai svarbu
Čia yra vienas iš labiausiai neįvertintų aspektų. Daugelis žmonių tiesiog paima tekstą ir meta jį į vertėją. Ir tada stebisi, kodėl rezultatas toks prastas. Bet tekstų paruošimas vertimui – tai atskiras įgūdis, kuris gali dramatiškai pagerinti rezultatus.
Pirma taisyklė: vienetas turi prasmę. Neversk po vieną sakinį, jei jie yra kontekstualiai susiję. Bet taip pat neversk per didelių gabalų vienu metu – vertėjai praranda kontekstą ilguose tekstuose. Optimalus gabalas – vienas paragrafas arba kelios susijusios pastraipos.
Antra taisyklė: išvalyk tekstą prieš vertimą. Jei verčiami duomenys iš PDF ar kito formato, dažnai atsiranda šiukšlių – puslapio numeriai, antraštės, kurios kartojasi, keisti simboliai. Visa tai gadina vertimą. Prieš versdamas, išvalyk tekstą.
Trečia taisyklė: atskir skaičius ir kodus nuo teksto. Jei tavo tekste yra kodai, identifikatoriai ar skaičiai, kurie neturėtų būti verčiami – pažymėk juos arba laikinai pakeisk neutraliais žymekliais. Pavyzdžiui, jei turi kodą „LT-KAU-2023-001”, vertėjas gali bandyti „išversti” „KAU” kaip kažką kita.
Ketvirta taisyklė: žinok savo kalbų porą. Skirtingi vertėjai skirtingai gerai veikia su skirtingomis kalbų poromis. DeepL puikiai verčia iš vokiečių, prancūzų, ispanų į anglų. Bet jei reikia versti iš suomių į lietuvių – galbūt geriau bus per anglų kaip tarpinę kalbą.
Tarpinės kalbos metodas – tai technika, kurią verta žinoti. Jei verčiamas tekstas yra, tarkime, japonų kalba, o tau reikia lietuviškai, ir tiesioginis vertimas yra prastos kokybės – pabandyk pirmiausia išversti į anglų, o tada iš anglų į lietuvių. Dažnai rezultatas būna geresnis, nes anglų kalba yra „gerai išmokyta” kalba daugumai vertėjų.
Techninė terminija – didžiausias galvos skausmas
Kalbant apie atvirų duomenų kontekstą, techninė terminija yra tikra problema. Statistikos terminai, geografiniai pavadinimai, sektoriniai terminai – visa tai gali būti išversta neteisingai arba nenuosekliai.
Pavyzdys iš realaus gyvenimo: dirbau su Eurostato duomenimis apie darbo rinką. Terminas „employment rate” buvo verčiamas tai kaip „užimtumo rodiklis”, tai kaip „įdarbinimo lygis”, tai kaip „darbo vietų skaičius” – priklausomai nuo konteksto ir vertėjo. Visi šie vertimai techniškai galimi, bet jie reiškia skirtingus dalykus, ir nenuoseklumas sukūrė painiavą.
Kaip su tuo kovoti:
- Sukurk savo terminų žodyną. Kai dirbi su konkrečia sritimi, pradėk kaupti sąrašą terminų ir jų patvirtintų vertimų. Tai gali būti paprastas Excel failas. Ilgainiui tai taupo daug laiko.
- Naudok specialistų žodynus. Eurostat, Pasaulio bankas, JTO – visos šios organizacijos turi oficialius terminų žodynus daugeliu kalbų. Prieš versdamas techninius terminus, patikrink, ar nėra oficialaus vertimo.
- Ieškok paralelines tekstų. Jei organizacija publikuoja dokumentus keliomis kalbomis (o daugelis tarptautinių organizacijų taip daro), rask tą patį dokumentą originalo ir tikslinės kalbos versijomis ir palygink. Tai geriausias būdas patikrinti, kaip turėtų būti išversti specifiniai terminai.
- DeepL Glossary funkcija. Jei naudoji DeepL Pro, yra galimybė sukurti savo terminų žodyną, kurį vertėjas naudos automatiškai. Tai labai naudinga, jei reguliariai dirbi su tais pačiais terminais.
Dar vienas dalykas, kurį reikia suprasti: kai kurie terminai tiesiog neturi gero vertimo. Ypač tai aktualu su administraciniais terminais, kurie yra specifiniai konkrečiai šaliai. Pavyzdžiui, prancūziška „commune” nėra tas pats, kas lietuviška „savivaldybė” – tai smulkesnis administracinis vienetas. Tokiais atvejais geriau palikti originalų terminą ir pateikti paaiškinimą skliausteliuose.
Automatizavimas: kai rankinis darbas nebetinka
Jei dirbi su dideliais duomenų kiekiais – tarkime, turi tūkstančius eilučių su teksto aprašymais, kuriuos reikia išversti – rankinis darbas tiesiog neįmanomas. Čia reikia automatizavimo.
Paprasčiausias kelias – API. Tiek DeepL, tiek Google Translate, tiek Microsoft Translator turi API, kurias gali naudoti programiškai. Jei moki Python, tai nėra labai sudėtinga:
DeepL Python biblioteka leidžia labai paprastai integruoti vertimą į savo duomenų apdorojimo skriptus. Pagrindinė logika yra tokia: nuskaitai duomenis, siunti tekstą per API, gauni vertimą, išsaugai. Tai gali atrodyti sudėtingai, bet iš tikrųjų yra kelios eilutės kodo.
Keletas praktinių patarimų automatizavimui:
- Nesiųsk per daug užklausų vienu metu. API turi ribas, ir jei jas viršysi, gausi klaidas arba blokavimą. Pridėk pauzę tarp užklausų – net 0,5 sekundės dažnai pakanka.
- Saugok tarpiniai rezultatai. Jei verčiamas didelis kiekis duomenų ir procesas nutrūksta per vidurį – nenori pradėti iš naujo. Išsaugok kiekvieną išverstą gabalą iš karto.
- Stebėk kaštus. Mokamos API yra apmokestinamos pagal simbolių kiekį. Prieš paleisdamas didelį vertimą, apskaičiuok, kiek tai kainuos. Kartais apsimoka pirmiausia išfiltruoti tekstą ir versti tik tai, kas tikrai reikalinga.
- Kešuok vertimus. Jei tie patys tekstai gali pasikartoti (o su duomenimis tai dažna situacija), saugok vertimų žodyną ir pirma tikrink, ar vertimas jau nėra atliktas.
Jei neprogramuoji – yra ir ne-programavimo sprendimų. Google Sheets turi integruotą GOOGLETRANSLATE funkciją, kuri leidžia versti tiesiogiai skaičiuoklėje. Tai nėra pati geriausia kokybė, bet labai patogu greitam darbui. Sintaksė paprasta: =GOOGLETRANSLATE(A1, "fr", "lt") išvers ląstelės A1 turinį iš prancūzų į lietuvių kalbą.
Kokybės tikrinimas – žingsnis, kurio negalima praleisti
Automatinis vertimas nėra tobulas. Tai žino visi. Bet problema ta, kad daugelis žmonių žino tai teoriškai, bet praktiškai elgiasi taip, lyg vertimas būtų tobulas – tiesiog ima ir naudoja rezultatą be jokio tikrinimo.
Koks yra minimalus kokybės tikrinimas, kurį visada reikėtų atlikti?
Perskaityk išverstą tekstą kaip skaitytojas, ne kaip redaktorius. Tai reiškia – nesustok ties kiekvienu žodžiu, bet atkreipk dėmesį į tai, ar tekstas apskritai turi prasmę. Ar sakiniai logiškai seka vienas kitą? Ar nėra vietų, kur tekstas staiga tampa nesuprantamas?
Ypatingą dėmesį skyrk skaičiams ir matavimo vienetams. Vertėjai kartais „išverčia” skaičius arba supainioja matavimo vienetus. Tai gali turėti rimtų pasekmių, jei dirbi su duomenimis, kur tikslumas svarbus.
Patikrink neigimus. Automatiniai vertėjai kartais praleidžia arba neteisingai verčia neigimus. „Šis metodas nėra rekomenduojamas” gali tapti „šis metodas yra rekomenduojamas” – ir tai fundamentaliai pakeičia prasmę.
Naudok atgalinį vertimą kaip greitą patikrinimą. Išversk tekstą iš originalo kalbos į tikslinę, o tada tą vertimą – atgal į originalą. Jei rezultatas labai skiriasi nuo originalo, tai signalas, kad vertimas gali būti problematiškas. Tai nėra tobulas metodas, bet greitas ir dažnai atskleidžia akivaizdžias klaidas.
Dar vienas dalykas – kai kurios klaidos yra sisteminės. Jei vertėjas vieną terminą išvertė neteisingai, jis tikriausiai tą patį terminą išvertė neteisingai visur. Todėl efektyviau yra identifikuoti ir ištaisyti sistemingas klaidas, o ne tikrinti kiekvieną sakinį atskirai.
Kai viskas susideda į vieną: tikras darbo procesas
Leisk man aprašyti, kaip atrodo realus darbo procesas, kai dirbi su atvirų duomenų rinkiniu iš kitos kalbos. Ne teorinis, o toks, kurį faktiškai naudoju.
Tarkime, radau įdomų duomenų rinkinį apie miestų oro kokybę iš Lenkijos aplinkos apsaugos agentūros. Duomenys lenkų kalba.
Žingsnis 1: Supratimas. Pirmiausia naudoju Google Translate, kad greitai suprasčiau, apie ką apskritai yra šis rinkinys. Tai ne galutinis vertimas – tiesiog žvalgyba. Ar tai, ko man reikia? Ar duomenys atitinka mano poreikius?
Žingsnis 2: Licencija. Prieš darydamas bet ką kitą, ieškau licencijos informacijos. Jei ji lenkų kalba, verčiu ją DeepL ir atidžiai perskaitau. Ar galiu naudoti šiuos duomenis savo tikslams? Ar reikia nurodyti šaltinį?
Žingsnis 3: Metaduomenys. Verčiu metaduomenų aprašymą – kas yra kiekvienas stulpelis, kokie matavimo vienetai, kaip buvo renkami duomenys. Čia naudoju DeepL ir atidžiai perskaitau rezultatą. Jei kažkas neaišku – ieškau paralelines dokumentacijos anglų kalba arba tiesiog ieškau to paties termino anglų kalba.
Žingsnis 4: Duomenų paruošimas. Jei duomenyse yra teksto laukai (kategorijų pavadinimai, aprašymai), sukuriu unikalių reikšmių sąrašą ir verčiu tik jas – ne visas eilutes. Tai taupo laiką ir pinigus.
Žingsnis 5: Terminų žodynas. Sukuriu paprastą lentelę: originalas → vertimas. Tai leidžia man būti nuosekliam ir greitai patikrinti, kaip buvo išversti konkretūs terminai.
Žingsnis 6: Tikrinimas. Perskaitau išverstus aprašymus ir metaduomenis kaip skaitytojas. Ar viskas turi prasmę? Ar nėra akivaizdžių klaidų?
Visas šis procesas su vidutinio dydžio duomenų rinkiniu užtrunka galbūt valandą. Bet tai valanda, kuri apsaugo nuo klaidų, kurios vėliau galėtų kainuoti daug daugiau laiko.
Svarbiausia, ką norėčiau, kad prisimintum: automatiniai vertėjai yra įrankiai, ne orakulai. Jie padeda tau suprasti – bet galutinis supratimas turi ateiti iš tavęs. Kuo geriau išmoksi dirbti su šiais įrankiais, tuo daugiau vertės galėsi išgauti iš milžiniško atvirų duomenų pasaulio, kuris techniškai yra prieinamas visiems, bet praktiškai – tik tiems, kurie moka juo naudotis. Ir tai nėra taip sunku, kaip gali atrodyti iš pradžių.