何时使用语言协商

语言协商的缺点

语言协商显然是有用的，但在全面实施语言协商之前，了解它的局限性很重要。为了说明这些，我们将使用www.example.be这个网站作为例子，该网站以佛兰德语、法语和德语提供其内容，启用了语言协商，所有页面默认为佛兰德语。一个用户名为Sylvia，她的母语是意大利语，但也会说德语。可能会出现几种情况：

1. Sylvia的浏览器配置正确，用户偏好首先是意大利语，其次是德语。www.example.be上没有意大利语，页面以德语返回，Sylvia很开心，一切都很好。这就是语言协商的目的！
2. Sylvia是一个非技术人员，从未听说过HTTP语言协商，也从未修改过浏览器设置。浏览器的语言是意大利语，默认表达用户对意大利语的偏好（这里没有问题）。点击www.example.be，发现没有意大利语，所以只能返回网站默认的佛兰德语，即使网站有德语版。这种情况不太好。
3. Sylvia没有使用自己的浏览器，而是坐在莫斯科的一家网吧里。那里的浏览器被配置为（或默认是）俄语。她看到的网站又是佛兰德语。这种情况同样不好。

现在情况很清楚了：语言协商并不总是能给出预期的结果。

此外，当各语言的页面不等价，也就是内容有所不同时，语言协商甚至毫不相关。单语言和多语言网站一文对此进行了一些说明，请特别参阅多语言，相同内容和多语言，内容适配这两个小节。但是请注意，某些文化适应措施（例如更改货币）并不一定会使页面不等价；只有当一个网站的不同语言版本的页面无法相互对应时，才不适合使用语言协商。

弥补不足

尽管有其局限性，语言协商仍然是一个有用的功能，我们也希望在多语言站点中实现它。但是，我们必须设法弥补语言协商的不足。简而言之，重要的是为访问者提供在语言协商结果不正确时覆盖自动选择的语言的方法。这意味着在页面中放置可以链接到其他语言的组件（我们在这里将它们称为语言控件）。当然，这些控件对不熟悉当前页面语言的用户来说必须要清晰易懂。

那么问题来了：我们应该对所有页面实现语言协商和手动语言控制，还是只对主页实施？最好的答案是“所有页面”，除了那些不够等价的页面以外。语言协商很好，因为如果Jaap将www.example.be网站上的链接通过电子邮件发送给Pierre，即使Jaap访问的是佛兰德语版的页面，Pierre看到了法语版也会很高兴。无论是否实现语言协商，网站都必须提供语言控制。如果没有协商，Pierre将需要手动从Jaap的链接切换到法语版本；即使有语言协商，Sylvia也需要在上述情况2和3中手动切换到德语。

顺便说一句，当用户偏好与网站的可用语言不匹配时，一些网站会选择返回一个专门的语言选择页面（www.example.be可以这样做而不是返回佛兰德语）。这样做的好处是可以清楚地说明情况，并且不会让一种语言优先于其他语言，因为这可能是一个政治敏感问题。然而，有些网站总是返回这个语言选择页面（用于主页）而不是实现语言协商。这会迫使每个人总是浏览该页面，却没有提供明显的优势，这样对用户不够友好。

页面导航

假设Sylvia访问www.example.be后看到的是佛兰德语页面（情况2或3），然后切换到德语并继续阅读，这不算太麻烦。但她随后点了一个链接以访问该站点中一个有趣的页面。哎呀，又是佛兰德语！幸运的是，她还可以切换到德语。但经过几次这样的弯路之后，她感到沮丧也是可以理解的。难道www.example.be就不能记住她不懂读佛兰德语吗？这里需要的是显式语言选择的粘性。

www.example.be可以通过多种方式来实现这种粘性。选择哪一个将取决于服务器端的底层技术以及可花费的时间。

如果站点实现了会话（session）机制（例如使用cookie），那么把语言变成会话状态的一部分是一件相当简单的事情。一旦Sylvia切换到了德语，她的选择就会被存储（在cookie本身或服务器中，以与cookie中的会话号匹配），从那时起，她在浏览的网页就会是德语版的。我们甚至可以使cookie持久化（尽管这会使隐私问题更加严重），以便Sylvia下次返回www.example.be时自动获取德语页面。有登录机制的站点还可以将语言偏好存储为用户设置的一部分，并相应地提供正确语言的页面，而语言协商仅用于没有登录的用户。