name: translation-review description: Vérifiez la qualité des traductions langue par langue, comme le ferait un éditeur natif : sens conforme à la référence, formulation naturelle, termes cohérents, registre approprié, grammaire correcte pour les nombres et le genre, longueur dans l'UI, conventions locales (dates, nombres, unités) et règles du projet. Utilisez-la après la vérification de traduction (« translation-check ») soit passée sur des textes nouveaux ou modifiés, lors de la revue d'une PR qui ajoute des textes, ou lorsqu'on vous demande de vérifier les traductions dans toutes les langues.
Revue de traduction, une langue à la fois
translation-check prouve que chaque clé existe avec les bons espaces réservés. Cette compétence lit les mots.
1. Périmètre et contexte
- Quels textes : les clés qu'une modification a ajoutées ou modifiées (diff des fichiers de locale par rapport à la branche de base), ou un espace de noms / un fichier entier si demandé. Obtenez la valeur de référence et la valeur de chaque langue côte à côte.
- Où ils apparaissent : trouvez l'utilisation de chaque clé dans le code (
git grep "<clé>"). S'agit-il d'un bouton, d'un titre, d'un e-mail, d'une erreur, d'une infobulle ? Quel espace a-t-il ? Est-il dans une phrase avec d'autres clés, ou prend-il un{{count}}, un nom, une date ? - Règles du projet :
AGENTS.mdet.claude/translations.json, pour les mots à éviter, les noms de produits et de plans qui restent non traduits, le registre de politesse et qui est le lecteur (client, concessionnaire, administrateur). - Glossaire existant : comment les mêmes termes sont déjà traduits ailleurs dans les fichiers de cette langue.
git grepun terme dans le dossier de cette locale. La cohérence prime sur vos préférences personnelles.
2. Vérifier chaque langue séparément
Pour chaque langue, vérifiez chaque texte pour :
- Sens : dit la même chose que la référence. Rien d'ajouté, rien d'omis, pas de faux amis. Les espaces réservés sont utilisés dans le bon rôle grammatical.
- Naturel : se lit comme le texte original d'un produit dans cette langue, pas une traduction mot à mot de l'anglais. Surveillez l'ordre des mots, les articles et la casse (noms allemands en majuscule ; pas de casse anglaise de titre dans les autres langues).
- Termes : la même chose porte le même nom partout (rapport, commande, crédit, VIN, noms de plans), et correspond au glossaire de l'étape 1.
- Registre : un seul registre dans tout le produit, par ex. Sie ou du en allemand, ви en ukrainien, vous en français, Vy en tchèque, Pan/Pani ou les formes neutres en polonais. Ne les mélangez pas.
- Grammaire avec variables : formes plurielles correctes pour les nombres réels (1, 2, 5, 21, 22, 25 en ukrainien, polonais et tchèque) ; cas après les prépositions ; accord en genre si l'espace réservé est un nom.
- Longueur : les boutons, onglets et badges restent à peu près aussi courts que la référence. Signalez tout ce qui dépasse d'environ 40 % dans un espace restreint.
- Conventions locales : unités (км, кВт, к.с. en ukrainien/bulgare), virgule décimale, ordre des dates, position de la devise, guillemets („…“ en allemand, « … » en français, «…» en ukrainien).
- Règles du projet : mots interdits, orthographe de la marque, noms de plans.
3. Rapport
Regroupez par langue, et pour chaque constat, donnez la clé, le texte actuel, le problème et une suggestion de texte :
uk — 2 constats
- reportPage:upgrade.cta — "Оновити до Complete звіту" — l'ordre des mots semble anglais ; Complete est un nom de plan → "Перейти на звіт Complete"
- ...
de — aucun constat
- Dites quelles langues vous pouvez juger avec confiance. Pour celles que vous ne maîtrisez pas, dites-le plutôt que de deviner, et suggérez une vérification par un locuteur natif.
- Si on vous demande de corriger : appliquez les suggestions dans les fichiers de locale, exécutez à nouveau
i18n:translation-check, et commitez les modifications. - Dans une revue de PR, publiez ces constats en tant que Nit, sauf si le sens est erroné ou qu'un mot interdit apparaît : dans ce cas, c'est Important.