¿Dónde lee Lovable las reglas de i18n? Knowledge, Skills y AGENTS.md

Lovable lee las reglas de i18n en tres sitios: el knowledge del workspace y del proyecto, que siempre están en contexto; los Skills, que solo se cargan cuando un prompt coincide con su descripción; y los archivos de instrucciones del repositorio conectado, donde un AGENTS.md en la raíz se lee sin importar cuánto lleve la conversación. Si pones las reglas en el sitio equivocado, la app que tradujiste la semana pasada lanzará su próxima funcionalidad en inglés. globalize.now es infraestructura de localización impulsada por IA, así que vemos las consecuencias de ese error en muchos repositorios de Lovable; la solución consiste sobre todo en saber qué superficie se lee y cuándo.

¿Por qué una app de Lovable traducida vuelve al inglés?

Porque la instrucción que la hizo multilingüe no estaba delante del agente cuando escribió el siguiente componente. Lovable resuelve el prompt que tiene en pantalla. Si ese prompt dice «añade una sección de testimonios» y nada en el contexto dice «toda cadena visible para el usuario pasa por <Trans>», el encabezado acaba como un literal, igual que en un proyecto recién creado.

Este problema no es el mismo que el de los catálogos que van por detrás del código, que es el fallo de sincronización que tratamos en por qué las traducciones de tu app de Lovable se rompen cada vez que lanzas. La sincronización mueve las cadenas envueltas a los archivos de locale. No puede mover una cadena que nunca se envolvió. La pregunta de fondo es qué estaba leyendo Lovable en el momento de escribir el código, y su documentación es inusualmente concreta al respecto.

¿Qué lee realmente Lovable antes de editar?

Según su documentación sobre knowledge, el knowledge del proyecto, el del workspace y los archivos de instrucciones del repositorio Git, como AGENTS.md o CLAUDE.md, guían al agente junto con el código del proyecto. Los Skills van aparte y se cargan bajo demanda.

Se diferencian en tres aspectos que importan para i18n.

Cuándo se leen. El knowledge se incluye en cada mensaje. Un Skill solo se incluye cuando la petición coincide con su descripción. Un AGENTS.md en la raíz se lee siempre, en palabras de Lovable, sin importar la duración de la sesión.

Su durabilidad en un chat largo. La documentación de Lovable incluye una advertencia explícita: en conversaciones muy largas y con mucho contexto, las instrucciones del knowledge pueden no seguirse siempre de forma consistente. La misma página afirma lo contrario del AGENTS.md de la raíz. Esa asimetría es la razón de ser de este post.

Quién puede editarlos. El knowledge del workspace solo lo editan propietarios y administradores. El knowledge del proyecto puede editarlo cualquiera con permisos de edición en el proyecto. El archivo del repositorio lo edita quien pueda hacer push, incluido el propio agente de Lovable.

Cada nivel de knowledge admite hasta 10.000 caracteres. Es de sobra para un puntero y muy poco para el conjunto completo de reglas cuando además quieres meter notas de arquitectura, esquema de base de datos y tono de marca.

Entonces, ¿dónde van las reglas de i18n?

En el repositorio, con un puntero corto en el knowledge. El razonamiento se deduce de la tabla anterior.

El AGENTS.md de la raíz del repo lleva las reglas completas. Se lee en cada mensaje sin importar la duración de la sesión, vive en Git y por tanto sobrevive a un chat nuevo, a un colaborador nuevo y a un cambio de agente, y no tiene un límite de caracteres que compita con el resto del contexto de tu proyecto. Cuando el Skill lovable-i18n ejecuta su configuración, su tercera fase escribe justo este archivo: un bloque de reglas de Lingui entre los marcadores <!-- lovable-i18n:rules:start --> y <!-- lovable-i18n:rules:end -->, que se crea si el archivo no existe, se añade si ya existe y se reemplaza entre los marcadores al volver a ejecutarlo, de modo que nada se duplica.

El knowledge del proyecto lleva un puntero de dos líneas. Algo así:

