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

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

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

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

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

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

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

?

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

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

流程圖

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

?

?

核心流程拆解

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

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

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

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

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

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

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

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

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

?文件落地： 自動在 lang 文件夾下生成標準的 zh.ts 和 en.ts 文件。

?

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

?

?

第三步：一鍵代碼替換

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

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

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

?

?

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

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

審核編輯 黃宇