TO B出海第一站:覆蓋18種多語言場景、打造國際化IT服務體系
#本文為人人都是產(chǎn)品經(jīng)理《原創(chuàng)激勵計劃》出品。
出海如今成為了很多企業(yè)的戰(zhàn)略,國內(nèi)卷不過,國外市場大有可為。和人一樣,產(chǎn)品想要出海,得先過語言關。由此帶來了IT產(chǎn)品的國際化需求,進而引發(fā)了IT產(chǎn)品功能的國際化改造,其中最突出的就是多語言支撐能力的推進。本文作者對此展開了分析,一起來看看吧。
自從中國加入WTO后,隨著政府一系列利國利民的政策發(fā)布,中國的高速發(fā)展之態(tài)勢已然勢不可擋,國內(nèi)市場已不再滿足中國企業(yè)的發(fā)展,國外市場已成為中國企業(yè)縱橫捭闔的戰(zhàn)地。中國企業(yè)爭先恐后的出海遨游,走向國際市場。
企業(yè)的國際化,必然帶來企業(yè)IT服務的國際化變革,以筆者效力的公司而言,正是因大刀闊斧的國際化拓展帶來的IT產(chǎn)品的國際化需求,引發(fā)了IT產(chǎn)品功能的國際化改造,這其中最突出的就是多語言支撐能力的推進。
筆者有幸主導過多套系統(tǒng)的多語言變革,特在此分享一些實操案例,與各位一起進步成長。
一、多語言產(chǎn)品現(xiàn)狀與場景研究
《孫子兵法·謀攻篇》 ——知己知彼方可百戰(zhàn)不殆。
要探索多語言的產(chǎn)品演進形態(tài),得先回歸看下多語言產(chǎn)品架構常犯的3大不良動作。
在筆者經(jīng)歷過的系統(tǒng)多語言架構變革中,經(jīng)常會出現(xiàn)各種不良,其中最突出的3點歸納如下:
1.1 多語言架構的3大不良
- 多語言元素缺斤少兩;多語言的邊界范圍梳理不全面,缺失體系化的多語言元素的盤點行為,造成多語言變革總是缺斤少兩,比如頁面多語言了,新聞公告忘記了等類似情況。
- 多語言架構單一僵化,認為只需加入語言條件即完成多語言變革,淺顯的將字段多語言實施方法泛化為所有元素的多語言實施方法,缺失體系化的多語言技術架構。比如部分主數(shù)據(jù)的多語言其實是源頭問題(EHR信息、法人信息等)、比如圖片多語言其實是設計標準問題。這些元素的多語言有不同的架構方法、并不能用字段多語言實施方法涵蓋。
- 多語言波及兼容乏陳:多語言變革只聚焦于元素的多語言化,而沒有對國際化的整體波及面進行評估,比如頁面的顯示要不要改造、網(wǎng)絡訪問的部署要不要改造、海外個人安全的方案要不要兼容等等。
1.2 用戶Mark的產(chǎn)品使用旅程
現(xiàn)以員工Mark的產(chǎn)品使用旅程為例,看如何推演出多語言產(chǎn)品元素、技術架構的搭建。
1)員工圖譜
2)員工Mark的產(chǎn)品使用旅程
從中可知多語言是包括很多方面的,在產(chǎn)品規(guī)劃設計階段輸出不良,則會有如牛鞭效應,將不良傳遞到項目周期的下一個階段,會帶來多語言產(chǎn)品設計不良,也會不斷放大,帶來技術架構設計不良。
如下圖所示:
1.3 多語言的場景分類
基于Mark的使用旅程,可進一步推演出多語言的元素分類。下面將多語言分為6個大類,分別為“通用元素類、字段類、圖片類、新聞公告類、外部系統(tǒng)傳入類、業(yè)務流類”。
該分類的標準有兩個,分別為“類別、來源”;其中元素類別(比如圖片、字段做區(qū)分)、元素的多語言來源(比如字段類和外部系統(tǒng)傳入類做區(qū)分)。
二、多語言能力中臺的技術架構
可能有些小伙伴會問,上面用6大多語言場景大類進行歸納整理的技術實現(xiàn)方法是什么呢?
下圖為多語言能力中臺技術架構圖:
三、通用元素類多語言產(chǎn)品設計
3.1 現(xiàn)狀分析
通用元素類是指所有系統(tǒng)中最普遍最廣泛的多語言類型,比如頁面標題、功能名稱、異常提示等。這類多語言場景更多是每個系統(tǒng)私有的多語言類型、不受外部關聯(lián)系統(tǒng)影響。
比如“功能名稱多語言”中“我的”這個字符,只要采用“ID、語種、內(nèi)容”即可完成多語言的設計,這種無需在此詳述。比較難的是帶有參數(shù)的通用元素類多語言,比如異常報錯。該類多語言不僅要在代碼架構上做好統(tǒng)籌規(guī)劃、而且還要考慮前端的用戶體驗。
因為這類內(nèi)容的普遍不良情況為:
- 報錯內(nèi)容因為沒有考慮到足夠多的參數(shù)形式,則會造成無法配置實現(xiàn)。比如“明細行的合同簽署方”,若開始沒有考慮到必須有“明細行”參數(shù),則會造成明細行字段無法實現(xiàn)多語言,無法通過配置實現(xiàn),必須寫死在代碼上;
- 報錯內(nèi)容沒有拆分成“問題描述”和“解決方案”,造成配置表無法兼容所有的通用元素;
3.2 設計目標
通用元素類涵蓋了頁面的通用組件類,比如分段控件、面包屑、導航菜單、選項卡。也包括異常提示類。通用元素類有一個明確的歸類標準“源數(shù)據(jù)源在本產(chǎn)品 + 字符元素組成”。
通用元素類的產(chǎn)品設計需要達成如下2個目標:
- 可兼容參數(shù):通用元素類既包含分段控件、也包括異常提示。分段控件的文本可全部翻譯即可,比如“我的”、“發(fā)現(xiàn)”;而異常提示卻包含參數(shù),比如“明細區(qū)的摘要不能為空”,摘要就是參數(shù)。故而通用元素類的產(chǎn)品設計先要兼容參數(shù)。
- 可一套代碼:通用元素類可用一套代碼框架做實施、構建的是多語言中臺技術能力中心。這套代碼框架不僅可兼容分段控件、也可兼容異常提示。
3.3 產(chǎn)品設計
我們舉一個例子來說明通用元素類的設計方案和技術架構,比如下面這一句異常報錯:
例子:明細行的合同簽署方和付款區(qū)的合同付款方必須一致,請進入我的合同查看該合同的詳細信息,確認合同簽署方信息。
這個例子在代碼架構上,可以采用“參數(shù)表達方式”來做表達,同時我們也可以將其拆分成“問題內(nèi)容”和“方案內(nèi)容”兩個部分,詳情如下:
從架構角度、所有的“通用元素類”內(nèi)容均可采用一個代碼架構來實施,下圖是通用元素類的后臺參數(shù)表,共由“3個必填 + 4個非必填”組成:
3.4 通用元素類多語言技術架構
基于此,我們可推演出“通用元素類”多語言場景的技術架構圖。在下圖中,一套程序方法就可將通用元素類的多種多語言場景做兼容。
四、字段類/外部系統(tǒng)傳入類多語言產(chǎn)品設計
4.1 現(xiàn)狀分析
很多小伙伴會疑惑,字段這么簡單的東西,在做多語言翻譯上有何技術架構,比如“供應商”,直接翻譯成“supplier”不就可以了,可實際執(zhí)行中,卻完全不是這么回事。在字段使用層面,一般會出現(xiàn)這幾種不良情況。
- 一個字段對應多個別名;比如供應商這個后臺字段,在實際使用時,有“供應商名稱”、“供貨方”、“供應者”、“交貨方”等這些別名。那“后臺字段名、前端別名、前端別名多語言”是什么關系呢?
- 一個字段的子項由外部系統(tǒng)傳輸;比如很多企業(yè)的供應商數(shù)據(jù)由“供應鏈中臺”端維護,或在SAP側維護,若外部系統(tǒng)沒有維護好多語言,則到底誰才應該為該類字段的多語言負責?
4.2 技術架構
下圖為字段類的技術架構圖,橫向上分為三層,分別為“字段層、別名層、別名多語言層”,縱向上分為“維度類型、維度成員”;
- 維度類型概念:字段名,比如“供應商”;
- 維度成員概念:字段名下的下拉子項,比如“深圳ABC有限公司”、“深圳DEF有限公司”。
從下圖可知、在維度類型這類多語言場景下。最底層是制度層、建立字段的唯一性標準和整個業(yè)務的主數(shù)據(jù)標準;再上面一層為字段層,字段要盡可能標準,不能出現(xiàn)兩個“供應商名稱”字段;基于標準的字段,上面則有別名層,每個字段有多個別名;同時在別名多語言下,則每個別名可配置多種語言表達方式。
基于不同產(chǎn)品特點,可設定哪種語種必填,比如有些企業(yè)在亞太市場,則亞太區(qū)的語言加一些國際通用語言,則可設置為必填。通過這樣的設計,不僅可極大的降低字段的復雜和冗余,而且還可降低字段的別名層面的運維配置工作量。
從上圖還可知,在維度成員這類多語言場景下。若是系統(tǒng)私有數(shù)據(jù),則依然可采用“字段層 > 別名層 > 別名多語言”的結構來維護;若維度成員是由外部系統(tǒng)傳入的,則為了保證內(nèi)容的準確性,不會由每個系統(tǒng)單獨去維護一套多語言,而會搭建一個數(shù)據(jù)中臺,由中臺做數(shù)據(jù)的統(tǒng)一定義,其他周邊系統(tǒng)全部調(diào)取這個中臺的數(shù)據(jù)源。
這里需要注意的一點時,針對維度成員,不允許新建多個別名,避免引發(fā)數(shù)據(jù)混亂。比如中國,英語只有“China”。
五、圖片類多語言產(chǎn)品設計
圖片類的產(chǎn)品架構也比較簡單,采用基礎的框架結構即可存儲,該結構為:ID + 語種 + 圖片標題 + 圖片URL;不過圖片類大部分小伙伴會忽略場景梳理。在整個系統(tǒng)中,圖片類主要包含如下場景:按鈕圖標、產(chǎn)品LOGO、下拉子項的備注說明、過渡圖標。
六、新聞公告類產(chǎn)品設計
6.1 產(chǎn)品設計
新聞公告類重點實現(xiàn)的是給不同語種的人發(fā)布對應語種的新聞公告。故而首先要給員工打標簽,這個標簽并不是運維配置實現(xiàn)的,而是在用戶使用系統(tǒng)的時候,根據(jù)用戶的登錄語言自動打標簽。然后在發(fā)布新聞公告的時候,則會自動將不同語種的文章發(fā)布到其主頁上。
6.2 技術架構
下圖中新聞公告多語言首先要搭建一個新聞公告中心,該功能平臺可針對一篇文章原稿(例A)編輯多份不同語種的文章(a1為中文/a2為英文)。然后系統(tǒng)自動根據(jù)用戶登錄系統(tǒng)所選的語言(英語),自動顯示a2文章給用戶。
七、業(yè)務流類多語言產(chǎn)品設計
在跨國家的業(yè)務流轉(zhuǎn)之中,錄入流程的人員和審批流程的人員率屬于不同國家,所以他們的語言也必然存在差異。很多跨國企業(yè)考慮翻譯會對源頭數(shù)據(jù)造成曲解,一般都會采用兩種方法來解決跨國業(yè)務流問題。
方法一為“源頭本地化、審批節(jié)點多語種化”;方法二為“源頭增加翻譯、審批和源頭統(tǒng)一語種”;
- 第一種方法是由本地語種人員錄入本地業(yè)務流數(shù)據(jù)、總部審批節(jié)點配備多語種人才;這種方法適用于數(shù)據(jù)源有很多本地化附件的場景、且這些附件內(nèi)容需要傳輸?shù)娇偛孔鲂r灆z查,比如財務報銷類;
- 第二種方法是在源頭增加一層翻譯節(jié)點,由翻譯節(jié)點人員將本地附件和內(nèi)容翻譯后向總部側傳遞,總部側無需新增多語種人才;這種方法適用于對數(shù)據(jù)結構化要求較高的場景,比如合同履約類。
八、多語言的顯示框架設計
8.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)境下用“橫排布局”,在其他語種下則自動切換成“錯行布局”。
第二方面:平鋪表格結構和跳轉(zhuǎn)九宮格結構;
同樣因為中文的簡練和整齊,不少中文系統(tǒng)會偏向用表格來布局頁面(這種布局我們稱之為“表格結構”)例圖1.3,將所有字段信息平鋪在頁面上,這樣會讓頁面顯得更整齊、也會讓頁面的學習成本降低;而在多語言環(huán)境下,因為多語言的長度不齊,則會造成頁面布局很混亂,所以我們一般會采用圖1.4
所示結構,這種結構會通過抽取最核心的字段在一個表格上,然后將其他信息采用子表的方式來展現(xiàn),子表布局為九宮格結構。
8.2 產(chǎn)品設計
在多語言產(chǎn)品設計中,我們不需要建設兩套前端框架,而要用一套“國際化”的前端框架去兼容國內(nèi)/海外的前端頁面結構。一方面是可以降低整個產(chǎn)品的開發(fā)成本,另外一方面可降低客戶的溝通困難。
我們在多語言產(chǎn)品的顯示框架下建立了三條準則:
一套標準的前端框架:
在TO B產(chǎn)品中,不同國家的人會針對一個頁面進行溝通,若這個頁面針對國內(nèi)人群顯示一套頁面框架,針對海外人群顯示一套頁面框架,則會極大的提升溝通成本。故而多語言前端框架則只有一套。頁面的框架、布局均是標準的。
一套靈活的配置體系:
在TO B產(chǎn)品中,為適應國內(nèi)/海外的語言,則定義了一套靈活的配置體系,該體系可配置標題和輸入框根據(jù)語言環(huán)境換行顯示、可配置表格區(qū)根據(jù)列數(shù)選用子表展開或單行顯示等等。
一套最兼容的前端規(guī)范:
在TO B產(chǎn)品中,在一套標準前端框架下,則需要做最兼容的前端規(guī)范,從而用最少的開發(fā)成本來解決最多元化的用戶場景。這個規(guī)范定義了標題的長度要與輸入框保持一致、定義了表格中列的最合適間距、圖標與圖標之間最合適的間距等。
8.3 案例分享&難點分析
8.3.1 難點分析
如下為筆者經(jīng)手的一款系統(tǒng),作為國際性企業(yè),該系統(tǒng)兼容了10種語言,如上的多語言框架和顯示框架均在該系統(tǒng)得到淋漓盡致的反映。
在產(chǎn)品成型的摸索過程中,也遇到了很多糾結和痛苦,主要有兩點。
在此分享給大家:
難點1:要不要以海外用戶習慣為依規(guī)
海外用戶有很明顯的性格特征,比如更遵守規(guī)則、更習慣流程和系統(tǒng)。而國內(nèi)用戶有更多個性訴求、也更愛挑戰(zhàn)規(guī)則。
在海外推廣中,團隊其實就受到這個挑戰(zhàn)。當時整個團隊分為兩大陣營。陣營一堅持一套前端顯示框架、對所有人均生效;陣營二堅持兩套前端顯示框架,依據(jù)海外用戶習慣搭建一套海外的顯示體系。
陣營二的小伙伴照搬了一款國際型的SAAS系統(tǒng),計劃將整個頁面都做copy(如下圖樣式)。從而實現(xiàn)國內(nèi)用戶登錄則顯示中文頁面;海外用戶登錄則顯示海外頁面(如下圖);
后面我們充分分析了人群和運作實際,最終整個團隊決定只用一套前端顯示框架。理由有二:
- 人群都是表哥表姐:該系統(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)正因為沒有體系化的多語言管理制度。造成大量該多語言翻譯的內(nèi)容沒有翻譯、多語言翻譯均是百度翻譯、行業(yè)術語沒有標準、圖標內(nèi)嵌中文字符、郵件公告沒有海外兼容等等問題。
也因為這些不良,造成團隊收到領導層的挑戰(zhàn)。痛定思痛之下,團隊快速響應,在一周內(nèi)就輸出了多語言管理制度,在系統(tǒng)維護、發(fā)文公告、設計樣式、術語規(guī)范、簡寫規(guī)則等方面做了一次體系化的整理。
一套系統(tǒng)的成功,IT系統(tǒng)改造完成只達成了20%的目標,另外80%還強依賴于運營。
8.3.2 案例分享
填單頁案例:
列表頁案例:
九、總結
相對于數(shù)字化轉(zhuǎn)型、營銷中臺、數(shù)字工廠4.0等高大上的概念而言,多語言是產(chǎn)品體系中小的不能再小的一個功能點。有些產(chǎn)品人眼光緊隨著都是前者這些聚光燈的概念,而忽視后者這些最基礎的功能點。
多語言初略看來就是對文字的語種做翻譯,而深究下卻有很多工作要去深度思考、要做好體系化的場景梳理、要做好差異化的技術架構、更要做好體驗改造和優(yōu)化。
產(chǎn)品路是珠峰路,得一步一個腳印,踏踏實實的攀登。謹以此言、與諸君共勉。
專欄作家
Boyka,人人都是產(chǎn)品經(jīng)理專欄作家。關注TO B、擁有大型企業(yè)多年企業(yè)端產(chǎn)品規(guī)劃和設計經(jīng)營,擅長產(chǎn)品團隊管理、產(chǎn)品戰(zhàn)略規(guī)劃、產(chǎn)品原型設計。
本文為人人都是產(chǎn)品經(jīng)理《原創(chuàng)激勵計劃》出品。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Unsplash,基于 CC0 協(xié)議。
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
填單頁案例的圖片放在文中的作用是?
我們目前只做了ID、語種和內(nèi)容的區(qū)分,沒有整可參數(shù)化的做法,看了覺得有點復雜,請問實操效果如何?
文章非常受益,寫的系統(tǒng)且深入。不過筆者可以考慮一下,從公司的角度,出海這么大場景里面,為了一個多語言整這么復雜的一套架構,投入如此之多的開發(fā)資源,roi 是否算的過來。筆者也考慮一下實際上出海創(chuàng)業(yè)公司,或者小企業(yè)的訴求,如何去落地這個場景
寫的不錯,很有啟發(fā)。
不過這個更多是產(chǎn)品設計層面的,針對不同國家的市場,像法規(guī)合理、隱私政策、第三方服務接入、云服務資源等等這些,尤其對C端產(chǎn)品能否也做一下分享,感謝。
感謝支持下一篇分享下隱私政策
非常感謝!!!非常非常有用!心里有底了