如果您的应用程序本地化为pt-br 和pt-pt，如果系统仅报告pt代码（通用葡萄牙语），您应该选择哪种语言？
这个问题与应用程序的性质、桌面、移动或基于浏览器无关。假设您无法从其他来源获取区域信息，并且您必须选择一种语言作为默认语言。
该问题也适用于更多案例，包括：
pt-pt和pt-bren-us和en-gbfr-fr和fr-CAzh-cn, zh-tw, .... - 事实上，在这种情况下，我知道它zh可以用作完整代码的简体中文zh-hans的主要语言。对于繁体中文，使用 , , 之类的代码，zh-tw正确的代码（规范）应该是.zh-hant-twzh-hkzh-mozh-hantQ1 :如何确定指定元语言的主要语言？
我需要一个至少包括葡萄牙语、英语和法语的解决方案。
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-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，但反之则不然。
一些参考资料
uloc_addLikelySubtagsICU 4.2 和更新版本（我认为是 4.0 草案uloc_minimizeSubtags）在uloc.h. 这实现了http://www.unicode.org/reports/tr35/#Likely_Subtagsuloc.h有处理想要与有的问题。但是它们有点无用，因为它们将 UEnumeration* 作为输入，并且没有公共 API 来构建 UEnumeration。uloc_acceptLanguageFromHTTPuloc_acceptLanguageflash.globalization命名空间中的 API 执行标记猜测和语言匹配 ( http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/flash/globalization/package-detail.html )。它适用于 TR-35，可以超越 @ 并考虑操作。例如， ifhave = [ ja ja@collation=radical ja@calendar=japanese ]和want = [ ja@calendar=japanese;collation=radical ]then 最佳匹配取决于您想要的操作。对于日期格式 ja@calendar=japanese 是更好的匹配，但是对于排序规则，您需要 ja@collation=radical您希望在葡萄牙或巴西拥有更多用户吗？相应地选择。
对于您的一般解决方案，您可以通过阅读Ethnologue找到答案。