Customizable internal strings to support i18n #3660
Replies: 7 comments
-
|
Yah, this is an interesting problem that sadly isn't very well addressed on the web. That is to say, there are a million things we could do it and not much in the way of a good platform example to follow. A few things we could try, all with trade-offs:
After talking with my manager about this we decided we could probably foot the bill to get all of our first-party strings internationalized and maintain that body of translations in this repo, so that's something. The question of how best to customize the strings remains, though. |
Beta Was this translation helpful? Give feedback.
-
|
In the case of first-party internationalization, would we pass in a locale or something to the viewer? |
Beta Was this translation helpful? Give feedback.
-
|
No, this would just be a convenience bundle of strings (probably a blob of JSON or CSV) so that users can incorporate them into their own systems. i18n string bundles tend to be too large to justify bundling inside of the library itself. |
Beta Was this translation helpful? Give feedback.
-
|
One idea that I have been playing with in my head is that we could dispatch a global self.addEventListener('model-viewer-locale-lookup', (event) => {
event.detail.localeStrings = {
// locale strings go here...
};
});This approach is somewhat esoteric, and has some similar qualities to a more traditional imperative API strategy, so here is the rationale: With a traditional imperative API, you would either need to access the constructor or an instance of const ModelViewerElement = customElements.get('model-viewer');
ModelViewerElement.setLocaleStrings(...);
// or...
const modelViewer = document.querySelector('model-viewer');
modelViewer.constructor.setLocaleStrings(...);However, that means you need to observe when With the event approach, there is no need to wait for the element to be defined, or look for places where it is used. You can just wait for the event to fire, and if it does, provide it the appropriate configuration. An additional caveat about declarative approaches: even if we went with a declarative approach, you would have to know of the instances where |
Beta Was this translation helpful? Give feedback.
-
|
Are there any examples out there of other libraries or scripts that configure stuff this way? I'm not sure I've ever seen configuring an object via the |
Beta Was this translation helpful? Give feedback.
-
|
It is unheard of, but not entirely unorthodox. The canonical example I would give is We have experimented with extensions of this concept in the past, but I am not aware of any production context where this is a common pattern. There are a lot of options here. I'm very interested to hear additional proposals. |
Beta Was this translation helpful? Give feedback.
-
|
It's possible that something less esoteric but similar in spirit might look like this: self.addEventListener('model-viewer-defined', () => {
const ModelViewerElement = customElements.get('model-viewer');
ModelViewerElement.localize(...);
}); |
Beta Was this translation helpful? Give feedback.
-
What are your thoughts on how we will localize the aria-labels in the viewer? Ex:
https://github.com/GoogleWebComponents/model-viewer/blob/e316b45d8e4eda631f9cbac88e9cf0e3e537bbbe/src/template.ts#L255
I know some of the properties can be done with slots, but for others we'll need to find some way to localize it.
Beta Was this translation helpful? Give feedback.
All reactions