在XHTML和HTML中使用语言信息

当我开始XHTML 1.1的时候，我一直不知道应该在xml:lang上写什么好，我想使用中文，它的值是zh、zh-cn/zh-CN还是gb2312/gbk/gb18030或者utf8？通常遇到问题我都优先Google中文，无奈也是找不到答案。看到一些权威的网站上使用gb2312，我还差点相信了，但根据我使用Linux中设置语言的经验，我直觉告诉我这是错误的。于是开始了把范围缩小到W3C中去Google，找到了Tutorial: Using language information in XHTML, HTML and CSS (DRAFT)，细阅，终于走出误区，愿将经验与大家分享。

依旧是翻译，但这篇文章太长了，而且还有许多我们用不着的信息，这次我只选择了部分，希望能把问题说清楚就好。

声明文档与文本语言

为什么要声明语言

关于文档语言的信息对于屏幕阅读器和易用性都极为重要，从一开始就有利。这些程序需要了解它们是否能从文本中生成输出，或者是否需要转到不同的语言模式。

标记语言信息也对应用恰当的样式变更有好处。比如，需要改变字体来调节不同字符，依据语言来生成不用的引号等等。

有的浏览器使用语言信息为中文简体，中文繁体，日文和韩文来侦测适合的字体。但是，在一个使用Unicode编码的页面中，这些语言可能共享相同的表意字符内码。操这些语言的人可能在使用这些字符上的一些小细节上有所不同。下面的插图演示了仅仅改变语言标签，在Mozilla上的文本的效果：

同一表一字符在不同语言中的形状

标记语言信息也允许你使用脚本提取指定语言的元素。举个例子，使用XSLT lang()函数可以从一个文件中提取指定语言的文本，或者在XSL-FO转换的时候应用语言指定样式。

在许多的案例中，第一次开发内容时，你可能不会意识到这些应用的重要性，虽然它们在创建的时候一般非常容易添加，这就会在需要样式翻新时遇上麻烦。

另外，一些为语言标签标记的程序还在早期开发或者缺乏中，但是，从现在起你就应该为你的内容增加语言信息，以便在技术成熟的时候收获未来的好处。
总体上始终为文档在标签中声明语言

HTML文档总体上应该声明文档的语言，可以通过在html标签中增加lang属性来实现。比如，下面声明了一个使用加拿大法语（Canadian French）的文档：

稍后我们会更具体地讲述如何为语言属性指定值。

当把XHTML伺服为text/html，你应该在html元素中都使用lang属性和xml:lang属性。xml:lang属性是在XML中确定语言信息的标准用法。以下演示你应该如何标记先前以text/html伺服的XHTML 1.0的例子：

xml:lang属性在处理HTML文件时并没有实际用处，但从lang属性继承过来意味着你要使脚本或校验器把该文档当作XML。

如果你以XML（比如，使用像applications/xhtml+xml的MIME类型）或者XHTML 1.1来伺服XHTML的话，你不再需要lang属性，因为它已经跟HTML语言分离了。单独的xml:lang属性就已足够。

始终声明文本的语言变更

在与内容主要语言不同的文本中，应该指出该文本的语言。方法跟与总体上始终为文档在标签中声明语言这一节相同——使用lang或者xml:lang属性。例如，在HTML中你可以写作：

The French for Cat is chat.

lang属性可以用在除applet、base、basefont、br、frame、frameset、iframe、param和script之外的任何HTML元素上。

又，以text/html伺服的XHTML 1.0，可以一起使用两个属性，比如：

The title in Chinese is xml:lang="zh-CN"中国科学院文献情报中心.

注意了，在最后一个例子中，在中文文本的周围没有让我们可以附加语言信息的标记，为达到目的所以引入了span元素。(请查看该段的源代码——译者注)

如果以XML伺服XHTML，像上节所描述的那样，你应该只使用xml:lang属性。

指定语言属性的值

使用RFC 3066规则

RFC 3066是定义如何使用语言标签来识别语言的标准。

语言标签由一个主要的subtag，尾随零个或更多附属的subtag，由连字符分开。

主subtag代表一种语言（有两种例外，i-和x-，在下面会讨论），任意尾随的subtag服务于修饰该语言的方言或用法。后面的subtag一般代表国家，方言或文字体系。

下面的例子表明了该文档不仅使用英语而且还是英式英语，就是说，跟美式英语相对的英语写成的。

subtag对大小写是敏感的，包括从A到Z，a到z，0到9的字母和数字，而且不能多于8个字符。

