Internationalization

Add multi-language support to your app. Use the Proyecta Content API for editorial localization, or ask the AI to wire up an i18n framework directly in code.

Proyecta supports two complementary approaches to internationalizing the apps you build:

1. Content localization via the Proyecta Content API — for editorial content (blog posts, FAQs, marketing copy) that needs to be translated into multiple languages
2. Code-level i18n via a translation framework — for UI strings, dates, currencies, and runtime locale switching

Both work today. Which one you need depends on what you’re translating.

Proyecta the builder itself ships with 24 locales, so the product is fluent in i18n. The same patterns apply to the apps you build inside it.

Option 1: Content localization (Proyecta Content API)

If you’re building a content-heavy site — blog, knowledge base, marketing pages, product catalog — use the built-in locale support. Tell the AI which languages you support ("Make the site available in English, Spanish and French") and it registers them for you, with English as the default. Then read your content back in the visitor’s language.

On the front end, the template’s typed content hooks resolve localized fields for you — pass the visitor’s active locale and each localized field comes back as a single translated value:

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
}

Behind the scenes the CMS walks a fallback chain — the requested locale → its configured fallbacks → the default locale — and reports the code it actually served on each entry as localeResolved. Omit locale on single-language sites and fields come back as raw values.

This is the right answer when:

• Editors who don’t write code need to translate content
• You want translations to be versionable
• You need locale-specific publishing (scheduled publishing is coming soon — entries currently require manual publish via the API)

See Content Management for the full Content API.

Option 2: Code-level i18n framework

For UI strings — labels, buttons, error messages, dates, currencies — ask the AI to wire up an i18n framework directly into your project:

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.

The AI will:

1. Pick a framework — the AI uses i18next with react-i18next (Proyecta’s standard)
2. Create catalog files in src/locales/ (one JSON per language)
3. Wrap text in t() calls (from react-i18next’s useTranslation hook)
4. Add a language switcher component
5. Wire URL routing with locale prefixes
6. Handle RTL layouts (dir="rtl") for Arabic, Hebrew, etc.
7. Format numbers, dates, and currencies per locale

Auto-translate with the AI

Once your base language is in place, the AI is great at producing the other catalog files:

• "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."

For high-stakes content (legal copy, medical, finance), have a human translator review the AI output before shipping.

Combining both approaches

Most real apps use both: code-level i18n for UI chrome (buttons, errors, navigation), and the Content API for editorial content (articles, product descriptions). They coexist cleanly — your i18n framework handles the catalog files at build time, the Content API serves localized entries at runtime.

Best practices

1. Pick your base language and finalize copy first. Translating a moving target is painful.
2. Batch translations. Don’t translate as you go — wait until a feature is stable.
3. Test RTL early if you support Arabic or Hebrew. RTL bugs hide until you actually look.
4. Include lang and dir on <html>. Browsers and screen readers depend on it.
5. Use Intl for formatting. Don’t hand-roll date or currency formatting — use Intl.DateTimeFormat, Intl.NumberFormat.

Coming soon

• In-builder locale management UI — pick locales, see translation coverage, edit catalogs without leaving Proyecta
• Auto-translate-on-save for new strings
• i18n-ready project templates with the framework pre-wired