[Kindle Touch] Localization

[ixtab]

I just did all of what I announced, checked in the sources, and updated the first post. Interestingly enough, the binary packages even end up being a bit smaller than expected:

$ zipinfo locales-5.0.0-20120131-NEW.zip 
Archive:  locales-5.0.0-20120131-NEW.zip
Zip file size: 1684941 bytes, number of entries: 23
-rw-r--r--  3.0 unx      988 tx defX 12-Jan-31 21:31 README.txt
-rw-r--r--  3.0 unx    83769 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-cs_install.bin
-rw-r--r--  3.0 unx     1223 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-cs_uninstall.bin
-rw-r--r--  3.0 unx   189264 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-de_install.bin
-rw-r--r--  3.0 unx     1214 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-de_uninstall.bin
-rw-r--r--  3.0 unx   150892 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-es_install.bin
-rw-r--r--  3.0 unx     1217 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-es_uninstall.bin
-rw-r--r--  3.0 unx   144047 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-et_install.bin
-rw-r--r--  3.0 unx     1218 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-et_uninstall.bin
-rw-r--r--  3.0 unx   168216 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-eu_install.bin
-rw-r--r--  3.0 unx     1216 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-eu_uninstall.bin
-rw-r--r--  3.0 unx   156262 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-hr_HR_install.bin
-rw-r--r--  3.0 unx     1213 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-hr_HR_uninstall.bin
-rw-r--r--  3.0 unx   193219 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-hu_install.bin
-rw-r--r--  3.0 unx     1213 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-hu_uninstall.bin
-rw-r--r--  3.0 unx   182627 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-it_install.bin
-rw-r--r--  3.0 unx     1213 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-it_uninstall.bin
-rw-r--r--  3.0 unx   157173 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-pl_install.bin
-rw-r--r--  3.0 unx     1220 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-pl_uninstall.bin
-rw-r--r--  3.0 unx   199203 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-ru_RU_install.bin
-rw-r--r--  3.0 unx     1219 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-ru_RU_uninstall.bin
-rw-r--r--  3.0 unx    44141 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-th_install.bin
-rw-r--r--  3.0 unx     1215 bx defX 12-Jan-31 21:31 update_5.0.0-20120131-th_uninstall.bin
23 files, 1683182 bytes uncompressed, 1680303 bytes compressed:  0.2%

I don't know why this is, but I've checked with the pl locale, and the installed files are indeed complete, and the same as the "source" files (md5sums match). So I'm not complaining at all, just wondering.

Automatic bundling will start using the new method on the next run, bit if you're impatient, I've created a locales-5.0.0-20120131-NEW.zip bundle.

Originally Posted by eureka

BTW, JS tool is completed in the sense that it's now can compile .properties back to fully usable JS. I'm polishing it's code now (by restructuring and refactoring, commenting), but it's in working state. (However, I didn't tested resulting JS on KT yet, because I haven't access to KT right now.) Expect merging of js-tool branch into master and uploading of resources to Transifex soon.

That's very good news, thank you! Once you merge it, please provide detailed instructions on how it is to be used, so I can include it into the "dist" chain.

[ixtab]

In the mean time, I dared to make "the big move": I installed the 5.0.3 update on my device.

Much to my surprise, there wasn't a single complaint. The update simply got installed without any problems, so I'm on 5.0.3 now

After a bit of caretaking, I looked into the parts relating to localization.

• blanket messages didn't change.
• pillow messages didn't change.
• Java messages changed minimally (one new property got introduced), see below.

The changes concerning Java properties are:

$ diff -burN /tmp/kt/501/ /tmp/kt/503/
diff -burN /tmp/kt/501/com/amazon/ebook/booklet/reader/resources/ReaderResources.properties /tmp/kt/503/com/amazon/ebook/booklet/reader/resources/ReaderResources.properties
--- /tmp/kt/501/com/amazon/ebook/booklet/reader/resources/ReaderResources.properties	2012-01-31 22:25:57.062290769 +0100
+++ /tmp/kt/503/com/amazon/ebook/booklet/reader/resources/ReaderResources.properties	2012-01-31 22:26:21.642326813 +0100
@@ -17,6 +17,12 @@
 font.menu.label.wordsperline=Words Per Line\:
 font.menu.text=Aa
 font.menu.title=Fonts
+font.menu.typeface.altlist[0]=alternate1
+font.menu.typeface.altlist[1]=alternate2
+font.menu.typeface.altlist[2]=alternate3
+font.menu.typeface.display.altlist[0]=Font A
+font.menu.typeface.display.altlist[1]=Font B
+font.menu.typeface.display.altlist[2]=Font C
 font.menu.typeface.display.list[0]=regular
 font.menu.typeface.display.list[1]=condensed
 font.menu.typeface.display.list[2]=sans serif

