¿Cómo se añade el Skill lovable-i18n a un workspace de Lovable?

Lo añades desde GitHub: abre Settings, luego Skills, luego Add, luego Import from GitHub, y apunta Lovable al repositorio globalize-now/lovable-i18n. Lovable lo descarga, lo valida y lo publica en el workspace, donde cualquier proyecto puede usarlo. globalize.now es infraestructura de localización impulsada por IA: genera las claves y los archivos de traducción, y la biblioteca de runtime de tu app los sirve. El Skill es cómo eso llega sin salir del editor de Lovable, y la razón por la que no hay ningún dashboard en el camino.

¿Qué es exactamente un Skill de Lovable?

Un Skill es un playbook corto y con nombre propio que guardas una vez a nivel de workspace. Tiene tres partes: un nombre permanente en minúsculas, una descripción que le indica a Lovable cuándo cargarlo, e instrucciones en markdown que Lovable sigue cuando se aplica.

La propiedad importante es que los Skills se cargan cuando se necesitan. El conocimiento de workspace es distinto — ese siempre está en contexto, y ahí es donde van los estándares de código y las reglas de marca. Un Skill solo entra en la conversación cuando la solicitud coincide con su descripción, así que un workspace puede tener muchos Skills específicos sin que ninguno recargue trabajo que no le corresponde.

Puedes invocar uno de forma deliberada escribiendo / en el campo de chat y eligiéndolo, o dejar que Lovable lo aplique automáticamente cuando tu prompt coincida. Piensa en el Skill como el cómo y en tu prompt como el qué.

También son portables. Lovable usa la misma estructura SKILL.md que la convención Agent Skills de Anthropic, por eso un Skill escrito para una herramienta se importa en la otra sin traducción. Eso no es un detalle menor para la localización: significa que las mismas instrucciones que montan i18n dentro de Lovable pueden viajar a un repositorio que después abras en Claude Code o Cursor.

¿Por qué una app de Lovable sale solo en inglés?

Porque el código generado no tiene ninguna capa de locale que pueda usar para hacer otra cosa. Cuando le pides a Lovable una página de precios, escribe el encabezado directamente en el componente como un literal, en el idioma en el que se lo pediste. Cada botón, estado vacío, toast y mensaje de validación se genera igual.

Pedirle al agente que «traduzca la app» más tarde da un resultado a medias: las pantallas que revisó por casualidad quedan traducidas, y la siguiente funcionalidad que construyes vuelve a llegar en inglés. Documentamos esta recurrencia en detalle en por qué las traducciones de Lovable se desincronizan, y el mecanismo no ha cambiado — el agente resuelve el prompt que tiene delante, no la arquitectura que hay detrás.

La solución es estructural y se hace una sola vez: dar claves a las cadenas, poner las traducciones en archivos y hacer que el runtime las lea desde ahí. Un Skill es un buen vehículo para ese trabajo precisamente porque es un procedimiento fijo, no un prompt que hay que redactar bien dos veces.

¿Qué instala el skill lovable-i18n?

Lingui v6, con catálogos PO en src/locales/[locale]/messages.po, macros Trans para la extracción, un componente selector de idioma y una GitHub Action. Detecta qué stack usa tu proyecto y genera la estructura en consecuencia — Vite SPA o TanStack Start, los dos stacks que genera Lovable.

Esa detección del stack importa más de lo que parece. El stack por defecto que genera Lovable pasó a ser TanStack Start con renderizado en servidor, y el cableado correcto de i18n es distinto entre una SPA renderizada en cliente y una app renderizada en servidor. Cubrimos el caso de renderizado en servidor por separado en la guía de TanStack Start; el Skill elige la ruta correcta para que no tengas que saber cuál te tocó.

Lo que no instala es una dependencia en tiempo de ejecución de nosotros. Los catálogos son archivos en tu repositorio. Si eliminaras globalize.now mañana, una app con Lingui y archivos PO ya confirmados sigue renderizando cada idioma que ya tiene.

¿Cómo se importa el Skill?

Cuatro pasos, una sola vez por workspace.

1. Conecta el proyecto de Lovable a GitHub. Usa el menú + en el input del chat, elige GitHub y luego Connect project. Los catálogos necesitan un repositorio real donde vivir.
2. Importa el Skill. Settings, luego Skills, luego Add, luego Import from GitHub, apuntando a https://github.com/globalize-now/lovable-i18n. El SKILL.md está en la raíz del repositorio, que es la estructura que espera Lovable cuando le das una URL de repositorio completo. Un subdirectorio dentro de un repositorio de Skills más grande también funciona, usando una URL tree o blob.
3. Añade el MCP de globalize. Abre Connectors, elige Custom MCP y añade https://api.globalize.now/mcp. El Skill te guía por el paso de inicio de sesión cuando llega el momento.
4. Dale el prompt a Lovable. Pídele que use el Skill lovable-i18n y el MCP de globalize para configurar i18n y traducir la app.

