10 Common i18n Mistakes Developers Make | Fix Guide 2025

Internationellisering (i18n) verkar enkelt — tills du upptäcker att tyska användare får avklippta knappar, japanska användare får avklippta meningdelar och arabisktalande användare står inför helt förstört layout. Det här är inte undantag. Det är de förväntade konsekvenserna av vanliga fel som de flesta utvecklingsteamen gör när de först närmar sig lokalisering. I denna guide går vi igenom de 10 vanligaste i18n-felen, förklarar exakt varför de uppstår och steg-för-steg visar hur du åtgärdar varje en. Oavsett om du bygger en ny app eller uppgraderar en befintlig — att undvika dessa fallgropar sparar dig veckor av debugging och levererar en polerad upplevelse för användare över hela världen.

Fel #1: hårdkodade strängar

Hårdkodade strängar är den grundläggande i18n-felet. Det händer eftersom utvecklare först fokuserar på att få funktioner att fungera och planerar att 'städa upp senare'. Men senare kommer aldrig, och plötsligt har du tusentals strängar spridda över hundratals filer.

['Ställ in ditt i18n-ramverk innan du skriver den första UI-koden', 'Använd en linter-plugin för att upptäcka hårdkodade strängar i mallar och komponenter', 'Håll översättningsnycklarna beskrivande och organiserade efter funktion eller sida']

Ställ in ditt i18n-ramverk innan du skriver den första UI-koden.

Använd ett linter-plugin för att upptäcka hårdkodade strängar i mallar och komponenter.

Håll översättningsnycklarna beskrivande och organiserade efter funktion eller sida.

Ett typiskt scenario

En utvecklare skriver direkt i JSX en knappetikett: <button>Submit Order</button>.

Appen levereras på engelska och fungerar felfritt. Sex månader senare utökar företaget till Tyskland.

Lokaliseringsteamet upptäcker över 2000 hårdkodade strängar. Eftermontering tar 3 veckor och orsakar 47 buggar.

Varför är det ett problem

I en mogen kodbas kan hårdkodade strängar nå upp till tusentals. Att extrahera dem i efterhand kräver att varje fil ändras, varje komponent testas igen och regressioner riskeras överallt.

Hårdkodade strängar är direkt inbäddade i källkoden, mallar eller komponenter. De kan inte extraheras, översättas eller bytas i körning utan att ändra själva koden.

Användare i icke-engelska lokaliseringar ser UI-element som inte är översatta, blandade med översatt innehåll — en kaotisk og oprofessionell känsla.

Så här åtgärdar du det

Flytta alla användarens synliga strängar från början till resursfiler.

Ställ in ett översättningsramverk (t.ex. next-intl, react-i18next, vue-i18n) innan du skriver din första komponent.

Skapa en resursfilsstruktur (t.ex. messages/de.json) och referera till alla strängar via översättningsnycklar som t('checkout.submitButton').

Lägg till en lint-regel eller ett pre-commit-hook som flaggar råa sträng-litteraler i UI-komponenter.

Fel #10: Översätta allt ordagrant

Inte allt innehåll bör översättas. Varumärkenamn, namn på juridiska personer, tekniska termer och vissa produktnamn bör förbli på sitt originalspråk. Översättning i onödan kan orsaka juridiska problem, varumärkesinkonsekvens och förvirring hos användarna.

Skapa ett glossary som anger att det inte ska översättas och dela det med alla översättare. Använd låsta segment eller separata namnrymder för varumärkes- och juridiska termer. Ge alltid kontextanteckningar till översättarna för tvetydiga strängar så att översättningsfel undviks.

Underhåll en 'översätt inte'-ordlista och dela den med alla översättare.

Använd låsta segment eller separata namnrymder för varumärkes- och juridiska termer.

Tillhandahåll alltid kontextanteckningar för tvetydiga strängar för att förhindra felöversättningar.

Ett typiskt scenario

En översättningsfil innehåller företagsnamnet 'CloudForge Inc.' och den tekniska termen 'OAuth 2.0 Token' som vanliga översättbara strängar.

