How do we enable localization of complex components?

[scomea]

So far FAST components have generally been fairly simple and developers could typically set strings on those elements directly (button titles, aria attributes, etc...). Now we are starting to see more complex UI's show up as part of components, for example the date picker component will have various flyouts that will need localized strings (even icon only buttons need accessible descriptions).

The prototype text editor has a generic "resources object" that templates can bind to ${x => x.resources["bulletButtonTooltip"]}. That was just a quick first guess at how to do this.

We should have a standard approach for how we implement this, so what should that approach be?

Thoughts?

[KingOfTac]

One Idea I've had, at least for static strings is to use the component definition to pass localized strings and icons to components when they get registered with the design system.

[scomea]

Would that make switching languages a bigger reset than it should be? As a Canadian I'm used to seeing french/english toggles everywhere.

[KingOfTac]

Interesting, I hadn't thought about toggling back and forth. I was mostly thinking of detecting the browser language and setting all the strings once.

[scomea]

Also, there is probably a notion of default strings for a component and being able to override on a per-instance basis too.