Internationalized strings for keys in Dojo Storage

[guest]

if i am using german "Umlaut" aka e.g. Ü,ä, ö in the key for storage data (document = utf-8) i get a Message:

Invalid key given: keySebastianSchüRmann

keySebastianSchueRmann woirks quite well

[bradneuberg]

Dojo Storage has never been tested for internationalizatin. Right now I filter the hash key's based on a whitelist, which must be an alphanumeric english character. How does saving internationalized values work, versus keys? My first instinct is to mark this as a WONTFIX for internalization keys, since these are a programmer construct, but I'm open to being persuaded. Now, if you have problems with internalizationed values I'd be concerned. Can you test for me?

[peller]

It's not an internationalization issue, per se. Does Flash ActionScript? support unicode properties and do the flash bindings support unicode? is there any reason to impose this restriction?

[bradneuberg]

This bug was because I am whitelisting good input instead of blacklisting, so I only allowed something like the alphabet, numbers, underscores, etc. I always like to whitelist, but it makes internationalization difficult. We will probably have to just do a blacklist of characters that are not allowed in a string name, and then allow the rest. As far as I know it should be okay in Flash, though the Flash/JavaScript boundry _code_ munge the internationalized characters -- I don't know since I haven't tested it. The one thing that is important to me is that all the Dojo Storage providers have the same restrictions when it comes to keynames, whether it is Gears, Flash, WhatWG, etc., so if folks want to expand the possible characters you can have in keynames they need to check the big three (Gears, Flash, WhatWG) and find out what their restricted characters and internationalization issues are.

[bradneuberg]

That _code_ part should have read _could_, so the Flash/JavaScript boundry could munge internationalized characters.

[peller]

Understood. If you're running a check, I don't know of a good portable way to identify "alphabet" characters, and like you say, it's only asking for trouble with underlying platform issues. The alternative would be not to check and let errors be thrown if the key is invalid. Less arg checking has been the approach we've taken in core and dijit, as it usually results in less bloat and more flexible code.

As long as the requirement is defined clearly and consistently, I see no harm in marking wontfix. I wonder if there is a way we can make this more obvious in the docs?

[peller]

sounds like a wontfix? if there are no intentions of fixing this for 1.1, should we close now so we don't have to keep triaging? someone can reopen the issue.

[bradneuberg]

Marking as WONTFIX since it introduces too many issues per each of the storage providers, and I don't know if they can guarantee i18n.