GitHub Copilot pour l'i18n : Configuration des flux de traduction dans VS Code

Mon Copilot est passé d'agaçant à indispensable

Il y a six mois, j'étais prêt à désactiver Copilot pour tout ce qui concernait l'i18n. Il continuait de suggérer des chaînes codées en dur alors que je voulais des clés de traduction. Il autocomplétait "Loading..." quand je voulais t('common.loading'). Il ne comprenait pas nos conventions de nommage de clés. Frustrant.

Puis j'ai découvert la fonctionnalité d'instructions personnalisées de Copilot. J'ai passé une soirée à la configurer correctement, et maintenant c'est l'opposé. Copilot aide réellement à la localisation au lieu de lutter contre elle.

Voici la configuration qui a transformé mon flux de travail.

Le problème avec le comportement par défaut de Copilot

Par défaut, Copilot ne sait pas que vous voulez des clés i18n au lieu de chaînes codées en dur, vos conventions de nommage de clés, quelle bibliothèque de traduction vous utilisez, ou que certain texte ne devrait pas être traduit (journaux, messages de développement).

Donc il suggère ce que fait la plupart du code sur GitHub : des chaînes anglaises codées en dur partout.

La solution est d'enseigner à Copilot l'approche i18n de VOTRE projet.

Configuration des instructions personnalisées Copilot

VS Code Copilot lit les instructions depuis .github/copilot-instructions.md. Créez ce fichier à la racine de votre projet.

Commencez par une section sur l'internationalisation. Expliquez que ce projet utilise react-i18next pour tout le texte visible par l'utilisateur et ne devrait JAMAIS utiliser de chaînes codées en dur.

Lors de la rédaction de texte visible par l'utilisateur, utilisez la fonction t() de useTranslation(). Utilisez le composant Trans pour l'interpolation complexe. Suivez le format de clé namespace.section.element.

Donnez des exemples : pour les boutons utilisez t('common.buttons.save') pas "Save". Pour les titres utilisez t('settings.profile.title') pas "Profile Settings". Pour les messages utilisez t('errors.network.timeout') pas "Connection timed out".

Spécifiez ce qu'il ne faut PAS traduire : messages console.log, messages d'erreur dans les blocs catch (pour le débogage), noms de classes CSS, identifiants techniques et étiquettes d'environnement de développement.

Listez vos espaces de noms : common pour les éléments UI partagés (boutons, étiquettes), errors pour les messages d'erreur, validation pour les messages de validation de formulaire, auth pour ce qui est lié à l'authentification, settings pour la page des paramètres, et les espaces de noms spécifiques aux fonctionnalités.

Après avoir ajouté ce fichier, les suggestions de Copilot changent radicalement. Il commence à proposer des clés de traduction au lieu de chaînes.

Faire comprendre à Copilot votre bibliothèque de traduction

Différents projets utilisent différentes bibliothèques i18n. Personnalisez vos instructions en conséquence.

Pour react-i18next, documentez le modèle d'importation : import useTranslation from 'react-i18next', puis déstructurez t depuis useTranslation('namespace'). Pour les composants avec HTML, utilisez Trans de react-i18next avec une i18nKey et une prop components. Pour les pluriels, utilisez t('items.count', { count: items.length }).

Pour next-intl, dans les composants serveur importez getTranslations depuis 'next-intl/server' et attendez-le. Dans les composants client, importez useTranslations depuis 'next-intl'. Notez que les messages sont dans /messages/{locale}.json.

Pour Vue I18n, dans les modèles utilisez {{ $t('key.path') }}. Dans setup, déstructurez t depuis useI18n() et appelez t('key.path').

Enseigner à Copilot vos conventions de nommage de clés

C'est là que la magie opère. Soyez précis sur la façon dont les clés doivent être nommées.

Documentez la structure : les clés suivent namespace.section.element.

Documentez les modèles :

