Matrix 首页推荐 

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。 
文章代表作者个人观点，少数派仅对标题和排版略作修改。

2020 年，根据对欧洲、亚洲、北美和南美 29 个国家和地区的 8709 名消费者的调查，语言服务咨询机构 CSA Research 发现，76% 的人在网购时更喜欢购买用自己母语标示了信息的产品，40% 的人永远不会从非母语网站上买东西。因此，CSA 给这份报告起的标题是《B2C：看不懂就不买》。

这再次印证了语言支持对于提升用户体验、促进用户增长的重要性。CSA 认为，本地语言支持可以打造更具粘性的消费者关系，而且更强大的全球化品牌，也会极大地影响购买决策。

这也是为什么专注于产品全球化咨询的独立商业咨询师 John Yunker，会十几年如一日地收集汇总和分析全球品牌网站的语言支持情况。他把网站或应用（主要是网站）上的语言选单——引导用户进入本地化版本网站的登陆页面和页首菜单称为「全球入口」（global gateway），当用户打开一个非自己母语的网页时，首先会寻找这个入口，把语言切换到自己的母语。

但在设计语言选单的时候，不同的公司/网站采取的策略各不相同，设计网站 SmashingMagazine.com 的主编、UX 设计师、前端开发者 Vitaly Friedman 就撰写了 一篇非常详尽的文章，梳理分析了现有网站实现语言选单时的各种做法，最后总结出了非常具有实操价值的语言选单设计原则。

「产品本地化蓝皮书」获得 Vitaly Friedman 授权，独家翻译并发布该文的中文版。

假设你刚刚抵达东京。带着（旅途劳顿带来的）不耐烦和（刚刚抵达的）兴奋，你准备开始自己的旅行，然而你的手机卡运营商发来紧急提醒，告诉你你的话费余额急需充值。有些担忧的你打开运营商的网站，却被转到了日语版网页。你看不懂日语，可页面上没有明显的选项来改变你所在的国家，也没有看到改变页面语言的选项。

你的流量不断减少，你在网页自动翻译和你有限的 VPN 选项之间左试右试，直到流量耗尽。网站上确实设置了语言选单，然而它被伪装在隐秘的符号和神秘的图标之间，一眼看过去就是找不到。

很有可能你也有过类似的经历。作为设计师，我们当然可以让语言选单更明显、更醒目，然而大多数时候，网页组件的外观只是问题的一个侧面。

在设计界面时，我们很多时候会下意识地将自己个人的假设、偏见和期望融入工作中。当然，我们不可能考虑到所有例外和特殊情况，所以我们会专注于最常见的情况，结果精心设计的用户体验，却因为某些情况导致了用户的不满。

其实要想解决这个问题，只需要解耦预设、允许覆盖（override），并允许用户按自己的情况指定语言选项就行。但在我们深入研究语言选单的设计原则之前，不妨先探讨一下目前有哪些方案可供选择。

关于语言选单的小细节

通常情况下，我们知道什么时候需要放一个语言选单。每个多语言网站都需要语言选单，对有多个官方/通行语言的国家和地区的公共服务和公司来说尤为如此。对于全球化的品牌、组织和旅游行业，以及可能以各种货币支付货物、运送到世界各地不同目的地的电子商务网站，也必须设置一个语言选单。

语言选单要放在什么位置呢？用户当然各有各的喜好。根据我的经验，想要改变国家/地区或语言设置时，绝大多数用户会立即到页首位置，如果页首没有，他们会跳到页面底部，在页脚中查找。

国家和地区选择标示，国旗（旗帜）的效果就相当好，如果用户没有看到国旗，他们会寻找以其他方式代表一种语言的图标——比如地球或「翻译」图标。当涉及到文章或具体页面的翻译时，用户一般会依靠 就近法则，在文章页首旁边寻找语言选项。

然而在设计的时候，我们需要考虑很多复杂的细节。当然，选单可以位于页首或者页脚的某个地方，但我们也可以根据用户所处的位置自动跳转，根据浏览器的偏好自动检测语言，或者跳出一个弹框，要求用户先选择一个地区。可以使用的工具还包括文本标签、缩写、图标或旗帜、原生或自定义下拉菜单、偏好设置面板、侧边栏、开关或者独立页面。

