Como adicionar a skill lovable-i18n a um workspace do Lovable?

Você a adiciona a partir do GitHub: abra Settings, depois Skills, depois Add, depois Import from GitHub, e aponte o Lovable para o repositório globalize-now/lovable-i18n. O Lovable baixa, valida e publica no workspace, onde todo projeto pode usá-la. O globalize.now é uma infraestrutura de localização com IA: ele gera as chaves e os arquivos de idioma, e a biblioteca de runtime do seu app é quem os utiliza. A skill é o meio pelo qual isso acontece sem sair do editor do Lovable, e é por isso que não existe painel nenhum nesse caminho.

O que é, exatamente, uma skill do Lovable?

Uma skill é um playbook curto, com nome próprio, que você armazena uma única vez no nível do workspace. Ela tem três partes: um nome permanente em minúsculas, uma descrição que informa ao Lovable quando carregá-la e instruções em markdown que o Lovable segue quando ela é aplicada.

A propriedade importante é que as skills carregam sob demanda. O conhecimento de workspace é diferente — esse sempre está no contexto, e é onde ficam padrões de código e regras de marca. Uma skill só entra na conversa quando o pedido corresponde à sua descrição, então um workspace pode conter muitas skills específicas sem que nenhuma delas sobrecarregue trabalhos não relacionados.

Você pode invocar uma deliberadamente digitando / no campo de chat e selecionando-a, ou deixar o Lovable aplicá-la automaticamente quando seu prompt corresponder. Pense na skill como o como e no seu prompt como o o quê.

Elas também são portáteis. O Lovable usa o mesmo formato SKILL.md da convenção Agent Skills da Anthropic, e é por isso que uma skill escrita para uma ferramenta é importada pela outra sem nenhuma adaptação. Isso não é um detalhe pequeno para localização: significa que as mesmas instruções que montam o i18n dentro do Lovable podem seguir para um repositório que você abra depois no Claude Code ou Cursor.

Por que um app Lovable é lançado só em inglês?

Porque o código gerado não tem nenhuma camada de idiomas para lançar qualquer outra coisa. Quando você pede ao Lovable uma página de preços, ele escreve o título diretamente no componente como um texto literal, no idioma em que você fez o prompt. Cada botão, estado vazio, toast e mensagem de validação chega da mesma forma.

Pedir ao agente para "traduzir o app" depois gera um resultado pela metade: as telas que ele inspecionou por acaso são trocadas, e a próxima funcionalidade que você constrói chega em inglês de novo. Documentamos essa recorrência em detalhe em por que as traduções do Lovable perdem a consistência, e o mecanismo não mudou — o agente resolve o prompt que está diante dele, não a arquitetura por trás dele.

A solução é estrutural e pontual: dê chaves às strings, coloque as traduções em arquivos, faça o runtime ler desses arquivos. Uma skill é um bom veículo para esse trabalho justamente por ser um playbook fixo, em vez de um prompt que você precisa formular corretamente todas as vezes.

O que a skill lovable-i18n instala?

Lingui v6, com catálogos PO em src/locales/[locale]/messages.po, macros Trans para extração, um componente de seletor de idioma e uma GitHub Action. Ele detecta qual stack seu projeto usa e monta a estrutura de acordo — Vite SPA ou TanStack Start, ambos gerados pelo Lovable.

Essa detecção de stack importa mais do que parece. A stack padrão gerada pelo Lovable migrou para o TanStack Start com renderização no servidor, e a configuração correta de i18n muda entre um SPA renderizado no cliente e um app renderizado no servidor. Cobrimos o caso de renderização no servidor separadamente no guia do TanStack Start; a skill escolhe o caminho certo para que você não precise saber qual dos dois você tem.

O que ela não instala é uma dependência de runtime em relação a nós. Os catálogos são arquivos no seu repositório. Se você removesse o globalize.now amanhã, um app Lingui com arquivos PO commitados continuaria renderizando todos os idiomas que já tinha.

Como você importa a skill?

Quatro etapas, uma única vez por workspace.

1. Conecte o projeto Lovable ao GitHub. Use o menu + no campo de chat, escolha GitHub, depois Connect project. Os catálogos precisam de um repositório de verdade para existir.
2. Importe a skill. Settings, depois Skills, depois Add, depois Import from GitHub, apontando para https://github.com/globalize-now/lovable-i18n. O SKILL.md fica na raiz do repositório, que é o layout que o Lovable espera quando você fornece uma URL de repositório inteiro. Um subdiretório dentro de um repositório maior de skills também funciona, usando uma URL tree ou blob.
3. Adicione o MCP da globalize. Abra Connectors, escolha Custom MCP e adicione https://api.globalize.now/mcp. A skill te guia pela etapa de login quando chegar a hora.
4. Faça o prompt no Lovable. Peça para ele usar a skill lovable-i18n e o MCP da globalize para configurar o i18n e traduzir o app.