• Titres de page : {page}.title (par exemple, settings.title)
• En-têtes de section : {page}.{section}.heading (par exemple, settings.profile.heading)
• Boutons : {namespace}.buttons.{action} (par exemple, common.buttons.save)
• Étiquettes de formulaire : {page}.form.{field}.label (par exemple, auth.form.email.label)
• Espaces réservés de formulaire : {page}.form.{field}.placeholder
• Messages d'erreur : errors.{category}.{type} (par exemple, errors.validation.required)
• Messages de succès : messages.success.{action} (par exemple, messages.success.saved)

Documentez les règles de nommage : utilisez le camelCase pour les clés à plusieurs mots, soyez descriptif (deleteConfirmation pas msg1), évitez les abréviations (numberOfItems pas numItems), et groupez les clés liées (tous les champs de formulaire sous .form.).

Avec ces modèles, lorsque vous tapez t(' après un bouton, Copilot suggère common.buttons. comme préfixe.

Configurations spécifiques à l'espace de travail

Pour les projets plus importants, vous voudrez peut-être des paramètres différents par espace de travail.

Dans .vscode/settings.json, vous pouvez définir github.copilot.chat.localeOverride sur "fr-FR" et configurer quels types de fichiers ont Copilot activé.

Vous pouvez également créer des fichiers d'instructions spécifiques à l'espace de travail qui étendent le principal.

Invites qui fonctionnent bien pour les tâches i18n

Au-delà des suggestions passives, Copilot Chat est excellent pour le travail i18n actif. Voici des invites que j'utilise régulièrement :

Extraction de chaînes : "Extrais toutes les chaînes codées en dur de ce fichier vers des clés de traduction. Utilise l'espace de noms settings. Mets à jour le JSX pour utiliser t() et ajoute les clés à mon fichier en.json."

Création de fichiers de traduction : "Crée un fichier de traduction pour l'espagnol (es) basé sur mon fichier anglais. Traduis les chaînes UI naturellement, garde les termes techniques, maintiens la syntaxe des espaces réservés comme {{name}}."

Recherche de chaînes codées en dur : "Trouve toutes les chaînes visibles par l'utilisateur codées en dur dans ce composant qui devraient être internationalisées. N'inclus pas console.log ou les messages d'erreur pour le débogage."

Génération de clés manquantes : "Regarde mon composant et compare à mon fichier de traduction. Quelles clés j'utilise qui n'existent pas dans le fichier de traduction ?"

Révision des traductions : "Révise ces traductions espagnoles pour : flux de langue naturel, gestion appropriée du pluriel, terminologie cohérente, et tout problème de longueur brisant l'UI."

Intégration avec les systèmes de gestion de traduction

Copilot ne peut pas appeler directement les API (sans outils activés MCP), mais vous pouvez toujours rationaliser le flux de travail.

Option 1 : Générer du JSON prêt pour TMS. Ajoutez à vos instructions que lors de la génération de nouvelles clés de traduction, Claude devrait également créer un fichier d'importation TMS au format JSON avec des champs key, value, context (pour les traducteurs), et maxLength.

Option 2 : Intégration CLI. Documentez dans vos instructions qu'après avoir ajouté de nouvelles clés, le développeur doit exécuter npx @intlpullhq/cli upload pour pousser les nouvelles clés vers le TMS et npx @intlpullhq/cli download pour récupérer les dernières traductions.

Option 3 : Utiliser les extensions Copilot. GitHub déploie des extensions Copilot qui peuvent appeler des API externes. Surveillez les intégrations TMS devenant disponibles. Cela permettra une véritable automatisation de bout en bout.

Erreurs courantes de Copilot i18n et correctifs

Erreur 1 : Suggérer une mauvaise syntaxe de bibliothèque. Si Copilot continue de suggérer i18n.t() alors que vous utilisez t(), ajoutez aux instructions : "NE JAMAIS utiliser : i18n.t(), i18next.t(), this.$t(). TOUJOURS utiliser : t() depuis le hook useTranslation()."

Erreur 2 : Oublier l'importation de l'espace de noms. Si les composants manquent l'importation useTranslation, ajoutez : "Chaque composant avec des traductions doit avoir : import { useTranslation } from 'react-i18next'; et const { t } = useTranslation('namespace'); à l'intérieur du composant."

Erreur 3 : Casse de clé incohérente. Ajoutez : "Le nommage des clés DOIT être cohérent. CORRECT : settings.profileTitle (camelCase). FAUX : settings.profile_title (snake_case). FAUX : settings.profile-title (kebab-case)."

Erreur 4 : Traduire du contenu technique. Ajoutez : "NE PAS traduire : noms de variables, points de terminaison API, messages de journal (sauf visible par l'utilisateur), noms de classes, attributs ID."

Avancé : Agents d'espace de travail avec Copilot

Le chat Copilot de VS Code prend en charge l'agent @workspace qui peut rechercher dans votre base de code. Utilisez-le pour les audits i18n :

@workspace trouve tous les fichiers avec des chaînes codées en dur qui devraient utiliser des clés de traduction

@workspace montre-moi tous les appels t() qui référencent des clés non présentes dans nos fichiers de traduction

@workspace quels espaces de noms sont utilisés dans la fonctionnalité settings ?

L'agent @workspace a accès au contexte de votre projet, rendant ces requêtes précises.

Comparaison : Copilot vs Claude Code vs Cursor pour l'i18n

Ayant utilisé les trois extensivement :

Mon avis : Utilisez Copilot si vous êtes déjà dans VS Code et voulez une assistance légère. Utilisez Claude Code si vous avez besoin de flux de travail multi-étapes autonomes. Utilisez Cursor si vous voulez une UX style Copilot avec des capacités MCP.

Ils ne sont pas mutuellement exclusifs. J'utilise Copilot pour des suggestions rapides et Claude Code pour des opérations complexes.

Le fichier d'instructions qui fonctionne

Après beaucoup d'itérations, voici ma structure copilot-instructions.md complète :

Commencez par le cadre : la bibliothèque est react-i18next v14+, le format de fichier est JSON avec structure imbriquée, l'emplacement est /public/locales/{lang}/{namespace}.json.

Documentez l'utilisation de la fonction de traduction : importez useTranslation depuis react-i18next, déstructurez t depuis useTranslation('namespace'), et utilisez t() en JSX.

Documentez le nommage des clés : format namespace.section.element. Les pages utilisent le nom de la page comme espace de noms (settings, dashboard, auth). Les éléments partagés utilisent l'espace de noms "common". Les erreurs utilisent l'espace de noms "errors". La validation utilise l'espace de noms "validation".

Listez les règles : NE JAMAIS utiliser de chaînes visibles par l'utilisateur codées en dur, TOUJOURS utiliser t() pour tout texte que les utilisateurs voient, TOUJOURS inclure l'espace de noms dans useTranslation(), TOUJOURS utiliser camelCase pour les clés, TOUJOURS ajouter des descriptions contextuelles pour le texte ambigu.

Documentez les modèles de clés pour les boutons, étiquettes, espaces réservés, titres, messages et erreurs.

Documentez les pluriels : utilisez le format ICU avec t('items.count', { count: n }). Dans le JSON, utilisez count_one pour le singulier et count_other pour le pluriel.

Ajoutez un rappel CLI : après avoir ajouté des clés, exécutez npx @intlpullhq/cli upload.

Commencer

1. Créez .github/copilot-instructions.md dans votre projet
2. Ajoutez les spécificités de votre bibliothèque i18n
3. Documentez vos conventions de nommage de clés
4. Incluez des exemples d'utilisation correcte
5. Listez ce qu'il ne faut PAS traduire
6. Testez en écrivant un nouveau composant. Copilot devrait suggérer des clés

L'investissement est d'environ 30 minutes à configurer. Le gain est un Copilot qui aide réellement avec l'i18n au lieu de travailler contre vous.

---

Vous utilisez IntlPull ? Ajoutez nos commandes CLI à vos instructions Copilot. Après que Copilot vous ait aidé à écrire des clés de traduction, une commande les synchronise avec votre TMS.