Localization
- This app is localized with Lingui. Every user-visible string is wrapped
  (<Trans>, t``, msg``) and new strings are appended to src/locales/*/messages.po.
- The full rules are in AGENTS.md at the repo root. Follow them on every edit.

El puntero está para el caso contra el que advierte la documentación. Si una conversación larga ha diluido el bloque de knowledge, el agente sigue teniendo el archivo del repo; si por alguna razón el archivo del repo no está en contexto, el puntero nombra la restricción. Dos superficies, una sola regla.

El knowledge del workspace, solo si todos los proyectos usan la misma biblioteca. El knowledge del workspace se aplica a todos los proyectos y solo hay uno. Si la mitad de tus proyectos usan Lingui y la otra mitad otra cosa, una regla de Lingui a nivel de workspace es incorrecta para la mitad, y Lovable tiende a priorizar el knowledge del proyecto en caso de conflicto. Reserva el knowledge del workspace para las reglas que valen en todas partes: botones en sentence case, nada de console.log, comentarios de código en inglés.

El Skill no es el sitio para las reglas. Esto sorprende a quien acaba de importarlo. Un Skill se carga cuando el prompt coincide con su descripción, así que lovable-i18n está en contexto cuando pides configurar i18n y ausente cuando pides una página de checkout. Es por diseño; un Skill que se cargara en cada mensaje sería simplemente knowledge. El trabajo del Skill es escribir una vez las reglas permanentes en el repo y apartarse.

¿Qué dicen las reglas de AGENTS.md?

Responden a las preguntas que un agente falla cuando solo se le dice «usa i18n». El bloque que escribe el Skill tiene seis partes.

Qué macro usar. Una lista de decisión: el texto que cambia con un número usa <Plural> o un plural ICU; el texto JSX usa <Trans>; los valores de atributos y las cadenas de manejadores de eventos, como los toasts, usan el t que devuelve useLingui(); las constantes a nivel de módulo usan msg y se resuelven dentro del componente. La regla también indica de qué ruta de importación viene cada una, porque importar el t equivocado enlaza una instancia global que la app nunca carga.

Interpolación. Solo una variable simple da nombre a su propio slot en el mensaje extraído. Cualquier otra expresión se extrae como {0}, algo con lo que un traductor no puede trabajar, así que la regla exige ph() para nombrarla.

Plurales. other es siempre obligatorio, las categorías son las de CLDR y se prohíbe el ternario entre dos cadenas, porque incrusta las reglas de plural del inglés en el componente. Si quieres contexto, qué es ICU MessageFormat explica la sintaxis a la que compilan las formas de plural.

Números y fechas. i18n.number() y i18n.date(), nunca toFixed() ni un símbolo de moneda concatenado a un valor. El propio ejemplo de knowledge del workspace de Lovable incluye una sección de localización que fija un formato de fecha y el formato numérico europeo, que es un buen instinto, pero es una regla de formato, no de envoltura. Una app puede cumplirla a la perfección y aun así lanzar todos los encabezados en inglés.

Comentarios para traductores. Las cadenas cortas con varias lecturas posibles, las etiquetas de acción sueltas y los términos de dominio llevan un comment= que describe dónde aparece la cadena. context= se reserva para cuando el mismo texto necesita traducciones distintas en sitios distintos.

Mantenimiento del catálogo. Cada cadena nueva se envuelve y se añade a cada src/locales/*/messages.po con un msgstr vacío, de modo que Lingui recurre al texto fuente hasta que llega una traducción. El agente nunca ejecuta lingui extract, porque Lovable no tiene terminal; de eso se encarga una GitHub Action tras la sincronización. Y nunca edita las líneas de comentario #. y #: de las entradas existentes, porque la extracción las regenera.

Esa última sección es lo que hace que las reglas sean específicas de Lovable. Un archivo de reglas de Cursor o Claude Code puede terminar con «ejecuta el linter». Uno de Lovable no puede, así que tiene que indicar qué hacer a mano y qué dejar para CI.

¿Qué hace cumplir la regla cuando Lovable no puede ejecutar nada?

El workflow de GitHub, y solo el workflow de GitHub. Lovable no tiene terminal, así que no hay paso de lint entre el momento en que el agente escribe un literal y el momento en que el cambio se sincroniza con tu repositorio. Esa es la diferencia estructural con los agentes de IDE, donde una regla de lint en CI es lo que hace fallar el build ante una cadena codificada.

Si lo activas durante la configuración, el Skill añade un workflow de GitHub Actions que se ejecuta en los push a la rama por defecto, que es donde aterriza la sincronización de Lovable, extrae las cadenas envueltas a los catálogos y vuelve a subir al repositorio un commit con el catálogo sincronizado. Si la app de GitHub no tiene el permiso workflows, el Skill te pide que añadas el archivo a mano en GitHub. Eso cierra el círculo para todo lo que el agente envolvió. No hace nada por una cadena que el agente no envolvió, porque la extracción solo ve macros.

Así que el panorama real es este: las reglas de AGENTS.md reducen la frecuencia con que aparece un literal sin envolver, el puntero en el knowledge las respalda en los chats largos y el diff en GitHub es donde atrapas el resto. Si quieres que una máquina atrape el resto, añade la regla no-literal-string de eslint-plugin-i18next como paso del mismo workflow. Se ejecuta sobre el repositorio, el único sitio donde un proyecto de Lovable puede ejecutar algo.

¿Qué pasa con las cadenas que sí se envuelven?

Hay que traducirlas, y eso es lo que merece la pena automatizar en lugar de repetir prompts. La conversión se hace una sola vez y ocurre en la app: conectas el repositorio y globalize.now convierte el codebase una vez, entregando el catálogo como una pull request que revisas. Después, los jobs de push traducen las unidades nuevas del catálogo a medida que llegan, de modo que un <Trans> que Lovable escribió el martes tiene sus traducciones en una pull request el miércoles. Sin paso por dashboard, sin exportación, sin cola de aprobación; el argumento más extenso a favor de este enfoque está en localizar una app de Lovable sin dashboard, y el camino exacto de configuración, incluida la conexión con GitHub y el conector de globalize, está en la página de integración con Lovable.

Una nota histórica, porque explica por qué este problema les resulta nuevo a algunos builders de Lovable. Lovalingo traducía las apps de Lovable en runtime, en el navegador, así que un componente nuevo generado en inglés simplemente se volvía a traducir al cargar y el problema nunca salía a la superficie. Cerró el 31 de agosto de 2026, y las apps que pasaron a catálogos versionados con la guía de migración se topan por primera vez con la cuestión de origen. El modelo de catálogos es la mejor contrapartida, porque el markup traducido es tuyo e indexable, pero exige que el agente escriba código traducible, y eso implica decirle dónde están las reglas.

Pon las reglas donde Lovable las lee

Ejecuta el Skill una vez para que AGENTS.md lleve el bloque completo, pega el puntero de dos líneas en el knowledge del proyecto y deja que el workflow de GitHub haga la extracción que el editor no puede. Si construyes en Lovable y quieres que la traducción de todo lo que llega al catálogo quede resuelta en lugar de tener que mantenerla, la página de Vibe Coders ofrece el resumen y los precios tienen su propia página.