Thanks for checking it!
Quote:
Originally Posted by eureka
I've ran this tool on 5.0.0 resources: tool's output is attached. No resources were changed between v5.0.0 and v5.0.1, as far as I can see. You could recheck, if you wish.
Tool's output, however, brings some difficulties to checking differencies with 'diff -r'.
Firstly, line endings in my output are '\r\n', while in yours they are '\n'. I'm on Windows, as you can guess. I think it'll be useful, if line endings will be uniform: '\n'. Could you implement it?
Secondly, timestamp in header comment. Could you remove it from output?
Also, could you output in UTF-8 without \uXXXX escape sequences?
|
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.
Quote:
Originally Posted by eureka
Overall, looks like I'm far behind you in progress of my JS tool. I'll try to speed up the work. I'm now refactoring it to fit parsed JS into nice internal data structures and planning to use XLIFF format for output. XLIFF is a XML, so I can attach metadata (like, 'it should be wrapped into MessageFormat constructor call') to translatable strings.
|
No problem :-) -- this is volunteer work after all. And if we get the Java part onto transifex, there will again be enough work for translators anyway
. But it's good to see we're progressing...
Quote:
Originally Posted by eureka
About uploading to transifex. I've made it with some throw-away scripts. One for scanning of src/5.0.0/framework for .properties and crafting .tx/config. Then I've manually changed all slugs of resources in this config (slug's length shouldn't exceed limit of 50 characters, and I wanted to put sensible abbreviation of 'com.amazon.kindle.<...>' into these 50 characters). Then 'tx push'. For displaying nice names of resources in Transifex WebUI, I've made another script which changed resources's names with using of Transifex API.
I've deleted these scripts, but surely I can make them again. I'll wait for your response about line endings in tool's output before importing this output into repository and Transifex. |
That'd be really nice, yeah. Please make sure to also check in the tools then ;-) (about the line endings, see above. I don't think they're a problem, but if you disagree, let me know and I'll see what I can do).