Opened 12 years ago

Closed 6 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 11 years ago by Adam Peller

Milestone: 1.11.2

comment:2 Changed 11 years ago by Adam Peller

Milestone: 1.21.4

comment:3 Changed 11 years ago by Adam Peller

Milestone: 1.4future

comment:4 Changed 11 years ago by 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).

comment:5 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by Adam Peller

Summary: Factor out i18n resources in mail demoImplement 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 11 years ago by Adam Peller

Summary: Implement or document "best practices" for mail demoImplement or document "i18n best practices" for mail demo

comment:8 Changed 9 years ago by Adam Peller

Owner: Adam Peller deleted

assigning all Dijit bugs to Bill

comment:9 Changed 7 years ago by bill

Priority: highlow

comment:10 Changed 6 years ago by dylan

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.