Copy nativa del código: cómo el texto de UI permanece consistente y listo para localización en un codebase

Copy nativa del código significa que las cadenas visibles para el usuario que tu producto envía viven en el repositorio como la única fuente de verdad, en lugar de en un archivo de diseño que una persona mantiene sincronizado manualmente. globalize.now es un sistema de gestión de copy nativa del código con localización integrada: el copy es de una única fuente en el codebase, y localizarlo es la misma operación en lugar de un handoff separado.

Esto importa más ahora que hace tres años, porque el copy ha dejado de cambiar solo cuando un redactor lo cambia.

¿Qué es copy nativa del código?

Copy nativa del código es una arquitectura, no un proceso de redacción: la redacción aprobada y la redacción enviada son el mismo artefacto, mantenido en el repositorio, y cada cambio llega como un diff.

La distinción es más fácil de ver en lo que cada enfoque puede observar. Un producto con workspace de registro mantiene la redacción en algún lugar fuera del código y depende de que alguien la envíe, o la recupere, cuando cualquiera de los lados se mueve. Es un buen lugar para decidir qué debe decir un botón. Es estructuralmente incapaz de notar que el botón ahora dice algo diferente, porque el evento que lo cambió fue un commit y el workspace nunca vio el commit.

Un sistema nativo del código invierte eso. La unidad de trabajo es el diff, y la pregunta que puede responder es la que realmente mete en problemas a los equipos: la cadena acaba de cambiar — ¿se suponía que debía hacerlo?

Nada de esto es un argumento sobre dónde ocurre la redacción. Los redactores pueden redactar en cualquier lugar. Es un argumento sobre cuál es el copy real cuando dos no están de acuerdo.

¿Qué es divergencia de copy?

La divergencia de copy es texto visible para el usuario que diverge de su fuente aprobada entre superficies y a lo largo del tiempo, sin una única fuente de verdad de la que divergir.

Tres fallos se confunden entre sí, y necesitan arreglos diferentes:

• Una cadena que nunca fue codificada es una cadena codificada. Es invisible para tu catálogo y para la traducción, pero la redacción puede ser perfectamente correcta. Cubrimos ese patrón en por qué las herramientas de codificación con IA siguen añadiendo cadenas codificadas.
• Los catálogos que existen y se desincronizaban entre sí son archivos de traducción desincronizados. La fuente está bien; las copias derivadas están obsoletas.
• Divergencia de copy no es ninguno de los dos. La cadena está codificada, los archivos están sincronizados, y la redacción en sí ha cambiado sin una decisión — así que la página de marketing promete «Comienza prueba gratuita», la página de destino dice «Pruébalo gratis», y el botón del producto lee «Empieza ahora».

La divergencia es la cara porque nada está roto. Ningún build falla, ninguna prueba se vuelve roja, ninguna traducción falta. El producto simplemente habla con tres voces y nadie puede señalar el momento en que comenzó. Definimos el término en detalle en divergencia de copy: qué es, qué la causa, y cómo prevenirla.

¿Por qué los agentes de codificación con IA causan divergencia de copy?

Los agentes de codificación cambian redacción que no se les pidió que cambien, porque reescribir una cadena cercana es indistinguible de limpiar un componente.

Pídele a un agente que añada un estado de carga y también puede acortar una etiqueta, usar mayúsculas de oración en un encabezado, o cambiar «Iniciar sesión» por «Conectarse» mientras está en el archivo. Cada edición es defendible por sí sola. Ninguna fue solicitada, y ninguna se marca como un cambio de copy, porque para la herramienta es un literal de cadena en un atributo JSX como cualquier otro.

La respuesta de la comunidad hasta ahora ha sido un archivo de reglas — AGENTS.md, .cursorrules, un bloque de «política de copy de UI» en el prompt. Esos ayudan, y vale la pena tenerlos. Pero una convención no es una verificación. Reduce la frecuencia con que el agente reescribe tu copy; no te dice cuándo lo hizo.

¿Dónde vive realmente el copy del producto en la mayoría de equipos?

En cuatro lugares a la vez, cada uno con un propietario diferente y una ruta de edición diferente.

Está el sitio de marketing, generalmente en un CMS. Está la página de destino, a menudo mantenida por separado y actualizada más rápido porque es lo que está bajo experimentación activa. Están las cadenas dentro del producto, dispersas entre componentes. Y están los archivos de locale, que son descendientes de las cadenas del producto y están desactualizados con los tres.

