10 algemene i18n-foute en hoe jy hulle vermy
Leer die mees algemene internasionale lokaliseringfoute wat ontwikkelaars maak, en hoe jy hulle kan regstel. Verbeter die lokaliseringkwaliteit van jou app met hierdie beste praktyke.
Internasionalisering (i18n) lyk maklik â totdat jy agterkom dat jou Duitse gebruikers afgesnyde knoppies sien, jou Japannese gebruikers geknikte sinfragmente kry en jou Arabies-sprekende gebruikers heeltemal kapotte uitleg beleef. Dit is nie randgevalle nie. Dit is die voorspelbare gevolgtrekkings van algemene foute wat die meeste ontwikkelingspanne maak wanneer hulle vir die eerste keer lokalisering aanpak. In hierdie gids gaan ons die 10 mees algemene i18n-foute deur, verduidelik presies waarom hulle gebeur, en wys jy stap vir stap hoe jy elkeen oplos. Of jy nou ân nuwe app bou, of ân bestaande een opgradeer â hierdie valkuiles vermy, spaar jou weke aan debugging en lewer ân gepoleerde ervaring vir wĂȘreldwye gebruikers.
Fout #1: Hardgekodeerde stringe
Hardkodering van strings is die basiese i18n-fout. Dit gebeur omdat ontwikkelaars eers daarop fokus om funksies aan die gang te sit, en beplan om dit later op te ruim. Maar later kom nooit, en skielik het jy duisende strings versprei oor honderde lĂȘers.
['Stel jou i18n-ramwerk op voordat jy die eerste lyn UI-kode skryf', 'Gebruik ân linter-æ件 om hardgekodeerde strings in Templates en Komponente te herken', 'Hou vertaal-sleutels beskrywend en georganiseer volgens funksie of blad']
Richte jouw i18n-ramwerk op voordat jy die eerste UI-reël skryf.
Gebruik 'n lint-plugin om hardgekodeerde strings in templates en komponente op te spoor.
Houd vertaal-sleutels beskrywend en georganiseerd volgens funksie of bladsy.
Een tipiese sytuasie
ân Ontwikkelaar skryf ân Knoppie-etiket direk in JSX: <button>Submit Order</button>.
Die app word in Engels uitgereik en werk soepel. Ses maande later brei die onderneming uit na Duitsland.
Diei Lokaliseringsteam ontdek 2.000+ hardgekodeerde strings. Die terugbou duur 3 weke en veroorsaak 47 bugs.
Waarom dit ân probleem is
In ân volwaardige kodebasis kan hardgekodeerde strings in die duisende loop. Hulle uit te skraap nĂĄ die feit vereis om elke lĂȘer aan te raak, elke komponent weer te toets en regressesies oor al die plekke te risiko.
Hardgekodeerde strings is direk in bronkode, templates of komponentes ingebed. Hulle kan nie uitgetrek, vertaal of tyd-gestuur word sonder om die kode self te verander.
Nuttigers in nie-Engelse locales sien on-vertaalde UI-elemente gemixed met vertaalde inhoud â ân chaotiese en onprofessionele indruk.
So behels jy dit
Lewer alle nutters sigbare strings van die begin in hulpbronlĂȘers uit.
Stel ân vertaalraamwerk op voordat jy jou eerste komponent skryf (bv. next-intl, react-i18next, vue-i18n).
Skep ân hulpbron-lĂȘerstruktuur (bv. messages/de.json) en verwys al die strings via sleutel soos t('checkout.submitButton').
Voeg ân linter-regel of ân Pre-Commit-Hook by wat raw string literals flag.
Fout #10: Alles woord-vir-woord vertaal.
Nie alle inhoud moet vertaal word nie. Handelsname, name van regsentiteite, tegniese terme en sekere produknamen moet in hul oorspronklike taal bly. Oormatige vertaling kan regsprobleme, handelsmerk-inkonsekwentheid en gebruikersverwarring veroorsaak.
["Onderhou 'nie-vertaal'-glossarium en deel dit met alle vertalers", 'Gebruik gesperde segmente of afsonderlike naamruimtes vir handelsname- en regsbegrippe', 'Voorsien altyd konteksnotas vir meerduidige strings om verkeerde vertalings te voorkom']
Pflege ein 'Nicht ĂŒbersetzen'-Glossar und teile es mit allen Ăbersetzern.
Nutze gesperrte Segmente oder separate Namespaces fĂŒr Marken- und Rechtsbegriffe.
Stelle immer Kontextnotizen fĂŒr mehrdeutige Strings bereit, um FehlĂŒbersetzungen zu verhindern.
ân Tipiese scenario
ân VertaallĂȘer bevat die maatskappynaam 'CloudForge Inc.' en die tegniese term 'OAuth 2.0 Token' as regulier vertaalbare strings.
Die Spaanse vertaler vertaal 'CloudForge' na 'ForjaNube' en 'OAuth 2.0 Token' na 'ficha OAuth 2.0'.
Resultaat: Gebruikers vind die maatskappy nie onder sy regte naam nie, en ontwikkelaars wat die Spaanse dokumentasie lees, raak verward deur onbekende vertaalde vakterme.
Waarom dit ân probleem is
Een verkeerd vertaalde handelsnaam in ân regsverklaring kan kontrakte ongeldig maak. Om elke string in elke taal na te gaan en reg te stel, verg ân projek wat baie weke tot maande kan duur.
Wanneer al die strings sonder konteks aan die vertaling gestuur word, kan vertalers moontlik handelsname ('Apple' â 'Apple'), regsbegrippe ('GmbH' â 'LLC') of tegniese benamings wat in Engels bly, vertaal.
Gebruikers vind nie produkte onder hul bekende handelsnaam nie, regsdocumente verwys na die verkeerde maatskappy, en tegniese dokumentasie word onduidelik as terme soos 'API Endpoint' vertaal word.
Hoe om dit reg te stel
Merk duidelik nie-vertaalbare inhoud uit en voorsien konteksnota's vir vertalers.
Skep 'nie-vertaal'-glossarium wat alle handelsname, produknamen, regsentiteite en tegniese terme lys wat onverander bly.
Gebruik 'n afsonderlike naamruimte of spesiale sleutels vir nie-vertaalbare inhoud. Baie i18n-instrumente ondersteun 'gesperde' segmente wat vertalers nie kan wysig nie.
Voeg vertaaler-kommentaar/beskrywings by jou vertaalingslĂȘers wat die konteks verduidelik: 'Dit is 'n handelsnaam â nie vertaal nie' of 'Vakterm â laat Engels'.
Fout #2: Stringverketteling
Suitselyn uit senuwees saamkleep lyk logies in Engels maar nie in ander tale nie. Woordvolgorde, grammatika en sinstruktuur verskil getrou tussen tale, wat gekoppelde strings onvertaalbaar maak.
['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']
Bou nooit sinne deur die samevoeging van vertaalde fragmentte nie.
Bruk navngitte plassholdere ('{name}') i stedet for posisjonelle ({0}) for klarhet
Bied kontekskommentaar aan vir vertalers wat verduidelik wat elke plekhouer bevat.
'n Tipiese scenario
Ontwikkelaar skryf: 'You have ' + count + ' items in your ' + cartType + ' cart' â werk perfek in Engels.
Die Duitse vertaler kry drie aparte fragmentte en kan nie ân grammatikal korrekte sin bou nie, omdat die woordorde verander moet word.
Resultaat: Duitse gebruikers sien 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' â holprig en onprofessioneel.
Waarom dit ân probleem is
Elk gekoppelde string is ân tikkende tydbom. By 20 tale en 50 gekoppelde strings het jy 1 000 potensiĂ«le grammatika-foute wat handmatig reggestel moet word.
String-Verkettung soos 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' zet ân spesifieke woordorde voor. Vertalers ontvang kontekslose fragmenten wat hulle nie kan herordiĂ«nteer nie.
Gebruikers sien grammatikaal verkeerde sinne. In Duits staan die werkwoord dikwels aan die einde. In Arabies is die hele struktuur omgedraai. Die uitkoms lees soos nonsens.
So los jy dit op
Gebruik benoemde plaasvervangers ({name}) in plaas van posisionele ({0}) vir duidelikheid, sodat vertalers die hele sin kan herstruktureer.
Erstatt sammensetting med en enkelt meldingsnĂžkkel med plassholdere: 'cart.summary': 'Du har {count} varer i din '{cartType}'-handlekurv'.
Gee veranderlikes as parameters aan jou vertaalfunksie: t('cart.summary', { count: 5, cartType: 'Premium' }).
Oversettere kan nĂ„ fritt omorganisere: 'Din '{cartType}'-handlekurv har {count} varer' â grammatisk korrekt tysk.
Fout #3: Meervoudvorming ignoreer
Engels het twee meervoudsvorme: enkelvoud en meervoud. Ontwikkelaars dink dikwels dat alle tale presies dieselfde werk. Hulle is nie. Pools het 4 vorme, Arabies het 6, en selfs tale soos Frans behandel nul anders as Engels.
['Gebruik altyd ICU MessageFormat of ân gelykwaardige biblioteek vir telbare inhoud', 'Skryf nooit eie meervoud-logika nie â vertrou die CLDR-reĂ«ls', 'Toets meervale met waardes soos 0, 1, 2, 5, 21 en 100 om alle kategorieĂ« te dek']
Skryf nooit eie meervoudlogika nie â vertrou die CLDR-reĂ«ls.
Toets meervoude met waardes soos 0, 1, 2, 5, 21 en 100 om alle kategorieë te dek.
Skryf nooit eie meervoudlogika nie â vertrou die CLDR-reĂ«ls.
'n Tipiese scenario
Ontwikkelaar skryf: count + (count === 1 ? ' lĂȘer' : ' lĂȘers') â behandel Duits korrek.
Die Poolse vertaler benodig 4 vorme: 1 plik, 2-4 pliki, 5-21 plikĂłw, 22-24 pliki. Die eenvoudige ternĂȘre kan dit nie uitdruk nie.
Resultaat: Poolse gebruikers sien '5 pliki' (fout vorm) in plaas van '5 plikĂłw' (korrekte vorm), en die app lyk kapot.
Waarom dit ân probleem is
Elk telbare selfstandige naamwoord in jou toepassing benodig meervoudbehandeling. By 50 sulke strings en 20 tale is dit 1 000 meervoudreĂ«ls â onmoontlik om handmatig te bestuur.
Eenvoudige if/else-toetse (count === 1 ? 'Datei' : 'Dateien') behandel net Duits/Engels. Die CLDR definieer tot ses kategorieĂ«: zero, one, two, few, many en other. Elke taal gebruik ân ander subset.
Gebruikers sien grammatikaal verkeerde tekste soos '1 boodskap' of heeltemal verkeerde meervoudsvorme. In formele kontekste vernietig dit die geloofwaardigheid.
Hoe los jy dit op
Gebruik ICU MessageFormat, wat alle CLDR-meervoud-regels uit die doos self ondersteun.
Definieer boodskappe met ICU-sintaksis: 'fileCount': '{count, plural, one {# lĂȘer} other {# lĂȘers}}'.
Vertalers stel alle benodigde meervoudsvorme vir hul taal beskikbaar. Pools: '{count, plural, one {# plik} few {# pliki} many {# plikĂłw} other {# pliku}}'.
Jou i18n-biblioteek kies tydens uitvoering outomaties die korrekte vorm gebaseer op die CLDR-reëls van die aktiewe locale.
Fout #4: Vas UI-element breedtes
Ontwerpers skep pixel-nauwkeurige uitlegte in Engels, en ontwikkelaars implementeer hulle met vaste breedtes. Maar vertaalde teks kan dramaties langer of korter wees. Duitse teks is omtrent 30% langer as Engels, terwyl Chinese teks 50% korter kan wees.
['Gebruik nooit vaste pixel-breedtes vir elemente met vertaalbare teks nie', 'Beplan vir 40% teksuitbreiding as basline â sommige tale expander nog meer', 'Gebruik CSS Flexbox of Grid vir lay-outs wat aan veranderlike inhoudslengtes pas']
Gebruik nooit vaste pixelwydtes vir elemente met vertaalbare teks nie.
Beplan vir ân 40% teksuitbreiding as basislyn â sommige tale brei nog meer uit.
Gebruik CSS Flexbox of Grid vir lay-outs wat aan wisselende inhoudslengtes pas.
ân Typiese scenario
Ontwerper skep 'n navigasie-balk met 5 knoppies, elk presies 100 px wyd â lyk op Engels fantasties.
Vertaling: 'Settings' word 'Instellings' (13 teenoor 8 tekens), 'Submit' word 'Dien in' (8 teenoor 6). Die navigasie-balk loop oor.
Resultaat: op mobiele toestelle stap knoppies oor mekaar op, of teks word afgesny, wat die navigasie vir Duitse gebruikers onbruikbaar maak.
Waarom dit 'n probleem is
Elk element met vaste breedte is ân potensiĂ«le breekpunt. ân Tipiese toepassing het honderde knoppies, etikette en kaarte wat almal teksuitbreiding moet kan hanteer.
Kontainer met vaste breedte (width: 120px) en knoppies van vaste grootte sny af of loop oor as teks uitbreid. CSS overflow: hidden verberg inhoud stilweg, terwyl overflow: visible die uitleg verbreek.
Nutzer sien afgesnyde labels soos 'Einstellu...' instead of 'Einstellungen', of knoppies wat aangrensende elemente oorlappe. Kritieke aksies word onleesbaar of onklikbaar.
Hoe-beheb jy dit
Ontwerp en implementeer buigsame lay-outs wat die inhoudslengte van alle lokalisasies kan hanteer.
Vervang vaste breedtes deur min-width, max-width en Flex-layouts. Gebruik CSS Grid of Flexbox om ruimte dinamies te versprei.
Stel tekskonteine op vir breeklinies: gebruik overflow-wrap: break-word en vermy white-space: nowrap by vertaalbare inhoud.
Toets jou UI met pseudo-lokalisering wat al die teks met 40% verleng om die worst-case-scenario te simuleer â nog voordat jy tekste aan vertalers stuur.
Fout #5: Datum- en getalformaat
Datum- en getalformatering raak elke data-aanbieding in jou toepassing: tabellen, diagramme, vorms, fakture, verslae. ân Globale oplossing dek honderde instansies.
['Vanaf dag een gebruik slegs logiese CSS-eienskappe (inline-start/end, block-start/end)', 'Toets jou app met dir='rtl' op die HTML-element by elke sprint-Review', 'Maak ân RTL-toetslys vir navigasie, ikone, vorms en vorderingwyses']
Formateer data of getalle nooit handmatig met string-templates nie â gebruik altyd Intl-API's.
Stoor al die data in ISO 8601 en geldeenhede in die kleinste eenheid (sent) intern.
Toets met lokalisasies wat verskillende desimale skeidingstekens, datumsvolgorde en kalendersstelsels gebruik.
'n tipiese scenario
Ontwikkelaars formatteer ân datum as MM/DD/YYYY en ân prys as $1,234.50 â korrek vir Amerikaanse gebruikers.
ân Duitse gebruiker sien die datum 03/04/2025 en lees dit as 3 April (DD/MM/YYYY-konvensie). Die prys $1,234.50 lyk asof dit 1.234,50 behoort te wees.
Resultaat: Die gebruiker bespreek ân vlug vir die verkeerde datum en bevraagteken die pryse-formaat. Ondersteuningskaartjies styg in die Duitse mark met 15%.
Waarom dit 'n probleem is
Datum- en getalformatering raak elke data-aanbieding in jou toepassing: tabellen, diagramme, vorms, fakture, verslae. ân Wereldwye oplossing dek honderde instansies.
Hardgekodeerde formaatstringe soos toLocaleDateString('en-US') of handmatige formaatering met Template-Literals ignoreer die werklike locale van die gebruiker. Selfs die korrekte locale maar die verkeerde kalender-stelsel (Gregorianies vs. Hijri) veroorsaak probleme.
Gebruikers lees data verkeerd en voer data in in die verkeerde formaat. ân Europese gebruiker wat 03/04/2025 sien, interpreteer dit moontlik as 3 April in plaas van 4 Maart â gemiste afsprake of verkeerde boekings.
So los jy dit op
Gebruik die ingeboude Intl-API of 'n locale-georiënteerde formaatbiblioteek vir alle data, tye, getalle en valuta.
Vervang manuele formatering deur Intl.DateTimeFormat(locale) vir datums en Intl.NumberFormat(locale, { style: 'currency', currency }) vir pryse.
Stoor data intern in ISO 8601-formaat (YYYY-MM-DD) en formatteer dit slegs vir vertoon volgens die gebruiker se locale.
Toets kritieke datum-/getalvertonings met minstens 5 verskillende lokaliteite: en-US, de-DE, ja-JP, ar-SA en zh-CN, om die belangrijkste formaatvariante te dek.
Fout #6: RTL-sprachen vergeet
Regs-na-lyn (RTL) tale soos Arabies, Hebreeuws en Persies word deur meer as 500 miljoen mense gebruik. Tog word die meeste toepassings net vir links-na-rechts (LTR) uitleg ontwerp. RTL-ondersteuning beteken nie net tekse om te draai â die hele UI moet gespieĂ«l word.
['Vanaf dag een gebruik slegs logiese CSS-eienskappe (inline-start/end, block-start/end)', "Toets jou app met dir='rtl' op die HTML-element by elke sprint-Review", 'Maak ân RTL-toetslys vir navigasie, ikone, vorms en vorderingwyses']
Gebruik vanaf die eerste dag uitsluitlik logiese CSS-eienskappe (inline-start/end, block-start/end).
Toets jou app met dir='rtl' op die HTML-element by elke sprint-resensie.
Skep ân RTL-toetslys vir navigasie, ikone, vorms en vorderingswysers.
'n Typiese scenario
Die ontwikkelaar gebruik margin-left: 16px en text-align: left oor die hele app â standaard-LTR-praktyk.
Die App begin in Saoedi-Arabië. Terug-knoppies wys vorentoe, kantbalkies verskyn aan die verkeerde kant, en numeriese data is verkeerd uitgelig.
Resultaat: Arabiese gebruikers verlaat die app na 30 sekondes. Die span benodig 4 weke vir noodgeval CSS-herstruktuur om die probleem op te los.
Waarom dit ân probleem is
RTL-ondersteuning raak elke komponent in jou app. RTL-ondersteuning nå-invoering vereis gewoonlik die herskryf van 30-50% van alle CSS-reëls en die beoordeling van elke ikon en uitleg.
CSS-eienskappe soos margin-left, padding-right, text-align: left en float: left hardkodeer die rigting. Ikone met rigtingsbetekenis (pyle, vorderingswysers) wys in die verkeerde rigting. Self border-radius-waardes moet gespiegeld word.
Arabiese gebruikers sien Navigasie in die verkeerde hoek, voortgangsbalkies loop terug, en teks wat met UI-elemente bots. Die app voel vreemd en onbenuttbaar.
So los jy dit op
Gebruik logiese CSS-eienskappe en toets vanaf die begin met RTL-lay-out.
Vervang alle fisiese CSS-Eienskappe deur logiese ekwivalente: margin-left â margin-inline-start, padding-right â padding-inline-end, text-align: left â text-align: start.
Stel die dir-attribuut op jou HTML-rootelement in volgens die aktiewe Locale. Gebruik die :dir(rtl) CSS-pseudoklasse vir RTL-spesifieke Overrides.
Toets alle ikon op rigtingsbetekenis. Vervang rigtingsgebonde ikone deur gespiegelde weergawes of gebruik CSS transform: scaleX(-1) vir RTL-kontexte.
Fout #7: Beelde met teks
Tekst in beelde ingebed â hetsy in hero-banner, knoppies, infografieke of skermskote â is ân lokalisering-nag. Elke beeld met teks moet vir elke taal nuut gemaak word, wat ontwerp- en vrystellingskoste vermeerder.
['Plak vertaalbare teks nooit direk in rasterbeelde (PNG, JPG) nie', 'Gebruik CSS-teks-overlays op agtergrondbeelde vir hero-banners en CTAâs', 'Outomaties die skermprentgenerering vir App Store-lysings en bemarkingsbladsye']
Bette ĂŒbersetzbaren Text niemals direkt in Rasterbilder (PNG, JPG) ein.
Nutze CSS-Text-Overlays auf Hintergrundbildern fĂŒr Hero-Banner und CTAs.
Automatisiere die Screenshot-Generierung fĂŒr App Store Listings und Marketing-Seiten.
ân Tipiese scenario
ân Ontwerper skep ân promosie-banner met die teks 'Start Your Free Trial' direk in die beeld ingebed.
Die lokaliseringspan vertaal al die UI-tekste, maar die banner wys op die Duitse bladsy steeds Engelse teks.
Resultaat: Die Duitse landingsbladsy het ân irriterende Engelse banner. Gelokaliseerde banners vir 15 tale neem 3 dae ontwerpwerk en vertraag die bekendstelling.
Waarom dit ân probleem is
ân Tipiese bemarkingsbladsy het 5-10 beelde met teks. By 15 tale is dit 75-150 beeldvariante wat geskep, onderhou en by elke ontwerpverandering opgedateer moet word.
Tekst wat in beelde ingebed is (PNG, JPG, SVG met ingebed teks) kan nie deur vertaalhulpmiddels geĂ«kstraheer word nie. Elke gelokaliseerde weergawe vereis dat ân ontwerper die brondokument handmatig wysig, uitvoer en oplaai.
Gebruikers sien beelde met teks in ân vreemde taal, of erger nog, ân mengsel van vertaalde koppelvlak en onvertaalde beelde. Dit lyk onkonsekwent en ondermyn die merkvertroue.
So los jy dit op.
Skil teks van beelde af deur CSS-oorlays te gebruik, SVG's met vertaalbare teks-elemente of dinamiese beeldgenerering.
Gebruik CSS om vertaalbare teks oor agtergrondbeelde te sit: posisioneer die tekslaag met absolute posisionering oor die beeldkonteiner.
Vir infografieke of diagramme gebruik SVG's met <text>-elemente wat vertaal-keys verwys, eerder as rooi strings ingebed.
Vir app-skerms in bemarkingsmateriaal, maak die skermopnames outomaties met gereedskap soos Fastlane (Mobile) of Playwright (Web), wat skerms in elke locale neem.
Fout #8: Ontbrekende vertalings nie hanteer nie.
Vertalings is tydens ontwikkeling altyd onvolledig. Nuwe funksies voeg sneller strings by as wat vertalers dit kan vertaal. Sonder behoorlike fallback-handling veroorsaak ontbrekende vertalings storte, leë UI-elemente of rou vertaling-sleutels wat vir gebruikers vertoon word.
['Skep altyd ten minste een fallback-taal in jou i18n-stel', 'Log ontbrekende vertaal-sleutels na jou moniteringstelsel vir nasporing', 'Stel 'n minimum-vertalingdekking vas voordat ân lokaal live mag wees']
Konfiguriere altyd minstens een fallback-taal in jou i18n-setup.
Logge fehlende Ăbersetzungs-Keys an dein Monitoring-System zur Nachverfolgung.
Setze einen Mindest-Ăbersetzungsabdeckungsgrad, bevor eine Locale live gehen darf.
ân Tipiese scenario
Ontwikkelaars voeg ân nuwe 'Premium Features'-gebied by met 15 nuwe vertalings-sleutels. Die Engelse weergawe word dadelik uitgelaai.
Die Franse vertalings is nog nie klaar nie. Die Franse bladsy wys rou sleutels: 'premium.feature1.title', 'premium.feature1.description'.
Resultaat: Franse gebruikers sien ân vasgeklemde bladsy vol ontwikkelaar- sleutel name. Die ondersteuningspan kry Dozens Bug-Reports.
Warum dit ân probleem is
Hoe groter jou app, hoe groter die kloof tussen Engelse stringe en vertalings in ander tale. ân app met 100 tale en 2 000 stringe kan te eniger tyd 10 000+ ontbrekende vertalings hĂȘ.
Sonder fallback-logika gee ân ontbrekende vertaalkey undefined, null of die rou Key-string terug (bv. 'checkout.confirmButton'). Template-Engines kan foute gooi, die bladsy crash of niks render.
Gebruikers sien stukkende UI: leë knoppies, ontbrekende etikette of kryptiese strings soos 'nav.settings.title' in plaas van regte teks. Dit is verwarrend en onprofessioneel.
So behebst jy dit
Rig ân robuuste fallback-ketting op en monitor die vertaaldekkings oor alle lokales.
Rig ân fallback-taalketting in jou i18n-konfigurasie in: ontbrekende Franse (fr) Sleutels val automatisch terug na Engels (en).
Voeg 'n Missing-Key-handler by wat onvertaalde sleutels na jou moniteringstelsel (bv. Sentry, Datadog) log, sonder om die gebruikerservaring te verbreek.
Skep 'n vertaaldekking-dashboard wat die voltooiingsgraad per lokalisering opspoor en vrystellings blokkeer as die dekking onder ân drempelwaarde val (bv. 95%).
Fout #9: tekenkodeeringsprobleme
Kodeeringsprobleme is die stille moordenaar van lokalisering. Alles lyk goed in Engels en Europese tale, maar sodra jy Chinees, Japannese, Koreaanse tale, Arabiese tale of Emoji byvoeg, verskyn verwronge tekens (Mojibake). Hierdie foute is berug moeilik om op te spoor.
['Gebruik UTF-8-kodering oral â brontekste, databasis, API-antwoorde en HTML-meta-tags', 'Gebruik utf8mb4 in MySQL (nie net utf8 nie), om die volle Unicode-bereik insluitend Emoji te ondersteun', 'Toets met regte inhoud in CJK, Arabies en Emoji om koderingprobleme vroeg te vang']
Verwende UTF-8-Kodierung ĂŒberall â Quelldateien, Datenbank, API-Antworten und HTML-Meta-Tags.
N use utf8mb4 in MySQL (nie utf8), om die volle Unicode-bereik insluitend emoji te ondersteun.
Toets met regte inhoud in CJK, Arabies en emoji om koderingprobleme vroeg te fangen.
ân Tipiese scenario
Ontwikkelaars stel ân MySQL-databasis met latin1-kollasie op (die ou standaard). Die app-bronkode gebruik UTF-8.
Japaniese gebruikers registreer hul werklike naam. Die databasis stoor 'ç°äžć€Șé' as beskadigde bytes.
Resultaat: Die Nutzerprofiel wys verstĂŒmmelten Text. Nog erger: Soek en Sortering breek vir alle CJK-namen, wat duisende gebruikers raak.
Warum dit ân probleem is
Kodeeringsprobleme versprei deur jou hele stack. ân verkeerde gekonfigureerde databasis-kollasie kan miljoene rekords beskadig â die herstel vereis duur data-migrasies.
Inkonsistente Kodering oor die Stack heen â UTF-8 in die Quelldateien, Latin-1 in die Databasis en Windows-1252 in die API-antwoorde â vernietig Multibyte-tekens. ân Eenige verkeerd gekonfigureerde laag kan 'æ„æŹèȘ' verander na '????' of 'ĂŠâ„ÊĆÂŹĂšÂȘ'.
N gebruikers sien misvormde tekste, vrae-teken of leë vakke waar hulle taal behoort te wees. In die ergste geval kan formulierinsette permanent in die databasis beskadig word.
So los jy dit op
Stel konsekwente UTF-8-kodering oor elke laag van jou Application Stack.
Stel al jou brontekste op UTF-8 in (konfigureer jou redakteur en .editorconfig). Voeg <meta charset='UTF-8'> by jou HTML en 'Content-Type: application/json; charset=utf-8' by API-antwoorde in.
Konfiguriere deine Datenbank op utf8mb4 (nie net utf8, wat in MySQL ân 3-Byte-Subset is). Set die Connection-Collation op utf8mb4_unicode_ci.
Kies lettertipes wat jou doel-skrifstelsels dek: Latynies, Kyrillies, CJK, Arabies en Devanagari. Gebruik System-Font-Stacks of Google Fonts met taal-subsets vir optimale laai.
Jou i18n-implementering toets.
Lengte-uitbrekingstoets
Verhoog alle vertaalde strings met 30-40% om die teksuitbreiding te simuleer wat in tale soos Duits, Fins of Grieks voorkom. Dit dek vensters met vaste breedte, afgeskorte etikette en oorskietende knoppies voordat jy begin vertaal.
"Stuur" â "áč ééééñðéñ_Ă©xpåñðéð" (40% langer)
Pseudo-lokalisering
Pseudo-lokalisering vervang elke teken deur 'n geaccentueerde ekwivalent (bv. 'a' â 'ĂĄ') en omring stringe met markeringe soos [!! en !!]. Dit maak dadelik sigbaar watter stringe hardgekodeer is en watter uit die vertalingstelsel kom. Voer pseudo-lokalisering uit as deel van jou CI-pyplyn om regressies outomaties vas te vang.
Elk teks op die skerm wat NIE binne [!! !!]-merkings ingesluit is, is hardgekodeer en moet uit die vertaalstelsel verwyder word. Hierdie toets vang 95% van die oorsiene strings in minder as een minuut.
"Boodskap stuur" â "[!! ĂåçងĆĂçងáč« áčĄĂ©Ă±Ă°Ă©Ă± !!]"
RTL-lay-outtoets
Selfs sonder Arabiese of Hebreeuse vertalings kan jy die RTL-lay-outtoets doen deur dir='rtl' by jou HTML-rootelement te voeg. Dit identifiseer direksionele CSS-foute onmiddellik: verkeerd uitgeliggde ikone, marges aan die verkeerde kant, stukkende navigasie en verkeerd gesorteerde Flex-items. Maak dit ân standaard-toets in elke sprint-resensie â dit neem 10 sekondes om oor te skakel en vang probleme wat anders weke aan regstellings in produksie sou neem.
Die i18n-Checkliste
['Alle gebruikerssigbare strings in hulpbronlĂȘers uitgelĂȘ', 'Geen string-konkatinasie om sinne te vorm nie', 'MeervoudigheidsreĂ«ls met ICU MessageFormat of soortgelyke tegnieke geĂŻmplementeer', 'Datums-, tyd- en getalformatering gebruik locale-ware APIs', 'RTL-lay-out getoets met Arabiese of Hebreeuse inhoud', 'Buigsame UI sonder vasgestelde breedtes vir teksinhoud', 'terugval-taal gekonfigureer en by ontbrekende sleutels getoets', 'UTF-8-kodering konsekwent oor alle lĂȘers en databasisse', 'App Store- en Play Store-metadate vir elke mark gelokaliseer', 'Skermprente en bemarkingsmateriaal vir elke taal opgedateer']