Opened 13 years ago
Closed 8 years ago
#5605 closed defect (wontfix)
Implement or document "i18n best practices" for mail demo
Reported by: | Adam Peller | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | future |
Component: | Dijit | Version: | 1.0 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
Change History (10)
comment:1 Changed 13 years ago by
Milestone: | 1.1 → 1.2 |
---|
comment:2 Changed 13 years ago by
Milestone: | 1.2 → 1.4 |
---|
comment:3 Changed 13 years ago by
Milestone: | 1.4 → future |
---|
comment:4 Changed 13 years ago by
comment:5 Changed 13 years ago by
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.
comment:6 Changed 13 years ago by
Summary: | Factor out i18n resources in mail demo → Implement or document "best practices" for mail demo |
---|
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.
comment:7 Changed 13 years ago by
Summary: | Implement or document "best practices" for mail demo → Implement or document "i18n best practices" for mail demo |
---|
comment:9 Changed 8 years ago by
Priority: | high → low |
---|
comment:10 Changed 8 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
This won't get done for 1.x. Closing it as wontfix.
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).