10 almindelige i18n-fejl og hvordan du undgår dem
Undgå dyre fejl i internationalisering. Lær de mest almindelige i18n-fejl, som udviklere begår, og hvordan du løser dem. Forbedr kvaliteten af lokaliseringen i din iOS-, Android- eller Web-app med disse bedste praksisser.
Internationale lokalisering (i18n) virker tilsyneladende enkel — indtil du opdager, at dine tyske brugere ser afkortede knapper, japanske brugere får ødelagte sætninger, og arabisk-sprogede brugere står over for helt ødelagte layout. Dette er ikke tilfældige tilfælde. Det er de forudsigelige konsekvenser af almindelige fejl, som de fleste udviklingsteams begår, når de først beskæftiger sig med lokalisering. I denne guide gennemgår vi de 10 mest almindelige i18n-fejl, forklarer præcist hvorfor de opstår, og viser dig trin for trin, hvordan du løser hver enkel. Uanset om du bygger en ny app eller opgraderer en eksisterende — at undgå disse faldgruber vil spare dig for uger af debugging.
Fejl nr. 1: hårdkodede strenge
Hardkodede strenge er den mest grundlæggende i18n-fejl. Det sker, fordi udviklere fokuserer på at få funktioner til at køre først og planlægger at 'rydde op senere'. Men senere kommer aldrig, og pludselig har du tusindvis af strings fordelt på hundredvis af filer.
['Rigtig dit i18n-rammeværk, før du skriver den første UI-linje', 'Brug et linting-plugin til at opdage hardkodede strenge i skabeloner og komponenter', 'Hold oversættelses-nøgler beskrivende og organiser dem efter funktion eller side']
Configurer dit i18n-rammeværk, før du skriver den første række UI-kode.
Brug et linter-Plugin for at detect hardkodede strings i templates og komponenter.
Giv oversættelsesnøglerne en beskrivende navngivning og organiser dem efter funktion eller side.
Et typisk scenarie
En udvikler skriver en knap-etiket direkte i JSX: <button>Submit Order</button>.
Appen leveres på engelsk og fungerer fejlfrit. Seks måneder senere ekspanderer virksomheden til Tyskland.
Lokaliseringsteamet opdager 2.000+ hardkodede strenge. Eftermontering varer 3 uger og forårsager 47 fejl.
Hvorfor er det et problem
I en moden Codebase kan hardkodede tekststrenge nå tusindvis af forekomster. At udtrække dem bagefter kræver berøring af hver enkelt fil, gen-test af hver komponent og risiko for regressioner overalt.
Hardkodede strenge er direkte indlejret i kildekoden, templates eller komponenter. De kan ikke ekstraheres, oversættes eller udskiftes ved kørsel uden at ændre selve koden.
Brugere i ikke-engelske lokalisationer ser ikke-oversatte brugergrænsefladeelementer blandet med oversat indhold — et kaotisk og uprofessionelt indtryk.
Så her er, hvordan du løser det
Eksternaliser alle brugervenlige strenge fra starten i ressourc-filer.
Opsæt et oversættelsesrammeværk (f.eks. next-intl, react-i18next, vue-i18n), før du skriver din første komponent.
Opret en struktur til ressourcer (f.eks. messages/da.json) og henvis til alle strenge gennem oversættelsesnøgler som t('checkout.submitButton').
Tilføj en linting-regel eller en pre-commit-hook, der markerer rå streng-literal i UI-komponenter.
Fejl nr. 10: At oversætte alting ordret.
Ikke alt indhold bør oversættes. Brandnavne, firmanavne, tekniske termer og bestemte produkternavne skal forblive på originalsproget. Overoversættelse kan medføre retlige problemer, mærkeinkonsistens og forvirring for brugerne.
["Opbevar et 'Ikke oversæt'-glossar og del det med alle oversættere", 'Brug lukkede segmenter eller separate navnerum til mærke- og juridiske begreber', 'Giv altid kontekstnoter til tvetydige strenge for at forhindre fejloversættelser']
Udarbejd en 'Ikke oversæt'-ordbog og del den med alle oversættere.
Brug låste segmenter eller separate navnespaces for varemærke- og juridiske termer.
Giv altid kontekstnoter til tvetydige strenge for at forhindre fejltolkninger.
Et typisk scenarie
En oversættelsesfil indeholder firmanavnet 'CloudForge Inc.' og det tekniske udtryk 'OAuth 2.0 Token' som almindeligt oversættelige strings.
Den spanske oversætter oversætter 'CloudForge' til 'ForjaNube' og 'OAuth 2.0 Token' til 'ficha OAuth 2.0'.
Resultatet: Brugere finder ikke virksomheden under dens rigtige navn, og udviklerne, der læser den spanske dokumentation, er forvirrede af ukendte oversatte tekniske termer.
Hvorfor er det et problem
Et enkelt forkert oversat mærkenavn i et juridisk dokument kan gøre kontrakter ugyldige. Korrigering af oversættelser i overmålet kræver at gennemgå hver streng i hvert sprog — en opgave på flere uger.
Når alle strengene sendes uden kontekst til oversættelse, kan oversættere muligvis oversætte mærker ('Apple' → 'Apfel'), juridiske termer ('GmbH' → 'LLC') eller tekniske betegnelser, der skal forblive på engelsk.
Brugere finder ikke produkter under deres kendte mærke, juridiske dokumenter refererer til forkert selskab, og teknisk dokumentation bliver uklar, hvis termer som 'API Endpoint' oversættes.
Sådan retter du det
Marker tydeligt ikke-oversættelige indhold og giv kontekstnoter til oversættere.
Lav et 'Ikke oversæt'-glossar, der opremser alle mærkenavne, produknavne, juridiske enheder og fagtermer, der skal forblive uændrede.
Brug en separat navnerum eller særlige nøgler til ikketranslatable indhold. Mange i18n-værktøjer understøtter 'låste' segmenter, som oversættere ikke kan redigere.
Tilføj oversætterkommentarer/beskrivelser til dine oversættelsesfiler, der forklarer konteksten: 'Dette er et varemærkenavn — oversæt ikke' eller 'Fagterm — forbliv på engelsk'.
Fejl nr. 2: strengsammenkædning
Sætninger sammensat af fragmenter virker på engelsk logiske, men på andre sprog varierer sætningsrækkefølgen, grammatikken og sætningsstrukturen markant, hvilket gør kædede strenge ikke-sammenhængende at oversætte.
['Byg aldrig sætninger ved at kæde oversatte fragmenter sammen', 'Brug navngivne pladsholdere ('{name}') i stedet for positionelle ({0}) for klarhed', 'Giv kontekstkommentarer til oversættere, der forklarer, hvad hver pladsholder indeholder']
Byg ikke sætninger ved at kæde oversatte fragmenter sammen.
Brug navngivne pladsholdere ('{name}') i stedet for positionelle ({0}) for klarhed
Giv kontekst-kommentarer til oversættere, der forklarer, hvad hver pladsholder indeholder
Et typisk scenarie
Udvikleren skriver: 'You have ' + count + ' items in your ' + cartType + ' cart' — fungerer perfekt på engelsk.
Den tyske oversætter får tre separate fragmenter og kan ikke danne en grammatisk korrekt sætning, fordi ordstillingen skal ændres.
Resultat: Tyske brugere ser 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — klodset og uprofessionelt.
Hvorfor er det et problem
Hver kædet streng er en tikken tidsbombe. Ved 20 sprog og 50 kædede strenge har du 1.000 potentielle grammatiske fejl, som skal rettes manuelt.
Sammenkædning af strenge som 'Willkommen ' + userName + ', du har ' + count + ' nye beskeder' kræver en bestemt ordstilling. Oversættere modtager sammenhængsløse fragmenter, som ikke kan omarrangeres.
Brugere oplever grammatiske fejl i sætninger. På tysk står verbet ofte til sidst. På arabisk er hele strukturen vendt om. Resultatet læses som vrøvl.
Sådan retter du det
Brug parametrede beskeder med navngivne pladsholdere, så oversættere kan omorganisere hele sætningen.
Erstat kædning med en enkelt beskednøgle med pladsholdere: 'cart.summary': 'Du har {count} varer i din '{cartType}'-kurv'.
Overgiv variabler som parameter til din oversættelsesfunktion: t('cart.summary', { count: 5, cartType: 'Premium' }).
Oversættere kan nu frit omarrangere: 'Din '{cartType}'-kurv indeholder {count} varer' — grammatisk korrekt tysk.
Fejl nr. 3: Ignorerer Pluralformen
Engelsk har to former for flertal: ental og flertal. Udviklere antager ofte, at alle sprog fungerer ens. Det gør de ikke. Polsk har 4 former, arabisk har 6, og endda sprog som fransk behandler nul på en anden måde end engelsk.
['Brug altid ICU MessageFormat eller et tilsvarende bibliotek til tællelige indhold', 'Skriv aldrig din egen plural-logik — stol på CLDR-reglerne', 'Test flertalsformer med værdier som 0, 1, 2, 5, 21 og 100 for at dække alle kategorier']
Brug altid ICU MessageFormat eller et tilsvarende bibliotek til tælleligt indhold
Skriv aldrig din egen flertalslogik — stol på CLDR-reglerne.
Test flertals med værdier som 0, 1, 2, 5, 21 og 100 for at dække alle kategorier.
Et typisk scenarie
Udvikleren skriver: count + (count === 1 ? ' Datei' : ' Dateien') — behandler tysk korrekt.
Polsk oversætter har brug for 4 former: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. Den enkle ternære kan ikke udtrykke det.
Resultat: Polske brugere ser '5 pliki' (forkert form) i stedet for '5 plików' (korrekt form), og appen virker som om den er defekt.
Hvorfor er det et problem
Hvert tælleligt substantiv i din app kræver pluralhåndtering. Ved 50 sådanne strenge og 20 sprog er der 1.000 regler for flertal — umuligt at administrere manuelt.
Enkle if/else-kontroller (count === 1 ? 'Datei' : 'Dateien') behandler kun tysk/engelsk. CLDR definerer op til 6 plural-kategorier: zero, one, two, few, many og other. Hver sprog bruger en anden underkategorisering.
Brugere ser grammatisk forkert tekst som '1 Nachricht' eller helt forkerte pluralformer. I formelle sammenhænge undergraver det troværdigheden.
Sådan løser du det
Brug ICU MessageFormat, der understøtter alle CLDRs regler for flertal uden videre.
Definér beskeder med ICU-syntaks: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
Oversættere angiver alle nødvendige pluralformer til deres sprog. Polsk: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
Din i18n-bibliotek vælger ved kørsel automatisk den korrekte form ud fra CLDR-reglerne for den aktive locale.
Fejl nr. 4: Faste UI-element bredder
Designere skaber pixelfe-eksakte layouts på engelsk, og udviklerne implementerer dem med faste bredder. Men oversat tekst kan være dramatisk længere eller kortere. Tysk tekst er omkring 30% længere end engelsk, mens kinesisk tekst kan være 50% kortere.
['Brug aldrig faste pixelbredder på elementer med oversætteligt tekst', 'Planlæg 40% tekstforlængelse som baseline — nogle sprog udvider sig endnu mere', 'Brug CSS Flexbox eller Grid til layouts, der tilpasser sig varierende indholds længder']
Brug aldrig faste pixelbredder på elementer med oversættelig tekst.
Planlæg en baseline på 40% tekstforøgelse — nogle sprog udvider sig endnu mere.
Brug CSS Flexbox eller Grid til layouts, der tilpasser sig varierende indholdslængder.
Et typisk scenarie
Designeren laver en navigationslinje med 5 knapper, hver præcis 100 px bred — ser fantastisk ud på engelsk.
Tysk oversættelse: 'Settings' bliver til 'Einstellungen' (13 vs 8 tegn), 'Submit' bliver til 'Absenden' (8 vs 6). Navbar'en løber over.
Resultat: På mobilenheder stapper knapperne sig oven på hinanden, eller teksten bliver afskåret, hvilket gør navigationen ubrugelig for tyske brugere.
Hvorfor er det et problem
Hvert element med fast bredde er et potentielt brudpunkt. En typisk app har hundrevis af knapper, labels og cards, der alle skal kunne rumme tekstudvidelsen.
Beholdere med fast bredde (width: 120px) og knapper af fast størrelse klipper af eller ruller uden om, når teksten udvider sig. CSS overflow: hidden skjuler indholdet stille, mens overflow: visible ødelægger layoutet.
Brugere ser afklippede etiketter som 'Einstellu...' i stedet for 'Einstellungen', eller knapper der overlappes af nærliggende elementer. Kritiske handlinger bliver ulæselige eller ikke klikbare.
Sådan gør du det
Design og implementer fleksible layouts, der tilpasser sig indholdets længde i alle lokaliseringer.
Erstat faste bredder med min-width, max-width og Flex-layouts. Brug CSS Grid eller Flexbox til at fordele pladsen dynamisk.
Sæt tekstcontaineren til ombrydning: brug overflow-wrap: break-word og undgå white-space: nowrap for oversatte tekster.
Test dit UI med en pseudo-lokalisering, der forlænger alle strengene med 40% for at simulere worst-case — endnu før du sender strengene til oversættere.
Fejl nr. 5: dato- og talformat
Data og tal virker tilsyneladende universelle. Men 01/02/2025 betyder den 2. januar i USA og den 1. februar i Europa. Kommatering og decimaler ændrer betydning: 1,000.50 (USA) vs 1.000,50 (Tyskland). At gøre det forkert fører til forvirring, datafejl og tab af tillid.
['Formater aldrig data eller tal manuelt ved hjælp af streng-skabeloner — brug altid Intl-API', 'Gem alle data internt i ISO 8601 og valutaer i den mindste enhed (cents)', 'Test med lokationer der bruger forskellige decimaltegn, datorekkefølger og kalendersystemer']
Formater aldrig data eller tal manuelt ved hjælp af strengskabeloner — brug altid Intl-API'er.
Gem alle data i ISO 8601 og valuta i den mindste enhed (cent) internt.
Test med locale-indstillinger, der bruger forskellige decimaltegn, datoformater og kalendersystemer.
Et typisk scenarie
Udvikleren formaterer en dato som MM/DD/YYYY og en pris som $1,234.50 — korrekt for amerikanske brugere.
En tysk bruger ser datoen 03/04/2025 og læser den som 3. april (DD/MM/ÅÅÅÅ-konventionen). Prisen $1,234.50 ser ud til at skulle være 1.234,50.
Resultatet: Brugeren booker en flyrejse til den forkerte dato og stiller spørgsmål ved prisformatet. Support-sagerne stiger med 15% på det tyske marked.
Hvorfor er det et problem
Datums- og talformatet påvirker enhver datafremstilling i din app: tabeller, diagrammer, formularer, fakturaer, rapporter. En global løsning dækker hundredvis af forekomster.
Hårdkodede format strings som toLocaleDateString('en-US') eller manuel formatering med Template-Literals ignorerer brugerens faktiske locale. Selv den korrekte locale men det forkerte kalender-system (gregoriansk vs. hijri) forårsager problemer.
Brugere læser data forkert og indtaster data i forkert format. En europæisk bruger, der ser 03/04/2025, tolker måske som 3. april i stedet for 4. marts — misset aftaler eller forkerte booking.
Sådan løser du det
Brug den indbyggede Intl-API eller et lokalisationsbevidst formatbibliotek til alle datoer, tider, tal og valutaer.
Erstat manuel formatering med Intl.DateTimeFormat(locale) til datoer og tider og Intl.NumberFormat(locale, { style: 'currency', currency }) til priser.
Gem data internt i ISO 8601-format (YYYY-MM-DD) og formatter dem kun til visning med brugerens locale.
Test kritiske dato- og talvisninger med mindst 5 forskellige locales: en-US, de-DE, ja-JP, ar-SA og zh-CN for at dække de vigtigste formatteringsvarianter.
Fejl nr. 6: Glemt RTL-sprog
RTL-sprog som arabisk, hebraisk og persisk bruges af mere end 500 millioner mennesker. Samtidig er de fleste apps designet udelukkende til layoutet højre-til-venstre (RTL). RTL-understøttelse betyder ikke kun at vende teksten — hele brugergrænsefladen skal spejles.
['Fra første øjeblik af brug kun logiske CSS-egenskaber (inline-start/end, block-start/end)', "Test din app med dir='rtl' på HTML-Elementet ved hver sprint-gennemgang", 'Lav en RTL-tryk- checkliste til navigation, ikoner, formularer og fremskridt']
Brug fra første dag udelukkende logiske CSS-attributter (inline-start/end, block-start/end)
Test din app med dir='rtl' på HTML-elementet ved hver sprint-gennemgang.
Opret en RTL-testcheckliste til navigation, ikoner, formularer og fremdriftsindikatorer.
Et typisk scenarie
Udvikleren bruger margin-left: 16px og text-align: left gennem hele appen — standard-LTR-praksis.
Appen starter i Saudi-Arabien. Tilbage-pile viser fremad, sidebjælker vises på den forkerte side, og numeriske data er forkert justeret.
Resultatet: Arabiske brugere forlader appen efter 30 sekunder. Teamet har brug for 4 uger nød-CSS-omstrukturering for at løse problemet.
Hvorfor er det et problem?
RTL-understøttelse påvirker hver enkelt komponent i din app. At indføre RTL bagefter kræver normalt at omskrive 30-50% af alle CSS-regler og at gennemgå hver ikon og layout.
CSS-egenskaber som margin-left, padding-right, text-align: left og float: left hardcoder retningen. Ikoner med retningsbetyder (pile, fremskridtsindikatorer) viser i forkert retning. Selv border-radius-værdier skal spejles.
Arabiske brugere ser navigation i det forkerte hjørne, fremskridtsbjælker kører baglæns, og tekst kolliderer med UI-elementer. Appen føles fremmed og ubrugelig.
Sådan løser du det
Brug logiske CSS-egenskaber og test RTL-layoutet fra begyndelsen.
Erstat alle fysiske CSS-egenskaber med logiske ækvivalenter: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Sæt dir-attributten på dit HTML-rodelement baseret på den aktive locale. Brug CSS-pseudoklassen :dir(rtl) til RTL-specifikke overrides.
Tjek alle ikoner for retningsbetyder. Udskift retningbundet ikoner med spejlvendte versioner eller brug CSS transform: scaleX(-1) til RTL-sammenhænge.
Fejl nr. 7: Billeder med tekst
Tekst indeni billeder — i hero-bannere, knapper, infografikker eller screenshots — er et lokaliseringsmareridt. Hvert billede med tekst skal laves på ny for hvert sprog, hvilket øger designomkostningerne og forsinker udgivelserne.
['Bedre aldrig indsætte oversættelig tekst direkte i rasterbilleder (PNG, JPG)', 'Brug CSS-tekstoverlays på baggrundsbilleder til hero-bannere og CTA'er', 'Automatér genereringen af screenshots til App Store-lister og marketing-sider']
Indsæt aldrig oversat tekst direkte i rasterbilleder (PNG, JPG).
Brug CSS-tekstoverlays på baggrundsbilleder til hero-bannere og CTAs.
Automatisér genereringen af skærmbilleder til App Store-oversigter og markedsføringssider
Et typisk scenarie
En designer laver et promo-banner med teksten 'Start Your Free Trial' indlejret direkte i billedet.
Lokaliseringsteamet oversætter alle UI-strenge, men banneret viser stadig engelsk tekst på den tyske side.
Resultat: Den tyske landingsside har et irriterende engelsk banner. At lave lokaliserede bannere til 15 sprog kræver 3 dages designarbejde og forsinker lanceringen.
Hvorfor er det et problem?
Et typisk marketing-site har 5-10 billeder med tekst. Ved 15 sprog er det 75-150 billedvarianter, der skal oprettes, vedligeholdes og opdateres ved hver designændring.
Tekst, der er indlejret i billeder (PNG, JPG, SVG med indlejret tekst), kan ikke udtrækkes af oversættelsesværktøjer. Hver lokaliseret version kræver, at en designer manuelt redigerer kildefilen, eksporterer den og uploader den.
Brugere ser billeder med tekst på et fremmedsprog, eller endnu værre en blanding af oversat UI og ikke-oversatte billeder. Det virker inkonsekvent og undergraver tilliden til mærket.
Sådan løser du det
Adskil teksten fra billederne ved hjælp af CSS-overlays, SVG'er med oversættelige tekst-elementer eller dynamisk billedgenerering.
Brug CSS til at placere oversættelig tekst over baggrundsbillederne: placér tekstlaget med absolut positionering over billedcontaineren.
Til infografikker eller diagrammer, brug SVG'er med <text>-elementer, der refererer til oversættelsesnøgler, i stedet for at indsætte rå streng.
Til app-skærmbilleder i markedsføringsmaterialer automatiser generation af skærmbilleder ved hjælp af værktøjer som Fastlane (Mobil) eller Playwright (Web), der tager skærmbilleder i hver locale.
Fejl #8: Manglende oversættelser ikke håndteret
Oversættelserne er under udviklingen altid ufuldstændige. Nye funktioner tilføjer strengene hurtigere, end oversættere kan oversætte dem. Uden ordentlig fallback-logik forårsager manglende oversættelser nedbrud, tomme UI-elementer eller rå oversættelses-nøgler, der vises for brugeren.
['Konfigurer altid mindst et fallback-sprog i din i18n-opsætning', 'Log manglende oversættelseskoder til dit overvågningssystem til sporing', 'Sæt et minimums-oversættelsesdækning, før en locale må gå live']
Konfigurer altid mindst et fallback-sprog i dit i18n-setup.
Log manglende oversættelsesnøgler i dit overvågningssystem til sporing.
Angiv et minimums oversættelsesdækning, før en locale kan gå live.
Et typisk scenarie
Udvikleren tilføjer et nyt 'Premium Features'-område med 15 nye oversættelsesnøgler. Den engelske version leveres straks.
De franske oversættelser er endnu ikke færdige. Den franske side viser rå nøgler: 'premium.feature1.title', 'premium.feature1.description'.
Resultat: Franske brugere ser en ødelagt side fuld af udvikler-sidige nøgle-navne. Support-teamet modtager adskillige fejlrapporter.
Hvorfor er det et problem
Jo større din app bliver, desto større bliver kløften mellem engelske strenge og oversættelser på andre sprog. En app med 100 sprog og 2.000 strenge kan til enhver tid have 10.000+ manglende oversættelser.
Uden fallback-logik returnerer en manglende oversættelsesnøgle undefined, null eller selve den rå nøglestreng (f.eks. 'checkout.confirmButton'). Skabelonmotorer kan kaste fejl, siden kan gå ned eller slet ikke renderes.
Brugere ser en ødelagt UI: tomme knapper, manglende mærkater eller kryptiske strenge som 'nav.settings.title' i stedet for rigtig tekst. Det er forvirrende og uprofessionelt.
Sådan løser du det
Konfigurer en robust fallback-kæde og overvåg oversættelsesdækningen på tværs af alle lokaliseringer.
Indstil en fallback-sprogkæde i din i18n-konfiguration: manglende franske nøgler ruller automatisk tilbage til engelsk (en).
Tilføj en Missing-Key-handler, der logger uoversatte nøgler til dit overvågningssystem (f.eks. Sentry, Datadog) uden at bryde brugeroplevelsen.
Opret et oversættelses-dækning-dashboard, der sporer fuldførelsen for hver locale og blokerer udgivelser, når dækningen falder under en tærskel (fx 95%).
Fejl nr. 9: Tegnkodningsproblemer
Tegnkodningsproblemer er den stille dræber af lokalisering. Alt ser ud til at være korrekt på engelsk og europæiske sprog, men når du tilføjer kinesisk, japansk, koreansk, arabisk eller emojis, optræder forvrængede tegn (mojibake). Disse fejl er notorisk svære at opdage.
['Brug UTF-8-kodning overalt — kildefiler, database, API-svar og HTML-meta-tags', 'Brug utf8mb4 i MySQL (ikke utf8) for at understøtte hele Unicode-området inklusive emoji', 'Test med ægte indhold i CJK, arabisk og emoji for tidligt at fange kodningsproblemer']
Brug UTF-8-kodning overalt — kildefiler, databaser, API-svar og HTML-meta-tags
Brug utf8mb4 i MySQL (ikke utf8) for at understøtte hele Unicode-området inklusiv Emoji.
Test med ægte indhold i CJK, arabisk og emoji for tidligt at fange kodningsproblemer.
Et typisk scenarie
Udvikleren opsætter en MySQL-database med latin1-collation (den gamle standard). App-kildekoden bruger UTF-8.
Japanske brugere registrerer sig med deres rigtige navn. Databasen gemmer '田中太郎' som beskadigede bytes.
Resultatet: brugerprofilen viser forvrænget tekst. Endnu værre: søgning og sortering fejler for alle CJK-navne, vilket påvirker tusindvis af brugere.
Hvorfor det er et problem
Kodningsproblemer breder sig gennem hele din stack. En dårligt konfigureret database-kollation kan beskadige millioner af poster — reparationen kræver dyre data-migrationer.
Inkonsekvent kodning på tværs af stacken — UTF-8 i kildefilerne, Latin-1 i databasen og Windows-1252 i API-svaret — ødelægger multibyte-tegn. En enkelt fejlkonfigureret lag kan ændre '日本語' til '????' eller '日本èª'.
Brugere ser forvrængede tekster, spørgsmålstegn eller tomme felter, hvor deres sprog skulle være. I værste fald bliver formularindtastninger permanent beskadiget i databasen.
Sådan løser du det
Gennemgående tving UTF-8-kodningen i hvert lag i din applikationsstack.
Sæt alle kildefiler til UTF-8 (konfigurer din editor og .editorconfig). Tilføj <meta charset='UTF-8'> i dit HTML og 'Content-Type: application/json; charset=utf-8' i API-svar.
Konfigurer din database til utf8mb4 (ikke kun utf8, som i MySQL er et 3-bytes subset). Indstil forbindelsens kollation til utf8mb4_unicode_ci.
Vælg skrifttyper, der dækker dine mål-skriftsystemer: latin, kyrillisk, CJK, arabisk, devanagari. Brug systemfont-stacks eller Google Fonts med sprog-subsets for optimal indlæsning.
Test din i18n-implementering.
Test af længdeudvidelse
Udvid alle oversatte tekststrenge med 30-40% for at simulere tekstudvidelse, som opstår i sproglige sprog som tysk, finsk eller græsk. Det dækker beholdere med fast bredde, afkortede etiketter og knapper, der løber over, før du begynder at oversætte. Mange pseudo-lokaliseringværktøjer tilbyder det som en indbygget funktion.
"Send" → "Ṡééééñðéñ_éxpáñðéð" (40% længere)
Pseudo-lokalisering
Pseudo-lokalisering erstatter hvert tegn med et akcentueret ækvivalent (f.eks. 'a' → 'á') og indrammer strenge med markeringer som [!! og !!]. Dette gør straks synligt, hvilke strenge der er hardcoded, og hvilke der kommer fra oversættelsessystemet. Kør pseudo-lokalisering som en del af din CI-pipeline for automatisk at fange regressioner.
Enhver tekst på skærmen, der IKKE er indrammet af [!! !!]-markeringerne, er hardkodet og skal udlægges til oversættelse.
"Send besked" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
Test af RTL-layout
Selvom der ikke findes arabiske eller hebraiske oversættelser, kan du teste RTL-layoutet ved at tilføje dir='rtl' til dit HTML-rodelement. Dette afslører straks CSS-fejl i retning: fejlagtigt justerede ikoner, margener på den forkerte side, ødelagt navigation og forkert sorterede flex-elementer. Gør det til en standardkontrol i hver sprint-gennemgang — det tager 10 sekunder at skifte og fanger problemer, der ellers ville tage uger at løse i produktionen.
i18n – tjekliste
['Alle brugervenlige tekster er flyttet ud i ressourcefiler', 'Ingen sammenkædning af strenge til dannelse af sætninger', 'Pluralregler implementeret ved hjælp af ICU MessageFormat eller tilsvarende', 'Dato-, tids- og talformattering anvender locale-sensitive API’er', 'RTL-layout testet med arabisk eller hebraisk indhold', 'Fleksibelt UI uden faste bredder for teksttunge elementer', 'Fallback-sprog konfigureret og testet ved manglende nøgler', 'UTF-8-kodning konsistent på tværs af alle filer og databaser', 'Metadata til App Store og Play Store lokalisere for hvert marked', 'Screenshots og marketing-assets opdateret for hvert sprog']