Internacionalização

Adicione suporte a múltiplos idiomas ao seu app. Use a Proyecta Content API para localização editorial, ou peça à IA para configurar um framework de i18n diretamente no código.

O Proyecta suporta duas abordagens complementares para internacionalizar os apps que você cria:

1. Localização de conteúdo via Proyecta Content API — para conteúdo editorial (posts de blog, FAQs, textos de marketing) que precisa ser traduzido para múltiplos idiomas
2. i18n no nível do código via um framework de tradução — para strings de interface, datas, moedas e troca de idioma em tempo de execução

Ambas funcionam hoje. Qual você precisa depende do que está sendo traduzido.

O próprio Proyecta, como builder, vem com 24 locales, então o produto é fluente em i18n. Os mesmos padrões se aplicam aos apps que você cria dentro dele.

Opção 1: Localização de conteúdo (Proyecta Content API)

Se você está construindo um site com muito conteúdo — blog, base de conhecimento, páginas de marketing, catálogo de produtos — use o suporte nativo a locales. Diga à IA quais idiomas você suporta ("Make the site available in English, Spanish and French") e ela os registra para você, com o inglês como padrão. Em seguida, leia seu conteúdo no idioma do visitante.

No frontend, os hooks de conteúdo tipados do template resolvem os campos localizados para você — passe o locale ativo do visitante e cada campo localized retorna como um único valor traduzido:

import { useCollection, useEntry } from '@/hooks/useContent';
import { useTranslation } from 'react-i18next';

function Blog({ slug }: { slug: string }) {
    const { i18n } = useTranslation();

    // List a collection in the current locale
    const { data: posts } = useCollection('posts', { locale: i18n.language });

    // Or read one entry by slug in the current locale
    const { data: post } = useEntry('posts', slug, { locale: i18n.language });

    // ...render posts / post
}

Por baixo dos panos, o CMS percorre uma cadeia de fallback — o locale solicitado → seus fallbacks configurados → o locale padrão — e reporta o código que de fato foi servido em cada entrada como localeResolved. Omita locale em sites de idioma único e os campos retornam como valores brutos.

Essa é a escolha certa quando:

• Editores que não escrevem código precisam traduzir conteúdo
• Você quer que as traduções sejam versionáveis
• Você precisa de publicação por locale específico (publicação agendada está chegando em breve — atualmente as entradas exigem publicação manual via API)

Consulte Gerenciamento de Conteúdo para a Content API completa.

Opção 2: Framework de i18n no nível do código

Para strings de interface — rótulos, botões, mensagens de erro, datas, moedas — peça à IA para configurar um framework de i18n diretamente no seu projeto:

Add internationalization to my app.
Support English, Spanish, French, and Arabic.
Add message catalogs in src/locales/.
Add a language switcher in the header.
Use locale-prefixed URLs like /en/about and /es/about.
Make sure RTL layout works correctly for Arabic.

A IA irá:

1. Escolher um framework — a IA usa i18next com react-i18next (o padrão do Proyecta)
2. Criar os arquivos de catálogo em src/locales/ (um JSON por idioma)
3. Envolver os textos em chamadas t() (do hook useTranslation do react-i18next)
4. Adicionar um componente de seleção de idioma
5. Configurar o roteamento de URLs com prefixos de locale
6. Tratar layouts RTL (dir="rtl") para árabe, hebraico, etc.
7. Formatar números, datas e moedas por locale

Tradução automática com a IA

Assim que seu idioma base estiver pronto, a IA é excelente para gerar os demais arquivos de catálogo:

• "Translate every string in src/locales/en.json into Spanish, French, German, and Japanese. Use natural, idiomatic phrasing — don't translate brand names."
• "My app is fully built in English. Add Spanish translations for everything and an es/ route prefix."

Para conteúdo de alto risco (textos jurídicos, médicos, financeiros), peça a um tradutor humano que revise o resultado da IA antes de colocar em produção.

Combinando as duas abordagens

A maioria dos apps reais usa as duas: i18n no nível do código para a interface (botões, erros, navegação) e a Content API para conteúdo editorial (artigos, descrições de produtos). Elas coexistem de forma limpa — seu framework de i18n cuida dos arquivos de catálogo em tempo de build, e a Content API serve as entradas localizadas em tempo de execução.

Boas práticas

1. Defina seu idioma base e finalize os textos primeiro. Traduzir um alvo em movimento é trabalhoso.
2. Agrupe as traduções. Não traduza conforme avança — espere até que uma funcionalidade esteja estável.
3. Teste RTL cedo se você suporta árabe ou hebraico. Bugs de RTL só aparecem quando você realmente olha.
4. Inclua lang e dir no <html>. Navegadores e leitores de tela dependem disso.
5. Use Intl para formatação. Não implemente formatação de data ou moeda manualmente — use Intl.DateTimeFormat, Intl.NumberFormat.

Em breve

• Interface de gerenciamento de locales no builder — escolha locales, veja a cobertura de tradução e edite catálogos sem sair do Proyecta
• Tradução automática ao salvar para novas strings
• Templates de projeto prontos para i18n com o framework pré-configurado