REST API的本地化

我将开始讨论，以收集有关API本地化实践的更多信息。HTTP似乎没有提供足够的指导，甚至实践状态还不够。

基本问题是，API可能需要提供依赖于用户文化，国家/地区，语言和时区的内容。例如，一个德国用户想用德语，带有欧洲公制日期，数字，单位，使用欧元货币和中欧时区的消息来阅读。

仔细阅读RFC 7231第5.3.5节“接受语言”以及进一步阅读RFC 4647，可能会认为Accept-Language它已经足够复杂了，应该采取的措施。但是有几个明显的缺点：

1. 语言标签可能不够精确，例如，用户可能只请求没有国家/地区代码的语言，因此歧义为：“ de，en; q = 0.8”
2. 即使用户同时提供语言和国家/地区偏好，也不清楚如何将消息语言环境和值格式语言环境的选择联系起来。例如，如果用户请求：“ hu_HU，en_US; q = 0.9”，而该应用程序缺少匈牙利消息，并且使用Java编写，该Java知道如何用匈牙利语格式化日期。那么，应用程序应该使用带有匈牙利日期的英语消息，还是提供带有美国日期的英语消息？实际情况可能更复杂。
3. 语言标签中没有时区。有这个好像没有标准的HTTP标头。

我看到微软已经考虑过ASP.Net中的＃2，并引入了Culture和UICulture的概念来将消息语言的选择与格式化分开。

在Java世界中，Spring已将TimeZoneAwareLocaleContext引入地址3

W3c发布了用于语言环境设置的接受语言指南。这或多或少表明Accept-Language还不够

那你在想什么？

1. 您是否知道API Tat可以全面解决此问题？指针？
2. API是否应该接受多个值来选择消息语言，值格式区域设置和时区？
3. 应该Accept-Language使用吗？