多语言网站很难——AI终于让它们变得实用
Source: Dev.to
不同的架构，不同的权衡
Flat‑file CMS 以截然不同的方式解决多语言网站的问题。有些系统（例如 Grav）直接在同一页面文件夹内存放语言变体。这使得切换语言非常直接，并且页面之间天然相连。
然而，Typemill 采用了另一种方法。它会 构建所有页面的完整索引 来管理导航、深层嵌套的内容结构以及拖拽排序。这让内容结构非常灵活——但也意味着不同语言不能简单地并列放在同一文件夹中。
项目而非文件夹
我最终采用的解决方案是引入 项目。每个项目拥有：
- 自己的内容空间
- 自己的导航
- 自己的逻辑和索引
项目最初并不是为多语言网站设计的——它们是一次意外的第一步。很快发现它们在一般情况下也很有用。由于 Typemill 还能将网站发布为 PDF 书籍或 EPUB 文件，项目同样可以用来管理单个安装中的多个出版物。
对于多语言网站来说，项目恰好是自然的匹配。每种语言成为一个独立的项目——隔离、干净、可独立管理——同时仍然是同一系统的一部分。唯一需要的是一个全局索引，用来记录语言变体之间的关联。
缺失的环节：AI 翻译
即使结构已经稳固，仍然有一个主要问题：翻译工作流。
手动复制页面、翻译文章、更新元数据对于小型网站还能应付，但会消耗大量时间，且随着项目规模扩大很快失效。
Flat‑file CMS 相较于基于数据库的系统的一大优势是使用 简单的 Markdown 文件。Markdown 也是几乎所有 LLM 服务和 API 的原生输出格式。这使得将 AI 服务集成到 Flat‑file CMS 中出奇地简单。利用这一优势来自动翻译，坦率地说，就是不费吹灰之力。
Typemill 已经通过一个名为 Kixote 的独立接口集成了 AI 服务。要实现翻译的全自动化，只需勾选一个复选框。当你创建新的语言页面时，Typemill 会把原始内容复制到目标语言项目中，并执行额外一步：将内容发送给 AI 服务并保存翻译后的响应。
就这么简单。
目前，自动翻译仅在创建翻译页面时运行。如果原始内容随后发生变化，翻译仍需手动更新。但这只是一个相对较小的后续步骤。
最后思考
在 Flat‑file CMS 中实现多语言支持一直是个难题——无论是结构上、概念上还是运营上。AI 并不能解决所有问题，但它消除了最大的痛点：重复的手动工作。依我之见，如果你今天正在为内容创作者构建工具，多语言支持至少应当提供一个自动翻译的选项。
观看演示
我制作了一个 5 分钟的演示视频，展示了使用这种方法在 Typemill 上搭建多语言网站有多么简单：
