I am starting this discussion to gather more info on localization practices for APIs. It seems HTTP does NOT provide sufficient guidance and even the state of practice is not sufficient enough.

The basic problem is that APIs may need to provide content that is dependent on the user culture, country, language and timezone. For example a German user would like to read messages in German language, with European metric dates, numbers, units, using Euro currency and in Central European Timezone.

Reading through [RFC 7231 Section 5.3.5 Accept-Language](https://www.rfc-editor.org/rfc/rfc7231#section-5.3.5) and further into RFC 4647 one may think `Accept-Language` is sophisticated enough and is what should be done. There are several notable shortcomings though:

1. Language tags may not be precise enough e.g. user may only request language without country code and thus leave ambiguity as: "de, en;q=0.8"
2. Even if the user supplies both language and country preferences it is not clear how to tie the selection of message locale and value formatting locale. For example if a user requests: "hu\_HU, en\_US;q=0.9" while the application lacks Hungarian messages and is written in Java that knows how to format date in Hungarian. So should the app use English messages with Hungarian dates or rather provide English messages with US dates? The actual situation may be more complex.
3. Timezone is not present in the language tags. There is [no HTTP standard header for this it seems](https://stackoverflow.com/questions/13/determine-a-users-timezone).

I see [Microsoft have thought about #2 in ASP.Net](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-2.2) and introduce the notion of Culture and UICulture to separate selection of message language from formatting.

In Java world Spring have introduced [TimeZoneAwareLocaleContext](https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/i18n/TimeZoneAwareLocaleContext.html) to address #3

W3c have issued guideline to [Accept-Language used for locale setting](https://www.w3.org/International/questions/qa-accept-lang-locales). This more or less says that `Accept-Language` is not enough

So what is your thinking?

1. Do you know of APIs tat solve this problem in comprehensive way? Pointers?
2. Should APIs accept multiple values for selecting message language, value formatting locale and timezone?
3. Should `Accept-Language` be used at all?