”Joko löydän tien tai teen sen itse.” Näin totesi Hannibal yli 2000 vuotta sitten epäileville kenraaleilleen kertoessaan, miten hän aikoo kuljettaa Karthagon armeijan sotanorsuineen Alppien yli. Ja hän onnistui.

Kun olemme tehneet WordPressillä monikielisiä verkkosivuja, on edessä ollut niin rotkoja kuin vuorenhuippujakin. Koska WordPress ei suoraan paketista tue monikielisyyttä, on sopivat ratkaisut täytynyt etsiä. Eikä valmiita ratkaisuja aina ole löytynyt, vaan työkaluja on pitänyt rakentaa itse. Tämä kirjoitus kertoo, miten monikielisyyden esteitä on meillä ylitetty.

On vain yksi hyvä monikielisyyslisäosa

Kun vuosia sitten aloimme rakentaa monikielisiä sivustoja WordPressille, sopivan lisäosan valinta ei ollut helppoa. Kaikki eri ratkaisut olivat lähteneet omille poluilleen esimerkiksi siinä, miten artikkelin kieli tallennettiin tietokantaan tai miten saman artikkelin käännökset liitettiin toisiinsa. Näillä valinnoilla on kauaskantoisia vaikutuksia latausnopeuteen, toimintavarmuuteen ja yhteensopivuuteen muiden lisäosien kanssa.

Kokeilimme alussa qTranslate- ja WPML-lisäosia. qTranslate tallensi kaikki saman artikkelin käännökset yhden artikkelin sisään, jolloin lisäosasta oli hankala päästä eroon. Jos lisäosan otti pois päältä, sisältö muuttui kaikkia kieliä yhdistäväksi sotkuksi. qTranslate hajosi yleensä aina WordPressin päivittyessä ja se ei tullut kovin hyvin toimeen muiden lisäosien kanssa.

WPML puolestaan oli ja on edelleen vanhin ja laajin monikielisyyslisäosa. Sillä on aina ollut paljon vanhaa kooditaakkaa ja se käyttää monenlaisia kikkoja ohittaakseen vanhoja WordPressin rajoitteita. WPML:n pahin vihollinen oli sen omat päivitykset, jotka kadottivat sisältöä, sotkivat valikkoja ja rikkoivat hallintanäkymiä. Kun jokin asia ei toiminut sivustolla, paljastui syylliseksi yleensä WPML. Lisäosa teki lisäksi sivuston latautumisesta hitaan valtavilla tietokantakyselyillään.

Huono monikielisyyslisäosa näkyi asiakkaille epävakaana sivustona, rikkinäisinä toimintoina ja hitautena.

Polylang osoittautui pelastukseksi. Sen vahvuus ja heikkous olivat sen yksinkertaisuudessa, joka teki siitä toimintavarman ja nopean. Yksinkertaisuuden hinta oli se, että WPML:ltä tuttua valmiiden ominaisuuksien, laajennusten ja integraatioiden yltäkylläisyyttä ei löytynyt. Tiesimme jo ensiaskeleilla, että tie Polylangin kanssa vaatisi omien hihojen käärimistä ja monien työkalujen rakentamista itse. Porkkanana vaihdossa oli kuitenkin luotettavuus. Omituiset toimintahäiriöt ja rikkinäiset päivitykset loppuivat Polylangiin siirtymisen jälkeen.

Kääntäjän ei pitäisi tuijottaa tyhjää ruutua

Polylangilla sisällön kääntämisen työläys tuli ilmi eräällä sivustolla, jossa kieliä oli paljon. Sisällön sivustolle syöttänyt henkilö kirjoitti aina ensin alkuperäisen jutun ja ryhtyi sen jälkeen liittämään käännöstoimistolta saadut käännökset WordPressiin. Prosessi meni jotenkin näin:

  • Kirjoita, muotoile ja kuvita upea artikkeli.
  • Klikkaa ”lisää käännös”-nappulaa.
  • Tuijota lamaantuneena tyhjää ruutua.
  • Lisää uudestaan kaikki otsikkotasot, kuvien asettelut ja videoupotukset.

Sisällöntuottajan aikaa valui hukkaan. Syntyi helposti pieniä tahattomia eroja kieliversioihin, kun kuva lisättiin vahingossa eri koossa, eri kohtaan tai ilman kuvatekstiä. Viimeinen niitti oli se, että jo taakse jätetyltä WPML-lisäosalta sisällön kopiointitoiminto olisi kyllä löytynyt, Polylangilta sen sijaan ei.

Tyhjä editori käännöksen pohjaksi on lohduton näky.

Tämä ominaisuus piti siis rakentaa itse ja syntyi laajennus Polylang Copy Content. Pelkän sisällön kopioimisen ja liittämisen lisäksi täytyy huolehtia, että kaikki upotetut kuvat ja galleriat tulevat käsiteltyä. Jos sivustolla käytetään kuvien kieliversiointia, on myös kuvista olemassa omat käännöksensä. Kopioinnissa täytyy siis etsiä upotetut kuvat, luoda tai etsiä olemassaoleva käännös ja korvata upotettu kuva uudella.

