出海如今成為了很多企業(yè)的戰(zhàn)略，國內卷不過，國外市場大有可為。和人一樣，產(chǎn)品想要出海，得先過語言關。由此帶來了IT產(chǎn)品的國際化需求，進而引發(fā)了IT產(chǎn)品功能的國際化改造，其中最突出的就是多語言支撐能力的推進。本文作者對此展開了分析，一起來看看吧。

自從中國加入WTO后，隨著政府一系列利國利民的政策發(fā)布，中國的高速發(fā)展之態(tài)勢已然勢不可擋，國內市場已不再滿足中國企業(yè)的發(fā)展，國外市場已成為中國企業(yè)縱橫捭闔的戰(zhàn)地。中國企業(yè)爭先恐后的出海遨游，走向國際市場。

企業(yè)的國際化，必然帶來企業(yè)IT服務的國際化變革，以筆者效力的公司而言，正是因大刀闊斧的國際化拓展帶來的IT產(chǎn)品的國際化需求，引發(fā)了IT產(chǎn)品功能的國際化改造，這其中最突出的就是多語言支撐能力的推進。

(資料圖)

筆者有幸主導過多套系統(tǒng)的多語言變革，特在此分享一些實操案例，與各位一起進步成長。

01 多語言產(chǎn)品現(xiàn)狀與場景研究

《孫子兵法·謀攻篇》 ——知己知彼方可百戰(zhàn)不殆。

要探索多語言的產(chǎn)品演進形態(tài)，得先回歸看下多語言產(chǎn)品架構常犯的3大不良動作。

在筆者經(jīng)歷過的系統(tǒng)多語言架構變革中，經(jīng)常會出現(xiàn)各種不良，其中最突出的3點歸納如下：

1. 多語言架構的3大不良

1）多語言元素缺斤少兩

多語言的邊界范圍梳理不全面，缺失體系化的多語言元素的盤點行為，造成多語言變革總是缺斤少兩，比如頁面多語言了，新聞公告忘記了等類似情況。

2）多語言架構單一僵化

認為只需加入語言條件即完成多語言變革，淺顯的將字段多語言實施方法泛化為所有元素的多語言實施方法，缺失體系化的多語言技術架構。比如部分主數(shù)據(jù)的多語言其實是源頭問題（EHR信息、法人信息等）、比如圖片多語言其實是設計標準問題。這些元素的多語言有不同的架構方法、并不能用字段多語言實施方法涵蓋。

3）多語言波及兼容乏陳

多語言變革只聚焦于元素的多語言化，而沒有對國際化的整體波及面進行評估，比如頁面的顯示要不要改造、網(wǎng)絡訪問的部署要不要改造、海外個人安全的方案要不要兼容等等。

2. 用戶Mark的產(chǎn)品使用旅程

現(xiàn)以員工Mark的產(chǎn)品使用旅程為例，看如何推演出多語言產(chǎn)品元素、技術架構的搭建。

1）員工圖譜

2）員工Mark的產(chǎn)品使用旅程

從中可知多語言是包括很多方面的，在產(chǎn)品規(guī)劃設計階段輸出不良，則會有如牛鞭效應，將不良傳遞到項目周期的下一個階段，會帶來多語言產(chǎn)品設計不良，也會不斷放大，帶來技術架構設計不良。

如下圖所示：

3. 多語言的場景分類

基于Mark的使用旅程，可進一步推演出多語言的元素分類。下面將多語言分為6個大類，分別為“通用元素類、字段類、圖片類、新聞公告類、外部系統(tǒng)傳入類、業(yè)務流類”。

該分類的標準有兩個，分別為“類別、來源”；其中元素類別（比如圖片、字段做區(qū)分）、元素的多語言來源（比如字段類和外部系統(tǒng)傳入類做區(qū)分）。

02 多語言能力中臺的技術架構

