10 errors i18n més comuns i com evitar-los
Aprèn quins són els errors d'internacionalització més comuns que cometen els desenvolupadors i com solucionar-los. Millora la qualitat de la localització de la teva aplicació amb aquestes bones pràctiques.
La internacionalització (i18n) sembla senzilla — fins que descobreixes que els teus usuaris alemanys veuen botons tallats, els teus usuaris japonesos reben fragments de frases mutilats i els teus usuaris de parla àrab tenen dissenys del tot trencats. Aquestes no són consultes marginals. Són les conseqüències previsible de errors comuns que la majoria dels equips de desenvolupament cometen quan comencen a abordar la localització. En aquest guia revisarem les 10 i18n més comuns, expliquem exactament per què passen i et mostrarem pas a pas com solucionar cadascun. Tant si estàs construint una nova aplicació com si estàs actualitzant una existents — evitar aquestes dificultats t'estalviarà setmanes de depuració.
Error #1: Cadenes codificades en dur
Codificar textuals en lloc de gestionar-los en fitxers d\'recursos és l\'error i18n més fonamental. S\'ocorre perquè els desenvolupadors prioritzen fer que les funcions funcionin i planifiquen "netejar-ho més tard". Però després mai no arriba i, de cop, tens milers de textos dispersos per centenars de fitxers.
['Configura el teu i18n-framework abans d'escriure la primera línia de codi UI', 'Utilitza un plugin de linter per detectar strings codificats en plantilles i components', 'Mantén claus de traducció descriptives i organitzades per característica o pàgina']
Configura el teu i18n-framework abans d'escriure la primera línia del codi de la UI.
Utilitza un plugin de linters per detectar cadenes hardcodades en plantilles i components.
Mantingues les claus de traducció descriptives i organitzades segons la funcionalitat o la pàgina.
Un escenari típic
Un desenvolupador escriu una etiqueta de botó directament en JSX: <button>Submit Order</button>.
L\'aplicació es lliura en anglès i funciona a la perfecció. Seix mesos després, l\'empresa s\'expandix a Alemanya.
El equip de localització descobreix 2.000+ strings codificats. La posada en marxa tardà 3 setmanes i va provocar 47 errades.
Per què és un problema
En una base de codi avançada, els strings codificats manualment poden arribar a les milers. Extreure'ls després requereix tocar cada fitxer, tornar a provar cada component i arriscar regressions en tots els llocs.
Els strings codificats de forma fixa estan directly incrustats en el codi font, plantilles o components. No poden extreure's, traduir-se o canviar en temps d'execució sense modificar el propi codi.
Els usuaris en locales que no són l\'anglès veuen elements de la interfície no traduïts barrejats amb contingut traduït — una impressió caòtica i poc professional.
Això és com ho pots solucionar
Externalitza tots els texts visibles per a l\'usuari des del principi als fitxers de recursos.
Configura un marc d\'intercanvi de traduccions (p. ex. next-intl, react-i18next, vue-i18n) abans d\'escriure la primera component.
Crea una estructura de fitxers de recursos (p. ex. messages/de.json) i referència tots els textos mitjançant claus de traducció com t('checkout.submitButton').
Afegeix una regla de linting o un ganxo de pre-commit que marqui literals de cadena en components UI.
Error #10: Traduir tot literalment
No tot el contingut hauria ser traduït. Noms de marca, noms de persones jurídiques, termes tècnics i determinats noms de productes han de romandre en la llengua original. La traducció en excés pot provocar problemes legals, incoherència de marca i confusió entre els usuaris.
["Mantingueu un glossari de 'No traduir' i comparteu-lo amb tots els traductors", 'Utilitza segments bloquejats o espais de noms separats per a marques i termes jurídics', 'Sempre proporciona notes de context per a cadenes ambigus per evitar traduccions incorrectes']
Mantén un glossari de 'No traducir' i comparteix-lo amb tots els traductors.
Utilitza segments bloquejats o namespaces separats per a termes de marca i de drets.
Proporciona sempre notes de context per cadenes ambiguës, per evitar malenteses en la traducció.
Un escenari típic
Una fitxer de traducció conté el nom de la companyia 'CloudForge Inc.' i el terme tècnic 'OAuth 2.0 Token' com a strings tradueibles normals.
El traductor espanyol tradueix 'CloudForge' com 'ForjaNube' i 'OAuth 2.0 Token' com 'token OAuth 2.0'.
Resultat: l'usuari no troba l'empresa pel seu nom real, i els desenvolupadors que llegeixen la documentació en espanyol es confonen pels termes tècnics no traduïts.
Per què això és un problema
Un únic nom de marca mal traduit en un document legal pot tornar els contractes invàlids. Corregir traduccions en excés requereix revisar cada cadena en cada idioma — una tasca de diverses setmanes.
Quan tots els strings s'envien sense context a la traducció, els traductors poden traduir noms de marca ('Apple' → 'Apfel'), termes legals ('GmbH' → 'LLC') o termes tècnics que han de romandre en anglès.
Els usuaris no troben productes sota el seu nom de marca conegut, documents legals fan referència a la societat incorrecta, i la documentació tècnica es torna incomprensible si termes com 'API Endpoint' es tradueixen.
Com resoldre-ho
Separa clarament continguts que no són tradueixos i proporciona notes de context per als traductors.
Crea un glossari de 'No traduir' que inclogui tots els noms de marca, noms de producte, persones jurídiques i termes tècnics que han de romandre inalterats.
Utilitza un espai de noms separat o claus especials per a continguts que no s'han de traduir. Molts eines i18n admeten segments 'bloquejats' que els traductors no poden editar.
Afegeix comentaris/descripcions per als traductors als teus fitxers d'i18n que expliquin el context: 'Aquest és un nom de marca — no traduir' o 'Term tècnic — deixar en anglès'.
Error #2: Concatenació de cadenes
Les frases formades amb fragments d\'una manera conjunta poden semblar lògiques en anglès, però en altres idiomes l\'ordenen de les paraules i la gramàtica canvien considerablement, fent que els fragments concatenats siguin intranslatius.
['No construeix mai frases concatenant fragments traduïts', 'Utilitza marcadors de posició amb nom ('{name}') en lloc de posicional ({0}) per a claredat', 'Proporciona comentaris de context per als traductors que expliquin què conté cada marcador de posició']
No construeix frases enllaçant fragments traduïts.
Utilitza marcadors de posició amb nom ('{name}') en lloc de posicional ({0}) per a claredat
Proporciona comentaris de context per als traductors que expliquin què conté cada marcador de posició
Una situació típica
L'el desenvolupador escriu: 'You have ' + count + ' items in your ' + cartType + ' cart' — funciona a la perfecció en anglès.
El traductor alemany rep tres fragments separats i no pot formar una oració gramaticalment correcta, ja que l'ordre de les paraules ha de canviar.
Resultat: els usuaris alemany veuen 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — és un treball poc fluid i poc professional.
Per què és un problema
Cada cadena enllaçada és una bomba de temps. Amb 20 idiomes i 50 cadenes enllaçades tens 1.000 possibles errors gramaticals que cal corregir manualment.
S\"trings concatenades com 'Willkommen '+ userName + ', tienes ' + count + ' missatges'' requereixen un ordre de paraules concret. Els traductors reben fragments sense context que no poden reordenar.
Els usuaris veuen frases gramaticalment incorrectes. En alemany, el verb sovint va al final. En àrab, tota l'estructura és girada. El resultat sona com una ximpleria.
Com ho pots arreglar
Utilitza missatges parametritzats amb marcadors amb noms, perquè els traductors puguin reubicar tota la frase.
Substitueix la concatenació per una única clau de missatge amb marcadors: 'cart.summary': 'Tens {count} articles al teu carret de compra '{cartType}''.
Passa les variables com a paràmetres a la teva funció de traducció: t('cart.summary', { count: 5, cartType: 'Premium' }).
Els traductors ara poden reordenar lliurement: 'El teu carret de compra '{cartType}' té {count} articles' — en alemany gramaticalment correcte.
Error #3: Ignorar la pluralització
L'anglès té dues formes de plural: singular i plural. L'empleat sovint assumeix que tots els idiomes funcionen igual. No és així. El polonès té 4 formes, l'aràbic té 6, i fins i tot llengües com el francès tracten la forma zero de manera diferent de l'anglès.
['Utilitza sempre ICU MessageFormat o una llibreria equivalent per a continguts amb plural', 'No escriguis mai la teva pròpia lògica de plural — confia en les regles CLDR', 'Prova els plurals amb valors com 0, 1, 2, 5, 21 i 100 per cobrir totes les categories']
Utilitza sempre ICU MessageFormat o una biblioteca equivalent per a continguts amb pluralització
Mai escriguis la teva pròpia lògica de pluralitat; confia en les regles CLDR.
Prova els plurals amb valors com 0, 1, 2, 5, 21 i 100, per cobrir totes les categories.
Un escenari típic
L'equip de desenvolupament escriu: count + (count === 1 ? ' Datei' : ' Dateien') — tracta l'alemany correctament.
El traductor polonès necessita 4 formes: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. El ternari simple no pot expressar-ho.
Resultat: els usuaris polonesos veuen '5 pliki' (forma incorrecta) en lloc de '5 plików' (forma correcta), i l'aplicació sembla que falla.
Per què això és un problema
Cada un substantiu comptable a la teva aplicació necessita un tractament de plural. Amb 50 d'aquests strings i 20 idiomes són 1.000 regles de plural — gairebé impossible de gestionar manualment.
Comprovacions simples amb if/else (count === 1 ? 'Datei' : 'Dateien') només funcionen per a l'alemany i l'anglès. CLDR defineix fins a 6 categories de plural: zero, one, two, few, many i other. Cada idioma utilitza un subconjunt diferent.
Els usuaris veuen textos gramaticalment incorrectes com '1 missatge' o formes de plural completament incorrectes. En contextos formals, això mina la credibilitat.
Com ho arreglar-ho
Utilitza ICU MessageFormat, que suporta totes les regles de plural CLDR de manera immediata.
Defineix missatges amb sintaxi ICU: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
Els traductors proporcionen totes les formes de plural necessàries per al seu idioma. Polonès: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
La teva llibreria i18n selecciona automàticament a temps d'execució la forma correcta segons les regles CLDR de la locale activa.
Error #4: Amplades fixes de elements de la interfície d'usuari
Els dissenyadors creen dissenys per píxel en anglès, i els desenvolupadors els implementen amb amplades fixes. Però el text traduït pot ser dràsticament més llarg o més curt. El text en alemany és al voltant d'un 30% més llarg que l'anglès, mentre que el text xinès pot ser fins a un 50% més curt.
['Mai utilitzis amplades fixes en elements amb text traductible', 'Planifica una expansió de text del 40% com a límit base — alguns idiomes s'expanden encara més', 'Utilitza CSS Flexbox o Grid per a dissenys que s'adaptin a llargues de contingut variables']
Mai utilitzis amplades fixes en píxels per a elements amb text que es pugui traduir.
Planifica un increment del 40% de text com a base — alguns idiomes s'adapten encara més.
Utilitza CSS Flexbox o Grid per a dissenys que s'adaptin a llargades de contingut variables.
Un escenari típic
El dissenyador crea una barra de navegació amb 5 botons, cadascun exactament de 100 px d'amplada — sembla molt bé en anglès.
Traducció alemanya: 'Settings' passa a 'Einstellungen' (13 vs 8 caràcters), 'Submit' passa a 'Absenden' (8 vs 6). La barra de navegació es desborda.
Resultat: En dispositius mòbils, els botons s'apilen uns sobre els altres o el text queda tallat, cosa que fa que la navegació sigui inusable per als usuaris alemanys.
Per què això és un problema
Cada element amb amplada fixa és un punt de fallida potencial. Una aplicació típica té centenars de botons, etiquetes i targetes, que han de poder soportar l'ampliació del text.
Contenidors amb amplada fixa (width: 120px) i botons de mida fixa poden tallar-se o desbordar-se quan el text s'allarga. El CSS overflow: hidden amaga el contingut en silenci, mentre que overflow: visible destrueix el disseny.
Els usuaris veuen etiquetes tallades com 'Einstellu...' en lloc de 'Einstellungen', o botons que sobreposen elements veïns. Les accions crítiques queden il·legibles o no es poden fer clic.
Això és com ho arregles
Dissenya i implementa dissenys flexibles que s'adaptin a la llargada del contingut de totes les localitzacions.
Sustituïu les amplades fixes per min-width, max-width i dissenys flexibles. Utilitza CSS Grid o Flexbox per distribuir l'espai de forma dinàmica.
Configura el contenidor de text perquè faci tall de línia: utilitza overflow-wrap: break-word i evita white-space: nowrap quan el contingut és traduït.
Prova la teva interfície amb una pseudo-localització que allarga tots els strings un 40% per simular el pitjor cas — encara abans d'enviar les cadenes als traductors.
Error #5: Formates de dates i de números
Les dades i les xifres poden semblar universals, però 01/02/2025 significa el 2 de gener a EUA i el 1 de febrer a Europa. Les comes i punts canvien de significat segons la regió: 1,000.50 (EUA) vs 1.000,50 (Alemanya). Fer-ho malament provoca confusió, errors en les dades i pèrdua de confiança.
['No formateïs dades o nombres manualment amb plantilles de cadena — utilitza sempre les API d'Intl', 'Guarda totes les dades en ISO 8601 i les monedes en la unitat més petita (cents) internament', 'Fes proves amb locals que utilitzin diferents separadors decimals, ordres de data i calendaris']
No formateu dades ni nombres manualment amb plantilles de cadena; utilitzeu sempre les API Intl.
Guarda totes les dades en ISO 8601 i les quantitats monetàries en la unitat més petita (cents) internament.
Prova amb locals que utilitzen diferents separadors decimals, ordres de data i sistemes de calendari.
Un escenari típic
El desenvolupador formatja una data com MM/DD/YYYY i un preu com $1,234.50 — correcte per als EUA.
Un usuari alemany veu la data 03/04/2025 i la llegeix com 3 d'abril (convenció DD/MM/YYYY). El preu $1,234.50 sembla que hauria de ser 1.234,50.
Resultat: l'usuari reserva un vol per la data incorrecta i qüestiona el format de preu. Els tiquets de suport augmenten un 15% al mercat alemany.
Per què és això un problema
La formata de dates i números afecta cada visualització de dades en la teva app: taules, gràfics, formularis, factures, informes. Una correcció global cobreix centenars d'instàncies.
Format strings codificats de forma dura com toLocaleDateString('en-US') o la formatació manual amb literals de plantilla ignoren la locale real de l'usuari. Fins i tot si la locale és correcta, però el calendari és el fals (gregorià vs. hijri) causa problemes.
Els usuaris llegeixen les dades de forma incorrecta i introdueixen dades en un format incorrecte. Un usuari europeu que veu 03/04/2025 pot llegir-ho com 3 d'abril en lloc de 4 de març — cites perdudes o reserves incorrectes.
Això és com ho resoldràs
Utilitza l'API Intl integrada o una biblioteca de formatació que sigui sensible a la localització per a totes les dates, hores, nombres i monedes.
Substitueix la formatació manual per Intl.DateTimeFormat(locale) per a dates i Intl.NumberFormat(locale, { style: 'currency', currency }) per a preus.
Emmagatzema les dades internament en format ISO 8601 (YYYY-MM-DD) i formátales només per a la visualització amb la configuració regional de l'usuari.
Prova les visualitzacions crítiques de dates i números amb almenys 5 locals diferents: en-US, de-DE, ja-JP, ar-SA i zh-CN, per cobrir les variants d'formatació més importants.
Error #6: S'han oblidat les llengües RTL.
Els idiomes de dreta a esquerra (RTL), com l’àrab, l’hebreu i el persa, són utilitzats per més de 500 milions de persones. Tot i això, la majoria d’aplicacions es dissenyen exclusivament per a dissenys de LTR (de l’esquerra a la dreta). El suport RTL no és només girar el text: tota la interfície d'usuari s’ha de reflectir.
['Des del primer moment utilitza només propietats CSS lògiques (inline-start/end, block-start/end)', "Prova l'app amb dir='rtl' a l'element HTML en cada sprint-review", 'Crea una llista de comprovacions RTL per a navegació, icones, formularis i indicadors de progrés']
Des de el primer dia, utilitza exclusivament propietats CSS lògiques (inline-start/end, block-start/end).
Prova la teva aplicació amb dir='rtl' a l'element HTML en cada sprint-Review.
Crea una RTL-test-checklist per a navegació, icones, formularis i indicadors de progrés.
Un escenari típic
El desenvolupador utilitza margin-left: 16px i text-align: left a tota l'aplicació — pràctica LTR estàndard.
L’aplicació s’inicia a l’Aràbia Saudita. Les fletxes de tornar indiquen cap endavant, les barres laterals apareixen a la banda equivocada i les dades numèriques estan mal alineades.
Resultat: Els usuaris àrabs abandonen l’aplicació després de 30 segons. L’equip necessita 4 setmanes de refactorització urgent de CSS per resoldre el problema.
Per què això és un problema
El suport RTL afecta cada component de la teva aplicació. Implementar RTL a posteriori normalment requeree reescriure entre el 30% i el 50% de totes les regles CSS i revisar cada icona i disseny.
Propietats CSS com margin-left, padding-right, text-align: left i float: left codifiquen la direcció. Icones amb indicació de direcció (fletxes, indicadors de progrés) apunten en la direcció equivocada. Fins i tot els valors de border-radius s'han de reflectir.
Els usuaris àrabs veuen la navegació a l'angle incorrecte, les barres de progrés que avancen en direcció contrària i text que entra en conflicte amb els elements de la interfície. L'aplicació se sent estranya i injugable.
Això és com ho resoldràs
Utilitza propietats CSS lògiques i prova des del principi amb el layout RTL.
Substitueix totes les propietats CSS físiques per equivalents lògics: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Configura l’atribut dir a l’element HTML arrel segons la locale activa. Utilitza la pseudoclasse CSS :dir(rtl) per overrides RTL específics.
Comprova totes icones per significació de direcció. Substitueix icones amb orientació reflectida o utilitza CSS transform: scaleX(-1) per contextos RTL.
Error #7: Imatges amb text
Text embedit en imatges — ja sigui en banners principals, botons, infografies o captures de pantalla — és un mals endeví de localització. Cada imatge amb text ha de ser creada de nou per a cada idioma, cosa que multiplica els costos de disseny i retarda les versions.
['Millor no inserir mai text traduïble directament en imatges raster (PNG, JPG)', 'Utilitza superposicions de text CSS sobre imatges de fons per als banners d'hero i les CTAs', 'Automatitza la generació de captures de pantalla per a les fitxes de l’App Store i les pàgines de màrqueting']
No incloguis mai text traduït directament en imatges raster (PNG, JPG).
Utilitza overlays de text CSS sobre imatges de fons per a banners Hero i CTAs.
Automatitza la generació de captures d'imatges per a llistats de l'App Store i pàgines de màrqueting.
Un escenari típic
Un dissenyador crea un banner promocional amb el text 'Start Your Free Trial' incrustat directament a la imatge.
L'equip de localització tradueix tots els textos de la interfície, però el banner a la pàgina alemanya segueix mostrant text en anglès.
Resultat: la pàgina de destinació alemanya té un banner en anglès que resulta irritant. Crear banners localitzats per a 15 idiomes triga 3 dies de feina de disseny i retarda el llançament.
Per què això és un problema?
Una pàgina típica de màrqueting té de 5 a 10 imatges amb text. En 15 idiomes són 75-150 variants d'imatges que s'han de crear, mantenir i actualitzar en cada canvi de disseny.
El text, que està incrustat en imatges (PNG, JPG, SVG amb text incrustat), no pot ser extret per eines de traducció. Cada versió localitzada requereix que un dissenyador editi l'arxiu font a mà, l'exporti i la carregui.
Els usuaris veuen imatges amb text en una llengua estrangera, o, encara pitjor, una barreja de la interfície traduccida i imatges no traduides. Això sembla incongruent i mina la confiança en la marca.
Com ho solucionis
Separa el text de les imatges mitjançant superposicions CSS, SVGs amb elements de text que es puguin traduir o amb generació d'imatges dinàmica.
Utilitza CSS per col·locar text traduïble sobre les imatges de fons: posiciona la capa de text amb posició absoluta per sobre del contenidor de la imatge.
Per a infografies o gràfics, utilitza SVGs amb elements <text> que facin referència a claus de traducció en lloc d'incorporar cadenes literals.
Per a captures de Pantalla d'aplicacions en materials de màrqueting, automatitza la generació de captures amb eines com Fastlane (mòbil) o Playwright (Web), que prenen pantalles en cada locale.
Error #8: Traduccions no tractades
Les traduccions són sempre incompletes durant el desenvolupament. Les noves funcionalitats afegeixen cadenes més ràpidament del que els traductors les poden traduir. Sense una gestió de fallback adequada, les traduccions que manca provoquen fallades, elements de l'UI buits o claus de traducció sense traduir que s'exhibeixen als usuaris.
['Configura sempre almenys una llengua de reserva en la configuració d'i18n', 'Registra les claus de traducció que falten al teu sistema de monitorització per al seguiment', 'Estableix un límit mínim de cobertura de traduccions abans que una localització pugui estar en producció']
Configura sempre almenys una llengua de reserva en la teva configuració d'i18n.
Registra les claus de traducció que falten en el teu sistema de monitorització per al seu seguiment.
Estableix sempre un mínim de cobertura de la traducció abans que una locale pugui entrar en directe.
Un escenari típic
L'/desenvolupador afegeix una nova secció 'Premium Features' amb 15 noves claus de traducció. La versió en anglès s lliura immediatament.
Les traduccions franceses encara no estan llestes. La pàgina francesa mostra claus en brut: 'premium.feature1.title', 'premium.feature1.description'.
Resultat: els usuaris francesos veuen una pàgina trencada plena de noms de claus de desenvolupador. L'equip de suport rep desenes de informes de bugs.
Per què això és un problema
Com més gran és la teva aplicació, més gran és la bretxa entre les cadenes en anglès i les traduccions en altres idiomes. Una aplicació amb 100 idiomes i 2.000 cadenes podria tenir en qualsevol moment més de 10.000 traduccions faltants.
Sense lògica de fallback, una clau de traducció que falti retorna undefined, null o la cadena de clau original (p. ex. 'checkout.confirmButton'). Els motors de plantilles poden generar errors, la pàgina pot fallar o no renderitzar res.
Els usuaris veuen una interfície trencada: botons buits, etiquetes faltants o cadenes críptiques com 'nav.settings.title' en lloc de text real. Això és confús i poc professional.
Com ho solucionis
Configura una cadena de fallback robusta i supervisa la cobertura de traduccions a totes les locals.
Richte una cadena de fallback per idiomes a la configuració i18n: les claus franceses (fr) que falten reverteixen automàticament a l'anglès (en).
Afegeix un gestor de claus no traduïdes que registri les claus no traduïdes al teu sistema de monitorització (per exemple Sentry, Datadog), sense trencar l'experiència de l'usuari.
Crea un panell de cobertura de traduccions que faci el seguiment del grau d'acabament per locale i bloquegi les versions quan la cobertura caigui per sota d'un llindar (p. ex. 95%).
Error #9: Problemes de codificació de caràcters
Els problemes de codificació de caràcters són els assassins silenciosos de la localització. Tot sembla correcte en anglès i en les llengües europees, però quan afegeixes xinès, japonès, coreà, àrab o emojis, apareixen caràcters mutilats (mojibake). Aquests errors són notòriament difícils de detectar.
['Utilitza codificació UTF-8 a tot arreu — arxius font, base de dades, respostes de l'API i etiquetes HTML Meta', 'Utilitza utf8mb4 a MySQL (no utf8), per donar suport a l'ample Unicode incloent Emoji', 'Fes proves amb contingut real en CJK, àrab i emoji, per capturar problemes de codificació aviat']
Utilitza la codificació UTF-8 en tot: arxius font, base de dades, respostes d'API i metatags HTML
Utilitza utf8mb4 en MySQL (no utf8) per donar suport a tot l'àmbit Unicode incloent Emoji.
Prova amb contingut real en CJK, àrab i Emoji per detectar problemes de codificació aviat.
Un escenari típic
El desenvolupador configura una base de dades MySQL amb col·lació latin1 (l'antic estàndard). El codi font de l'aplicació utilitza UTF-8.
Els usuaris japonesos s'inscriuen amb el seu nom real. La base de dades emmagatzema '田中太郎' com a bytes danyats.
Resultat: el perfil d'usuari mostra text mutilat. Més greu: la cerca i l'ordenació es trenquen per a tots els noms CJK, cosa que afecta milers d'usuaris.
Per què això és un problema
Els problemes de codificació s'estenen a través de tot l'stack. Una col·lació de base de dades mal configurada pot danyar milions d'enregistrements — la reparació requereix migracions de dades costoses.
Konzistent kodowanie napříč stackom — UTF-8 v zdrojových súboroch, Latin-1 v databáze a Windows-1252 v API odpovědi — naruší multibyte znaky. Jedna chybně nakonfigurovaná vrstva přemění '日本語' na '????' alebo '日本èª'.
Els usuaris veuran textos mutilats, signes de pregunta o quadradets buits on hauria d'estar la seva llengua. En el pitjor cas, les dades introduïdes en els formularis quedaran permanentment danyades a la base de dades.
Això és com ho resoldràs
Força la codificació UTF-8 de manera coherent a través de cada capa de la teva pila d'aplicacions.
Configura tots els arxius font a UTF-8 (configura el teu editor i .editorconfig). Afegeix <meta charset='UTF-8'> al teu HTML i 'Content-Type: application/json; charset=utf-8' en les respostes de l'API.
Configura la base de dades a utf8mb4 (no només utf8, que és un subconjunt de 3 bytes en MySQL). Configura la col·lació de connexió a utf8mb4_unicode_ci.
Tria tipografies que cobreixin els teus sistemes d'escriptura objectius: llatí, cirílic, CJK, àrab i devanagari. Utilitza stacks de fonts del sistema o Google Fonts amb subconjunts de llengua per a una càrrega òptima.
Prova la teva implementació i18n
Prova d'extensió de la longitud
Amplieu totes les cadenes traduccides entre 30-40 % per simular l'expansió de text que ocorre en idiomes abundants com l'alemany, el fi nès o el grec. Això ajuda a gestionar contenidors de grandària fixa, etiqetes tallades i botons que excedeixen la mida abans de començar a traduir. Molts eines de pseudo-localització inclouen aquesta funció com a part de la cadena d'eines.
"Envia" → "Ṡééééñðéñ_éxpáñðéð" (40% més llarg)
Pseudo-localització
La pseudo-localització substitueix cada caràcter per un equivalent amb accent (p. ex., 'a' → 'á') i envolta les cadenes amb marques com [!! i !!]. Això fa visible immediatament quins textos són codificats literalment i quins provenen del sistema de traducció. Executa la pseudo-localització com a part de la teva pipeline de CI per detectar regressions automàtiques.
Cada text en la pantalla que NO estigui entre [!! !!]-marcadores és codificat de forma rígida i cal externalitzar-lo. Aquest test atrapa 95% de les cadenes que s'obliden en menys d'un minut.
"Enviar missatge" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
Prova de maquetació RTL
Encara que no tinguis traduccions en àrab o hebreu, pots provar la maquetació RTL afegint dir='rtl' a l'element arrel del teu HTML. Això desvela immediatament errors de CSS de direcció: icones mal alineades, marges a la banda incorrecta, navegació trencada i elements flex mal ordenats. Fes-ho un control estàndard en cada sprint review — només 10 segons per activar-ho i captura problemes que d'altra manera requeririen setmanes per arreglar en producció.
La llista de verificació i18n
['Tots els textos visibles per a l\'usuari s\'han externalitzat en fitxers de recursos', 'No s\'utilitza la concatenació de cadenes per crear frases', 'Regles de plurals implementades amb ICU MessageFormat o l\'equivalent', 'La formateació de dates, hores i nombres utilitza APIs sensibles a la configuració regional', 'Disposició RTL provada amb continguts en àrab o hebreu', 'UI flexible sense amplades fixes per a elements amb text', 'Idioma de reserva configurat i provat quan faltin claus', 'Codificació UTF-8 coherent a tots els fitxers i bases de dades', 'Metadades de l\'App Store i Play Store localitzades per a cada mercat', 'Captures de pantalla i assets de màrqueting actualitzats per a cada idioma']