<%= t(".unread", count: @count) %>
``` Sélectionner l'espagnol ne traduit pas ce fichier. Si les solutions de repli vers l'anglais sont activées, les lecteurs hispanophones voient toujours « Inbox » et « You have 3 unread messages. » Rails a besoin d'un catalogue espagnol pour pouvoir afficher du contenu en espagnol. Chaque message anglais ajouté ou modifié entraîne le même travail dans chaque langue. La gem [rails-i18n](https://github.com/svenfuchs/rails-i18n) fournit les formats propres à chaque paramètre régional ainsi que les règles de pluriel. [i18n-tasks](/kb/general-translation-vs-i18n-tasks) détecte les clés et les formes du pluriel manquantes. General Translation fournit les messages traduits dont ces outils ont besoin. ## Traduire les fichiers de paramètres régionaux Rails avec General Translation Conservez Rails I18n pour les recherches et confiez à General Translation la génération des autres fichiers de paramètres régionaux. La CLI `gt` s'exécute sur Node.js, traduit les fichiers YAML et conserve vos clés. Pour cet exemple de traduction de l'anglais vers l'espagnol, placez les messages dans `translations/en.yml`, sans la clé racine `en:` : ```yaml title="translations/en.yml" inbox: show: title: "Inbox" unread: one: "You have %{count} unread message." other: "You have %{count} unread messages." ``` Faites pointer `gt.config.json` vers ces fichiers de travail. Une courte étape d'export ajoute les clés de paramètre régional de Rails et génère les catalogues chargés par l'application : ```json title="gt.config.json" { "defaultLocale": "en", "locales": [ "es" ], "files": { "yaml": { "include": [ "translations/[locale].yml" ] } } } ``` Définissez `GT_PROJECT_ID` et `GT_API_KEY` comme indiqué dans [Générer des traductions](/docs/cli/guides/generating-translations). Si vous disposez déjà de traductions pour ce catalogue, placez-les dans `translations/es.yml` sans la clé racine `es:`, puis exécutez [`npx gt upload`](/docs/cli/reference/commands/upload) avant de générer de nouvelles traductions. ```ruby title="script/export_rails_locales.rb" require "json" require "yaml" require "fileutils" config = JSON.parse(File.read("gt.config.json")) locales = ([config.fetch("defaultLocale")] + config.fetch("locales")).uniq catalogs = locales.to_h do |locale| messages = YAML.safe_load_file("translations/#{locale}.yml", aliases: true) raise "Expected a message map for #{locale}" unless messages.is_a?(Hash) [locale, { locale => messages }.to_yaml] end FileUtils.mkdir_p("config/locales") catalogs.each do |locale, catalog| File.write("config/locales/#{locale}.yml", catalog) end ``` ```bash npx gt translate && ruby script/export_rails_locales.rb ``` L'export génère les fichiers `config/locales/en.yml` et `config/locales/es.yml` de ce catalogue. Continuez à modifier les fichiers de travail dans `translations/` ; l'application charge les copies exportées. Synchronisez les modifications apportées aux traductions locales avec [`npx gt save-local`](/docs/cli/reference/commands/save-local) avant la prochaine exécution de traduction. General Translation traduit chaque fichier en appliquant le [glossaire et les instructions personnalisées](/docs/platform/dashboard/guides/defining-context-for-translations) de votre projet : un nom de produit ou un ton formel reste ainsi cohérent dans tous les fichiers de paramètres régionaux, et votre équipe peut [relire et modifier les traductions](/docs/platform/dashboard/guides/reviewing-translations) dans le tableau de bord. Les entrées inchangées réutilisent les traductions existantes : exécuter la CLI en CI à chaque fusion ne traduit donc que ce qui a changé. Avant la livraison, exécutez `i18n-tasks missing` et `i18n-tasks check-consistent-interpolations` pour vérifier les clés, les formes du pluriel et les espaces réservés `%{count}` des catalogues exportés. ## Rails I18n et General Translation en un coup d’œil | Fonctionnalité | Rails I18n | General Translation | | -------------------------------------------------- | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Description | Bibliothèque Ruby pour rechercher et formater des traductions | Plateforme de traduction avec une CLI, des bibliothèques pour JavaScript et Python, et un tableau de bord | | Affiche les traductions dans une application Rails | Oui, dans les vues, les contrôleurs et les mailers | Fournit les catalogues utilisés par ces mêmes appels Rails I18n | | Produit les traductions | Non | Oui, sous forme de fichiers YAML avec [`npx gt translate`](/docs/cli/reference/commands/translate) | | Règles de pluriel | Règles anglaises par défaut ; règles CLDR avec rails-i18n | Traduit les formes source configurées ; Rails les sélectionne à l’exécution | | Cohérence entre les fichiers | Dépend de vos traducteurs | Glossaire et instructions personnalisées appliqués à chaque fichier | | Relecture | Votre processus de pull request | Tableau de bord, en complément de votre processus de pull request | | Coût | Gratuit, licence MIT | [Facturation à l’usage](https://generaltranslation.com/pricing) | Utilisez Rails I18n seul si des traducteurs ou un prestataire vous livrent déjà vos fichiers de paramètres régionaux, ou si vous ne prenez en charge qu’une ou deux langues que vous modifiez à la main. Ajoutez General Translation si votre texte anglais évolue souvent et que vous souhaitez régénérer chaque fichier de paramètres régionaux dans votre CI, avec une terminologie cohérente, plutôt que d’attendre un aller-retour avec vos traducteurs. ## Points clés * Rails I18n affiche les traductions à partir de `config/locales` et formate les dates et les nombres ; rails-i18n ajoute les règles de pluriel et les données de paramètres régionaux. Ni l'un ni l'autre ne produit de traductions. * General Translation traduit vos fichiers YAML en s'appuyant sur votre glossaire et vos instructions personnalisées, et tient les traductions à jour au fil des modifications du texte anglais. * Conservez les catalogues modifiables dans `translations/`, puis exportez-les vers les racines de paramètres régionaux de Rails après avoir exécuté [`npx gt translate`](/docs/cli/reference/commands/translate). ## Related questions - [General Translation ou i18n-tasks : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-i18n-tasks.mdx): i18n-tasks est une gem Ruby qui détecte les clés Rails I18n manquantes ou inutilisées, fait le ménage dans les fichiers de paramètres régionaux et peut compléter les clés manquantes via Google Translate, DeepL, OpenAI, Yandex ou watsonx. General Translation traduit des fichiers de paramètres régionaux entiers en s’appuyant sur votre glossaire, vos instructions personnalisées et la relecture dans le tableau de bord. Les deux outils remplissent des rôles différents, et de nombreuses équipes peuvent les utiliser ensemble. - [General Translation ou Mobility : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-mobility.mdx): Mobility stocke les attributs traduits de vos modèles dans votre base de données. General Translation produit ces traductions via son API, en s’appuyant sur votre glossaire et vos instructions personnalisées. Utilisez les deux pour traduire vos fiches produits, articles et autres contenus de base de données sans renoncer à vos modèles Rails. - [General Translation vs i18next, react-intl et next-intl : quelle bibliothèque d’i18n choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-i18n-libraries.mdx): Les bibliothèques open source comme i18next, react-intl et next-intl ne traduisent rien. Elles affichent les traductions que vous leur fournissez dans un fichier de catalogue par langue, rédigées par vous, vos traducteurs ou un service tiers. Les bibliothèques de General Translation sont elles aussi open source et remplissent le même rôle, mais General Translation se charge en plus de la traduction, en s’appuyant sur votre code comme contexte. - [Pourquoi utiliser General Translation plutôt qu’un TMS (Smartling, Lokalise, Phrase, Crowdin ou Transifex) ?](https://generaltranslation.com/fr/kb/general-translation-vs-tms.mdx): Un système de gestion de la traduction (TMS) comme Smartling, Lokalise, Phrase, Crowdin ou Transifex coordonne les traducteurs, mais les ingénieurs doivent toujours extraire les chaînes, les envoyer, attendre les traductions, puis les réintégrer dans le produit. General Translation traduit le contenu directement dans votre code, avec son contexte, fournit toutes les langues à chaque livraison et repose sur des bibliothèques open source, sans dépendance à un fournisseur. - [Quel est le meilleur logiciel de localisation pour les développeurs ?](https://generaltranslation.com/fr/kb/best-localization-software.mdx): Privilégiez un système unique qui couvre l’ensemble du pipeline, de la bibliothèque i18n dans votre code jusqu’à la traduction et la livraison, plutôt que d’assembler tant bien que mal une bibliothèque, un système de gestion de la traduction et un prestataire de traduction distincts. ## Previous and next questions - Previous question: [General Translation ou Paraglide JS : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-paraglide.mdx) - Next question: [General Translation ou Symfony Translation : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-symfony-translation.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.