一次把 Sumiyomi 扩到 14 种语言，我学到的事

Sumiyomi 最近几次更新表面上看起来很简单：新增泰语、巴西葡萄牙语、印地语，再往前是挪威语、印尼语、德语。版本说明里写出来也就几行。

但真正做起来我才发现，多语言不是「把 App 里的字符串翻译掉」这么轻。一个独立开发者如果想把它长期维护好，至少要同时管四件事：App UI、App Store 文案、截图文案、官网更新记录。

问题一：语言数量越多，错位越容易发生

最容易出错的是版本号和物料不一致。比如 App 已经是 v3.1.4，但官网 changelog 还停在 v3.0.4；App Store 某个地区的描述写了 11 种语言，另一个地方已经写成 14 种。

这类问题不是代码 bug，但会让整个产品显得不可靠。用户点进官网，看到版本记录落后，第一反应可能是「这个 app 还维护吗」。所以我把 Sumiyomi 的版本说明统一放在项目里的 AppStoreAssets，官网再用脚本从这些源文件生成 changelog。

问题二：App Store 物料也是产品的一部分

很多时候我会把 App Store 当成最后一步：功能做好，再补文案。但多语言以后这种做法很危险。因为每个 locale 都有标题、副标题、关键词、宣传语、截图文案，任何一个遗漏都会让上架准备变得很乱。

这次我把新语言的 UI、关键词、推广文案、截图文案一起整理。这个流程比只改代码慢，但它让发布更稳：版本说明、商店介绍和官网讲的是同一件事。

问题三：官网不能靠手工复制

Sumiyomi 的更新频率比我一开始想象的高。手工维护网页时，最容易犯的错误就是只改最新一条，忘了中间版本，或者把「Latest」标在旧版本上。

所以现在官网的 Sumiyomi changelog 是从 release notes 自动生成的。脚本会按版本号倒序排列，把中文作为主内容，再折叠日文和英文。这样我只要维护项目里的发布说明，官网就能同步。

这次用到的技术

• Swift / SwiftUI 的多语言资源管理
• App Store Connect 多 locale 元数据整理
• 静态官网里的 HTML changelog 自动生成
• 发布前用脚本校验 JSON、XML、页面版本号和线上结果

这不是特别炫的技术，但它是小产品长期维护最需要的部分：让重复工作变少，让容易忘的事情自动发生。

做完之后我更确定一件事：独立开发不是只把功能做出来，真正难的是让每次发布都可重复、可检查、可回到同一个节奏里。