My try to extend the concept

[trading-peter]

Update
As mentioned further down the thread, I created a new project called i18-n because I work with it in a quite big project and changes are also quite massive.

Just updating this first message to redirect you right away so you don't accidentally waste time on old stuff (aka the branch in my i18n-msg fork).

Cheers

---

Maybe you're interested in giving this a look and providing some feedback.
Kinda forward of me, sooo... sorry.

I have a new branch in my fork of your project called i18n-msg-domain

I tried to expand the hole i18n-msg stuff and created an additional i18n-msg-domain component.
It make it possible to declaratively define the location of the locale files, what language to use and additionally the ability to define language domains. The part of loading the locale files is moved over to the new component.

So now we can throw multiple i18n-msg-domain elements on the page, for different languages and even to target different sets of i18n-msg elements (by using the language domain).
i18n-msg was also modified big time by me to make it work together with the new i18n-msg-domain.

I also added HTML sanitizing (I created an element/behavior called dom-purify for this).

A demo is in the component page under the demo area so you can try it out quickly.

So if you have to time to look into this, I would be more than thankfull.

[mandaman2k]

looks very good, it could help a lot

[trading-peter]

Till @ebidel finds time to look into this, meanwhile I created a separate repository with a more refined version. I did this, because I need the element in my project and the changes are quite massive.
i18-n & i18-n-domain

[ebidel]

Still on my todo list :)

On Thu, Aug 6, 2015 at 12:52 AM Peter Kaske [email protected]
wrote:

Till @ebidel https://github.com/ebidel finds time to look into this,
meanwhile I created a separate repository with a more refined version. I
did this, because I need the element in my project and the changes are
quite massive.
i18-n & i18-n-domain https://github.com/pkaske/i18-n

—
Reply to this email directly or view it on GitHub
#14 (comment).

[mandaman2k]

just a quick question, if im using the polymer-starter-kit, where would the locales folder need to be?

Thanks

[ebidel]

The locales folder is expected to be top-level, alongside your site's code.

On Thu, Aug 6, 2015 at 12:15 PM mandaman2k [email protected] wrote:

just a quick question, if im using the polymer-starter-kit, where would
the locales folder need to be?

Thanks

—
Reply to this email directly or view it on GitHub
#14 (comment).

[ghost]

Hey @pkaske & @ebidel

This looks great and really useful for Projects where i am using Polymer. I have some remarks, and would like your feedback.

1. Best Practices: Can you add a description to the ReadMe. For example detection of default locale.
2. Detection: How to detect what the user has as their default locale in their browser.
   I would also like to test with cordova for Android and IOS and see if it works there also.

3.Async loading: In terms of loading the locales, it seems that it should be behind a async loading pattern, and so only load the files needed for their locales. @ebidel , the work you did on AppShell seems relevant, and so maybe a 2nd demo with at least AppShell and delayed loading of the correct locale is a good idea.

[ebidel]

1-2. For auto detection, you could try navigator.language. However, this doesn't always seem to return the browser's setting. The Accept-Language header looks more reliable.
3. The locales folder is loaded async on page load (when the element registers itself). It defaults to en, but you can configure that. Any changes to the language thereafter, are lazy/async.

Generally, I wouldn't use this element as-is in production. For Santa Tracker, we had a build gulp script that replaces all the occurrences of <i18n-msg> with their translated equivalent. This means we didn't incur the cost of an XHR and the content was already translated. We served a separate file for each locale. Google's infrastructure took care of directing users to the right locale.

https://github.com/google/santa-tracker-web/blob/master/gulp_scripts/i18n_replace/index.js

[ghost]

@ebidel Thanks for the feedback, and advice.
Server side replacement does not match my needs.

For me its:

1. detect locale on desktop, mobile and inside cordova
2. async loading of translated text.
3. mixin with other components. Needs to be a Service Component i suspect as other components need to reference certain keys, and get back translated text.

I will see what patterns exist for a Polymer Service component.