你会发现，以上很多解决方案本身就有可用性问题；如果要最大限度地提升沟通准确性、减少歧义，我们得想个适当的策略，做好语言标记、分组、展示，让语言选单对用户来说一目了然，同时还应避免影响无障碍和自动翻译功能正常工作。

最一开始我们来聊一个显而易见的原则——但也要注意：自动跳转可能会有帮助，但它造成的挫折和烦恼多过它的益处。

避免自动跳转

许多网站会基于用户的位置（IP 地址）或浏览器语言设置自动跳转。然而，人在东京并不意味着 Ta 能流利地阅读日语；用户的首选地区是荷兰，并不意味着他们想把买的东西送到荷兰；如果用户的首选地区是法国，网站却没有法语版，用户则会碰到默认语言的页面，而这种语言不一定是他们最熟悉的语言。

如果不先询问用户，我们无法自信地推断他们的偏好。但这并不是说我们应该不惜一切代价避免自动跳转。如果一个用户碰巧从德国访问一个美国网站，把他们引向德语页面是完全合理的。但是，如果一个浏览器首选语言为英语的德国用户访问一个德语网站，那自动跳转到该网站的英国或美国英语页面，就会让人摸不到头脑——尽管在某些罕见的情况下，这很可能恰好符合了用户的意图。

一般来说，基于用户位置跳转可能比基于浏览器语言跳转更有指导意义，但前者依然很容易出错。

在第一次访问 Dyson.com 时，网站页首会提示访问者选择首选地区和语言。用户可以点击取消这个提示栏，之后在页脚找到语言选单。

Backcountry 是一家美国户外装备和服装公司，它会自动将其用户跳转到另一个页面，因为自 2018 年起，为避免违反 GDPR 规定，该网站不再向美国以外的地区提供服务，这些用户不用 VPN 就无法访问该网站，为在美国的朋友购买和配送礼物。

奥迪 会自动将用户跳转到一个它认为最适合的国家对应的页面。不过用户可以通过点击右上角的语言选单来选择自己所在的国家和地区，点了之后会出现一个带有自动完成功能的文本框，以及暂时无法点击的「继续」按钮。

全球版 BMW 网站 不会自动将用户跳转到任何网页。用户可以在页面右上角找到「BMW in your country」的选项，点击会打开一个弹框，列出所有选项，上面的「BMW in your country」按钮也会变得醒目，点击它，就会跳转到被认为是最适合的地区网站。

宜家 没有自动跳转，但有一个非常显眼的选单，里面包括了世界上各大国家的域名、内名（endonyms）和语言。它的「Go shopping」按钮可能是世界上最大的，大到可能值得登上世界吉尼斯纪录。不过在宜家网站上，你可以设置国家和地区，但不一定能设置语言。

虽然礼貌的跳转是合理的，但自动跳转不尽合理。不经询问，就把用户从一个网站跳转到另一个网站，其实就是在设计中植入了我们的假设，而这种做法通常是不可取的，也难怪会有用户感到不解，甚至放弃使用你的产品。讽刺的是，很少有人去跟踪了解这部分数据，因为放弃使用这件事发生在「另一个」网站上，而那个网站通常由在地球另一端的另一个部门或团队管理。

无论我们是想把用户引向另一个网站，还是就是必须使用自动跳转，最好能允许用户用手动设置覆盖自动跳转。这就要求我们驯服自己的假设，把相关预设解耦。

解除位置和语言预设之间的绑定关系

许多网站有一种假设，即位置、语言和货币通常是紧密绑定的，比如用户的位置选择德国，他们可能会更喜欢浏览德语，希望价格以欧元标示。然而，这种假设对一些人有效，但对其他人来说，则会完全破坏他们使用产品的体验。

例如，如果你想在德国从 阿迪达斯 官网上购买运动鞋，把它送给你在波兰的朋友，你就要确保在结账时能看懂波兰语。你可以选择用德语浏览、配送到德国，也可以选择用波兰语浏览、配送到波兰，但不可以在配送波兰的选项中选择用英语浏览网站。也就是说，语言和地点之间的关系绑得死死的。

