1. 背景
隨着京東各業務板塊國際化進程的不斷推進，諸多業務已經融入了多元文化中，一個一體化的多語言系統解決方案成爲各個技術團隊討論的焦點。國際物流系統憑藉在國際化領域多年的經驗，特別是在系統多語言處理上長期的經驗積累，總結了一套標準的系統多語言框架，旨在爲大家提供幫助，避免各系統在國際化進程中重複的調研。這篇文章將由淺入深地論述如何從項目伊始就構建多語言，包括文化敏感性的準備、本地化流程的自動化、技術實施的策略、以及用戶體驗優化的細節。
2. 國際化多語言原理介紹
國際化多語言是指將應用程序的功能和代碼設計抽象化，使其能夠適應不同地區的語言、貨幣、日期格式等需求，而無需對產品核心邏輯進行大的修改的一種方法，其核心思想是將文本內容從代碼中分離出來，存儲在獨立的國際化資源文件中，再根據用戶的語言偏好動態加載和替換顯示內容。這一過程使得應用程序能夠在全球範圍內使用，提高用戶體驗，並考慮到不同文化背景的用戶需求。從大的方面分類，系統國際化分爲前端和後端兩部分，下文將簡述國際化多語言各個部分的實現原理。
2.1. 前端國際化
前端頁面直面客戶，是國際化多語言中最重要的一環，前端國際化主要進行頁面靜態資源和後端交互兩部分的改造。在目前流行的前端框架中，比如React和Vue都提供了成熟的國際化工具，無須自己實現，大大簡化了前端國際化的過程，其工作原理通常涉及以下幾個步驟：
通過使用這些成熟的國際化工具，開發者可以更加輕鬆地實現前端國際化，提高產品的全球競爭力。這些工具不僅提供了豐富的功能和靈活的配置選項，還與主流的前端框架緊密集成，使得前端國際化變得更加簡單和高效。
2.2. 後端國際化
目前不論是JAVA本身，還是SPRING框架，都有成熟的方案支持國際化，實現基本思路是相同的，在此以SPRING框架爲例進行介紹。當前在進行系統的國際化過程中，整體5個步驟是非常成熟的，核心技術沒有大的差異，主要的變化點在第一步註冊之前的詞條抽取和最終國際化取值方式。
核心類說明：
1. ApplicationContext：ApplicationContext是 Spring 框架的核心接口之一，它負責管理 Spring 容器中的 beans，包括 bean 的實例化、配置和管理。在國際化中，ApplicationContext可以用來定義和加載不同語言環境下的配置文件，比如 properties 文件。
2. ResourceBundleMessageSource：ResourceBundleMessageSource是 Spring 提供的實現MessageSource接口的一個類，主要用於加載資源文件（通常是 properties 文件）。資源文件包含了鍵值對，其中鍵是國際化的標識符，值是對應的語言文本。ResourceBundleMessageSource能夠支持基於文件系統的資源 bundle，也可以配置爲其他來源，如類路徑、URL 等。
3. MessageSourceAccessor：MessageSourceAccessor是ResourceBundleMessageSource的一個便捷包裝類，它提供了一些便捷的方法來訪問和獲取國際化消息。通過MessageSourceAccessor，開發者可以更容易地獲取到國際化消息，而不需要直接操作ResourceBundleMessageSource。
4. LocaleContextHolder：是一個實用類，用於持有當前線程的LocaleContext封裝了當前的國際化信息，比如當前的語言環境和時區。使用LocaleContextHolder可以方便地在整個應用程序中共享國際化設置。
5. RequestContextFilter:RequestContextFilter是 Spring MVC 中的一個組件，主要用於在請求的生命週期中注入和保存上下文信息。雖然RequestContextFilter本身不是專門用於國際化的，但可以用來在請求範圍內傳遞國際化相關的信息，如當前的語言環境。
首先，在應用程序啓動時，系統會預先加載所有預設的語言詞條；其次，在用戶發出請求時，系統會基於當前應用的上下文環境解析出相應的本地語言信息；最後，根據解析結果返回相應語言類型的響應。儘管國際化技術原理看似清晰易懂，並且市場上已有成熟的框架可供使用，但要想構建一個專業且支持多語言的國際化系統，我們必須直面衆多挑戰，並全面考慮每個語種的特性。
3. 國際化多語言關鍵環節
爲了構建一個支持國際化多語言的系統，無論是前端還是後端，都需要進行以下四個主要方面的改造工作：一是提取和整理國際化資源文件；二是對文本文檔進行語言相關的替換；三是實現處理國際化邏輯的代碼；四是進行界面和功能的自適應性調整以適應不同語言和文化習俗。
1. 國際化資源文件抽取和翻譯：首先需要從現有代碼中，將所有面向用戶的詞條通過合適的工具進行抽取，形成獨立於代碼之外的配置文件，比如前端的js文件，後端的properties文件，所有詞條形成中文資源文件、英文資源文件以及其他目標語言文件，每種文件內都包含相同的 key:value鍵值對類型的詞條。如下圖分別是國際化系統的中文和英文詞條文件中的內容。對於頁面詞條的提取可選擇合適的國際化庫或框架（如I18next、React-i18next、Vue-i18n、Intl.js等），從而快速的完成。
2. 文本文檔替換：在開發過程中，將需要國際化的文本內容通過特定標識（如國際化鍵（key））引用，而不是直接嵌入到代碼中。這樣，無論應用程序在什麼語言環境下運行，都可以通過這些標識找到對應的翻譯文本，如下是前端VUE框架下的頁面靜態資源替換，需要將原來的中文文字替換成特定標識和第一步中的key形式，比如：{{this.$t('avaliableOrders')}}。這部分工作通常是和第一步工作同時進行的，現有詞條提取組件可以幫完成這些靜態資源的替換，但是前後端的交互部分通常需要開發者進行特別處理。
同樣，如果後端有做國際化，也需要同樣的操作，目前常用的形式有直接替換法或者集中攔截處理方法，可根據團隊偏好和架構現狀進行處理。
3. 實現國際化邏輯：前端應用啓動時，根據用戶的語言偏好（通常是通過瀏覽器的語言設置或用戶設置）動態選擇對應的國際化資源文件。這個過程一般由前端框架的國際化庫或框架自身來處理。通常需要編寫代碼來加載和解析國際化資源文件，以實現用戶語言偏好設置的處理邏輯，創建函數或組件來展示國際化文本。
4. 自適應性調整：該階段是國際化過程中最耗時的階段，是一個持續的過程，包含前端樣式、頁面Logo、顏色背景、翻譯準確度等諸多因素，是一個長期且具有挑戰性的工作。
無論是在前端還是後端，以上四個步驟都是實現國際化必不可少的環節。具體到我們的實際工作中，這些步驟主要涉及前端詞條的抽取、後端詞條的抽取、前端頁面的國際化、接口的國際化，以及異步任務的國際化。
4. 多語言過程中的挑戰和誤區
4.1. 翻譯本土化挑戰
國際化（Internationalization，簡稱I18n）和本土化（Localization，簡稱L10n）是兩個相關但有所區別的概念，它們在軟件開發、產品設計、市場營銷等領域中扮演着重要角色。國際化是指設計和開發軟件或產品時，使其能夠適應多種語言和文化。這個過程主要集中在軟件或產品的架構和代碼層面，以確保它們能夠輕鬆地被本地化爲不同的語言。國際化的核心目標是創建一個靈活的平臺，使得本地化成爲可能。本土化是指在國際化基礎上，對軟件或產品進行詳細的定製，以滿足特定地區的語言、文化和習俗等需求。本土化涉及到將國際化產品中的文本、圖形、格式等元素替換爲特定語言或地區的版本，在實際的實現過程中存在較多挑戰。
1. 語言多樣性：世界上有超過7000種語言，而且每種語言都有其獨特的語法、詞彙和表達方式，這爲多語言本土化帶來了巨大的挑戰。不同語種詞條的長度和書寫格式會給原有僅支持中文一種語言的系統帶來較大沖擊，頁面會變得凌亂不堪。
2. 文化差異：不同文化對某些概念的理解可能大相徑庭，這就要求本土化團隊不僅要精通目標語言，還要深入瞭解當地文化，以確保翻譯的準確性和文化適應性，比如頁面的Logo和提示語等，可能在不同的文化中存在較大不同含義，需要區別化的對待。
3. 資源投入：多語言本土化需要大量的人力、物力，對於資源有限的團隊來說，這是一個不小的挑戰。初始系統架構的改造只是一個開始，要想做好做專業，真正的挑戰在於諸多細節的磨合調整，這需要投入大量的資源。
4. 技術難題：多語言本土化需要處理各種複雜的語言和技術問題，如如何處理一詞多義、如何適應不同的字符集等，這需要高級的技術能力和豐富的實踐經驗。
5. 維護和更新：隨着語言和文化的變化，多語言本土化產品可能需要定期維護和更新，以確保持續的文化適應性和產品的有效性。
4.2. 頁面樣式的國際化難度
前端頁面是直接面向客戶的，第一印象就能決定系統國際化是否專業的認知，除了國際化中常見的詞條抽取和管理外，主要是頁面樣式和目標語種文化的自適應問題。
1. 界面佈局適應性：不同語言的顯示長度可能不同，例如，中文和英文的顯示長度比例就可能不同，這可能導致界面佈局需要調整以適應不同語言，如下的案例是多語言過程中非常常見的，葡萄牙語相對較長，可能會導致不正常的換行從而影響頁面佈局。
2. 性能優化：加載和渲染多語言內容可能會影響頁面加載時間，如何確保性能，尤其是在移動端和網絡環境不佳的場景中，是一個需要考慮的問題。
3. 圖標和符號：在某些情況下，圖標和符號也需要根據目標語言進行調整。例如，英美國家習慣用美元符號（$）表示金額，但在其他地區，如中國，人們更習慣使用人民幣符號（¥）。
4. 顏色選擇：顏色在不同文化中有不同的含義和象徵意義。例如，紅色在中國文化中代表喜慶，而在西方文化中則可能被視爲危險或警告的顏色。因此，需要根據目標市場的文化背景選擇合適的顏色方案。
5. 本地化不僅僅是翻譯：有時需要對文本進行本地化調整，不僅僅是翻譯，例如日期、時間、貨幣表示等。目前很多國家存在冬令時、夏令時之分，如何讓系統時間也無感知的做到自動切換也是一個較大改造。
4.3. 後端接口國際化多語言誤區
在國際化的議題上，普遍的共識是前後端均需進行相應的改造。因此，我們見證了從前端到後端的全流程國際化改革，包括詞條的抽取和代碼的調整。然而，在這一過程中，我們逐漸意識到前端的國際化進程相較於後端更爲迅速，而後端的調試流程則顯得較爲繁瑣且耗時。另外，由於後端業務邏輯的複雜性，將其與國際化處理邏輯相結合將更爲複雜。所以我們需要考慮後端避免大量的國際化改造。後端接口按照客戶的同步，廣義可以分爲兩種，一種是開放對外提供的接口，另一種是內部其他應用或者模塊間調用的接口。那麼我們看看其他國際大廠和友商的做法。
4.3.1. 對外開放接口國際化調研
案例一、Amazon Marketplace Web Service (MWS) API:
亞馬遜的API接口通常返回的是XML或者JSON格式的數據，而不是直接的多語言提示。因此，調用方需要根據自己的應用程序邏輯來處理這些數據，並將其轉換爲中文或其他所需語言的提示，意味着Amazon將多語言交給調用方處理，接口統一返回英文。
請求參數：
返回接口示例：
小結：雖然MWS API大部分接口主要以英文返回錯誤消息和描述信息，但提供了廣泛的文檔本地化，並且爲用戶界面提供了多種語言選項，可以讓用戶很清楚的知道具體接口含義，這種做法基本是目前國際化接口的主流形式，非常值得借鑑。
案例二、菜鳥國際開放平臺
目前菜鳥國際對外開放接口也沒有支持多語言化，統一英文返回，接口入參也未設定語言的入參，平臺支持中英文兩種語言選擇，模式和MWS是完全相同的。
案例三、Google Maps API
Google API（例如：Google Maps API）通常允許通過請求參數設置語言選項，例如使用`language`參數，用以返回本地化後的結果。對於異常描述而言，如果API調用返回錯誤，Google也會根據語言參數返回相應本地化的錯誤消息，這也和Google Maps本土化要求高有很直接的關係。
目前，除了國際知名的互聯網企業外，其他大型物流公司，如UPS等，亦僅提供默認的英語界面。因此，在對外提供的接口設計中，我們應儘量維持單一的英文輸出版本。沒有必要引入多語言支持，因爲隨着服務對象的不斷國際化，維護多套語言版本的工作量將呈災難性增長。
4.3.2. 內部接口國際化誤區
在實際應用中，開發團隊往往傾向於遵循慣例，認爲實現國際化多語言支持需要同時開發前後端組件。當然，這種做法並非不可行，但相應的成本可能會相對較高。
在這裏我們以前後端內部接口交互爲例，傳統的做法如上圖所示，前端國際化一般會分爲本身靜態資源的國際化和後臺接口請求的國際化，前端資源國際化沒有什麼異議，對於後臺接口的國際化，如果採用這種後端處理的國際化形式，可能會帶來一些問題。在系統維護方面，除了後端繁瑣的國際化搭建外，最直觀的就是後端給前端返回內容前端不可預見，給前端展示帶來不可預見的問題；在體驗方面，將後端異常描述或者提示直接暴露給前端用戶，對客戶體驗非常不友好，因爲往往後端提示信息多數是系統級別的，不具備業務指導價值。如果跳出這個怪圈，會有很大的優勢。
1. 解耦合：後端和前端之間的耦合度降低，後端只需關注業務邏輯和數據處理，前端則專注於界面展示和用戶體驗，統一全面管理詞條的翻譯。
2. 靈活性：前端可以根據需要隨時更新翻譯，而不需要等待後端的更新。這對於快速迭代和本地化調整非常有利，前端技術的發展非常迅速，框架和庫如React、Vue等提供了支持國際化強大的功能和靈活性，使得前端國際化更加高效和便捷。
3. 可維護性：當需要更新或添加新的語言時，只需在前端進行修改，無需更改後端代碼，節省後端大量的國際化工時。
👉 國際物流涉足海外業務多年，在國際化的路上摸索了很長時間，對於以上模式我們也經歷過，最終我們採用了內部模塊不做國際化的大膽嘗試，後端通過統一的接口設計，返回統一的code碼和業務描述，前端根據code碼統一管理匹配多語言信息。
對於內部web和ws服務模塊間的多語言交互，把多語言處理流程全部放在前端統一管理，前端會對後端的code碼對應的含義進行二次封裝，讓提示更具有導向性，更加貼近客戶而不是系統級別的異常提示。實際開發中，是否採用這種模式取決於具體的業務需求和團隊偏好，如果團隊有能力維護好前端的國際化邏輯，有時間處理前端多語言改造，並且希望保持後端的簡潔和高效，那麼這種模式是一個非常不錯的選擇，根據我們團隊多年對兩種模式的使用經驗總結，強烈推薦這種模式。
5. 國際物流多語言推薦方案介紹
鑑於以上種種挑戰和難點，以下章節是目前國際物流系統在多語言實踐中總結的統一方案，方案涉及國際化多語言的各個環節，包括公共詞條庫的建設，前後端詞條抽取以及詞條的翻譯替換。
5.1. 國際公共詞條庫
爲了解決翻譯本土化的難題，我們嘗試了多種方案。最直接的方法是依賴第三方翻譯服務商，但這種做法存在多個問題。首先，成本較高；其次，翻譯的準確性無法保證。主要問題是，我們的每個系統都具有專業性，日常使用中看似簡單的詞彙，翻譯公司可能無法準確理解其含義，從而導致翻譯結果無法準確表達原意。因此，這種方法產生的結果並不理想。隨着越來越多的系統在做國際化，我們發現同行業系統之間有很多詞彙是相同的，但是不同系統的翻譯結果可能有差異，無法做到術語統一，這會給用戶帶來困擾，對外體驗不好，因此我們孕育出想做一個行業詞條庫的想法。
通過國際供應鏈各個系統詞條彙總，統計出高頻詞條，通過GPT智能翻譯加人工校對，確保詞條翻譯的準確性和本土化，有了公共詞庫作爲基礎，所有系統多語言翻譯優先查詢公共詞庫，確保不同系統術語統一，其次纔是複雜文本GPT智能翻譯。
國際公共詞庫成型示意圖：
通過現有國際物流系統的詞條，我們通過使用頻率篩選出高頻詞條，通過GPT翻譯加人工校驗的方式進行詞條沉澱，考慮到不同位置展示的詞條書寫格式的差異，詞條類型根據不同的用途進行分類管理。比如考慮到菜單類詞條可能很多英語寫法喜歡縮寫，會將頁面菜單詞條和異常提示詞條分類存放，使用的時候同樣的詞彙會根據具體的類型進行翻譯。
通過公共詞庫的實踐，我們避免了很多詞彙的二次翻譯，同時翻譯結果的準確性和本土化程度大幅提高，隨着詞條沉澱的增多，發揮的作用將會越大，所以，如果你的系統正在做國際化，強烈推薦沉澱一份公共詞庫，可以讓系統翻譯更加統一，更加精確。
5.2. 前端詞條抽取
前端是國際化最主要的部分，是直接面對用戶的界面，國際化能夠確保用戶能夠以自己的母語使用軟件，理解信息，這對於提升用戶體驗至關重要。良好的用戶體驗可以增加用戶的滿意度和忠誠度，從而提高產品的市場競爭力。前端詞條的抽取是國際化的第一個環節，目前流行的React、Vue都有非常成熟的詞條抽取工具，比如i18next、react-intl等等，但是如果你正在使用 Vue.js 開發應用程序，並且正在尋找一個簡單易用、集成度高的國際化解決方案，DUI18N 可能是一個不錯的選擇，其簡潔的配置和集成方式，無需複雜的設置即可快速開始國際化，它提供了自動提取功能，能夠從Vue組件中自動識別需要翻譯的字段，大大提高了翻譯效率。
選擇合適的工具，根據操作步驟，即可完成國際化詞條抽取第一步。抽取好的詞條按照語種進行存儲，目前iWMS系統支持包含英語、德語、葡萄牙語等在內的10種語言，按照文件進行單獨存儲。目前抽取出來的詞條大致有兩種管理模式，第一種類似下圖，在一個對象裏面整體通過key:value的模式進行平鋪展開；另一種是對象嵌套的模式，按照模塊劃分存放。在此推薦第一種模式，方便集中管理並且可以防止同一詞條多個翻譯的情況，並且平鋪的管理模式，更有利於後面程序化或者自動化處理。
前端code碼形式：
5.3. 後端詞條抽取
普通的內部引用模塊，我們不建議進行國際化，但是可能會遇到對外接口在客戶要求下或者後端必須處理的場景，在此推薦一個國際物流目前在用的後端詞條國際化方案。這是一個插件形式的組件，可以一鍵將異常碼完成國際化，前提是你的系統需要經過良好的設計，系統提示集中管理，不要有類似於魔數一樣的硬編碼。
插件執行完畢後，會根據語種將對應的詞條進行分文件存儲，並具備增量更新機制。該詞條抽取方案不僅依賴於GPT智能翻譯，而且結合了我們第一步實現的國際公共詞條庫。在翻譯每個詞條時，我們首選公共詞條庫中沉澱的詞條，其次才採用GPT翻譯。
5.4. 前端頁面國際化
前端國際化主要分爲兩個大類：頁面靜態資源國際化和後端交互數據國際化。對於前端靜態資源的國際化目前各個系統的做法大致相同，主要的工作量在前端樣式匹配問題。前後端交互方面上文已經進行過分析，大家可以根據自己團隊的具體情況進行選擇，在此再次推薦後端不進行多語言返回的形式。
5.4.1. 頁面靜態資源國際化
在構建前端國際化應用的過程中，最爲關鍵的挑戰之一便是樣式適配問題。遺憾的是，許多前端組件在設計階段並未充分關注到自適應性。由於不同語言的詞彙長度存在差異，這會引發頁面佈局的混亂，迫使前端開發者投入巨大的精力進行修正。因此，若是有意打造一個支持多語言的國際化系統，開發者在設計頁面時就必須留意諸多細節。以下，我們列舉了一些在實施國際化策略時，常用到的調整方法。
1. 使用相對單位
2. 文本截斷或換行
3. 動態佈局調整
4. 設計彈性佈局
5. 靈活調整頁面佈局
5.4.2. 後端返回數據國際化
這個環節是前後端交互的主要環節，我們採用後端不進行國際化的模式，後端通過統一的業務code碼和描述信息返回的形式。一個設計良好的系統，在交互過程中通常會直接將業務code碼和描述信息返回並做展示，爲此怎麼做到最簡單的改動達到最理想的國際化效果呢？在此推薦一個簡單高效而後端無須國際化的方法。
方案的要點在於前端對於調用請求進行統一的封裝收口並攔截處理，會在所有的請求返回後對返回報文中要展示的信息通過code碼獲取本地的多語言結果，替換後端的多語言結果，這樣在系統進行國際化的時候，前端可以做到較小的交互改動達到理想的國際化結果。
5.5. 接口國際化
接口國際化原則：對外提供接口可以根據自己的實際情況決定要不要做國際化，根據以往經驗，不要把國際化放在後端，可以通過返回code編碼和英文描述的形式，前端根據編碼自動國際化。但是如果在客戶或者系統限制等方面一定要做國際化，以下是接口國際化方面的措施。
| 服務間調用 | HTTP | JSF |
| 入參屬性 | Accept-Language傳參 | RpcContext傳參 |
目前公司內部常用的接口類型主要是HTTP和JSF兩種類型，不管任何接口，都要接收調用方的目標語言，不建議大家將目標語言放入調用參數中單獨處理，建議HTTP類型接口通過Accept-Language傳參，JSF類型接口通過RpcContext傳參，內部邏輯根據接口類型進行統一攔截處理。
5.6. 異步任務國際化
異步任務通常是內部邏輯，一般不會直接返回給客戶，多數無須國際化，但一些特殊的場景也有給業務人員展示的情況，比如一些監控數據或者數據導入的失敗原因，這種情況下，不可在後端數據庫存儲具體的語言。部分系統爲了實現多語言，可能相同的詞條數據庫存儲多套，根據前端的請求返回具體的語種，這種做法擴展性較差，後期新增語種會比較麻煩。解決這種問題辦法類似於前面講的前端國際化，統一存儲錯誤code碼，將多語言展示邏輯放在前端完成，在展示時根據當前的目標語言和錯誤碼動態渲染。
6. 國際多語言方案進階——自動語言定製
目前iWMS正在籌備建設語言自動化定製功能，以滿足海外多樣的語言需求，同時解決之前新增語種高昂的翻譯成本和漫長的開發週期問題。該方案將會滿足業務在線自動完成語種的定製，研發無須發版，快速生效，方便業務，解放研發。整體方案依託於我們以上介紹的前端詞條統一管理的模式，結合目前強大的GPT能力和國際翻譯詞條庫，通過雲端統一管理詞條，達到動態加載詞條，動態增加語種的目的。
整體模塊分佈：
本方案採納了一種獨特的後端非國際化策略，即接口設計返回標準化編碼與描述。具體的編碼含義則在前端實現國際化。得益於這種創新的 多語言架構設計，我們得以實現無需發佈新版本即可進行語言定製。其核心在於，詞條信息存儲於雲端，並在用戶訪問時通過雲端動態拉取，並在前端進行緩存處理。當用戶選擇語言定製服務時，GPT服務中心將根據中文詞條原文進行目標語言的翻譯，並形成多語言文件存儲，從而實現語種定製功能。
7. 總結
構建一套專業的多語言系統是一個複雜且具有挑戰性的過程，涉及戰略規劃、團隊協作、技術實現等多個方面，一套支持多語言系統架構的搭建完成只是冰山一角，在技術層面和非技術層面仍然需要大量的精力進行持續優化。在技術層面，需要根據項目需求和團隊能力選擇合適的技術棧和框架，同時關注界面佈局、文本處理、資源管理、性能優化等方面。然而技術之外，詞條多語言本身卻是最具有挑戰性的，比如你的翻譯或者菜單縮寫是否足夠本土化，怎麼證明已經足夠本土化，是一個亟待解決的問題。雖然我們目前可以通過大模型等能力協助我們，但是仍然有很大提升空間，我們只有持續不斷地實踐和總結，才能不斷進步，爲用戶提供更專業的多語言系統。
作者：京東物流 高耀飛
來源：京東雲開發者社區