Den spanska översättaren översätter 'CloudForge' till 'ForjaNube' och 'OAuth 2.0 Token' till 'ficha OAuth 2.0'.

Resultat: användare hittar inte företaget under dess verkliga namn, och utvecklare som läser den spanska dokumentationen blir förvirrade av okända översatta facktermer.

Varför är det ett problem

Ett felöversatt varumärkesnamn i ett juridiskt dokument kan göra kontraktet ogiltigt. Att rätta till sådana översättningar kräver granskning av varje sträng på varje språk — flera veckor.

Om alla strängar skickas till översättning utan sammanhang kan översättare översätta varumärkena ('Apple' → 'Apfel'), juridiska termer ('GmbH' → 'LLC') eller tekniska beteckningar som måste förbli på engelska.

Användare hittar inte produkter under sitt välkända varumärke, juridiska dokument refererar till fel företag och teknisk dokumentation blir otydlig när begrepp som 'API Endpoint' översätts.

Så här åtgärdar du det

Tydligt markera icke-översättbara innehåll och tillhandahåll kontextanteckningar till översättarna.

Skapa ett glosarium som anger att det inte ska översättas och dela det med alla översättare. Använd låsta segment eller separata namnrymder för varumärkes- och juridiska termer. Ge alltid kontextanteckningar till översättarna för tvetydiga strängar så att översättningsfel undviks.

Använd ett separerat namespace eller särskilda nycklar för innehåll som inte går att översätta. Många i18n-verktyg stöder 'låsta' segment som översättare inte kan redigera.

Lägg till översättarkommentarer/beskrivningar till dina översättningsfiler som förklarar sammanhanget: Detta är ett varumärke — översätt inte eller en fackterm — behåll engelska ordet.

Fel #2: Strängkedjor

Att använda meningar som sammansatta av fragment blir logiskt på engelska, men fungerar inte i andra språk. Ordföljd, grammatik och meningsstruktur varierar dramatiskt mellan språk, vilket gör sammanhängande strängar oöversättbara.

['Bygg aldrig meningar genom att kedja ihop översatta fragment', 'Använd namngivna platshållare ('{name}') istället för positionella ({0}) för tydlighet', 'Ge kontextkommentarer till översättare som förklarar vad varje platshållare innehåller']

Aldrig skapa meningar genom att sammanfoga översatta fragment.

Använd namngivna platshållare ('{name}') istället för positionella ({0}) för tydlighet

Tillhandahåll kontextkommentarer för översättare som förklarar vad varje platshållare innehåller.

Ett typiskt scenario

Utvecklaren skriver: 'You have ' + count + ' items in your ' + cartType + ' cart' — fungerar perfekt på engelska.

Den tyska översättaren får tre separata fragment och kan inte bilda en grammatiskt korrekt mening eftersom ordföljden måste ändras.

Resultatet: tyska användare ser 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — kantigt och oprofessionellt.

Varför är det ett problem

Varje sammanlänkad sträng är en tickande tidsbomb. Med 20 språk och 50 sammanlänkade strängar har du 1 000 potentiella grammatiska fel som måste åtgärdas manuellt.

String-sammanfogning som 'Willkommen ' + användarnamn + ', du har ' + count + ' nya meddelanden' kräver en viss ordning på orden. Översättare får sammanhangslösa fragment som de inte kan omstrukturera.

Användare ser grammatiskt felaktiga meningar. På tyska står verbet ofta i slutet. På arabiska är hela strukturen omvänd. Resultatet läses som nonsens.

Så här åtgärdar du det

Använd parametriserade meddelanden med namngivna platshållare så att översättare kan omstrukturera hela meningen.

Ersätt kedjning med en enda meddelandenyckel med platshållare: 'cart.summary': 'Du har {count} artiklar i din '{cartType}'-varukorg'.

Skicka variablerna som parametrar till din översättningsfunktion: t('cart.summary', { count: 5, cartType: 'Premium' }).

Översättare kan nu fritt omorganisera: 'I din '{cartType}'-varukorg finns {count} artiklar' — grammatiskt korrekt tyska.

