View Single Post
Old 01-03-2012, 05:18 AM   #62
eureka
but forgot what it's like
eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.
 
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
Quote:
Originally Posted by ixtab View Post
I have come up with pretty much the same approach, see the attached file...

If have also tested mine with the browser part, which uses a slightly different format (multiple vars, arrays etc.) There is also the audio player ui which uses a MessageFormat *inside* the "variable". I fell asleep after doing and shortly verifying this, but take a look at the attached files and let me know if it makes sense...
It contains the source code (is it readable enough?... it's still lots of regexes) as well as a proposed output (and folder structure).
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.

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.

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 ). 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).

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)

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.
eureka is offline   Reply With Quote