rest - 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 编写的。那么该应用程序应该使用带有匈牙利日期的英文消息还是提供带有美国日期的英文消息？实际情况可能更复杂。
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. 您是否知道可以全面解决此问题的 API？指针？
2. API 是否应该接受多个值来选择消息语言、值格式化区域设置和时区？
3. 是否应该使用 Accept-Language？

Answer 1

好的，伙计们，

这里是我如何回答我的问题的总结。我希望这对 future 的 API 作者有所帮助。

基于 API 之上的 UI(不包括货币表示)的基本要求似乎是:

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

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

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

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