如果您的应用程序本地化为pt-br和pt-pt,如果系统仅报告"pt"代码,您应该选择哪种语言？

如果您的应用程序已本地化,pt-br 并且pt-pt如果系统仅报告pt代码(通用葡萄牙语),您应选择何种语言？

此问题独立于应用程序,桌面,移动或基于浏览器的性质.让我们假设你是不是能够得到区域信息从另一个来源,你必须选择一种语言作为默认的一个.

这个问题也适用于更多案例,包括:

pt-pt 和 pt-br

en-us 和 en-gb

fr-fr 和 fr-CA

zh-cn,zh-tw.... - 实际上在这种情况下我知道zh可以用作完整代码的简体中文的主要语言zh-hans.对于中国传统,用类似的代码zh-tw,zh-hant-tw,zh-hk,zh-mo正确的代码(规范)应该是zh-hant.

Q1:如何确定指定元语言的主要语言？

我需要一个至少包括葡萄牙语,英语和法语的解决方案.

Q2:如果系统报告简体中文(PRC)(zh-cn)作为用户的首选语言,我只翻译英文和繁体中文(en,zh-tw)我应该从两个选项中选择:en或者zh-tw？

通常,您应该将"猜测缺少的参数"问题与"匹配我想要的语言环境列表与我拥有的语言环境列表"问题分开.它们是不同的.

猜测缺少的部分

这些都是棘手的领域,甚至(可能)政治上充电.

但除了极少数例外,规则是选择语言的"原始国家".例外情况主要基于人口.所以fr-FR用于fr,es-ES等.一些例外:pt-BR而不是pt-PT,en-US而不是en-GB.

zh也普遍接受(并且中国标准要求)zh映射到zh-CN.

您可能还需要查看国家/地区以确定脚本,或者反过来.例如,az => az-AZ但是az-Arab => az-Arab-IR,并且az_IR => az_Arab_IR

匹配'想要'对'有'

这涉及匹配需求列表和具有语言列表.处理列表会让事情变得更难.如果可能的话,结果也应该以聪明的方式排序.(例如,如果want = [ fr ro ]和have = [ en fr_CA fr_FR ro_RO ]那么你可能要[ fr_FR fr_CA ro_RO ]为结果.

语言与不同脚本之间不应该匹配.所以zh-TW不应该回到zh-CN,而mn-Mong不应该回退到mn-Cyrl.棘手的领域:sr-Cyrl理论上不应该回到sr-Latn,但用户可能会理解.ro-Cyrl可能会回到ro-Latn,但不是相反.

一些参考

RFC 4647处理语言回退(但在这种情况下不是很有用,因为它遵循"从右边切割"规则).

ICU 4.2和更新版本(我认为4.0中的草案)已经uloc_addLikelySubtags(和uloc_minimizeSubtags)uloc.h.这实现了http://www.unicode.org/reports/tr35/#Likely_Subtags

此外,在ICU uloc.h有uloc_acceptLanguageFromHTTP与uloc_acceptLanguage该交易有希望VS都有.但它们有点无用,因为它们将UEnumeration*作为输入,并且没有用于构建UEnumeration的公共API.

除了简单的RFC 4647之外,还有一些关于语言匹配的工作.请参阅http://cldr.unicode.org/development/design-proposals/languagedistance

位于http://code.google.com/p/as3localelib/的 ActionScript中的区域设置匹配

新的Flash Player 10.1 flash.globalization命名空间中的API 同时标记猜测和语言匹配(http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/flash/globalization/package-detail.html).它适用于TR-35,可以超越@并考虑操作.举例来说,如果have = [ ja ja@collation=radical ja@calendar=japanese ]和want = [ ja@calendar=japanese;collation=radical ]那么最佳匹配取决于你想要的操作.对于日期格式化ja @ calendar = japanese是更好的匹配,但是对于整理,你想要ja @ collat​​ion = radical