Duas restrições importantes antes de começar. Criar, editar, excluir e importar skills personalizadas do workspace é restrito a owners e admins do workspace — editores podem ver e invocar qualquer skill, mas não podem adicionar novas. E adicionar uma skill pelas Configurações não consome créditos; a mensagem que depois usa essa skill é cobrada como qualquer outra mensagem de build.

O passo a passo completo, com as URLs exatas, está na página de integração com o Lovable.

Qual MCP é esse, e qual não é?

Essa é a parte confusa, e entender ao contrário custa uma tarde inteira.

O Lovable expõe duas superfícies MCP que apontam em direções opostas. O servidor Lovable MCP, em mcp.lovable.dev, permite que um agente externo — ChatGPT, Claude, Cursor, VS Code — crie e edite seus projetos Lovable a partir de outro lugar. Os chat connectors, adicionados em Connectors como um MCP personalizado, funcionam ao contrário: eles permitem que o agente do Lovable acesse uma ferramenta externa enquanto você constrói o app.

O MCP da globalize é do segundo tipo. Você está dando ao agente do Lovable a capacidade de criar seu projeto de localização, traduzir os catálogos e conectar o repositório, sem precisar abrir um segundo produto para isso. A própria documentação do Lovable faz essa distinção de forma explícita, o que já é um bom sinal de que essa confusão é comum.

A consequência prática: se você se pegar colando uma URL no Claude ou no Cursor para fazer isso funcionar, você está na superfície errada. Aqui, tudo acontece dentro do editor do Lovable.

O que acontece depois da configuração inicial?

A skill monta a estrutura, e o diff é sincronizado com o GitHub. Revise como faria com qualquer outra mudança — a configuração do Lingui, os catálogos PO, as edições nos componentes que envolvem strings em macros Trans, o seletor de idioma — e depois faça o merge para a sua branch padrão.

Depois disso, a conversão está concluída. Ela acontece uma única vez, dentro do app: você conectou o repositório, e o globalize.now converteu a base de código uma vez para gerar o catálogo. A partir daí, os push jobs traduzem as novas unidades do catálogo e as entregam como um pull request que você faz o merge. Você continua dando prompts no Lovable normalmente; as novas strings vão parar no catálogo em vez de se acumularem como textos fixos não traduzidos.

Não existe etapa de exportação, nem de importação, nem uma tela onde alguém aprova strings uma a uma. Se você quiser entender melhor por que isso importa, veja como localizar um app Lovable sem dashboard.

Por que uma skill em vez de um widget de tradução?

Porque um widget e um catálogo geram artefatos diferentes, e só um deles é seu.

Um widget em tempo de execução — o modelo do Weglot — injeta JavaScript que reescreve o texto no navegador depois que a página já carregou. O resultado é um flash de inglês, um layout que se ajusta conforme o tamanho das strings muda, e uma única página em inglês no índice, com a tradução acontecendo no lado do cliente, onde um crawler não consegue enxergar de forma confiável. Funciona em qualquer site, que é seu grande diferencial, e é uma escolha razoável para uma landing page de marketing cujo código você não controla.

Um catálogo commitado é a troca oposta. Exige acesso ao código, o que você tem, e em troca o markup traduzido é renderizado a partir do seu próprio repositório, com uma página indexável por idioma. O Lovalingo foi construído sobre o modelo em tempo de execução especificamente para o Lovable e encerrou as atividades em 31 de agosto de 2026; se você está migrando dele, o guia de migração mostra como exportar o que você tinha. Esse encerramento também é o argumento mais claro a favor do formato baseado em arquivos: catálogos PO no seu histórico do Git não dependem de uma empresa continuar existindo.

Se você quiser a versão completa, focada no resultado em vez do mecanismo, comece por tornar um app Lovable multilíngue. Se quiser saber quanto custa antes de começar, a página de preços tem os planos atuais.

Adicione uma vez

A importação é uma ação única no workspace, e é gratuita. Depois disso, i18n é algo que você pede pelo chat, como qualquer outra funcionalidade, e as traduções chegam como arquivos que são seus.