Fel #3: Pluralisierung

Engelska har två pluralformer: singular och plural. Utvecklare antar ofta att alla språk fungerar på samma sätt. Så är inte fallet. Polska har 4 former, arabiska har 6, och till och med språk som franska behandlar noll på annat sätt än engelska.

['Alltid använd ICU MessageFormat eller ett motsvarande bibliotek för räknbara innehåll', 'Skriv aldrig egen plural-logik — lita på CLDR-reglerna', 'Testa pluralformer med värden som 0, 1, 2, 5, 21 och 100 för att täcka alla kategorier']

Använd alltid ICU MessageFormat eller ett motsvarande bibliotek för pluralformer.

Skriv aldrig din egen plurallogik – lita på CLDR-reglerna.

Testa pluralformer med värden som 0, 1, 2, 5, 21 och 100 för att täcka alla kategorier.

Ett typiskt scenario

Utvecklaren skriver: count + (count === 1 ? ' Datei' : ' Dateien') — korrekt hantering av tyska.

Polsk översättare behöver 4 former: 1 plik, 2–4 pliki, 5–21 plików, 22–24 pliki. En enkel ternär kan inte uttrycka det.

Resultatet: polska användare ser '5 pliki' (felaktig form) istället för '5 plików' (korrekt form), och appen ser ut att krångla.

Varför är det ett problem

Varje räknebara substantiv i din app kräver pluralhantering. Vid 50 sådana strängar och 20 språk är det 1 000 pluralregler — omöjligt att hantera manuellt.

Enkla if/else-kontroller (count === 1 ? 'Datei' : 'Dateien') täcker endast tyska och engelska. CLDR definierar upp till 6 plural-kategorier: zero, one, two, few, many och other. Varje språk använder en annan uppsättning kategorier.

Användare ser grammatiskt felaktiga texter som '1 Nachrichten' eller helt felaktiga pluralformer. I formella sammanhang undergräver det trovärdigheten.

Så här åtgärdar du det

Använd ICU MessageFormat som stöder alla CLDR pluralregler direkt.

Definiera meddelanden med ICU-syntax: 'fileCount': '{count, plural, one {# fil} other {# filer}}'.

Översättare tillhandahåller alla nödvändiga pluralformer för sitt språk. Polska: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.

Din i18n-bibliotek väljer automatiskt vid körning rätt form baserat på CLDR-reglerna för den aktiva lokalen.

Fel #4: Fasta UI-element-bredd

Designer skapar pixelerade layout för engelska och utvecklarna implementerar dem med fasta bredder. Men översatt text kan vara dramatiskt längre eller kortare. Tysk text är ungefär 30% längre än engelska, medan kinesisk text kan vara 50% kortare.

['Använd aldrig fasta pixelbredder för element med översättbart textinnehåll', 'Planera för 40% textersökning som baslinje — vissa språk expanderar ännu mer', 'Använd CSS Flexbox eller Grid för layouter som anpassar sig till varierande innehållslängder']

Använd aldrig fasta pixelbredder på element med översättbart textinnehåll.

Planera en baslinje med 40 % textökning — vissa språk utökas ännu mer.

Använd CSS Flexbox eller Grid för layouter som anpassar sig till varierande innehållslängder.

En typisk scen

Designern skapar en navigationsrad med 5 knappar, var och en exakt 100 px bred — ser bra ut på engelska.

Tysk översättning: 'Settings' blir till 'Einstellungen' (13 tecken jämfört med 8), 'Submit' blir till 'Absenden' (8 jämfört med 6). Navigationsfältet går över kanten.

Resultat: På mobilenheter staplas knapparna ovanpå varandra eller texten kapas, vilket gör navigeringen oanvändbar för tyska användare.

Varför är det här ett problem

Varje element med fast bredd är en potentiell brytpunkt. En typisk app har hundratals knappar, etiketter och kort som måste tåla textförlängning.

Kontainern med fast bredd (width: 120px) och knappar fast storlek klipper av innehåll eller flyter över när texten expanderar. CSS overflow: hidden döljer innehåll tyst, medan overflow: visible förstör layouet.

