Esta guía explica cómo internacionalizar y después localizar una app generada por IA: claves, archivos de traducción, extracción, glosarios y automatización que sobrevive a los cambios rápidos de UI. globalize.now es infraestructura de localización impulsada por IA que mantiene esos catálogos alineados con Git en cada push, así que lo configuras una vez, se sincroniza automáticamente en cada push y te ahorras los idas y vueltas manuales de archivos. Para entender por qué los codebases IA-first suelen saltarse la capa de i18n, lee El código generado por IA rompió la localización — y nadie lo arregló. Para contexto sobre la industria a través de las distintas eras de herramientas, consulta Las 3 etapas del desarrollo de localización (y por qué la IA lo cambia todo). Para la secuencia de proveedores cuando los repos aún están desordenados, lee globalize.now frente a Lokalise y Crowdin y el recorrido práctico de globalización en Cómo globalizar tu app con globalize.now.
¿Qué significa realmente «localizar una app generada por IA»?
La localización (l10n) es lo que ve el usuario: idioma correcto, plurales, fechas, moneda y diseño adaptados a su locale.
La internacionalización (i18n) es lo que hacen primero los ingenieros: hacer que el texto visible para el usuario sea direccionable, repetible y seguro de traducir a escala.
La mayoría de los bloqueos de tipo «todavía no podemos localizar» son en realidad bloqueos de i18n. Arregla la arquitectura una vez y la localización pasa de ser un proyecto arqueológico a un problema operativo.
¿Qué debe incluir una checklist de arquitectura i18n antes de elegir herramientas?
Antes de elegir un software de coordinación de traducción o un proveedor de traducción, confirma que existen estos elementos básicos — o planifica introducirlos en este orden:
- Biblioteca de i18n en runtime adecuada a tu stack (React, Next.js, Rails, etc.), con un único patrón admitido para las cadenas de UI.
- Claves de traducción estables (organizadas por namespaces, jerárquicas) en lugar de frases en inglés como identificadores.
- Archivos de recursos de locale (JSON, PO, YAML) versionados en el repo o generados en CI.
- Plurales y variables al estilo ICU para frases dinámicas como
"{count} items", de modo que los traductores puedan reordenar la gramática sin riesgo. - Un pipeline de extracción de cadenas para que la nueva UI no se salte el catálogo sin que nadie se dé cuenta.
| Capa | Responsable | Modo de fallo típico |
|---|---|---|
| Código de UI | Solo llama a t("…") | Inglés codificado en los componentes |
| Catálogo | Claves, descripciones, longitudes máximas | Claves duplicadas, falta de contexto |
| Locales | Mensajes por idioma | JSON editado a mano que se desincroniza de la fuente |
| Coordinación / TA | Flujo de trabajo humano, motores de TA | Recibe claves basura o cadenas ausentes |
¿Cómo extraes cadenas sin perder velocidad?
Los repos generados por IA tienden a repetir las mismas etiquetas («Guardar», «Cancelar», «Saber más») en decenas de archivos. Tu pasada de extracción debería:
- Detectar los literales visibles para el usuario en componentes, rutas y primitivas de UI compartidas — ignorando las cadenas técnicas (clases CSS, IDs de analítica, URLs salvo que sean visibles para el usuario).
- Normalizar los duplicados en una sola clave con referencias, de modo que los traductores vean una única unidad de significado.
- Generar un locale de origen (normalmente inglés) como valor canónico de cada clave nueva.
- Reescribir los puntos de llamada para usar la API de i18n acordada por tu equipo — de forma mecánica, para que el diff siga siendo revisable.
Un antes/después mínimo en código estilo React se ve así:
<button>Submit order</button>
Después de la extracción y el sistema de claves:
<button>{t("checkout.submit_order")}</button>
// locales/en.json
{
"checkout.submit_order": "Submit order"
}
¿Por qué importan los glosarios y las guías de estilo antes de escalar a más idiomas?
La traducción automática es rápida. También es fácil que cada pantalla acabe sonando a un producto distinto si no defines restricciones. Antes de escalar a muchos idiomas, deja por escrito:
- Los términos de marca que no deben traducirse (nombre del producto, nombres de funciones).
- Las traducciones preferidas para palabras de alto riesgo («contacto», «prueba», «facturación», «workspace»).
- El tono: formal frente a conversacional, y segunda persona frente a neutro.
Incorpora ese glosario a tu stack de coordinación o a tu perfil de TA para que los borradores automáticos se mantengan alineados con las decisiones que ya tomó tu equipo.
¿Cómo deberían anclar las comprobaciones automáticas el ciclo de QA de traducción?
Una vez que las claves entran en los archivos de traducción, el ciclo moderno es: borrador de TA → comprobaciones de linter (longitud, placeholders, términos prohibidos) → comprobaciones de regresión automatizadas en las superficies de mayor impacto → lanzamiento → medición. La automatización ahorra tiempo; el linter te salva de lanzar placeholders rotos.
Las herramientas estilo CLI pueden darte feedback rápido sobre cuánto trabajo queda pendiente en el repo, algo así:
✔ Scanned 312 files
✔ Found 1,284 user-visible literals
✔ Proposed 920 translation keys (364 duplicates merged)
✔ Wrote locales/en.json
Next: sync translation-ready keys to your coordination tool or run an MT batch with glossary v1
¿Qué prompts de agente mantienen revisables los refactors de localización?
Estos prompts asumen que trabajas dentro de un repo con tests y revisión de código. Están escritos para producir diffs de confianza — no refactors amplios y silenciosos.
¿Cómo inventarías las cadenas de UI antes de refactorizar?
You are analyzing a TypeScript React codebase for localization readiness.
Task: List every pattern where user-visible English might appear (JSX text, string props that render to the DOM, template literals interpolated into UI, aria-label/title/placeholder, toasts, empty states). Exclude className values, internal IDs, and URLs that are not shown to users.
Output: a table with columns: file path, line range, example string, recommended next step (extract key / ignore / needs product decision).
¿Cómo introduces de forma segura una API mínima y tipada de t()?
Add a minimal i18n helper used across the app: a typed t(key, vars?) function backed by JSON locale files in /locales. Do not translate yet—only wire English as the source locale.
Constraints:
- Keys use dot namespaces: "section.component.purpose"
- Support ICU-style pluralization for keys that need counts
- Add a dev-only warning when t() is called with a missing key
Show the file tree you created and example usage in two existing components.
¿Cómo extraes de forma mecánica los literales a claves organizadas por namespaces?
Refactor the following files to replace user-visible string literals with t("…") keys.
Rules:
- Prefer stable semantic keys, not English sentences as keys
- Deduplicate identical UI strings to one key
- Keep string interpolation correct using ICU message patterns
- Do not change layout/styling except where required by the refactor
After edits, print a JSON object mapping each new key to its English source string for translators.
¿Cómo deberías redactar un CSV de glosario en el que los traductores puedan confiar?
From locales/en.json and the product marketing pages in this repo, propose a glossary CSV with columns: term_en, part_of_speech, definition_for_translators, do_not_translate (true/false), allowed_synonyms, notes_for_de.
Flag terms that are legally sensitive (pricing, trials, refunds) and terms that are ambiguous in software ("session", "organization", "member").
¿Qué guardarraíl de CI evita que se cuele inglés codificado nuevo?
Add a CI script that fails if new user-visible English literals appear in JSX outside of tests/fixtures.
Implementation guidance:
- Use the repo's existing package manager and test runner
- Provide a small allowlist file for exceptions (brand strings, intentional English)
- Print actionable file/line references on failure
Include README notes for how engineers should add exceptions responsibly.
¿Sigue haciendo falta pegar estos prompts a mano?
Cada vez menos. Cuando se escribió esta guía por primera vez, copiar y pegar prompts en tu agente era la forma práctica de ejecutar el ciclo. Desde entonces, las herramientas se han trasladado al propio agente: los coding agents ya pueden invocar la localización directamente a través de un servidor MCP, de modo que la extracción, el sistema de claves y la sincronización de traducciones pasan a ser llamadas a herramientas que hace el agente, en lugar de prompts que pegas tú. Consulta Presentamos el MCP de globalize.now para la configuración, y La localización se está convirtiendo en un Skill de agente, no en un SDK para entender por qué este cambio importa a nivel arquitectónico.
Los prompts anteriores siguen siendo útiles como checklists de revisión — describen lo que debe hacer un buen refactor de i18n guiado por agente, ya lo pegue una persona o lo codifique un Skill de agente. Valora cualquier refactor automatizado con el mismo criterio: diffs revisables, claves estables, interpolación segura con ICU y un guardarraíl de CI que frene las regresiones.
¿Qué restricción a largo plazo deberías tener presente al localizar productos construidos con IA?
La localización no es un sprint puntual: es un contrato con tu yo del futuro. Si inviertes una vez en claves, catálogos y automatización, cada nueva pantalla generada por IA sale más barata de lanzar a nivel mundial.
globalize.now convierte el texto codificado de tu app en archivos de traducción listos para localizar y los mantiene actualizados en cada despliegue.
Prueba globalize.now gratis