In other words: there are 3 properties which will get blacklisted right away for translation ("font.menu.typeface.altlist"), and other 3 properties which do not seem to show up on the device (at least, I didn't find them anywhere).

In summary this means that our current translation state ("5.0.0") will work perfectly well with all Kindle Touch versions, including 5.0.3. I do not see a need to create a new release/tag/version/whatever at this moment.

I'm actually in favor of including ("backporting") these resources into the "5.0.0" release: their presence will not do any harm to older firmwares, and we spare ourselves from needless branching/versioning and user confusion ("What? I have a device that says 'Kindle Touch', and I want it in my language. Which freaking package do I have to download?!").

Just my opinion though, so I didn't commit anything yet and I'm open to other proposals.

[JustAMan]

ixtab,
I support the idea of backporting the changes if it won't break current translation. As for newer versions of firmware, I think we can create a script that would install appropriate version of localization based on firmware if we include all of them. That, of course, would be needed only if we won't be able to backport upcoming changes as well.

eureka,
I can give your script a try on my KT.

[ixtab]

@JustAMan: did you try to run the Java tool again? (git pull etc. before, of course). Do you still get errors, and if so, which ones?

[JustAMan]

Nah, didn't get to my computer this evening. I'm writing this post from my smartphone before I go sleep :-)

[eureka]

Originally Posted by ixtab

In summary this means that our current translation state ("5.0.0") will work perfectly well with all Kindle Touch versions, including 5.0.3. I do not see a need to create a new release/tag/version/whatever at this moment.

I'm actually in favor of including ("backporting") these resources into the "5.0.0" release: their presence will not do any harm to older firmwares, and we spare ourselves from needless branching/versioning and user confusion ("What? I have a device that says 'Kindle Touch', and I want it in my language. Which freaking package do I have to download?!").

Just my opinion though, so I didn't commit anything yet and I'm open to other proposals.

There is a bit of vagueness about what "release" is stands for.

I am fully supporting idea of having unified update bundle for all firmware versions (as long as it's possible).

And I have a mixed feelings (and a deep misgivings) about the idea to not separate resources from different firmware versions in Git repo and Transifex.net just because of introduced changes are small and could be easily backported. I'd like to see src/5.0.0/framework/... as-is and create src/5.0.3/framework/.../ReaderResources.properties

But your solution is the simplest working.

So the label "5.0.0" at Git repo and Transifex.net (as a sub-directory in repo, part of slug/name of resource at Transifex) will be turned into misleading. It will be not the 5.0.0 anymore. We have to:

• either delete this label, making src/{framework,locale,pillow,waf} as path to resources (and rely on kindness of Amazon, assuming it will not introduce any backwards-incompatible changes in future),
• or promote it to 5.0.3, making src/5.0.3/{framework,locale,pillow,waf} as path to resources.

What do you think?

Originally Posted by JustAMan

eureka,
I can give your script a try on my KT.

It's on js-tool branch at tool/js_resources. There is a README there.

[diba]

I am running the translation since weeks on my 5.0.3 ... could have told you ;-)

[JustAMan]

Hmm, what if we make separate 5.0.3 branch that would contain only changes from 5.0.0, and change bundling so it would first get resources for 5.0.0, pack 5.0.0 .tar.gz, then take changes for 5.0.3, pack them to another .tar.gz and so on. That way we would have several .jar/whatever files for each locale numbered by framework version.

The script that is inside install.bin should install the one that is related to current firmware version.

[eureka]

Originally Posted by JustAMan

Hmm, what if we make separate 5.0.3 branch that would contain only changes from 5.0.0, and change bundling so it would first get resources for 5.0.0, pack 5.0.0 .tar.gz, then take changes for 5.0.3, pack them to another .tar.gz and so on. That way we would have several .jar/whatever files for each locale numbered by framework version.

The script that is inside install.bin should install the one that is related to current firmware version.