Användare ser kortade etiketter som 'Einstellu...' istället för 'Einstellungen', eller knappar som överlappar närliggande element. Kritiska åtgärder blir oläsliga eller oklikkbara.

Hur åtgärdar du det

Utforma och implementera flexibla layouter som anpassar sig till innehållslängden i alla lokaler.

Byt ut fasta bredder mot min-width, max-width och använd flex/grid layouter. Använd CSS Grid eller Flexbox för att dynamiskt fördela plats.

Ställ in textbehållare för radbrytning: använd overflow-wrap: break-word och undvik white-space: nowrap vid översättbart innehåll.

Testa din UI med pseudo-lokalisering som förlänger alla strängar med 40% för att simulera Worst Case — innan du skickar strängarna till översättare.

Fel #5: Datum- och talformattering

Data och siffror verkar universella. Men 01/02/2025 betyder den 2 januari i USA och den 1 februari i Europa. Kommatecken och decimaler byter betydelse i siffror: 1,000.50 (USA) jämfört med 1.000,50 (Sverige). Att göra det fel leder till förvirring, datafel och förlorat förtroende.

['Formatera aldrig data eller tal manuellt med strängmallar — använd alltid Intl API:er', 'Spara alla data i ISO 8601-format (YYYY-MM-DD) och valutor i den minsta enheten (cent) internt', 'Testa med lokalinställningar som använder olika decimaltecken, datumordning och kalendersystem']

Formatera aldrig data eller tal manuellt med strängmallar — använd alltid Intl-API:er.

Spara alla data i ISO 8601 och valutor i minsta enhet (cent) internt.

Testa med olika lokaler som använder olika decimalavskiljare, datumordning och kalendersystem.

Ett typiskt scenario

Utvecklaren formaterar ett datum som MM/DD/YYYY och ett pris som $1,234.50 — korrekt för amerikanska användare.

En tysk användare ser datumet 03/04/2025 och tolkar det som 3 april (DD/MM/YYYY-konventionen). Priset $1,234.50 ser ut som om det borde vara 1.234,50.

Resultat: användaren bokar en flygresa för ett felaktigt datum och ifrågasätter prisformatet. Supportärenden ökar på den tyska marknaden med 15%.

Varför är det problematiskt

Datum- och talformat påverkar varje data‑presentation i din app: tabeller, diagram, formulär, fakturor, rapporter. En global lösning täcker hundratals instanser.

Hårdkodade formatsträngar som toLocaleDateString('en-US') eller manuell formatering med templates ignorerar användarens språk. Även rätt lokal men fel kalender-system (Gregorian vs Hijri) orsakar problem.

Användare läser data fel och matar in dem i fel format. En europeisk användare som ser 03/04/2025 tolkar det kanske som 3 april istället för 4 mars — missade möten eller felaktiga bokningar.

Så här åtgärdar du det

Använd den inbyggda Intl-API:n eller ett lokalt anpassat formateringsbibliotek för alla datum, tider, tal och valutor.

Byt ut manuell formatering mot Intl.DateTimeFormat(locale) för datum och Intl.NumberFormat(locale, { style: 'currency', currency }) för priser.

Lagra uppgifterna internt i ISO 8601-format (YYYY-MM-DD) och formatera dem endast för visning med användarens lokala inställning.

Testa kritiska datum- och siffersignaleringar med minst fem olika lokalinställningar: en-US, de-DE, ja-JP, ar-SA och zh-CN, för att täcka de viktigaste formateringsvarianterna.

Fel #6: Glöm RTL-språk

Höger-till-vänster (RTL) språk som arabiska, hebreiska och persiska används av över 500 miljoner människor. Ändå utformas de flesta appar endast för vänster-till-höger (LTR) layout. RTL-stöd betyder inte bara att texten vänds — hela användargränssnittet måste speglas.

['Använd från första dagen uteslutande logiska CSS-egenskaper (inline-start/end, block-start/end)', "Testa din app med dir='rtl' på HTML-elementet vid varje sprintgranskning", 'Skapa en RTL-testchecklista för navigation, ikoner, formulär och framdrivningsindikatorer']