Tällä laajennuksella on noin 1000 latauskertaa vain Composer-paketinhallinnan kautta, eli se on todennäköisesti tälläkin hetkellä satojen sivustojen käytössä. Polylangin maksulliseen Pro-versioon tuli vastaava ominaisuus pian julkaisun jälkeen. Olimme Polylangin kehittäjän kanssa tietämättämme rakentaneet samaa ominaisuutta suunnilleen samaan aikaan, mutta me ehdimme julkaista ensin.

Klikkaus, joka särkee sivuston

Polylangissa on näppärä ominaisuus, jolla artikkelin kielen voi vaihtaa jälkikäteen. Jos alkaa kirjoittaa artikkelia ruotsiksi ja huomaa myöhemmin, että artikkelin kieleksi onkin valittu suomi, voi tämän asetuksen vaihtaa. Käyttöliittymässä kielen valinta näkyy pudotusvalikkona käännösten yläpuolella, mutta pelkästään sitä tuijottamalla ei ole ihan selvää, mitä valikosta tapahtuu…

Kerran saimme asiakkaalta viestin, että heidän sivustolla yhden kielen etusivu oli rikki. Mitään päivityksiä tai koodimuutoksia ei oltu tehty. Pienellä tutkimustyöllä selvisi, että tältä kieleltä ei löytynyt käännöksistä koko etusivua ollenkaan. Asiakas oli luullut siirtyvänsä käännöksestä toiseen, mutta olikin epähuomiossa vaihtanut etusivun kielen toiseksi, jolloin yksi kieliversio jäi ilman etusivua. Tämä kaikki yhdellä klikkauksella.

Päätimme parantaa käyttöliittymää hiukan ja loimme laajennuksen Polylang Smart Language Select Disabler. Artikkelin kieltä voi vaihtaa niin kauan, kun käännöksiä ei ole, minkä jälkeen koko pudotusvalikko poistetaan näkyvistä. Näin sivusto ei mene rikki yhdestä harhaklikkauksesta.

Tämä pieni muutos on pelastanut monia sivustoja.

Sivuston pienten tekstipätkien kääntäminen

Sivupohjiin tulee aina pieniä tekstipätkiä kuten ”Avaa valikko” ja ”Jaa somessa”, jotka eivät suoraan liity mihinkään artikkeliin tai sivuun. Näitä tekstejä ei voi siis kääntää vain luomalla käännöstä tietystä artikkelista. Tarvitaan jokin erillinen paikka pikkutekstien kääntämiseen.

Olemme törmänneet monenlaisiin virityksiin pienten tekstipätkien kääntämisessä. Kuvassa Janne Ala-Äijälä, WordCamp Finland 2016.

WordPress tarjoaa sisäänrakennetun tavan kääntää lisäosia ja teemoja PO/MO-tiedostojen kautta. Koko projektista generoidaan POT-tiedosto, joka kerää kaikki käännöstä kaipaavat tekstipätkät. PO-tiedostot kääntävät nämä tekstit ja käännöksistä tulee MO-tiedostoja, joita kone pystyy lukemaan. Koko prosessi on räätälöidyille sivupohjille kankea, asiakkaan käännettäväksi vaikea ja yllättävän hidas ladata.

Polylang tarjoaa käännöksiin oman työkalunsa, johon me pystymme koodista käsin rekisteröimään tekstipätkät, ja käännökset voi syöttää suoraan hallintanäkymästä. Alkuperäisen tekstinkin pystyy muokkaamaan hallintanäkymässä, jolloin kehittäjän ei tarvitse etukäteen tietää, pitääkö sivustolla lukea alkuperäisellä kielellä ”Kerro kaverille” vai ”Jaa somessa”. Asiakas voi muuttaa sen itse myöhemmin.

Verkkosivujemme aloituspakkaus Aucor Starter sisältää valmiin työnkulun ja työkaluja tekstipätkien kääntämiseen tällä tavalla. Esimerkiksi ystävämme Dudella ja Vincitillä ovat lainanneet näitä omiin teemoihinsa.

Sisältömassan automaattinen käsittely ja korjaus

Ei tietysti riitä, että sisällöntuottajat voivat itse kliksutella uusia käännöksiä hallinnasta. Joskus sisältöä pitää tuoda sivustolle toisesta järjestelmästä, rajapinnasta tai vanhalta sivustolta. Silloin sivustolle siirtyy jopa monta sataa artikkelia, tuotetta tai toimipistettä. Tähän sisältömassaan pitää automaattisesti merkitä esimerkiksi sisällön kieli ja yhdistää saman artikkelin käännökset toisiinsa. Toki nämä tiedot saisi klikkailtua yksitellen hallinnastakin, mutta elämä on liian lyhyt sellaiseen.