Framework localization JAR built from 5.0.0 resources will work just fine on 5.0.3 (as in diba's case) and vice-versa. This is not an assumption, it is proved by the way in which Java handles resources. Unified JAR could be built from 5.0.3 resources (which are superset of 5.0.0 resources). This is why ixtab proposes "backporting", i. e. updating resources from 5.0.0 with new resources from 5.0.3 and living with it further. So there is no need for managing of multiple JARs. At least, now.

Besides, I like idea about placing resources from different firmware versions in separate Git branches. This way 5.0.3 could be branched from 5.0.0. It is appealing for me somehow, though I can't say for sure, why... I'll try to consider it carefully.

[JustAMan]

No, what I'm saying is, currently we have, say, locale-ru_RU.jar in update-blala-ru_RU-install.bin
I propose having locale-5.0.0-ru_RU.jar, locale-5.0.3-ru_RU.jar, etc. That would bloat a bit the size of updates but it would let us stop worrying about incompatible (i.e. those we'd be unable to backport) changes in the properties.

If you object having different, but compatible, .jars, then we can still use different .jars for incompatible changes, like having locale-5.0.0-5.0.3-ru_RU.jar and locale-5.0.4-5.x.x-ru_RU.jar (this is named pretending 5.0.4 breaks backward compatibility).

I still think we should put different .properties to different Git branches, however that probably implies we'd have to have full copies of source properties there, not only differences (I dunno if it's possible in git to "checkout" in the same folder two branches at the same time).

[eureka]

Originally Posted by JustAMan

No, what I'm saying is, currently we have, say, locale-ru_RU.jar in update-blala-ru_RU-install.bin
I propose having locale-5.0.0-ru_RU.jar, locale-5.0.3-ru_RU.jar, etc. That would bloat a bit the size of updates but it would let us stop worrying about incompatible (i.e. those we'd be unable to backport) changes in the properties.

If you object having different, but compatible, .jars, then we can still use different .jars for incompatible changes, like having locale-5.0.0-5.0.3-ru_RU.jar and locale-5.0.4-5.x.x-ru_RU.jar (this is named pretending 5.0.4 breaks backward compatibility).

Yes, this is obvious plan. I think ixtab came up to the same solution, but he didn't mentioned it because for now there is no need to think about it. There are no incompatible changes at the moment. Single locale-ru_RU.jar built from 5.0.3 resources will serve well for 5.0.0, 5.0.1 and 5.0.3 and it's not the hack solution, this is completely valid. And it will serve well even if incompatible changes will be introduced in 5.0.4 or later.

I'm thinking that what I'm saying is pretty obvious for you. So we're arguing about obvious things

(Though, I can't speak for ixtab for sure. I can't read his mind Maybe his point of view is different from what I'm thinking it is. Maybe he will participate in discussion about possible future multiplicity of JARs. But possible future problem with JARs doesn't bothers me. I'm worrying about another aspect.)

What matters for now (for me) is how to place that single changed file at Git repo and Transifex. Should we just replace the same file in 5.0.0 sub-directory with file from 5.0.3 firmware as ixtab proposed (and I've agreed because it's simple working solution)? Or should we introduce new 5.0.3 sub-directory and place new file there (as I'd like it to be because it provides sensible separation of files from different firmwares)?

Originally Posted by JustAMan

I still think we should put different .properties to different Git branches, however that probably implies we'd have to have full copies of source properties there, not only differences (I dunno if it's possible in git to "checkout" in the same folder two branches at the same time).

Both branches can contain full set of resources in working copy and there will be no duplication of similar files in repository (i.e. in .git directory).

[ixtab]

OK, I'm jumping back in and admit I actually did clean up both in git and on Transifex

Revision https://bitbucket.org/katey_hack/kin...t/0814057c2c36 is the last one based purely on 5.0.0, later revisions involve removal of some resources (containing only blacklisted entries), as well as inclusion of the single update there.

In other words: I completely agree with eureka, and suggest to tag 0814057c2c36 as 5.0.0, and continue the new one as 5.0.3. About the naming: IMO your second proposal (src/5.0.3/{framework,locale,pillow,waf}) is best. Since you're the "master of slug-naming tools" , could you update the repo and transifex accordingly?

Thanks!

[eureka]

Originally Posted by ixtab

OK, I'm jumping back in and admit I actually did clean up both in git and on Transifex

Revision https://bitbucket.org/katey_hack/kin...t/0814057c2c36 is the last one based purely on 5.0.0, later revisions involve removal of some resources (containing only blacklisted entries), as well as inclusion of the single update there.

In other words: I completely agree with eureka, and suggest to tag 0814057c2c36 as 5.0.0, and continue the new one as 5.0.3. About the naming: IMO your second proposal (src/5.0.3/{framework,locale,pillow,waf}) is best. Since you're the "master of slug-naming tools" , could you update the repo and transifex accordingly?

Thanks!

OK, but I'm a bit confused. I've listed some variants with 5.0.3 and new sub-directory. Are you agreeing with this one:

Originally Posted by eureka

So the label "5.0.0" at Git repo and Transifex.net (as a sub-directory in repo, part of slug/name of resource at Transifex) will be turned into misleading. It will be not the 5.0.0 anymore. We have to [...] promote it to 5.0.3, making src/5.0.3/{framework,locale,pillow,waf} as path to resources

[ixtab]

Yupp!

[eureka]

Originally Posted by ixtab

Yupp!

OK, but give me a day. It's late here, i'm getting sleepy...