10 vanlige i18n-feil og hvordan du unngÄr dem
LĂŠr de vanligste i18n-feilene som utviklere gjĂžr, og hvordan du retter dem. Forbedre lokaliseringen av appen din med disse beste praksis.
Internasjonalisering (i18n) virker ukomplisert â inntil du oppdager at dine tyske brukere ser avkuttede knapper, dine japanske brukere fĂ„r fragmenterte setningsdeler, og dine arabisk-talende brukere stĂ„r overfor helt Ăždelagte layouter. Dette er ikke tilfeldigheter. Det er de forutsigbare konsekvensene av vanlige feil som de fleste utviklingsteams gjĂžr nĂ„r de gĂ„r i gang med lokalisering for fĂžrste gang. I denne guiden gĂ„r vi gjennom de 10 vanligste i18n-feilene, forklarer nĂžyaktig hvorfor de skjer, og viser deg trinn for trinn hvordan du lĂžser hver enkelt. Enten du bygger en ny app eller oppgraderer en eksisterende â Ă„ unngĂ„ disse fallgruvene vil spare deg uker med debugging og gi en polert opplevelse for brukere over hele verden.
Feil #1: Hardkodede strenger
Hardkodering av strenger er den mest grunnleggende i18n-feilen. Den skjer fordi utviklere fÞrst fokuserer pÄ Ä fÄ funksjoner til Ä fungere, og planlegger Ä 'rydde opp senere'. Men senere kommer aldri, og plutselig har du tusenvis av strenger fordelt over hundrevis av filer.
['Sett i et i18n-rammeverk fĂžr du skriver fĂžrste UI-linje', 'Bruk en Linter-plugin for Ă„ oppdage hardkodede strengfragmenter i maler og komponenter', 'Hold oversettelsesnĂžkler beskrivende og organisert etter funksjon eller side']
Sett opp i18n-rammeverket ditt fĂžr du skriver den fĂžrste UI-koden.
Bruk en linter-plugin for Ă„ oppdage hardkodede strenger i maler og komponenter.
Hold oversettelsesnĂžklene beskrivende og organisert etter funksjon eller side.
Et typisk scenario
En utvikler skriver et knappetekst direkte i JSX: <button>Submit Order</button>.
Appen leveres pÄ engelsk og fungerer feilfritt. Seks mÄneder senere utvider selskapet til Tyskland.
Lokaliseringsteam oppdager 2.000+ hardkodede strenger. Oppgraderingen tar 3 uker og forÄrsaker 47 feil.
Hvorfor er dette et problem
I en moden kodebase kan hardkodede strenger gÄ opp i tusenvis. à extrahere dem senere krever at du berÞrer hver fil, tester hver komponent pÄ nytt og risikerer regresjoner overalt.
Hardkodierte Strings er direkte inne i kildekoden, malene eller komponentene. De kan ikke ekstraheres, oversettes eller byttes ut ved kjĂžring uten Ă„ endre koden.
Brukere i ikke-Engelske lokaliseringer ser uoversatte UI-elementer blandet med oversatt innhold â et kaotisk og uprofesjonelt inntrykk.
Slik lĂžser du det
Spar alle brukerens synlige strenger fra starten i ressursfiler.
Stell opp et oversettelsesrammeverk (f.eks. next-intl, react-i18next, vue-i18n) fĂžr du skriver din fĂžrste komponent.
Opprett en ressursfil-struktur (f.eks. messages/de.json) og referer alle strenger via oversettelsesnĂžkler som t('checkout.submitButton').
Legg til en lint-regel eller en pre-commit-hook som flagger rÄ streng-literal i UI-komponenter.
Feil nr. 10: Alt oversettes bokstavelig.
Ikke alt innhold bÞr oversettes. Merkevarer, navn pÄ rettslige enheter, tekniske termer og visse produkter bÞr forbli pÄ sitt opprinnelige sprÄk. Overivrig oversettelse kan skape rettslige problemer, merkevareinkonsistens og brukerforvirring.
["Vedlikehold et 'Ikke-oversett'-glossarium og del det med alle oversettere", "Bruk sperrede segmenter eller separate namespaces for merke- og rettsbegreper", "SĂžrg alltid for kontekstnotater for tvetydige strenger for Ă„ forhindre feiltolkede oversettelser"]
Logg et 'Ikke oversett'-glossar og del det med alle oversettere.
Bruk sperrede segmenter eller separate namespaces for merke- og rettslige termer.
Houd altijd contextnotities voor ambigu strings om verkeerde vertalingen te voorkomen.
Et typisk scenario
Een vertaalbestand bevat de bedrijfsnaam 'CloudForge Inc.' en de technische term 'OAuth 2.0 Token' als reguliere vertaalbare strings.
Den spanske oversetteren oversetter 'CloudForge' til 'ForjaNube' og 'OAuth 2.0 Token' til 'OAuth 2.0-token'.
Resultat: Brukere finner ikke selskapet under dets egentlige navn, og utviklere som leser den spanske dokumentasjonen blir forvirret av ukjente fagbegreper.
Hvorfor er det et problem
En enkelt feiloversatt merknavn i et juridisk dokument kan gjĂžre kontrakten ugyldig. Ă rette oversettelser som er for mye krever Ă„ gjennomgĂ„ hver streng i hvert sprĂ„k â en jobb som tar flere uker.
Hvis alle strengene sendes uten kontekst til oversettelse, kan oversettere oversette merkename ('Apple' â 'Apfel'), juridiske termer ('GmbH' â 'LLC') eller tekniske betegnelser som mĂ„ forbli pĂ„ engelsk.
Brukere finner produkter ikke under sitt kjente merke. Juridiske dokumenter refererer til feil selskap, og teknisk dokumentasjon blir uforstÄelig hvis begreper som 'API Endpoint' oversettes.
Slik lĂžser du det
Marker innhold som ikke kan oversettes tydelig og gi kontekstnotater til oversetteren.
Lag en 'Ikke-oversett'-ordliste som lister opp alle merkevarer, produktenavn, rettslige enheter og fagbegreper som mÄ forbli uendret.
Bruk en separat namespace eller spesielle nÞkler for ikke-oversettbart innhold. Mange i18n-verktÞy stÞtter 'lÄste' segmenter som oversettere ikke kan redigere.
TilfĂžj oversetterkommentarer/beskrivelser til oversettelsesfilene dine som forklarer konteksten: 'Dette er et merkenavn â ikke oversette' eller 'Fagterm â behold pĂ„ engelsk'.
Feil #2: Sammenkoblede strenger
Fragments aan elkaar plakken virker logisk pÄ engelsk, men fungerer ikke pÄ andre sprÄk. Ordstilling, grammatikk og setningsstruktur varierer dramatisk mellom sprÄkene, noe som gjÞr sammenkoblede strenger uoversettbare.
['Bygg aldri setninger ved Ă„ sette sammen oversatte fragmenter', 'Bruk navngitte plassholdere ('{name}') i stedet for posisjonelle ({0}) for klarhet', 'Gi kontekstkommentarer til oversettere som forklarer hva hver plassholder inneholder']
Bouw nooit zinnen door het samenvoegen van vertaalde fragmenten.
Bruk navngitte plassholdere ('{name}') i stedet for posisjonelle ({0}) for klarhet
Gi kontekstkommentarer til oversettere som forklarer hva hver plassholder inneholder.
Et typisk scenario.
Utvikleren skriver: 'You have ' + count + ' items in your ' + cartType + ' cart' â fungerer perfekt pĂ„ engelsk.
Den tyske oversetteren mottar tre separate fragmenter og kan ikke danne en grammatisk korrekt setning fordi ordstillingen mÄ endres.
Resultat: Tyske brukere ser 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' â hĂžres stivt ut og er uprofesjonelt.
Hvorfor er dette et problem
Hver lenkede streng er en tikkende tidsbombe. Med 20 sprÄk og 50 lenkede strenger har du 1 000 potensielle grammatikkfeil som mÄ rettes manuelt.
Sammenkobling av strenger som 'Willkommen ' + userName + ', du har ' + count + ' nye meldinger' krever en viss ordstilling. Oversettere fÄr kontekstlÞse fragmenter som de ikke kan omorganisere.
Brukere ser grammatisk feilaktige setninger. PÄ tysk stÄr verbet ofte til slutt. PÄ arabisk er hele strukturen snudd. Resultatet leser seg som meningslÞst.
Slik lĂžser du det.
Bruk parameteriserte meldinger med namnede plassholdere, slik at oversettere kan omorganisere hele setningen.
Erstatt sammenstilling med en enkelt meldingsnĂžkkel med plassholdere: 'cart.summary': 'Du har {count} varer i din '{cartType}'-handlekurv'.
OverfĂžr variabler som parametere til oversettelsesfunksjonen din: t('cart.summary', { count: 5, cartType: 'Premium' }).
Oversettere kan nĂ„ fritt omorganisere: 'I din '{cartType}'-handlekurv er det {count} varer' â grammatisk korrekt tysk.
Feil #3: Ignorering av flertall
Engelsk har to pluralformer: entall og flertall. Utviklere antar ofte at alle sprÄk fungerer pÄ samme mÄte. Det gjÞr de ikke. Polsk har fire former, arabisk har seks, og til og med sprÄk som fransk behandler null pÄ en annen mÄte enn engelsk.
['Bruk alltid ICU MessageFormat eller et tilsvarende bibliotek for tellelige innhold', 'Skriv aldri din egen flertallslogikk â stol pĂ„ CLDR-reglene', 'Test flertall med verdier som 0, 1, 2, 5, 21 og 100 for Ă„ dekke alle kategorier']
Bruk alltid ICU MessageFormat eller et tilsvarende bibliotek for tellelig innhold.
Skriv aldri din egen flertallslogikk â stol pĂ„ CLDR-reglene.
Test meervoud met waarden zoals 0, 1, 2, 5, 21 en 100 om alle categorieën te dekken.
Et typisk scenario.
Utvikleren skriver: count + (count === 1 ? ' Datei' : ' Dateien') â behandelt Duits korrekt.
Den polske oversetteren trenger 4 former: 1 plik, 2â4 pliki, 5â21 plikĂłw, 22â24 pliki. Den enkle ternĂŠre kan ikke uttrykke det.
Resultat: Polske brukere ser '5 pliki' (feil form) i stedet for '5 plikĂłw' (riktig form), og appen ser ut til Ă„ vĂŠre Ăždelagt.
Hvorfor er det et problem.
Hver tellbare substantiv i appen din trenger flertallsbehandling. Med 50 slike strings og 20 sprĂ„k er det 1 000 pluralregler â umulig Ă„ administrere manuelt.
Enkle if/else-sjekker (count === 1 ? 'Datei' : 'Dateien') behandler bare tysk/engelsk. CLDR definerer opptil 6 plural-kategorier: zero, one, two, few, many og other. Hver sprÄk bruker en annen delmengde.
Brukere ser grammatisk feil tekst som '1 Nachrichten' eller helt gale pluralformer. I formelle sammenhenger Ăždelegger dette troverdigheten.
Slik lĂžser du det.
Bruk ICU MessageFormat som har innebygde CLDR-pluralregler.
Definer meldinger med ICU-syntaks: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
Oversetteren leverer alle nÞdvendige pluralformer for sprÄket sitt. Polsk: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
Ditt i18n-bibliotek velger automatisk riktig form i kjÞretid basert pÄ CLDR-reglene for den aktive locale.
Feil #4: Faste UI-element-bredder
Designere lager pikselpresise layouter op engelsk, og utviklere implementerer dem med faste bredder. Men oversatt tekst kan vĂŠre dramatisk lengre eller kortere. Tysk tekst er omtrent 30% lengre enn engelsk, mens kinesisk tekst kan vĂŠre 50% kortere.
['Ikke bruk faste pikselbredder pĂ„ elementer med oversettbart tekst', 'Planlegg 40% tekstforlengelse som baseline â noen sprĂ„k vokser enda mer', 'Bruk CSS Flexbox of Grid for layouter som tilpasser seg varierende innholds lengder']
Gebruik nooit vaste pixelbreedtes bij elementen met vertaalbare tekst.
Bruk en baseline pĂ„ 40% tekstforlengelse â noen sprĂ„k utvider seg enda mer.
Bruk CSS Flexbox eller Grid for oppsett som tilpasser seg varierende innholdslengder.
Et typisk scenario
Designeren lager en navigasjonslinje met 5 knapper, elke nĂžyaktig 100px bred â ser flott ut pĂ„ engelsk.
Oversettelsen til tysk: 'Settings' blir til 'Einstellungen' (13 vs 8 tegn), 'Submit' blir til 'Absenden' (8 vs 6). Navbarloopt over.
Resultatet: PÄ mobiler er knappene stablet oppÄ hverandre eller teksten blir avkuttet, noe som gjÞr navigasjonen for tyske brukere ubrukelig.
Hvorfor er dette et problem
Hvert element med fast bredde er et potensielt bruddpunkt. En typisk app har hundrevis av knapper, etiketter og kort som alle mÄ tÄle tekstforlengelse.
En beholder med fast bredde (width: 120px) og knapper med fast stÞrrelse klipper av innhold eller lÞper utenfor nÄr teksten utvides. CSS overflow: hidden skjuler innhold stille, mens overflow: visible Þdelegger oppsettet.
Brukere ser avkuttede etiketter som 'Einstellu...' i stedet for 'Innstillinger', eller knapper som overlapper naboelementer. Kritiske handlinger blir uleselige eller ikke-klikkbare.
Slik fikser du det
Utvikle og implementere fleksible layouter som tilpasser seg innholdets lengde i alle lokalisasjoner.
Vervang vaste breedtes door min-width, max-width en Flex-layouts. Gebruik CSS Grid of Flexbox om de ruimte dynamisch te verdelen.
Still inn tekstkonteksten for linjeskift: bruk overflow-wrap: break-word og unngÄ white-space: nowrap ved oversettbart innhold.
Test UI-en din med pseudo-lokalisering som forlenger alle strenger med 40% for Ă„ simulere verste fall â fĂžr du sender strengene til oversettere.
Feil #5: Dato- og tallformat
Data og tall virker universelle. Men 01/02/2025 betyr 2. januar i USA og 1. februar i Europa. Kommaer og punkt bytter betydning i tall: 1,000.50 (USA) vs 1.000,50 (Tyskland). Ă gjĂžre dette feil fĂžrer til forvirring, datafeil og tapt tillit.
['FormatĂ©r aldri data eller tall manuelt med strengmaler â bruk alltid Intl-APIene', 'Lagre alle data internt i ISO 8601-format (YYYY-MM-DD) og valuta i minste enhet (Cent) internt', 'Test med localeer som bruker forskjellige desimalseparatorer, dato-rekkefĂžlger og kalendersystemer']
Formater aldri data eller tall manuelt med strengmaler â bruk alltid Intl-API-er.
Lagre alle data i ISO 8601 og valuta i minste enhet (cent) internt.
Test locale-er som bruker forskjellige desimalskilletegn, dato-ordning og kalendersystemer.
Et typisk scenario
Utvikleren formaterer et dato som MM/DD/YYYY og en pris som $1,234.50 â korrekt for amerikanske brukere.
En tysk bruker ser 03/04/2025 og leser det som 3. april (DD/MM/JJJJ-konvensjonen). Prisen $1,234.50 ser ut som om den burde vĂŠre 1.234,50.
Resultat: Brukeren bestiller en flytur for feil dato og stiller spÞrsmÄl ved prisformatet. KundestÞttesaker i det tyske markedet Þker med 15 %.
Hvorfor er dette et problem
Datokonvertering og tallformat berber berpengaruh ke display data i appen din: tabeller, diagrammer, skjemaer, fakturaer, rapporter. En global lĂžsning dekker hundrevis av forekomster.
Hardkodete formatstrenger som toLocaleDateString('en-US') eller manuell formattering med template-literals ignorerer brukerens faktiske locale. Selv om locale er riktig, men kalenderen er feil (gregoriansk vs. Hijri) skaper problemer.
Brukere leser data feil og skriver inn data i feil format. En europeisk bruker som ser 03/04/2025 tolker det kanskje som 3. april i stedet for 4. mars â miste avtaler eller feilbestillinger.
Slik fikser du det
Bruk den innebygde Intl-API-en eller et locale-sensitive formatteringsbibliotek for alle datoer, tider, tall og valuta.
Erstatt manuell formatering med Intl.DateTimeFormat(locale) for datoer og Intl.NumberFormat(locale, { style: 'currency', currency }) for priser.
Lagre alle data internt i ISO 8601-format (YYYY-MM-DD) og formater dem kun for visning med brukerens locale.
Test med localeer som bruker forskjellige desimalseparatorer, dato-rekkefĂžlger og kalendersystemer.
Feil #6: Glemte RTL-sprÄk
HĂžyre-til-venstre (RTL) sprĂ„k som arabisk, hebraisk og persisk brukes av mer enn 500 millioner mennesker. Likevel blir de fleste appene utformet utelukkende for venstre-til-hĂžyre (LTR) layout. RTL-stĂžtte betyr ikke bare Ă„ snu teksten â hele brukergrensesnittet mĂ„ speiles.
['Bruk logiske CSS-egenskaper og test med RTL-layout fra fÞrste dag', 'Test appen din med dir='rtl' pÄ HTML-elementet ved hver sprint-review', 'Lag en RTL-test-sjekkliste for navigasjon, ikoner, skjemaer og framdriftsindikatorer']
Bruk fra dag Ă©n utelukkende logiske CSS-egenskaper (inline-start/end, block-start/end).
Test appen din med dir='rtl' pÄ HTML-elementet i hver sprint-review.
Maak een RTL-testchecklist voor navigatie, iconen, formulieren en voortgang.
Et typisk scenario
Utvikler bruker margin-left: 16px og text-align: left gjennom hele appen â standard-LTR-praksis.
Appen startet i Saudi-Arabia. Tilbakepilene peker mot fram, sidemenyene vises pÄ feil side, og numeriske data er feiljustert.
Resultat: Arabiske brukere forlater appen etter 30 sekunder. Teamet trenger 4 ukers nĂžd-CSS-refactoring for Ă„ fikse problemet.
Hvorfor er dette et problem
RTL-stĂžtte berkommer til hver enkelt komponent i appen din. Ă innfĂžre RTL i ettertid krever vanligvis Ă„ omskrive 30-50% av alle CSS-regler og Ă„ sjekke hvert ikon og oppsett.
CSS-egenskaper som margin-left, padding-right, text-align: left og float: left hardkodes retningen. Ikoner med retningbetydning (piler, fremskrittindikatorer) peker i feil retning. Selv border-radius-verdier mÄ speiles.
Arabiske brukere ser navigasjonen i det feil hjÞrnet, fremdriftslinjen gÄr bakover, og teksten kolliderer med UI-elementer. Appen fÞles fremmed og ikke-brukbar.
Slik fikser du det
Bruk logiske CSS-egenskaper og test med RTL-layout fra starten.
Erstatt alle fysiske CSS-egenskaper med logiske ekvivalenter: margin-left â margin-inline-start, padding-right â padding-inline-end, text-align: left â text-align: start.
Sett dir-attributtet pÄ HTML-roten basert pÄ aktiv lokal. Bruk CSS-pseudo-klassen :dir(rtl) for RTL-spesifikke overrides.
Sjekk alle ikoner pÄ retning. Bytt ut retning-avhengige ikoner med speilverd versjoner eller bruk CSS-transform: scaleX(-1) for RTL-kontekster.
Feil #7: Bilder mit Text
Tekst i bilder inn i hero-banners, knapper osv â er en lokalisasjons-mareritt. Hvert bilde med tekst mĂ„ lages pĂ„ nytt for hvert sprĂ„k, noe som Ăžker designkostnadene og forsinker utgivelser.
['Aldri tilby vert tekst direkte i rasterbilder (PNG, JPG)', 'Bruk CSS-tekstoverlegg pÄ bakgrunnsbilder for hero-banners og CTA-er', 'Automatiser skjermbildedannelse for App Store-oppfÞringer og markedsfÞringssider']
Plaats vertaalbare tekst nooit rechtstreeks in rasterafbeeldingen (PNG, JPG).
Gebruik CSS-tekstoverlay op achtergrondafbeeldingen voor hero-banner en CTA's.
Automatiseer de screenshot-generatie voor App Store-listings en marketingpagina's.
Et typisk scenario
En designer lager et promot-banner med teksten 'Start Your Free Trial' innebygd direkte i bildet.
Lokaliseringsteamet oversetter alle UI-strenger, men banneret viser fortsatt engelsk tekst pÄ den tyske siden.
Resultatet: Den tyske landingssiden har en irriterende engelsk banner. à lage lokalisert bannere for 15 sprÄk tar 3 dagers designarbeid og forsinker lanseringen.
Hvorfor er dette et problem
En typisk markedsfĂžringsside har 5â10 bilder med tekst. Med 15 sprĂ„k blir det 75â150 bildvarianer som mĂ„ opprettes, vedlikeholdes og oppdateres ved hver designendring.
Tekst i bilder inn i bilder (PNG, JPG, SVG med innebygd tekst) kan ikke trekkes ut av verktĂžy for oversettelse. Hver lokalisert versjon krever at en designer manuelt redigerer kildedfilen, eksporterer og laster opp.
Brukerne ser bilder med tekst pÄ et fremmed sprÄk, eller enda verre, en blanding av oversatt UI og uoversatte bilder. Dette virker inkonsekvent og undergraver merkevaren.
Slikt lĂžser du det
Del teksten fra bildene ved hjelp av CSS-overlays, SVG-er med oversettbare tekst-elementer eller dynamisk bildgenerering.
Bruk CSS for Ă„ plassere oversettbar tekst over bakgrunnsbilder: plasser tekstlaget med absolutt posisjonering over bilde-beholderen.
Voor infographics of diagrammen gebruik SVG's met <text>-elementen die verwijzen naar vertaalbare sleutels, in plaats van rauwe strings in te bedden.
For App-skjermbilder i markedsfĂžringsmateriell, automatiser genereringen av skjermbilder med verktĂžy som Fastlane (Mobil) eller Playwright (Web), som tar skjermbilder i hver locale.
Feil #8: Manglende oversettelser blir ikke hÄndtert
Oversettelsene er alltid ufullstendige under utvikling. Nye funksjoner legger til strings raskere enn oversettere kan oversette. Uten riktig fallback-hÄndtering forÄrsaker manglende oversettelser krasjer, tomme UI-elementer eller rÄ oversettelsesnÞkler som vises til brukeren.
['Konfigurer alltid minst ett fallback-sprÄk i i18n-innstillingene dine', 'Logg manglende oversettelsesnÞkler til overvÄkingssystemet ditt for sporing', 'Sett et minimum oversettelsesdekningsgrad fÞr en locale gÄr live']
Konfigurer alltid minst ett fallback-sprÄk i din i18n-innstilling.
Logg manglende oversettelsesnÞkler til overvÄkingssystemet for oppfÞlging.
Stel een minimale vertaaldekking in voordat een locale live mag gaan.
Et typisk scenario
Utvikler legger til en ny 'Premium Features'-del med 15 nye oversettelsesnĂžkler. Den engelske versjonen leveres med Ă©n gang.
De franske oversettelsene er fortsatt ikke ferdige. Den franske siden viser rÄe nÞkler: 'premium.feature1.title', 'premium.feature1.description'.
Resultatet: Franske brukere ser en Ăždelagt side full av utvikler-kjerne-navn. Support-teamet mottar dusinser av feilrapporter.
Hvorfor er dette et problem
Jo stÞrre appen din blir, desto stÞrre blir gapet mellom engelske strenger og oversettelser pÄ andre sprÄk. En app med 100 sprÄk og 2.000 strenger kan nÄr som helst ha 10.000+ manglende oversettelser.
Uten fallback-logikk returnerer en manglende oversettelsesnÞkkel undefined, null, eller den rÄ nÞkkelen som tekst (f.eks. 'checkout.confirmButton'). Malmotorer kan kaste feil, siden krasje eller ikke render noe.
Brukere ser en Ăždelagt UI: tomme knapper, manglende etiketter eller kryptiske strenger som 'nav.settings.title' i stedet for ekte tekst. Dette er forvirrende og lite profesjonelt.
Slikt lĂžser du det
Konfigurer en robust fallback-kjede og overvÄk oversettelsesdekningen i alle locales.
Konfigurer en fallback-sprÄk-kjede i i18n-konfigurasjonen din: manglende fr-nÞkler faller automatisk tilbake til engelsk (en).
Legg til en Missing-Key-handler som logger uoversatte nÞkler til overvÄkingssystemet ditt (f.eks. Sentry, Datadog) uten Ä bryte brukeropplevelsen.
Opprett et oversettelsesdekningsdashbord som sporer fullfÞringsgraden per locale og blokker utgivelser nÄr dekningen faller under en terskelverdi (f.eks. 95%).
Feil nr. 9: Tegnkodingproblemer
Problemer med tegnsetting er den stille morderen av lokalisering. Alt ser ut til Ä fungere pÄ engelsk og europeiske sprÄk, men nÄr du legger til kinesisk, japansk, koreansk, arabisk eller emoji, dukker forvrengte tegn opp. Disse feilene er beryktet vanskelige Ä spore.
['Bruk UTF-8-koding overalt â kildefiler, databasen, API-svar og HTML-meta-tags', 'Bruk utf8mb4 i MySQL (ikke utf8) for Ă„ stĂžtte full Unicode-omrĂ„det inkludert emoji', 'Test med ekte innhold i CJK, arabisk og emoji for Ă„ fange kodingsproblemer tidlig']
Bruk UTF-8-koding overalt â kildefiler, databaser, API-responser og HTML-meta-tags.
Bruk utf8mb4 i MySQL (ikke utf8) for Ä stÞtte hele Unicode-omrÄdet inkludert Emoji.
Teste med ekte innhold i CJK, arabisk og emoji, for Ă„ fange opp kodingsproblemer tidlig.
Et typisk scenario
Utvikleren setter opp en MySQL-database med latin1-kollasjon (den gamle standarden). Applikasjonens kildekode bruker UTF-8.
Japanske brukere registrerer seg med sitt virkelige navn. Databasen lagrer 'ç°äžć€Șé' som Ăždelagte bytes.
Resultatet: Brukerens profil viser forvrengt tekst. Enda verre: sĂžk og sortering bryter for alle CJK-navn, noe som berĂžrer tusenvis av brukere.
Hvorfor er det et problem
Problemer med koding sprer seg gjennom hele stacken. En feilkonfigurert kolasjon i databasen kan skade millioner av poster â reparasjonen krever kostbare migrasjoner.
Inkonsistente koding over hele stack â UTF-8 i kildefilene, Latin-1 i databasen og Windows-1252 i API-svar â Ăždelegger multibyte-tegn. En enkelt feilkonfigurert lag vil forvandle 'æ„æŹèȘ' til '????' eller 'ĂŠâ„ÊĆÂŹĂšÂȘ'.
Brukere ser tilkuttede tekster, spÞrsmÄlstegn eller tomme bokser der sprÄket deres burde vÊre. I verste fall blir skjemainndata permanent skadet i databasen.
Slik lĂžser du det
Tving UTF-8-koding konsistentThrough hvert lag av applikasjons-stack.
Stell alle brontilder i UTF-8 (konfigurer din editor og .editorconfig). Legg til <meta charset='UTF-8'> i HTML-en din og 'Content-Type: application/json; charset=utf-8' i API-responsene.
Konfigurer databasen din til utf8mb4 (ikke bare utf8, som er et 3-byte subset i MySQL). Sett tilkoblings-kollasjonen til utf8mb4_unicode_ci.
Kies lettertypen die jouw doelschriftsystemen dekken: Latinsk, Cyrillisk, CJK, Arabisk, Devanagari. Gebruik system-font-stacks of Google Fonts met taal-subsets voor optimale laadtijden.
Test din i18n-implementasjon.
Lengdeutvidelsestest
Utvid alle oversatte strenger med 30-40% for Ä simulere tekstlengdeÞkning som oppstÄr i sprÄk med lange ord som tysk, finsk eller gresk. Dette dekker containere med fast bredde, avkuttede etiketter og knapper som gÄr utenfor fÞr du begynner Ä oversette. Mange pseudo-lokalisering verktÞy tilbyr dette som innebygd funksjon.
"Send" â "áč ééééñðéñ_Ă©xpåñðéð" (40% lengre)
Pseudo-lokalisering.
Pseudo-lokalisering erstatter hvert tegn med et aksentert ekvivalent (f.eks. 'a' â 'ĂĄ') og omgir strenger med markĂžrer som [!! og !!]. Dette gjĂžr umiddelbart synlig hvilke strenger som er hardkodet og hvilke som kommer fra oversettelsessystemet. KjĂžr pseudo-lokalisering som en del av CI-pipelinen din for automatisk Ă„ fange regresjoner.
Hver tekst pÄ skjermen som IKKE er innkapslet i [!! !!]-markÞrene, er hardkodet og mÄ utlegges. Denne testen fanger omtrent 95% av oversette strenger som blir oversatt i lÞpet av under ett minutt.
"Send melding" â "[!! ĂåçងĆĂçងáč« áčĄĂ©Ă±Ă°Ă©Ă± !!]"
RTL-layouttest
Selv uten arabiske eller hebraiske oversettelser kan du teste RTL-layout ved Ă„ legge dir='rtl' til HTML-roten-elementet ditt. Dette oppdager umiddelbart retning-relaterte CSS-feil: feiljusterte ikoner, marginer pĂ„ feil side, skadet navigasjon og feil sorterte flex-elementer. GjĂžr dette til en standard sjekk i hver sprintgjennomgang â det tar 10 sekunder Ă„ bytte, og fanger problemer som ellers ville tatt uker Ă„ lĂžse i produksjon.
i18n-sjekkliste
['Alle strenger som vises for brukeren i ressursfiler er flyttet', 'Ingen streng-sammenkobling brukt for Ä lage setninger', 'Pluralregler implementert med ICU MessageFormat eller tilsvarende', 'Dato-, tid- og tallformat bruker locale-tilpassede API-er', 'RTL-layout med arabisk eller hebraisk innhold testet', 'Fleksibelt UI uten faste bredder for teksttunge elementer', 'Fallback-sprÄk konfigurert og testet ved manglende nÞkler', 'UTF-8-koding konsistent i alle filer og databaser', 'Metadata for App Store og Play Store lokalisert for hvert marked', 'Skjermbilder og markedsfÞringsressurser for hvert sprÄk oppdatert']