You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It might be more user and developer friendly in our polyfill to support parsing of the <mapml-viewer lang="en|fr|sv|uk|etc">lang attribute (to the extent that we have internationalized message strings for the language). Currently, the map relies on the <map-options> tag to obtain the language of the "browser", but perhaps allowing control of the localization of the map interface by the lang attribute would be user and developer friendly, being as it would be under the control of the author. Currently, the language of the map can be forced by some tricks, for example on this experiment. (Source).
For example, while the injected <map-options> could and should specify what language is selected by the user's "browser" (simulated or provided by our mapml-extension chromium extension, currently), maybe it would be cool to be able to override that default language and provide the map localization in the author-selected lang value. That's what is happening in this MDN example, (although the only user interface requiriing localization is the text entered by the author).
One consequence of implementing this would be to force us into shipping UI localized strings with the bundle. Other ideas below!
The text was updated successfully, but these errors were encountered:
Also could consider localizing the <layer-> element via a lang attribute. Where to stop?! It's a global attribute so in principle it could appear on any element in MapML too, although it would have to be considered what it would mean/do on each one.
Consider making the lang attribute dynamic, that is, not a one-time initialization. This is probably necessary in fact for script support that decides on the language after creating the map, in a language picker, for example.
It might be more user and developer friendly in our polyfill to support parsing of the
<mapml-viewer lang="en|fr|sv|uk|etc">
lang
attribute (to the extent that we have internationalized message strings for the language). Currently, the map relies on the<map-options>
tag to obtain the language of the "browser", but perhaps allowing control of the localization of the map interface by thelang
attribute would be user and developer friendly, being as it would be under the control of the author. Currently, the language of the map can be forced by some tricks, for example on this experiment. (Source).For example, while the injected
<map-options>
could and should specify what language is selected by the user's "browser" (simulated or provided by our mapml-extension chromium extension, currently), maybe it would be cool to be able to override that default language and provide the map localization in the author-selectedlang
value. That's what is happening in this MDN example, (although the only user interface requiriing localization is the text entered by the author).One consequence of implementing this would be to force us into shipping UI localized strings with the bundle. Other ideas below!
The text was updated successfully, but these errors were encountered: