Internationalization code seems ok, any progress?

[uvworkspace]

I looked at the code trying to make it work for my project for different locales. In activator.js I just replace 'en_US' with variable lang, whose value is obtained from req.lang passed in from previous middleware. Now I can add templates of different locales in the template directory.

This is just a quick hack, a little better maybe define another configurable property (similar to idProperty but on req). I'm wondering if this direction is ok (to the extent that you guys will consider it, or you have some plan regarding internationalization). Thanks.

[deitch]

Hey @uvworkspace actually that is perfect. Years ago I did an i18n library for JS - at https://github.com/deitch/jsorm-i18n now a little dated - but the structure was the same. The concept is exactly that, you should be able to use files that end in en_US, else en else just the name. It was the inspiration for this part.

The only place in activator that the default language is used explicitly is those two lines in activator.js where it calls "en_US". It makes a lot of sense to do what you did - take it out to a config var, defaulting to "en_US" (which, I will admit, is a little America-centric, and I speak 3 languages and a smattering of a few others, but it is where most of the market is nowadays; just being practical).

The only question I have is whether or not req.lang is the right place to put it. It seems to have some common accepted practice, though, so we can live with it.

We definitely do not want to start parsing the Accept-Language header; that is something that should happen at earlier middleware, select the preferred language, and pass it on to activator.

Thanks for the great suggestions; we'll set up some tests and implement!

[deitch]

Done. v0.4.4. Git push and npm publish complete. Enjoy!

[uvworkspace]

Well thanks a lot. I proposed so I don't have to clone it and modify just several lines. :).

[deitch]

Actually was harder than I expected. The tests took some time to get just right, and although the req.lang || 'en_US was easy, there was a nasty little bug with the template caching. But all is great now.

[uvworkspace]

Yes I can see it now. I need to control the locale used for different user based on url query and/or session, so the locale assignment is done earlier, and using Accept-Language header is not enough for me.

Now I guess later someone who want to use it may ask to use a different property name, then allowing user to configure it in init() may be good enough for a longer while, I guess. Thanks for the hard work.

[deitch]

So? Go ahead and put in middleware to set req.lang based on however you want. A different user can use different middleware.

Look in the README; I put in a very basic example of where and how to put it.

[deitch]

And you are quite welcome! Use it well.