Dos restricciones que conviene conocer antes de empezar. Crear, editar, eliminar e importar Skills personalizados del workspace está restringido a los owners y admins del workspace — los editores pueden ver e invocar cualquier Skill, pero no pueden añadir uno. Y añadir un Skill desde Settings no consume créditos; el mensaje que más adelante lo usa se factura como cualquier otro mensaje de build.

El paso a paso completo con las URL exactas está en la página de integración de Lovable.

¿Cuál es este MCP, y cuál no es?

Esta es la parte que confunde, y entenderla al revés te cuesta una tarde entera.

Lovable expone dos superficies MCP que apuntan en direcciones opuestas. El servidor MCP de Lovable en mcp.lovable.dev permite que un agente externo — ChatGPT, Claude, Cursor, VS Code — cree y edite tus proyectos de Lovable desde otro sitio. Los chat connectors, añadidos en Connectors como un MCP personalizado, son lo contrario: dejan que el agente de Lovable acceda a una herramienta externa mientras construyes.

El MCP de globalize es del segundo tipo. Le estás dando al agente de Lovable la capacidad de crear tu proyecto de localización, traducir los catálogos y conectar el repositorio, sin que tengas que abrir un segundo producto para hacerlo. La propia documentación de Lovable marca esta distinción explícitamente, señal de que suele confundir a la gente.

La consecuencia práctica: si te encuentras pegando una URL en Claude o Cursor para que esto funcione, estás en la superficie equivocada. Todo esto ocurre dentro del editor de Lovable.

¿Qué pasa después de la primera configuración?

El Skill genera la estructura y el diff se sincroniza con GitHub. Revísalo como cualquier otro cambio — la configuración de Lingui, los catálogos PO, las ediciones de componentes que envuelven cadenas en macros Trans, el selector de idioma — y después haz merge a tu rama por defecto.

A partir de ahí, la conversión está hecha. Es algo que se hace una sola vez y dentro de la app: conectaste el repositorio, y globalize.now convirtió el codebase una vez para generar el catálogo. Desde ese momento, los push jobs traducen las nuevas unidades del catálogo y las entregan como un pull request que tú haces merge. Sigues dándole prompts a Lovable con normalidad; las cadenas nuevas llegan al catálogo en vez de acumularse como literales sin traducir.

No hay paso de exportación, ni paso de importación, ni pantalla donde alguien apruebe cadenas una por una. Si quieres el argumento más largo de por qué esto importa, está en localizar una app de Lovable sin dashboard.

¿Por qué un Skill y no un widget de traducción?

Porque un widget y un catálogo producen artefactos distintos, y solo uno de los dos es tuyo.

Un widget en tiempo de ejecución — el modelo de Weglot — inyecta JavaScript que reescribe el texto en el navegador después de que la página ya cargó. Obtienes un destello de inglés, un layout que se mueve cuando las cadenas cambian de longitud, y una sola página en inglés en el índice, con la traducción ocurriendo en el cliente, donde un crawler no la ve de forma fiable. Funciona en cualquier sitio, que es su verdadero argumento de venta, y es una opción razonable para una página de marketing cuyo código no controlas.

Un catálogo confirmado en el repositorio es el trato contrario. Requiere acceso al código, que tú tienes, y a cambio el markup traducido se renderiza desde tu propio repositorio, con una página indexable por idioma. Lovalingo se construyó sobre el modelo en tiempo de ejecución específicamente para Lovable y cerró el 31 de agosto de 2026; si estás migrando desde ahí, la guía de migración explica cómo exportar lo que tenías. Ese cierre es también el argumento más claro a favor del formato basado en archivos: los catálogos PO en tu historial de Git no dependen de que una empresa siga existiendo.

Si quieres la versión de extremo a extremo enfocada en el resultado y no en el mecanismo, empieza con hacer multilingüe una app de Lovable. Si quieres saber cuánto cuesta antes de empezar, la página de precios tiene los planes actuales.

Añádelo una vez

La importación es una acción del workspace que se hace una sola vez, y es gratis. A partir de ahí, i18n es algo que pides en el input del chat como cualquier otra funcionalidad, y las traducciones llegan como archivos que son tuyos.