事实证明，在很多情况下，这个假设是行不通的，比如：

• 一个人正在使用德国的 VPN，但他人不在德国，也不懂德语。
• 一个人从德国访问网站，但可能只是去德国几天，而且 Ta 可能根本不会说、也不懂德语。
• 一个人住在德国，用德语访问一个网站，但喜欢用公司的信用卡支付美元，而不是用欧元。
• 一个居住在德国的人可能想从一家美国商店给一个美国朋友送一件东西，但却一直被转到德国版网站。
• 一个人从美国访问网站，但 Ta 需要能够在结账时提供增值税号，因为负责采购产品的是一家德国办事处，用的也是德国信用卡支付。

当然，我们可能会认为所有这些情况都是非常罕见的边缘案例，所以选择忽略它们。但首先，我们需要记录一下有多少人真正遇到了这样的问题，并因此而最终放弃使用你的产品。在实践中，尤其是对于全球品牌来说，这些数字可能比你想象的更大。

之所以有这些问题，是因为我们把常见的情况框定在紧密绑定的、甚至缺乏灵活性的预设中。当然，预设作为默认选项有其用处，但当默认预设不够好的时候，情况就会失控。解除预设之间的绑定、让用户分别做选择，其实是个好主意。

在 Mondraker 上，用户可以分别选择所处位置和语言。所有国家被分为了几个选项卡，用户可以在底部选择自己愿意使用的语言。这种做法的缺点是：根据选定的国家选择语言，可能不如先选语言再选国家效率高。

Monese 在页首右上角显示了两个选项卡。用户可以在语言和国家/地区之间切换，分别定义各自的偏好。

用户的偏好不一定仅仅局限于国家/地区和语言。我们还可以让用户自定义用户界面的其他元素，比如货币、自动翻译、计量单位、日期格式等等。

允许用户设置自定义首选项

对于许多网站，语言和所处位置只是传达网站和用户匹配度的第一层重要属性。然而，为了向用户提供价值，我们可能要再多想一步。

Revolve.com 会根据用户的 IP 和浏览器的区域设置**，使用预设的语言、国家/地区和货币设置。不过用户可以用自定义的偏好来覆盖这些预设值。他们可以选择配送国家/地区、网站上显示的语言和货币。首选项的提示位于页首，由语言代码缩写、旗帜和货币代码组合而成。

这些细节足以显示所有产品的最终价格，包括到相应地区的配送费用和用户最熟悉的金额。它实现了所处位置、语言和货币的完美解绑。

Airbnb 推荐语言时搭配显示了对应地区，但也允许用户调整自己的偏好，选择自己喜欢的语言和地区。此外，用户可以选择将房源描述和评论自动翻译成自己选择、且 Airbnb 支持的任意一种语言。点击页首右上角的地球图标，就会出现这个弹框。

设置完毕后，用户可以在不同旅行目的地之间切换，比较相同货币下的房价，评论也会自动翻译成自己熟悉的语言。这给用户带来了极大的便利。

iHerb 则更进一步，为用户提供了一整套额外偏好。用户不仅可以选择他们的语言、首选货币和配送目的地（对于美国的目的地还可以用邮政编码指定），还可以选择首选计量单位、检查可用的支付方式和可用的配送供应商。这些选项也没有选择老式的下拉菜单，而是采用了可以智能自动补全的菜单。

在 道富环球投资管理 的网站上，用户可以定义一些特殊的偏好。用户首次访问网站会出现一个弹框，向用户解释网站对用户所在地和他们访问网站目的的一些假设。在这个弹框里，用户可以改变自己所在地点，指定自己的身份，选择自己首选访问的网站类型。

总地来说，通过选择这些选项，用户就掌握了主动权，从而由自己来定制访问网站的体验，如：

• 配送地点
• 货币单位
• 计量单位
• 时间/日期格式
• 时区偏好
• 自身经验水平

当然，问题的关键在于，如何向用户展示所有这些设置。是用一个单独的设置页面，用侧栏？放在页首还是页脚？其实一种选择，是在用户进入网站时，通过一个模态或非模态弹框显示这些设置——不过这种方案尚且存在争议。

