Quote:
Originally Posted by ixtab
Thanks for checking it!
All of these things come from Java itself, and none of them should really matter.
- the line endings and timestamp are produced by Properties.store(). There certainly *could* be a way of changing the line endings or removing the timestamp comment, but honestly: is it really a problem?
- I'm not outputting escape sequences. Again, it's what Java Properties.store() produces. properties files are encoded in ISO-8859-1, so escaping UTF-8 is actually the proper way. Some of the originally localized files include yet another way of escaping (using octal escapes, if I'm not mistaken). These escapes are hard-coded in the original translations.
As said, none of this *should* matter. The source files themselves only serve as input to transifex anyway. The translated files are the only ones actually being "packed" (as .properties or as .class, depending on what is required or makes more sense). In any case, the only thing that really matters IMO is whether transifex can make sense of the inputs (as produced by "extract"), and whether locale files (as produced by "compile") display properly on the Kindle. Both of these should be the case.
|
Line endings and timestamp in header comment matters in Git repo workflow. If
- I'll commit these files as-is with '\r\n'
- and then you'll find out that some translatable properties are missing in only one existing .properties file (or whatever that will require to change content of commited .properties)
- and you'll run your tool again
- and you'll add it's whole output with '\n' (instead of adding only changed .properties file)
then Git will show that all .properties files were changed because, well, all line endings were changed. All lines will appear in 'git diff' output, so it will be of no use.
OK, line endings could be no problem with 'git config --global core.autocrlf input' (as I've just found out), but timestamp changes will pollute 'git diff' output even on small changes in only one .properties file.
Also, using of UTF-8 instead \uXXXX will be useful for reader of translated .properties files taken straight from Git repo. I'm saying as Russian-speaking user. All Russian strings (using cyrillic alphabet) will be represented as long sequences of \uXXXX. It will be hard to fix some translation errors from plain old text editor (while using transifex command-line client).
But, then, I've thought that you are controlling output of your tool, and also, that .properties is only intermediate format for translating which is compiled back into .class in the end. So I've made some suggestions on how to improve tool's output. But it seems you're using Java-provided functions for outputting data into .properties files and also put some of these .properties back into bundle on compiling, so inablility of change .properties format makes sense for me now. So I'm not insisting on changing it and will proceed to commit it into Git repo and Transifex (in a day or so).