# General Translation Knowledge Base: Comment migrer de Lokalise vers General Translation ? URL: https://generaltranslation.com/fr/kb/migrate-from-lokalise.mdx Docs index: https://generaltranslation.com/llms.txt Description: 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é. Category: Outils de workflow Last updated: 2026-11-12 Authors: Kevin Wu Published: 2026-11-12 Lokalise stocke vos chaînes sous forme de clés dans un projet, génère à l’export des fichiers de ressources pour chaque plateforme et les synchronise avec votre dépôt. En passant à General Translation, vous conservez les fichiers de ressources 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 glossaire devient un groupe de contexte que votre application, votre documentation et vos autres projets peuvent partager. ## Qu’est-ce qui est repris de Lokalise ? | Dans Lokalise | Dans General Translation | | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Clés exportées sous forme de fichiers pour chaque plateforme | Les mêmes fichiers, répertoriés sous `files` dans `gt.config.json` | | Traductions | Importées avec [`npx gt upload`](/docs/cli/reference/commands/upload) et conservées jusqu’à ce que leur source change | | Glossaire | Un glossaire de [groupe de contexte](/docs/platform/dashboard/guides/defining-context-for-translations), importé depuis un fichier CSV | | Guides de style pour Pro AI | [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 | Commentaires dans les fichiers iOS et Android, que General Translation utilise comme contexte, ou fichier de [métadonnées associées aux clés](/docs/cli/reference/keyed-metadata) pour JSON et 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 | | GitHub App, auto-pull et GitHub Actions | [`npx gt translate`](/docs/cli/reference/commands/translate) dans la CI, ou pull requests [Locadex](/docs/platform/locadex/quickstart) | | Tâches de relecture | Modification dans le [tableau de bord](/docs/platform/dashboard/guides/reviewing-translations), avec approbation dans l’offre Enterprise | | SDK over-the-air pour iOS, Android et Flutter | Les traductions sont intégrées à vos fichiers de ressources à chaque livraison de l’application | La CLI lit les formats JSON, YAML, `.pot` et `.po`, 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 prend pas en charge XLIFF, ARB, les fichiers Java `.properties`, ni les exports CSV et XLSX : choisissez donc un format compatible lors du téléchargement. ## Étape 1 : Exporter un fichier par langue Lokalise ne conserve pas vos fichiers d'origine ; il les reconstruit à partir des clés à chaque export. Si votre dépôt contient déjà des fichiers synchronisés par Lokalise, exportez avec les mêmes paramètres pour obtenir un résultat identique, puis faites un diff avec le dépôt avant l'importation. Avec la [CLI `lokalise2`](https://github.com/lokalise/lokalise-cli-2-go/blob/master/docs/lokalise2_file_download.md), l'export JSON d'une application web se présente ainsi : ```bash lokalise2 --token "$LOKALISE_TOKEN" --project-id "$LOKALISE_PROJECT_ID" file download \ --format json \ --original-filenames=false \ --bundle-structure "locales/%LANG_ISO%/common.json" \ --unzip-to . \ --export-empty-as skip \ --filter-data nonhidden \ --async ``` Quatre paramètres sont déterminants pour une importation propre : * **`--export-empty-as skip`.** Par défaut, Lokalise exporte les clés non traduites sous forme de chaînes vides, et `base` les remplit avec le texte source. Dans les deux cas, elles seraient importées comme des traductions. `skip` les exclut. * **Formats des formes plurielles et des espaces réservés.** Choisissez ceux que lit votre bibliothèque : `--plural-format i18next_v4` pour les clés `_one` et `_other` d'i18next, ou `--plural-format icu --placeholder-format icu` pour next-intl. (Consultez la documentation de Lokalise sur les [formats des formes plurielles et des espaces réservés](https://developers.lokalise.com/reference/api-plurals-and-placeholders).) * **Plateformes.** Chaque clé est associée à une ou plusieurs plateformes, et un export ne contient que les clés de la plateforme correspondant à son format. Lancez un export par plateforme : `--format strings` et `stringsdict` pour iOS, et `--format xml` pour Android. * **`--async`.** Le téléchargement synchrone de Lokalise est réservé aux projets de moins de 10 000 paires clé-langue ; au-delà, il faut passer par le téléchargement asynchrone. Sans la CLI, ouvrez la page **Download** du projet, choisissez le format, réglez **Empty translations** sur skip, puis cliquez sur **Build and download**. Le téléchargement requiert l'autorisation de contributeur **Download files**. Vérifiez les codes de paramètres régionaux dans les noms de dossiers. Lokalise utilise ses propres codes de langue, comme `en_GB`, que la CLI compare strictement à votre liste `locales`. Pour remplacer un code, cliquez dessus sur la page **Download** ou utilisez `--language-mapping` ; vous pouvez aussi indiquer dans `gt.config.json` les codes tels qu'ils sont exportés. ## Étape 2 : arrêter la synchronisation de Lokalise Avant que General Translation n'écrive le moindre fichier, désactivez tous les mécanismes qui écrivent des traductions dans votre dépôt : * Supprimez le webhook d'auto-pull de Lokalise dans les paramètres de votre dépôt GitHub. * Cessez d'utiliser le déclencheur GitHub lors des téléchargements, qui ouvre des pull requests depuis une nouvelle branche. * Supprimez ou désactivez les flux de travail qui utilisent les GitHub Actions de push et de pull de Lokalise. Les applications GitLab, Bitbucket et Azure DevOps fonctionnent de la même manière. Si deux outils écrivent dans les mêmes fichiers, c'est le dernier à écrire qui l'emporte. ## Étape 3 : indiquer les fichiers au CLI Installez le CLI `gt` et décrivez les fichiers exportés dans `gt.config.json` : ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de", "fr", "pt-BR"], "files": { "json": { "include": ["locales/[locale]/*.json"] } } } ``` Le CLI lit la syntaxe de messages i18next et next-intl dans les fichiers JSON lorsqu'il détecte `i18next` ou `next-intl` dans votre `package.json`, et traite les autres valeurs JSON comme de simples chaînes. (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 bien définissez `projectId` dans la configuration. En CI, utilisez `GT_API_KEY` avec une clé API de projet disposant des autorisations **Fichiers > Écriture**, **File d'attente de traduction > Activée** et **Contexte > Écriture**. ## Étape 4 : Importer votre glossaire et le contexte de vos clés Sur la page [Glossary](https://docs.lokalise.com/en/articles/1400629-glossary) de Lokalise, utilisez **More > Download CSV** pour exporter tous les termes avec leurs traductions. Le fichier utilise le point-virgule comme séparateur et contient une colonne par langue, par exemple `de_DE`. Conservez `term`, renommez `description` en `definition` et chaque colonne de langue en `translation_`, par exemple `translation_de`, supprimez les autres colonnes, puis enregistrez le fichier avec la virgule comme séparateur. 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, puis assignez le groupe à votre projet avant la première exécution de traduction : les nouvelles traductions utiliseront ainsi votre terminologie dès le départ. Les descriptions de clés indiquent au traducteur la signification d'une chaîne de caractères. Les exportations iOS `.strings` et Android `strings.xml` les incluent par défaut sous forme de commentaires, et General Translation transmet ces commentaires comme contexte. Pour le JSON, récupérez la description et la limite de caractères de chaque clé avec `lokalise2 key list`, ou à partir d'une exportation [`json_structured`](https://docs.lokalise.com/en/articles/3229161-structured-json) de votre langue source enregistrée en dehors des dossiers définis dans `gt.config.json`, puis écrivez-les dans un fichier de [métadonnées associées aux clés](/docs/cli/reference/keyed-metadata) placé à côté du fichier source : ```json title="locales/en/common.metadata.json" { "checkout": { "save": { "context": "Button that saves the shipping address", "maxChars": 12 } } } ``` Recréez vos guides de style Pro AI sous forme d'[instructions personnalisées](/docs/platform/dashboard/guides/defining-context-for-translations). Si votre offre inclut la gestion de la mémoire de traduction, un administrateur de l'équipe peut en conserver une archive à l'aide de l'option **Download as TMX file**, accessible dans **Team settings > Translation memory**. ## É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, par exemple 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 exportés. Les clés que Lokalise n'avait pas traduites seront traduites par General Translation à la prochaine modification de leur fichier source. Pour les livrer plus tôt, terminez leur traduction dans Lokalise avant d'exporter. ## É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`, qui recense les traductions déjà écrites par la CLI afin qu’elle ne les retélécharge pas. Si votre équipe modifie des fichiers traduits dans le dépôt, exécutez [`npx gt save-local`](/docs/cli/reference/commands/save-local) avant la prochaine traduction afin de conserver ces modifications. ## Quand faut-il rester sur Lokalise ? Restez sur Lokalise si vos applications mobiles natives dépendent de mises à jour OTA (over-the-air) des chaînes, si vos designers travaillent avec le plugin Figma et des captures d'écran, si vous commandez des traductions professionnelles directement dans l'outil, ou si votre pipeline échange des fichiers XLIFF ou ARB. (Voir [General Translation vs. Lokalise](/kb/general-translation-vs-lokalise).) ## Questions fréquentes ### Vais-je perdre mes traductions relues ? Non, à condition d'ignorer les traductions vides lors de l'export 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). ### Que deviennent les captures d'écran ? Elles restent dans Lokalise. Pour ne pas perdre les informations qu'elles fournissaient aux traducteurs, indiquez où apparaît chaque chaîne de caractères dans le contexte propre à sa clé (étape 4). ## Points clés * Exportez un fichier par langue et par plateforme avec `--export-empty-as skip`, en conservant le format de pluriel que votre application lit déjà. * Supprimez le webhook, les déclencheurs et les Actions de Lokalise avant que General Translation n’écrive dans les mêmes fichiers. * Importez le glossaire dans un groupe de contexte et reprenez les descriptions des clés comme 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 lors de la compilation ou avec Locadex. ## Related questions - [Alternatives à Lokalise : General Translation ou Lokalise](https://generaltranslation.com/fr/kb/general-translation-vs-lokalise.mdx): General Translation est une alternative solide à Lokalise pour les équipes qui souhaitent garder des textes lisibles dans le JSX et intégrer la traduction au développement. Lokalise repose sur des clés partagées, des intégrations avec les outils de design et la livraison over-the-air sur mobile. General Translation génère les traductions à partir du contenu balisé de l’application et permet la relecture dans son tableau de bord ou dans les pull requests GitHub. - [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 migrer de Phrase vers General Translation ?](https://generaltranslation.com/fr/kb/migrate-from-phrase.mdx): 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é. - [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 Crowdin vers General Translation ?](https://generaltranslation.com/fr/kb/migrate-from-crowdin.mdx) - Next question: [Comment migrer de Phrase vers General Translation ?](https://generaltranslation.com/fr/kb/migrate-from-phrase.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.