非模态弹框案例

「产品本地化蓝皮书」注：模态弹框是一个出现在主内容之上的对话框，它使系统进入一个需要用户交互的特殊模式。用户和主内容的互动会暂时被这个对话框封闭，直到用户明确地与模态对话框进行交互之后才会恢复。

无可否认，模态弹框其实 不太算个好主意，它打破了用户流程，需要用户立即采取行动，所以容易让人生厌。然而，当我们需要提醒用户关注重要细节时——比如数据丢失、相互排斥的设置、关键错误——用它还是很合适的。

上面列出的一些网站在用户首次访问时就会跳出一个模态弹框，要求用户在使用网站前指定他们的意图和偏好。在其他网站上，默认的预设会默默应用，如果需要的话，用户可以选择调整——有时采用弹框，有时需要到专门的页面。

虽然模态弹框总是会被用户注意到，但 可用性测试显示，它们常常被本能地忽略，有时甚至连用户还没意识到弹框说了什么东西，就被点掉了。另一方面，由于用户非常专注于产品，他们也往往不会注意到导航栏上货币选择、计量单位或配送地点这类信息。只有必须要变更语言时，他们才可能注意到其他可以调整的设置项。

Booking 没有使用选项卡的模式，而是在页首为货币和语言使用了独立按钮。它会根据用户设备信息推断出一些设置，并直接应用，用户也可以重新选择，覆盖预设选项。它没有采用 <select>下拉菜单——它通常是最慢的表单组件，所有选项都以纯文本形式显示，因此可以通过浏览器内搜索功能进行搜索。

相较之下，Skyscanner 允许用户点一个大按钮弹出所有的可以定制的选项，并将选项分进了几个下拉菜单中。另外，如果用户不小心错选，界面总会自动退回到英文。

哪个选项更好？ 最终当然要通过可用性测试来决定。在语言选单这个特定案例中，在用户进入时显示模态弹框可能不算坏主意，因为它为用户提供了实际的价值——一个他们自己可能无法发现的价值。然而，可能另一种替代方案的效果更好——使用非模态对话框代替。

进入 Patagonia 网站时，会在左下角弹出一个固定的非模态弹框。用户可以选择地点和语言，并将他们的偏好保存在 cookie 里。用户也可以通过访问页脚的偏好栏随时打开语言选单。

在上面的模拟图中，重要的内容并没有被模态弹框挡住，用户可以滚动、导航、选择和复制粘贴。然而，偏好窗格出现在屏幕的右下部，可以被折叠或最小化，但它确实需要用户操作。这样做比默默地放在全局导航栏里更有干扰性，但也更容易发现。

如果你不确定你的项目的最佳选择，可以考虑先在导航栏中添加一个链接。测试一下 设计相关的关键指标，看看采用更少干扰和更友好的非模态弹框和模态弹框，结果会如何变化。模态弹框的表现很可能会比想象中更好。

采用点击式的浮层菜单

大型企业非常明白一点：在一个小小的浮层、甚至是较大的弹框中浏览几十个地区选项，是件相当麻烦的事，需要相当精细的滑动页面才能做到。因此，经常有网站在不同页面上展示所有可用选项，按区域划分，有时还配上旗帜来说明。

Revolut 在一个单独的专门页面上显示所有可用的选项。这些国家是用英语显示的，按区域分组并按字母顺序排列。然而，这个页面不仅展示了可用的地区，还展示了尚未可用的地区。对于这种特殊情况，允许用户自行过滤可能是一个好主意，比如隐藏所有不可用的地区，也许可以在列表上方设置一个切换按钮或选项卡。

罗技 网站上显示的大多数语言用的都是相对应的本地文字，例如，「Deutschland」代表德国，「中国」代表中国。这让即使看不懂英语的用户也能找到他们选择的地区或语言。在页面上，所有地区（和可用的语言）都按地域分组，并通屏分栏显示，方便用户寻找。

