[bazzargh]

"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.

[kyllikki]

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 ;-)