# General Translation Knowledge Base: General Translation ou Symfony Translation : lequel choisir ? URL: https://generaltranslation.com/fr/kb/general-translation-vs-symfony-translation.mdx Docs index: https://generaltranslation.com/llms.txt Description: Symfony Translation affiche les messages en PHP et en Twig. General Translation traduit ses catalogues YAML en CI, les maintient à jour à mesure que votre source évolue et offre aux relecteurs un tableau de bord pour les modifier. Conservez le rendu de Symfony et intégrez la traduction automatisée à votre workflow de livraison. Category: Internationalisation Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 C’est grâce au composant Translation qu’une application Symfony affiche le texte dans la langue du lecteur : `trans()` en PHP et le filtre `|trans` en Twig recherchent une clé dans le catalogue du paramètre régional courant, avec ICU MessageFormat pour gérer les formes plurielles et les sélections. Il organise et affiche les traductions, mais ne les produit pas : le catalogue de chaque langue est rédigé par vous, par vos traducteurs ou par un système de gestion de la traduction (TMS) avec lequel Symfony se synchronise. C’est précisément cette étape manquante que comble General Translation. La CLI de General Translation traduit vos catalogues YAML Symfony, et Symfony continue de se charger de leur affichage. ## Les points forts de Symfony Translation * **Une seule API pour PHP et Twig.** `$translator->trans()`, [le filtre `|trans` et la balise `{% trans %}` dans les modèles](https://symfony.com/doc/current/translation.html#translations-in-templates), ainsi que `t()` avec `TranslatableMessage` pour les messages que vous créez maintenant et traduisez plus tard, comme les messages flash. * **Domaines et nombreux formats de fichiers.** Les catalogues sont nommés selon le schéma `domain.locale.format` (`messages.fr.yaml`, `validators.fr.yaml`), et Symfony charge les formats YAML, XLIFF, PHP, JSON, PO et MO, CSV, INI, Qt ainsi que les bundles de ressources ICU. [Sa documentation recommande YAML pour les projets simples](https://symfony.com/doc/current/translation.html#translation-resource-file-names-and-locations) et XLIFF lorsque les traductions sont produites par des outils ou des équipes spécialisés. * **ICU MessageFormat.** [Ajoutez `+intl-icu` au nom d'un catalogue](https://symfony.com/doc/current/reference/formats/message_format.html) (`messages+intl-icu.en.yaml`) pour que ses messages utilisent la syntaxe ICU pour les formes plurielles, les sélections et le formatage des nombres et des dates. Cela nécessite l'extension PHP `intl` ; le polyfill de Symfony ne prend en charge que l'anglais. * **Extraction et vérifications.** [`translation:extract` repère les messages dans les modèles Twig, le code PHP et les contraintes de validation](https://symfony.com/doc/current/translation.html#extracting-translation-contents-and-updating-catalogs-automatically) et les ajoute à vos catalogues, au format XLIFF 1.2 sauf si vous précisez `--format`. `debug:translation` liste les messages manquants, inutilisés et de secours, et `lint:translations` vérifie le contenu des catalogues. * **Solutions de repli.** Un message `es_AR` manquant [se rabat successivement sur `es_419` et `es`, puis sur vos paramètres régionaux de secours](https://symfony.com/doc/current/translation.html#fallback-translation-locales), et l'absence est journalisée. * **Fournisseurs de traduction.** [`translation:push` et `translation:pull` synchronisent les catalogues avec Crowdin, Loco, Lokalise et Phrase](https://symfony.com/doc/current/translation.html#translation-providers) via des paquets bridge officiels, et vous pouvez écrire votre propre fournisseur. * **Messages du framework inclus.** Le composant Validator fournit ses messages de contraintes intégrés traduits dans plus de 50 langues. Le composant est [sous licence MIT ; la version 8.1 nécessite PHP 8.4.1 ou une version ultérieure](https://packagist.org/packages/symfony/translation), et la 7.4 est la version LTS (support à long terme). ## Ce que Symfony Translation vous laisse gérer Voici un pluriel ICU dans un catalogue anglais : ```yaml title="translations/messages+intl-icu.en.yaml" inbox: title: Inbox unread: >- {count, plural, =0 {You have no unread messages.} one {You have # unread message.} other {You have # unread messages.} } ``` Quelqu'un a également rédigé `messages+intl-icu.es.yaml` à la main, avec les mêmes clés et le pluriel réécrit en espagnol. Voici ce qu'on obtient en affichant les deux, ainsi que l'allemand, avec le composant autonome (`symfony/translation` 8.1.5) : ```php title="render.php" setFallbackLocales(['en']); $translator->addLoader('yaml', new YamlFileLoader()); // Le suffixe +intl-icu active ICU MessageFormat pour le domaine messages. foreach (['en', 'es'] as $locale) { $file = __DIR__."/translations/messages+intl-icu.$locale.yaml"; $translator->addResource('yaml', $file, $locale, 'messages+intl-icu'); } foreach (['en', 'es', 'de'] as $locale) { echo $locale, ': ', $translator->trans('inbox.unread', ['count' => 3], 'messages', $locale), "\n"; } ``` ```text title="Output" en: You have 3 unread messages. es: Tienes 3 mensajes sin leer. de: You have 3 unread messages. ``` L'espagnol fonctionne parce que quelqu'un l'a traduit. L'allemand n'a pas de catalogue, donc Symfony se rabat discrètement sur l'anglais : dans une application complète, la traduction manquante est journalisée et `debug:translation de` la signale, mais rien ne produit l'allemand. Chaque nouvelle clé relance le cycle, dans chaque langue. `translation:extract --force` ajoute la clé à chaque catalogue, préfixée par `__` (ou vide avec `--no-fill`), puis quelqu'un la traduit, soit à la main, soit dans un TMS avec lequel les commandes de fournisseur synchronisent les fichiers (envoi et récupération). Un fournisseur ne fait que déplacer des fichiers ; la traduction elle-même, tout comme l'abonnement TMS sur lequel elle repose, reste une affaire à part. ## Comment General Translation s'intègre à une application Symfony Laissez Symfony se charger de l'affichage et confiez au CLI de General Translation le remplissage des catalogues. Faites pointer une entrée `yaml` vers votre répertoire de traductions, en plaçant `[locale]` à l'endroit où figure le paramètre régional dans chaque nom de fichier : ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["es", "fr", "de"], "files": { "yaml": { "include": ["translations/*.[locale].yaml"] } } } ``` [`npx gt translate`](/docs/cli/reference/commands/translate) détecte chaque catalogue anglais correspondant, comme `messages+intl-icu.en.yaml` et `validators.en.yaml`, puis génère `messages+intl-icu.es.yaml`, `validators.es.yaml`, et ainsi de suite pour chaque paramètre régional cible, en conservant intacts vos clés et noms de domaine. Exécutez-le en CI après que `translation:extract` a ajouté de nouvelles clés aux catalogues anglais. Les entrées inchangées réutilisent leurs traductions existantes : chaque exécution ne traduit donc que le texte nouveau ou modifié. Quelques points méritent une attention particulière avec Symfony : * **Messages ICU.** Conservez `+intl-icu` dans les noms des catalogues pour que Symfony formate les messages traduits avec ICU. Exécutez `lint:translations` après la génération et prévisualisez le message de la boîte de réception avec des valeurs de 0, 1 et 3. * **Codes de paramètres régionaux.** Conservez les noms de paramètres régionaux existants de votre application. Pour `pt_BR`, ajoutez-le à `locales` et définissez `"customMapping": { "pt_BR": { "code": "pt-BR" } }` dans `gt.config.json`. La CLI utilise alors le portugais du Brésil et écrit le fichier `messages.pt_BR.yaml` attendu par Symfony. (Voir [`customMapping`](/docs/cli/reference/config#custom-mapping).) * **Node.js en CI.** La CLI étant un paquet npm, votre tâche CI a besoin de Node.js, ainsi que de `GT_API_KEY` et `GT_PROJECT_ID` dans ses secrets. (Voir [Configurer la CLI](/docs/cli/guides/configuring#credentials).) Au-delà du remplissage des catalogues, General Translation en garantit la cohérence : le glossaire et les instructions personnalisées d’un groupe de contexte appliquent la même terminologie et le même ton à chaque projet auquel il est assigné, et votre équipe [relit et modifie les traductions dans le tableau de bord](/docs/platform/dashboard/guides/reviewing-translations). Utilisez le même groupe de contexte pour votre application Symfony, votre documentation et votre site marketing afin qu’un terme produit reste identique sur les trois. (Voir [Définir le contexte des traductions](/docs/platform/dashboard/guides/defining-context-for-translations).) ## Symfony Translation et General Translation en un coup d'œil | Fonctionnalité | Symfony Translation | General Translation | | ------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | Rôle | Recherche et affiche les messages en PHP et Twig | Produit les catalogues utilisés par vos appels PHP et Twig | | Traduit votre contenu | Non ; les fournisseurs synchronisent les catalogues avec Crowdin, Loco, Lokalise ou Phrase | Oui, avec [`npx gt translate`](/docs/cli/reference/commands/translate) | | Formats de catalogue | YAML, XLIFF, PHP, JSON, PO et MO, CSV, INI, Qt, bundles de ressources ICU | YAML et JSON pour ce workflow de catalogues | | Détection des nouvelles chaînes | `translation:extract` analyse Twig, PHP et les contraintes | Traduit tout le contenu des catalogues anglais | | ICU MessageFormat | Catalogues `+intl-icu` avec l'extension `intl` | Traduit les valeurs des catalogues pour le moteur de rendu ICU de Symfony | | Traductions manquantes | Chaîne de repli, journaux, `debug:translation` | Génère tous les paramètres régionaux configurés à chaque exécution | | Coût | Gratuit et sous licence MIT ; les fournisseurs facturent séparément | [Facturation à l'usage](https://generaltranslation.com/pricing) | ## Quand utiliser l'un ou l'autre Pour l'affichage, la question ne se pose pas : une application Symfony doit conserver Symfony Translation. La vraie décision porte sur la façon dont ses catalogues sont alimentés. Conservez un fournisseur de traduction si vos traducteurs travaillent en XLIFF dans un TMS, si vous achetez des prestations de traduction humaine professionnelle ou si votre processus actuel fonctionne déjà. (Voir [Pourquoi utiliser General Translation plutôt qu'un TMS ?](/kb/general-translation-vs-tms)) Choisissez General Translation si vous voulez que le catalogue YAML de chaque paramètre régional soit traduit dans la CI à chaque modification, avec une terminologie partagée et une relecture dans le tableau de bord, sans fichiers à envoyer ni attente. ## Utiliser les deux 1. Partez de vos catalogues YAML Symfony et ajoutez `gt.config.json` comme indiqué ci-dessus. 2. Si vous disposez déjà de traductions, téléversez-les avec [`npx gt upload`](/docs/cli/reference/commands/upload) avant d'en générer de nouvelles. 3. Exécutez [`npx gt translate`](/docs/cli/reference/commands/translate) dans votre CI une fois que Symfony a extrait les nouveaux messages dans vos catalogues anglais. 4. Relisez les traductions dans le tableau de bord. Si vous modifiez localement les fichiers YAML téléchargés, synchronisez-les avec [`npx gt save-local`](/docs/cli/reference/commands/save-local) avant la prochaine exécution de génération. ## Points clés à retenir * Symfony Translation effectue le rendu des messages, extrait les clés et se synchronise avec les fournisseurs de TMS ; la production des traductions reste une étape à part. * General Translation traduit les catalogues YAML de Symfony dans la CI, en conservant vos clés et vos domaines, afin que PHP et Twig continuent d'utiliser les mêmes messages. * Conservez un fournisseur de TMS pour le XLIFF et les traducteurs professionnels ; optez pour General Translation si vous souhaitez que vos catalogues soient traduits à chaque modification. ## Related questions - [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. - [General Translation ou GNU gettext : avez-vous besoin des deux ?](https://generaltranslation.com/fr/kb/general-translation-vs-gettext.mdx): Conservez GNU gettext pour l’extraction et l’affichage, et ajoutez General Translation pour générer et maintenir les fichiers PO. General Translation tient compte des notes aux traducteurs et du contexte des messages lors de la génération, applique une terminologie partagée et met à la disposition des relecteurs un éditeur dans le tableau de bord. Vos appels gettext existants et vos catalogues compilés restent en place. - [General Translation ou Rails I18n : avez-vous besoin des deux ?](https://generaltranslation.com/fr/kb/general-translation-vs-rails-i18n.mdx): Rails I18n recherche les messages et formate les dates et les nombres. General Translation produit les traductions, les tient à jour au fil de l’évolution de votre texte anglais et offre à votre équipe un tableau de bord pour la relecture. Utilisez les deux pour livrer des catalogues Rails traduits à chaque version. - [General Translation ou le framework de traduction de Django : avez-vous besoin des deux ?](https://generaltranslation.com/fr/kb/general-translation-vs-django-i18n.mdx): Utilisez conjointement le framework de traduction de Django et General Translation. Django gère l’extraction des messages, la sélection de la langue et l’affichage. General Translation remplit ses fichiers PO, formes du pluriel comprises, avec la terminologie de votre produit et une relecture dans le tableau de bord. Vos modèles et vos motifs d’URL restent inchangés, tandis que les traductions évoluent au rythme de votre code. ## Previous and next questions - Previous question: [General Translation ou Rails I18n : avez-vous besoin des deux ?](https://generaltranslation.com/fr/kb/general-translation-vs-rails-i18n.mdx) - Next question: [General Translation ou Tolgee : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-tolgee.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.