Traduire un fichier XLIFF en japonais, balises et state conservés

Ce que le japonais change dans vos unités XLIFF

Une chaîne japonaise mêle trois écritures : les kanji pour les notions (保存, « enregistrer »), les hiragana pour la grammaire, les katakana pour les emprunts (ダウンロード, « télécharger »). Il n'y a pas d'espace entre les mots et la ponctuation est en pleine chasse : la virgule devient 、 et le point 。. Dans un fichier XLIFF, cela a des conséquences précises.

• Encodage. Le japonais exige un encodage Unicode. Manuce conserve l'encodage du fichier tel quel : un XLIFF déclaré en ISO-8859-1 ne peut pas recevoir de caractères japonais. Déposez-le en UTF-8.
• Langue cible. Vérifiez que le fichier annonce bien le japonais : target-language="ja" sur l'élément <file> en XLIFF 1.2, trgLang="ja" sur la racine <xliff> en XLIFF 2.0.
• Longueur. Le japonais compte souvent moins de caractères que le français, mais chaque caractère occupe à peu près la largeur de deux lettres latines. Un libellé court en kanji (設定) peut s'allonger dès qu'il passe en katakana (アカウントのセキュリティ設定).
• Registre. En interface, les phrases s'écrivent d'ordinaire à la forme polie en です/ます : « Impossible d'enregistrer le fichier. » devient 「ファイルを保存できませんでした。」. Les boutons restent brefs, souvent un simple nom : 保存, キャンセル.

Balises en ligne et ordre des mots japonais

Le japonais place le verbe en fin de phrase. Une unité comme Cliquez sur <g id="1">Enregistrer</g> pour continuer. devient 続行するには<g id="1">保存</g>をクリックしてください。 : la balise encadre toujours le même mot, mais sa place dans la phrase a changé. C'est sans conséquence tant qu'il n'y a qu'une balise.

Avec plusieurs balises ou espaces réservés, Manuce conserve leur ordre. Or l'ordre naturel japonais est parfois inverse : « Page <x id="1"/> sur <x id="2"/> » se dit spontanément en commençant par le total. La traduction doit donc construire la phrase autour de l'ordre imposé, par exemple <x id="1"/>ページ目（全<x id="2"/>ページ）. Relisez ces unités à plusieurs balises en priorité.

Autre piège : les espaces autour des balises. En français, Bienvenue, <ph id="1"/> contient une espace ; en japonais on attend 「ようこそ、<ph id="1"/>さん」, sans espace et avec le suffixe さん après le nom. Si votre code ajoute lui-même des espaces par concaténation de chaînes, elles apparaîtront au milieu du texte japonais.

Une chaîne qui perdrait une balise est refusée et signalée ; si les balises ou variables d'une valeur ne correspondent toujours pas à la source, la valeur source est gardée et le rapport le dit.

Pluriels, compteurs et dates : ce qui reste dans le code

Le japonais n'a qu'une catégorie de pluriel CLDR, other. Si vos unités contiennent des messages ICU ({count, plural, one {# fichier} other {# fichiers}}), seule la branche other sert en japonais ; vérifiez dans le livrable comment les branches ont été rendues et ce que votre bibliothèque attend pour ja.

Le nombre s'accompagne en revanche d'un classificateur qui dépend de ce qu'on compte : 3件 pour des résultats, 3個 pour des objets, 3人 pour des personnes. « <x id="n"/> résultats » devient <x id="n"/>件の結果. Une chaîne trop générique (« <x id="n"/> éléments ») oblige à choisir un classificateur passe-partout ; une note dans le fichier qui précise ce qui est compté aide le traducteur.

Manuce ne traduit pas les nombres, formats de date, URL, adresses email, identifiants, couleurs ni clés. Un format dd/MM/yyyy présent dans une valeur reste tel quel : l'ordre japonais année, mois, jour (2025年3月14日 ou 2025/03/14) se règle dans votre code de localisation, pas dans le XLIFF.

Ce que Manuce rend, et ce qu'il ne fait pas

• Le même fichier XLIFF, 1.2 ou 2.0 : la source est traduite dans l'élément cible, l'attribut state est mis à jour.
• Indentation, ordre des éléments, guillemets, commentaires, fins de ligne, encodage et BOM conservés ; seules les valeurs changent.
• Les unités marquées translate="no" sont respectées ; les notes du fichier servent de contexte au traducteur.
• Chaque valeur traduite est comparée à la source (variables, balises).
• Un rapport : chaînes traduites, chaînes laissées telles quelles et pourquoi.

Manuce ne réordonne pas les balises, ne teste pas le rendu dans votre application et n'ajuste pas la mise en page : un bouton trop étroit pour ダウンロード reste à élargir de votre côté. Manuce ne reçoit ni glossaire ni mémoire de traduction ; il ne produit pas non plus de traduction assermentée.

Le prix porte sur les mots des valeurs, clés et balises exclues ; le japonais est une langue à supplément (coefficient ×1,6 sur le prix au mot).

Préparer le fichier et vérifier après livraison

Avant le dépôt :

• Enregistrez le fichier en UTF-8 et contrôlez la langue cible ja.
• Marquez translate="no" les noms de produit à garder en lettres latines ; sinon, un nom peut être transcrit en katakana.
• Conservez les notes de développeur exportées par votre outil : « Ouvert » (statut) et « Ouvrir » (bouton) ne se traduisent pas pareil, 公開中 et 開く par exemple.
• Lisez l'extrait gratuit : il montre le registre et le traitement des balises avant de payer.

Après la livraison :

• Parcourez le rapport et cherchez les unités restées en source.
• Réimportez le fichier et affichez l'interface avec une police japonaise et la langue déclarée lang="ja" : sans cela, certains kanji peuvent s'afficher avec le tracé chinois de la police de repli.
• Contrôlez les coupures de ligne : un 。 ou un 、 ne doit pas ouvrir une ligne, et un libellé tronqué au milieu d'un mot katakana devient illisible.
• Faites relire par un locuteur natif les unités à plusieurs balises, puis faites évoluer leur state dans votre outil.

En pratique

1. Exportez le XLIFF (1.2 ou 2.0) en UTF-8, avec ja comme langue cible.
2. Marquez translate="no" les noms de produit à garder en lettres latines.
3. Déposez le fichier : devis immédiat sur les mots des valeurs et extrait gratuit d'un paragraphe.
4. Payez, puis récupérez le XLIFF traduit et son rapport.
5. Réimportez-le et vérifiez l'affichage japonais dans l'application.