REST API的本地化

Question

我将开始讨论，以收集有关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使用吗？

Answer 1

好，朋友们，

这是我如何回答我的问题的摘要。我希望这有助于未来的 API 作者。

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

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

在 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 版本似乎存在不同程度的问题。

Answer 2

我会将所有数据保存为通用的区域设置独立格式。对于使用 . 作为小数点分隔符、使用 ISO 8601 和 UTC 格式的日期和时间等。

仅在绝对必要时才提供本地化文本。在这种情况下，从接受语言标头字段获取区域设置，如果您有本地化字符串，则传递该字符串。如果没有回退到您拥有的字符串。

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

这是一个示例。