Localisation de grands dépôts de code avec LLM : flux de travail d'un développeur pour 4 500 clés d'interface utilisateur

Un développeur a documenté son processus de localisation d'un projet de jeu de grande envergure avec environ 4 500 clés d'interface utilisateur stockées dans un fichier en-US.json de 500 Ko. Il a utilisé un flux de travail LLM en plusieurs étapes pour gérer l'extraction, la traduction et l'amélioration de la qualité.

Tentatives initiales d'extraction et de traduction

D'abord, il a utilisé Claude pour scanner sa base de code, extraire les chaînes d'interface utilisateur codées en dur et les migrer vers les normes i18n, créant ainsi le fichier de localisation. Pour la traduction en italien, il a d'abord essayé Claude et Gemini Pro (via Gemini CLI et Antigravity). Les deux modèles cloud ont produit des traductions de qualité inacceptable. Gemini Pro a également rencontré des erreurs avec le fichier volumineux, nécessitant de le diviser en 10 morceaux plus petits.

Passage aux modèles locaux et la percée contextuelle

Il a ensuite essayé TranslateGemma localement via LM Studio, traduisant clé par clé. Bien que légèrement meilleure, la qualité n'était toujours pas acceptable. L'idée clé était que les mots d'interface utilisateur sont souvent ambigus, et que la traduction nécessite une désambiguïsation et un contexte d'utilisation.

Pour résoudre cela, il est retourné à Claude pour générer un deuxième fichier. Pour chacune des 4 500 clés, Claude a inspecté l'utilisation du code pour fournir un contexte : où la chaîne apparaît, sa fonction (étiquette de bouton, description, indication de saisie) et son effet dans le gameplay.

Le pipeline de traduction final

Il a construit un pipeline de traduction automatisé avec les étapes suivantes :

• Regrouper les clés par lots avec leur contexte généré.
• Utiliser une invite axée sur la traduction fonctionnelle (et non littérale).
• Appliquer la préservation des espaces réservés et des balises.
• Envoyer les requêtes à un modèle local via LM Studio.

TranslateGemma ne pouvait pas gérer le format d'invite riche en contexte, il a donc changé de modèle. Il a testé sur un Mac Mini M1 avec 16 Go de mémoire unifiée.

Performance des modèles et résultats

Qwen 3 4B a bien performé, mais Qwen 3 8B était le point idéal, produisant moins d'erreurs de grammaire et de meilleures formulations tout en restant gérable à exécuter localement. Le pipeline final peut traduire les 4 500+ clés dans plusieurs langues, prenant environ 8 heures par langue sur sa machine. Il utilise un modèle quantifié pour pouvoir continuer à travailler pendant qu'il s'exécute en arrière-plan.

Le développeur note que cette approche a produit une qualité suffisamment bonne pour être livrée et semblait meilleure que de nombreux projets auto-traduits qu'il a vus.