REST API的本地化

问题描述

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

I am starting this discussion to gather more info on localization practices for APIs. It seems HTTP does NOT provide sufficient guidance and even the state of practice is not sufficient enough.

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

The basic problem is that APIs may need to provide content that is dependent on the user culture, country, language and timezone. For example a German user would like to read messages in German language, with European metric dates, numbers, units, using Euro currency and in Central European Timezone.

通读 RFC 7231第5.3.5节接受语言" 和进一步进入RFC 4647，人们可能会认为Accept-Language已经足够复杂，应该怎么做.但是，有几个明显的缺点:

Reading through RFC 7231 Section 5.3.5 Accept-Language and further into RFC 4647 one may think Accept-Language is sophisticated enough and is what should be done. There are several notable shortcomings though:

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

我看到 Microsoft已经考虑过#2在ASP.Net中使用，并引入了Culture和UICulture概念，以将消息语言的选择与格式化分开.

I see Microsoft have thought about #2 in ASP.Net and introduce the notion of Culture and UICulture to separate selection of message language from formatting.

在Java世界中，Spring引入了 TimeZoneAwareLocaleContext 指向地址#3

In Java world Spring have introduced TimeZoneAwareLocaleContext to address #3

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

W3c have issued guideline to Accept-Language used for locale setting. This more or less says that Accept-Language is not enough

那你在想什么?

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

1. Do you know of APIs tat solve this problem in comprehensive way? Pointers?
2. Should APIs accept multiple values for selecting message language, value formatting locale and timezone?
3. Should Accept-Language be used at all?

推荐答案

好的，

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

here is a summary of how I answer my question. I hope this helps future API authors.

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

The fundamental requirements for an UI based on top of API excluding currency presentation seem to be:

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

1. Select the best language out of the available product translations using RFC 4647 list of language ranges
2. Select the best data format out of the available using RFC 4647 list of language ranges
3. Allow clients to provide distinct preferences for translation and format. There will be cases where people will not find the best translation and yet prefer to see the proper formatting aligned with their culture.
4. Allow clients to specify a timezone using IANA TZDB identifiers
5. Format data elements using Unicode CLDR http://cldr.unicode.org/
6. Use named placeholders in localization bundles e.g. "{drive} is corrupt" is easier to translate properly than "{1} is corrupt"

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

On the REST HTTP headers I suggest use of 3 headers

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

1. accept-language - used for selecting translation and following the guidelines of RFC 7231 https://tools.ietf.org/html/rfc7231#section-5.3.5
2. format-locale - used to select data formatting style if different from the translation language preferences. Again list of language range elements. Defaults to accept-language if omitted.
3. timezone - used to select timezone for rendering date and time values. This should be valid timezone ID from the IANA TZDB https://www.iana.org/time-zones

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

Implementation wise it seems Java 8 and later have full capability to implement a globalized application. Other languages and older Java versions seem to have varying degrees of issues.

这篇关于REST API的本地化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！