Quote:
Originally Posted by eureka
Ohhh, duplicating efforts is no good. I think, this is a lack of communication from my side, as I didn't shared my plans before starting work. Maybe, a wiki page on Bitbucket with a list of needed tools and other plans will be useful. Then each of us could pick a field of operation and add his name after each tool/actions he is currently working on.
|
Not a bad idea. Would you set up a skeleton for it?
Quote:
Originally Posted by eureka
So, I've took a look on your code (btw, you should commit it without doubt) and it's results. All is OK for me (comments were useful, thanks). I think, I'd prefer if you'll continue your work and finish it, so we'll can use your tool. How do you feel about it? I'll not remove my POC (yet), as I want to see if I could parse those WAF string you've mentioned. But I'll not make it in complete usable tool, if you'll agree to finish your tool.
Also, I'd suggest you taking a look at available JS parsers for Perl, it could be easier to work with parse tree, than with regexp matching results. (I don't know if there are any JS parsers for Perl, just suggesting another one way).
|
I'm ok with continuing my stuff. In any case, don't remove yours -- it only takes a few bytes of space and can still be useful later on. Maybe as the tools directory grows, we can simply put a README with explanations in it.
I also totally agree that actually parsing the JS is a much better idea, because it's much more robust. The current script heavily depends on a "uniform" layout of the files -- which all currently abide to -- but may well break in the future. I'll look into it, but don't hold your breath...
Quote:
Originally Posted by eureka
I've seen that you've changed wifi_wizard_dialog_strings.js by removing WifiWizardDialogStringTable_{pre,post}_unable variable and adding it's contents into appropriate strings below. While it's a understandable and suitable approach, I'd like to see these strings as separate resources. (BTW, my POC handles this situation very well  ).
|
This is a misunderstanding

The pre_ and post_ things are NOT there in the original files, but rather were already factored out by me when I thought we'd have to translate stuff manually. The file in the last zip actually IS the original ;-) -- should've made this clearer though.
Quote:
Originally Posted by eureka
On repo directory structure for Pillow and WAF apps localizing: I'd like to see it as following:
Code:
src/5.0.0/pillow
original/
strings/
wifi_wizard_dialog_strings.js
wifi_wizard_dialog_strings.tjs
...
locales/
en_US/
strings/
wifi_wizard_dialog_strings.properties
...
de_DE/
strings/
wifi_wizard_dialog_strings.properties
...
Code:
src/5.0.0/waf
original/
browser/
js/
strings.tjs
strings.js
store/
strings/
strings.tjs
strings.js
locales/
browser/
locales/
en_US/
js/
strings.properties
de_DE/
js/
strings.properties
store/
locales/
en_US/
strings/
strings.properties
de_DE/
strings/
strings.properties
And, on KT it would go into '/usr/share/webkit-1.0/pillow/locales', '/var/local/waf/browser/locales', '/var/local/waf/store/locales', ...
This is somewhat obscure and multilevel hierarchy, but the idea under it is simple: keep original files in separate directory, try to mirror original hierarchy as much as possible and place 'locales' directory into the 'root' directory of app (pillow, browser, store etc)
|
Agreed, with one minor suggestion. Remove the intermittent "locales", IMO it is superfluous. I guess that a directory containing "original","en_US","de_DE" etc. is easier (and 'original' cannot be confused with a locale anyway).
Quote:
Originally Posted by eureka
One new note. There are also translatable resources that are missed in our plans: Kindle User Guide and low-level screens.
On locale change langpicker.so somehow founds appropriate KUG (Kindle User Guide) in /opt/amazon/kug and copies it at /mnt/us/documents. Also it's chooses localized low-level screens from /opt/amazon/low_level_screens/locale_CODE.
KUG is in AZW format (i.e. in MOBI), it should be possible transform it to XHTML and transifex supports translating of XHTML.
But with low-level screens (.png images) there is no direct solution. I've thought about converting it to base64, then placing resulting string in one of file that is supported by transifex and creating instruction for translators how to decode it and encode back after translation. The biggest image is only about 20K in .png and 32K encoded in base64, so size isn't problem, I assume.
|
Yeah, that certainly is yet another problem, but I suggest to leave it for later. We have anough other things to do at the moment... BTW, which png files do you mean? Can you give an example?
If figured out a much more serious problem yesterday. You may have realized that I created two new resources on transifex. For some obscure reason, these files had not been found by my extraction tools, and I manually created the properties files. Now, there is *at least* one further resource: com/amazon/ebook/booklet/reader/resources/ReaderResources.class in opt/amazon/ebook/lib/ReaderSDK-impl.jar
This one contains many resources as well. The real problem is that the resource (which is a ListResourceBundle) also contains ARRAYS of Strings which need to be translated. PropertyResourceBundle doesn't support arrays, though. So in the end, in order to properly translate these, we MUST create a ListResourceBundle class instead of a flat properties file.
Any ideas?!