Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider prototype support for the global lang attribute on <mapml-viewer> #994

Open
prushforth opened this issue Oct 9, 2024 · 3 comments · Fixed by #999
Open

Consider prototype support for the global lang attribute on <mapml-viewer> #994

prushforth opened this issue Oct 9, 2024 · 3 comments · Fixed by #999
Labels
i18n Internationalization and localization idea needs discussion

Comments

@prushforth
Copy link
Member

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!

@prushforth prushforth added idea i18n Internationalization and localization needs discussion labels Oct 9, 2024
@prushforth
Copy link
Member Author

prushforth commented Oct 9, 2024

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.

The CSS pseudo class :lang looks interesting.

@prushforth
Copy link
Member Author

One consequence of implementing this would be to force us into shipping UI localized strings with the bundle

So we will limit the set of lang values that are runtime-supported to en and fr, which limits the usefulness but demonstrates the concept.

@prushforth
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n Internationalization and localization idea needs discussion
Projects
None yet
1 participant