10 yleisintä i18n-virhettä ja miten vältät ne
Opi yleisimmistä kansainvälistymisen virheistä, joita kehittäjät tekevät, ja miten korjata ne. Paranna sovelluksesi lokalisaation laatua näiden parhaiden käytäntöjen avulla.
Kansainvälistäminen (i18n) vaikuttaa yksinkertaiselta — kunnes huomaat, että saksalaiset käyttäjät näkevät rajatut napit, japanilaiset käyttäjät saavat katkaistuja lauseen fragmentteja ja arabiaa käyttävät käyttäjät näkevät täysin vialliset asettelut. Nämä eivät ole reunatapauksia. Ne ovat odotettavia seurauksia yleisistä virheistä, joita suurin osa kehitystiimeistä tekee, kun lokalisointeja lähdetään tekemään ensimmäistä kertaa. Tässä oppaassa käymme läpi 10 yleisintä i18n-virhettä, selitämme tarkasti miksi ne tapahtuvat ja näytämme askel askeleelta, miten jokaisen virheen korjaat. Ei ole väliä rakennatko uutta sovellusta vai lisäätkö olemassa olevaa — näiden sudenkuoppien välttäminen säästää sinulta viikkoja virheenkorjauksia.
Virhe #1: Kovakoodatut merkkijonot
Merkkijonojen kovakoodaus on i18n:n perusvirhe. Se johtuu siitä, että kehittäjät keskittävät ensin ominaisuuksien toimivuuteen ja aikovat 'siistimisen myöhemmin'. Mutta myöhemmin se ei koskaan tule, ja sinulla on tuhansia merkkijonoja hajallaan sadoissa tiedostoissa.
['Aseta i18n-rajapintasi ennen UI-koodin ensimmäistä riviä', 'Käytä linter-lisäosaa kovakoodattujen merkkijonojen havaitsemiseen malleissa ja komponenteissa', 'Pidä käännösavaimet kuvailevina ja organisoituina ominaisuuden tai sivun mukaan']
Aseta i18n-rajapintasi ennen UI-koodin ensimmäistä riviä
Käytä linter-lisäosaa kovakoodattujen merkkijonojen havaitsemiseen malleissa ja komponenteissa
Pidä käännösavaimet kuvailevina ja organisoituina ominaisuuden tai sivun mukaan
Tyypillinen tilanne
Ohjelmistokehittäjä kirjoittaa napin tekstin suoraan JSX:ään: <button>Submit Order</button>.
Sovellus julkaistaan englanniksi ja toimii moitteettomasti. Kuuden kuukauden kuluttua yritys laajentaa toimintaansa Saksaan.
Lokalisointitiimi löytää 2 000+ kovakoodattua merkkijonoa. Jälkiasennus kestää 3 viikkoa ja aiheuttaa 47 bugia.
Miksi tämä on ongelma
Kehittyneessä koodipohjassa kovakoodatut merkkijonot voivat kasvaa tuhansiksi. Niiden jälkietäminen vaatii kaikkien tiedostojen muokkaamisen, jokaisen komponentin uudelleentestauksen ja kaikkialla regresioiden riskin.
Kovakoodatut merkkijonot ovat suoraan lähdekoodissa, malleissa tai komponentteissa kiinnitettyinä. Niitä ei voi erottaa, kääntää tai ajonaikaisesti vaihtaa ilman, että koodia itseä muutetaan.
Käyttäjät ei-englanniksi lokalisoiduilla alustoilla näkevät kääntämättömiä UI-elementtejä sekoittuneina käännetyn sisältöön — kaaottinen ja epäammattimaisen vaikutelman.
Näin korjaat sen
Säilytä kaikki käyttäjälle näkyvät merkkijonot alusta alkaen resurssitiedostoissa.
Ota käyttöön käännyskehys (esim. next-intl, react-i18next, vue-i18n) ennen ensimmäisen komponentin kirjoittamista.
Luo resurssitiedostorakenne (esim. messages/fi.json) ja viittaa kaikki merkkijonot käännös-avaimilla kuten t('checkout.submitButton').
Lisää lint-sääntö tai pre-commit-hook, joka merkitsee raakakirjoitusmerkkijonot käyttöliittymäkomponenteissa.
Virhe #10: Kaikki sanat tarkasti kääntäminen
Kaikki sisältöä ei pitäisi kääntää. Brändinimet, oikeudellisten entiteettien nimet, tekniset termit ja tietyt tuotemerkit on säilytettävä alkuperäisellä kielellään. Liiallinen kääntäminen voi aiheuttaa oikeudellisia ongelmia, brändi-inhimillisyys ja käyttäjän hämmentyminen.
["Pidä yllä 'Älä käännä'-sanastoa ja jaa se kaikille kääntäjille", 'Käytä lukittuja segmenttejä tai erillisiä nimiavaruuksia tuotemerkki- ja oikeudellisille termeille', 'Anna aina kontekstitiedot moniselitteisille merkkijonoille, jotta virheellisiä käännöksiä vältetään']
Pidä yllä 'Älä käännä'-sanastoa ja jaa se kaikille kääntäjille
Käytä lukittuja segmenttejä tai erillisiä nimiavaruuksia tuotemerkki- ja oikeudellisille termeille
Anna aina kontekstitiedot moniselitteisille merkkijonoille, jotta virheellisiä käännöksiä vältetään
Tyypillinen skenaario
Käännöstiedosto sisältää yrityksen nimen 'CloudForge Inc.' ja teknisen termin 'OAuth 2.0 Token' tavallisina käännettävinä merkkijonoina.
Esimerkiksi espanjalainen kääntäjä kääntää 'CloudForge' sanaksi 'ForjaNube' ja 'OAuth 2.0 Token' sanaksi 'ficha OAuth 2.0'.
Tuloksena: Käyttäjät eivät löydä yritystä oikealla nimellä, ja espanjankielistä dokumentaatiota lukevat kehittäjät ovat hämmentyneitä tuntemattomista termistöistä.
Miksi tämä on ongelma
Yhden väärin käännetyn tavaramerkin nimen vuoksi oikeudellisessa asiakirjassa sopimukset voivat tulla mitättömiksi. Ylikäännösten korjaaminen vaatii jokaisen merkkijonon tarkistamisen jokaisessa kielessä — useiden viikkojen työ.
Kun kaikki merkkijonot lähetetään kääntäjille kontekstittomasti, kääntäjät voivat kääntää brändinimet ('Apple' → 'Omena'), oikeudelliset termit ('GmbH' → 'LLC') tai tekniset termit, jotka on säilytettävä englanniksi.
Käyttäjät eivät löydä tuotteita tunnetulla brändinimellään, oikeudelliset asiakirjat viittaavat väärään yhtiöön, ja tekninen dokumentaatio on vaikeasti ymmärrettävää, kun termit kuten 'API Endpoint' kääntyvät.
Näin korjaat sen
Merkitse ei-käännettävät sisällöt selvästi ja anna kääntäjille kontekstimuistiinpanot.
Laadi 'ei-käännettävän' sanakirja, joka listaa kaikki tuotemerkit, tuotenimet, oikeushenkilöt ja alan termit, jotka on säilytettävä muuttumattomina.
Käytä erillistä namespacea tai erityisiä avaimia ei-käännettävälle sisällölle. Monet i18n-työkalut tukevat 'lukittuja' segmenttejä, joita kääntäjät eivät voi muokata.
Lisää kääntäjien kommentteja/kuvauksia käännöstiedostoihisi, jotka selittävät kontekstin: 'Tämä on tuotemerkki — ei käännettävä' tai 'Ammatteinen termi — säilytä englanniksi'.
Virhe #2: Merkkijonojen ketjuttaminen
Fragmenttien yhdistäminen lauseiksi näyttää englanniksi järkevältä, mutta muissa kielissä se ei toimi. Sanojen järjestys, kielioppi ja lauserakenne vaihtelevat kielestä toiseen, mikä tekee ketjutetuista merkkijonoista kääntämättömiä.
['Älä koskaan yhdistä lauseita kääntämällä fragmentteja', 'Käytä nimettyjä paikkamerkkejä ('{name}') sijaan sijaintipohjaisia ({0}) selkeyden vuoksi', 'Tarjoa kontekstikommentteja kääntäjille, jotka selittävät, mitä kukin paikkamerkki sisältää']
Älä koskaan muodosta lauseita yhdistämällä käännettyjä fragmentteja
Käytä nimettyjä paikkamerkkejä ('{name}') sijaan sijaintipohjaisia ({0}) selkeyden vuoksi
Tarjoa kontekstuaalisia huomautuksia kääntäjille, jotka selittävät, mitä jokainen paikkamerkki sisältää.
Tyypillinen skenaario
Kehittäjä kirjoittaa: 'You have ' + count + ' items in your ' + cartType + ' cart' — toimii täydellisesti englanniksi.
Saksalainen kääntäjä saa kolme erillistä fragmenttia eikä kykene muodostamaan kieliopillisesti oikeaa lausetta, koska sanajärjestyksen on muututtava.
Tuloksena: Saksalaiset käyttäjät näkevät 'Sie haben ' + count + ' Artikels in deinem Warenkorb' — virheellinen lause, menettää sujuvuutta.
Miksi tämä on ongelma
Jokainen ketjutettu merkkijono on tikittävä aikapommi. Kielen määrä on 20 ja ketjutettujen merkkijonojen määrä 50; se voi johtaa 1 000 kielioppivirheeseen, joita on korjattava manuaalisesti.
Merkkijonojen ketjutus kuten 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' edellyttää tietyn sanajärjestyksen. Kääntäjät saavat kontekstittomia fragmentteja, joita he eivät voi järjestää.
Käyttäjät näkevät kieliopillisesti vääriä lauseita. Saksaksi verbi on usein lopussa. Arabialaisessa kielessä koko rakenne on päinvastainen. Tulos kuulostaa järjettömältä.
Näin korjaat sen
Käytä parametrisoituja viestejä nimettyjen paikkamerkkien kanssa, jotta kääntäjät voivat muuttaa koko lauseen.
Korvaa yhdistäminen yhdellä viestivälinellä ja paikkamerkeillä: 'cart.summary': 'Sinulla on {count} artikkelia '{cartType}'-ostoskorissasi'.
Siirrä muuttujat käännöstoimintoon parametreina: t('cart.summary', { count: 5, cartType: 'Premium' }).
Kääntäjät voivat nyt vapaasti järjestää: 'Sinun '{cartType}'-ostoskorissasi on {count} artikkelia' — kieliopillisesti oikea saksa.
Virhe #3: Monikoinnin laiminlyönti
Englannilla on kaksi monikkomuotoa: yksikkö ja monikko. Kehittäjät olettavat usein, että kaikilla kielillä on sama sovitus. Eivät. Puolalla on 4 muotoa, arabiaksi 6, ja jopa ranskankieliset käsittelevät nollan eri tavalla kuin englanti.
['Käytä aina ICU MessageFormatia tai vastaavaa kirjastoa laskettavien sisältöjen käsittelyyn', 'Älä koskaan kirjoita omaa monikkomuodon logiikkaasi — luota CLDR-sääntöihin', 'Kokeile monikkomuotoja arvoilla kuten 0, 1, 2, 5, 21 ja 100 kattamaan kaikki kategoriat']
Käytä aina ICU-viestimuotoa tai vastaavaa kirjastoa laskettaville arvoille
Älä koskaan kirjoita omaa monikkomuotlogiikkaa — luota CLDR-sääntöihin
Testaa monikkomuotoja arvoilla kuten 0, 1, 2, 5, 21 ja 100 kattamaan kaikki kategoriat.
Tyypillinen skenaario
Kehittäjä kirjoittaa: count + (count === 1 ? ' Datei' : ' Dateien') — käsittelee saksan kieltä oikein.
Puolalainen kääntäjä tarvitsee 4 muotoa: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. Yksinkertainen ternäärinen ei pysty ilmaisemaan tätä.
Tuloksena: Puolalaiset käyttäjät näkevät '5 pliki' (virheellinen muoto) sijaan '5 plików' (oikea muoto), ja sovellus vaikuttaa katkenneelta.
Miksi tämä on ongelma
Jokainen laskettava substantiivi sovelluksessasi tarvitsee monikon käsittelyn. 50 tällaista merkkijonoa ja 20 kieltä tarkoittavat 1 000 monikon sääntöä — mahdotonta hallita käsin.
Yksinkertaiset if/else-tarkistukset (count === 1 ? 'Datei' : 'Dateien') kattavat vain saksan ja englannin. CLDR määrittelee jopa 6 monikkomuodon kategorian: zero, one, two, few, many ja other. Jokainen kieli käyttää eri osaa.
Käyttäjät näkevät kieliopillisesti vääriä tekstejä kuten '1 Nachrichten' tai täysin vääriä monikkomuotoja. Formaaleissa yhteyksissä se rikkoo uskottavuuden.
Näin korjaat sen
Käytä ICU-viestimuotoa, joka tukee kaikki CLDR-monikot automaattisesti.
Määrittele viestit ICU-syntaksilla: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
Kääntäjät tarjoavat kaikki tarvittavat monikkomuodot omalle kielelleen. Puolaksi: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
Sinun i18n-kirjastosi valitsee ajonaikaisesti oikean muodon aktiivisen locale:n CLDR-sääntöjen mukaan.
Virhe #4: Kiinteät UI-elementtien leveydet
Suunnittelijat luovat pikselintarkkoja asetteluja englanniksi, ja kehittäjät toteuttavat ne kiinteillä leveysarvoilla. Mutta käännetty teksti voi olla dramaattisesti pidempi tai lyhyempi. Saksankielinen teksti on noin 30% pidempi kuin englanninkielinen, kun taas kiinankielinen teksti voi olla 50% lyhyempi.
['Älä koskaan käytä kiinteitä pikselileveyksiä käännettävän tekstin sisältävien elementtien kanssa', 'Varaa 40 % tekstin laajennus perustasoksi — joillakin kielillä laajentuminen on vielä suurempaa', 'Käytä CSS Flexbox tai Grid -rakenteita, jotka sopeutuvat vaihtelevaan sisällön pituuteen']
Älä koskaan käytä kiinteitä pikselileveyksiä käännettävän tekstin sisältävien elementtien kanssa
Varaa noin 40 % tekstin lisäykselle baselines‑n vuoksi — joillakin kielillä lisäys on vielä suurempi
Käytä CSS Flexbox tai Grid -rakenteita, jotka sopeutuvat eripituisen sisällön mukaan
Tyypillinen skenaario
Suunnittelija luo navigointipalkin, jossa on 5 painiketta, jokainen täsmälleen 100px leveä — näyttää englanniksi erinomaiselta.
Saksan käännös: 'Settings' muuttuu 'Einstellungen'ksi (13 vs 8 merkkiä), 'Submit' muuttuu 'Absenden'iksi (8 vs 6). Navigaatiopalkki ylivuotaa.
Tuloksena: Mobiililaitteissa napit pinoutuvat päällekkäin tai teksti leikataan, mikä tekee navigoinnista saksankielisille käyttäjille hyödyttömän.
Miksi tämä on ongelma
Jokaisella kiinteän leveyden omaavalla elementillä on potentiaalinen murtokohta. Tyypillisessä sovelluksessa on satoja näppäimiä, tunnisteita ja kortteja, joiden kaikkien on kestettävä tekstin laajentumista.
Kiinteä leveys (width: 120px) sisältöä sisältävä säiliö ja kiinteän kokoiset napit leikkaavat sisällön, kun teksti kasvaa. CSS overflow: hidden piilottaa sisällön hiljaisesti, kun overflow: visible rikkoo asettelun.
Käyttäjät näkevät katkaistuja tunnisteita kuten 'Einstellu...' sen sijaan kuin 'Einstellungen', tai painikkeita, jotka peittävät viereisiä elementtejä. Keskeiset toiminnot ovat luettamattomia tai ei-klikkattavissa.
Näin korjaat sen
Muotoile ja toteuta joustavat layoutit, jotka sopeutuvat kaikkien Locales-sisällön pituuteen.
Korvaa kiinteät leveydet min-width, max-width ja joustavilla layoutioilla. Käytä CSS Grid tai Flexboxia tilan dynaamiseen jakamiseen.
Aseta tekstikonteiner katkaisemaan rivit: käytä overflow-wrap: break-word ja vältä white-space: nowrap käännettävällä sisällöllä.
Testaa UI:n pseudo-lokalisaatiolla, joka pidentää kaikkia merkkijonoja noin 40 % simuloidakseen pahimman mahdollisen tilan — ennen kuin lähetät merkkijonot kääntäjille.
Virhe #5: Päivämäärä- ja numeromuotoilu
Datan ja lukujen näytöt voivat vaikuttaa universaaleilta. Mutta 01/02/2025 tarkoittaa Yhdysvalloissa 2. tammikuuta ja Euroopassa 1. helmikuuta. Desimaalierottimet ja pisteet voivat muuttaa merkityksen: 1,000.50 (USA) vs 1.000,50 (Saksa). Tämän virheellinen toteutus johtaa sekaannukseen, data-virheisiin ja luottamuksen menetykseen.
['Älä koskaan formatoi dataa tai numeroita manuaalisesti merkkijonopohjaisilla templteillä — käytä aina Intl-API:ita', 'Tallenna kaikki tiedot ISO 8601 -muodossa ja valuutat pienimmässä yksikössä (sentteinä) sisäisesti', 'Testaa erilaisilla localeilla, joissa on erilaiset desimaalierottimet, päivämääräjärjestykset ja kalenterit']
Älä koskaan muodosta tietoja tai numeroita käsin merkkijonopohjaisilla template-tekniikoilla — käytä aina Intl-API:ta.
Tallenna kaikki tiedot ISO 8601 -muodossa ja valuutat pienimmässä yksikössä (sentteinä) sisäisesti
Testaa localeilla, joissa on erilaiset desimaalierottimet, päivämääräjärjestykset ja kalenterit
Tyypillinen skenaario
Kehittäjä muotoilee päivämäärän muodossa MM/DD/YYYY ja hinnan muodossa $1,234.50 — oikein US-käyttäjille.
Saksalainen käyttäjä näkee päivän 03/04/2025 ja tulkitsee sen 3.4.2025 (DD/MM/YYYY-konventio). Hinta $1,234.50 näyttää siltä, että sen pitäisi olla 1.234,50.
Tuloksena: Käyttäjä varaa lennon väärällä päivämäärällä ja epäilee hintamuotoa. Tukipyyntöjä Saksassa kasvaa 15 %.
Miksi tämä on ongelma
Päivämäärä- ja numeromuotoilut koskevat jokaista sovelluksesi datan näyttöä: taulukot, kuviat, lomakkeet, laskut, raportit. Globaalilla korjauksella kattuu satoja ilmentymiä.
Kovakoodatut formaattimerkkijonot kuten toLocaleDateString('en-US') tai manuaalinen muotoilu template-lausekkeilla ohittavat käyttäjän todellisen locale. Oikea locale mutta väärä kalenteri aiheuttaa ongelmia.
Käyttäjät lukevat dataa väärin ja syöttävät tiedot väärässä formaatissa. Esimerkiksi eurooppalainen käyttäjä näkee 03/04/2025 ja tulkitsee sen 3.4.2025 (DD/MM/YYYY).
Näin korjaat sen
Käytä sisäänrakennettua Intl-APIa tai locale-tukea sisältävää formaattikirjastoa kaikille datalle, ajoille, numeroille ja valuutoille.
Korvaa manuaalinen muotoilu Intl.DateTimeFormat(locale) -funktiolla päivämääriin ja Intl.NumberFormat(locale, { style: 'currency', currency }) -funktiolla hinnoille.
Säilytä tiedot ISO 8601 -muodossa (YYYY-MM-DD) ja muotoile ne vain näytölle käyttäjän localea vasten.
Testaa kriittiset päivämäärä- ja numeroesitykset vähintään viidellä eri lokaaleilla: en-US, de-DE, ja-JP, ar-SA ja zh-CN, kattaaksesi tärkeimmät muotoiluvaihtoehdot.
Virhe #6: RTL-kielet unohtuneet
Vasemmasta oikeaan (RTL) -kielet kuten arabia, heprea ja persiskaa käyttävät yli 500 miljoonaa ihmistä. Suurin osa sovelluksista kuitenkin suunnitellaan LTR-yleisöä varten. RTL-tuki ei tarkoita vain tekstin kiertämistä — koko käyttöliittymä on peilitettävä.
['Käytä alusta lähtien vain loogisia CSS-ominaisuuksia (inline-start/end, block-start/end)', 'Testaa sovellustasi dir="rtl" HTML-elementillä jokaisessa sprinttikatsauksessa', 'Laadi RTL-testilista navigaatiolle, kuvakkeille, lomakkeille ja etenemisenä näyttöarvoille']
Käytä alusta lähtien vain loogisia CSS-ominaisuuksia (inline-start/end, block-start/end)
Testaa sovellustasi dir='rtl' HTML-elementillä jokaisessa sprintin katselmuksessa
Laadi RTL-testilista navigaatiolle, kuvakkeille, lomakkeille ja etenemisenä näyttöarvoille
Tyypillinen tilanne
Kehittäjä käyttää margin-left: 16px ja text-align: left koko sovelluksessa — normaali LTR-linjaus.
Sovellus avautuu Saudi-Arabiassa. Takaisin-painikkeet osoittavat eteenpäin, sivupalkit ilmestyvät väärälle puolelle, ja numeerinen data on väärin kohdistettu.
Tuloksena: Arabialaiset käyttäjät poistuvat sovelluksesta 30 sekunnin kuluttua. Tiimi joutuu tekemään 4 viikon Notfall-CSS-Refactoringin.
Miksi tämä on ongelma
RTL-tuki koskee jokaista sovelluksesi komponenttia. RTL:n jälkikäteen käyttöönotto vaatii tyypillisesti 30-50% kaikkien CSS-sääntöjen uudelleenkirjoittamisen sekä jokaisen ikonin ja asettelun tarkistamisen.
CSS-ominaisuudet kuten margin-left, padding-right, text-align: left ja float: left kovakoodavat suunnan. Kuvakkeet, joilla on suuntamerkintä (nuolipainikkeet ja etenemisen indikaattorit) osoittavat väärään suuntaan. Jopa border-radius-arvot on peilitettävä.
Arabialaiset käyttäjät näkevät navigoinnin väärässä kulmassa, etenemispalkit liikkuvat taaksepäin, ja UI-elementtien kanssa törmäävä teksti on epäselvää. Sovellus tuntuu vieraannuttavalta ja käytettävyys on heikkoa.
Näin korjaat sen
Käytä loogisia CSS-ominaisuuksia ja testaa RTL-layoutia alusta alkaen.
Korvaa kaikki fyysiset CSS-ominaisuudet loogisilla vastineilla: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Aseta dir-attribuutti HTML-juurin elementille aktiivisen locale:n mukaan. Käytä :dir(rtl) CSS-pseudokieltä RTL-overrideihin.
Tarkista kaikki kuvakkeet suunnan mukaan. Korvaa suunnasta riippuvat kuvakkeet peilatuilla versioilla tai käytä CSS transform: scaleX(-1) RTL-ympäristöjä varten.
Virhe #7: Kuvat, joissa on teksti
Tekstin upottaminen kuviin – olipa kyse hero-banneristä, napeista, infografiikoista tai näytöistä – on lokalisointikauhu. Jokainen tekstiä sisältävä kuva on tehtävä uudelleen jokaiselle kielelle, mikä moninkertaistaa suunnittelukustannukset ja hidastaa julkaisua.
['Älä koskaan upota käännettävää tekstiä suoraan rasterikuvien (PNG, JPG) sisään.', 'Käytä CSS-tekstin päällekkäisyyksiä taustakuvissa hero-bannerien ja CTA-iden yhteydessä.', 'Automatisoi kuvakaappauksien luominen App Store -luetteloille ja markkinointisivuille.']
Älä koskaan upota käännettävää tekstiä suoraan rasterikuvien (PNG, JPG) sisälle
Käytä CSS-tekstioverlayta taustakuvien päällä hero-bannerissa ja CTA:issa
Automatisoi kuvakaappausten generointi App Store -listauksille ja markkinointisivuille
Tyypillinen skenaario
Suunnittelija luo promo-bannerin, jonka tekstinä on 'Start Your Free Trial' upotettuna suoraan kuvaan.
Lokalisaatiotiimi kääntää kaikki UI-tekstit, mutta saksan sivun banneri näyttää yhä englantia.
Tuloksena: Saksan laskeutumissivulla on häiritsevä englanninkielinen banneri. 15 kielen lokalisoitujen bannerien laatiminen kestää 3 päivää suunnittelutyötä ja viivästyttää julkaisua.
Miksi tämä on ongelma
Tyypillisellä markkinointisivulla on 5–10 kuvaa, joissa on teksti. 15 kielellä tämä tarkoittaa 75–150 kuvaversiota, jotka on luotava, ylläpidettävä ja päivitettävä jokaisen muotoilumuutoksen yhteydessä.
Kuvien sisälle upotettu teksti (PNG, JPG, SVG upotetulla tekstillä) ei ole käännettävissä käännöstyökaluilla. Jokainen lokalisoitu versio vaatii, että suunnittelija muokkaa lähdetiedostoa manuaalisesti, vie sen ulos ja lataa sen uudelleen.
Käyttäjät näkevät kuvia, joissa on teksti vieraalla kielellä, tai vielä pahempaa, sekoituksen käännetystä käyttöliittymästä ja kääntämättömistä kuvista. Tämä heikentää brändin luotettavuutta.
Näin korjaat sen
Erottele teksti kuvista käyttämällä CSS-päällekkäisyyksiä, käännettävissä olevia tekstielementtejä sisältäviä SVG-tiedostoja tai dynaamista kuvien luomista
Käytä CSS:ää asettaaksesi käännettävän tekstin kuvan päälle: aseta tekstikerros absoluuttisella sijoittelulla kuvan kontainerin päälle.
Infografiikoille tai kaavioille käytä SVG-tiedostoja, joissa on <text>-elementtejä, jotka viittaavat käännösavaimiin sen sijaan, että upottaisit raakaa merkkijonoa.
App-näyttökuvat markkinointimateriaaleihin automatisoi kuvankaappausten generoinnin työkaluilla, kuten Fastlane (mobiili) tai Playwright (verkkosivut), jotka tallentavat näytöt jokaisessa lokalisaatiossa.
Virhe #8: Puuttuvia käännöksiä ei ole käsitelty
Käännökset ovat kehityksen aikana aina puutteellisia. Uudet ominaisuudet lisäävät merkkijonoja nopeammin kuin kääntäjät ehtivät niitä kääntää. Ilman kunnollista fallback-käsittelyä puuttuvat käännökset voivat aiheuttaa sovelluksen kaatumisen, tyhjiä käyttöliittymän elementtejä tai raakkoja käännös-avaimia, joita käyttäjät näkevät.
['Aseta aina vähintään yksi varakieli i18n-asetuksiisi', 'Kirjaa puuttuvat käännösavaimet seurantajärjestelmääsi', 'Aseta vähimmäiskäännösten kattavuus ennen kuin locale julkaistaan']
Aseta aina vähintään yksi varakieli i18n-asetuksiisi
Kirjaa puuttuvat käännösavaimet seurantajärjestelmääsi
Aseta vähimmäiskäännösten kattavuus ennen kuin locale julkaistaan
Tyypillinen tilanne
Kehittäjä lisää uuden 'Premium Features' -osion 15 uudella käännösavaimella. Englanninkielinen versiop julkaistaan välittömästi.
Ranskankieliset käännökset eivät ole vielä valmiita. Ranskalainen sivu näyttää raakkoja avaimia: 'premium.feature1.title', 'premium.feature1.description'.
Tulokset: Ranskalaiset käyttäjät näkevät rikkinäisen sivun, joka on täynnä kehittäjäpuolen avainten nimiä. Tukitiimi saa kymmeniä virheraportteja.
Miksi tämä on ongelma
Sovelluksesi kasvaessa ero englanninkielisten merkkijonojen ja muiden kielten käännösten välillä kasvaa. Sovelluksella, jolla on 100 kieltä ja 2 000 merkkijonoa, voi olla milloin tahansa yli 10 000 puuttuvaa käännöstä.
Ilman fallback-logiikkaa puuttuva käännösavain palauttaa undefined, null tai raakaksi jätetyn avaimen (esim. 'checkout.confirmButton'). Template-moottorit voivat heittää virheitä, aiheuttaa sivun kaatumisen tai mitään ei näytetä.
Käyttäjät näkevät rikkoutuneen käyttöliittymän: tyhjät painikkeet, puuttuvat otsikot tai kryptiset merkkijonot kuten 'nav.settings.title' todellisen tekstin sijaan. Tämä on hämmentävää ja epäammattimaista.
Näin korjaat sen
Määritä vankka fallback-ketju ja seuraa käännösten kattavuutta kaikissa lokalisoinneissa.
Määritä i18n-määrittelyysi fallback-kieliketju: puuttuvat ranskan (fr) avaimet palautuvat automaattisesti englanniksi (en).
Lisää Missing-key-käsittelijä, joka kirjaa kääntämättömät avaimet valvontajärjestelmääsi (esim. Sentry, Datadog) häiritsemättä käyttäjäkokemusta.
Luo käännösten kattavuuden hallintanäkymä, joka seuraa käännösten valmiusastetta jokaiselle locale-alueelle ja estää julkaisut, kun kattavuus laskee alle kynnyksen (esim. 95%).
Virhe #9: Merkkien koodausongelmat
Merkkikoodausongelmat ovat lokalisoinnin hiljainen tappaja. Kaikki näyttää englanniksi ja eurooppalaisilla kielillä hyvältä, mutta kun lisäät kiinan, japanin, korean, arabian tai emoji-käyttöä, ilmestyy mojibake-merkkien vääristymiä. Nämä virheet ovat tunnetusti vaikeasti havaittavissa.
['Käytä UTF-8-koodausta kaikkialla — lähdekoodit, tietokanta, API-vastaukset ja HTML-meta-tunnisteet', 'Käytä utf8mb4:ää MySQL:ssä (ei utf8), jotta koko Unicode-alue, mukaan lukien emoji, on tuettu', 'Testaa todellisella sisällöllä CJK-, arabiankielisillä ja emoji-sisällöillä, jotta koodausongelmat havaitaan aikaisin']
Käytä UTF-8-koodausta kaikkialla — lähdetiedostoja, tietokantaa, API-vastauksia ja HTML-meta-tunnisteita
Käytä utf8mb4:ää MySQL:ssä (ei utf8), jotta koko Unicode-alue, mukaan lukien emoji, on tuettu
Testaa todellisella sisällöllä CJK-, arabiankielisillä ja emoji-sisällöillä, jotta koodausongelmat havaitaan aikaisin
Tyypillinen tilanne
Kehittäjä asettaa MySQL-tietokannan latin1-kollaation (vanha vakiokäytäntö). Lähdekoodi käyttää UTF-8.
Japanilaiset käyttäjät rekisteröityvät oikealla nimellään. Tietokanta tallentaa '田中太郎' vioittuneina tavuina.
Tuloksena käyttäjäprofiili näyttää epäselvää tekstiä. Vielä pahempaa: haku ja lajittelu epäonnistuvat kaikille CJK-nimille, mikä vaikuttaa tuhansiin käyttäjiin.
Miksi tämä on ongelma
Koodausongelmat leviävät koko pinon läpi. Väärin määritetty tietokanta-collation voi vahingoittaa miljoonia tietueita — korjaus vaatii kalliita tietomigraatioita.
Epäjohdonmukainen koodaus koko pinon halki — UTF-8 lähdetiedostoissa, Latin-1 tietokannassa ja Windows-1252 API-vastauksissa — rikkoo monibyte-merkit. Yksi väärin konfiguroitu kerros muuttaa '日本語' merkkijonoksi '????' tai '日本èª'.
Käyttäjät näkevät rikottuja tekstejä, kysymysmerkkejä tai tyhjiä laatikoita, joissa pitäisi olla heidän kielensä. Pahin tapauksessa lomakekenttien syötteet vahingoittuvat pysyvästi tietokantaan.
Näin korjaat sen
Varmista UTF-8-koodauksen johdonmukaisuus jokaisessa sovelluspinon kerroksessa.
Aseta kaikki lähdetiedostot UTF-8:iin (konfiguroi editorisi ja .editorconfig). Lisää <meta charset='UTF-8'> HTML-tiedostoihisi ja 'Content-Type: application/json; charset=utf-8' API-vastauksiin.
Konfiguroi tietokanta utf8mb4:ään (ei vain utf8, joka MySQL:ssä on kolmitavun alijoukko). Aseta yhteys-kollaatio utf8mb4_unicode_ci.
Valitse kirjasimet, jotka kattavat kohdekielesi kirjoitusjärjestelmät: latina, kyrillinen, CJK, arabia, devanagari. Käytä järjestelmäfonttien pinoja tai Google Fonts -fontteja, joissa on kielikohtaiset subsetit, jotta lataus on nopeaa.
Testaa i18n-toteutuksesi
Pituuden laajennustesti
Laajenna kaikki käännetyt merkkijonot 30–40 prosentilla, jotta tekstin laajentuminen simuloi runsaasti tekstiä sisältävissä kielissä, kuten saksan, suomen tai kreikan kaltaisissa kielissä esiintyvää lisäystä. Tämä kattaa kiinteän leveyden sisältävät kontit, katkaistut nimikkeet ja ylivuotavat napit ennen käännöksen aloittamista. Monet pseudo-lokalisaatio-työkalut tarjoavat tämän ominaisuutena.
"Lähetä" → "Ṡééééñðéñ_éxpáñðéð" (40% pidempi)
Pseudo-lokalisaatio
Pseudo-lokalisaatio korvaa jokaisen merkin aksentoidulla vastineella (esim. 'a' → 'á') ja ympäröi merkkijonot merkintöjen kuten [!! ja !!] avulla. Näin näet heti, mitkä merkkijonot ovat kovakoodattuja ja mitkä käännösjärjestelmän kautta. Ota pseudo-lokalisaatio mukaan CI-pipelineen, jotta regressiot saadaan automaattisesti kiinni.
Jokainen näytöllä oleva teksti, joka ei ole [!! !!]-merkintöjen sisällä, on kovakoodattu ja sen tulisi ulkoistaa. Tämä testi tunnistaa 95 % ohitetuista merkkijonoista alle minuutin sisällä.
"Lähetä viesti" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
RTL-layout-testi
RTL-layoutin testaaminen onnistuu ilman arabia- tai hepreankäännöksiä lisäämällä HTML:ään dir='rtl'. Tämä paljastaa heti suuntaan liittyvät CSS-ongelmat: ikonit väärin kohdistettuina, marginaalit väärällä puolella, toimimaton navigointi ja virheellisesti järjestetyt flex-itemit. Tee siitä vakiotesti jokaisessa sprintin katselmuksessa — se kestää vain 10 sekuntia ja estää ongelmat, jotka muuten veisivät viikkoja korjaamisessa tuotantoon.
i18n-tarkistuslista
['Kaikki käyttäjille näkyvät merkkijonot on siirretty resurssitiedostoihin', 'Älä käytä merkkijonojen ketjuttamista lauseiden muodostamiseen', 'Monikielisyyssäännöt ICU-viestimuodon tai vastaavan kanssa toteutettu', 'Päivämäärä-, aika- ja numerosyntaksin tulee käyttää lokalisointiyhteensopivia API-rajapintoja', 'RTL-layout testattu arabian- tai hepreankielisillä sisällöillä', 'Joustava käyttöliittymä, jonka ei ole kiinteitä leveyksiä tekstiä sisältävissä elementeissä', 'Vara-kieli on määritetty ja puuttuvien avainten varalta testattu', 'UTF-8-koodauksen on oltava johdonmukainen kaikissa tiedostoissa ja tietokannoissa', 'Kuvankaappaukset ja markkinointivälineet jokaiselle kielelle päivitetty', 'i18n-tarkistuslista']