12-30-2011, 05:08 PM | #46 |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
/opt/amazon/ebook/config/locales/ files
So, a bit about the files found in /opt/amazon/ebook/config/locales/
All files in there should be "standard" Java properties files (very similar to Windows .ini files). Because these files are evaluated *NOT* only by Java, but also by the built-in "langpicker" parts, you may want to be extra-cautious about their format. Even slightly "strange" formats *may* have been a cause for fuckups, as reported earlier in this thread. So, to be on the safe side: - let every line be a line in the "key=value" format. - use only Unix line separators, and do not have blank lines in the file. - make sure the last line in the file is terminated by a newline. This may be over-cautious, but see above. So, the general format of an entry (using a concrete example) is: Code:
locale=pl locales.supported=pl-PL display.name.pl-PL=Polski posix.id=en_US.UTF-8 Code:
locale=<LOC_LANG> locales.supported=<LOC_LANG>-<LOC_REG> display.name.<LOC_LANG>-<LOC_REG>=<NAME> posix.id=<POSIX_ID> * LOC_REG is the specific variant (e.g. the region). For language and region codes, you can find as much information as you want. I'll stick with https://wiki.mozilla.org/L10n:Locale_Codes and http://docs.oracle.com/javase/1.5.0/...il/Locale.html, and let you find your way from there. In almost all applicable cases, the language is written in lower case, and the region is the same as the language, but in uppercase. If this is *not* the case for your particular localization needs, you will certainly know about the subtleties. locale is required, and must be set to the language code. locales.supported is required, and must be set to the concrete region code this locale supports. This argument *may* (presumably) be present more than once. display.name.<LOC_LANG>-<LOC_REG> must be present for each supported region, and its value is the string identifying that locale to the user in the user interface (see above for an example). posix.id is, in principle, optional, and refers to the POSIX id of the chosen locale which is used in the underlying system. It it is not set, it will be determined from the abovementioned settings. HOWEVER, not all valid locales are available in the Linux system underlying the Kindle, so is is strongly recommended to always set this value to "en_US.UTF-8". The above example shows all of these settings. While there is no particular file naming to observe, I strongly recommend to use <LOC_LANG>_<LOC_REG>.properties, so for example "pl_PL.properties" for the example above. Last edited by ixtab; 12-30-2011 at 05:32 PM. |
12-30-2011, 06:22 PM | #47 |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
... and finally, the Javascript subsystem.
Attached is a file which I believe contains the localizable strings of the JS subsytem. Again, I think this could serve as a basis on which to start producing localizations. For an idea about how all of these parts *could* play together, see my next post. |
Advert | |
|
12-30-2011, 07:16 PM | #48 |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Bringing it all together
So I made a few posts concerning the individual parts of the Kindle Touch. Finally, here is an overview about how they could all work together, and how all of that could be bundled in a single file:
Suppose we're interested in the german (de_DE) translation, which has not been installed on the Kindle yet. Then the bundle would contain: - /opt/amazon/ebook/config/locales/de_DE.properties: file containing the description of the locale, and enabling it in the first place. - /usr/share/locale/de : directory containing "low-level" strings, such as the ones displayed when connecting the Kindle. (USB mode, restarting etc.). This is what is referred to as "blanket" in previous posts. - /opt/amazon/ebook/lib/locale-de_DE.jar: file containing localization of a major part of the UI, especially for actually reading ebooks. This is what is referred to as the "Java" part is previous posts, and what much of the discussion so far has been referring to. - /var/local/locale/de-DE/: This is where the JavaScript-related parts referred to in my last message would go to. Because there is no "built-in" method for having the Kindle choose a correct version of these, I propose an upstart script which would automatically select the correct folder, use a "mount --bind" command to "override" the unlocalized strings with it. That script doesn't exist yet, but the effect should be along the lines of Code:
mount --bind /var/local/locale/de-DE /usr/share/webkit-1.0/pillow/strings |
12-31-2011, 03:32 AM | #49 | |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Quote:
Code:
lipc-set-prop -s com.lab126.pillow interrogatePillow '{"__id__": 0, "pillowId": "search_bar", "replySrc": "", "function": "document.querySelector(\".input-container label\").textContent=\"hi from a l10n possibility\""}' So, instead of bind mounting, upstart script could apply localized strings programmatically. More tedious work should be done to implement it, but it's less obtrusive. |
|
12-31-2011, 10:57 AM | #50 | ||||
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Quote:
Quote:
Quote:
Quote:
|
||||
Advert | |
|
12-31-2011, 11:26 PM | #51 | |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Quote:
Long story short: create '/usr/share/webkit-1.0/pillow/strings/locales/en-us/' directory, copy there localized strings files, restart pillow (or select language again) and then (given that current/selected locale is en_US) you will see localized messages. I hope you'll get the point. On locale change event (which is emitted, when user changes language) all Pillow apps are reloaded, and so their's resources. This is could works for WAF apps also, as this mechanism is provided by underlying WebKit library. Last edited by eureka; 12-31-2011 at 11:28 PM. Reason: clarification |
|
01-01-2012, 04:20 AM | #52 |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Wow, this is great news! So there actually *is* a simple and non-intrusive way to add localization to pillow/WAF apps.
Thanks for researching this! Out of curiosity, how did you find this out? |
01-01-2012, 05:45 AM | #53 | |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Quote:
Since you are the maintainer of the projects, could you upload the en_US versions of the blanket *.po's? I already have the german translation finished for these :-) Ahh, my bad. You're right. |
|
01-01-2012, 11:27 AM | #54 | |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Quote:
As you was the initiator of localization, I've also added you as a maintainer of all Kindle Touch projects. |
|
01-01-2012, 11:36 AM | #55 |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Looking at strings, contained in relevant executables and shared libraries; looking at debug level logs; looking at parameters of called functions, while debugging pillowd by gdb; and, finally, looking at strace output (scanning strace output was indeed last but, surprisingly, completely sufficient for discovering algorithm of searching for localized resources).
|
01-01-2012, 12:28 PM | #56 | |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Quote:
In the mean time, I have been playing around with the "blanket" one a bit. I was initially a bit surprised by the result of "tx --auto-remote", because the folder structure does not make sense at all. So I recreated the entire thing from scratch with a "correct" folder layout, removed the resources you created (fortunately it's only 3 of them), and checked in the stuff again. After checking out the project again in a different directory, it turns out that the structure was again screwed up. So I was blaming you for something which isn't your fault... sorry In any case, we now know that for that tool to make sense, it's best to also provide the .tx/config, so people get a meaningful layout of the files locally. I only realized this now, and also that you keep the master copy in git. So instead of using my own directories locally, I can just sync to the git one :-) By now, I hope I cleaned up the mess I had created. |
|
01-01-2012, 01:52 PM | #57 | |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Quote:
Sorry for not clearing it in time. It takes away use-cases for '--auto-remote' (as you've found out, '--auto-remote' use it's own directory structure). '--auto-local' should be avoided at all, as it doesn't include all needed info at updating .tx/config. Instead, I've crafted config manually. It's easy. Would you like to register on Bitbucket and PM me your username? Then I'll give you admin rights to kindle-touch-l10n repository (with commit rights included). I imagine translation workflow as following:
That said, I wouldn't mind if youl'll add your (existing or new) tools written in Perl (if they will be pretty well commented). Release actions could be automated up to a point when they're executed by bot on some server and then compiled updates with translation pack are provided via some web-site. This is how I want it to be, but don't know yet if I can do it. |
|
01-01-2012, 02:07 PM | #58 | |||
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Quote:
Quote:
Quote:
There's one final issue that I'm having with the JS part: the format that is used is relatively standard, but it's still executable JS which transifex can't make sense of. Would "ripping out" the strings into a .properties file make sense, so that they can be translated using the normal method? Or do you see an alternative? (short of simply editing the JS files directly). |
|||
01-01-2012, 07:55 PM | #59 |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
A note to translators
(This post is also linked from the transifex pages for people which may have reached the projects somehow else than through this forum.It is recommended to also read the very first post of this thread, which is continuously updated to reflect the latest important changes, and provides general useful information).
There are four individual subprojects on Transifex:
Feel free to start a translation for your language. You need to apply for ALL 4 subprojects individually! Because many translations have been (partially) requested, but then "abandoned", please make sure that you are actually willing to perform the translation work, and apply to all subprojects. Translation requests covering only a subset of the resources (i.e., not all subprojects) may be rejected. General guidelines:
If you want to use transifex' command-line tool, make sure that you use the .tx/config file provided on the git repository!!! More information in this post. Information below is slightly outdated, but important nevertheless. Subsequent efforts have reduced the risk of wrong translations. Still, you should be very careful with your edits. Here's an example of how easy it is to screw up (there are also some hints on how to detect and fix such problems). VERY IMPORTANT: the resource files have been extracted automatically and DO contain things which are actually NOT meant to be translated (this is particularly true for the "framework" resources). In the worst case, translating these could break functionality! For some parts, this is obvious, like URLs, command-lines etc. For others, it is not so obvious (for example there are resources named "east", "west" etc.). If in doubt, either do not translate an item, or simply copy the original string. You can always come back if you see that you still have some english strings on your Kindle. Examples: do NOT translate the strings "east", "west", "north", "south", "tap", "title", "author", "collection", "mostrecent". If you do, you WILL break functionality. There are other strings like this as well. As a general rule of thumb, treat every entry consisting of a single lowercased word with caution, and do not translate it initially. There are a few exceptions to this rule (e.g. TTS resources like "slower", "faster"). But you will save yourself from a lot of headaches if you don't translate these initially, but only after testing and verifying that such strings appear verbatim on the device. I'm sorry for this inconvenience, but as said, the Strings have been extracted automatically. I do not have the resources to go over every single item, so use common sense. Last edited by ixtab; 04-24-2012 at 11:19 PM. |
01-02-2012, 08:22 AM | #60 | |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Quote:
One note: this properties should be uploaded to transifex with type MOZILLAPROPERTIES. Format of Mozilla .properties is same as Java .properties, but in Mozilla .properties non-ASCII values are stored as UTF-8 strings, not as Unicode-escaped sequences. It's more friendly for reader of .properties. I've commited POC of tool for extracting JS strings. For now, it's just searching for strings in given file and dumps internal representation of found strings. Each found string is represented as tuple: Code:
(<id of string>, <value of string>, <starting position of string in JS file>, <ending position of string in JS file>) With this information it could be possible to convert JS file into two: JS template and .properties, like: Code:
// strings.js var a = 'a'; var b = { x = 'x'; y = 'y' }; Code:
// strings.template.js var a = '{{a}}'; var b = { x = '{{b.x}}'; y = '{{b.y}}' } Code:
# strings.properties a=a b.x=x b.y=y What do you think about it? |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Kindle 3 localization | JirkaS | Kindle Developer's Corner | 287 | 05-20-2018 10:08 AM |
[K3] Physical keyboard localization | Sir Alex | Kindle Developer's Corner | 112 | 05-19-2018 11:23 PM |
Kindle 4 (no touch) GUI Localization | Sir Alex | Kindle Developer's Corner | 43 | 09-13-2013 07:19 AM |
Keyboard localization (hack) | Sir Alex | Kindle Developer's Corner | 72 | 04-16-2013 03:05 PM |
Kindle 3, Nook Simple Touch, Kobo Touch and Libra Pro Touch | jbcohen | Which one should I buy? | 4 | 06-18-2011 07:58 PM |