可能有些小伙伴會問，上面用6大多語言場景大類進行歸納整理的技術實現(xiàn)方法是什么呢？

下圖為多語言能力中臺技術架構圖：

03 通用元素類多語言產(chǎn)品設計

1. 現(xiàn)狀分析

通用元素類是指所有系統(tǒng)中最普遍最廣泛的多語言類型，比如頁面標題、功能名稱、異常提示等。這類多語言場景更多是每個系統(tǒng)私有的多語言類型、不受外部關聯(lián)系統(tǒng)影響。

比如“功能名稱多語言”中“我的”這個字符，只要采用“ID、語種、內容”即可完成多語言的設計，這種無需在此詳述。比較難的是帶有參數(shù)的通用元素類多語言，比如異常報錯。該類多語言不僅要在代碼架構上做好統(tǒng)籌規(guī)劃、而且還要考慮前端的用戶體驗。

因為這類內容的普遍不良情況為：

報錯內容因為沒有考慮到足夠多的參數(shù)形式，則會造成無法配置實現(xiàn)。比如“明細行的合同簽署方”，若開始沒有考慮到必須有“明細行”參數(shù)，則會造成明細行字段無法實現(xiàn)多語言，無法通過配置實現(xiàn)，必須寫死在代碼上；

報錯內容沒有拆分成“問題描述”和“解決方案”，造成配置表無法兼容所有的通用元素；

2. 設計目標

通用元素類涵蓋了頁面的通用組件類，比如分段控件、面包屑、導航菜單、選項卡。也包括異常提示類。通用元素類有一個明確的歸類標準“源數(shù)據(jù)源在本產(chǎn)品 + 字符元素組成”。

通用元素類的產(chǎn)品設計需要達成如下2個目標：

可兼容參數(shù)：通用元素類既包含分段控件、也包括異常提示。分段控件的文本可全部翻譯即可，比如“我的”、“發(fā)現(xiàn)”；而異常提示卻包含參數(shù)，比如“明細區(qū)的摘要不能為空”，摘要就是參數(shù)。故而通用元素類的產(chǎn)品設計先要兼容參數(shù)。

可一套代碼：通用元素類可用一套代碼框架做實施、構建的是多語言中臺技術能力中心。這套代碼框架不僅可兼容分段控件、也可兼容異常提示。

3. 產(chǎn)品設計

我們舉一個例子來說明通用元素類的設計方案和技術架構，比如下面這一句異常報錯：

例子：明細行的合同簽署方和付款區(qū)的合同付款方必須一致，請進入我的合同查看該合同的詳細信息，確認合同簽署方信息。

這個例子在代碼架構上，可以采用“參數(shù)表達方式”來做表達，同時我們也可以將其拆分成“問題內容”和“方案內容”兩個部分，詳情如下：

從架構角度、所有的“通用元素類”內容均可采用一個代碼架構來實施，下圖是通用元素類的后臺參數(shù)表，共由“3個必填 + 4個非必填”組成：

4. 通用元素類多語言技術架構

基于此，我們可推演出“通用元素類”多語言場景的技術架構圖。在下圖中，一套程序方法就可將通用元素類的多種多語言場景做兼容。

04 字段類/外部系統(tǒng)傳入類

多語言產(chǎn)品設計

1. 現(xiàn)狀分析

很多小伙伴會疑惑，字段這么簡單的東西，在做多語言翻譯上有何技術架構，比如“供應商”，直接翻譯成“supplier”不就可以了，可實際執(zhí)行中，卻完全不是這么回事。在字段使用層面，一般會出現(xiàn)這幾種不良情況。

一個字段對應多個別名；比如供應商這個后臺字段，在實際使用時，有“供應商名稱”、“供貨方”、“供應者”、“交貨方”等這些別名。那“后臺字段名、前端別名、前端別名多語言”是什么關系呢？

