Mobiilisovellusten lokalisointi useille kielille on edessä, kun suomalainen sovellus on valmis ja kotimarkkinoilla toimiva tuote halutaan Ruotsiin, Saksaan tai vaikkapa Japaniin. Tämä artikkeli on tarkoitettu sovelluskehittäjille, tuoteomistajille ja pienten ohjelmistoyritysten yrittäjille, jotka miettivät, miten kieliversiot tehdään ilman että sovellus hajoaa ja budjetti karkaa. Kun työvaiheet, kustannukset ja tyypilliset sudenkuopat ovat selvillä ennen ensimmäistä tarjouspyyntöä, säästää helposti viikkoja korjaustyötä.
Mitä mobiilisovelluksen lokalisointi käytännössä sisältää
Lokalisointi on muutakin kuin käyttöliittymätekstien kääntämistä. Siihen kuuluvat painikkeet, virheilmoitukset, push-ilmoitukset, sovelluskaupan kuvaukset, kuvakaappaukset, tietosuojaseloste ja usein myös asiakastuen ohjeet. Lisäksi päivämäärät, valuutat, mittayksiköt ja numeroiden desimaalierottimet mukautetaan kohdemaan käytäntöihin.
Teknisesti työ alkaa merkkijonotiedostoista. iOS-sovelluksissa tekstit ovat tyypillisesti Xcoden String Catalog -tiedostoissa (.xcstrings) tai vanhemmissa .strings-tiedostoissa, Androidissa strings.xml-tiedostoissa. Flutter-projekteissa käytetään ARB-tiedostoja ja React Native -sovelluksissa usein JSON-muotoa. Kokenut käännöstoimisto pyytää nämä tiedostot sellaisenaan eikä Excel-taulukkoon kopioituna, koska jokainen kopiointivaihe lisää virheen mahdollisuutta.
Laajemmin ohjelmiston kieliversioiden työvaiheita käsitellään artikkelissa ohjelmistojen lokalisoinnin käytännöstä ja työvaiheista.
Myytti: konekäännös riittää, koska tekstit ovat lyhyitä
Yleinen ajatus on, että parin sanan painiketekstit voi ajaa DeepL:n tai Google Translaten läpi. Juuri lyhyys on kuitenkin ongelma. Merkkijono ”Open” voi tarkoittaa avaa-käskyä tai auki-tilaa, eikä konekäännös näe kontekstia, jossa sana näkyy.
Suomi on tässä erityisen vaativa kieli. Sijamuodot, yhdyssanat ja taivutus tekevät siitä, että muuttujia sisältävä lause kuten ”Lähetit viestin käyttäjälle {name}” toimii englanniksi, mutta suomeksi nimi pitäisi taivuttaa. Ammattikääntäjä kirjoittaa lauseen uudelleen muotoon ”Viesti lähetetty: {name}”, jolloin taivutusta ei tarvita. Konekäännös ei tee tällaista ratkaisua.
Jälkikäännöseditointi eli post-editing voi silti olla järkevä välimuoto esimerkiksi laajoissa ohjeteksteissä. Käyttöliittymän ydinteksteihin kannattaa aina käyttää ihmiskääntäjää.
Tekstin pituus, monikot ja oikealta vasemmalle -kielet
Englannista käännetty saksankielinen teksti on tyypillisesti 20–35 % pidempää, ja suomen yhdyssanat venyvät helposti yli painikkeen leveyden. ”Settings” on suomeksi ”Asetukset”, mutta ”Notification preferences” muuttuu muotoon ”Ilmoitusasetukset”, joka ei enää mahdu kapeaan välilehteen. Japani ja kiina taas lyhentävät tekstiä, mutta vaativat usein suuremman fonttikoon luettavuuden vuoksi.
Monikkomuodot ovat toinen kompastuskivi. Englannissa on kaksi muotoa, venäjässä ja ukrainassa kolme, arabiassa kuusi. Jos kehittäjä on koodannut ”{count} items” -rakenteen yhdellä merkkijonolla, arabiankielinen versio on kieliopillisesti väärin jo lähtökohtaisesti. Androidin plurals-elementti ja iOS:n String Catalogin monikkotuki ratkaisevat tämän, kun niitä käytetään alusta asti.
Arabia ja heprea kirjoitetaan oikealta vasemmalle. Silloin koko näkymä peilataan: takaisin-nuoli siirtyy oikeaan reunaan ja edistymispalkki etenee toiseen suuntaan. Tämä on kehitystyötä, ei käännöstyötä, ja se kannattaa budjetoida erikseen.
Näin mobiilisovellusten lokalisointi etenee vaihe vaiheelta
Ammattilainen aloittaa kansainvälistämisestä eli siitä, että koodissa ei ole kovakoodattuja tekstejä ja että asettelu joustaa. Sen jälkeen työ etenee seuraavasti:
1. Merkkijonot viedään käännöstiedostoiksi ja jokaiseen lisätään kuvaus tai kuvakaappaus kontekstiksi.
2. Käännöstoimisto rakentaa termikannan ja kääntää tekstit CAT-työkalussa, jolloin käännösmuisti tallentuu tulevia päivityksiä varten.
3. Pseudolokalisoinnilla testataan etukäteen, missä kohdissa pidennetty teksti katkeaa.
4. Käännökset tuodaan takaisin sovellukseen ja natiivipuhuja tarkistaa ne oikealla laitteella.
5. Sovelluskaupan metatiedot ja kuvakaappaukset lokalisoidaan erikseen.
Käännösmuisti on tässä ratkaiseva. Kun sovellukseen tulee kahden viikon välein päivitys, jossa muuttuu 40 merkkijonoa, maksetaan vain uusista ja muuttuneista. Tästä lisää artikkelissa CAT-työkaluista Trados ja MemoQ. Monet kehitystiimit käyttävät myös Lokalise-, Crowdin- tai Phrase-alustoja, joihin käännöstoimisto voi työskennellä suoraan.
Sovelluskaupan metatiedot ovat oma projektinsa
App Storessa sovelluksen nimi ja alaotsikko saavat olla enintään 30 merkkiä ja avainsanakenttä 100 merkkiä. Google Playssa lyhyt kuvaus on 80 merkkiä ja pitkä kuvaus 4 000 merkkiä. Näihin rajoihin ei päästä suoralla käännöksellä, vaan tarvitaan SEO-käännöstä ja usein transcreationia.
Ruotsalainen käyttäjä ei välttämättä hae samoilla sanoilla kuin suomalainen. Kuntosovelluksen avainsana voi olla suomeksi ”treeni”, mutta ruotsiksi ”träning” tai ”gym” – riippuen siitä, mitä kohdemaassa oikeasti haetaan. Hyvä kääntäjä tarkistaa hakuvolyymit ennen kuin kirjoittaa kuvauksen.
Hinnat ja aikataulut
Käyttöliittymäteksteissä sanahinta on yleisimmin 0,10–0,30 €/sana kielestä riippuen. Englanti, ruotsi ja saksa ovat edullisimmasta päästä, japani, kiina ja arabia kalleimmasta. Tyypillisessä sovelluksessa on 2 000–8 000 sanaa, joten yksi kieliversio maksaa karkeasti 300–2 000 €. Pienissä päivityksissä kannattaa varautua minimilaskutukseen, usein 40–80 € tilausta kohden.
Valmistusaika on 2 000 sanan käyttöliittymälle muutama arkipäivä, mutta viiden kielen samanaikainen julkaisu testauksineen vie helposti 3–4 viikkoa. Selkeä pyyntö nopeuttaa tarjousta – katso vinkit artikkelista käännöstoimiston tarjouspyynnön sisällöstä.
Yleisimmät virheet lokalisointiprojekteissa
Ensimmäinen virhe on kääntää tekstit ilman kontekstia. Kääntäjä saa listan irrallisia merkkijonoja eikä tiedä, onko ”Book” substantiivi vai verbi. Tulos on sovellus, jossa varauspainikkeessa lukee ”Kirja”.
Toinen virhe on lauseiden rakentaminen paloista koodissa. Kun ”You have” + {count} + ”new messages” liitetään yhteen, sanajärjestystä ei voi muuttaa, ja suomen, japanin tai saksan kielioppi rikkoutuu.
Kolmas virhe on unohtaa Suomen oma kaksikielisyys. Jos sovellus on tarkoitettu kunnille, hyvinvointialueille tai julkiselle sektorille, ruotsinkielinen versio on usein edellytys eikä lisäominaisuus. Saamelaisalueella toimivissa palveluissa voi tulla vastaan myös pohjoissaamen tarve, ja siihen erikoistuneita kääntäjiä on vähän – aikataulu kannattaa varata väljäksi.
Lokalisointi ei myöskään ole mainostoimiston tai viestintätoimiston työtä. Mainostoimisto suunnittelee kampanjan ja viestintätoimisto hoitaa PR:n, mutta kieliversiot, termikannat ja käännösmuistit ovat käännöstoimiston ydinosaamista.
UKK
Kuinka monelle kielelle sovellus kannattaa lokalisoida ensin?
Useimmille suomalaisille sovelluksille järkevä ensimmäinen vaihe on englanti ja ruotsi, sitten saksa. Laajentamista kannattaa ohjata latausdatalla: jos 15 % latauksista tulee Espanjasta ilman espanjankielistä versiota, siellä on selvä kysyntä.
Tarvitaanko mobiilisovelluksen käännökseen auktorisoitu kääntäjä?
Ei yleensä. Auktorisoitua kääntäjää tarvitaan virallisiin asiakirjoihin. Sovelluksen käyttöehdot ja tietosuojaseloste kannattaa kuitenkin antaa juridisiin käännöksiin perehtyneelle kääntäjälle.
Paljonko päivitysten kääntäminen maksaa?
Käännösmuistin ansiosta vain uudet ja muuttuneet merkkijonot laskutetaan täydellä hinnalla. Toistuvat osumat hinnoitellaan usein 25–50 %:lla sanahinnasta tai kokonaan ilmaiseksi.
Lokalisointi osaksi kehitysprosessia
Paras tulos syntyy, kun lokalisointi on osa jokaista julkaisusykliä eikä erillinen projekti julkaisun jälkeen. Kun merkkijonot sisältävät kontekstin, asettelu joustaa ja käännösmuisti kulkee versiosta toiseen, uuden kielen lisääminen maksaa murto-osan ensimmäisestä. Käytännön vinkki: pyydä käännöstoimistolta ensin 200 merkkijonon pilotti ja testaa se oikealla laitteella ennen kuin tilaat koko sovelluksen.