How to keep Java properties files human readable

Question

Grails uses Java Properties files too.

I can use Google translate to do an initial translation of my message.properties file, even into languages like Chinese. I can see the actual Chinese characters in my new messages_zh_CN.properties file, when I view it in Netbeans or notepad++.

But once the file goes into svn, when it's checked out, the Chinese characters aren't visible any more. All you can see is the ISO 8859-1 encoding. For example:

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

It does still work once the app is run. And Google translate is a great short cut to a translation. But after that, the properties file needs to be sent to a native speaker for editing.

So how can I get the properties file in ISO 8859-1 back to being human readable? Like this:

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

Answer 1

For Eclipse, there is this 'Property Editor' plugin -> http://propedit.sourceforge.jp/index_en.html

It does exactly what you are looking for, doing unicode-to-glyph-and-back translation behind the scenes.

Answer 2

I think your diagnostic is wrong.

The \\uXXXX syntax is what is used by a property-aware editor to save non-ASCII sequences for it to be robust across encoding schemes and platforms, and I think this is what has happened here.

Please retrace your steps to see which editor saves in this form and then either keep using this editor (and other \\uXXXX aware ones) or stay away from it. You may want to tell your native speaking translators to use the same editor as you choose to do.

Answer 3

I'd go for Thorbjørn Ravn Andersen 's answer: The .properties file has been edited in a specialized editor that automatically saves Unicode characters in its ASCII notation (\\uXXXX).

Alexander Pogrebnyak has mentioned such an editor, and they are pretty common in the "Java world".

mfloryan mentioned the native2ascii tool (that comes with the JDK), that does the conversion under the hood.

---

Now some background on all that:

Java 's i18n mechanisms are mostly based on the PropertyResourceBundle class, which ApiDoc states:

Constructing a PropertyResourceBundle instance from an InputStream requires that the input stream be encoded in ISO-8859-1. In that case, characters that cannot be represented in ISO-8859-1 encoding must be represented by Unicode Escapes

Thus, as a workaround(!), in the Java world, you can either use the JDK's native2ascii to transform the .properties files, or, alternatively, use a specialized editor that saves "Unicode Escapes" but lets you edit the actual Unicode characters.

In the Spring framework, in contrast, the i18n mechanisms are, by default, based on Spring's ResourceBundleMessageSource class, which is fully Unicode-enabled. Grails ' i18n mechanisms are Spring-based.

Grails default setting grails.enable.native2ascii = true is meant to enable mixed Spring/Grails and Java environments. - You'll neither need the native2ascii tool nor a special .properties files editor if you're not using Java's own ResourceBundle.getBundle("foo").getKey("bar") , and if you're not working with "classic Java" JSTL or JSF tags.

With Grails and Spring, you can use Unicode .properties files just as they are.

Answer 4

I has nothing to do with SVN - I don't think. There is a configuration option in Grails that dictates this behaviour. In the Config.groovy file you will find the following line:

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

This means, that the native2ascii command is applied to the properties file and converts them to unicode notation. You can set this option to false if you want to retain the original native language charset. You can always reverse you file as well using the native2ascii -reverse command.