一個字段的子項由外部系統(tǒng)傳輸；比如很多企業(yè)的供應商數(shù)據(jù)由“供應鏈中臺”端維護，或在SAP側維護，若外部系統(tǒng)沒有維護好多語言，則到底誰才應該為該類字段的多語言負責？

2. 技術架構

下圖為字段類的技術架構圖，橫向上分為三層，分別為“字段層、別名層、別名多語言層”，縱向上分為“維度類型、維度成員”；

維度類型概念：字段名，比如“供應商”；

維度成員概念：字段名下的下拉子項，比如“深圳ABC有限公司”、“深圳DEF有限公司”。

從下圖可知、在維度類型這類多語言場景下。最底層是制度層、建立字段的唯一性標準和整個業(yè)務的主數(shù)據(jù)標準；再上面一層為字段層，字段要盡可能標準，不能出現(xiàn)兩個“供應商名稱”字段；基于標準的字段，上面則有別名層，每個字段有多個別名；同時在別名多語言下，則每個別名可配置多種語言表達方式。

基于不同產(chǎn)品特點，可設定哪種語種必填，比如有些企業(yè)在亞太市場，則亞太區(qū)的語言加一些國際通用語言，則可設置為必填。通過這樣的設計，不僅可極大的降低字段的復雜和冗余，而且還可降低字段的別名層面的運維配置工作量。

從上圖還可知，在維度成員這類多語言場景下。若是系統(tǒng)私有數(shù)據(jù)，則依然可采用“字段層 > 別名層 > 別名多語言”的結構來維護；若維度成員是由外部系統(tǒng)傳入的，則為了保證內容的準確性，不會由每個系統(tǒng)單獨去維護一套多語言，而會搭建一個數(shù)據(jù)中臺，由中臺做數(shù)據(jù)的統(tǒng)一定義，其他周邊系統(tǒng)全部調取這個中臺的數(shù)據(jù)源。

這里需要注意的一點時，針對維度成員，不允許新建多個別名，避免引發(fā)數(shù)據(jù)混亂。比如中國，英語只有“China”。

05 圖片類多語言產(chǎn)品設計

圖片類的產(chǎn)品架構也比較簡單，采用基礎的框架結構即可存儲，該結構為：ID + 語種 + 圖片標題 + 圖片URL；不過圖片類大部分小伙伴會忽略場景梳理。在整個系統(tǒng)中，圖片類主要包含如下場景：按鈕圖標、產(chǎn)品LOGO、下拉子項的備注說明、過渡圖標。

06 新聞公告類產(chǎn)品設計

1. 產(chǎn)品設計

新聞公告類重點實現(xiàn)的是給不同語種的人發(fā)布對應語種的新聞公告。故而首先要給員工打標簽，這個標簽并不是運維配置實現(xiàn)的，而是在用戶使用系統(tǒng)的時候，根據(jù)用戶的登錄語言自動打標簽。然后在發(fā)布新聞公告的時候，則會自動將不同語種的文章發(fā)布到其主頁上。

2. 技術架構

下圖中新聞公告多語言首先要搭建一個新聞公告中心，該功能平臺可針對一篇文章原稿(例A)編輯多份不同語種的文章（a1為中文/a2為英文）。然后系統(tǒng)自動根據(jù)用戶登錄系統(tǒng)所選的語言（英語），自動顯示a2文章給用戶。

07 業(yè)務流類多語言產(chǎn)品設計

在跨國家的業(yè)務流轉之中，錄入流程的人員和審批流程的人員率屬于不同國家，所以他們的語言也必然存在差異。很多跨國企業(yè)考慮翻譯會對源頭數(shù)據(jù)造成曲解，一般都會采用兩種方法來解決跨國業(yè)務流問題。

方法一為“源頭本地化、審批節(jié)點多語種化”；方法二為“源頭增加翻譯、審批和源頭統(tǒng)一語種”；

