Implement or document "i18n best practices" for mail demo

[bill]

What is this about exactly? In general dijit best practice is to do translation on the server, for things like tooltips and button / menu text. If you want you could change menu.html to menu.php and have it look up those values in PHP but I don't see a reason to do it in javascript. If you do want to demonstrate client lookup should probably be a separate demo (or just sample code somewhere).

[bill]

Actually, I need to revise my statement above.

I meant to say that typically the server has separate versions of mail.html, one per language. That's good for a number of reasons:

• that's how translation houses work (you send them a set of HTML files and they return a translated set)
• minimizes processing time on the server; ideally server can send down static files.
• less obfuscated HTML
• minimizes the number of XHR requests, and the amount of data passed down to the client

Anyway, I'd need a compelling reason to change the mail demo in this way.

[Adam Peller]

Yeah, I'm not sure client-side resources are appropriate either. (Translation houses can translate JS bundles too, and unlike say JSP substitutions, dojo.i18n doesn't involve processing time on the server, but I agree with the latter two points.) I think the thought was that we ought to apply some sort of i18n scheme, whatever the Dojo way is, to our sample app. I tend to agree that server-side translation makes sense. I'll change the title accordingly. We should have covered other aspects of the widgets. We could just provide a couple of translated HTML files, or perhaps this isn't worth doing.

We do have a couple of hard-coded strings, like a confirm() box that probably should be fixed.

[Adam Peller]

assigning all Dijit bugs to Bill

[dylan]

This won't get done for 1.x. Closing it as wontfix.