Använd från början endast logiska CSS-egenskaper (inline-start/end, block-start/end).

Testa din app med dir='rtl' på HTML-elementet vid varje sprintgranskning.

Skapa en RTL-testchecklista för navigation, ikoner, formulär och framstegsmätare.

Ett typiskt scenario

Utvecklaren använder margin-left: 16px och text-align: left genom hela appen — standard LTR-praxis.

Appen startar i Saudiarabien. Tillbakaknappen pekar framåt, sidofält visas på fel sida och numeriska data är feljusterade.

Resultat: arabiska användare lämnar appen efter 30 sekunder. Teamet behöver fyra veckor av akut CSS-omskrivning för att åtgärda problemet.

Varför är det ett problem

RTL-stöd berör varje enskild komponent i din app. Att lägga till RTL i efterhand kräver vanligtvis att skriva om 30–50% av CSS-reglerna och att testa varje ikon och layout.

CSS-egenskaper som margin-left, padding-right, text-align: left och float: left kodar riktningen fast. Ikoner med riktningsegenskaper (pilar, framstegindikatorer) pekar i fel riktning. Även border-radius-värden måste speglas.

Arabiska användare ser navigeringen i fel hörn, framstegsfältet går baklänges och texten kolliderar med UI-element. Appen känns främmande och oanvändbar.

Så här åtgärdar du det

Använd logiska CSS-egenskaper och testa RTL-layouten från början.

Byt ut alla fysiska CSS-egenskaper mot logiska motsvarigheter: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.

Ställ in dir-attributet på HTML-rootelementet baserat på den aktiva lokaliteten. Använd CSS-pseudoklassen :dir(rtl) för RTL-specifika överskrivningar.

Kontrollera alla ikoner för riktning. Ersätt riktningsoberoende ikoner med speglade versioner eller använd CSS transform: scaleX(-1) för RTL-sammanhang.

Fel #7: Bilder med text

Text i bilder att-innehålla i bilder — oavsett om i hero-banners, knappar, infografik eller skärmdumpar — är en lokaliseringsmardröm. Varje bild med text måste göras om för varje språk, vilket ökar designkostnaderna och fördröjer releaser.

['Aldrig bädda in översatt text direkt i rasterbilder (PNG, JPG)', 'Använd CSS-textöverlägg på bakgrundsbilder för hero-banners och CTA:er', 'Automatisera skärmdumpsgenereringen för App Store-listningar och marknadsföringssidor']

Lägg aldrig översättbar text direkt i rasterbilder (PNG, JPG).

Använd CSS-textöverlägg på bakgrundsbilder för hero-banners och CTA:er.

Automatisera skärmdumpsgenereringen för App Store-listningar och marknadsföringssidor.

Ett typiskt scenario

En formgivare skapar en kampanjbanner med texten 'Start Your Free Trial' inbäddad direkt i bilden.

Lokaliseringsteamet översätter alla UI-strängar, men bannern visar fortfarande engelsk text på den tyska sidan.

Resultat: den tyska landningssidan har ett irriterande engelskt banner. Att skapa lokala banners för 15 språk tar tre dagar av designarbete och fördröjer lanseringen.

Varför är det ett problem

Typisk en marknadsföringssida har 5–10 bilder med text. På 15 språk blir det 75–150 bildvarianter som måste skapas, underhållas och uppdateras vid varje designändring.

Text som är inbäddat i bilder (PNG, JPG, SVG med inbäddat text) kan inte extraheras av översättningsverktyg. Varje lokaliserad version kräver att en formgivare manuellt redigerar källfilen, exporterar och laddar upp den.

Användare ser bilder med text på ett främmande språk, eller ännu värre, en blandning av översatt UI och oöversatta bilder. Det känns inkonsekvent och undergräver varumärkets förtroende.

Så här åtgärdar du det

Dela texten från bilderna med hjälp av CSS-överlägg, SVG:er med översättbara textfält eller dynamisk bildgenerering.