第一種方法是由本地語種人員錄入本地業(yè)務流數(shù)據(jù)、總部審批節(jié)點配備多語種人才；這種方法適用于數(shù)據(jù)源有很多本地化附件的場景、且這些附件內容需要傳輸?shù)娇偛孔鲂ｒ灆z查，比如財務報銷類；

第二種方法是在源頭增加一層翻譯節(jié)點，由翻譯節(jié)點人員將本地附件和內容翻譯后向總部側傳遞，總部側無需新增多語種人才；這種方法適用于對數(shù)據(jù)結構化要求較高的場景，比如合同履約類。

08 多語言的顯示框架設計

1. 產(chǎn)品分析

經(jīng)過前面的產(chǎn)品規(guī)劃和技術架構，多語言的結構體系基本完成。接下來則需對多語言的顯示框架和運營體系進行建設。

首先，我們要先回歸中文和其他語言之間的最大差異，中文較于其他語言最大的特點就是，中文名詞在長度上比其他語種更短，也更為精練和準確。比如中文的“供應商名稱”，在英文里面就是“”；可以比較一下兩者之間的長度，若在系統(tǒng)上，則中文會顯得非常整齊精練，而其他語言則會遮擋從而顯示不全。

多語言的長度帶來的系統(tǒng)的改變，在系統(tǒng)設計層面主要體現(xiàn)幾個方面：

第一方面：橫排布局與錯行布局；

因為中文的簡練和整齊，不少中文系統(tǒng)都采用下圖1.1所示的方式來設計頁面，這種設計我們稱呼為“橫排布局”。可在多語言環(huán)境下，這種設計就會帶來不良的體驗，因為字段名均被遮擋了，所以在多語言環(huán)境下，系統(tǒng)將要采用圖1.2所示的方式來布局，我們稱之為“錯行布局”。

當然程序可以設計根據(jù)語言環(huán)境自動切換不同布局，比如在中文環(huán)境下用“橫排布局”，在其他語種下則自動切換成“錯行布局”。

第二方面：平鋪表格結構和跳轉九宮格結構；

同樣因為中文的簡練和整齊，不少中文系統(tǒng)會偏向用表格來布局頁面（這種布局我們稱之為“表格結構”）例圖1.3，將所有字段信息平鋪在頁面上，這樣會讓頁面顯得更整齊、也會讓頁面的學習成本降低；而在多語言環(huán)境下，因為多語言的長度不齊，則會造成頁面布局很混亂，所以我們一般會采用圖1.4

所示結構，這種結構會通過抽取最核心的字段在一個表格上，然后將其他信息采用子表的方式來展現(xiàn)，子表布局為九宮格結構。

2. 產(chǎn)品設計

在多語言產(chǎn)品設計中，我們不需要建設兩套前端框架，而要用一套“國際化”的前端框架去兼容國內/海外的前端頁面結構。一方面是可以降低整個產(chǎn)品的開發(fā)成本，另外一方面可降低客戶的溝通困難。

我們在多語言產(chǎn)品的顯示框架下建立了三條準則：

一套標準的前端框架：

在TO B產(chǎn)品中，不同國家的人會針對一個頁面進行溝通，若這個頁面針對國內人群顯示一套頁面框架，針對海外人群顯示一套頁面框架，則會極大的提升溝通成本。故而多語言前端框架則只有一套。頁面的框架、布局均是標準的。

一套靈活的配置體系：

在TO B產(chǎn)品中，為適應國內/海外的語言，則定義了一套靈活的配置體系，該體系可配置標題和輸入框根據(jù)語言環(huán)境換行顯示、可配置表格區(qū)根據(jù)列數(shù)選用子表展開或單行顯示等等。

一套最兼容的前端規(guī)范：

在TO B產(chǎn)品中，在一套標準前端框架下，則需要做最兼容的前端規(guī)范，從而用最少的開發(fā)成本來解決最多元化的用戶場景。這個規(guī)范定義了標題的長度要與輸入框保持一致、定義了表格中列的最合適間距、圖標與圖標之間最合適的間距等。

3. 案例分享&難點分析

1）難點分析

如下為筆者經(jīng)手的一款系統(tǒng)，作為國際性企業(yè)，該系統(tǒng)兼容了10種語言，如上的多語言框架和顯示框架均在該系統(tǒng)得到淋漓盡致的反映。

在產(chǎn)品成型的摸索過程中，也遇到了很多糾結和痛苦，主要有兩點。

在此分享給大家：

難點1：要不要以海外用戶習慣為依規(guī)

海外用戶有很明顯的性格特征，比如更遵守規(guī)則、更習慣流程和系統(tǒng)。而國內用戶有更多個性訴求、也更愛挑戰(zhàn)規(guī)則。

在海外推廣中，團隊其實就受到這個挑戰(zhàn)。當時整個團隊分為兩大陣營。陣營一堅持一套前端顯示框架、對所有人均生效；陣營二堅持兩套前端顯示框架，依據(jù)海外用戶習慣搭建一套海外的顯示體系。

陣營二的小伙伴照搬了一款國際型的SAAS系統(tǒng)，計劃將整個頁面都做copy（如下圖樣式）。從而實現(xiàn)國內用戶登錄則顯示中文頁面；海外用戶登錄則顯示海外頁面（如下圖）；

后面我們充分分析了人群和運作實際，最終整個團隊決定只用一套前端顯示框架。理由有二：

人群都是表哥表姐：該系統(tǒng)是一款報銷系統(tǒng)，雖然使用者有普通員工，但是產(chǎn)品的運營方就是財經(jīng)體系的表哥表姐，這類人群最習慣的就是表格。所以要用最習慣的顯示框架來設計系統(tǒng)。作為TO B產(chǎn)品，不能僅僅考慮普通員工（C端用戶），更要考慮運營人群（B端客戶）。

界面都為效率服務：作為TO B產(chǎn)品，人群非常復雜，在日常工作中就經(jīng)常會截頁面圖來做溝通，若一個系統(tǒng)兩套前端框架，則會造成溝通界面缺失。極大影響公司運營效率。

難點2：要不要建體系化的多語言管理制度

在國際化推進伊始，整個團隊的重心ALL IN在系統(tǒng)設計層面，對多語言管理制度雖偶有討論，但均不是認為很重要。所以團隊并沒有建立多語言管理制度。

可隨著國際化推進進行快速發(fā)展期，卻發(fā)現(xiàn)正因為沒有體系化的多語言管理制度。造成大量該多語言翻譯的內容沒有翻譯、多語言翻譯均是百度翻譯、行業(yè)術語沒有標準、圖標內嵌中文字符、郵件公告沒有海外兼容等等問題。

也因為這些不良，造成團隊收到領導層的挑戰(zhàn)。痛定思痛之下，團隊快速響應，在一周內就輸出了多語言管理制度，在系統(tǒng)維護、發(fā)文公告、設計樣式、術語規(guī)范、簡寫規(guī)則等方面做了一次體系化的整理。

一套系統(tǒng)的成功，IT系統(tǒng)改造完成只達成了20%的目標，另外80%還強依賴于運營。

2）案例分享

填單頁案例：

列表頁案例：

09 總結

相對于數(shù)字化轉型、營銷中臺、數(shù)字工廠4.0等高大上的概念而言，多語言是產(chǎn)品體系中小的不能再小的一個功能點。有些產(chǎn)品人眼光緊隨著都是前者這些聚光燈的概念，而忽視后者這些最基礎的功能點。

多語言初略看來就是對文字的語種做翻譯，而深究下卻有很多工作要去深度思考、要做好體系化的場景梳理、要做好差異化的技術架構、更要做好體驗改造和優(yōu)化。

產(chǎn)品路是珠峰路，得一步一個腳印，踏踏實實的攀登。

謹以此言、與諸君共勉。

關鍵詞：