WordPressin lokalisointi ja i18n kokonaisuutena
WordPressin lokalisointi näyttää pintapuolisesti yksinkertaiselta: käännetään tekstit eri kielille ja valitaan haluttu kieli asetuksista. Todellisuudessa kyse on paljon syvemmästä arkkitehtuurisesta kokonaisuudesta, jossa yhdistyvät PHP:n i18n-mekanismit, gettext-järjestelmä, JavaScript-käännökset, tietokantamallit ja suorituskykykysymykset.
Kun lokalisointi tehdään oikein, WordPress-sivusto on aidosti monikielinen, ylläpidettävä ja laajennettava. Kun se tehdään huolimattomasti, lopputulos on sekava yhdistelmä kovakoodattuja merkkijonoja, rikkoutuneita päivityksiä ja vaikeasti debugattavia kielivirheitä. Tässä artikkelissa pureudutaan siihen, miten WordPressin i18n toimii teknisesti ja miksi se on paljon enemmän kuin pelkkä käännöstiedosto.
Mitä i18n ja l10n oikeasti tarkoittavat
Kansainvälistäminen vs. lokalisointi
i18n (internationalization) tarkoittaa sitä, että koodi on alun perin kirjoitettu niin, että se voidaan kääntää. l10n (localization) tarkoittaa varsinaista kääntämistä ja aluekohtaista sovittamista.
WordPressin näkökulmasta:
-
i18n on kehittäjän vastuulla
-
l10n on sisällöntuottajan, kääntäjän tai yhteisön vastuulla
Jos i18n on tehty huonosti, l10n ei voi korjata tilannetta jälkikäteen.
Miksi i18n on tekninen ominaisuus
Lokalisointi ei ole vain tekstiä. Se koskee myös:
-
päivämäärä- ja aikamuotoja
-
numeroita ja valuuttoja
-
suuntaa (LTR vs RTL)
-
typografiaa ja rivinvaihtoja
-
JavaScriptin generoimia tekstejä
Siksi i18n on osa ohjelmistoarkkitehtuuria, ei vain sisältökerros.
WordPressin i18n-ydin: gettext
gettext-malli
WordPress käyttää gettext-järjestelmää, joka perustuu avain–arvo-parien sijaan alkuperäisiin merkkijonoihin. Alkuperäinen teksti toimii tunnisteena.
Tämä tarkoittaa, että:
-
alkuperäinen kieli (yleensä englanti) on “totuus”
-
käännökset sidotaan täsmällisiin merkkijonoihin
-
pienikin tekstimuutos rikkoo käännöksen
Tämä on tehokasta, mutta vaatii kurinalaisuutta.
MO- ja PO-tiedostot
Käännökset elävät PO-tiedostoissa (tekstimuoto) ja MO-tiedostoissa (binäärimuoto). WordPress käyttää ajonaikaisesti MO-tiedostoja suorituskyvyn vuoksi.
Teknisesti WordPress:
-
lataa käännökset muistissa oleviksi taulukoiksi
-
hakee oikean käännöksen jokaiselle i18n-funktiolle
-
tekee tämän jokaisella pyynnöllä
Tämä tekee käännöksistä yllättävän kriittisen osan suorituskykyä.
WordPressin i18n-funktiot
Perusfunktiot
WordPress tarjoaa joukon funktioita, joilla merkkijonot tehdään käännettäviksi. Näiden funktioiden käyttäminen oikein on i18n:n ydin.
Keskeinen periaate on yksinkertainen:
-
yksikään käyttäjälle näkyvä merkkijono ei saa olla kovakoodattu
Jos teksti näkyy selaimessa, sen pitää kulkea i18n-kerroksen kautta.
Konteksti ja monimerkityksisyys
Sama sana voi tarkoittaa eri asioita eri yhteyksissä. WordPressin i18n tukee kontekstia, jotta kääntäjä voi valita oikean merkityksen.
Tämä on erityisen tärkeää admin-käyttöliittymissä, joissa sama termi voi olla:
-
substantiivi
-
verbi
-
tekninen käsite
Ilman kontekstia käännökset ovat usein virheellisiä.
Tekstialueet ja domain-ajattelu
Text domain arkkitehtuurisena rajana
Text domain määrittää, mihin käännöskokonaisuuteen merkkijono kuuluu. WordPressissä:
-
ytimellä on oma domain
-
jokaisella lisäosalla on oma domain
-
jokaisella teemalla on oma domain
Text domain ei ole koriste. Se on nimiavaruus, joka estää törmäykset ja pitää käännökset hallittavina.
Yksi domain, yksi vastuu
Yleinen virhe on käyttää väärää text domainia tai useita domaineja samassa lisäosassa. Tämä johtaa tilanteeseen, jossa:
-
käännöksiä ei ladata
-
osa teksteistä jää kääntämättä
-
debuggaus on vaikeaa
Hyvä nyrkkisääntö: yksi projekti, yksi text domain.
JavaScript ja i18n WordPressissä
Moderni WordPress on kaksikielinen myös JS:ssä
Gutenberg, block editor ja modernit teemat tuottavat suuren osan käyttöliittymästä JavaScriptillä. Tämä tarkoittaa, että i18n ei voi jäädä PHP-tasolle.
WordPress tarjoaa JavaScript-puolelle oman i18n-kerroksen, joka peilaa PHP:n logiikkaa.
Käännösten lataaminen JS:lle
JavaScript-käännökset eivät tule automaattisesti. WordPress:
-
generoi JSON-muotoiset käännökset
-
liittää ne tiettyihin skripteihin
-
lataa ne vain tarvittaessa
Jos tämä ketju katkeaa, JavaScript-tekstit jäävät englanniksi, vaikka PHP-puoli olisi käännetty oikein.
Yleinen virhe: kovakoodattu JS-teksti
Yksi yleisimmistä i18n-virheistä on kovakoodata teksti JavaScriptiin. Tämä rikkoo lokalisoinnin täydellisesti ja on usein vaikea havaita ennen tuotantoa.
Lokalisointi ja tietokanta
Sisältö vs. käyttöliittymä
WordPress erottaa periaatteessa:
-
käyttöliittymän tekstit (koodissa)
-
sisällön (tietokannassa)
Käyttöliittymä lokalisoidaan gettextillä. Sisältö lokalisoidaan eri mekanismeilla, kuten:
-
erillisillä sisällöillä per kieli
-
metadatalla
-
kielikohtaisilla tauluilla
Näitä ei pidä sekoittaa.
Miksi koodiin ei kuulu kielikohtaista sisältöä
Jos kielikohtainen sisältö on kovakoodattu PHP:hen, sitä ei voi:
-
muokata editorissa
-
päivittää ilman koodimuutoksia
-
hallita käännösprosesseissa
i18n koskee käyttöliittymää, ei sisältöstrategiaa.
Suorituskyky ja i18n
Käännösten lataus ei ole ilmaista
Jokainen ladattu käännöstiedosto:
-
vie muistia
-
lisää tiedostojärjestelmäoperaatioita
-
kasvattaa bootstrap-aikaa
Suurissa WordPress-ympäristöissä, joissa on kymmeniä lisäosia, i18n voi muodostua yllättäväksi suorituskykypullonkaulaksi.
Hyvät käytännöt
Teknisesti hyvin tehty i18n:
-
lataa vain tarvittavat käännökset
-
käyttää yhtä text domainia
-
ei rakenna dynaamisia merkkijonoja käännösfunktioiden sisään
-
välttää turhaa käännöskutsujen määrää silmukoissa
i18n ei ole ilmainen ominaisuus, mutta se on hallittavissa.
RTL ja visuaalinen lokalisointi
Oikealta vasemmalle -kielet
WordPress tukee RTL-kieliä, mutta tuki ei ole automaattinen. Teeman ja lisäosien täytyy:
-
käyttää loogisia CSS-ominaisuuksia
-
välttää kovakoodattuja suuntia
-
testata layout RTL-tilassa
i18n ei ole vain tekstiä. Se on myös visuaalista suunnittelua.
Yleisimmät virheet WordPressin i18n:ssä
Yleisin virhe on lisätä i18n jälkikäteen. Toinen on käyttää i18n-funktioita väärin tai epätasaisesti. Kolmas on unohtaa JavaScript kokonaan.
Kaikki nämä johtavat samaan lopputulokseen: osittain käännettyyn, epäluotettavaan käyttöliittymään.
Milloin i18n on onnistunut
WordPressin lokalisointi on onnistunut, kun:
-
yksikään teksti ei ole kovakoodattu
-
käännökset toimivat ilman lisälogiikkaa
-
uudet kielet voidaan lisätä ilman koodimuutoksia
-
kehittäjä ei ajattele kieltä erikoistapauksena
Parhaimmillaan i18n katoaa näkyvistä. Se on siellä, mutta siihen ei tarvitse koskea.
Lopuksi: i18n on osa ammattimaista WordPress-kehitystä
WordPressin lokalisointi ei ole lisäominaisuus. Se on merkki siitä, että järjestelmä on rakennettu kestämään aikaa, kasvua ja erilaisia käyttäjäryhmiä.
Teknisesti hyvin toteutettu i18n tekee WordPressistä aidosti globaalin alustan. Huonosti toteutettuna se tekee siitä paikallisen kompromissin.
Ja juuri siksi lokalisointi ei ole käännöstyötä. Se on ohjelmistosuunnittelua.
