multiple pages in an app using same translations

[mvolkmann]

Description

If I understand correctly, when an app has multiple pages that use app-localize-behavior, each one needs to specify the language and call this.loadResources to load a translation file. I want to specify the language once for every use of app-localize-behavior in my app and call this.loadResources once.

Expected outcome

I can specify the language and the path to the translation file once and all uses of app-localize-behavior take advantage of those.

Actual outcome

I have to specify these things in every usage of app-localize-behavior.

Browsers Affected

all

[mvolkmann]

I really think wanting all instances of app-localize-behavior to use the same language is the common case.

If I were to supply a pull request for this, would there be any interest in merging it?

[notwaldorf]

I wasn't saying it wasn't a real use case, I was mostly saying this is a thing you can do in your elements, not in the behaviour. To keep the behaviour as general as possible, for each of your element implementations you can set the value of the language to be Polymer.myCustomLanguage. Since you have to define these elements anyway, it makes sense they need to know what their language is. And, from outside the elements in your app, when you change the value of Polymer.myCustomLanguage, all will be updated.

Does that make sense? We try to avoid having globals on the Polymer object, since they're available everywhere around the app (and any apps using elements that use this behaviour), which makes these elements leak implementation details pretty badly.

I can put together a JSBin if this still doesn't make sense

[mvolkmann]

It does make sense, but I still have a concern. Suppose my app has 20 uses of this behavior and I want to have a single drop-down on a settings page that can change the language. How will I communicate that change to all the custom elements that use this behavior? I could invent my own mechanism to handle that. However, if this is something that many apps will want then maybe it is better for that functionality to be directly supported by the behavior.

[joeblew99]

The Mediator pattern is not enough in this scenario. Some sort of global state is needed.
Some use the Routing, some use Sessions.

There is also a global state aspect here: #39

[mvolkmann]

@notwaldorf, I created a pull request that supports this with the minimum changes possible. It only requires changing app-localize-behavior to emit two event.

#40

[mvolkmann]

I created a new pull request that correctly squashes my previous commits. Please reconsider this one: #44

[bwh-rl]

Are there any plans on adding the AppLocalizeBehavior into the Starter Kit template?
With inlined resources inside the app element, and the usage inside the view elements?

In the Starter Kit template there are multiple pages, and having multiple pages is most likely the common case, so this would be a great place to show us how we are supposed to use this behavior on multiple pages?

Having separate resources is imho not very clean, besides small apps where they are inlined.
But as soon as the resources are loaded, you want to load them only one time?
And also if you only load the resources needed in that view, i don't think that loading the basics "ok, cancel, save, discard, age, size" again for every view makes much sense.

[zlamma]

If I read this correctly, this seems to be asking for functionality from #46 ("Sub-components should have language inherited").

If that's the case, then component authors with this problem might be interested in the alternative to use an ancestor's lang= attribute that I have mentioned there.