Hacker News new | past | comments | ask | show | jobs | submit login

"Finally the Java property file format was used (with UTF-8 encoding) which while having bugs in the import and export escaping these could at least be worked around."

The java property file format is ISO-8859-1 not UTF-8. I have to wonder if that's the bugs you hit? While you can have something that is UTF-8, there's a couple of wrinkles with trying to use that with java i18n.

See: http://docs.oracle.com/javase/6/docs/api/java/util/ResourceB...

... when you load a resourcebundle, it tries to load a properties file, and it ends up calling this method:

http://docs.oracle.com/javase/6/docs/api/java/util/Propertie...

... which mentions the encoding.

There's a couple of ways around this - one is to write a bunch of code to change how resourcebundles are loaded, the other is to use java's native2ascii tool in your to provide files that are correctly escaped.




Transifex have extended the format and allow resources to be UTF-8 encoded (see http://help.transifex.com/features/formats.html#java-propert... ) however the importer does not correctly cope with single quote characters, backslash n (newline) and several other characters being encoded when they ought to be (as per the document you referenced which I also used to begin with ;-)

If you look at the script Vivek wrote http://git.netsurf-browser.org/netsurf.git/tree/utils/split-... he clearly documents the odd importer issues which is why we called it the transifex resource format and not Java resource format ;-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: