Devrais-je utiliser java.text.MessageFormat pour des messages localisés sans espaces réservés?

Question

Nous localisons le texte de l'interface utilisateur pour une application Web exécutée sur Java 5 et nous avons un dilemme sur la manière dont nous produisons les messages définis dans les fichiers de propriétés - type utilisé par java.util.Properties .

Certains messages incluent un espace réservé qui sera rempli à l'aide de java.text.MessageFormat . Par exemple:

search.summary = Your search for {0} found {1} items.

MessageFormat est gênant, car une citation unique est un caractère spécial, bien qu’elle soit courante dans le texte anglais. Vous devez taper deux pour une citation unique littérale:

warning.item = This item''s {0} is not valid.

Cependant, les trois quarts des quelque 1 000 messages de l'application n'incluent pas d'espace réservé. Cela signifie que nous pouvons les sortir directement, en évitant MessageFormat et en laissant les guillemets simples:

help.url = The web page's URL

Question: devrions-nous utiliser MessageFormat pour tous les messages, pour une syntaxe cohérente, ou éviter MessageFormat dans la mesure du possible, afin que la plupart des messages n'aient pas besoin d'être échappés?

Il y a clairement des avantages et des inconvénients dans les deux cas.

Notez que la documentation de l'API pour MessageFormat reconnaît le problème et suggère de ne pas résoudre le problème:

  

Les règles d'utilisation des guillemets au sein de   modèles de format de message malheureusement   se sont avérés quelque peu déroutants.   En particulier, ce n'est pas toujours évident   aux localisants si guillemets simples   besoin d'être doublé ou non. Assure-toi   informer les localisateurs sur les règles,   et dites-leur (par exemple, en utilisant   commentaires dans la source du regroupement de ressources   fichiers) quelles chaînes seront traitées   par MessageFormat.

Answer 1

Écrivez simplement votre propre implémentation de MessageFormat sans cette fonctionnalité gênante. Vous pouvez consulter le code de Enregistreur SLF4J .

Ils ont leur propre version du formateur de message qui peut être utilisé comme suit:

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

Des espaces réservés vides peuvent être utilisés avec un ordre par défaut et numérotés dans certains cas de localisation où différentes langues effectuent des permutations de mots ou de parties de phrases.

Answer 2

À la fin, nous avons décidé de contourner le problème des guillemets simples en utilisant toujours & # 8216; curly & # 8217; citations:

warning.item = This item\u2019s {0} is not valid.

Answer 3

Utilisez le caractère `` à la place de 'pour citer. Nous l'utilisons tout le temps sans problèmes.

Utilisez MessageFormat uniquement lorsque vous en avez besoin, sinon ils ne font que gonfler le code et n'ont aucune valeur supplémentaire.

Answer 4

À mon avis, la cohérence est importante pour ce genre de chose. Les fichiers de propriétés et MessageFormat ont déjà de nombreuses limitations. Si vous trouvez cela troublant, vous pouvez & "Compiler &"; vos fichiers de propriétés pour générer ceux qui sont correctement formés. Mais je dirais qu’il faut utiliser MessageFormat partout. De cette façon, lorsque vous gérez le code, vous n'avez plus à vous soucier des chaînes qui sont formatées ou non. Cela devient plus simple à gérer, car vous pouvez confier le traitement des messages à une bibliothèque sans vous soucier des détails à un niveau élevé.

Answer 5

Une autre alternative ... Lors du chargement du fichier de propriétés, encapsulez simplement le flux d'entrée dans un FilterInpuStream qui double chaque citation.