Je ne veux pas être le porteur de mauvaises nouvelles, mais ce que vous proposez est en fait une mauvaise idée. Je travaille pour une entreprise qui prend l'i18n très au sérieux et nous avons découvert (douloureusement) que vous ne pouvez pas insérer des mots dans des phrases comme ça, car elles n'ont souvent aucun sens. Ce que nous faisons est simplement de déconnecter le texte d'erreur des bits variables afin d'éviter ces problèmes. Pour, par exemple, nous générerons une erreur:
XYZ-E-1002 Frobozz not configured for multiple zorkmids (F22, 7).
Et puis, dans la description de l'erreur, vous déclarez simplement que les deux valeurs entre parenthèses à la fin étaient l'identifiant Frobozz et le nombre de zorkmids vous avez essayé de l'infliger.
Cela laisse la traduction i18n comme une tâche incroyablement facile puisque vous avez, au moment de la traduction, tous des éléments de langage dont vous avez besoin sans se soucier si les bits variables doivent être au singulier ou au pluriel, masculin ou féminin, premier, deuxième, ou troisième déclinaison (peu importe ce que cela signifie réellement).
L'équipe de traduction doit simplement convertir "Frobozz not configured for multiple zorkmids" et c'est beaucoup plus facile.
Pour ceux qui voudraient voir un exemple concret, j'ai quelque chose de nos BOD de traduction (avec suffisamment de choses a changé pour protéger les coupables).
À un certain moment, quelqu'un présenté les observations suivantes:
The {name} {object} is invalid
où {name} était le nom d'un objet (clients, commandes, etc.) et {object} était le type d'objet lui-même (table, fichier, document, stocké procédure, etc).
Assez simple pour l'anglais, la langue principale (probablement seulement) des développeurs, mais ils ont rencontré un problème lors de la traduction en allemand/suisse-allemand. Alors que le "document clients" a été traduit correctement (dans un sens positionnel) en Kundendokument, le fait que la chaîne de format ait un espace entre les deux mots était un problème. C'était essentiellement parce que les développeurs essayaient de faire paraître la phrase plus naturelle mais, malheureusement, seulement plus naturelle basée sur leur expérience limitée.
Un plus gros problème était avec la "procédure stockée des clients" qui est devenue gespeichertes Verfahren der Kunden, littéralement "procédure stockée des clients". Alors que les clients allemands peuvent avoir mis en place un espace dans Kunden dokument, il n'y a aucun moyen d'imposer gespeichertes Verfahren der Kunden sur {name} {object} avec succès.
Maintenant vous pouvez dire qu'une chaîne de format intelligent aurait fixé cela, mais il y a plusieurs raisons pour lesquelles ce serait incorrect:
- Ceci est un exemple très simple, il y a probablement d'autres plus complexes (J'essaierais d'obtenir quelques exemples, mais nos comités de traduction ont clairement indiqué qu'ils ont un travail plus pressant que de se soumettre à tous mes caprices).
- le point entier des chaînes de format est d'externaliser la traduction. Si les chaînes de format elles-mêmes sont spécifiques à la cible de traduction, vous avez gagné très peu en externalisant le texte.
- les développeurs ne devraient pas avoir à se préoccuper des chaînes de format comme
{possible-pre-adjectives} {possible-pre-owner} {object} {possible-post-adjectives} {possible-post-owner} {possible-postowner-adjectives}. C'est le travail des équipes de traduction car ils comprennent les nuances.
Notez que l'introduction de la déconnexion élude cette question bien:
The object specified by <parameter 1>, of type <parameter 2>, is invalid.
Parameter 1 = {name}.
Parameter 2 = {object}.
Der sache nannte <parameter 1>, dessen art <parameter 2> ist, ist falsch.
Parameter 1 = {name}.
Parameter 2 = {object}.
Cette dernière traduction a été l'un de mes, s'il vous plaît ne pas l'utiliser pour contester la qualité de nos traducteurs. Il ne fait aucun doute que les Allemands qui parlent couramment vont bien rigoler.
Utilisez une autre langue? Python fait cela, mais c'est une question intéressante pour C – shodanex