Une manière deübersetzentranslatetranslatetraduiretraducirübersetzentradurretraduzirперевести翻訳する翻译번역하다traduiresans casser le moindre octet.

Une seule {name} mal placée change tout. Une salutation devient une UI cassée. Un CTA perd sa variable. Un paywall traduit le placeholder qu’il devait injecter. Les moteurs de traduction génériques traitent le fichier comme du texte ; les traducteurs humains, aussi soigneux soient-ils, n’ont pas reçu le contrat structurel que votre build attend.

Nous nous plaçons entre les deux. Nous lisons votre fichier comme du code, ne traduisons que les chaînes, validons chaque placeholder touché, et réassemblons le document avec une parité octet-à-octet sur tous les jetons non-textuels. Le diff est vide là où il doit l’être.

Avant même de traduire, il faut décider où vit la copie. Un Excel partagé tient le temps d'un sprint, puis casse au premier merge. Un fichier dans le repo, à côté du code qui le consomme, tient des années.

JSON pour les apps qui itèrent vite, XLIFF pour les workflows pros à plusieurs mains. Les deux ont leurs raisons, et nous prenons les deux. Si vous hésitez sur lequel adopter, on en discute.

La plupart des sites à fort volume de pages bloquent au même endroit. L'équipe sait qu'il faut un JSON ou un XLIFF, mais ne sait pas comment l'extraire de sa stack. Le projet de traduction reste sur étagère pendant des mois, faute du bon point d'entrée.

On ouvre votre code et votre CMS. On identifie où vit la copie traduisible — composants, content models, blocks, références. On choisit le format adapté à votre workflow. On vous remet le fichier prêt à traduire, avec le script d'extraction si vous voulez le rejouer à chaque release.