Internationaliseringskonsultation: Fixa det som inte fungerar, planera vad som kommer härnäst
Du vet redan att i18n är svårt. Jag har sett symptomen: RTL-layouter som kollapsar, tysk text som svämmar över knappar, API-svar på fel språk och översättningar som tappar synkroniseringen inom veckor efter lansering. Jag säljer inga mirakelkurer. Jag hjälper dig att reda ut den specifika röran ditt team befinner sig i – och bygga system som inte går sönder på samma sätt igen.
"Vi borde ha planerat detta tidigare"
Arkitekturskatten du betalar nu
Du lanserade på engelska. Det fungerade. Sedan lade du till franska "bara för startsidan". Nu är du här för att:
Din kodbas har lang=-kontroller spridda över 47 filer
Produktchefer frågar 'kan vi A/B-testa text?' och teknikavdelningen svarar 'inte utan en omskrivning'.
Du har tre olika översättningsarbetsflöden och inget av dem fungerar tillförlitligt
Vad jag har sett gå sönder:
- Team som lägger över 6 månader på att i efterhand införa i18n i en Next.js-app eftersom strängar var hårdkodade i komponenterna
- Översättningsfiler som hamnar ur synk eftersom utvecklare inte vet vilken fil de ska uppdatera
- "Lokaliseringsstopp" innan releaser eftersom ingen litar på översättningskedjan
- Motstånd mot att ändra översatt innehåll eftersom arbetsflödet är så smärtsamt
Vad jag kan hjälpa till med:
- Refaktoriseringsstrategier så att du kan införa i18n stegvis (jag kräver inte "stoppa allt och skriv om")
- Processutformning för att hålla översättningar synkroniserade utan att blockera utveckling
- Arkitekturgranskningar för att identifiera var din nuvarande metod kommer att brista vid 10+ språk
i18n är arkitektur, inte en funktion. Att försöka lägga till det i efterhand är som att bestämma att ditt hus behöver en källare efter att det redan är byggt.
Jag hjälper dig gräva den källaren – eller avgöra om du verkligen behöver en.
RTL förstör allt
Ditt gränssnitt designades inte för arabiska, hebreiska eller urdu
Du ändrade till dir="rtl" och såg din layout explodera:
Vad jag har sett:
- Designsystem med över 200 komponenter där bara 12 hanterar RTL korrekt
- Team som använder float: left istället för logiska egenskaper, vilket skapar RTL-buggar i varje ny funktion
- Popovers och modaler som kräver komponentspecifika RTL-överstyrningar
- Ramverk som påstår sig ha "RTL-stöd" men som bara spegelvänder layoutriktningen och förstör placeringslogiken
Vad jag kan hjälpa till med:
- Migrering till logiska CSS-egenskaper (margin-inline-start istället för margin-left)
- Granskningar av designsystem för att hitta RTL-minor innan de släpps
- Ramverksspecifik vägledning (Tailwind, shadcn, MUI) för RTL-först-styling
Att manuellt åtgärda RTL-buggar i varje komponent är ohållbart. Jag gör RTL-stödet systematiskt, inte en ständig brandkårsutryckning.
"Den tyska texten bröt vår knapp"
Gränssnitt som inte byggdes för översättning
Engelska passar. Tyska gör det inte. Din design förutsatte:
Sedan översatte du till tyska, finska eller thailändska och upptäckte:
Knappar som kapas mitt i ord
Tabeller med horisontell rullning på varje rad
Text som radbryts till oläsbara block
Icke-latinsk text klipps av eftersom behållare har fasta bredder
Vad jag kan hjälpa till med:
- Elastiska UI-mönster som anpassar sig efter innehållslängden.
- Teckenbudgetplanering (att veta att tyska expanderar 30 %, thailändska inte använder mellanslag)
- Typografisystem som hanterar CJK, arabiska och devanagari utan att gå sönder
Jag hjälper dig bygga gränssnitt som överlever översättning – innan du har betalat för 10 000 ord som inte passar.
Du behöver ingen föreläsning om varför i18n är viktigt. Du behöver någon som har felsökt RTL-popovers klockan 02:00 på natten, diskuterat teckenbegränsningar med produktteam och utformat översättningsflöden som verkligen fungerar.
Fallgropar som ingen varnade dig för
Berättelser från skyttegravarna – team som har varit med
Det här är inte teoretiskt. Det här är saker som gick sönder i produktion:
Pluraliseringshelvetet
Engelska: "1 item" kontra "2 items"
Polska: "1 przedmiot" / "2 przedmioty" / "5 przedmiotów" (3 pluralformer)
Arabiska: 6 pluralformer
Din logik med count === 1 ? 'item' : 'items' fungerar inte längre.
Kaos med datum och tid
Du formaterade datum med toLocaleDateString(). Sedan såg användare i Japan "2025年2月9日" i dina CSV-exporter och Excel strulade.
Språkkonflikt i API
Din frontend begär franska. Ditt API returnerar engelska eftersom auth-tokenen inte bär med sig språkinställningen. Nu har du ett gränssnitt med blandade språk och användarna tror att det är en bugg.
Testning med pseudospråk
Du testade inte med [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] innan du gick i produktion. Nu är din polska sajt oanvändbar.
Det osynliga antagandet
Du antog att strängar är det enda som behöver översättning. Sedan stötte du på datum, siffror, valutor, sortering, sökning – allt har lokalspecifikt beteende.
Vad jag kan hjälpa till med:
- ICU MessageFormat-implementation (hanterar pluralformer, genus, sammanhang).
- API i18n-mönster (språkförhandling, reservstrategier)
- QA-processer som fångar upp dessa problem innan översättningsbyråerna gör det
Arbetsflödet är den svåra biten
Hur håller du 8 språk synkroniserade när du lanserar dagligen?
Du har löst tekniken. Nu har du fastnat i processen:
Utvecklare slår ihop kod med nya engelska strängar. Översättningar släpar efter med 2 veckor. Användare ser halvöversatt gränssnitt.
Du vet inte vilka strängar som är säkra att ta bort (används de? Är de översatta? Ligger de hos en byrå?)
Produktteamet vill uppdatera texten. Ingen vet om att ändra "Submit" till "Send" kommer att sabba 12 språk.
Översättningsfiler ligger ur synk med produktionsmiljön i veckor i sträck
Frågor som team ställer till mig:
Vad jag har sett gå sönder:
- Översättningsfiler incheckade i git som avviker från strängarna i produktionsmiljön
- 'Rör inte den spanska filen'-varningar eftersom ingen vet vad som är säkert att ändra.
- Funktioner som lanserades på engelska och översattes sex månader senare (om ens någonsin)
Vad jag kan hjälpa till med:
- Utformning av översättningspipeline (när man ska använda i18n-bibliotek, TMS respektive AI)
- Git-arbetsflöden för att hålla källsträngar och översättningar synkroniserade
- Automatisering som blockerar PR:er om nya strängar inte är markerade för översättning
Tekniken går att lösa. Arbetsflödet är flaskhalsen. Jag utformar arbetsflöden som inte kräver hjältedåd för att underhålla.
Team jag har arbetat med
Globala produkter, regional expertis
LINE (Japan, Taiwan, Thailand)
Meddelandeplattform verksam på tre primära östasiatiska marknader. Arbetade med utmaningar relaterade till hantering av CJK-tecken, integration i plattformens ekosystem och användarupplevelser som varierar mellan Japan, Taiwan och Thailand.
KakaoTalk (Sydkorea)
Koreas dominerande meddelandeplattform. Hanterade koreaspecifika produktkrav, inklusive förväntningar på språklig formalitet i användargränssnittet och behov av plattformsintegration.
Change.org (196 länder, 20+ prioriterade språk)
Global plattform för petitioner där både snabbhet och kvalitet på innehållet spelar roll. Hjälpte till att utforma översättningsarbetsflödet för användargenererat politiskt och socialt innehåll på olika marknader.
Airbnb (220+ länder, 60+ språk)
Global marknadsplats med komplexa i18n-krav. Rådgav kring utmaningar gällande tillit/säkerhet på flera språk och kulturell anpassning av plattformskoncept på olika marknader.
Intercom (30+ språk, global B2B SaaS)
Kundkommunikationsplattform för globala företagskunder. Arbetade med produktinternationalisering för realtidssupportverktyg och lokalisering av kunskapsbaser.
Lilith Games (Kina, Japan, Korea, USA, EU)
Mobilspelsutgivare med globalt distribuerade titlar. Hanterade marknadsspecifika utmaningar kring innehållslokalisering och regionala plattformskrav.
Marknader jag har lanserat i:
Östasien (Japan, Korea, Kina):
CJK-typografi, integration med plattformsekosystem, stöd för vertikal text
Sydostasien (Thailand, Vietnam, Indonesien):
Stöd för flera skriftsystem och mobilanpassade användarförväntningar
MENA (arabisktalande regioner):
RTL-layoutkrav, formella kontra vardagliga språkliga förväntningar, kulturell innehållsanpassning
Europa:
24 officiella språk, produktlanseringar i flera länder
Amerika:
Regionala språkvariationer (latinamerikansk spanska vs. spanska från Spanien, brasiliansk portugisiska), tvåspråkiga marknader
Jag har sett vad som fungerar och vad som inte gör det på dessa marknader – inte utifrån teori, utan från att leverera produkter som riktiga användare litar på.
Låt oss fixa det som går sönder
Du behöver ingen föreläsning om varför i18n är viktigt. Du behöver någon som har felsökt RTL-popovers klockan 02:00 på natten, diskuterat teckenbegränsningar med produktteam och utformat översättningsflöden som verkligen fungerar.
Granskning av arkitektur och strategi (1–2 veckor):
Jag kan berätta vad som kommer att gå sönder när du lägger till dina nästa tre språk och vad det kommer att kosta att åtgärda
Stöd vid marknadslansering (4–8 veckor):
Du lanserar i Japan/MENA/EU och behöver experter som gjort det förut
Löpande partnerskap:
Löpande konsultstöd när du skalar från 2 språk till 20
Jag sysslar inte med teori. Jag prioriterar, planerar och levererar.