需要注意的是HTML规范仍然推荐使用RFC 1766来确定语言。RFC 3066是RFC 1766的升级并且大大超越，而在HTML规范中有一个计划勘错表，因此你应该使用RFC 3066不管HTML规范的现阶段如何解说。
主subtag

所有的初始subtag必须是1，2或者3个字母的长度。所有2和3字母的subtag都是定义代码来代表语言的ISO 639 part 2中的语言代码。1个字母的subtag是一个i-或x-前缀，稍后我们会描述。

尽管代码是大小写敏感，它们经常小写，但这仅仅是一个惯例而已。

又注意，ISO提供2字母和3字母代码的选择时，你应该选择2字母的。这就确保了为每一种语言尽快地使用一个独一无二的代码，稍过时的使用2字母代码（基于 RFC 1766，不允许3字母长度的代码）数据也就不用更改了。同时，哪些3字母代码应避免的问题不是问题，因为所有的有两种不同的3字母代码的少数语言同时也会有2字母代码。

附subtag

增加附subtag可以表示地理区域，方言，文字体系，或者其他对主要（语言）subtag的改进。主subtag可以尾随任意数目的subtag，尽管多于一个的并不常见。

RFC 3066指出，任何位于次位置的2字母subtag都是ISO 3166国家代码。在任何第三位置或接下来的位置使用subtag都没有规则。

2字母的用以表示国家的ISO代码通常大写，但这也仅仅是一个惯例。
特殊的主subtag

RFC 3066定义了一些在可能不会从ISO语言代码开始的例子。

以i-开始的语言标签是为IANA注册语言标签（IANA-registered language tags）保留的。举些例子：

* i-mingo
* i-klingon
* i-tao

以x-开始的语言标签为用户自定义语言标签提供了构件。次位置上的标签必须多于一个字母，并且不能为以下的保留subtag：AA, QM-QZ, XA-XZ, and ZZ。

当然，在基于2字母或3字母的ISO代码可用的时候，这些识别语言的方法都不需要使用。这些方法用于限制或者防止可互用语言的混淆。

IANA注册语言标签

可以通过在RFC 3066提到的email提交程序来注册IANA语言标签。这些标签可以有3到8字母长的次位置代码。

注册IANA代码比使用用户自定义代码好，因为它最小化了混淆的可能性，因为IANA代码对其他人是显性的。另一方面，IANA标签是ISO标准声明不赞成的新代码。声明不赞成的IANA标签包括no-bok（挪威“Book语言”——使用ISO 639的nb），i-navajo（Navajo——使用ISO 639的lb），i-lux（(Luxembourgish——使用ISO 639的lb），还有其他更多的。基于此理由，IANA注册代码应该只临时出现，用以填补ISO代码的空缺。

尽管i-前缀为IANA代码所保留，但不是所有的IANA代码都是从它开始的。比如，有很多中文方言已经注册了IANA代码，包括zh-guoyu（国语，呵呵，为什么不是普通话putonghua？），zh-hakka（客家），zh-min（闽），zh-min-nan（闽南），zh-wuu（吴）等等。

同时，业已注册的IANA代码允许你指定繁体或简体中文。过去这必须为简体中文使用zh-CN（中国大陆）和为繁体中文使用zh-TW（中国台湾）。但你不能保证其他人认知甚至遵循这个惯例。比如，有人使用zh-HK来表示繁体中文。现在IANA使用了zh-Hans和zh-Hant代码分别指定简体中文和繁体中文。下面两段举例说明了这两个代码的使用：

当世界需要沟通时，请用Unicode！

當世界需要溝通時，請用統一碼（Unicode）

语言标签的其他要点

尽管大部分时候RFC3066语言标签运作良好，但仍然有以下一些问题：

* 需要比ISO所提供的更多的代码来转换世界上接近6000中的语言尚未覆盖需要表达通用区域的代码，比如，现在仍然没有为许多组织用以创建西班牙语内容的泛拉美西班牙语代码。
* 尚未覆盖需要表达通用区域的代码，比如，现在仍然没有为许多组织用以创建西班牙语内容的泛拉美西班牙语代码。
* 现在仍然缺乏语言标签值与locale的清晰性。locale是语言加上地理区域的组合，在软件中通常用来设置日期与时间之类的事情。
* 有时候确实需要区分使用附属于该语言的文字体系。比如，蒙古人可能写蒙语或斯拉夫语，克罗地亚也可能写拉丁语或者斯拉夫语……

现在来自ISO TC37，SIL和W3C的工作人员都在为这些问题的解决方案努力着。

同时，你应该始终记住，你可以在IANA注册你所需要的语言标签。