# General Translation Knowledge Base: Comment migrer de Phrase vers General Translation ? URL: https://generaltranslation.com/fr/kb/migrate-from-phrase.mdx Docs index: https://generaltranslation.com/llms.txt Description: Conservez vos fichiers de paramètres régionaux, votre bibliothèque d’i18n et vos traductions vérifiées. Récupérez vos fichiers depuis Phrase Strings sans clés non traduites ni solutions de repli, désactivez Repo Sync, puis importez les fichiers avec npx gt upload avant le premier npx gt translate. General Translation traduit ensuite les chaînes nouvelles et modifiées lors de votre compilation, en s’appuyant sur votre base terminologique, placée dans un groupe de contexte, et sur les descriptions de clés, utilisées comme contexte propre à chaque clé. Category: Outils de workflow Last updated: 2026-11-12 Authors: Kevin Wu Published: 2026-11-12 Phrase Strings, le produit de localisation logicielle de Phrase, stocke vos chaînes sous forme de clés dans un projet, génère les fichiers de paramètres régionaux au moment du téléchargement et les synchronise avec votre dépôt. En passant à General Translation, vous conservez les fichiers de paramètres régionaux que votre application lit déjà : la CLI `gt` les importe avec vos traductions existantes, puis traduit les chaînes nouvelles et modifiées lors de votre compilation ou dans votre CI. Votre bibliothèque d’i18n et vos clés restent inchangées ; intégrer le texte directement dans le code est une étape distincte et facultative (voir [migrer depuis react-i18next](/kb/migrate-from-react-i18next) ou [depuis next-intl](/kb/migrate-from-next-intl)). Votre base terminologique devient un groupe de contexte que votre application, votre documentation et vos autres projets peuvent partager. Ce guide porte sur Phrase Strings ; les documents traduits dans Phrase TMS suivent un workflow différent. ## Qu’est-ce qui est repris de Phrase Strings ? | Dans Phrase Strings | Dans General Translation | | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cibles de récupération (pull) `.phrase.yml` | `files` dans `gt.config.json`, avec `[locale]` à la place de `` | | Traductions | Importées avec [`npx gt upload`](/docs/cli/reference/commands/upload) et conservées jusqu’à ce que leur source change | | Base terminologique | Un glossaire de [groupe de contexte](/docs/platform/dashboard/guides/defining-context-for-translations), importé depuis un fichier CSV | | Guides de style | [Instructions personnalisées](/docs/platform/dashboard/guides/defining-context-for-translations), globales ou par paramètre régional | | Descriptions de clés et limites de caractères | Un fichier de [métadonnées associées aux clés](/docs/cli/reference/keyed-metadata) avec `context` et `maxChars` pour chaque clé, au format JSON ou YAML | | Mémoire de traduction | Vos traductions téléversées : les chaînes inchangées les conservent, et seules les chaînes nouvelles ou modifiées sont traduites. Les fichiers TMX ne sont pas importés | | Repo Sync | [`npx gt translate`](/docs/cli/reference/commands/translate) dans la CI, ou des pull requests [Locadex](/docs/platform/locadex/quickstart) | | Vérification et relecture des traductions | Modification dans le [tableau de bord](/docs/platform/dashboard/guides/reviewing-translations), avec approbation incluse dans l’offre Enterprise | | SDK de mise à jour à distance (OTA) pour iOS, Android, React Native, Flutter, i18next et Rails | Les traductions sont intégrées à vos fichiers de paramètres régionaux et livrées avec chaque livraison de l’application | La CLI lit les formats JSON, YAML, `.pot` et `.po`, les fichiers iOS `.strings`, `.stringsdict` et `.xcstrings`, Android `strings.xml`, `.resx`, HTML, Markdown et MDX, entre autres. (Consultez les [formats pris en charge](/docs/cli/reference/config#files).) Elle ne lit pas les formats XLIFF, ARB, Java `.properties`, ni les exports CSV et XLSX : choisissez donc un format pris en charge lors de la récupération. ## Étape 1 : récupérer un fichier par paramètre régional Phrase génère les fichiers à partir des clés à chaque téléchargement. Si votre dépôt contient déjà des fichiers synchronisés par Phrase, effectuez le pull avec les mêmes cibles `.phrase.yml` afin d'obtenir un résultat identique, puis faites un diff avec le dépôt avant l'importation. Voici à quoi ressemble une cible de pull pour une application JSON : ```yaml title=".phrase.yml" phrase: project_id: "YOUR_PROJECT_ID" file_format: nested_json pull: targets: - file: ./locales//app.json params: file_format: nested_json include_empty_translations: false ``` Exécutez ensuite [`phrase pull`](https://developers.phrase.com/en/developer-tools/strings-cli) avec un jeton d'accès disposant de la portée `read`. Omettez `--branch` pour récupérer les fichiers depuis la branche principale. Si votre compte est hébergé dans le centre de données américain de Phrase, ajoutez `host: https://api.us.app.phrase.com/v2` sous `phrase:` dans `.phrase.yml`. Trois paramètres sont essentiels pour une importation propre : * **Clés non traduites.** `include_empty_translations: false`, la valeur par défaut de la CLI, exclut les clés non traduites. Ne définissez ni `fallback_locale_id` ni `use_locale_fallback`, et vérifiez que le paramètre de projet **Use fallback for unverified translations** est désactivé. Chacune de ces options comble les manques avec le texte d'un autre paramètre régional, qui serait alors importé comme une traduction. * **Format de fichier.** Utilisez le format que votre bibliothèque lit déjà : `nested_json` ou `simple_json`, `i18next_4` pour i18next, `yml` pour Rails, `strings` et `stringsdict` pour iOS, `strings_catalog` pour `.xcstrings`, et `xml` pour Android. Le format `json` de Phrase correspond au JSON des extensions Chrome, et non à du JSON générique. (Consultez la liste des [formats de fichiers pris en charge](https://support.phrase.com/hc/en-us/articles/9652464547740) par Phrase.) * **Noms des paramètres régionaux.** `` est remplacé par le nom que vous avez donné à chaque paramètre régional dans Phrase, par exemple `de-AT`. La CLI `gt` compare les noms de dossiers à votre liste `locales` de manière stricte : vous devez donc renommer les paramètres régionaux dans Phrase, les faire correspondre avec `locale_mapping` sous `phrase:` dans `.phrase.yml` (Phrase CLI 2.59.0 ou version ultérieure), ou bien indiquer dans `gt.config.json` les noms tels qu'ils sont récupérés. Sans la CLI, ouvrez l'onglet **Languages** du projet et cliquez sur **Download** pour télécharger plusieurs paramètres régionaux à la fois, en laissant la case **Include empty translations** décochée. ## Étape 2 : désactiver Repo Sync et OTA La fonctionnalité [Repo Sync](https://support.phrase.com/hc/en-us/articles/5784125562012-GitHub-Strings) de Phrase, configurée sous **Automations > Repo Syncs**, peut importer le contenu à chaque push et exporte les traductions sous forme de pull requests, par défaut depuis une branche `phrase-translations`. Avant que General Translation n'écrive le moindre fichier, désactivez chaque synchronisation pour qu'elle cesse d'importer et d'exporter, fermez toutes les pull requests Phrase encore ouvertes et supprimez les étapes `phrase push` et `phrase pull` de votre CI. Si deux outils écrivent dans les mêmes fichiers, c'est le dernier à écrire qui l'emporte. Si vos applications mobiles utilisent Phrase OTA, les applications installées continuent de recevoir les nouvelles livraisons OTA. Cessez d'en créer, ou supprimez la distribution, pour qu'elles ne reçoivent plus de mises à jour, puis retirez le SDK lors d'une prochaine livraison de l'application. ## Étape 3 : indiquer les fichiers à la CLI Installez la CLI `gt` et déclarez les fichiers récupérés dans `gt.config.json` : ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de", "fr", "pt-BR"], "files": { "json": { "include": ["locales/[locale]/app.json"] } } } ``` La CLI lit la syntaxe de messages i18next et next-intl dans les fichiers JSON lorsqu'elle détecte `i18next` ou `next-intl` dans votre `package.json`, et traite les autres valeurs JSON comme de simples chaînes de caractères. (Voir [Fichiers JSON](/docs/cli/reference/formats/json-files).) Connectez-vous avec [`npx gt login`](/docs/cli/reference/commands/login) et définissez `GT_PROJECT_ID`, ou renseignez `projectId` dans la configuration. En CI, utilisez `GT_API_KEY` avec une clé API de projet disposant des autorisations **Files > Write**, **Translation queue > Enabled** et **Context > Write**. ## Étape 4 : Importer votre base terminologique et le contexte de vos clés Dans Phrase Strings, ouvrez **Term bases**, puis **More > Download CSV**, choisissez les champs et cliquez sur **Download**. Le fichier contient les colonnes `term`, `case_sensitive`, `translatable` et `description`, ainsi qu’une colonne par paramètre régional. (Consultez [Uploading and downloading terms](https://support.phrase.com/hc/en-us/articles/10112307427740).) Renommez `description` en `definition` et chaque colonne de paramètre régional, comme `de`, en `translation_de`, puis supprimez les colonnes `case_sensitive` et `translatable`. L’outil d’importation de General Translation lit directement cette structure et interprète les autres structures à l’aide de l’IA. Dans le tableau de bord, créez un [groupe de contexte](/docs/platform/dashboard/guides/defining-context-for-translations), cliquez sur **Import**, choisissez le fichier et associez le groupe à votre projet avant la première exécution de traduction, afin que les nouvelles traductions respectent votre terminologie dès le départ. Les descriptions de clés et les limites de caractères indiquent au traducteur le sens d’une chaîne de caractères et sa longueur maximale. Ajoutez une seconde cible de récupération (pull) pour votre paramètre régional source avec `file_format: strings_json`, enregistrée en dehors des dossiers définis dans `gt.config.json` (par exemple `./phrase-export/app.strings.json`). Ce fichier contient les champs `description` et `max_characters_allowed` de chaque clé ; écrivez-les dans un fichier de [métadonnées associées aux clés](/docs/cli/reference/keyed-metadata) à côté du fichier source : ```json title="locales/en/app.metadata.json" { "checkout": { "save": { "context": "Button that saves the shipping address", "maxChars": 12 } } } ``` Recréez vos guides de style sous forme d'[instructions personnalisées](/docs/platform/dashboard/guides/defining-context-for-translations). Pour archiver votre mémoire de traduction, exportez chaque langue du projet au format TMX. ## Étape 5 : téléverser avant de traduire Exécutez d'abord [`npx gt upload`](/docs/cli/reference/commands/upload). Cette commande envoie chaque fichier source ainsi que le fichier traduit correspondant pour chaque paramètre régional, puis enregistre ces traductions comme terminées : ```bash npx gt upload npx gt translate ``` [`npx gt translate`](/docs/cli/reference/commands/translate) ne traduit ensuite que ce qui manque, comme un nouveau paramètre régional ou un fichier sans traduction, et écrit les résultats aux mêmes chemins. Si vous exécutez [`npx gt translate`](/docs/cli/reference/commands/translate) avant [`npx gt upload`](/docs/cli/reference/commands/upload), de nouvelles traductions sont générées et écrasent les fichiers récupérés. Les clés que Phrase n'avait pas traduites seront traduites par General Translation à la prochaine modification de leur fichier source. Pour les livrer plus tôt, terminez-les dans Phrase avant de les récupérer. ## Étape 6 : traduire automatiquement les nouveaux textes Désormais, exécutez [`npx gt translate`](/docs/cli/reference/commands/translate) lors de votre [compilation ou dans votre CI](/kb/translations-in-ci), ou laissez [Locadex](/docs/platform/locadex/quickstart) ouvrir des pull requests contenant les traductions. Commitez `gt-lock.json` : ce fichier recense les traductions déjà écrites par la CLI, afin qu’elle ne les télécharge pas une seconde fois. Si votre équipe modifie des fichiers traduits directement dans le dépôt, exécutez [`npx gt save-local`](/docs/cli/reference/commands/save-local) avant la prochaine traduction pour conserver ces modifications. ## Quand faut-il rester sur Phrase ? Restez sur Phrase si une même plateforme doit gérer à la fois les chaînes de votre logiciel et un programme de traduction de documents dans Phrase TMS, si vos applications mobiles natives reposent sur les mises à jour OTA, si vous commandez de la traduction humaine via Phrase, ou si votre pipeline échange des fichiers XLIFF ou ARB. (Voir [General Translation vs. Phrase](/kb/general-translation-vs-phrase).) ## Questions fréquentes ### Vais-je perdre mes traductions vérifiées ? Non, à condition de récupérer les traductions sans solutions de repli et d'exécuter [`npx gt upload`](/docs/cli/reference/commands/upload) avant [`npx gt translate`](/docs/cli/reference/commands/translate). Les traductions téléversées sont conservées tant que leur texte source ne change pas, et votre équipe peut corriger n'importe quelle traduction depuis le [tableau de bord](/docs/platform/dashboard/guides/reviewing-translations). ## Points clés * Exportez un fichier par paramètre régional avec `include_empty_translations: false` et sans paramètre régional de secours, dans le format que votre application lit déjà. * Désactivez Repo Sync et OTA avant que General Translation n’écrive dans ces mêmes fichiers. * Faites correspondre les noms de paramètres régionaux de Phrase aux `locales` de `gt.config.json`, importez la base terminologique dans un groupe de contexte, puis reprenez les descriptions de clés et les limites de caractères sous forme de contexte par clé avant de lancer la traduction. * Exécutez [`npx gt upload`](/docs/cli/reference/commands/upload) avant le premier [`npx gt translate`](/docs/cli/reference/commands/translate), puis traduisez les nouveaux contenus pendant la compilation ou avec Locadex. ## Related questions - [Alternatives à Phrase : General Translation ou Phrase](https://generaltranslation.com/fr/kb/general-translation-vs-phrase.mdx): General Translation est une solide alternative à Phrase Strings lorsque votre application et votre documentation sont livrées ensemble. Il génère des traductions à partir du code et des fichiers de contenu, applique une terminologie partagée et s’intègre à votre workflow de livraison. Phrase associe la localisation logicielle à un TMS orienté documents, à la gestion des prestataires et à un large choix de moteurs de traduction. - [Comment migrer de Lokalise vers General Translation ?](https://generaltranslation.com/fr/kb/migrate-from-lokalise.mdx): Conservez vos fichiers de ressources, votre bibliothèque d’i18n et vos traductions relues. Exportez depuis Lokalise sans les traductions vides, désactivez sa synchronisation GitHub, puis importez les fichiers avec npx gt upload avant le premier npx gt translate. General Translation traduit ensuite les chaînes nouvelles et modifiées lors de votre compilation, en s’appuyant sur votre glossaire placé dans un groupe de contexte et sur les descriptions de clés, utilisées comme contexte propre à chaque clé. - [Comment migrer de Crowdin vers General Translation ?](https://generaltranslation.com/fr/kb/migrate-from-crowdin.mdx): Conservez vos fichiers de ressources, votre bibliothèque d’i18n et vos traductions relues. Activez l’option Skip untranslated strings, téléchargez vos traductions, empêchez l’intégration Git de Crowdin de pousser des traductions, puis importez les fichiers avec npx gt upload avant le premier npx gt translate. General Translation traduit ensuite les chaînes nouvelles et modifiées lors de votre compilation, à l’aide de votre glossaire stocké dans un groupe de contexte. - [Comment maintenir les traductions à jour à chaque déploiement ?](https://generaltranslation.com/fr/kb/translations-in-ci.mdx): Exécutez la traduction comme une étape du pipeline avant chaque compilation de production, afin que les nouveaux textes soient livrés traduits avec le déploiement qui les ajoute. Le CLI gt de General Translation s’en charge avec npx gt translate, à l’aide d’une clé API de projet et d’un identifiant de projet stockés comme secrets CI. - [Qu’est-ce qu’une mémoire de traduction, et en avez-vous encore besoin avec l’IA ?](https://generaltranslation.com/fr/kb/what-is-translation-memory.mdx): Une mémoire de traduction (TM) est une base de données de paires de segments source et cible déjà traduits, dans laquelle un outil de traduction recherche des correspondances exactes, en contexte et approximatives. Avec l’IA, vous voulez toujours réutiliser les formulations approuvées et disposer des traductions passées comme contexte. General Translation réutilise les traductions correspondantes issues des versions antérieures des fichiers et conserve les modifications de l’équipe, sans mémoire de traduction distincte à maintenir. ## Previous and next questions - Previous question: [Comment migrer de Lokalise vers General Translation ?](https://generaltranslation.com/fr/kb/migrate-from-lokalise.mdx) - Next question: [Quel est le meilleur outil de localisation continue pour les équipes qui livrent chaque jour ?](https://generaltranslation.com/fr/kb/best-continuous-localization-tools.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.