View Single Post
Old 01-03-2012, 05:18 AM   #63
ixtab
(offline)
ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.
 
ixtab's Avatar
 
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
Quote:
Originally Posted by eureka View Post
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 View Post
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 View Post
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 View Post
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 View Post
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?!
ixtab is offline   Reply With Quote