2020 年，根據對歐洲、亞洲、北美和南美 29 個國傢和地區的 8709 名消費者的調查，語言服務咨詢機構 CSA Research 發現，76% 的人在網購時更喜歡購買用自己母語標示瞭信息的產品，40% 的人永遠不會從非母語網站上買東西。因此，CSA 給這份報告起的標題是《B2C：看不懂就不買》。

這再次印證瞭語言支持對於提升用戶體驗、促進用戶增長的重要性。CSA 認為，本地語言支持可以打造更具粘性的消費者關系，而且更強大的全球化品牌，也會極大地影響購買決策。

這也是為什麼專註於產品全球化咨詢的獨立商業咨詢師 John Yunker，會十幾年如一日地收集匯總和分析全球品牌網站的語言支持情況。他把網站或應用（主要是網站）上的語言選單——引導用戶進入本地化版本網站的登陸頁面和頁首菜單稱為「全球入口」（global gateway），當用戶打開一個非自己母語的網頁時，首先會尋找這個入口，把語言切換到自己的母語。

但在設計語言選單的時候，不同的公司/網站采取的策略各不相同，設計網站 http://SmashingMagazine.com 的主編、UX 設計師、前端開發者 Vitaly Friedman 就撰寫瞭一篇非常詳盡的文章，梳理分析瞭現有網站實現語言選單時的各種做法，最後總結出瞭非常具有實操價值的語言選單設計原則。

「產品本地化藍皮書」獲得 Vitaly Friedman 授權，獨傢翻譯並發佈該文的中文版。

---

假設你剛剛抵達東京。帶著（旅途勞頓帶來的）不耐煩和（剛剛抵達的）興奮，你準備開始自己的旅行，然而你的手機卡運營商發來緊急提醒，告訴你你的話費餘額急需充值。有些擔憂的你打開運營商的網站，卻被轉到瞭日語版網頁。你看不懂日語，可頁面上沒有明顯的選項來改變你所在的國傢，也沒有看到改變頁面語言的選項。

你的流量不斷減少，你在網頁自動翻譯和你有限的 VPN 選項之間左試右試，直到流量耗盡。網站上確實設置瞭語言選單，然而它被偽裝在隱秘的符號和神秘的圖標之間，一眼看過去就是找不到。

Stripe 在網頁頁腳設置瞭彈出式窗口，允許用戶跳轉到不同國傢版本的頁面

很有可能你也有過類似的經歷。作為設計師，我們當然可以讓語言選單更明顯、更醒目，然而大多數時候，網頁組件的外觀隻是問題的一個側面。

在設計界面時，我們很多時候會下意識地將自己個人的假設、偏見和期望融入工作中。當然，我們不可能考慮到所有例外和特殊情況，所以我們會專註於最常見的情況，結果精心設計的用戶體驗，卻因為某些情況導致瞭用戶的不滿。

其實要想解決這個問題，隻需要解耦預設、允許覆蓋（override），並允許用戶按自己的情況指定語言選項就行。但在我們深入研究語言選單的設計原則之前，不妨先探討一下目前有哪些方案可供選擇。

關於語言選單的小細節

通常情況下，我們知道什麼時候需要放一個語言選單。每個多語言網站都需要語言選單，對有多個官方/通行語言的國傢和地區的公共服務和公司來說尤為如此。對於全球化的品牌、組織和旅遊行業，以及可能以各種貨幣支付貨物、運送到世界各地不同目的地的電子商務網站，也必須設置一個語言選單。

海康威視在網頁右側設置瞭語言選單浮層

語言選單要放在什麼位置呢？用戶當然各有各的喜好。根據我的經驗，想要改變國傢/地區或語言設置時，絕大多數用戶會立即到頁首位置尋找，如果頁首沒有，他們會跳到頁面底部，在頁腳中查找。

在網頁上標示國傢和地區選單所在位置，國旗（旗幟）的效果就相當好，如果用戶沒有看到國旗，他們會尋找以其他方式代表一種語言的圖標——比如地球或「翻譯」圖標。當涉及到文章或具體頁面的翻譯時，用戶一般會依靠就近法則，在文章標題旁邊尋找語言選項。

Lululemon 官網右側有一個用於選擇顯示貨幣的側欄浮層。語言選擇用的是另一個下拉菜單

然而在設計的時候，我們需要考慮很多復雜的細節。當然，選單可以位於頁首或者頁腳的某個地方，但我們也可以根據用戶所處的位置自動跳轉，根據瀏覽器的偏好自動檢測語言，或者跳出一個彈框，要求用戶先選擇一個地區。可以使用的工具還包括文本標簽、縮寫、圖標或旗幟、原生或自定義下拉菜單、偏好設置面板、側邊欄、開關或者獨立頁面。

你會發現，以上很多解決方案本身就有可用性問題；如果要最大限度地提升溝通準確性、減少歧義，我們得想個適當的策略，做好語言標記、分組、展示，讓語言選單對用戶來說一目瞭然，同時還應避免影響無障礙和自動翻譯功能正常工作。

最一開始我們來聊一個顯而易見的原則——但也要註意：自動跳轉可能會有幫助，但它造成的挫折和煩惱多過它的益處。

避免自動跳轉

許多網站會基於用戶的位置（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, http://www.flagsarenotlanguages.com/blog/, James Offer
• My take on language selectors, https://uxdesign.cc/my-take-on-language-selectors-945caceb58f7, Zsolt Szilvai
• Accessible implementation details, https://uxdesign.cc/designing-language-selectors-that-work-well-with-assistive-technology-c645a16e73e7, Zsolt Szilvai
• UX practice: Skyscanner’s language selector, https://medium.com/nyc-design/ux-practice-skyscanners-language-selector-276167b4ed84
• Language switching UI/UX on multilingual sites, https://www.robertjelenic.com/language-switching-ui-ux-on-multilingual-sites/, Robert Jelenic
• Best practices for presenting website language selection, https://www.robertjelenic.com/language-switching-ui-ux-on-multilingual-sites/
• UI/UX design of a language selector, https://share-design.kr/en/article/ui-ux-design/1
• Interesting language selector patterns on Siemens Design System, https://ux.siemens-healthineers.com/ui-marcom/components/language-selection/usage/index.html
• Designing a language switch: Examples and best practices, https://usersnap.com/blog/design-language-switch/, Thomas Peham

Vitaly Friedman，UX 設計師，前端開發者，http://SmashingMagazine.com 主編。喜歡解決復雜的用戶體驗、前端和性能問題。

題圖來源：Shutterstock