I don't think the problem is specific to widgets. Any reusable code
modules will want to be able to encapsulate localizations. In a server
environment especially, that needs to be based on a variable at runtime.
  Can someone illustrate how this would work using i18n as a straight
module? Passing in a config seems to have an impact on the code as it is
loaded, not provide a choice each time the code is used. I'm thinking that
approach would only work in the case where we create separate sandboxed
environments based on locale.


On Tue, May 7, 2013 at 8:09 AM, Christophe Jolif wrote:

Yes, loading i18n as a straight module is a solution for application level
NLS keys but we need a solution for widgets. We can't expect each widget to
load i18n as a module and do his own work with it, we need a standard way
to deal with that. And as you said it is also true for dojo/css or whatever
CSS loader we will use. It will have to recognize which theme the users has
configured to be loaded.

I guess the problem with your proposed solution Bill is that it extends
AMD require function in what I suppose is a non standard manner? From what
I can read here http://livedocs.dojotoolkit.org/loader/amd#the-amd-api we
should be able to passe configuration as the first argument not the last
one?


On Fri, May 3, 2013 at 4:36 AM, Bill Keese wrote:

Thanks for all the responses. I agree that the server needs to support
multiple locales simultaneously, and if we pre-expand templates on the
server, that requirement expands to all the dijit widgets too.

Yes, we could use i18n() as a straight module to load locales explicitly,
or use that alternate syntax to dojo/i18n! where you specify a locale.
Maybe that's the best solution, although I was really hoping to use the
simple dojo/i18n! syntax, effectively treating locale as a global variable.

I don't think this issue is limited to i18n. Imagine how a dojo/css!
plugin could load the CSS for the current theme, or how loading the
"dijit/Tooltip" module would delegate to two separate modules depending on
if it were a mobile or desktop environment. Likewise for gfx,
high-contrast-mode, etc.

So I wonder if running on node should somehow "spawn a new environment"
for each browser connection. In AMD terms, that means calling require()
with the locale etc. specified, something like:

require([...], callback, {locale: "ja-jp", theme: "soria", platoform:
"tablet"});

Does something like that make any sense?

_______________________________________________
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

--
Christophe

_______________________________________________
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20130507/b5d544c2/attachment-0001.htm

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 22 | next ›
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedMay 1, '13 at 7:57p
activeJun 3, '13 at 11:01a
posts22
users6
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase