如題。這些都不知道，還談啥國際化？

1.翻譯

產品要國際化，首當其沖就面臨一個問題——語言問題。所以必須要翻譯。

翻譯就翻譯唄，有啥要注意的？

總結起來，有這么兩點：

• 從項目進度來看，越早開始越好。因為翻譯完成，你才能進入設計、開發；
• 盡量節省一些翻譯費用。

翻譯費用其實挺貴的。有多貴呢？來，開開眼：

舉個例子：

• 假如要中譯英，翻譯一萬字（不多吧），費用約200*10 = 2000元。
• 假如要中譯西班牙語，翻譯一萬字，費用約400*10 = 4000元。

而一個產品往往長期運營，幾十萬字很正常吧，你看這費用，反正比咱搬磚的工資高。。。

如何節省費用？

說起來也簡單：盡量縮減語句，盡量去除標點符號。

為什么？因為翻譯社告訴我們：

根據中華人民共和國國家標準GB/T 19363.1-2003 對翻譯行業服務規范的要求，中文字數統計是以不計空格字符數為計算單位的?？赡芪覀兤綍r不是很注重標點符號，其實在文字表達中，標點符號的重要不亞于單字單詞，一個標點符號可以改變全句話的意思，而我們的工作也是做到了這一點，保證每個標點符號的準確，保證譯文表達的意思和原文一樣。

看到沒？一個標點符號也算一個字。

說到這，還有一個小插曲：翻譯社給的依據是國家標準GB/T 19363.1-2003，我去工標網查了下，發現這份標準早已作廢，現行的標準是GB/T 19363.1-2008。

不過，計字方法倒沒變，國標這么說：

怕翻譯社計算錯的話，就用office看看字數統計，如下圖：

2.切換語言的方式

切換語言看起來很簡單，不就是點擊、切換？并沒有這么簡單。

目前主流的切換語言方式有3種：

• 直接顯示語言選擇
• 直接顯示國家
• 顯示國家 + 語言選擇

所謂「存在即合理」，為何存在這三種？我們的產品應該選擇哪一種？這就取決于我們的用戶需求與產品目標。說白了，就是需求。

1）直接顯示語言選擇

例如BURSA MALAYSIA：http://www.bursamalaysia.com/market/

這種方式的適用場景是：

• 場景1：僅針對1個國家，但這個國家有幾種語言。比如馬來西亞國內的網站，需要3種語言，就可以做成這種形式。
• 場景2：針對多個國家，但每個國家只有1種語言。比如美國用英語、中國用中文，語言選擇上分別顯示英語、中文，點擊英語，則切換至針對美國用戶的界面；點擊中文，則切換至針對中國用戶的界面。
• 場景3：針對多個國家，但提供給每個國家的內容都完全相同。比如馬來西亞有英語，美國也有英語，這時馬來西亞的用戶、美國的用戶看到的界面完全相同。

2）直接顯示國家

例如蘋果：https://www.apple.com/choose-your-country/

這種方式的適用場景為：每個國家僅有一種語言。

PS：蘋果官網該頁面底部也提供了部分國家的多種語言，比如加拿大的法語、英語。

3）顯示國家 + 語言選擇

比如：https://www.malaysiaairlines.com/my/ms.html

這種方式的使用場景為：不同國家用戶的需求不同，而且提供給不同國家用戶的產品也不同，而且同一語言還對應多個國家。這時就要已國家為準。

比如馬來西亞，主要語種有3種：馬來語、英語、漢語。但你會發現，英語和漢語在多個國家都會使用。假如提供給馬來西亞的英文內容與提供給美國的英文內容不同，就不能直接通過語言來切換，而應以國家為切換標準。

3.URL

別看URL很簡單，也有一些注意點。

PS：這些注意點主要針對SEO。

對于不同語種，主流的URL使用方式有3種：

1）不同語種網站完全獨立，放在不同國家域名上

例如：ITDoer.com、ITDoer.cn、ITDoer.com.co.jp。谷歌采用的就是這種方式。

采用這種方式，優點在于用戶和搜索引擎都能很好地識別地理位置，但網站完全獨立，推廣上需要獨立推廣，耗時費力。

2）不同語種網站放在主域名的子域名上

例如：en.ITDoer.com、zh.ITDoer.com。維基百科采用的就是這種方式。

采用這種方式，優點在于可以繼承一些主域名的權重，但網站完全獨立，推廣上需要獨立推廣，耗時費力。

3）不同語種網站放在主域名的二級目錄下

例如：ITDoer.com/en/、ITDoer.com/cn/。蘋果采用的就是這種方式。

采用這種方式，優點在于二級目錄完全繼承主域名的權重。

但有人也說用戶和搜索引擎都可能對網站語種產生一定程度的混淆，有的還說不同二級目錄很難放在不同國家的主機上，技術上實現比較困難。不過這種方式其實很常見，個人認為可以采用。

4.兩類數據

產品國際化，必然會面臨如下兩類數據。這兩類數據直接決定了表結構設計。如果這點沒考慮到，就會被開發哥哥懟死……

• 獨立數據
• 公共數據

1）獨立數據

獨立數據即在前后端代碼中，不同語言對應的數據完全獨立。

例如對于微信的「朋友圈」這個按鈕，不同語言對應的數據就是獨立的。你在中文界面看到的是「朋友圈」三個字，而在英文界面則看到的是「Moments」。

對于獨立的數據，處理起來很簡單：

• 前端——翻譯所有字段名，寫死即可。
• 后臺——輸入對應字段對應語言的數據即可。

當然，「朋友圈」按鈕并不對應后臺數據。不過我們可以假設「朋友圈」按鈕的值取自后臺一個字段X，那中文的后臺就會輸入「朋友圈」，而英文的后臺則會輸入「Moments」。

2）公共數據

還有一部分數據處理起來比較麻煩，這就公共數據。

公共數據就是在前后端代碼中，不同語言對應的數據是公共的。

比如微信用戶名。不論你把微信的語言改成什么，你的用戶名都不會變。

但公共數據還得進一步細分：

a.不變的公共數據

比如用戶頭像、用戶名、用戶個性簽名、手機號碼、郵箱等。這類數據如果隨語言變化，就失去了原本的意義。

b.可變的公共數據

比如性別、溫度單位、地區名。

對于性別，用戶將中文字段 [性別] 設置為”男”，那么英文就會將字段 [性別] 顯示為字段 [gender]，而且其值為顯示為”male”。

這類數據其實可以不變，但改變語言之后，顯然體驗更好。

不變呢？其實用戶也能看懂——因為用戶肯定會選擇他熟悉的語言，更何況有些可變的公共數據還是用戶自己設置的信息，他若不熟悉，如何設置？

另外，開發哥哥還告訴我：前后端字段對應，才能做成一張表，才能做在后臺的同一個模塊。

也就是說：不同語種的網站字段如果不同，就不能共用一個后臺模塊，就必然導致數據的獨立。

本文由 @?ITDoer 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議