大鹏 AI 玩转 Django CRM 国际化

很多人对「国际化」的理解停留在装个 i18n 库、把按钮文字抽成变量这一步。真接到一个跑了几年、前后端混杂的 Django CRM 项目时，会发现完全不是这么回事：模板里散落着硬编码中文，SvelteKit 前端有自己一套语言包，页面里还插着几段老式 JavaScript 脚本，改完一处漏一处，构建能过但界面上还是中文，最后根本说不清到底改干净没有。这门课就是冲着这种「改造现场」来的。

它解决的是哪一类能力缺口

课程选的是一个真实的 Django CRM 开源项目作为载体，不是新起一个干净的 demo。这意味着你要面对的是遗留项目的典型脏活：词条分散在多处、前后端两套机制并存、命名和结构不统一。如果只会用 Django 自带的翻译机制，遇到 SvelteKit 部分就会卡住；如果只会前端多语言方案，又搞不定后端模板和数据库里的内容。

具体来说，课程覆盖三个容易断层的地方。一是 SvelteKit 前端用 Paraglide JS 搭多语言架构，这是相对新的方案，和传统 JSON 语言包思路不同，需要重新理解消息编译和类型安全的玩法。二是老式 JavaScript 脚本里的国际化失效——这类问题最容易被忽略，因为组件都改好了，偏偏某段直接操作 DOM 的脚本还在写死文案，靠肉眼很难扫出来。三是用 Codex 辅助做遗留审计，把「哪里还没国际化」从人工翻文件变成可批量排查的动作。

Codex 在流程里扮演什么角色

课程把 Codex 放在审计、改造和修复这几个环节，而不是当万能生成器用。你需要的判断力在于：哪些改动交给它批量处理，哪些必须自己确认。遗留审计是最典型的场景——让工具扫出可疑的硬编码点，再由你判断是文案、是测试数据、还是本就不该翻译的标识符。这个「它给候选、你做决策」的分工，比单纯学一个 API 更接近实际工作。

自动验收为什么被单独拿出来

国际化改造最容易出现的情况是：代码改完了，自己觉得没问题，换个人一打开页面就发现漏了。课程引入 Playwright 做自动验收，并且用了多 Agent 的方式推进，目的就是把「改没改干净」变成可重复执行的检查，而不是靠人工点页面。这部分值得重点练，因为它同时训练两件事：怎么写国际化相关的断言，以及怎么组织多个 Agent 分担验收任务。

学完应该能回答这些问题

• 一个前后端混用的 Django CRM，国际化改造应该按什么顺序推进，先动哪一层风险最小？
• Paraglide JS 和常见的语言包方案差别在哪，为什么它在 SvelteKit 里值得用？
• 组件都翻译了，某段普通 JavaScript 脚本里的文案却还是中文，排查思路是什么？
• 用 Codex 做遗留审计时，如何区分真漏点和误报，避免把不该翻的内容也改掉？
• Playwright 验收国际化时，断言应该盯什么，才能覆盖到构建产物而不只是源码？
• 改造完成、构建修复之后，一次可交付的新版本发布需要确认哪些环节？

适合谁，以及需要先补什么

如果你已经能写 Python 和 Django，看得懂 SvelteKit 项目结构，并且前端基础不至于被组件和状态绕晕，这门课的节奏是合适的。反过来，如果 Django 的模板渲染、静态文件机制还没理顺，或者没碰过 SvelteKit，建议先把这两块跑通再进来，否则大部分时间会花在理解项目本身，而不是国际化方法上。

练习建议是别只看讲解：把课程用的 CRM 项目自己拉下来，先手动找出三处你认为是硬编码的地方，再对照课程里的审计流程看漏了哪些。改造类课程的坑在于「看懂了等于会了」的错觉，只有自己扫一遍、改一遍、跑一遍验收，才知道哪一步会真的卡住。