Kansainvälistymiskonsultaatio: Korjaa se, mikä hajoaa, suunnittele seuraavat askeleet.
Tiedätte jo, että i18n on vaikeaa. Olen nähnyt oireet: RTL-asettelut, jotka romahtavat, saksankielinen teksti, joka valuu painikkeiden yli, API-vastaukset väärällä kielellä ja käännökset, jotka ajautuvat epäsynkkaan viikkojen kuluessa lanseerauksesta. En myy hopealuoteja. Autan teitä selvittämään sen tietyn sotkun, jossa tiiminne on — ja rakentamaan järjestelmiä, jotka eivät rikkoudu samalla tavalla kahdesti.
"Tämä olisi pitänyt suunnitella aiemmin"
Arkkitehtuurivero, jota maksatte nyt
Lanseerasitte englanniksi. Se toimi. Sitten lisäsitte ranskan "vain laskeutumissivua varten". Nyt olette täällä, koska:
Koodipohjassanne on lang= -tarkistuksia ripoteltuna 47 tiedostoon
Tuotejohtajat kysyvät "voimmeko A/B-testata tekstiä?" ja tekniikka sanoo "ei ilman uudelleenkirjoitusta"
Teillä on kolme erilaista käännöstyönkulkua, eikä yksikään niistä toimi luotettavasti
Mitä olen nähnyt rikkoutuvan:
- Tiimit, jotka käyttävät yli 6 kuukautta i18n:n jälkiasentamiseen Next.js-sovellukseen, koska merkkijonot oli kovakoodattu komponentteihin
- Käännöstiedostot eivät pysy synkronoituna, koska kehittäjät eivät tiedä, mitä tiedostoa pitää päivittää
- "Lokalisointijäädytys"-jaksot ennen julkaisuja, koska kukaan ei luota käännösputkeen
- Vastustus käännetyn sisällön muuttamiselle, koska työnkulku on niin tuskallinen
Mitä teen:
- Refaktorointistrategiat, jotka antavat teille mahdollisuuden tehdä i18n:n käyttöönotosta asteittaista (en vaadi "pysäyttäkää kaikki ja kirjoittakaa uudelleen")
- Prosessin suunnittelu, jotta käännökset pysyvät synkronoituna estämättä kehitystä
- Arkkitehtuurikatselmukset sen tunnistamiseksi, missä nykyinen lähestymistapanne rikkoutuu 10+ kielen kohdalla.
i18n on arkkitehtuuria, ei ominaisuus. Sen lisääminen jälkikäteen on kuin päättäisi, että talo tarvitsee kellarin sen jälkeen, kun se on jo rakennettu.
Autan teitä kaivamaan sen kellarin – tai päättämään, tarvitsetteko oikeasti sellaista.
RTL rikkoo kaiken
Teidän käyttöliittymäänne ei ollut suunniteltu arabiaksi, hepreaksi tai urduksi
Vaihdoitte dir="rtl" ja katsoitte, kun asettelunne räjähti:
Mitä olen nähnyt:
- Suunnittelujärjestelmät, joissa on yli 200 komponenttia ja joista vain 12 käsittelee RTL:n kunnolla
- Tiimit, jotka käyttävät float: left -määrittelyä loogisten ominaisuuksien sijaan ja luovat RTL-bugeja jokaiseen uuteen ominaisuuteen
- Ponnahdusikkunat ja modaalit, jotka vaativat komponenttikohtaisia RTL-ylikirjoituksia
- Ohjelmistokehykset, jotka väittävät tarjoavansa "RTL-tuen" mutta jotka vain kääntävät asettelun suunnan ja rikkovat sijoittelulogiikan
Mitä teen:
- CSS:n loogisten ominaisuuksien migraatio (margin-inline-start margin-leftin sijaan)
- Suunnittelujärjestelmäauditoinnit, joilla löytää RTL-miinat ennen kuin ne toimitetaan
- Framework-kohtaiset ohjeet (Tailwind, shadcn, MUI) RTL-ensin-tyylittelyyn
RTL-bugien korjaaminen käsin jokaisessa komponentissa ei ole kestävää. Teen RTL-tuesta järjestelmällistä, en jatkuvaa palojen sammuttelua.
"Saksankielinen teksti rikkoi painikkeemme"
Käyttöliittymä, jota ei rakennettu kääntämistä varten
Englanti mahtuu. Saksa ei. Suunnittelunne oletti:
Sitten käänsitte saksaksi, suomeksi tai thaiksi ja huomasitte:
Painikkeiden teksti katkeaa kesken sanan
Taulukot, joissa on vaakasuuntainen vieritys jokaisella rivillä
Teksti, joka rivittyy lukukelvottomiksi lohkoiksi
Ei-latinalainen teksti katkeaa, koska säiliöillä on kiinteät leveydet
Mitä teen:
- Joustavat UI-mallit, jotka venyvät sisällön pituuden mukaan
- Merkkibudjetin suunnittelu (tietää, että saksa laajenee 30 %, thai ei käytä välilyöntejä)
- Typografiajärjestelmät, jotka käsittelevät CJK:n, arabian ja devanagarin rikkoutumatta
Autan teitä rakentamaan käyttöliittymän, joka kestää kääntämisen—ennen kuin olette maksaneet 10,000 sanaa, jotka eivät mahdu.
Te ette tarvitse luentoa siitä, miksi i18n on tärkeää. Te tarvitsette jonkun, joka on debuggannut RTL-ponnahdusikkunoita kello 2 aamulla, väitellyt tuotetiimin kanssa merkkibudjeteista ja suunnitellut käännösputkia, jotka oikeasti toimivat.
Sudenkuopat, joista kukaan ei varoittanut
Sotatarinoita tiimeiltä, jotka ovat käyneet tämän läpi
Nämä eivät ole teoreettisia. Nämä ovat asioita, jotka rikkoutuivat tuotannossa:
Monikkomuotohelvetti
Englanti: "1 kohde" vs "2 kohdetta"
Puola: "1 przedmiot" / "2 przedmioty" / "5 przedmiotów" (3 monikkomuotoa)
Arabia: 6 monikkomuotoa
Teidän count === 1 ? 'kohde' : 'kohteet' -logiikkanne ei enää toimi.
Päivämäärä-/aikakaaos
Muotoilit päivämäärät toLocaleDateString():llä. Sitten käyttäjät Japanissa näkivät CSV-vienneissäsi "2025年2月9日", ja Excel meni sekaisin.
API:n kielten epäsuhta
Frontendinne pyytää ranskaa. API:nne palauttaa englantia, koska todennustunniste ei sisällä lokaalia. Nyt käyttöliittymänne on kaksikielinen ja käyttäjät ajattelevat, että se on bugi.
Pseudolokaalitestaus
Ette testanneet tekstillä [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] ennen tuotantoon siirtymistä. Nyt puolankielinen sivustonne on käyttökelvoton.
Näkymätön oletus
Oletitte, että merkkijonot ovat ainoa asia, joka pitää kääntää. Sitten törmäätte päivämääriin, numeroihin, valuuttoihin, lajitteluun, hakuun—kaikkeen, jolla on kielialuekohtainen logiikka.
Mitä teen:
- ICU MessageFormat -toteutus (käsittelee monikot, sukupuolen, kontekstin)
- API:n i18n-mallit (kielineuvottelu, fallback-strategiat)
- QA-prosessit, jotka löytävät nämä ongelmat ennen kuin käännöstoimistot löytävät
Työnkulku on se vaikea osuus
Miten pidätte 8 kieltä synkronoituna, kun toimitatte päivittäin?
Olette selvittäneet teknologian. Nyt olette jumissa prosessissa:
Kehittäjät yhdistävät koodia, jossa on uusia englanninkielisiä merkkijonoja. Käännökset laahaavat 2 viikkoa jäljessä. Käyttäjät näkevät puoliksi käännetyn käyttöliittymän.
Et tiedä, mitkä merkkijonot on turvallista poistaa (ovatko ne käytössä, käännetty vai toimistolla työn alla?)
Tuote haluaa päivittää tekstiä. Kukaan ei tiedä, rikkooko "Submit"-sanan muuttaminen "Send"-sanaksi 12 kieltä.
Käännöstiedostot eivät pysy synkronoituina tuotannon kanssa viikkoja kerrallaan.
Kysymyksiä, joita tiimit kysyvät minulta:
Mitä olen nähnyt rikkoutuvan:
- Git:iin lisätyt käännöstiedostot, jotka poikkeavat tuotannon merkkijonoista
- "Älkää koskeko espanjan tiedostoon" -varoitukset, koska kukaan ei tiedä, mitä on turvallista muuttaa
- Ominaisuudet lanseerataan englanniksi ja käännetään sitten 6 kuukautta myöhemmin (jos koskaan)
Mitä teen:
- Käännösputken suunnittelu (milloin käyttää i18n-kirjastoja, milloin käyttää TMS:ää, milloin käyttää tekoälyä)
- Git-työnkulut lähdemerkkijonojen ja käännösten synkronointiin
- Automaatio, joka estää PR:t, jos uusia merkkijonoja ei ole merkitty käännettäväksi
Teknologia on ratkaistavissa. Työnkulku on este. Suunnittelen työnkulkuja, jotka eivät vaadi sankaritekoja ylläpitoon.
Tiimit, joiden kanssa olen työskennellyt
Globaalit tuotteet, alueellinen asiantuntemus
LINE (Japani, Taiwan, Thaimaa)
Viestintäalusta, joka toimii 3 ensisijaisella itäaasialaisella markkinalla. Työskentelin CJK-merkkien käsittelyyn liittyvien erityishaasteiden, alustan ekosysteemintegraation sekä käyttäjäkokemusodotusten parissa, jotka eroavat Japanin, Taiwanin ja Thaimaan välillä.
KakaoTalk (Etelä-Korea)
Korean hallitseva viestintäalusta. Työskentelin Korean markkinakohtaisten tuotevaatimusten parissa, mukaan lukien käyttöliittymän kielen muodollisuusodotukset ja alustan integraatiotarpeet.
Change.org (196 maata, 20+ ensisijaista kieltä)
Globaali vetoomusalusta, jossa sekä sisällön nopeus että laatu merkitsevät. Auttoi navigoimaan käännöstyönkulussa käyttäjien tuottamalle poliittiselle/yhteiskunnalliselle sisällölle eri markkinoilla.
Airbnb (220+ maata, 60+ kieltä)
Globaali markkinapaikka, jolla on monimutkaiset i18n-vaatimukset. Konsultoin useilla kielillä luottamukseen ja turvallisuuteen liittyvissä haasteissa sekä alustan käsitteiden kulttuurisessa mukauttamisessa eri markkinoille.
Intercom (yli 30 kieltä, maailmanlaajuinen B2B-SaaS).
Asiakasviestintäalusta, joka palvelee kansainvälisiä yritysasiakkaita. Työskentelin tuotteen kansainvälistämisen parissa reaaliaikaisten tukityökalujen ja tietopankin lokalisoinnissa.
Lilith Games (Kiina, Japani, Korea, Yhdysvallat, EU)
Mobiilipelijulkaisija, jonka pelit julkaistaan maailmanlaajuisesti. Työskentelin markkinakohtaisten haasteiden parissa sisällön lokalisoinnissa ja alueellisissa alustavaatimuksissa.
Markkinat, joilla olen tehnyt lanseerauksen:
Itä-Aasia (Japani, Korea, Kiina):
CJK-typografia, alustaympäristön integraatio, pystysuoran tekstin tuki
Kaakkois-Aasia (Thaimaa, Vietnam, Indonesia):
Usean kirjoitusjärjestelmän tuki, mobiili ensin -käyttäjäodotukset
MENA (arabiaa puhuvat alueet):
RTL-asetteluvaatimukset, muodollisen vs. puhekielisen kielen odotukset, sisällön kulttuurinen mukauttaminen
Eurooppa:
24 virallista kieltä, usean maan samanaikaiset tuotelanseeraukset
Amerikat:
Alueelliset kielivariaatiot (LATAM-espanja vs. Espanja, brasilianportugali), kaksikieliset markkinat
Olen nähnyt, mikä toimii ja mikä epäonnistuu näillä markkinoilla – en teoriasta, vaan toimittamalla tuotteita, joista todelliset käyttäjät ovat riippuvaisia.
Korjataan se, mikä rikkoutuu
Te ette tarvitse luentoa siitä, miksi i18n on tärkeää. Te tarvitsette jonkun, joka on debuggannut RTL-ponnahdusikkunoita kello 2 aamulla, väitellyt tuotetiimin kanssa merkkibudjeteista ja suunnitellut käännösputkia, jotka oikeasti toimivat.
Arkkitehtuuri- ja strategia-arviointi (1–2 viikkoa):
Kerron teille, mikä rikkoutuu, kun lisäätte seuraavat 3 kieltä, ja mitä sen korjaaminen maksaa
Markkinalanseerauksen tuki (4–8 viikkoa):
Olette lanseeraamassa Japanissa/MENA/EU ja tarvitsette asiantuntijoita, jotka ovat tehneet sen aiemmin
Jatkuva kumppanuus:
Sulautettu konsultointi, kun skaalatte 2 kielestä 20 kieleen
En tee teoriaa. Teen triagea, tiekarttoja ja toimitan.