Quote:
Originally Posted by ixtab
Just committed the changes. Please test-drive the new version and let me know if it works (I don't have Windows around...).
|
It works fine (output has '\n' line endings and no timestamp), thanks again.
Quote:
Originally Posted by ixtab
I guess you're right in principle. But (there are two "but"s):
- localized property files come from transifex (tx pull), not from the extraction tool.
|
Yeah, you are right here. I was looking into tool output and saw there some _de resources with \uXXXX escapes (they are at com/amazon/kindle/kindlet/internal/developer/install, at least). But now I am thinking that these localized resources (extracted from Kindle) are of no value and shouldn't be imported into Transifex, so presence of \uXXXX escapes in them doesn't matter.
(BTW, just for the reference: resources with type=MOZILLAPROPERTIES are exported in UTF-8 from Transifex.)
Quote:
Originally Posted by ixtab
- I am not converting every single properties file into a class, but only some. There is a very simple heuristic behind the selection: i) if a properties file contains arrays, then necessarily create a class from it; ii) otherwise, temporarily create a class, then bundle whichever file is smaller (the original properties file, or the class file). This could of course be changed to make everything into a class, but this will normally bloat the size of the .jar (factor ~ 2 while testing the de locale). In addition, the classes are not terribly efficient (they internally use a Base64-encoded version of the serialized String of the contents, which must be decoded and deserialized when the class is loaded). Of course there are no benchmarks around, but I guess that this may be slower than directly using .properties. So to summarize, the resulting jar contains a mix of .properties and .class files.
|
OK, then I'm fine with escaped Unicode characters. As I've said, expect importing of resources onto Transifex in a day or so.