Open ianthetechie opened 3 weeks ago
seems reasonable to me with the caveat being that we fallback to http headers only after first checking whether the existing language option was set. if the existing option is not set then headers can be checked.
Ahh yes, good clarification. Thanks!
Getting localized directions to users is something that's interesting to me, and I'm wondering if there's a better way than the current approach of specifying a single 2 letter language code. Setting a language code in the query string or POST body is fine if you know, for example, that you need directions in Korean AND you also know that Valhalla supports Korean (it doesn't :P). But maybe the user also understands some other supported language which they'd prefer over English directions?
There's a web standard for this already; both web browsers and (good) mobile HTTP clients send a useful hierarchy of wants in the Accept-Language header, and some APIs (like Pelias) take this into account to automatically localize content. Valhalla could improve the UX by supporting this header too, parsing the priority list, and identifying a language for the response based on what's supported.
Is there interest in supporting this directly in Valhalla? If so, I'd be happy to take a swing at implementation.