Använd CSS för att placera den översatta texten ovanpå bakgrundsbilderna: placera textlagret med absolut positionering ovanför bildbehållaren.

För infografik eller diagram, använd SVG:er med <text>-element som refererar till översättningsnycklarna, istället för att bädda in råa strängar.

För app-skärmdumpar i marknadsföringsmaterial automatisera skärmdumpsgenereringen med verktyg som Fastlane (Mobil) eller Playwright (Web), som tar skärmbilder i varje lokalisering.

Fel nr 8: Otillräckligt hanterade saknade översättningar

Översättningar under utvecklingen är alltid ofullständiga. Nya funktioner lägger till strängar snabbare än översättarna hinner översätta dem. Utan riktig fallback-behandling orsakar saknade översättningar krascher, tomma UI-element eller råa översättningsnycklar som visas för användarna.

['Alltid konfigurera minst ett fallback-språk i din i18n-inställning', 'Logga saknade översättningsnycklar till ditt övervakningssystem för uppföljning', 'Sätt en minsta översättningstäckning innan en lokalitet får gå live']

Konfigurera alltid minst ett fallback-språk i din i18n-inställning.

Logga saknade översättningsnycklar till ditt övervakningssystem för uppföljning.

Sätt en minsta översättningsnivå innan en locale går live.

Ett typiskt scenario

Utvecklaren lägger till ett nytt avsnitt 'Premium Features' med 15 nya översättningsnycklar. Engelsk version levereras omedelbart.

Franska översättningar är fortfarande inte klara. Den franska sidan visar råa nycklar: 'premium.feature1.title', 'premium.feature1.description'.

Resultat: Franska användare ser en trasig sida full med utvecklarnamn på nycklar. Supportteamet får hundratals bug-rapporter.

Varför är det ett problem

Ju större din app blir, desto större blir glappet mellan engelska strängar och översättningar till andra språk. En app med 100 språk och 2000 strängar kan när som helst ha över 10 000 saknade översättningar.

Utan fallback-logik returnerar ett saknat översättningsnyckel undefined, null eller den råa nyckelsträngen (t.ex. 'checkout.confirmButton'). Template-motorer kan orsaka fel, sidan kraschar eller renderar ingenting.

Användare ser ett trasigt användargränssnitt: tomma knappar, saknade etiketter eller kryptiska strängar som 'nav.settings.title' i stället för riktig text. Det är förvirrande och oprofessionellt.

Så här åtgärdar du det

Konfigurera ett robust fallback-kedja och övervaka översättningsomfånget över alla lokaler.

Ställ in ett fallback-språk i din i18n-konfiguration: saknade franska nycklar returnerar automatiskt till engelska (en).

Lägg till en hanterare för saknade nycklar som loggar oföröversatta nycklar till ditt övervakningssystem (t.ex. Sentry, Datadog) utan att avbryta användarupplevelsen.

Skapa en översättningstäckningsdashboard som spårar färdigställandet per locale och blockerar releaser när täckningen faller under en tröskel (t.ex. 95%).

Fel #9: Teckenkodningsproblem

Kodningsproblem är de tysta mördarna för lokalisering. Allt ser bra ut på engelska och europeiska språk, men så snart du lägger till kinesiska, japanska, koreanska, arabiska eller emojis uppstår förvrängda tecken (Mojibake). Dessa buggar är kända för att vara svåra att upptäcka.

['Alltid använd UTF-8-kodning överallt — i källkoden, databasen, API-svaren och HTML-meta-tagar', 'Använd utf8mb4 i MySQL (inte bara utf8), för att stödja hela Unicode-området inklusive emojis', 'Testa med verkligt innehåll i CJK, arabiska och emoji för att tidigt fånga kodningsproblem']

Använd UTF-8-kodning överallt — källfiler, databas, API-svar och HTML-meta-taggar.

Använd utf8mb4 i MySQL (inte utf8) för att stödja hela Unicode-området inklusive emojis.

Testa med riktigt innehåll i CJK, arabiska och emoji för att fånga kodningsproblem tidigt.

Ett typiskt scenario

