CodeSpirit 多語(yǔ)言國(guó)際化使用指南Beta做國(guó)際化這件事很多人一開(kāi)始覺(jué)得簡(jiǎn)單無(wú)非就是“把文案抽出來(lái)翻譯幾份切換一下”。真到上手才發(fā)現(xiàn)坑全埋在后面語(yǔ)言包怎么組織才不失控帶參數(shù)的消息怎么處理某個(gè)語(yǔ)言的復(fù)數(shù)規(guī)則跟中文完全不一樣怎么辦日期格式、貨幣符號(hào)、文字方向……哪一樣拎出來(lái)都能讓項(xiàng)目在臨上線前翻車(chē)。這篇指南就圍繞CodeSpirit項(xiàng)目的國(guó)際化實(shí)踐展開(kāi)把從資源文件設(shè)計(jì)、文案抽取到運(yùn)行時(shí)切換、問(wèn)題排查的完整鏈路梳理一遍所有內(nèi)容都來(lái)自我在實(shí)際項(xiàng)目里踩過(guò)的坑和驗(yàn)證過(guò)的方案適合正在做國(guó)際化改造、或者準(zhǔn)備給項(xiàng)目增加多語(yǔ)言支持的開(kāi)發(fā)者參考。1. 項(xiàng)目啟動(dòng)前先想清楚語(yǔ)言資源文件的組織方式與命名策略1.1 資源文件的目錄結(jié)構(gòu)怎么定后續(xù)維護(hù)才不痛苦很多團(tuán)隊(duì)做國(guó)際化第一步就是建一個(gè)locales目錄然后按語(yǔ)言分文件夾。這個(gè)方向沒(méi)錯(cuò)但顆粒度怎么切直接決定半年后你維護(hù)這個(gè)項(xiàng)目時(shí)的心情。我見(jiàn)過(guò)最崩潰的寫(xiě)法是把所有文案全塞進(jìn)一個(gè)messages.js里一個(gè)對(duì)象幾千行找一個(gè)鍵靠CtrlF來(lái)回掃。這種方案在項(xiàng)目只有三五個(gè)頁(yè)面時(shí)還能忍一旦模塊變多沖突和誤改就成了家常便飯。更合理的方式是按業(yè)務(wù)域拆分。CodeSpirit里我推薦這么組織src/ locales/ zh-CN/ common.json auth.json dashboard.json settings.json en-US/ common.json auth.json dashboard.json settings.json這么做的好處顯而易見(jiàn)每個(gè)模塊的文案獨(dú)立成文件多人并行開(kāi)發(fā)時(shí)各自改各自的git沖突的概率大幅下降。而且按模塊加載時(shí)可以做到只加載當(dāng)前路由需要的語(yǔ)言包而不是一次性加載全部首屏性能更好。用JSON而不是JS模塊存文案也有講究。JSON是純數(shù)據(jù)不摻邏輯后端如果要做翻譯管理平臺(tái)或者想用在線表格維護(hù)文案導(dǎo)入導(dǎo)出都方便。JS模塊雖然能寫(xiě)函數(shù)、能用變量但也容易混進(jìn)業(yè)務(wù)邏輯最后搞不清語(yǔ)言包里到底存的是數(shù)據(jù)還是代碼。1.2 Key的命名策略一眼看懂歸屬避免“孤兒文案”Key的命名是國(guó)際化項(xiàng)目里最容易被忽視、后患最大的決策。沒(méi)有統(tǒng)一規(guī)范翻譯的人不知道這個(gè)key是哪個(gè)頁(yè)面的開(kāi)發(fā)的人不知道這個(gè)key有沒(méi)有被引用最后就是一堆“孤兒文案”躺在語(yǔ)言包里刪也不敢刪留又占地方。我建議的命名格式是“模塊.頁(yè)面.元素.狀態(tài)”比如dashboard.chart.revenueLabel、auth.login.submitButton、settings.profile.avatarUploadSuccess。這套規(guī)則有四個(gè)明確的優(yōu)勢(shì)可讀性好看到key就知道它屬于哪個(gè)功能無(wú)需打開(kāi)頁(yè)面去對(duì)照按前綴就能實(shí)現(xiàn)語(yǔ)言包的自動(dòng)合并和分割配合構(gòu)建工具做tree-shaking也方便排序后結(jié)構(gòu)清晰代碼審查時(shí)一眼能看出新增了哪些文案工具鏈可以基于前綴自動(dòng)生成文檔甚至校驗(yàn)?zāi)硞€(gè)模塊下是否有漏翻譯的key再補(bǔ)充一點(diǎn)狀態(tài)盡量寫(xiě)在key里比如按鈕的加載中狀態(tài)是auth.login.submitButtonLoading而不是auth.login.loading。因?yàn)閘oading這個(gè)詞太泛放common里會(huì)被各種地方引用改起來(lái)牽一發(fā)動(dòng)全身寫(xiě)在具體業(yè)務(wù)key下語(yǔ)義明確后續(xù)刪除也無(wú)牽掛。2. 最容易踩坑的五個(gè)國(guó)際化細(xì)節(jié)占位符、復(fù)數(shù)、日期、貨幣與排版方向2.1 占位符別用字符串拼接請(qǐng)統(tǒng)一采用命名參數(shù)國(guó)際化里最經(jīng)典的低級(jí)錯(cuò)誤就是寫(xiě)這樣的代碼// 這樣寫(xiě)翻譯的人根本沒(méi)法調(diào)整語(yǔ)序 const msg 歡迎 username 登錄系統(tǒng);中文語(yǔ)序下“歡迎XX登錄系統(tǒng)”沒(méi)毛病但英文習(xí)慣是“Welcome, XX”有些語(yǔ)言甚至?xí)褎?dòng)詞放到句尾。你一旦用了字符串拼接翻譯就只能放棄語(yǔ)法正確性把整句硬拆成幾段。這不是翻譯能力問(wèn)題是代碼結(jié)構(gòu)堵死了人家的路。正確做法是使用命名占位符。CodeSpirit統(tǒng)一用{name}這種語(yǔ)法{ welcome.message: 歡迎 {username} 登錄系統(tǒng), welcome.message_en: Welcome, {username} }調(diào)用時(shí)統(tǒng)一走工具函數(shù)不要出現(xiàn)“有的地方用{}、有的地方用%s、有的地方用$1”這種混亂局面。另外要特別提醒同一個(gè)key下的參數(shù)不同語(yǔ)言版本里必須保持一致。曾有個(gè)項(xiàng)目把{count}寫(xiě)成了{(lán)num}中文語(yǔ)言包沒(méi)暴露問(wèn)題但英文語(yǔ)言包渲染時(shí)直接把{count}當(dāng)普通文本輸出在頁(yè)面上用戶看到一串花括號(hào)。這種事情就是在挑戰(zhàn)用戶耐心測(cè)試還未必覆蓋得到。2.2 復(fù)數(shù)形式不要以為只有英語(yǔ)才區(qū)分單復(fù)數(shù)中文的復(fù)數(shù)處理很簡(jiǎn)單名詞基本不變靠量詞表達(dá)數(shù)量。所以很多國(guó)內(nèi)團(tuán)隊(duì)設(shè)計(jì)語(yǔ)言包時(shí)壓根沒(méi)考慮過(guò)復(fù)數(shù)鍵位。等英文包上線問(wèn)題就來(lái)了。英文里“1 item”和“5 items”是兩回事。而阿拉伯語(yǔ)、俄語(yǔ)這些語(yǔ)言的復(fù)數(shù)規(guī)則更復(fù)雜有的分單數(shù)、雙數(shù)、少數(shù)、多數(shù)。硬編碼count 1 ? items : item只能cover住英文遇上別的語(yǔ)言就原形畢露。如果要手動(dòng)管理可以這樣設(shè)計(jì)消息結(jié)構(gòu){ cart.itemCount: { one: 1 item, other: {count} items } }但這還遠(yuǎn)遠(yuǎn)不夠因?yàn)椴煌Z(yǔ)言對(duì)“哪類(lèi)數(shù)字算one”的定義不同。所以更可靠的方案是借助Intl.PluralRules這個(gè)瀏覽器原生APIconst pr new Intl.PluralRules(ru); pr.select(1); // one pr.select(2); // few pr.select(5); // many在CodeSpirit里我建議語(yǔ)言包的值先通過(guò)一個(gè)pluralize工具函數(shù)處理根據(jù)當(dāng)前語(yǔ)言環(huán)境自動(dòng)選擇正確的復(fù)數(shù)形式。這個(gè)坑不踩不知道等海外用戶開(kāi)始反饋“頁(yè)面上寫(xiě)著1 items”你就明白什么叫細(xì)節(jié)決定體驗(yàn)了。2.3 日期與貨幣永遠(yuǎn)使用Intl API而不是手寫(xiě)格式時(shí)間格式化是另一個(gè)重災(zāi)區(qū)。“2024年1月5日”在中文環(huán)境沒(méi)問(wèn)題但放到英文環(huán)境應(yīng)該是“January 5, 2024”或“2024/01/05”歐洲很多國(guó)家又是“5 January 2024”。你要是自己寫(xiě)正則拼接基本就把自己鎖死在一種格式上了。瀏覽器提供了足夠強(qiáng)大的原生能力一定優(yōu)先使用const date new Date(2024-01-05T10:30:00); // 根據(jù)不同locale自動(dòng)格式化 new Intl.DateTimeFormat(zh-CN, { dateStyle: full }).format(date); // 2024年1月5日星期五 new Intl.DateTimeFormat(en-US, { dateStyle: full }).format(date); // Friday, January 5, 2024貨幣也同理Intl.NumberFormat可以自動(dòng)處理貨幣符號(hào)、千分位和小數(shù)位甚至不同貨幣的展示習(xí)慣。這點(diǎn)在設(shè)計(jì)訂單金額展示時(shí)極其關(guān)鍵同一個(gè)數(shù)字1234.5美元環(huán)境顯示$1,234.50歐元區(qū)顯示1 234,50 €不是簡(jiǎn)單換個(gè)符號(hào)就行。在CodeSpirit里我封裝了一個(gè)formatDateTime和一個(gè)formatCurrency函數(shù)內(nèi)部統(tǒng)一走Intl API業(yè)務(wù)代碼只管傳入Date對(duì)象和金額不要自己做任何拼接。這類(lèi)基礎(chǔ)函數(shù)越早統(tǒng)一越好不然后面改一次所有頁(yè)面都得跟著動(dòng)。2.4 從右到左語(yǔ)言適配你的頁(yè)面可能整個(gè)鏡像如果你的產(chǎn)品將來(lái)要支持阿拉伯語(yǔ)或希伯來(lái)語(yǔ)那國(guó)際化不只是文案翻譯整個(gè)布局都要反一反。英文是從左往右讀阿拉伯語(yǔ)從右往左導(dǎo)航欄、文字對(duì)齊、圖標(biāo)方向全得跟著變。好在這個(gè)問(wèn)題CSS本身有方案。dir屬性切換后flex布局和grid布局大部分情況下會(huì)自動(dòng)鏡像但這不是白來(lái)的有幾個(gè)地方必須提前設(shè)計(jì)文本對(duì)齊不能用硬編碼的text-align: left盡量用邏輯屬性text-align: start和endmargin和padding也盡量用margin-inline-start這類(lèi)邏輯屬性而不是margin-left、margin-right箭頭圖標(biāo)、翻頁(yè)按鈕的左右方向需要做鏡像處理CodeSpirit的做法是在根節(jié)點(diǎn)動(dòng)態(tài)設(shè)置dir屬性配合一套R(shí)TL樣式覆蓋變量。做這塊時(shí)最好找母語(yǔ)者測(cè)試光靠開(kāi)發(fā)自己看是看不出問(wèn)題的——我自己曾經(jīng)把阿拉伯語(yǔ)頁(yè)面做出來(lái)箭頭全反了還不自知直到被用戶截圖打臉。2.5 語(yǔ)言包里的“硬編碼”漏網(wǎng)之魚(yú)文案抽離最怕的不是抽得慢而是抽不干凈。常見(jiàn)漏網(wǎng)之魚(yú)包括圖片里的文字比如按鈕背景圖里寫(xiě)著“立即購(gòu)買(mǎi)”這種只有設(shè)計(jì)師重新出圖才能解決后端返回的錯(cuò)誤信息后端接口直接拋中文前端翻譯不了頁(yè)面標(biāo)題document.title的拼接字符串第三方組件自帶的文案比如日期選擇器的“今天”“確定”這里沒(méi)有銀彈全憑細(xì)心和規(guī)范。我習(xí)慣在每個(gè)迭代的代碼審查里專門(mén)加一條“文案檢查”看到字符串字面量就問(wèn)一句這個(gè)東西會(huì)不會(huì)顯示給用戶會(huì)的話為什么不走語(yǔ)言包這個(gè)習(xí)慣堅(jiān)持下來(lái)后期翻譯遺漏率會(huì)降很多。3. 從零搭建一套可用的國(guó)際化流程安裝配置到運(yùn)行時(shí)切換3.1 基礎(chǔ)引入與初始配置首次接壤的準(zhǔn)備工作以CodeSpirit前端項(xiàng)目為例先安裝國(guó)際化插件這是vue和react生態(tài)里最常用的方案。安裝好后建立語(yǔ)言包目錄并導(dǎo)入基礎(chǔ)文案。初始化的核心配置大概長(zhǎng)這樣import { createI18n } from vue-i18n; const i18n createI18n({ legacy: false, locale: localStorage.getItem(locale) || navigator.language || zh-CN, fallbackLocale: zh-CN, messages: { zh-CN: { common: require(../locales/zh-CN/common.json), auth: require(../locales/zh-CN/auth.json) }, en-US: { common: require(../locales/en-US/common.json), auth: require(../locales/en-US/auth.json) } } });這里有兩個(gè)關(guān)鍵點(diǎn)第一fallbackLocale一定要設(shè)置。它的作用是當(dāng)某個(gè)key在英文語(yǔ)言包里缺失時(shí)自動(dòng)降級(jí)用中文填充而不是直接把key名扔到頁(yè)面上。這能避免很多“半成品”的尷尬畫(huà)面。第二首屏的locale不要寫(xiě)死優(yōu)先從用戶過(guò)往選擇讀取。localStorage里存了上次的偏好就用偏好沒(méi)有就用瀏覽器語(yǔ)言。這算是最樸素的用戶體驗(yàn)優(yōu)化。還需要在index.html里提前設(shè)置好lang屬性和dir屬性。ESLint等靜態(tài)檢查工具也建議配一個(gè)html標(biāo)簽的lang校驗(yàn)可以提前發(fā)現(xiàn)很多疏忽。3.2 運(yùn)行時(shí)切換語(yǔ)言不只是換語(yǔ)言包狀態(tài)和路由也得聯(lián)動(dòng)語(yǔ)言切換看起來(lái)就是點(diǎn)個(gè)按鈕把locale變量改掉但真實(shí)落地要注意三件事。第一件事切換后要手動(dòng)觸發(fā)重新渲染。有些框架的響應(yīng)式系統(tǒng)不會(huì)自動(dòng)追蹤locale的變化你改了值頁(yè)面卻沒(méi)反應(yīng)讓人懷疑自己寫(xiě)錯(cuò)了。解決方法是把當(dāng)前語(yǔ)言作為響應(yīng)式依賴注入或者顯式調(diào)用nextTick后重新渲染。第二件事持久化當(dāng)前語(yǔ)言。切換語(yǔ)言后立即存入localStorage刷新頁(yè)面時(shí)還能保持用戶的偏好。這個(gè)細(xì)節(jié)雖然簡(jiǎn)單但沒(méi)做的話用戶每次打開(kāi)都要重新選語(yǔ)言體驗(yàn)分直接扣一截。第三件事異步加載語(yǔ)言包。切換語(yǔ)言時(shí)如果目標(biāo)語(yǔ)言包還沒(méi)加載需要?jiǎng)討B(tài)import然后等加載完成再更新localeasync function changeLocale(locale) { if (!loadedLocales.has(locale)) { const messages await import(../locales/${locale}/index.js); i18n.global.setLocaleMessage(locale, messages.default); loadedLocales.add(locale); } i18n.global.locale.value locale; localStorage.setItem(locale, locale); }這種懶加載模式的好處是首包不攜帶所有語(yǔ)言英文用戶訪問(wèn)中文站點(diǎn)時(shí)不會(huì)為了看英文而先下載一整包中文。項(xiàng)目語(yǔ)言多了以后這個(gè)性能收益非常明顯。還有一個(gè)小細(xì)節(jié)切換語(yǔ)言后一些第三方組件不會(huì)自動(dòng)跟著變。比如日期選擇器它內(nèi)部默認(rèn)是英文切換成中文后還顯示“January”。這種組件一般自帶locale屬性需要在切換時(shí)主動(dòng)傳入對(duì)應(yīng)配置。這也是國(guó)際化里比較頭疼的一類(lèi)問(wèn)題沒(méi)有統(tǒng)一的解決方案只能逐個(gè)排查組件文檔。3.3 帶參數(shù)的消息、富文本消息與動(dòng)態(tài)key的安全接入語(yǔ)言包里除了純靜態(tài)文案還有大量帶動(dòng)態(tài)參數(shù)的消息。比如訂單狀態(tài)的提示需要把訂單號(hào)放到句子里。用前面的命名參數(shù)方案在模板里這樣調(diào)用p{{ t(order.created, { orderNo: order.orderNo }) }}/p這種用法是基礎(chǔ)但有兩個(gè)進(jìn)階場(chǎng)景需要注意。一是富文本。有些文案里需要嵌入鏈接、加粗文字等HTML標(biāo)簽語(yǔ)言包不能只存純文本。CodeSpirit的實(shí)踐是把富文本拆成段落級(jí)別的key在模板里組合渲染而不是試圖在JSON里寫(xiě)HTML片段。看到有人把整段HTML塞進(jìn)語(yǔ)言包的勸一句翻譯工具的轉(zhuǎn)義問(wèn)題會(huì)讓你哭。二是動(dòng)態(tài)key。有時(shí)候key的一部分是變量比如order.status.${status}這種寫(xiě)法。這種風(fēng)格要盡量避免因?yàn)榫S護(hù)困難翻譯的人不知道這個(gè)key可能有哪些值測(cè)試也覆蓋不全。正確的做法是把所有狀態(tài)列出來(lái)在語(yǔ)言包中平鋪寫(xiě)出寧可顯式寫(xiě)五個(gè)key也別“聰明”地拼一個(gè)動(dòng)態(tài)key。3.4 靜態(tài)提取與自動(dòng)檢查別讓人工翻譯成為瓶頸文案寫(xiě)得規(guī)范英文翻譯的質(zhì)量就不會(huì)差但項(xiàng)目大了以后人工翻譯跟不上開(kāi)發(fā)速度是必然。這時(shí)候工具鏈就派上用場(chǎng)了。我常用的是一個(gè)“提取-對(duì)齊-校驗(yàn)”三件套流程。構(gòu)建時(shí)自動(dòng)掃描代碼中所有調(diào)用t()和$t()的位置收集第一個(gè)參數(shù)中的key和語(yǔ)言包中的key做對(duì)比。缺失的key輸出警告多余的key輸出提醒。這個(gè)流程雖簡(jiǎn)單但能保證“提交代碼時(shí)語(yǔ)言包基本是齊的”。翻譯本身可以用現(xiàn)成的翻譯API做初稿再人工校對(duì)。不過(guò)要小心機(jī)器翻譯在專業(yè)術(shù)語(yǔ)上經(jīng)常翻得不準(zhǔn)比如“提現(xiàn)”“風(fēng)控”“權(quán)益”這類(lèi)詞機(jī)器很可能翻譯成字面意思離業(yè)務(wù)本意差遠(yuǎn)了。初審之外的終審必須由熟悉業(yè)務(wù)的人來(lái)做。4. 上線后最容易翻車(chē)的幾個(gè)問(wèn)題排查思路與避坑實(shí)錄4.1 問(wèn)題一某些頁(yè)面切換語(yǔ)言后沒(méi)反應(yīng)排查順序有講究。先看控制臺(tái)有沒(méi)有報(bào)錯(cuò)多半是語(yǔ)言包加載失敗key找不到。再看網(wǎng)絡(luò)面板里語(yǔ)言包資源有沒(méi)有真的發(fā)請(qǐng)求沒(méi)發(fā)就是懶加載邏輯里loadedLocales的狀態(tài)更新出了問(wèn)題。如果頁(yè)面局部沒(méi)反應(yīng)重點(diǎn)檢查組件是不是沒(méi)有綁定當(dāng)前語(yǔ)言這個(gè)響應(yīng)式依賴。比如你在setup里解構(gòu)了t但使用的是普通變量而不是computed切換后組件不會(huì)重新渲染。這個(gè)屬于響應(yīng)式依賴丟失問(wèn)題記住一個(gè)原則所有跟語(yǔ)言相關(guān)的派生狀態(tài)都要用computed包一層。4.2 問(wèn)題二日期組件、富文本組件語(yǔ)言跟主體不一致第三方組件沒(méi)跟隨語(yǔ)言切換通常是因?yàn)榻M件內(nèi)部有自己的國(guó)際化管理掛在全局的locale上。排查時(shí)先確認(rèn)組件文檔里屬性名稱然后創(chuàng)建一個(gè)統(tǒng)一的管理器在切換語(yǔ)言時(shí)同步更新所有已注冊(cè)組件的locale。我一個(gè)項(xiàng)目里同時(shí)接了日期組件、富文本編輯器、代碼高亮它們各有各的語(yǔ)言包切換邏輯各不相同。后來(lái)寫(xiě)了一個(gè)syncComponentLocale函數(shù)在語(yǔ)言切換流程里逐個(gè)調(diào)用每個(gè)組件實(shí)例的更新方法。這個(gè)函數(shù)名字聽(tīng)起來(lái)土但確實(shí)管用。4.3 問(wèn)題三動(dòng)態(tài)內(nèi)容里的時(shí)間還是舊格式或貨幣符號(hào)錯(cuò)亂這個(gè)跟響應(yīng)式有關(guān)系但本質(zhì)是“格式化函數(shù)的執(zhí)行時(shí)機(jī)”問(wèn)題。如果你在組件初始化時(shí)把時(shí)間字符串格式化好了存成普通變量語(yǔ)言切換后這個(gè)字符串不會(huì)重新計(jì)算。務(wù)必把格式化放到渲染期或者用computed包裹。貨幣符號(hào)錯(cuò)亂的情景常見(jiàn)于金額數(shù)據(jù)在接口層被處理成字符串返回前端拿不到數(shù)字也就沒(méi)法做Intl.NumberFormat。后來(lái)我們約定后端一律返回?cái)?shù)字前端負(fù)責(zé)格式化徹底根治了這個(gè)隱患。4.4 避坑經(jīng)驗(yàn)搭建一個(gè)“翻譯檢查面板”比一百次口頭強(qiáng)調(diào)都管用最后一個(gè)建議聽(tīng)起來(lái)有點(diǎn)“重”但收益不小。在內(nèi)部開(kāi)發(fā)環(huán)境里我習(xí)慣做一個(gè)隱藏的翻譯檢查面板把所有語(yǔ)言包缺失的key、未翻譯的條目、格式可疑的值匯總成列表按頁(yè)面展示。測(cè)試同學(xué)在驗(yàn)證功能時(shí)順手打開(kāi)面板瞄一眼幾秒鐘就能發(fā)現(xiàn)有沒(méi)有漏翻譯的文案比事后翻截圖高效太多。做法也不復(fù)雜攔截所有翻譯調(diào)用的返回結(jié)果如果發(fā)現(xiàn)返回的字符串里還含有{或}就判定為key缺失把信息推送到面板上。理論上這不難難的是堅(jiān)持做。但說(shuō)實(shí)話就靠這個(gè)面板我們有一次趕上線日程時(shí)在測(cè)試環(huán)境里提前攔截了二十多個(gè)漏翻的key避免了一場(chǎng)線上事故。5. 交互體驗(yàn)與性能優(yōu)化的幾個(gè)加分項(xiàng)5.1 骨架屏和加載狀態(tài)里語(yǔ)言也要跟著變很多團(tuán)隊(duì)只注重完整頁(yè)面的語(yǔ)言切換卻忽略了加載態(tài)和異常態(tài)。用戶切換語(yǔ)言后骨架屏上的占位文字還停留在舊語(yǔ)言這種不一致最容易被人截圖挑刺。骨架屏文案也要從語(yǔ)言包里取同時(shí)要保證切換語(yǔ)言的瞬間骨架屏立即刷新。這需要在模板里把骨架屏用到的文案同樣定義為響應(yīng)式依賴。5.2 按需加載與緩存策略語(yǔ)言包不該成為首屏負(fù)擔(dān)國(guó)際化不是“把所有語(yǔ)言都掛在首屏資源里”而是“用戶需要什么語(yǔ)言就提供什么語(yǔ)言”。首屏只加載當(dāng)前語(yǔ)言的必要模塊其他語(yǔ)言模塊等用戶切換時(shí)再異步加載。這本身就是最基礎(chǔ)也最有效的優(yōu)化。加上緩存策略后效果更好。語(yǔ)言包變更頻率低非常適合給一份強(qiáng)緩存同步更新時(shí)用構(gòu)建hash或版本號(hào)做資源更新。曾經(jīng)有段時(shí)間我們某個(gè)語(yǔ)言包沒(méi)加版本號(hào)導(dǎo)致用戶改了偏好語(yǔ)言后依然拉取舊緩存頁(yè)面上一半新文案一半舊文案排查了半天才發(fā)現(xiàn)是緩存問(wèn)題?，F(xiàn)在語(yǔ)言包文件名里帶上內(nèi)容hash這個(gè)問(wèn)題再?zèng)]出現(xiàn)過(guò)。5.3 從“地道翻譯”到“本地化”語(yǔ)言背后的文化適配“翻譯”和“本地化”是兩件事。真正好的國(guó)際化不只是把中文換成英文還要考慮當(dāng)?shù)氐奈幕?xí)慣。比如日期是“2024年1月5日”這樣的表達(dá)習(xí)慣還是“1/5/2024”數(shù)字是十進(jìn)制的千分位格式還是某些國(guó)家習(xí)慣用空格分隔首字母大小寫(xiě)規(guī)則、標(biāo)點(diǎn)符號(hào)、地址書(shū)寫(xiě)順序……這些細(xì)節(jié)靠翻譯工具搞不定需要各個(gè)國(guó)家地區(qū)的真實(shí)使用場(chǎng)景來(lái)反推。如果你的產(chǎn)品將來(lái)要出海建議早一點(diǎn)找到目標(biāo)市場(chǎng)的用戶做語(yǔ)言包評(píng)審而不是等上線后讓用戶幫忙“找茬”。6. 寫(xiě)在最后國(guó)際化不是一次改造而是一套持續(xù)運(yùn)轉(zhuǎn)的機(jī)制做國(guó)際化改造代碼層面的工作量大概只占四成剩下六成都花在流程和方法論上。語(yǔ)言包的維護(hù)不是上線那天結(jié)束而是從那天才開(kāi)始。后續(xù)每個(gè)迭代都可能新增文案每個(gè)文案都可能漏翻譯每個(gè)翻譯都可能不地道。所以關(guān)鍵不是上線那天的狀態(tài)而是你有沒(méi)有建立一套讓語(yǔ)言包“持續(xù)被維護(hù)”的機(jī)制——比如代碼審查里的文案檢查、構(gòu)建時(shí)的key對(duì)齊校驗(yàn)、測(cè)試環(huán)境的翻譯面板。按我個(gè)人的經(jīng)驗(yàn)先用一個(gè)小模塊試點(diǎn)把語(yǔ)言包結(jié)構(gòu)、命名規(guī)范、運(yùn)行時(shí)切換流程跑通再推廣到全項(xiàng)目。別一上來(lái)就全面鋪開(kāi)不然光是排查歷史遺留文案就夠你消耗掉所有精力。希望這套CodeSpirit的國(guó)際化實(shí)踐能讓你在改造路上少踩幾個(gè)坑。