I AI’ens tidsalder lancerer produktteams hurtigere end nogensinde—men lokalisering er ikke den egentlige flaskehals. Det virkelige problem er, at de fleste teams stadig bygger til en engelsksproget verden og behandler lokalisering som et oprydningstrin til sidst.
Teams afgrænser funktioner på engelsk, skriver brugerhistorier på engelsk, tester på engelsk og bevæger sig frem mod lanceringen i den antagelse, at oversættelse er en hurtig opfølgende opgave. Så rammer virkeligheden: Hele brugersegmenter kan ikke bruge det, der er blevet bygget, på meningsfuld vis. Undersøgelser viser, at 76 % af brugerne foretrækker produkter på deres eget sprog, og kun 67 % vil acceptere oplevelser med blandede sprog. Det hul er ikke et oversættelsesproblem—det er en fejl i produktdesignet.
Du ser det overalt. Notifikationer på iPhone er en klassisk fælde: Teams lokaliserer appen, men notifikationerne går i stykker, fordi ingen har taget højde for tysk tekstudvidelse eller kinesisk tekstforkortelse. Det samme sker ved betalt brugeranskaffelse. Engelsk annoncetekst passer perfekt—indtil den udvides i oversættelsen og bliver afvist af Google eller Meta på grund af tegnbegrænsninger.
Det her er ikke et værktøjsproblem. Det er et arbejdsgangsproblem.
AI-oversættelse har øget hastigheden og sænket omkostningerne, men den løser ikke en proces, der aldrig blev designet til globale brugere til at begynde med. Teams, der rent faktisk bevæger sig hurtigt globalt, oversætter ikke bare hurtigere—de integrerer lokalisering i den måde, produkter designes, testes og lanceres på fra dag ét.
Sådan ser det ud i praksis.
1. Forbind dit kodelager for at udløse automatisk oversættelse
Problemet: Udviklere sender kode med nye UI-strenge, og uger senere husker nogen at udtrække dem til oversættelse. Når oversættelserne kommer tilbage, er funktionen allerede lanceret på markeder, hvor kun engelsk understøttes, og de internationale teams arbejder ud fra en forældet version.
Løsningen: Forbind din lokaliseringsplatform direkte til GitHub, GitLab eller Bitbucket, så oversættelsesarbejdsgange udløses ved hver kodeændring. Når en udvikler committer ændringer, der indeholder nye oversættelige strenge, udtrækker systemet dem automatisk, sender dem til AI-oversættelse og returnerer de færdige oversættelser som en pull-anmodning.
Sådan implementerer du det:
- Brug din lokaliseringsplatforms indbyggede GitHub-integration til at forbinde grene
- Konfigurer systemet til at registrere nye strenge i ressourcefiler (JSON, YAML, gettext PO)
- Opsæt webhook-meddelelser, der giver dit team besked, når oversættelserne er klar
- Kortlæg dit kildesprog til målsprog (f.eks. en-US → fr-FR, de-DE, ja-JP)
Det skal du holde øje med: Ikke alle strenge skal oversættes med det samme. Konfigurer regler til at udelukke fejlfindingsmeddelelser eller eksperimentelle funktioner, der stadig er skjult bag funktionsflag. Angiv oversættelsesprioriteter baseret på udgivelsesplaner. Kritiske UI-strenge kan sendes direkte til AI-oversættelse, mens markedsføringstekst kan kræve menneskelig gennemgang. Jeg taler med kunder hver dag for at hjælpe dem med at afgøre, hvad der kræver menneskelig opmærksomhed, og hvad AI kan håndtere; vilkår og betingelser, privatlivspolitikker og alt med juridiske konsekvenser bør altid gennemgås af et menneske.
Målepunkter, du bør følge: Tiden fra kodecommit til oversat pull-anmodning (sigt efter under 24 timer) samt procentdelen af udgivelser, der lanceres samtidigt på alle sprog. Med den rette automatisering på plads kan teams lancere på markant flere sprog på én gang, end de kunne, da størstedelen af processen var manuel.
Have an account? Log In
2. Design med realistisk oversat indhold fra dag ét
Problemet: Designere tester grænseflader med Lorem Ipsum eller kort engelsk pladsholdertekst. Når den faktiske tyske oversættelse kommer tilbage 30 % længere, går knapper i stykker, navigationen ombrydes uhensigtsmæssigt, og hele layoutet skal bygges om. Jeg har set dette afspore lancering efter lancering. Et team lancerede en funktion til "glemt adgangskode" på svensk, hvor linket blev afskåret i notifikationen efter oversættelsen, så brugerne blev låst ude af hele appen.
Løsningen: Brug AI til at generere realistiske oversættelser direkte i dine designværktøjer under prototypingsfasen. Tysk tekst bliver 20-30 % længere, russisk 15 %, mens nogle asiatiske sprog bliver kortere. Når du designer med denne variation fra starten, tvinger det dig til at træffe bedre layoutbeslutninger, som kommer alle brugere til gode.
Sådan implementerer du det:
- Forbind dit designværktøj (Figma, Sketch, Adobe XD) med din lokaliseringsplatforms udvidelse
- Generer prøveoversættelser til dine målsprog, når du opretter designs
- Test layouts med den længst forventede udvidelse (typisk tysk eller finsk)
- Byg fleksible beholdere og dynamisk tekststørrelse i stedet for elementer med fast bredde
Det skal du holde øje med: Antallet af tegn er ikke den eneste faktor. Nogle sprog, f.eks. arabisk eller hebraisk, læses fra højre mod venstre og kræver spejlvendte layouts. Japansk og kinesisk kræver ofte større skriftstørrelser for at være lette at læse. Test disse variationer tidligt.
Målepunkter at følge: Antallet af layoutrettelser efter lancering pr. sprog, procentdelen af UI-komponenter, der fungerer på alle sprog uden ændringer.
3. Indbyg kvalitetstjek af oversættelser i din CI/CD-pipeline
Problemet: Oversættelser leveres med ødelagte variabler, manglende formateringsmærker eller strenge, der overskrider tegnbegrænsninger. Disse problemer opdages først i produktionen, når brugerne møder fejlmeddelelser eller ødelagte brugerflader.
Løsningen: Automatisér kvalitetssikringen ved at integrere validering af oversættelser i din pipeline for kontinuerlig integration. AI kan kontrollere oversættelser i forhold til din brandordliste, markere potentielle problemer og sikre, at tekniske elementer som variabler og HTML-tags forbliver intakte.
Sådan implementerer du det:
- Tilføj validering af oversættelser som et trin i din CI/CD-pipeline sammen med statisk analyse og enhedstests
- Konfigurér automatiserede kontroller for manglende variabler (%s, {username}), ødelagte HTML-tags, overskredne tegnbegrænsninger og overtrædelser af ordlisten
- Opsæt AI-drevet efterredigering for automatisk at rette mindre problemer med brandkonsistens
- Opret fejltilstande; byggeprocessen gennemføres ikke, hvis kritiske strenge indeholder fejl
Det skal du holde øje med: Automatisér ikke kvalitetskontrollerne for meget. AI kan opdage tekniske fejl, men kulturel passendehed og følelsesmæssig tone kræver stadig menneskelig vurdering i indhold med store konsekvenser, f.eks. juridisk sprog eller medicinsk information. Brandnavne fortjener også særlig opmærksomhed. Vi arbejder med en række kunder, hvis navne er almindelige navneord.
Uden ordentlige sikkerhedsforanstaltninger vil AI-oversættelsessystemer behandle dem som almindelige ord i stedet for brands, hvilket fuldstændigt ændrer betydningen af sætningerne. Heldigvis vil systemet, hvis du har opsat brandterminologien korrekt, før du bruger AI til at oversætte, fange de fleste af disse problemer, før de når produktionen.
Målepunkter at følge: Antallet af oversættelsesfejl, der opdages før udgivelse, sammenlignet med efter udgivelse, samt procentdelen af oversættelser, der består automatiseret kvalitetssikring i første forsøg.
4. Brug AI til løbende international test
Problemet: Kvalitetssikringsteams tester den engelske version grundigt, men internationale versioner får højst overfladiske stikprøver. Problemer som afkortet tekst, forkerte datoformater eller fejl i valutaomregningen slipper igennem, fordi der ikke findes nogen systematisk måde at teste alle lokaliteter på.
Løsningen: Moderne AI-oversættelse er pålidelig nok til test- og valideringsarbejdsgange. Generér testindhold på flere sprog, kør automatiserede brugerfladetests med oversatte strenge, og opdag internationaliseringsproblemer, før de udvikler sig til dyre genopbygninger.
Sådan implementerer du det:
- Udvid dine eksisterende testsuiter, så de køres mod flere lokaliteter og ikke kun engelsk
- Brug AI til at generere testdata (brugernavne, adresser, produktbeskrivelser) på målsprogene
- Test formularvalidering med internationale telefonnumre, postnumre og specialtegn
- Kør visuelle regressionstests for at opdage layoutproblemer, når tekstlængden ændrer sig
Det skal du holde øje med: Nogle internationaliseringsfejl opstår kun ved bestemte sprogkombinationer. Test sprog med forskellige egenskaber: meget lange ord (tysk), højre-til-venstre-tekst (arabisk), ikke-latinske tegn (kinesisk) og særlige diakritiske tegn (vietnamesisk).
AI har også begrænsninger baseret på de tilgængelige træningsdata. Oversættelser til engelsk, spansk og kinesisk er ofte stærke, fordi der findes rigeligt onlineindhold på disse sprog. Men når du oversætter til russisk eller andre mindre udbredte sprog, har LLM'en måske ikke nok kontekst til at producere pålidelige oversættelser. Det er vigtigt at overveje, hvordan du vil verificere kvaliteten eller opdage hallucinationer, især når du ikke har modersmålstalende på teamet.
Målepunkter at følge: Antallet af internationaliseringsfejl, der findes under test, sammenlignet med produktionen, samt testdækningen på tværs af lokaliteter.
5. Automatisér oversættelsen af dynamisk indhold
Problemet: Din app viser brugergenereret indhold, kundeservicesvar eller notifikationer i realtid, som ikke kan oversættes på forhånd. Før AI nåede sit nuværende kvalitetsniveau, var den bedste løsning ofte helt at undlade at oversætte UGC, fordi det ville have været for dyrt og ikke have levet op til kvalitetsstandarderne. Men det efterlader internationale brugere med en blanding af lokaliserede brugerfladeelementer og ikke-lokaliseret indhold, hvilket skaber en inkonsekvent oplevelse.
Løsningen: Brug API-baseret AI-oversættelse til dynamisk indhold, der skal oversættes efter behov. Opsæt intelligent mellemlagring, så ofte efterspurgte oversættelser hentes med det samme, mens nyt indhold oversættes næsten i realtid.
Sådan implementerer du det:
- Opret forbindelse til din lokaliseringsplatforms API for oversættelse efter behov
- Implementer intelligent caching – gem oversættelser af almindelige fraser og hyppigt anvendt indhold
- Opsæt fallback-logik: Hvis en oversættelse ikke er gemt i cachen, skal du anmode om en AI-oversættelse og returnere resultaterne på under et sekund
- Brug oversættelseshukommelse for at opretholde konsistens
Vær opmærksom på: API-baseret oversættelse medfører latenstid og omkostninger. Optimer ved at samle anmodninger i batches, cache så effektivt som muligt, og oversæt kun det indhold, som brugerne faktisk anmoder om. Overvåg omhyggeligt din brug af oversættelses-API'et.
Målepunkter, der skal følges: API-svartid for oversættelsesanmodninger, cache-hit-rate og omkostning pr. tusind oversatte tegn. Nu hvor AI pålideligt kan oprette nye oversættelser baseret på tidligere indhold, er lokalisering af dynamisk indhold faktisk mulig inden for budgetbegrænsningerne.
More Articles
Sådan får du det til at fungere
Disse fem tilgange fungerer bedst, når de implementeres i rækkefølge. Start med at forbinde dit kodelager for at etablere den grundlæggende automatiseringspipeline. Når den er stabil, kan du tilføje oversættelser og kvalitetstjek på designtidspunktet. Udvid derefter til international testning, og håndter til sidst dynamisk indhold.
Lokalisering er ikke en efterbehandling – den bør være integreret i arbejdsgangen.
Lyft er et godt eksempel på, hvordan dette ser ud i praksis. De ønskede at udvide deres app ud over engelsk og var allerede begyndt med spansk, men havde flere sprog på den umiddelbare køreplan. Problemet var mængden – teamet kunne se oversættelsesarbejdet vokse hurtigere, end de kunne bemande det, eftersom driften i høj grad var manuel. De stod over for et valg mellem at udvide teamet eller udnytte AI til at gøre arbejdsgangene mere effektive.
De valgte automatisering, og vi arbejdede sammen med Lyft om at redesigne lokaliseringsarbejdsgangene og automatisere oversættelsen af web-, app-, hjælpecenter- og udviklermateriale i realtid. De implementerede Smartlings platform med en forudbygget Contentful-integration, som gjorde det muligt at opsætte automatiserede arbejdsgange på tværs af alle deres indholdstyper og eliminere de fleste af de manuelle overdragelser, der forsinkede dem.
Resultatet var en reduktion på 50 % i tiden til implementering af nyt indhold, og Lyft leverede hele appoplevelsen på otte nye sprog uden at justere køreplanen eller ansætte flere teammedlemmer.
Når lokalisering bliver en del af de processer, du allerede er fortrolig med, bliver global ekspansion en konfigurationsændring i stedet for en omskrivning af projektet.
Hvad produktchefer skal gøre anderledes
Dette skifte kræver, at teams ændrer deres opfattelse af, hvad det vil sige at være "færdig". Det er ikke nok at levere funktioner, der fungerer i dit udviklingsmiljø. De skal fungere i de miljøer, hvor dine brugere faktisk befinder sig.
Produktchefer skal medtage internationale hensyn i definitionerne af brugerhistorier. Designere skal lave prototyper med realistisk oversat indhold. Ingeniører skal bygge systemer, der ikke bryder sammen, når indhold ændrer længde eller retning.
De produkter, der vinder globalt, er dem, der er designet globalt fra starten. Værktøjerne findes. Spørgsmålet er, om dit team vil fortsætte med at designe til en engelsksproget verden eller begynde at bygge til det globale marked, som I allerede forsøger at betjene.