Utvecklaren konfigurerar en MySQL-databas med latin1-sortering (gammal standard). Applikationens källkod använder UTF-8.

Japanska användare registrerar sig med sitt riktiga namn. Databasen sparar '田中太郎' som skadade bytes.

Resultatet: användarens profil visar förvrängd text. Värre är att sökning och sortering kraschar för alla CJK-namn, vilket påverkar tusentals användare.

Varför är det ett problem

Kodningsproblem sprider sig över hela stacken. En felkonfigurerad databas-kollation kan skada miljontals poster — reparationen kräver kostsamma data-migreringar.

Inkonsistent kodning över hela stacken — UTF-8 i källkoden, Latin-1 i databasen och Windows-1252 i API-svaret — förstör multibyte-tecken. En enda felkonfigurerad skikt gör att '日本語' blir till '????'.

Användare ser förvrängda texter, frågetecken eller tomma rutor där deras språk borde vara. I värsta fall kan formulärinmatningar skadas permanent i databasen.

Så här löser du det

Säkerställ en konsekvent UTF-8-kodning på varje skikt i din applikationsstack.

Ställ in alla källfiler till UTF-8 (konfigurera din redigerare och .editorconfig). Lägg till <meta charset='UTF-8'> i din HTML och 'Content-Type: application/json; charset=utf-8' i API-svaren.

Konfigurera din databas till utf8mb4 (inte bara utf8, som i MySQL är en 3-bytes-subset). Ställ in anslutningskollationen till utf8mb4_unicode_ci.

Välj teckensnitt som täcker dina målteckensystem: Latinenska, Kirilliska, CJK, Arabiska och Devanagari. Använd systemfont-stackar eller Google Fonts med språksunderfält för optimal laddning.

Testa din i18n-implementering

Längdförlängningstest

Öka alla översatta strängar med 30–40 %, för att simulera textökningen som förekommer i språk med rik vokabulär som tyska, finska eller grekiska. Detta täcker behållare med fast bredd, avklippta etiketter och överflödiga knappar innan du börjar översätta. Många pseudo-lokaliseringsverktyg erbjuder detta som en inbyggd funktion.

"Skicka" → "Ṡééééñðéñ_éxpáñðéð" (40 % längre)

Pseudo-lokalisering

Pseudospråklokalisationen ersätter varje tecken med en accentuerad motsvarighet (t.ex. 'a' → 'á') och omger strängar med markörer som [!! och !!]. Det gör omedelbart tydligt vilka strängar som är hårdkodade och vilka som kommer från översättningssystemet. Kör pseudospråk-lokalisering som en del av din CI-pipeline för att automatiskt fånga regressioner.

Varje text på skärmen som inte är inuti [!! !!]-markeringar är hårdkodat och måste flyttas ut till lokalisering. Denna test fångar 95% av förbisedda strängar på under en minut.

"Skicka meddelande" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"

RTL-layouttest

Även utan arabiska eller hebreiska översättningar kan du testa RTL-layout genom att lägga dir='rtl' på ditt HTML-rootelement. Detta avslöjar omedelbart riktinstrukter CSS-buggar: felaktigt justerade ikoner, marginaler på fel sida, trasig navigering och felaktigt sorterade flex-element. Gör det till en standardkontroll i varje sprintgranskning — det tar 10 sekunder att växla och fångar problem som annars skulle ta veckor att åtgärda i produktionen.

i18n-checklistan

['Alla användarens synliga strängar är flyttade till resursfiler', 'Använd inte sträng-konkatenation för bildandet av meningar', 'Regler för plural används med ICU MessageFormat eller motsvarande implementerad', 'Datums-, tids- och talformattering använder lokalanpassade API:er', 'RTL-layout testad med arabiskt eller hebreiskt innehåll', 'Flexibla UI utan fasta bredder för textinnehåll', 'Konfigurerat fallback-språk och testat vid saknade nycklar', 'UTF-8-kodning över alla filer och databaser konsekvent', 'Metadatan för App Store och Play Store lokalisera för varje marknad', 'Skärmbilder och marknadsföringsmaterial för varje språk uppdaterade']