About attributes about i18n-msg

[ebidel]

Adding a msg property that notifies sounds like a good idea to me! Want to propose a PR?

[RoXuS]

Yes, I do the PR as soon as possible !

Thank you for your answer

[ronnyroeller]

+1 - This would be a great way to simplify usage!

@ebidel - What do you think about pushing this further by exposing all localized messages of the current language via a Behavior? Elements with this behavior would get a property i18n (type Object).
For example to access the localized value for key "paper_label" from within an element with this behavior:

<paper-input label="[[i18n.paper_label]]"></paper-input>

This would significantly simplify using the localized values in methods.

[RoXuS]

Yeah it is a good idea, and the original i18n-msg element could use this behavior.

Maybe it is better than the msg property because we will not have to insert an i18n-msg element on each attribute.

[sumukhj84]

@RoXuS and @ebidel : did you roll out the changes for attributes i am also looking for it as i am using this awesome element

[ronnyroeller]

@sumukhj84 - I don't think it did.
We actually ended up creating our own i18n-behavior that exposes the translations as properties. I also wrote a blog post about it with some additional background: https://medium.com/collaborne-engineering/localize-polymer-applications-216e8bc90e1a

[RoXuS]

@sumukhj84 I do the PR see #28.

But for now I have no news from @ebidel.

[ebidel]

@ronnyroeller I like the idea of a behavior that elements can use. Want to prototype it in a new PR?

Taking a look at @#28

[sumukhj84]

@ronnyroeller i like the idea but i have few questions after reading your blog :

1. Is the JS file used for any language is per element basis like you wrote my-element.en.i18n.js, my-element.de.i18n.js?
2. Are these JS files get loaded in the polymer app on demand or at the first request all JS files for each language will be loaded once?
3. So if i have 6 languages to support then i must create 6 language JS files per element so if for example i have 6 elements then 36 JS files will be required? I am confused here.
4. Is this element has support to IE10 or IE11? As many of our user use these browsers.
5. Is this element Production ready?

[ronnyroeller]

@sumukhj84 to your questions:

1. Yes, we prefer having the localizations per element as this makes it easier to distribute the development of the elements over various teams/repositories. We use tools to combine all texts before sending them to our translation agency, and then afterwards distribute the translated content to the element-specific i18n files.
2. All localizations are currently loaded when the element is loaded. It would certainly make sense to load them on demand instead (just not a requirement for us right now).
3. Yes, that's right. vulcanize puts all files together during the build, i.e. in the end it's all part of the final distribution file.
4. We officially support IE11+ for our customers but I don't see a reason why it wouldn't work with IE10.
5. We have been using it in production for a while.

Let me highlight the last point of my blog post: "I wish I wouldn’t have to write this post. Hence: Please, PolymerElements team, get out the carbon elements! :) For the time being, our open sourced carbon-i18n-behavior might help some folks localizing their Polymer applications." - So this is really just a lightweight solution until the Polymer team brings out the "official" i18n behavior. That's one of the reason why we don't use the JS files as the raw format of the translations. Instead we generate them from the XLIFF files which we exchange with our translations agency (see https://medium.com/collaborne-engineering/localize-polymer-applications-with-a-translation-agency-b3291b574c85).
Hence, our i18n behavior does only the bare minimum. Feel free to extend it to your own needs.

[PS: Sorry, as this response is a bit off topic to the initial ticket.]

[ronnyroeller]

@ebidel - Absolutely. We'd rather contributing to an existing elements instead of creating & maintaining our own elements.
Along those lines: it would be really helpful if the Polymer team could provide a bit more transparency regarding the "official" i18n support that was announced back at the Amsterdam summit. Knowing when it's expected to be available and how it's going to look like would help us to put temporary solutions in place from which it's easy to migrate afterwards. Just my two cents :)

[RoXuS]

@ebidel, @ronnyroeller I have a simple example with i18n behavior.

The i18n-msg works perfectly (demo+tests) with this behavior :
https://github.com/RoXuS/i18n-msg/blob/behavior/i18n-msg.html

I have made a component which use this behavior to get translations :
https://github.com/RoXuS/i18n-msg/blob/behavior/i18n-page-example.html

It's not completely finish but a good start pending the Polymer component.

[Zoramite]

Hi @RoXuS I've sent you a pull request to the changes that you made. I like what the behavior adds and it makes things pretty nice to work with. I've moved more of the functionality into the behavior which removes most of the boilerplate.

Updated example element: https://github.com/Zoramite/i18n-msg/blob/behavior/demo/i18n-msg-behavior-example.html

Now it just requires adding the behavior and defining the message ids in the properties and the behavior takes care of the rest.

[RoXuS]

Hi @Zoramite thanks for your work !
Yes I had left the option to use any property name, but you're right, perhaps it is better to limit the boilerplate.

I added this commit to add the new name of the example in the all-import.html script.

[ebidel]

Think this is fixed in #28