Quote:
Originally Posted by MatzeMatz
@eureka: what firmware version has your device? v5.0.0 or v5.0.1?
I also assume there are differences between the texts which have to be translated.
Is the current focus more on v5.0.0 or more on v5.0.1?
What are the plans for both versions?
Support only one of them? Or both together?
If yes, how do we handle the differences?
I wonder if it's possible to make some branches for that on transifex
|
I have v5.0.0 on my device. When I've named resources, I assumed that ixtab had this version too.
I don't know if there are any differences between 5.0.0 and 5.0.1 (concerning resources). I think, I'll create list of MD5 sums for any file, where resources was extracted from, and provide it. If someone then will make such a list for 5.0.1, we can find differing files and will know what was changed (if it was).
My plans are to support any future version of firmware. Any new (or differed) resource will be introduced on transifex with "tag" [5.x.x] . Other (not changed) resources will be taken as-is from translation for previous firmware. In Git repo these new/differed resources will go into src/5.x.x folder, where also some metadata will be stored to provide list of resources needed to be taken from another folder (of previous firmware version).
Quote:
Originally Posted by ixtab
@eureka: I checked the low_level_screens, and except for the shipping mode message, all seem to have been localized. Besides, I *think* that I had to reset my device to shipping mode lately (because I thoroughly demolished everything) while the german locale was installed, and I *think* that there was no text at all. (like only 1, 2, 3 images so you know what you should do, but no textual description). But I didn't pay close attention, so I may be wrong. Don't wanna wreck my Kindle right now just to verify this...
|
OK, it makes sense. In .po files there are same messages as on low-level screens and also numbers which are looked like a coordinates for messages positioning on low-level screen. So I think Amazon makes lifes of translators a little bit easier with it.
Quote:
Originally Posted by ixtab
BTW, did you check the /opt/amazon/low_level_screens/sq-AL/600x800/ pictures? WTF?
|
I don't know. sq-AL is Albanian, right? And the text on pictures is surely not Albanian. It's in English but with characters from foreign alphabets.
(Though naming of Albanian for a distorted language has a subtle implication for a user from Russian internets:
http://en.wikipedia.org/wiki/Olbanian_language)
Quote:
Originally Posted by ixtab
ok, final update for today.
I rewrote the parser to consider all compiled ResourceBundles (this does *NOT* include the very few .properties files). The unfiltered result is attached.
|
Looks good.
OK, so there are two tasks for now: dealing with resources in JavaScript files and in Java .class files. Which one would you like to take? I'll take another one then. (Anyway we'll end with one tool written in Python.)
Looking at output of your tool I've received an insight: there could be no need in original .js and .class files for constructing of translation.
JS strings are always in one format: there is one variable contained object with a strings and with other objects, which are contiaining strings or other objects... As in .properties we have name of object and it's keys ("PasswordDialogStringTable.passwordEntryTitle" or "bapp.strings.error.na"), we could construct JavaScript file from the ground-up. It will looks not the same as original file, but will return the same result.
Expression with function in waf/adviewer/scripts/resources.js evaluates into "var AdResources = {strings: {...} }" at the end, so it's pretty much the same format. And information about array as value of object's property in waf/browser/js/strings.js could be encoded in property name. These rare exceptions from common rule could be hard-coded in tool.
Though, I can't say definitely could .class files be reconstructed from .properties in output format of your new parser, I hope it is so.
The advantage is absence of Amazon code in repository.