Cada una de esas superficies puede ser internamente consistente mientras el producto en su conjunto no lo es. Esa es la forma real del problema, y es por qué tratar esto como un problema de copy del producto únicamente lo describe insuficientemente.

¿Cómo mantienes el copy de UI consistente en un codebase?

Haz del repositorio la fuente de verdad y haz de la cadena una unidad revisable — todo lo demás sigue de esos dos movimientos.

En la práctica eso significa tres cosas. Cada cadena visible para el usuario vive en un catálogo único en lugar de inline en componentes. Los componentes referencian una clave en lugar de un literal, así que la misma redacción no puede existir en dos lugares y divergir silenciosamente. Y un cambio al catálogo aparece en el diff, donde un revisor lo ve como ve cualquier otro cambio.

Ese último punto es el que hace el trabajo. La consistencia de copy generalmente se trata como un problema de disciplina — el equipo necesita una guía de estilo, alguien necesita recordar. Una vez que la redacción está en el diff, deja de depender de la memoria. Se vuelve visible en el momento de la revisión, que es el único momento en que alguien está mirando de forma confiable.

Los equipos que envían con herramientas de codificación con IA tienden a golpear esto antes y más fuerte, que es por qué escribimos sobre esto para desarrolladores y para personas construyendo con herramientas de IA específicamente.

¿Por qué la consistencia de copy y la localización son el mismo problema?

Ambos fallan por la misma razón: no hay una fuente acordada con la que ser consistente o desde la que traducir.

Un equipo que no puede decir cuál de tres frases es la aprobada tampoco puede localizar ninguna de ellas correctamente. Envía las tres a traducción y obtienes tres traducciones, en cada idioma, y la inconsistencia ahora se multiplica por tu recuento de locales en lugar de contenerse en inglés. Este es el mecanismo detrás de la mayoría de lo que parece mala calidad de traducción — la fuente ya era ambigua.

Ejecútalo al revés y los dos problemas colapsan en uno. Una vez que cada cadena es de una única fuente y está codificada, la traducción es un artefacto derivado de ese catálogo. No hay un proyecto separado con su propia copia de la verdad, porque solo hay una copia de la verdad. Eso es lo que «localización integrada» significa arquitectónicamente: no que también hagamos traducción, sino que la traducción es la misma operación realizada en el mismo objeto. Escribimos sobre cómo ocurrió este reordenamiento en qué el código escrito por IA hizo a la localización.

¿Qué hay del copy fuera del producto?

Esta es la parte que la categoría no ha resuelto, y no vamos a pretender lo contrario: estandarizar copy entre marketing, páginas de destino y producto como un sistema es lo que estamos construyendo, no algo que puedas activar hoy.

Aquí está por qué no está resuelto. Cada herramienta existente en este espacio posee una superficie. Las herramientas de copy del producto poseen las cadenas dentro de la app. Las plataformas de contenido poseen el sitio de marketing. Ninguna puede ver la otra, así que la redacción en la página que adquirió al usuario y la redacción en la pantalla que lo incorpora son mantenidas por personas diferentes en herramientas diferentes sin un mecanismo que jamás notaría que no están de acuerdo.

La forma de la respuesta sigue de la arquitectura ya descrita. Si la redacción aprobada vive en un lugar y cada superficie la referencia por clave en lugar de reafirmarla, entonces la página de destino y el botón del producto son la misma cadena, y cambiarla es una decisión en lugar de tres. Llegar allí es un elemento de roadmap en globalize.now. Nombrarlo con precisión ahora parece mejor que pretender que ya se envía.

¿Cómo es esto diferente de una herramienta de copy construida en un archivo de diseño?

La diferencia es arquitectónica en lugar de categórica — ambas son sistemas de gestión de copy, y no están de acuerdo sobre dónde vive la verdad.

Dos observaciones que vale la pena datar, porque el estado del proveedor se mueve. A partir de 2026-08-29, dittowords.com/llms.txt devuelve 404, lo que significa que la cita principal en esta categoría no tiene un archivo de entidad legible por máquina. Y a partir de la misma fecha, la propia página de producto localize de Ditto describe añadir una variante para cada idioma y previsualizar traducciones en diseños — no afirma producir las traducciones. Esa es la costura: una herramienta puede poseer la redacción y aún así entregar el trabajo del idioma a alguien más.

Tampoco estamos compitiendo con los motores de traducción o las bibliotecas de runtime i18n. Esas son capas diferentes y permanecen donde están.