戴尔 没有把所有地区显示在一个长长的页面上，而是分选项卡、按地域把地区进行了分组。它没有使用国旗，所以查找起来有点儿困难。国家/地区和语言也被合并在了一起，这样一来，用户查找时就无需太多滑动页面。

并非所有网站的选项卡都长一个样。思科 使用了一个带有垂直选项卡的小浮层，显得非常紧凑，解决方案也非常简单明了。值得注意的是，选项卡的主要缺点，是内容无法通过页面内搜索查找（起码 目前是这样）。用户也总是得先选择一个地域才能进一步选择国家/地区。

当然，还有一个办法是采用垂直的手风琴菜单来分组国家。eDreams 就是这样做的。你可能因此需要更多的垂直空间，但所有的选项都可以从上到下一次性扫过。

甲骨文 的官网上有个稍显不同的国家选单：点击式的浮层菜单，所有国家都被分组排布，而不是显示一个独立的页面。这是一个非常紧凑和直接的解决方案。

如果你需要显示大量语言，可以尝试是否可以将其分组并显示在一个页面上。如果页面因此变得太挤，可以考虑将它们分组放进手风琴菜单或选项卡内——前提是设计成简单明了的选项卡样式，没有奇怪的文本标签。或者也可以采用更好的选择：为用户提供直击目标的自动完成建议。

显示自动完成建议

把自动完成弄对并不容易。如果我们同时处理国家/地区和语言，这个方案就不太容易实施。为了让自动完成更好用，我们需要支持常见缩写、本地说法，以及所有可用选项的简称。当然，我们的自动完成建议应该同时显示国家/地区和语言，并且提供单独选择国家/地区或语言的选项。此外，还可能要考虑支持多种「主要」语言（比如英语、法语、西班牙语）。这么一说，自动完成方案可一点也不容易啊！

在 Framework 上，用户可以分别选择国家/地区和语言，两者都有自动完成功能，最常用的选项被突出显示，用户无需在国家/地区列表中滚动寻找。虽然这在某些情况下可能完全够用，除非用户的国家/地区没有在列表中出现。这种时候，我们可以显示与用户输入选项位置最接近的地区，而不要将用户引向死胡同。

在上面的模拟图中，点击「附近的 4 个地点」可以打开一个手风琴菜单，突出显示离立陶宛最近的地点，格式上做缩进。当用户是想开立新的银行账户时，这种模式可能不太适用，但如果用户要找的是某个特定的办公地点时，这个方案可能就有用了。

Wise 还提供了语言设置的自动完成功能。如果相同的语言出现在多个项目中，自动完成功能会指定它指的是哪个国家。所有语言选项都以其本地文字呈现。

保时捷 使用了手风琴菜单浮层以及自动完成功能。该界面支持缩写，并以旗帜图标显示了可用选项。

毋庸置疑，自动完成功能是语言选单很好的补充。然而在测试时，我们要观察一下人们如何使用自动完成功能，以及他们实际输入什么文字来寻找自己的国家。有时，为了使自动完成功能适用于不同语言而进行的微调，可能会是一项难度不低、过于耗时的工作。

把国家/地区分组显示

并非每一个地点或语言都要在语言选单中用单独的条目表示。如果多个国家使用同一种语言，那能不能按语言分组显示国家呢？

Daniel Marchini 提出了一个 有趣的概念，即在语言选单里按语言显示国家旗帜。如果多个国家使用的语言完全相同，真的有必要将它们分成不同的条目显示吗？例如，葡萄牙语这个选项对应葡萄牙和巴西两个国家，西班牙语则对应墨西哥和西班牙。显然，不是所有国家都可以这样分组，但如果你的目标用户来自特定的国家，这个方案可能值得一试。

Airwallex 的国家选单将所有欧洲国家归到了「欧盟」选项下。它的服务适用于整个欧盟，因此没必要选择个别国家。然而，如果选单稍微长一点，而要寻找在荷兰开立银行账户的选项，你可能稍后才能意识到，荷兰被假定为欧盟内的一个国家。

使用旗帜表示国家，用文本标签表示语言

