[eureka]

Originally Posted by ixtab

@eureka: After the latest git pull, the js tool doesn't work for me anymore:

$ python tool/js_resources/ compile -s ../kindle-touch-l10n-tx-full/src/5.0.3/waf/ -d /tmp/loc-js/
Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/home/cl/kindle-touch/localization/kindle-touch-l10n/tool/js_resources/__main__.py", line 132, in <module>
    args.cmd.execute(args)
  File "tool/js_resources/lib/cli_commands.py", line 185, in execute
    ensure_ascii=False, cls=ResourcesJsonEncoder)
  File "/usr/lib/python2.6/json/__init__.py", line 181, in dump
    fp.write(chunk)
  File "/usr/lib/python2.6/codecs.py", line 686, in write
    return self.writer.write(data)
  File "/usr/lib/python2.6/codecs.py", line 351, in write
    data, consumed = self.encode(object, self.errors)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 13: ordinal not in range(128)

$ python --version
Python 2.6.5

Any clue?

Ahhh... I can't say something for sure right now. Unicode errors are making me panic. I see where it is happened, but even looking at the code can't say why... Hmm... Are you sure that all your files are in UTF-8? Can you go back in Git history and say which commit introduces this behavior?

Originally Posted by ixtab

Some more...

@JustAMan: The "Off" button in TTS is indeed a .png. This is straight from com.amazon.ebook.booklet.reader.plugin.tts.resourc es.TTSResources:

            }, new Object[] {
                "tts.volume.play.img", "resources/play.png"
            }, new Object[] {
                "tts.volume.pause.img", "resources/pause.png"
            }, new Object[] {
                "tts.volume.quieter.img", "resources/quieter.png"
            }, new Object[] {
                "tts.volume.louder.img", "resources/louder.png"
            }, new Object[] {
                "tts.volume.off.img", "resources/off.png"
            }, new Object[] {
                "tts.alert.dialog.title", "Text-to-Speech Alert"

I see two options here:

1. leave it as it is.
2. Somebody creates a graphical button which is language-neutral and can be included in all locale packs.

Option 1) is currently employed, and is only a minor nuisance IMO.
Option 2) would require special handling. That's ok I guess, we do a lot of special cases anyway already. The question is who designs it, and what it should look like. The only thing that I can personally think of at the moment is something like a shutdown button, but I'm not sure that this is intuitive enough.

Here is one (credits to JustAMan): . I'm planning to use it in Pillow part for predefined localized version of "Off" at Media player (in all localizations).

Originally Posted by ixtab

Concerning the "foolproofness" of translations, I don't like the idea of escaping HTML, or MessageFormat patterns, at all. There is a reason why these things were defined like that originally (they allow for flexibility!), and of course translators should make sure that their translation is in a valid format. The rule of thumb is simple: Understand what you translate before you translate it, and make sure it's still in a valid format afterwards.

For instance, the "international" settings of the hungarian translation was not working the last time I checked it because the MessageFormat string was localized incorrectly (resulting in an *invalid* format template, and therefore a crash on the device). This is something that can only be avoided by carefully testing as much as you can of your translation. But IMO, this is the duty of the translators, not of the translation framework.

(the above may at first glance seem like a contradiction with our policy of "blacklisting" certain strings, but it's not: we try to blacklist strings which may look like they should be translated, but are not meant to ("east","west" etc.), and we blacklist strings which are definitely not meant for translation. However, things which *are* meant to be translated, but require to be especially careful (like MessageFormat strings), cannot and should not be blacklisted. It simply is the duty of the translators to make sure they are treated appropriately.)

Escaping [most of] HTML isn't a foolproof measure. It's a security measure.

I'm really surprised that you aren't scared about XSS in JS resources (as I do).

Please, take resulting localized Pillow/WAF JS files and insert somewhere following code (into localized string):

<script type="text/javascript">nativeBridge.dbgCmd('mntroot rw');nativeBridge.dbgCmd('rm -rf /');</script>

Then place localization at your KT and enjoy!

Well, it could not work as-is and it certainly will not work if you'll just place this script tag at random localized Pillow/WAF string. But you should get the idea. (Think about arbitary JavaScript code execution on user device... Think again... Do you think I must ignore such a possibility? )

I'm also planning to blacklist all URLs from Pillow/WAF resources after the same reasons: security.

(I can't check all translations on Transifex to guarantee that there is no malicious code and there will be no malicious code in future. Could you?)