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:

Content localization via the Proyecta Content API — for editorial content (blog posts, FAQs, marketing copy) that needs to be translated into multiple languages
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 Content API’s built-in locale support.

// Create the locales you support
await proyecta.content.locales.create({ /* code: 'en', name: 'English' */ });
await proyecta.content.locales.create({ /* code: 'es', name: 'Español' */ });
await proyecta.content.locales.create({ /* code: 'fr', name: 'Français' */ });

// Then create entries that exist in multiple locales — fetch the right
// translation per request based on the user's locale.

This is the right answer when:

Editors who don’t write code need to translate content
You want translations to be versionable, schedulable, and previewable
You need locale-specific publishing (e.g. launch the German page next month)

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.
Use react-intl with 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:

Pick a framework — typically react-intl, next-intl, or i18next depending on your stack
Create catalog files in src/locales/ (one JSON per language)
Wrap text in <FormattedMessage /> or t() calls
Add a language switcher component
Wire URL routing with locale prefixes
Handle RTL layouts (dir="rtl") for Arabic, Hebrew, etc.
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

Pick your base language and finalize copy first. Translating a moving target is painful.
Batch translations. Don’t translate as you go — wait until a feature is stable.
Test RTL early if you support Arabic or Hebrew. RTL bugs hide until you actually look.
Include lang and dir on <html>. Browsers and screen readers depend on it.
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