设计国家/地区选单时，考虑使用各国旗帜几乎是很自然的选择，毕竟与单纯的文本相比，国旗显然是让用户一目了然的选项。这的确是事实，然而正如 James Offer 在他关于 旗帜不能代表语言 一文中所说，旗帜由每个国家/地区特有，但语言往往是跨越国界的。

加拿大、越南、塞内加尔、瑞士和许多其他国家都有讲法语的人，如果认为所有来自这些国家的用户都将他们选择的语言与法国国旗联系起来，那肯定是不准确的。

在 我对语言选单的看法 一文中，Zsolt Szilvai 展示了一个关于这一难题的有趣例子。在对为阿联酋设计的一个应用进行可用性测试时，许多人发现阿拉伯语是用某一国的旗帜表示的。但因为阿拉伯语在许多国家使用，因此不能用任何一个国家的国旗来表示。

Curve.com 设置了一个默认的国际版英文页面，另外还有一些其他选项，但人们可能想知道「国际（英语）」和「英语（美国）」之间的区别。当用旗帜来表示语言时，情况就会有点混乱。

Backmarket 在页脚放了一排旗帜来表示各个本地版本的网站。当我们想把用户引向特定的本地版本网站时，用旗帜代表国家是最安全的，但不能用来表示语言。许多网站会直接在页脚添加本地版本站点的链接，这样用浏览器页面搜索也能方便地找到。

用旗帜代表国家/地区，用纯文本代表语言。Bol.com 似乎都做对了。国家选单（带着国旗）位于页面右上角，也是大多数用户所习惯去寻找的位置。

为避免误解，如果你的用户需要选择某个特定的国家/地区，请一定使用旗帜。然而，如果你为用户提供的是某种特定语言的选项，使用旗帜可能就不会有良好效果，不如使用自动完成功能列出所有可用的国家，并在旁边放上语言文本标签。

这就引出了下一个问题：这些标签究竟应该怎么写？是用英语还是用一种语言的本地写法呢？

使用语言的本地写法作为文本标签

假设很容易出错，对于货币、语言和所处位置的组合是这样，对用文本标签标记语言也是如此。我们不应该假设用户说的语言，就是我们选择作为默认选项的语言。相反，当用户选择一种语言时，通常最好使用该语言的本地写法来标记它。

因此，与其选项里假设用户能看懂英文，写 German 和 Chinese，不如把这些选项标记为 Deutsch 和 中文。

但是，如果语言选项都用本地写法标注，那碰巧到中国的外国人切换到自己母语时可能会遇到问题。当然，使用旗帜可以帮助人们找到语言选单按钮，但我们也可以用一个标签来修饰语言选单的按钮，例如在前面加上「Language」标签，让它更容易被发现。我们也可以在页首添加一个标了「English」的链接。当然，这些也都是我们的假设，但可能会比在导航栏和网页源码两个页面里跳来跳去容易一些。

Booking 用悬浮提示来告诉用户可以在本地版本页面更改成其他语言。如果你选择使用悬停提示（这种情况比较少见），可以考虑在悬浮文本中使用一个许多用户能看懂的语言，比如英语。

使用地球图标和翻译图标

既然使用旗帜可能出问题，那什么才是旗帜的合理替代物呢？正如文章开头简要提到的，我们也可以用表示「地球」或「翻译」的图标来表示地区和语言选单。还有一个 官方语言图标，可以免费使用，但不幸的是，它仍然没有其他图标那样容易识别。

当然，不是每个人都能理解与他们几乎看不懂的单词结合在一起的图标，但如果它被放在页首或页脚的显眼位置，被人们发现的机会就会大大增加。

Tomorrow.one 在每个页面的页脚显示一个大大的下拉选单，上面有一个地球图标。在它的页首是没有这个菜单的。如果页面不是很长，这可能不是一个大问题，但如果用户不得不滚动很久才能到页脚，或者页面的 无限滚动 让人们无法滚动到页脚，他们就可能会放弃这种努力。

在 Atlassian 的官网上，语言选单被隐藏在页面最末端的页脚中，用一个地球仪图标表示。然而如果用户使用另一种浏览器语言设置打开网站，它就会在页面最上方建议更改语言，那儿也会出现一个地球图标。

