Internacionalización

Agrega soporte multiidioma a tu app. Usa la API de Contenido de Proyecta para localización editorial, o pídele a la IA que integre un framework de i18n directamente en el código.

Proyecta admite dos enfoques complementarios para internacionalizar las apps que construyes:

1. Localización de contenido mediante la API de Contenido de Proyecta — para contenido editorial (artículos de blog, FAQs, copy de marketing) que necesita traducirse a varios idiomas
2. i18n a nivel de código mediante un framework de traducción — para cadenas de UI, fechas, monedas y cambio de idioma en tiempo de ejecución

Ambos funcionan hoy. Cuál necesitas depende de lo que vayas a traducir.

Proyecta como builder se entrega con 24 locales, por lo que el producto domina el i18n. Los mismos patrones aplican a las apps que construyes dentro de él.

Opción 1: Localización de contenido (API de Contenido de Proyecta)

Si estás construyendo un sitio con mucho contenido — blog, base de conocimiento, páginas de marketing, catálogo de productos — usa el soporte de locales integrado. Dile a la IA qué idiomas soportas ("Make the site available in English, Spanish and French") y ella los registra por ti, con inglés como predeterminado. Luego recupera tu contenido en el idioma del visitante.

En el frontend, los hooks de contenido tipados del template resuelven los campos localizados por ti — pasa el locale activo del visitante y cada campo localized regresa como un único valor traducido:

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
}

Internamente, el CMS recorre una cadena de fallback — el locale solicitado → sus fallbacks configurados → el locale predeterminado — e indica el código que realmente sirvió en cada entrada como localeResolved. Omite locale en sitios de un solo idioma y los campos regresan como valores directos.

Esta es la opción correcta cuando:

• Editores que no escriben código necesitan traducir contenido
• Quieres que las traducciones sean versionables
• Necesitas publicación específica por locale (la publicación programada estará disponible próximamente — actualmente las entradas requieren publicación manual mediante la API)

Consulta Gestión de Contenido para conocer la API de Contenido completa.

Opción 2: Framework de i18n a nivel de código

Para cadenas de UI — etiquetas, botones, mensajes de error, fechas, monedas — pídele a la IA que integre un framework de i18n directamente en tu proyecto:

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.

La IA hará lo siguiente:

1. Elegirá un framework — la IA usa i18next con react-i18next (el estándar de Proyecta)
2. Creará archivos de catálogo en src/locales/ (un JSON por idioma)
3. Envolverá el texto en llamadas t() (del hook useTranslation de react-i18next)
4. Agregará un componente selector de idioma
5. Configurará el enrutamiento de URLs con prefijos de locale
6. Manejará layouts RTL (dir="rtl") para árabe, hebreo, etc.
7. Formateará números, fechas y monedas según el locale

Auto-traducción con la IA

Una vez que tu idioma base está listo, la IA es excelente para generar los demás archivos 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 contenido crítico (textos legales, médicos, financieros), pide a un traductor humano que revise el resultado de la IA antes de publicar.

Combinando ambos enfoques

La mayoría de las apps reales usan los dos: i18n a nivel de código para el chrome de la UI (botones, errores, navegación), y la API de Contenido para el contenido editorial (artículos, descripciones de productos). Coexisten sin problema — tu framework de i18n maneja los archivos de catálogo en tiempo de compilación, y la API de Contenido sirve las entradas localizadas en tiempo de ejecución.

Buenas prácticas

1. Elige tu idioma base y finaliza el copy primero. Traducir un objetivo en movimiento es costoso.
2. Agrupa las traducciones. No traduzcas sobre la marcha — espera hasta que una funcionalidad esté estable.
3. Prueba RTL desde el principio si soportas árabe o hebreo. Los bugs de RTL no se notan hasta que realmente los buscas.
4. Incluye lang y dir en <html>. Los navegadores y lectores de pantalla dependen de ello.
5. Usa Intl para el formato. No implementes manualmente el formato de fechas o monedas — usa Intl.DateTimeFormat, Intl.NumberFormat.

Próximamente

• UI de gestión de locales en el builder — elige locales, visualiza la cobertura de traducción y edita catálogos sin salir de Proyecta
• Auto-traducción al guardar para cadenas nuevas
• Templates de proyecto listos para i18n con el framework preconfigurado