Internationalisation

Ajoutez la prise en charge multilingue à votre application. Utilisez la Proyecta Content API pour la localisation éditoriale, ou demandez à l’IA de configurer un framework i18n directement dans le code.

Proyecta propose deux approches complémentaires pour internationaliser les applications que tu crées :

1. Localisation de contenu via la Proyecta Content API — pour le contenu éditorial (articles de blog, FAQ, textes marketing) qui doit être traduit en plusieurs langues
2. i18n au niveau du code via un framework de traduction — pour les chaînes d’interface, les dates, les devises et le changement de locale à l’exécution

Les deux fonctionnent dès aujourd’hui. Laquelle choisir dépend de ce que tu traduis.

Proyecta lui-même est livré avec 24 locales, le produit maîtrise donc parfaitement l’i18n. Les mêmes patterns s’appliquent aux applications que tu construis à l’intérieur.

Option 1 : Localisation de contenu (Proyecta Content API)

Si tu construis un site à fort contenu — blog, base de connaissances, pages marketing, catalogue produits — utilise la prise en charge native des locales. Indique à l’IA les langues que tu supportes ("Make the site available in English, Spanish and French") et elle les enregistre pour toi, avec l’anglais comme langue par défaut. Récupère ensuite ton contenu dans la langue du visiteur.

Côté frontend, les hooks de contenu typés du template résolvent les champs localisés pour toi — transmets la locale active du visiteur et chaque champ localized te renvoie une valeur traduite unique :

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
}

En coulisses, le CMS parcourt une chaîne de fallback — la locale demandée → ses fallbacks configurés → la locale par défaut — et indique le code effectivement servi sur chaque entrée via localeResolved. Omets locale sur les sites en une seule langue et les champs sont renvoyés sous forme de valeurs brutes.

C’est la bonne solution quand :

• Des rédacteurs non techniques ont besoin de traduire du contenu
• Tu veux que les traductions soient versionnables
• Tu as besoin d’une publication spécifique par locale (la publication planifiée arrive prochainement — les entrées nécessitent actuellement une publication manuelle via l’API)

Consulte Gestion de contenu pour la Content API complète.

Option 2 : Framework i18n au niveau du code

Pour les chaînes d’interface — libellés, boutons, messages d’erreur, dates, devises — demande à l’IA de configurer un framework i18n directement dans ton projet :

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.

L’IA va :

1. Choisir un framework — l’IA utilise i18next avec react-i18next (le standard Proyecta)
2. Créer les fichiers de catalogue dans src/locales/ (un JSON par langue)
3. Encapsuler le texte dans des appels t() (via le hook useTranslation de react-i18next)
4. Ajouter un composant de sélection de langue
5. Configurer le routage URL avec des préfixes de locale
6. Gérer les layouts RTL (dir="rtl") pour l’arabe, l’hébreu, etc.
7. Formater les nombres, dates et devises selon la locale

Traduction automatique avec l’IA

Une fois ta langue de base en place, l’IA est très efficace pour générer les autres fichiers de catalogue :

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

Pour les contenus à enjeux élevés (textes juridiques, médical, finance), fais relire le résultat de l’IA par un traducteur humain avant de mettre en production.

Combiner les deux approches

La plupart des applications réelles utilisent les deux : l’i18n au niveau du code pour l’interface générale (boutons, erreurs, navigation), et la Content API pour le contenu éditorial (articles, descriptions de produits). Les deux coexistent sans friction — ton framework i18n gère les fichiers de catalogue au moment du build, la Content API sert les entrées localisées à l’exécution.

Bonnes pratiques

1. Choisis ta langue de base et finalise les textes en premier. Traduire une cible mouvante est pénible.
2. Regroupe les traductions. Ne traduis pas au fil de l’eau — attends qu’une fonctionnalité soit stable.
3. Teste le RTL tôt si tu supportes l’arabe ou l’hébreu. Les bugs RTL ne se voient pas tant qu’on ne regarde pas vraiment.
4. Inclus lang et dir sur <html>. Les navigateurs et les lecteurs d’écran en dépendent.
5. Utilise Intl pour le formatage. Ne code pas manuellement le formatage des dates ou des devises — utilise Intl.DateTimeFormat, Intl.NumberFormat.

Prochainement

• Interface de gestion des locales dans le builder — choisis tes locales, visualise la couverture des traductions, modifie les catalogues sans quitter Proyecta
• Traduction automatique à la sauvegarde pour les nouvelles chaînes
• Templates de projets prêts pour l’i18n avec le framework préconfiguré