Monday.com 将语言选单放在了页面的最上方左上角的位置。所有选项都以三栏形式呈现，当前的选择以蓝色突出显示。

虽然旗帜更容易识别，但图标也可以作为一种替代选项，特别是当你需要让用户选择语言而不是位置的时候。即使在页首提供了选单，把它同时放在底部也是一个安全的选择，这样能确保用户在需要时能方便地找到它。

避免使用语言简写或缩写

Zsolt Szilvai 在测试中 发现的另一个有趣的问题，与使用缩写、首字母或代码来表示语言有关。当导航栏的空间不足时，我们可以用「EN」表示英语，「DE」表示德国，「UA」表示乌克兰。事实上，这些缩写通常都很好理解，但当用户使用浏览器的自动翻译翻译网站时，它们会带来令人惊讶的结果。

自动翻译不仅经常会让菜单爆框、破坏布局，它也会翻译语言速记，产生的界面可能非常难以理解。然而，如果避免使用缩写，转而使用用当地文字书写的语言全称，用户就完全不必处理这些问题了。请译员人工翻译文本，也会让人们寻找自己的母语版本页面变得更容易。

N26.de 使用缩写「EN」表示英语。选中的语言在选项列表中不可点击，但提升一下颜色对比度可能会更好。当用户向下滚动页面时，页首仍然是固定在最上方的，所以真的没有必要在页脚也显示语言选单。

Wise 在右上角使用缩写来标记语言选单，但在点击时会显示语言的全名，并用了明显的焦点样式来显示用户当前所在的位置。这就避免了自动翻译的问题，因为自动翻译经常把缩写变成随机字符串。

结语

国家和语言选单看起来好像是一个相当微不足道的设计挑战，但是有很多小细节决定了体验的好坏。在设计选单时，一定要抛弃预设，尽量少些可以把某些选项放在一起的想法。用户希望语言选单位于每个页面的页首或页脚，他们经常会通过旗帜、「地球」或「翻译」图标来寻找它。

如果你的产品只支持几种语言，一个下拉浮层可能就完全足够了。如果你需要显示 10-15 种语言，也许值得尝试带有自动完成功能的非模态浮层。如果有更多选项需要显示，可以考虑使用一个独立页面，将国家/地区组织到选项卡或手风琴菜单里。

语言选单设计检查清单

最后还是一个检查清单，包括了设计更好的语言选单时要考虑的一些重要原则。

• 可以用页面跳转，但避免自动跳转。
• 解除位置、语言或其他选项之间的绑定关系。
• 允许用户设置自定义偏好（货币、时区、计量单位）。
• 考虑使用非模态弹框。
• 把国家/地区和语言分区显示，或者放进选项卡或手风琴菜单里。
• 提供带有自动完成建议的输入框。
• 可以用旗帜代表国家，但不要用旗帜来代表语言。
• 考虑使用 地球 和 翻译 图标，避免使用旗帜。
• 用本地文字标记语言，例如用 Deutsch 代替 German。
• 避免使用语言代码或缩写。
• 出于无障碍的考虑，把国家选单放到页首和页脚，并且可以用键盘快捷键使用。

参考资料

• Flags are not languages, James Offer
• My take on language selectors, Zsolt Szilvai
• Accessible implementation details, Zsolt Szilvai
• UX practice: Skyscanner’s language selector
• Language switching UI/UX on multilingual site, Robert Jelenic
• Best practices for presenting website language selection
• UI/UX design of a language selector
• Interesting language selector patterns on Siemens Design System
• Designing a language switch: Examples and best practices, Thomas Peham

Vitaly Friedman，UX 设计师，前端开发者，SmashingMagazine.com 主编。喜欢解决复杂的用户体验、前端和性能问题。

「产品本地化蓝皮书」（productloc）公众号是宣讲互联网产品全球化/本地化实践的平台，如果你也有兴趣和我、和大家分享自己对产品本地化的见解，请在下文或公众号留言告诉我，或者和我在 LinkedIn 上建立联系。

> 下载 少数派 2.0 客户端、关注 少数派公众号，解锁全新阅读体验 📰 

> 实用、好用的 正版软件，少数派为你呈现 🚀