Comment conserver les fichiers de propriétés Java lisibles par l'utilisateur

Question

Grails utilise également les fichiers de propriétés Java.

Je peux utiliser Google translate pour faire une traduction initiale de mon fichier message.properties, même dans des langues comme le chinois. Je peux voir les caractères chinois réels dans mon nouveau fichier messages_zh_CN.properties, lorsque je l'affiche dans Netbeans ou notepad ++.

Mais une fois que le fichier va dans svn, quand il est extrait, les caractères chinois ne sont plus visibles. Tout ce que vous pouvez voir est l'encodage ISO 8859-1. Par exemple:

default.paginate.prev =\u4e0a\u4e00\u9875 
default.paginate.next =\u4e0b\u4e00\u6b65 
default.boolean.true =\u771f 
default.boolean.false =\u5047 

Il ne fonctionne encore une fois que l'application est exécutée. Et Google translate est un excellent raccourci vers une traduction. Mais après cela, le fichier de propriétés doit être envoyé à un locuteur natif pour être édité. Comment puis-je rendre le fichier de propriétés dans ISO 8859-1 de nouveau lisible par l'homme?

Comme ceci:

default.paginate.prev =上一页 
default.paginate.next =下一步 
default.boolean.true =真 
default.boolean.false =假 

Answer 1

Pour Eclipse, il y a ce plugin 'Property Editor' ->http://propedit.sourceforge.jp/index_en.html

Il fait exactement ce que vous cherchez, faire la traduction unicode-to-glyphe et derrière la scènes.

Answer 2

Je pense que votre diagnostic est erroné.

La syntaxe \ uXXXX est ce qui est utilisé par un éditeur prenant en charge les propriétés pour enregistrer des séquences non ASCII pour qu'il soit robuste à travers les schémas de codage et les plates-formes, et je pense que c'est ce qui s'est passé ici.

Veuillez revenir sur vos pas pour voir quel éditeur est sauvegardé dans ce formulaire, puis soit continuer à utiliser cet éditeur (et d'autres qui en sont conscients) ou rester à l'écart. Vous pouvez indiquer à vos traducteurs de langue maternelle d'utiliser le même éditeur que vous le souhaitez.

Answer 3

Je n'ai rien à voir avec SVN - je ne pense pas. Il existe une option de configuration dans Grails qui dicte ce comportement. Dans le fichier Config.groovy, vous trouverez la ligne suivante:

// enabled native2ascii conversion of i18n properties files 
grails.enable.native2ascii = true 

Cela signifie que la commande native2ascii est appliquée aux fichier de propriétés et les convertit en notation unicode. Vous pouvez définir cette option sur false si vous souhaitez conserver le jeu de caractères d'origine dans la langue maternelle. Vous pouvez toujours inverser le fichier en utilisant la commande native2ascii -reverse.

Answer 4

Je vais pour Thorbjørn Ravn réponse Andersen: Le fichier .properties a été édité dans un éditeur spécialisé qui enregistre automatiquement les caractères Unicode dans sa notation ASCII (\ uXXXX).

Alexander Pogrebnyak a mentionné un tel éditeur, et ils sont assez communs dans le "monde Java".

mfloryan a mentionné l'outil native2ascii (fourni avec le JDK), qui fait la conversion sous le capot.

---

maintenant quelques informations sur tout ce qui:

mécanismes de i18n Java sont principalement basées sur la classe PropertyResourceBundle, qui ApiDoc états:

la construction d'un PropertyResourceBundle instance à partir d'un InputStream nécessite que le flux d'entrée soit codé en ISO- 8859-1. Dans ce cas, les caractères qui ne peuvent pas être représentés dans encodage ISO-8859-1 doivent être représentés par Unicode Escapes

Ainsi, comme solution de contournement (!), Dans le monde Java, vous pouvez utiliser la native2ascii JDK pour transformer les fichiers .properties, ou, alternativement, utiliser un éditeur spécialisé qui enregistre "Escape Unicode", mais vous permet d'éditer les caractères Unicode réels.

Dans le cadre printemps, en revanche, les mécanismes de i18n sont, par défaut, selon la classe de printemps ResourceBundleMessageSource, qui est entièrement compatible Unicode. Grails 'Les mécanismes i18n sont à base de ressorts.

Le paramètre par défaut Grails grails.enable.native2ascii = true permet d'activer les environnements mixtes Spring/Grails et Java. - Vous n'aurez pas non plus besoin de l'outil native2ascii ni d'un éditeur de fichiers .properties si vous n'utilisez pas le ResourceBundle.getBundle("foo").getKey("bar") de Java, et si vous ne travaillez pas avec des balises JSTL ou JSF "Java classique". Avec Grails et Spring, vous pouvez utiliser les fichiers .properties Unicode comme ils le sont.