Étiquettes multilingues
GCM est livré avec l'anglais, l'espagnol, le français et le portugais comme langues d'interface supportées. Les chaînes d'interface (étiquettes de boutons, éléments de menu, messages d'erreur) viennent des fichiers de traduction i18n/locales/<lang>.json maintenus par la plateforme. Mais les données — vos types de membres, les noms de vos réunions, vos pays, vos états civils — vivent dans la base de données. Pour que ces étiquettes suivent la langue choisie par l'utilisateur, chaque table de référence a une colonne translations JSONB.
Cet article couvre ce qu'il y a dans cette colonne, quand vous devriez la remplir, et comment le rendu bascule quand une traduction manque.
La forme des traductions
Chaque ligne de table de référence a une colonne JSONB appelée translations avec cette forme :
{
"en": { "name": "Visitor" },
"es": { "name": "Visitante" },
"fr": { "name": "Visiteur" },
"pt": { "name": "Visitante" }
}Les clés de premier niveau sont des codes de locale (en, es, fr, pt). La valeur de chacune est un objet de nom de champ → chaîne traduite. La plupart des lignes de référence n'ont qu'un champ name aujourd'hui, mais la même colonne s'étend proprement à d'autres champs localisables (description, forme plurielle) sans migration.
Les codes de locale correspondent à la constante SUPPORTED_LOCALES dans src/shared/lib/i18n-localize.ts :
| Code | Langue |
|---|---|
en | English |
es | Español |
fr | Français |
pt | Português |
Comment la résolution fonctionne
Quand l'interface a besoin de rendre le nom d'une ligne, elle appelle l'assistant localize() avec les traductions de la ligne, la colonne name héritée comme repli, et la locale active de l'utilisateur :
localize(row.translations, row.name, language, "name")L'assistant parcourt quatre étapes de résolution dans l'ordre :
translations[locale][field]— correspondance exacte sur la locale demandée.translations.en[field]— repli anglais.row[field]— la colonne canonique héritée. (Pour les types de membres, c'estmember_types.name.)- Chaîne vide — l'appelant peut rendre un placeholder.
Donc un utilisateur espagnol regardant un type de membre sans traduction espagnole voit l'étiquette anglaise plutôt qu'une cellule vide. Un utilisateur regardant une réunion en portugais — une locale moins traduite — voit le portugais si disponible, puis l'anglais, puis la colonne name brute. Aucune locale n'affiche silencieusement une cellule vide.
Quand vous devriez remplir les traductions
Le coût UX de laisser les traductions vides est petit (repli sur l'anglais) mais visible pour vos congrégants bilingues. Trois règles d'or :
Traduisez toujours si votre congrégation est bilingue
Si vous prêchez régulièrement dans deux langues ou avez des membres qui ne lisent qu'une, remplissez les deux étiquettes chaque fois que vous ajoutez une ligne de référence. Les 20 secondes que ça prend quand vous ajoutez un type de membre évitent une étiquette anglais-uniquement gênante dans le profil d'un membre espagnol.
Traduisez aussi les listes gérées par la plateforme
Pays, états, villes, genres, états civils — ceux-ci viennent pré-traduits par la plateforme mais la couverture n'est pas à 100 %. Si vous remarquez qu'un pays ou état affiche l'anglais dans votre interface espagnole, vous pouvez le signaler via le support et l'administrateur de plateforme remplira la locale manquante.
Sautez les traductions si vous êtes monolingue
Si toute votre congrégation parle une langue et que vous n'avez aucun plan d'en ajouter une autre, sautez l'entrée des traductions. La chaîne de repli garantit que le nom canonique est rendu correctement. Vous pouvez toujours revenir et les remplir plus tard — ajouter une traduction ne déplace jamais la ligne, ça ne fait qu'ajouter au JSONB.
L'interface de saisie des traductions
Quand vous ajoutez ou éditez une ligne de référence, la boîte de dialogue affiche une entrée Traductions.
Elle ressemble à une entrée de texte à onglets — un onglet par locale supportée, par défaut sur l'anglais. Tapez d'abord l'étiquette anglaise (qui se reflète dans la colonne canonique name), puis basculez sur les onglets espagnol / français / portugais pour remplir le reste.
Les onglets que vous voyez dépendent de SUPPORTED_LOCALES. Ajouter une nouvelle langue de plateforme est un changement d'une ligne dans i18n-localize.ts plus la livraison du fichier de traductions d'interface correspondant — pas de migration de base de données. Les lignes existantes ont juste des entrées vides pour la nouvelle locale jusqu'à ce que vous les remplissiez.
Traduction en masse
Pour les administrateurs d'organisation qui configurent un tout nouveau locataire en langue espagnole, le chemin le plus rapide est :
- Ajoutez chaque type de membre d'abord en anglais.
- Ouvrez la base de données via le module Journaux de données ou votre projet Supabase.
- Utilisez un seul UPDATE :
UPDATE member_types SET translations = jsonb_set(translations, '{es,name}', '"<spanish name>"') WHERE name = '<english name>'. - Rafraîchissez l'interface — chaque membre déjà assigné à ce type affiche maintenant l'étiquette espagnole.
Les administrateurs de plateforme peuvent le faire pour les tables de référence globales (genres, statuts, géographie) sur demande.
Ce qui est traduit où
| Table | Champ | Qui le remplit |
|---|---|---|
member_types | name | Admin org |
meetings | name | Admin org |
genders | name | Admin plateforme |
relationship_statuses | name | Admin plateforme |
countries | name | Admin plateforme |
states | name | Admin plateforme |
cities | name | Admin plateforme |
pages (constructeur de site) | title, body | Admin org (interface séparée) |
notifications | subject, body | Admin org (interface séparée) |
events | title, description | Admin org (éditeur d'événement) |
Le schéma est cohérent à travers la plateforme : partout où les données saisies par l'utilisateur doivent suivre la langue du spectateur, la ligne reçoit une colonne translations JSONB et l'interface la lit à travers le même assistant localize().
Historique de migration
La colonne translations a été ajoutée à l'échelle de la plateforme dans la migration 20260518020000_translations_jsonb_system avec l'assistant localize(). Avant ça, les tables individuelles avaient des colonnes _es (par ex. meetings.name_es) qui étaient incohérentes et ne s'étendaient pas à de nouvelles langues. Ces colonnes _es ont été migrées hors des réunions, mois, événements, pages et notifications — voir les docs de la base de code pour la référence canonique.
Si vous trouvez une ancienne colonne _es dans src/integrations/supabase/types.ts, c'est un reliquat dans le fichier de types auto-généré plutôt que quelque chose dans lequel vous devriez écrire. Écrivez toujours via la colonne translations JSONB.
Et si j'ai besoin d'une cinquième langue ?
Ajoutez le code de locale à SUPPORTED_LOCALES dans src/shared/lib/i18n-localize.ts, livrez un fichier src/i18n/locales/<code>.json correspondant avec les chaînes d'interface, et la base de données est prête sans migration. Les lignes existantes obtiennent une entrée vide pour la nouvelle locale ; les administrateurs les remplissent au fil du temps. Envoyez un e-mail à l'équipe d'ingénierie si votre locataire a besoin d'une langue qui n'est pas dans la liste supportée.
Suivant
- Personnaliser les types de membres — pratiquez le workflow sur une liste que vous possédez pleinement.
- Genres et états civils — où les traductions sont gérées par la plateforme.
- Pays, états, villes — pré-traduits à une couverture variable.