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

Capability: Display map content in a users preferred language #136

Open
nchan0154 opened this issue Sep 9, 2019 · 3 comments
Open

Capability: Display map content in a users preferred language #136

nchan0154 opened this issue Sep 9, 2019 · 3 comments
Labels
discussion: capability a specific capability or feature: should it be included? what details? should it be a requirement? section: map viewer Capabilities & use cases for declarative map viewer widgets status: placeholder there's a matching section heading / some text in the report, but it's far from complete

Comments

@nchan0154
Copy link
Contributor

@nchan0154 nchan0154 commented Sep 9, 2019

This issue is for discussion of the map viewer capability “Display map content in a users preferred language”.


This capability popped into my head when I was working on adding tags to the various capability conclusions. I noticed that we have several tags related to localization, but no capabilities related to this yet.

Ideally, the map language would reflect the language set in the browser headers. From some quick testing, a few tools seem to support this, Google Maps and Bing being the main ones.

@nchan0154 nchan0154 added discussion: capability a specific capability or feature: should it be included? what details? should it be a requirement? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft section: map viewer Capabilities & use cases for declarative map viewer widgets labels Sep 9, 2019
@prushforth
Copy link
Member

@prushforth prushforth commented Sep 9, 2019

Good catch! I believe this ties into content language negotiation which is tied as you say to headers, so +1 for conveying map (and language) semantics via content negotiation.

@nchan0154
Copy link
Contributor Author

@nchan0154 nchan0154 commented Sep 11, 2019

Bringing you in @AmeliaBR as it may have gotten lost in the Great Wall of Notifications

@AmeliaBR
Copy link
Member

@AmeliaBR AmeliaBR commented Sep 11, 2019

This is definitely an important user-focused use case (see map content with labels you can read!)

Might need a little more thought to define how this can be broken out into a technical capability of the map viewer.

For the case of serving a different image file: If it is handled through HTTP content negotiation with the server, different data getting served based on the accept-language headers automatically added by the browser to all requests, then that's pretty transparent for the viewer widget code. It's the server that has the extra behavior. Still maybe worth mentioning in the context of data formats and server APIs.

But, if the localized content also includes real text, than the viewer does need to be able to detect the language in the returned feature data and handle it correctly when it's inserted into the markup.

@Malvoz Malvoz added status: placeholder there's a matching section heading / some text in the report, but it's far from complete and removed status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft labels Jan 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion: capability a specific capability or feature: should it be included? what details? should it be a requirement? section: map viewer Capabilities & use cases for declarative map viewer widgets status: placeholder there's a matching section heading / some text in the report, but it's far from complete
Projects
None yet
Development

No branches or pull requests

4 participants