Planifica una aplicación web que gestione flujos de traducción, datos de locales, revisiones, comprobaciones QA y releases. Incluye modelo de datos, UX e integraciones.
La gestión de localización es el trabajo cotidiano de conseguir que el texto de tu producto (y a veces imágenes, fechas, monedas y reglas de formato) se traduzca, revise, apruebe y publique—sin romper el build ni confundir a los usuarios.
Para un equipo de producto, la meta no es “traducir todo”. Es mantener cada versión en idioma exacta, coherente y actualizada a medida que el producto cambia.
La mayoría de los equipos empiezan con buenas intenciones y acaban con un lío:
Una app útil de gestión de localización soporta múltiples roles:
Construirás un MVP que centralice cadenas, rastree estado por locale y soporte revisión básica y exportación. Un sistema más completo añade automatización (sincronización, comprobaciones QA), contexto enriquecido y herramientas como glosario y memoria de traducción.
Antes de diseñar tablas o pantallas, decide de qué es responsable tu app de gestión de localización. Un alcance ajustado hace que la primera versión sea usable—y evita que rehagas todo después.
Las traducciones rara vez viven en un solo lugar. Anota lo que necesitas soportar desde el día uno:
Esta lista te ayuda a evitar un enfoque “un flujo para todo”. Por ejemplo, el copy de marketing puede necesitar aprobaciones mientras que las cadenas de UI requieren iteración rápida.
Elige 1–2 formatos para el MVP y luego amplía. Opciones comunes: JSON, YAML, PO y CSV. Una elección práctica para el MVP es JSON o YAML (para cadenas de app), y CSV solo si ya dependes de importaciones desde hojas de cálculo.
Sé explícito sobre requisitos como formas plurales, claves anidadas y comentarios. Estos detalles afectan la gestión de archivos locale y la fiabilidad de tus importaciones/exportaciones futuras.
Define un idioma fuente (habitualmente en) y establece comportamiento de fallback:
También decide qué significa “terminado” por locale: ¿100% traducido, revisado o publicado?
Para el MVP céntrate en el proceso de revisión y en el flujo básico i18n: crear/editar cadenas, asignar trabajo, revisar y exportar.
Planifica añadidos posteriores—capturas/contexto, glosario, memoria de traducción básica e integración con MT—pero no los construyas hasta validar el flujo central con contenido real.
Una app de traducción tiene éxito o fracasa por su modelo de datos. Si las entidades y campos subyacentes están claros, todo lo demás—UI, workflow, integraciones—se simplifica.
La mayoría de equipos cubre el 80% de sus necesidades con un pequeño conjunto de tablas/colecciones:
en, en-GB, pt-BR).checkout.pay_button).Modela las relaciones explícitamente: un Project tiene muchos Locales; una Key pertenece a un Project; una Translation pertenece a una Key y a un Locale.
Añade un estado a cada traducción para que el sistema guíe a las personas:
draft → in_review → approvedblocked para cadenas que no deben publicarse aún (revisión legal, falta de contexto, etc.)Mantén los cambios de estado como eventos (o una tabla de historial) para poder responder “¿quién aprobó esto y cuándo?” más adelante.
Las traducciones necesitan más que texto plano. Captura:
{name}, %d) y si deben coincidir con la fuenteComo mínimo, persiste: created_by, updated_by, timestamps y una breve change_reason. Esto acelera las revisiones y genera confianza cuando los equipos comparan lo que está en la app con lo que se publicó.
Las decisiones de almacenamiento moldearán todo: la UX de edición, la velocidad de import/export, el diffing y con qué confianza puedes publicar.
Fila-por-clave (una fila DB por clave por locale) es ideal para dashboards y workflows. Puedes filtrar fácilmente “falta francés” o “necesita revisión”, asignar propietarios y calcular progreso. La desventaja: reconstruir un archivo de locale para exportar requiere agrupar y ordenar, y necesitarás campos extra para rutas de archivo y namespaces.
Documento-por-archivo (guardar cada archivo locale como un documento JSON/YAML) mapea limpiamente a cómo funcionan los repositorios. Es más rápido para exportar y mantiene el formateo idéntico. Pero buscar y filtrar se complica a menos que también mantengas un índice de claves, estados y metadatos.
Muchos equipos usan un híbrido: fila-por-clave como fuente de verdad, más snapshots generados de archivos para exportación.
Conserva historial de revisiones a nivel de unidad de traducción (key + locale). Cada cambio debe registrar: valor previo, valor nuevo, autor, timestamp y comentario. Esto facilita revisiones y rollback.
Por separado, rastrea snapshots de release: “qué exactamente se publicó en v1.8”. Un snapshot puede ser una etiqueta que apunte a un conjunto consistente de revisiones aprobadas en todos los locales. Así evitas que ediciones tardías alteren silenciosamente un build publicado.
No trates “plural” como un booleano. Usa ICU MessageFormat o categorías CLDR (por ejemplo, one, few, many, other) para que idiomas como polaco o árabe no queden forzados a reglas inglesas.
Para género y otras variaciones, módelas como variantes del mismo key (o mensaje) en lugar de claves ad-hoc separadas, para que los traductores vean el contexto completo.
Implementa búsqueda de texto completo sobre key, source text, traducción y notas de desarrollador. Acompáñala con filtros que coincidan con el trabajo real: estado (nuevo/traducido/revisado), etiquetas, archivo/namespace y faltante/vacío.
Indexa estos campos pronto—la búsqueda es la función que se usa cientos de veces al día.
Una app de gestión de localización suele empezar simple—subir un archivo, editar cadenas, descargar de nuevo. Se complica cuando añades múltiples productos, muchos locales, lanzamientos frecuentes y un flujo constante de automatización (sync, QA, MT, revisiones).
La manera más fácil de mantener flexibilidad es separar responsabilidades desde temprano.
Una configuración común y escalable es API + UI web + jobs en background + base de datos:
Esta separación te permite añadir más workers para tareas pesadas sin reescribir la app.
Si quieres moverte rápido en la primera versión, una plataforma de scaffolding como Koder.ai puede ayudarte a generar la UI (React), la API (Go) y el esquema PostgreSQL a partir de una especificación estructurada y algunas iteraciones en chat—luego exportas el código cuando estés listo para gestionar el repo y el despliegue.
Mantén la API centrada en unos pocos recursos core:
checkout.button.pay).Diseña endpoints para soportar edición humana y automatización. Por ejemplo, listar keys debería aceptar filtros como “falta en locale”, “cambiado desde”, o “necesita revisión”.
Trata la automatización como trabajo asíncrono. Una cola típicamente maneja:
Haz jobs idempotentes (seguros de reintentar) y registra logs por proyecto para que los equipos puedan autodiagnosticar fallos.
Incluso equipos pequeños pueden generar grandes datasets. Añade paginación para listas (keys, historial, jobs), cachea lecturas comunes (estadísticas por locale del proyecto) y aplica rate limits para proteger endpoints de import/export y tokens públicos.
Estos son detalles aburridos que evitan que tu sistema de gestión de traducciones se vuelva lento justo cuando la adopción crece.
Si tu app almacena cadenas fuente e historial de traducción, el control de acceso no es opcional—es cómo previenes ediciones accidentales y mantienes decisiones trazables.
Un conjunto simple de roles cubre la mayoría de equipos:
Trata cada acción como un permiso para poder evolucionar después. Reglas comunes:
Esto mapea limpiamente a un sistema de gestión de traducciones y es flexible para contratistas.
Si tu compañía ya usa Google Workspace, Azure AD u Okta, SSO reduce el riesgo de contraseñas y facilita el offboarding. Email/contraseña funciona para equipos pequeños—exige contraseñas fuertes y flujos de recuperación.
Usa sesiones seguras de corta duración (cookies HTTP-only), protección CSRF, rate limiting y 2FA cuando sea posible.
Registra quién cambió qué y cuándo: ediciones, aprobaciones, cambios de locale, exports y actualizaciones de permisos. Combina el log con “deshacer” vía historial de versiones para que los rollback sean seguros y rápidos (ver /blog/plan-storage-and-versioning).
Tu UI es donde realmente ocurre el trabajo de localización, así que prioriza las pantallas que reducen idas y vueltas y hacen el estado obvio de un vistazo.
Empieza con un dashboard que responda tres preguntas rápido: qué está hecho, qué falta y qué está bloqueado.
Muestra progreso por locale (porcentaje traducido, porcentaje revisado) y un contador claro de “cadenas faltantes”. Añade un widget de cola de revisión que destaque ítems esperando aprobación y un feed de “cambios recientes” para que los revisores detecten ediciones riesgosas.
Los filtros importan más que los gráficos: locale, área del producto, estado, asignado y “cambiado desde el último release”.
Un buen editor es lado a lado: fuente a la izquierda, objetivo a la derecha, con el contexto siempre visible.
El contexto puede incluir la key, capturas de pantalla (si las tienes), límites de caracteres y placeholders (p. ej., {name}, %d). Incluye historial y comentarios en la misma vista para que los traductores no necesiten una pantalla de “discusión” separada.
Haz el flujo de estado en un clic: Draft → In review → Approved.
El trabajo de localización suele ser “muchos cambios pequeños”. Añade selección múltiple con acciones como asignar a usuario/equipo, cambiar estado y exportar/importar por locale o módulo.
Mantén las acciones masivas restringidas por roles (ver /blog/roles-permissions-for-translators si lo cubres en otra parte).
Los traductores intensivos pasan horas en el editor. Soporta navegación completa por teclado, estados de foco visibles y atajos como:
También apoya lectores de pantalla y modos de alto contraste—la accesibilidad mejora la velocidad para todos.
Una app de gestión de localización triunfa o falla por su flujo. Si la gente no sabe qué traducir a continuación, quién toma una decisión o por qué una cadena está bloqueada, tendrás retrasos y calidad inconsistente.
Comienza con una unidad de trabajo clara: un conjunto de keys para un locale en una versión específica. Permite a PMs o leads asignar trabajo por locale, archivo/módulo y prioridad, con fecha de vencimiento opcional.
Haz las asignaciones visibles en una bandeja “Mi trabajo” que responda: qué está asignado, qué está atrasado y qué espera a otros. Para equipos grandes, añade señales de carga (conteo de ítems, estimación de palabras, última actividad) para que las asignaciones sean justas.
Construye una canalización simple de estado, por ejemplo: No traducido → En progreso → Listo para revisión → Aprobado.
La revisión debe ser más que un chequeo binario. Soporta comentarios inline, sugerencias de edición y aprobar/rechazar con motivo. Cuando un revisor rechaza, conserva el historial—no sobrescribas.
Esto hace que el proceso de revisión sea auditable y reduce errores repetidos.
La fuente cambiará. Cuando eso pase, marca traducciones existentes como Needs update y muestra un diff o un resumen de “qué cambió”. Conserva la traducción anterior como referencia, pero evita que vuelva a aprobarse sin una decisión explícita.
Notifica en eventos que bloquean el progreso: nueva asignación, solicitud de revisión, rechazo, fecha próxima y cambio de fuente que afecte cadenas aprobadas.
Mantén las notificaciones accionables con enlaces directos como /projects/{id}/locales/{locale}/tasks para que la gente pueda resolver en un clic.
El manejo manual de archivos es donde los proyectos de localización empiezan a desviarse: traductores trabajan sobre cadenas obsoletas, devs olvidan tirar actualizaciones y releases salen con locales a medias.
Una buena app trata import/export como una tubería repetible, no como una tarea puntual.
Soporta los caminos comunes que los equipos usan de verdad:
Al exportar, permite filtrar por proyecto, rama, locale y estado (p. ej., “solo aprobadas”). Así evitas que cadenas parcialmente revisadas se filtren a producción.
La sincronización solo funciona si las keys se mantienen consistentes. Decide pronto cómo se generan las cadenas:
checkout.button.pay_now), protégelas de renombres accidentales.Tu app debe detectar cuando cambia una fuente pero la key no, y marcar traducciones como needs review en lugar de sobreescribirlas.
Añade webhooks para que el sync ocurra automáticamente:
main → importar cadenas fuente actualizadas.Los webhooks deben ser idempotentes (seguros de reintentar) y producir logs claros: qué cambió, qué se saltó y por qué.
Si implementas esto, documenta la configuración más sencilla (acceso al repo + webhook + export por PR) y enlázala desde la UI, por ejemplo: /docs/integrations.
QA de localización es donde una app deja de ser un simple editor y empieza a prevenir bugs en producción.
El objetivo es detectar problemas antes de que las cadenas se publiquen—especialmente los que solo aparecen en un archivo locale concreto.
Comienza con comprobaciones que pueden romper la UI o el formateo:
{count} presente en inglés pero faltante en francés, o formas plurales inconsistentes).% suelto en printf-style, mensajes ICU mal formados).Trata estos como “bloqueantes de release” por defecto, con un mensaje claro y un puntero a la clave y locale exactos.
Estas no siempre rompen la app, pero dañan la calidad y la coherencia de marca:
El texto puede ser correcto y aun así verse mal. Añade la capacidad de solicitar captura de pantalla por clave (o adjuntar una captura a una clave), para que los revisores validen truncamientos, saltos de línea y tono en la UI.
Antes de cada release, genera un resumen QA por locale: errores, advertencias, cadenas sin traducir y los principales problemas.
Facilita la exportación o enlace interno (p. ej., /releases/123/qa) para que el equipo tenga una vista única de “go/no-go”.
Agregar glosario, memoria de traducción (TM) y traducción automática (MT) puede acelerar mucho la localización—pero solo si la app los trata como guía y ayuda, no como contenido listo para publicar.
Un glosario es una lista curada de términos con traducciones aprobadas por locale (nombres de producto, conceptos de UI, frases legales).
Almacena entradas como término + locale + traducción aprobada + notas + estado.
Para aplicarlo, añade comprobaciones en el editor:
La TM reutiliza segmentos previamente aprobados. Mantenlo simple:
Trata la TM como un sistema de sugerencias: los usuarios pueden aceptar, editar o rechazar, y solo las traducciones aceptadas retroalimentan la TM.
MT es útil para borradores y backlog, pero no debe ser salida final por defecto.
Haz MT opt-in por proyecto y por job, y enruta cadenas llenadas por MT por el proceso normal de revisión.
Diferentes equipos tienen restricciones distintas. Permite a admins seleccionar proveedores (o desactivar MT), fijar límites de uso y elegir qué datos se envían (p. ej., excluir claves sensibles).
Registra solicitudes para visibilidad de coste y auditoría, y documenta opciones en /settings/integrations.
Una app de localización no debe solo “almacenar traducciones”: debe ayudar a publicarlas con seguridad.
La idea clave es un release: un snapshot congelado de cadenas aprobadas para un build específico, de modo que lo que se despliega sea predecible y reproducible.
Trata un release como un bundle inmutable:
Esto te permite responder: “¿Qué publicamos en v2.8.1 para fr-FR?” sin adivinar.
La mayoría de equipos quiere validar traducciones antes de que los usuarios las vean. Modela exportaciones por entorno:
Haz el endpoint de exportación explícito (por ejemplo: /api/exports/production?release=123) para prevenir fugas accidentales de texto no revisado.
El rollback es más fácil cuando los releases son inmutables. Si un release introduce problemas (placeholders rotos, terminología incorrecta), deberías poder:
Evita “editar producción en sitio”—rompe la auditoría y complica el análisis de incidentes.
Notablemente, esta mentalidad de “snapshot + rollback” encaja con plataformas modernas de build. Por ejemplo, Koder.ai incluye snapshots y rollback como flujo de trabajo de primera clase, lo cual es un buen modelo mental al diseñar releases inmutables de localización.
Tras el despliegue, ejecuta un pequeño checklist operativo:
Si muestras historial de releases en la UI, incluye una vista simple de “diff vs. release anterior” para que los equipos detecten cambios riesgosos rápidamente.
Seguridad y visibilidad son la diferencia entre una herramienta de localización útil y una en la que los equipos confían. Una vez que tu flujo funcione, protégelo y empieza a medirlo.
Aplica el principio de menor privilegio por defecto: los traductores no deberían poder cambiar ajustes del proyecto, y los revisores no deberían ver facturación o exports solo-admin. Haz los roles explícitos y auditables.
Guarda secretos de forma segura. Mantén credenciales DB, claves de firma de webhooks y tokens de terceros en un gestor de secretos o variables de entorno encriptadas—nunca en el repo. Rota claves periódicamente y al offboarding.
Los backups no son opcionales. Haz backups automáticos de BD y almacenamiento de objetos (archivos locale, adjuntos), prueba restauraciones y define retenciones. Un “backup que no se puede restaurar” es solo almacenamiento extra.
Si las cadenas pueden contener contenido de usuarios (tickets de soporte, nombres, direcciones), evita almacenarlas en el sistema de traducción. Prefiere placeholders o referencias y elimina valores sensibles de los logs.
Si debes procesar ese texto, define reglas de retención y restricciones de acceso.
Mide unas pocas métricas que reflejen la salud del flujo:
Un dashboard simple más export CSV es suficiente para empezar.
Cuando la base esté estable, considera:
Si planeas ofrecer esto como producto, añade un camino claro de upgrade y llamada a la acción (ver /pricing).
Si tu objetivo inmediato es validar el flujo con usuarios reales, también puedes prototipar el MVP en Koder.ai: describe roles, flujo de estados y formatos de import/export en modo planning, itera en la UI React y la API Go vía chat, y luego exporta la base de código cuando estés listo para endurecerla para producción.
Una aplicación web de gestión de localización centraliza tus cadenas y gestiona el flujo alrededor de ellas —traducción, revisión, aprobaciones y exportación— para que los equipos puedan desplegar actualizaciones sin claves rotas, marcadores faltantes o estado incierto.
Comienza por definir:
pt-BR → pt → en)Un alcance ajustado evita el error de “una sola forma de trabajo para todo” y mantiene el MVP usable.
La mayoría de los equipos cubren el flujo básico con:
Guarda metadatos que eviten errores en producción y reduzcan revisiones repetidas:
Depende de lo que optimices:
Un enfoque común es híbrido: fila-por-clave como fuente de la verdad, más snapshots de archivos generados para exportaciones.
Usa dos capas:
Esto evita que ediciones silenciosas modifiquen lo ya desplegado y facilita el análisis de incidentes.
Empieza con los roles que reflejan el trabajo real:
Céntralo en unos pocos recursos:
Projects, Locales, Keys, TranslationsY haz que los endpoints de listado soporten filtros útiles como:
Ejecuta trabajo pesado de forma asíncrona:
Haz que los jobs sean idempotentes (seguros de reintentar) y almacena logs por proyecto para que los equipos puedan diagnosticar fallos sin revisar logs del servidor.
Prioriza comprobaciones que eviten una UI rota:
{count}, %d) y cobertura de pluralesTrátalas como bloqueantes de release por defecto, y añade advertencias menos severas para consistencia de glosario y espacios/case para mejorar calidad sin bloquear todo.
draft → in_review → approved)Si estas entidades están bien definidas, las pantallas, permisos e integraciones son más sencillas de construir y mantener.
created_by, updated_by, timestamps, motivo del cambio)Esto es lo que diferencia “un editor de texto” de un sistema en el que los equipos pueden confiar.
Define permisos por acción (editar fuente, aprobar, exportar, gestionar locales) para poder evolucionar sin romper flujos.
Así soportas tanto la edición humana en la UI como la automatización vía CLI/CI.