它叫 AI Localization，是一个只在 Unreal Editor 中运行的 AI 辅助本地化插件。简单来说，就是把原本需要导出、翻译、再导回去的本地化流程，尽量收进编辑器里完成。
这个插件最初是为我的游戏 Lover Completion Plan 做的。它不是什么特别成熟的大型工具，更像是一个从真实需求里长出来的小项目：够我自己用，也顺手把它放出来了。
在写这个插件之前，我已经有一套能工作的翻译流水线。
先从 Unreal 导出某种目标语言的 .po 文件，再把文件拖到一个 Python 脚本上。脚本会调用 AI，把内容翻译成文件里指定的语言，并输出一份翻译完成的 .po 文件。
这套方式本身没有问题，甚至已经帮我省下不少时间。但我的游戏需要支持十种语言，如果每一种语言都要单独导出、拖文件、等待翻译、检查结果、再导回项目，重复操作还是很多。语言一多，真正浪费时间的往往不是 AI 翻译本身，而是这些围绕文件来回处理的步骤。
后来我看到了 AI Localization Automator。它的思路和完成度都不错，我也很喜欢这种把翻译流程直接放进编辑器的方式。不过对我这个项目来说，它的价格有点高，于是我就开始想：既然需求已经很明确，能不能自己做一个只满足当前项目需求的版本？
我先把需要解决的流程和大致规划写下来，再让 AI 协助实现。最后得到的就是现在这个插件。它不算精致，但能够配置自己的 API 供应商，把游戏本地化内容整体交给 AI 处理，已经把我最在意的效率问题解决掉了。
AI Localization 会接入 Unreal Editor 的本地化工具：
/chat/completions 接口，因此可以配置自己的 endpoint、模型和 API key。基本使用流程就是：选择 Target 和目标语言，配置 Provider，点击 Start Translation，检查表格中的结果，最后再 Apply & Compile。这样不需要把 .po 文件反复拖到外部脚本上，翻译、检查和应用都留在同一个工作流里。
游戏文本不是单独一句一句存在的。尤其是剧情、对话和角色台词，如果模型只看到一条孤立文本，翻译很容易丢掉说话人、场景和前后顺序。
所以这个插件里用了一个比较简单的上下文策略：
namespace 区分文本所属的场景或上下文。key 对说话人和文本顺序排序。这样一来，同一场景里的内容会尽量一起交给模型处理，模型能看到更连续的上下文。它当然不是万能的剧情理解系统，但对我项目中的对话翻译来说已经比完全随机、逐条发送稳定不少。
插件还会保护一些不能被翻坏的结构：Unreal 占位符、printf 格式符、富文本标签、首尾空白和多行换行数量都会在接受译文前校验。校验失败的条目会保留给人检查，不会被自动导入。多行文本也会使用受保护的换行 token，减少模型擅自重排换行带来的问题。
整个插件从规划到可用，AI 开销大概只花了四十多元，不到五十元。对比当时我看到的商业方案，自己做这个小工具的成本还是挺有意思的。
当然，这不是说它能直接替代成熟产品。商业插件有更完整的支持、长期维护和更广泛的兼容性；我这个版本的目标只是把自己的实际翻译流程跑顺。它目前只支持 OpenAI-compatible chat-completions 接口，不支持 streaming response、模型发现和费用统计；它也是 Editor-only 插件，不负责打包后游戏运行时的实时翻译。
API key 也不会写进项目源码。Windows 下会使用 Windows Credential Manager 保存凭据，其他平台只在当前 Editor 会话内保存；预设文件只记录是否存在凭据，不保存 key 本身。
现在这个项目已经按照 MIT License 开源：
Plugins/AILocalization 目录，启用后从 Unreal Editor 的 Tools 菜单打开管理器。说到底，它就是我为自己的游戏随手做出来的一个小工具，估计大部分时间也只会在自己的项目里使用。不过目前该有的流程基本都能跑，实际用起来也还不错。
如果它刚好能帮到同样需要给 Unreal 项目做多语言本地化的人，欢迎直接使用、修改或 fork；Issue、Pull Request 和改进建议也都欢迎。
本站基于 Astro 和 Mizuki 主题构建，静态站点部署在 Cloudflare Pages 上。
我可以在网站后台添加日记或文章。后台保存并不是直接改服务器上的数据库，而是由 Cloudflare Pages Functions 校验请求后，调用 GitHub Contents API，把内容提交到 OldWood-u/oldwood-blog 的 main 分支。之后 GitHub Actions 会异步执行检查、翻译和部署，所以保存完成到网站完全更新之间可能会有一小段时间。
公开文章会交给 DeepSeek 生成英语、日语和韩语的翻译 sidecar。翻译工作流会记录源内容哈希，检查受保护的链接、日期、Markdown 和其它结构化内容；如果中文源文件发生变化，旧译文会被识别为过期，而不是悄悄当成最新译文使用。它不是保存请求里同步完成的翻译，也不能保证每一次提交都立刻完成部署。
已经变成全流程流水线啦（骄傲.jpg）
由于我主要做游戏开发（程序），所以对于网页搭建并不是那么熟悉。
但我又想做一个好看的网站，该怎么办呢？
睡大觉啦，梦里什么都有
于是我使用了现成的博客模板，就是 Astro + Mizuki 啦～
这里的“后端”需要稍微解释准确一点：Cloudflare Pages 负责静态页面的构建和发布，Pages Functions 负责登录、内容读写、媒体上传等 API；GitHub 仓库则是文章和结构化内容的持久化来源。域名是在阿里云购买的，一个属于我自己的网站就这样慢慢搭起来了。
我从高中，不对，初中就想做个自己的网站了，居然到现在才正式做出来（哭.jpg）
但很显然，如果只是简单地使用模板、改成自己的信息，那就太 low 啦。换言之又是一个换皮网站罢了。
所以我需要定制化修改。其实就是改下布局，把不需要的功能删除/隐藏，新增些自己认为重要的功能
**这部分才是最折磨的。**我一开始还想自己手搓来着，但很快就放弃了，不是说太难，而是太累了。整个网站的内容比我想的要多，光是改 Config 文件就要费好大劲儿，更别提后面还要新增的内容了。
但现在是什么时代？**AI 时代！**所以我使用 Opencode + GPT5.6 Sol 帮我梳理整个网站，由 AI 帮我填入，我只需要提供信息就行了。整个流程还是相对顺利的。
长篇文章放在 src/content/posts/ 中，每篇文章是一个 Markdown 或 MDX 文件。Astro 的内容集合会读取 frontmatter，并校验标题、发布日期、分类、标签、草稿状态等字段；文章详情页再把正文交给 Astro 的 Markdown 管线渲染。
日记、项目、首页横幅和其它频繁编辑的结构化内容则集中在 src/data/admin-content.json。这样做的好处是：文章正文仍然适合用 Markdown 写作，日记和项目则可以在后台用卡片、日期和图片控件管理，不需要把所有内容都塞进一个格式里。
Cloudflare Pages 负责把仓库里的 Astro 项目构建成静态网站并发布。Pages Functions 是同一个部署环境里的 API 层，后台登录、会话校验、文章读写、结构化内容保存和图片上传都通过它完成。
上传图片时，API 会检查文件大小、允许的 MIME 类型和文件签名，只把安全的图片写入 public/images/uploads/。文章正文中保存的是最终站内路径，而不是临时的浏览器对象地址。正文预览会在必要时使用本地临时预览，这样刚上传但还没完成新一轮部署的图片也能立即看到。
管理后台使用 GitHub Contents API 读写 main 分支。更新文章时，客户端会带上它读取到的文件 SHA，服务端在写入前再次比较远端 SHA。如果另一个后台窗口已经先改过同一篇文章，SHA 就会不一致，服务端会拒绝这次写入，避免我的修改覆盖别人的修改。
每次编辑已有文章时，服务端会生成新的 updated ISO 时间并写入 frontmatter；新建文章则不强行写入这个字段。文章页面底部因此可以显示真正的最后修改时间，而不是把发布日期伪装成更新时间。
文章保存到 GitHub 后，GitHub Actions 会根据中文源文件运行翻译脚本。翻译结果保存在 translations/content/en、ja 和 ko 目录的 sidecar 文件中，并带有 sourceHash、模型和生成状态等信息。草稿、加密文章和密码文章不会发送到翻译服务。
翻译工作流完成后会提交翻译 sidecar，部署工作流再构建 Astro 项目并通过 Wrangler 发布到 Cloudflare Pages。由于这些步骤是异步的，后台提示“已提交”代表 GitHub 写入成功，不代表所有语言的页面已经在同一秒完成更新。
后台 API 需要有效的管理会话，写请求还要通过严格的同源检查。GitHub token、会话签名密钥和 DeepSeek API key 只放在运行环境或 GitHub Secrets 中，不会进入文章、前端代码或日志。Markdown 预览会经过安全清洗，过滤脚本、事件处理器和危险 URL；文件路径、图片类型、请求大小和 GitHub 文件版本也都会在服务端再次校验。
这套方案没有传统意义上的数据库：GitHub 既保存内容源文件，也提供版本历史；Cloudflare Pages 提供静态站点，Pages Functions 提供必要的 API。它不一定是最复杂的架构，但对一个个人站点来说，修改可追踪、部署自动化，而且我可以在后台继续写作，已经足够实用了。
首先先说明，Mizuki 兼具丰富功能与优雅设计，本人才疏学浅，如果有任何不规范或错误的地方那都是我的错！可以直接提出！（我也不知道为什么要写这个，反正我就是写了）
整个前端我基本都是 Vibe Coding，因为效率真的很高。而且 Mizuki 包含很多现成的组件可以直接使用，这样也不用担心 AI 会自我发挥，做出些不符合主题的东西了。
基本总结为以下改动：
后面还会继续记录新的功能和踩坑。先这样，下一篇见！