如果您的应用程序已在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？
答案 0 :(得分：10)
通常，您应该将“猜测缺少的参数”问题与“匹配我想要的语言环境列表与我所拥有的语言环境列表”问题分开。他们是不同的。
猜测丢失的部分
这些都是棘手的领域，甚至（可能）有政治色彩。
但除了极少数例外，规则是选择该语言的“原始国家”。 例外情况主要基于人口。 所以fr-FR为fr，es-ES等 一些例外：pt-BR而不是pt-PT，en-US而不是en-GB。
zh也普遍接受（并且中国标准要求）zh映射到zh-CN。
您可能还需要查看国家/地区以确定脚本，或者反过来。 例如，az =＆gt; az-AZ但是az-Arab =＆gt; az-Arab-IR和az_IR =＆gt; 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，但不是相反。
部分参考
uloc_addLikelySubtags中有uloc_minimizeSubtags（及uloc.h）。这实现了http://www.unicode.org/reports/tr35/#Likely_Subtags uloc.h，uloc_acceptLanguageFromHTTP和uloc_acceptLanguage处理了与想要对比。但是它们有点无用，因为它们将UEnumeration *作为输入，并且没有用于构建UEnumeration的公共API。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 @ collation = radical 答案 1 :(得分：4)
您希望在葡萄牙或巴西拥有更多用户吗？相应地选择。
对于您的一般解决方案，您可以通过阅读Ethnologue来了解。