Internationaliseringskonsultation: Ret det, der går i stykker, planlæg det næste
Du ved allerede, at i18n er svært. Jeg har set symptomerne: RTL-layouts, der kollapser, tysk tekst, der flyder ud over knapper, API-svar på det forkerte sprog og oversættelser, der glider ud af synkronisering få uger efter lancering. Jeg sælger ikke mirakelløsninger. Jeg hjælper dig med at rede den specifikke rod ud, dit team sidder i, og bygge systemer, der ikke bryder sammen på samme måde to gange.
»Vi burde have planlagt det her tidligere«
Den arkitekturskat, du betaler lige nu
Du lancerede på engelsk. Det virkede. Så tilføjede du fransk »bare til landingssiden.« Nu er du her, fordi:
Din kodebase har lang=-tjek spredt ud over 47 filer
Produktledere spørger »kan vi A/B-teste teksten?«, og udvikling svarer »ikke uden en omskrivning«
Du har tre forskellige oversættelsesarbejdsgange, og ingen af dem fungerer pålideligt
Hvad jeg har set gå galt:
- Teams, der bruger mere end 6 måneder på at eftermontere i18n i en Next.js-app, fordi strenge var hardkodet i komponenter
- Oversættelsesfiler, der glider ud af synkronisering, fordi udviklere ikke ved, hvilken fil de skal opdatere
- »Lokaliseringsstop« før udgivelser, fordi ingen stoler på oversættelsespipelinen
- Modstand mod at ændre oversat indhold, fordi arbejdsgangen er så besværlig.
Det hjælper jeg med:
- Refaktoreringsstrategier, der lader dig indføre i18n trinvist (jeg kræver ikke, at du »stopper alt og skriver om«)
- Procesdesign til at holde oversættelser synkroniserede uden at blokere udvikling
- Arkitekturgennemgange for at identificere, hvor din nuværende tilgang går i stykker ved mere end 10 sprog
i18n er arkitektur, ikke en funktion. At forsøge at tilføje det senere er som at beslutte, at dit hus skal have en kælder, efter du allerede har bygget det.
Jeg hjælper dig med at grave den kælder – eller finde ud af, om du overhovedet har brug for en.
RTL ødelægger alt
Din brugerflade er ikke designet til arabisk, hebraisk eller urdu
Du satte dir=»rtl« på og så dit layout eksplodere:
Hvad jeg har set:
- Designsystemer med mere end 200 komponenter, hvor kun 12 håndterer RTL korrekt
- Teams der bruger float: left i stedet for logiske egenskaber og dermed skaber RTL-fejl i hver ny funktion
- Popovers og modaler der kræver komponentspecifikke RTL-tilpasninger
- Frameworks, der påstår at have »RTL-support«, men kun spejlvender layoutretningen og ødelægger placeringslogikken
Det hjælper jeg med:
- Migrering til logiske CSS-egenskaber (margin-inline-start i stedet for margin-left)
- Designsystemaudits der finder RTL-landminer, før de sendes i produktion
- Frameworkspecifik vejledning (Tailwind, shadcn, MUI) til RTL-first styling
At rette RTL-fejl manuelt i hver eneste komponent er uholdbart. Jeg gør RTL-support systematisk – ikke til en konstant brandslukningskamp.
»Den tyske tekst ødelagde vores knap«
UI der ikke var bygget til oversættelse
Engelsk passer. Tysk gør det ikke. Dit design antog:
Så oversatte du til tysk, finsk eller thai og opdagede:
Knapper afskåret midt i et ord
Tabeller med vandret scroll på hver række
Tekst, der ombrydes til ulæselige blokke
Ikke-latinsk tekst bliver afkortet, fordi containere har faste bredder
Det hjælper jeg med:
- Fleksible UI-mønstre, der tilpasser sig indholdslængden
- Planlægning af tegnbudget (velvidende at tysk udvider med 30 %, og thailandsk ikke bruger mellemrum)
- Typografisystemer, der håndterer CJK, arabisk og devanagari uden at gå i stykker
Jeg hjælper dig med at bygge en brugerflade, der overlever oversættelse, før du har betalt for 10.000 ord, der ikke passer.
Du har ikke brug for en forelæsning om, hvorfor i18n er vigtigt. Du har brug for en, der har debugget RTL-popovers klokken 2 om natten, diskuteret med produktteamet om tegnbudgetter og designet oversættelsespipelines, der rent faktisk virker.
Faldgruberne ingen advarede dig om
Krigshistorier fra teams, der har prøvet det
Det her er ikke teoretisk. Det er ting, der gik galt i produktion:
Flertalshelvede
Engelsk: »1 element« vs. »2 elementer«
Polsk: »1 przedmiot« / "2 przedmioty" / »5 przedmiotów« (3 flertalsformer)
Arabisk: 6 flertalsformer
Din count === 1 ? 'item' : 'items'-logik virker ikke længere.
Dato/tid-kaos
Du formaterede datoer med toLocaleDateString(). Så så brugere i Japan »2025年2月9日« i dine CSV-eksporter, og Excel gik i stå.
Uoverensstemmelse i API-sprog
Din frontend anmoder om fransk. Din API returnerer engelsk, fordi auth-tokenet ikke medsender locale. Nu har du en brugerflade med blandede sprog, og brugerne tror, det er en fejl.
Pseudolokalitetstest
Du testede ikke med [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] inden du gik i produktion. Nu er din polske side ubrugelig.
Den usynlige antagelse
Du antog, at strenge er det eneste, der skal oversættes. Så stødte du på datoer, tal, valutaer, sortering, søgning – alt har lokalespecifik adfærd.
Det hjælper jeg med:
- ICU MessageFormat-implementering (håndterer flertalsformer, køn og kontekst)
- API i18n-mønstre (sprogforhandling, fallback-strategier)
- QA-processer, der fanger disse problemer, før oversættelsesbureauerne gør
Arbejdsgangen er det svære
Hvordan holder du 8 sprog synkroniseret, når du releaser dagligt?
Du har styr på teknologien. Nu sidder du fast i processen:
Udviklere merger kode med nye engelske strenge. Oversættelserne halter 2 uger bagefter. Brugerne ser en halvoversat brugerflade.
Du ved ikke, hvilke strenge det er sikkert at slette (bruges de? er de oversat? er de undervejs hos et bureau?)
Produkt vil opdatere teksten. Ingen ved, om det at ændre »Submit« til »Send« vil påvirke 12 sprog.
Oversættelsesfiler, der i ugevis er ude af synkronisering med produktion
Spørgsmål teams stiller mig:
Hvad jeg har set gå galt:
- Oversættelsesfiler tjekket ind i git, som afviger fra produktionsstrengene
- »Rør ikke den spanske fil«-advarsler, fordi ingen ved, hvad man trygt kan ændre
- Funktioner lanceret på engelsk, derefter oversat 6 måneder senere (hvis overhovedet).
Det hjælper jeg med:
- Design af oversættelsespipeline (hvornår man bør bruge i18n-biblioteker, hvornår man bør bruge TMS, og hvornår man bør bruge AI)
- Git-arbejdsgange til at holde kildestrenge og oversættelser synkrone
- Automatisering der blokerer PR'er, hvis nye strenge ikke er markeret til oversættelse
Teknologien kan løses. Arbejdsgangen er flaskehalsen. Jeg designer arbejdsgange, der ikke kræver heltegerninger at vedligeholde.
Teams jeg har arbejdet med
Global-produkter, regional ekspertise
LINE (Japan, Taiwan, Thailand)
Beskedplatform med aktivitet på tværs af 3 primære østasiatiske markeder. Arbejdede med udfordringer knyttet til håndtering af CJK-tegn, integration med platformens økosystem og forskelle i brugeroplevelsesforventninger mellem Japan, Taiwan og Thailand.
KakaoTalk (Sydkorea)
Koreas dominerende beskedplatform. Håndterede produktkrav specifikt for det koreanske marked, herunder forventninger til sproglig formalitet i brugerfladen og behov for platformintegration.
Change.org (196 lande, mere end 20 prioritetssprog)
Global-underskriftsplatform, hvor både indholdshastighed og kvalitet er afgørende. Hjalp med at tilrettelægge oversættelsesarbejdsgangen for brugergenereret politisk/socialt indhold på tværs af forskellige markeder.
Airbnb (mere end 220 lande, mere end 60 sprog)
Global-markedsplads med komplekse i18n-krav. Rådgav om udfordringer med tillid og sikkerhed på flere sprog samt kulturel tilpasning af platformkoncepter på tværs af markeder.
Intercom (mere end 30 sprog, global B2B SaaS)
Kundekommunikationsplatform, der betjener globale virksomhedskunder. Arbejdede med produktinternationalisering af realtids-supportværktøjer og lokalisering af vidensbase.
Lilith Games (Kina, Japan, Korea, USA, EU)
Mobilspiludgiver med titler distribueret globalt. Løste markedsspecifikke udfordringer med indholdslokalisering og regionale platformkrav.
Markeder, jeg har lanceret i:
Østasien (Japan, Korea, Kina):
CJK-typografi, integration med platformsøkosystemer, understøttelse af lodret tekst
Sydøstasien (Thailand, Vietnam, Indonesien):
Understøttelse af flere skriftsystemer, mobilførst-brugerforventninger
MENA (arabisktalende regioner):
RTL-layoutkrav, forventninger til formelt kontra dagligdags sprog, kulturel indholdstilpasning
Europa:
24 officielle sprog, produktlanceringer i flere lande
Amerika:
Regionale sprogvariationer (latinamerikansk spansk vs. spansk fra Spanien, brasiliansk portugisisk), tosproget marked
Jeg har set, hvad der virker, og hvad der fejler på disse markeder – ikke baseret på teori, men på at levere produkter, som rigtige brugere er afhængige af.
Lad os rette det, der går i stykker
Du har ikke brug for en forelæsning om, hvorfor i18n er vigtigt. Du har brug for en, der har debugget RTL-popovers klokken 2 om natten, diskuteret med produktteamet om tegnbudgetter og designet oversættelsespipelines, der rent faktisk virker.
Arkitektur- og strategigennemgang (1-2 uger):
Jeg fortæller dig, hvad der går i stykker, når du tilføjer de næste 3 sprog, og hvad det vil koste at rette op på
Support til markedslancering (4-8 uger):
Du lancerer i Japan/MENA/EU og har brug for eksperter, der har gjort det før
Løbende partnerskab:
Integreret rådgivning, mens du skalerer fra 2 sprog til 20
Jeg laver ikke teori. Jeg laver triage, roadmaps og shipper.