Internasjonaliseringskonsultasjon: Fiks det som feiler, planlegg veien videre
Du vet allerede at i18n er vanskelig. Jeg har sett symptomene: RTL-layouter som bryter sammen, tysk tekst som flyter over knapper, API-svar på feil språk og oversettelser som blir utdaterte i løpet av uker etter lansering. Jeg selger ikke vidunderkurer. Jeg hjelper deg med å nøste opp det spesifikke rotet teamet ditt sitter i — og bygge systemer som ikke knekker sammen på samme måte to ganger.
«Vi burde ha planlagt dette tidligere»
Arkitekturskatten du betaler i dag
Du lanserte på engelsk. Det fungerte. Så la du til fransk «bare for landingssiden». Nå er du her fordi:
Kodebasen din har lang=-sjekker spredt over 47 filer
Produktledere spør «kan vi A/B-teste teksten?» og utviklerne svarer «ikke uten en omskriving»
Du har tre forskjellige oversettelsesarbeidsflyter, og ingen av dem fungerer pålitelig
Hva jeg har sett gå i stykker:
- Team som bruker mer enn 6 måneder på å ettermontere i18n i en Next.js-app fordi strenger var hardkodet i komponenter
- Oversettelsesfiler som blir utdaterte fordi utviklere ikke vet hvilken fil de skal oppdatere
- «Lokaliseringsfrys» før utgivelser fordi ingen stoler på oversettelsesprosessen
- Motstand mot å endre oversatt innhold fordi arbeidsflyten er så smertefull
Hva jeg hjelper med:
- Refaktoreringsstrategier som lar deg innføre i18n gradvis (jeg krever ikke at du «stopper alt og skriver om»)
- Prosessdesign for å holde oversettelser synkronisert uten å blokkere utviklingen
- Arkitekturgjennomganger for å avdekke hvor den nåværende tilnærmingen din vil bryte sammen ved mer enn 10 språk
i18n er arkitektur, ikke en funksjon. Å legge det til i etterkant er som å bestemme at huset trenger kjeller etter at det allerede er bygget.
Jeg hjelper deg med å grave den kjelleren – eller avgjøre om du faktisk trenger en.
RTL ødelegger alt
Brukergrensesnittet ditt var ikke designet for arabisk, hebraisk eller urdu
Du satte dir=«rtl» og så layouten sprekke:
Det jeg har sett:
- Designsystemer med mer enn 200 komponenter der bare 12 håndterer RTL ordentlig
- Team som bruker float: left i stedet for logiske egenskaper – og skaper RTL-feil i hver ny funksjon
- Popovers og modaler som krever komponentspesifikke RTL-overstyringer
- Rammeverk som hevder å ha «RTL-støtte», men som bare speiler layoutretningen uten å håndtere plasseringslogikken
Hva jeg hjelper med:
- Migrering til logiske CSS-egenskaper (margin-inline-start i stedet for margin-left)
- Revisjon av designsystemer for å avdekke RTL-landminer før de sendes
- Rammeverk-spesifikk veiledning (Tailwind, shadcn, MUI) for RTL-først-styling
Å manuelt fikse RTL-feil i hver komponent er uholdbart. Jeg gjør RTL-støtte systematisk – ikke konstant brannslukking.
«Den tyske teksten sprengte knappen vår»
Brukergrensesnitt som ikke var laget for oversettelse
Engelsk passer. Tysk gjør det ikke. Designet ditt antok:
Så oversatte du til tysk, finsk eller thai og oppdaget:
Knapper kuttes av midt i et ord
Tabeller med horisontal rulling på hver rad
Tekst som brytes om til uleselige blokker
Ikke-latinsk tekst blir avkortet fordi beholderne har faste bredder
Hva jeg hjelper med:
- Elastiske UI-mønstre som tilpasser seg innholdslengden
- Tegnbudsjettplanlegging (med tanke på at tysk utvider 30 % og thai ikke bruker mellomrom)
- Typografisystemer som håndterer CJK, arabisk og devanagari uten å knekke
Jeg hjelper deg med å bygge brukergrensesnitt som tåler oversettelse – før du har betalt for 10 000 ord som ikke passer.
Du trenger ikke et foredrag om hvorfor i18n er viktig. Du trenger noen som har feilsøkt RTL-popovers klokka 2 om natta, kranglet med produktteamet om tegnbudsjetter og designet oversettelsespipelines som faktisk fungerer.
Fellene ingen advarte deg om
Skrekkhistorier fra team som har vært der
Dette er ikke teoretisk. Dette er ting som gikk i stykker i produksjon:
Flertallsformhelvete
Engelsk: «1 item» vs. «2 items»
Polsk: «1 przedmiot» / «2 przedmioty» / «5 przedmiotów» (3 flertallsformer)
Arabisk: 6 flertallsformer
Din count === 1 ? 'item' : 'items'-logikk fungerer ikke lenger.
Dato/tid-kaos
Du formaterte datoer med toLocaleDateString(). Så fikk brukere i Japan opp «2025年2月9日» i CSV-eksportene dine, og Excel brøt sammen.
API-språkkonflikt
Frontenden din ber om fransk. API-et ditt returnerer engelsk fordi autentiseringstokenet ikke har med seg lokalitet. Nå har du et brukergrensesnitt med blandet språk, og brukerne tror det er en feil.
Pseudolokaletesting
Du testet ikke med [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] før du gikk i produksjon. Nå er den polske siden din ubrukelig.
Den usynlige antakelsen
Du antok at tekststrenger er det eneste som trenger oversettelse. Så traff du på datoer, tall, valutaer, sortering og søk – alt har lokalitetsspesifikk oppførsel.
Hva jeg hjelper med:
- ICU MessageFormat-implementering (håndterer flertall, kjønn og kontekst)
- API i18n-mønstre (språkforhandling, reservestrategier)
- QA-prosesser som fanger opp disse problemene før oversettelsesbyråene gjør det
Arbeidsflyten er den vanskelige delen
Hvordan holder du 8 språk synkronisert når du leverer daglig?
Teknologien er på plass. Nå sitter du fast på prosessen:
Utviklere fletter inn kode med nye engelske strenger. Oversettelsene henger etter med 2 uker. Brukerne ser et halvveis oversatt brukergrensesnitt.
Du vet ikke hvilke strenger som trygt kan slettes (er de i bruk? oversatt? underveis hos et byrå?)
Produktteamet vil oppdatere teksten. Ingen vet om det å endre «Submit» til «Send» vil ødelegge 12 språk.
Oversettelsesfiler er ute av synk med produksjon i ukevis
Spørsmål team stiller meg:
Hva jeg har sett gå i stykker:
- Oversettelsesfiler innsjekket i git som avviker fra produksjonsstrengene
- «Ikke rør den spanske filen»-advarsler fordi ingen vet hva som er trygt å endre
- Funksjoner lansert på engelsk, deretter oversatt 6 måneder senere (om noensinne)
Hva jeg hjelper med:
- Design av oversettelsespipeline (når du skal bruke i18n-biblioteker, når du skal bruke TMS, når du skal bruke AI)
- Git-arbeidsflyter for å holde kildestrenger og oversettelser i synk
- Automatisering som blokkerer PR-er hvis nye strenger ikke er merket for oversettelse
Teknologien kan løses. Det er arbeidsflyten som er flaskehalsen. Jeg designer arbeidsflyter som ikke krever heltedåder å vedlikeholde.
Team jeg har jobbet med
Globale produkter, regional ekspertise
LINE (Japan, Taiwan, Thailand)
Meldingsplattform som opererer i 3 østasiatiske hovedmarkeder. Jobbet med utfordringer knyttet til CJK-tegnhåndtering, integrasjon med plattformøkosystemer og ulike forventninger til brukeropplevelse på tvers av Japan, Taiwan og Thailand.
KakaoTalk (Sør-Korea)
Koreas dominerende meldingsplattform. Håndterte produktkrav spesifikke for det koreanske markedet, inkludert forventninger til språklig formalitet i brukergrensesnittet og behov for plattformintegrasjon.
Change.org (196 land, mer enn 20 prioriterte språk)
Global plattform for underskriftskampanjer der både innholdshastighet og kvalitet er avgjørende. Bidro til å finne en god arbeidsflyt for oversettelse av brukergenerert politisk og sosialt innhold på tvers av ulike markeder.
Airbnb (mer enn 220 land, mer enn 60 språk)
Global markedsplass med komplekse i18n-krav. Ga råd om utfordringer knyttet til tillit og sikkerhet på flere språk, samt kulturell tilpasning av plattformkonsepter på tvers av markeder.
Intercom (mer enn 30 språk, global B2B SaaS)
Kundekommunikasjonsplattform for globale bedriftskunder. Jobbet med produktinternasjonalisering av sanntids supportverktøy og lokalisering av kunnskapsbasen.
Lilith Games (Kina, Japan, Korea, USA, EU)
Mobilspillutgiver med titler distribuert globalt. Løste markedsspesifikke utfordringer knyttet til innholdslokalisering og regionale plattformkrav.
Markeder jeg har lansert i:
Øst-Asia (Japan, Korea, Kina):
CJK-typografi, integrasjon med plattformøkosystemer, støtte for vertikal tekst
Sørøst-Asia (Thailand, Vietnam, Indonesia):
Støtte for flere skriftsystemer, mobilfokuserte brukerforventninger
MENA (arabisktalende regioner):
Krav til RTL-layout, formelle kontra uformelle språkforventninger, kulturell innholdstilpasning
Europa:
24 offisielle språk, produktlanseringer i flere land
Amerika:
Regionale språkvariasjoner (latinamerikansk spansk vs. spansk fra Spania, brasiliansk portugisisk), tospråklige markeder
Jeg har sett hva som fungerer og hva som feiler i disse markedene – ikke basert på teori, men på erfaring med å levere produkter som ekte brukere er avhengige av.
La oss fikse det som ikke fungerer
Du trenger ikke et foredrag om hvorfor i18n er viktig. Du trenger noen som har feilsøkt RTL-popovers klokka 2 om natta, kranglet med produktteamet om tegnbudsjetter og designet oversettelsespipelines som faktisk fungerer.
Arkitektur- og strategivurdering (1–2 uker):
Jeg forteller deg hva som vil ryke når du legger til de neste 3 språkene, og hva det vil koste å fikse
Markedslanseringsstøtte (4–8 uker):
Du lanserer i Japan/MENA/EU og trenger eksperter som har gjort det før
Løpende partnerskap:
Innebygd rådgivning mens du skalerer fra 2 til 20 språk
Jeg driver ikke med teori. Jeg driver med triagering, veikart og leveranser.