REST API的本地化

Question

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

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

仔细阅读RFC 7231 Section 5.3.5 Accept-Language并进一步读入RFC 4647，人们可能会认为Accept-Language足够复杂，应该这样做。但是，有几个明显的缺点：

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

我看到Microsoft have thought about #2 in ASP.Net，并介绍了Culture和UICulture的概念，以将消息语言的选择与格式化分开。

在Java世界中，Spring引入了TimeZoneAwareLocaleContext来解决＃3

W3c已发布了Accept-Language used for locale setting的指南。这或多或少表明Accept-Language是不够的

那你在想什么？

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

Answer 1

我将所有数据保留为与通用语言环境无关的格式。对于使用的数字。作为小数点分隔符，使用ISO 8601和UTC等格式的日期和时间。

仅在绝对必要时提供本地化文本。在这种情况下，请从accept-language标头字段获取语言环境，如果您具有本地化的字符串，则可以通过该语言环境。如果不退回给您，则返回字符串。

例如，您可能会使用包含多种语言的产品数据的多语言产品数据库。当您为数据库编写API时，您可以使用用户的语言（如果有）选择产品数据。

这里是sample。

Answer 2

好的，

这是我如何回答问题的摘要。我希望这对将来的API作者有所帮助。

基于API的UI的基本要求（不包括货币表示）似乎是：

1. 使用RFC 4647语言范围列表从可用的产品翻译中选择最佳的语言
2. 使用RFC 4647语言范围列表从可用数据中选择最佳数据格式
3. 允许客户为翻译和格式提供不同的首选项。在某些情况下，人们可能找不到最佳的翻译，而是希望看到与他们的文化相符的正确格式。
4. 允许客户端使用IANA TZDB标识符指定时区
5. 使用Unicode CLDR http://cldr.unicode.org/
设置数据元素的格式
6. 在本地化包中使用命名占位符，例如比“ {1}损坏”更容易正确翻译“ {drive}损坏”

在REST HTTP标头上，我建议使用3个标头

1. accept-language-用于选择翻译并遵循RFC 7231 https://tools.ietf.org/html/rfc7231#section-5.3.5
的准则
2. format-locale-用于选择与翻译语言首选项不同的数据格式样式。再次列出语言范围元素。如果省略，则默认为accept-language。
3. timezone-用于选择时区以呈现日期和时间值。这应该是来自IANA TZDB https://www.iana.org/time-zones
的有效时区ID。

在实施方面，Java 8和更高版本似乎具有实现全球化应用程序的全部功能。其他语言和Java的较早版本似乎都有不同程度的问题。