Closed RoXuS closed 8 years ago
Adding a msg
property that notifies sounds like a good idea to me! Want to propose a PR?
Yes, I do the PR as soon as possible !
Thank you for your answer
+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.
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.
@RoXuS and @ebidel : did you roll out the changes for attributes i am also looking for it as i am using this awesome element
@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
@sumukhj84 I do the PR see https://github.com/ebidel/i18n-msg/pull/28.
But for now I have no news from @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
@ronnyroeller i like the idea but i have few questions after reading your blog :
@sumukhj84 to your questions:
vulcanize
puts all files together during the build, i.e. in the end it's all part of the final distribution file.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.]
@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 :)
@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.
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.
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.
Think this is fixed in https://github.com/ebidel/i18n-msg/pull/28
Hello ebidel,
Thx for this component.
We use it in our components but we have a problem with the attributes. For example, how to translate the label of the paper-input ?
I try two solutions.
This solution is ok but I have to pass the i18n element to the compute ! So I have to create the statement of i18n :
I add lastMsg in your component like this:
Have you a more usable solution for this case ?
Julien