Create the i18n plugin. It should initially behave like dojo's and RequireJS's i18n plugin. (Later, we'll likely add a feature to prefetch / inject strings that may be stored and/or retrieved by an alternative mechanism. For instance, a project could use this feature to preload a customized bundle for a particular client or OEM.)
The current requireJS function returns a collection of strings, but I think it would be cool if it was a REF with strings as a property. Maybe a REF to some singleton class, so that var i18n = REF.getInstance(). Then we could do things like i18n.setLocale(code) and i18n.getString(key) and attach events like i18n.bind("localeChanged",onLocaleChanged)
Some of the solutions I have seen, offer a substitution/template scheme built into i18n.
imho templating should be left out because its easy enough to fetch the value, then compile in a template function from underscore/mustache/etc/etc/etc
As templating solutions get stronger and more feature rich (conditionals and so forth) any built in support for it here would just get in the way.
I've often dreamed of being able to switch the locale without a reload. Seems like we've just about got all of the components in @cujojs to do that now. I'll put a bit more thought into that. Sounds like a very cool idea! :)
I use RequireJS's i18n plugin with curl in my application and they work fine together. The only little problem/drawback I’ve encountered is that the plugin doesn’t allow to use properly a deep (more than 2 levels, i.e. menu.text.item1 instead of menu_text.item1) hierarchy of messages that isn’t fully translated for all alternative locales. In other words, if you have menu.text.item1 and menu.text.item2 in root bundle and only menu.text.item1 in a specific translation bundle then you won’t have menu.text.item2 from root bundle as default text (menu.text.item2 will be undefined). It is because plugin’s mixin function isn’t recursive.
That's great to hear, @gamtiq! I am glad it works! -- John
It seems to me that most of the tricks (writing locale to session and/or HTML, choosing locale fallbacks, routing of async requests to the resource handler) happen on the server side, whereas the client side plugin can be kept relatively lightweight. In other words, why not keep it simple and let the app developers take it from there?
And while I agree that no-refresh locale switching is a noble dream, I don't think it's realistic on most existing sites. You'd need to bind locale update events to not only content nodes (which are usually served by a non-JS server), but also every meta tag (title, description, opengraph tags, etc.), image tag (that may contain localized text), external CSS file (since they often reference one or more localized image sprites), as well as potentially client side templates (which shouldn't include text, but we know from experience they sometimes do). Worse yet, for some sites you may run into encoding or text direction issues, if one locale uses Western European ISO-8859-1, while another uses Chinese Big5 or Arabic Windows-1256.
Thanks for the input @JensRoland! Encoding is something I don't have an answer for, yet. :)
There's a version of this in the dev branch. Needs docs, of course.
The initial issue description seems to imply that this should operate like RequireJS and Dojo's i18n plugins, but it doesn't seem to (at least, as of curl 0.7.3) - it doesn't appear to expect the root object in the root bundle, and expects translations in bundlename/language.js instead of language/bundlename.js. (Contrast the expectations of curl's i18n plugin with http://requirejs.org/docs/api.html#i18n)
So I guess my question is, do you believe this inconsistency is a bug, or by design?
This is by design. I hadn't realized that the dojo and requirejs i18n plugins had increased in complexity when I wrote this issue. The dojo and requirejs i18n plugins seem to be trying to be ultra-general-purpose. Imho, the tools should make simple things simple. It's easy to create and/or adapt the plugins, so more advanced users -- or those who wish to do things differently -- should be able to create their own i18n plugin.
Sorry if the lack of documentation caused you some hassles. See #190.
The requireJS i18n plugin specifies available languages in the base language file. This avoids the need to traverse language parents at runtime to find which languages are available so you don't get numerous 404s. I'd say this is probably the right way to go.