1. 背景與痛點：存量代碼的“多語言噩夢”

在前端開發(fā)中，將一個成熟的中文存量項目進(jìn)行國際化多語言（i18n）改造，往往面臨著以下困境：

?工作量巨大： 項目包含數(shù)百個 .vue/.js/.ts 等文件，散落著成千上萬個硬編碼的中文字符串。

?人工易錯： 手動提取容易遺漏，且極其枯燥，極易產(chǎn)生 Copy/Paste 錯誤。

?命名困難： 為每一個中文詞條想一個語義化的英文 Key（如 homePageTitle）不僅耗時，而且難以保證團(tuán)隊風(fēng)格統(tǒng)一。

?維護(hù)成本高： 翻譯文件（zh.ts/en.ts）的維護(hù)和代碼中的替換需要同步進(jìn)行，稍有不慎就會導(dǎo)致報錯。

如果按照傳統(tǒng)的人工查找替換方式，預(yù)計需要耗費(fèi)數(shù)周的人力。為了打破這一僵局，我決定利用 JoyCode 結(jié)合我開發(fā)的 i18n-mcp 工具，打造一套自動化的國際化多語言解決方案。

?

2. 解決方案：JoyCode + i18n-mcp

我基于 MCP (Model Context Protocol) 開發(fā)了一個工具 i18n-mcp，通過 JoyCode 的 AI 能力來調(diào)度和執(zhí)行以下三個核心步驟，實現(xiàn)了從“提取”到“替換”的全鏈路自動化。

流程圖

以下是i18n-mcp的流程圖（由JoyCode生成）

?

?

核心流程拆解

第一步：智能提取中文與去重

i18n-mcp 自動掃描所有源文件。利用正則或 AST（抽象語法樹）精準(zhǔn)識別代碼中的中文字符串（包括 Template、Script 和 JSX 部分）。

?全量掃描（full-project-scan工具）： 文件過多的時候，全量掃描會有問題?？梢酝ㄟ^指定文件夾的方式，掃描該文件夾下面的文件。

?增量掃描（git-change工具）：針對git變更的文件，進(jìn)行掃描。精準(zhǔn)定位變更文件，僅處理本次變更涉及的代碼，大幅提升效率。

?智能去重： 對提取出的文本進(jìn)行去重，確保相同的中文文案（如“確認(rèn)”、“取消”）只生成一個 Key，避免冗余。

第二步：AI 輔助翻譯與文件生成

?翻譯緩存： 優(yōu)先查詢 數(shù)據(jù)存儲層 中的 Translation Cache，已翻譯過的文案直接復(fù)用，顯著降低 Token 消耗并加速流程。

?自動化翻譯： 提取的中文列表沒有在緩存中或zh文件中的，被發(fā)送給 LLM，自動翻譯成英文。

?語義化 Key 生成： 區(qū)別于傳統(tǒng) Hash 值，LLM 根據(jù)代碼上下文（Context）自動生成符合語義的 Key（如將“請輸入密碼”生成為 pleaseInputPassword），提升代碼可讀性。

?文件落地： 自動在 lang 文件夾下生成標(biāo)準(zhǔn)的 zh.ts 和 en.ts 文件。

?

生成示例： zh.ts: { "pleaseSelect": "請選擇" } en.ts: { "pleaseSelect": "Please Select" }

?

?

第三步：一鍵代碼替換

?變更預(yù)覽 (Preview)： 在實際修改前，可調(diào)用 preview-changes 工具展示即將變更的代碼對比，確保修改符合預(yù)期。

?AST 節(jié)點替換： 使用 extract-and-replace 工具，將源代碼中的硬編碼字符串精準(zhǔn)替換為國際化方法（如 $t('pleaseSelect')）。

?無損格式保持： 基于 AST 的替換策略能夠完美保留原代碼的縮進(jìn)、換行和注釋，修改后的代碼無需二次 Lint 即可直接提交。

?

?

3. 成果與收益：從“數(shù)周”到“數(shù)小時”

通過引入 JoyCode + i18n-mcp 的實踐，我在項目的國際化改造中取得了顯著的成效：

審核編輯 黃宇