Erään kerran saimme siirtotiedoston, josta uudelle sivustolle piti tuoda Excelissä satoja jälleenmyyjiä. Sisällön kieli oli helppo asettaa tuonnin yhteydessä, kun se oli merkitty valmiiksi jokaiselle riville. Ongelmaksi tuli kuitenkin näiden käännösten liittäminen toisiinsa. Polylangin pitää tietää, mitkä artikkelit ovat käännöksiä toisistaan, jotta käännösten välillä voi liikkua hallinnassa. Liitokset näkyvät myös metatiedoissa, mikä on tärkeää hakukonenäkyvyydelle.

Siirtotiedostossa saman artikkelin käännökset piti merkitä yksilöllisellä tunnisteella (tässä tapauksessa käytimme y-tunnusta), etsiä käännökset ja liittää ne toisiinsa. Rakensimme tähän tehtävään Polylang Translation Mapper -laajennuksen, joka tekee juuri näin. Yhdistämiseen menee viisi minuuttia, minkä jälkeen laajennuksen voi poistaa.

Sisällön massakäsittely on helposti sotkuista ja stressaavaa hommaa.

Toinen tapaus sattui, kun asiakas ihmetteli, miksi artikkelin pääkuvan kuvateksti muuttuu alkuperäisessä artikkelissa, kun sen vaihtaa käännöksessä. Huomasin, että Polylangissa ei ollut käytössä mediakirjaston käännöksiä. Tismalleen samat kuvat, kuvatekstit ja ruudunlukijoiden käyttämät alt-tekstit vilisivät siis joka kielessä. Sisältöäkin oli kertynyt jo sen verran, ettei niitä viitsinyt käsitellä yksitellen.

Polylangissahan löytyy kyllä oma vipu sille, tehdäänkö kuvista kieliversioita vai ei. Sitä ei vain oltu laitettu päälle eikä kieliversioita tehty. Käännösasetuksen kytkeminen päälle ei korjaa kaikkia jo lisättyjä kuvia. Piti siis etsiä kaikki upotetut kuvat, luoda kuvista käännökset ja korvata upotetut kuvat uusilla. Rakensimme tähän laajennuksen Polylang Translate Existing Media, joka käy koko sisällön läpi parissa minuutissa ja korjaa kaikkiin sivustoihin kuviin oikeat kieliversiot käyttöön. Tämän jälkeen asiakas pystyi vapaasti kääntämään kuvien tekstejä ilman alkuperäisten tekstien katoamista.

On muuten huomattava, että aikanaan kuvien kieliversioiden tekemistä välteltiin, koska kuvien kääntäminen vaati asiakkaalta työlästä klikkailua yksitellen. Jokainen kuva täytyi kopioida ja kääntää käsin mediakirjastossa. Nykyään luomamme Polylang Copy Content luo automaattisesti kieliversiot kaikista artikkeliin upotetuista kuvista ja tuo ne paikalleen sisältöön, kun käännös luodaan, eikä asiakkaan tarvitse klikkailla kuvia erikseen.

Arabian, kiinan ja venäjän omituiset osoitteet

WordPress muuttaa artikkelin otsikon automaattisesti osoitteeksi kelpaavaksi versioksi. Esimerkiksi ”Nätti sää” muuttuu osoitteessa ”natti-saa”, jotta se toimii kaikkialla. Miksi osoitteeseen ei sitten voi tunkea mitä tahansa merkkejä, on tarina toiselle päivälle.

Jostain syystä WordPress ei kykene tekemään tätä siivousta kaikille kielille. Eräälle sivustolle luotiin venäjän, kiinan ja arabian kieliversiot. Huomattiin, että WordPress ei osaa siivota osoitteita suoraan oikein. Puuttuville kielille tulee todennäköisesti joskus tuki suoraan WordPressiin, mutta toistaiseksi asia korjaantui lisäosilla (arabia, kiina, venäjä).

Jotta asia ei olisi ollut liian helppo, kävi pian ilmi, että nämä lisäosat eivät tule keskenään toimeen. Arabian lisäosa poistaa kaikki kyrilliset merkit ellei kiinan lisäosa ehdi kadottamaan arabiaa ensin. Jos koko kolmikkoa tarvitsee samaan sivustoon, pitää nämä osoitesiivoukset koota niin, että ne eivät kiusaa toisiaan. Loimme lisäosan Aucor URL Sanitizer, joka huomioi koko kolmikon ilman konflikteja.

Karseeta säätöä?

Monikielisyys tuo sivuston rakennukseen kokonaisen uuden kerroksen haasteita. Ne haasteet on kuitenkin tähän mennessä aina voitettu. Vaikka WordPress ei tarjoile meille virallisia monikielisyystyökaluja, voimme lähestyä niitä Hannibalin tavoin. Me joko löydämme valmiit ratkaisut tai rakennamme ne itse – sekä jaamme ne muille.

Monikielisyydestä löytyy tarinoita enemmänkin. Kävin viime vuonna vieraana Suomen ainoassa WordPress-podcastissa juttelemassa monikielisyydestä ja WordPressistä. Käy kuuntelemassa perustelut esimerkiksi sile, miksi lippuja ei kannata käyttää kielivalintana.