问题标签 [ietf-bcp-47]

根据关于 的Google 信息hreflang，我想出了这个，但我的en和默认指向相同的 URL，而不是另一个en/。那会好吗？我不想创建另一个文件夹，因为它需要额外的维护。

基本上，默认和主站点是英文的。如果用户需要查看其他语言，他们只需转到额外文件夹zh-*。

我也可以在 URL 中缩短必须zh-hanttocht和zh-hanstochs吗？

我正在为 iOS 应用程序编写服务器 API。作为初始化过程的一部分，应用程序应通过 API 调用将电话界面语言发送到服务器。

问题在于 Apple在其函数中使用了称为IETF BCP 47 语言标识符的东西。NSLocale preferredLanguages

返回的值有不同的长度（例如[aa, ab, ace, ach, ada, ady, ae, af, afa, afh, agq, ...]，我发现很少有解析器可以将此代码转换为适当的语言标识符。

我想使用更常见的ISO-639-2 三字母语言标识符，它无处不在，具有多种语言的许多解析器，并且具有标准的三字母语言表示。

如何将 IETF BCP 47 语言标识符转换为 ISO-639-2 三字母语言标识符，最好在 Python 中？

有没有一种聪明的方法可以在 Android 中为小于 21 的 API 获取 BCP47 语言代码？在 API 级别 21+ 中，Locale.toLanguageTag 正是我所需要的。你将如何在较低的 API 级别获得此功能？

我正在编写一个通过 HTTP 获取数据的 Android 应用程序。服务器端实现完全了解 IETF BCP 47（包括RFC 4647）。它解析Accept-Language标头并考虑用户的语言偏好，并具有优雅的回退。

为了利用这些功能，最好（至少有可能）从 Android 中获得不止一种语言。

例如，在 Chrome 中，我可以添加多种语言并根据我的个人喜好对其进行排序。我不知道 Android 平台上的此功能。

目前，我只是Locale.getDefault()，但我更愿意使用来自浏览器的List<Locale.LanguageRange>（来自 Java 8）通过Accept-Language.

1. 我是否忽略了正确的 Android API？如果是这样，请重新指出我。
2. Android甚至支持吗？如果不是，为什么不呢？是计划好的吗？

一段时间以来，我一直在使用类似的方法来获取用户所在的国家/地区（ISO-3166）：

我一直认为该字符串类似于en-US-- 国家将在数组的第二个位置。

我认为这个假设是不正确的。根据 MDN 文档，navigator.language返回：“表示 BCP 47 中定义的语言版本的字符串。” 阅读 BCP 47，保证主要语言子标签是第一个（例如，'en'），但不保证区域代码是第二个子标签。在区域子标签之前和之后可以有子标签。

例如"sr-Latn-RS"是一个有效的 BCP 47 语言标签：

navigator.language从BCP 47 的子集返回的值是否仅包含语言和区域？或者是否有一个库或正则表达式通常用于从语言标签中提取区域子标签？

我正在尝试通过运行命令aapt来测试功能。

但我收到了这个奇怪的错误信息。

诸如此类。

我正在使用 Gradle 3.0.1 来构建项目。是什么导致了这个错误？

我正在从 R 包中运行出色的 pandoc，依靠LaTeX babel 包来进行一些排版细节。

Pandoc期望lang参数为BCP 47代码（例如en-US），但babel期望它自己的语言代码（例如american）。

Pandoc 非常棒，在这个 haskell 脚本中映射了两者。

本着防御性编程的精神，我想在我的用户使用错误的语言代码时警告他们，并给他们一个明确的列表，列出这些可接受的 BCP 47 代码。

这样的列表（或向量，或其他）是否存在于 R 或包中的某个位置以方便使用？

我试图避免手动输入 pandoc haskell 脚本。

给定 IANA 时区 ID，例如"America/New_York"or "Europe/Lisbon"，我如何使用 ICU4C获取相应的BCP-47 时区 ID，例如"usnyc"or ？"ptlis"

这些值是生成带有扩展名的 Unicode BCP-47 区域设置 ID所必需的，例如'en-US-u-fw-mon-hc-h23-tz-usnyc“.

互联网上的许多文章（例如这篇文章）建议使用xml:lang或一些自定义属性来编码有关 XML 标记内的语言的元信息。他们提到这些代码必须符合BCP47 标准。

让我们看看如果我按照文章的建议对语言属性进行编码会发生什么：

1. 内部 DTD：<!ATTLIST text xml:lang NMTOKEN #IMPLIED>
2. 内部 XML：<text xml:lang="YODU991Yklew-e-ijsw02ijwk">...</text>

预期的结果是什么？

DTD 验证器将检查YODU991Yklew-e-ijsw02ijwk代码是否是真正的 BCP47 语言代码、国家和脚本是否存在并将其标记为红色，如果这些代码不正确。与http://schneegans.de/完全相同的方式有助于验证这些代码（错误代码与正确代码）。

相反会发生什么？

Validator 仅将此属性视为一些文本，并且不会验证，如果它是真实的语言代码或一些乱码。

辅助区域构造语言的本质是促进属于同一组语言的说话者之间的交流（参见泛浪漫语言、泛斯拉夫语言和泛日耳曼语言的示例）。

因此，在为此类语言选择最准确的 IETF BCP 47 语言代码时，会出现以下困境：

一方面，上述语言是人为的，对于这种情况有一个直接的选择art-x-langname。这适用于art-x-tokipona，art-x-solresol依此类推。

另一方面，区域语言虽然正在构建，但显然与现存语言有遗传关系，更重要的是，可以通过自动翻译工具很好地解释，例如谷歌翻译：

roa-x-neolatin因此，使用,等语言代码gem-x-folkspra而sla-x-interslv不是通用代码不是更准确art-x-...吗？

BCP47 本身是否有解决这种困境的方法？如果没有，是否有反对第二种解决方案（使用集体语言代码）的强烈论据？