REST API 的本地化答案

【问题标题】：Localization for REST APIsREST API 的本地化
【发布时间】：2019-05-25 13:08:21
【问题描述】：

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

基本问题是 API 可能需要提供取决于用户文化、国家、语言和时区的内容。例如，德国用户希望阅读德语消息，其中包含欧洲公制日期、数字、单位，使用欧元货币和中欧时区。

通读RFC 7231 Section 5.3.5 Accept-Language 并进一步了解RFC 4647，您可能会认为Accept-Language 已经足够成熟，应该这样做。但是有几个明显的缺点：

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

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

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

W3c 已向Accept-Language used for locale setting 发布了指南。这或多或少说明Accept-Language不够用

那么你的想法是什么？

【问题讨论】：

格式化和使用特定于区域设置的数字等可以从 CLDR 数据库中获得，正如许多供应商似乎所做的那样cldr.unicode.org 但是仍然可能存在一些问题： 1. CLDR 的可用翻译存在差异，即 CLDR 封面许多语言环境，而大多数 API 的翻译很少 2. 人们是否可能希望使用与 CLDR 值相矛盾的自己的格式设置？

【解决方案1】：

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

仅在绝对必要时提供本地化文本。在这种情况下，从接受语言标头字段中获取语言环境，如果您有本地化的字符串，请通过它。如果不回退到您拥有的字符串。

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

这是sample。

【讨论】：

延迟或推迟服务本地化的好主意。事实上，您更进一步，只提供将被本地化的数据，将其留给 UI 来进行实际的本地化。这在服务相互调用的微服务环境中可能会更好。最终，某些服务将需要缓存来自其他服务的结果，并将它们交付给不同地区的多个最终用户。有了这个想法，API 可能会返回消息键和带有参数的 json 对象，参数采用区域设置中性格式，而不是准备显示的字符串。

【解决方案2】：

好吧，伙计们，

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

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

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

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

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

【讨论】：