问题
Discourse 的内容本地化功能（包括手动和通过 Discourse AI 进行的自动本地化）在本地化主题标题、帖子、分类名称和分类描述方面表现非常出色。然而，分类的主题模板（categories.topic_template）却无法进行本地化。在多语言社区中，编辑器预填内容始终显示为网站的默认语言——对所有人都一样。
当前行为
CategoryLocalization 按语言环境存储 name 和 description（Localizable concern 为 Topic/Post/Category 提供“多语言环境名称/描述支持”）。- 无论成员的界面语言环境如何，编辑器始终使用未本地化的
topic_template。
建议的解决方案
- 将
topic_template 添加到 CategoryLocalization 中（包括管理员本地化编辑器 UI）。
- 当成员在某个分类中打开编辑器时，使用与其界面语言环境匹配的模板；如果不存在本地化版本，则回退到该分类的默认模板。
- 较新的按分类设置的表单模板也存在同样的问题：它们可以在不同分类之间有所不同，但在单个分类内部没有语言环境感知的变体——多语言配置不得不将社区拆分为按语言划分的独立分类来规避此问题。
使用场景
我们运营一个双语社区（默认语言为德语，通过自动 AI 翻译支持英语）。某些分类提供了包含检查清单项目和用于内置日期选择器的 [event] 块的结构化编辑器模板。目前，英语用户只能看到德语模板。我们的变通方法是使用单一的双语模板（每个标签在同一行上重复为“德语 / 英语”），这虽然可行，但对于编辑者和成员来说都很笨拙，并且使编辑器内容翻倍。
相关
- #32464（本地化分类路由）——相同的本地化范围，分类。
3 个赞
接着我最初的请求，这里提供一个具体的实现草图——如果这个方向听起来合理，我很乐意帮忙提交 PR。
问题： 分类主题模板（categories.topic_template）无法本地化。CategoryLocalization 模型和 Localizable 关注点（concern）仅覆盖 name 和 description，因此 AI 内容本地化流水线会相应地跳过模板。无论用户处于哪种语言环境，编辑器（Composer）始终插入基础语言的模板。
使用场景： 我们在生产环境中运行一个双语（德/英）社区，使用 Discourse AI 内容本地化功能进行自动翻译。帖子和主题的翻译效果很好，但用于结构化内容的分类模板——例如带有检查清单的 Bug 报告表单、通过 [event] BBCode 实现的 RSVP 流程——无法按语言复制，因为功能性 BBCode 必须恰好存在一次。唯一的变通方法是使用包含生硬双语标签（如“App-Version / App version:”）的单一模板，这会降低所有人的可读性。
建议：
- 在
category_localizations 中添加一个可空的 topic_template 文本列
- 编辑器逻辑：如果存在用户当前语言环境的本地化记录，则使用其模板；否则回退到
category.topic_template
- 在分类管理界面中按语言环境暴露/持久化该字段（位于本地化名称/描述旁边）
- 在翻译分类时，将
topic_template 纳入 AI 内容本地化流水线（类似 description 的处理方式）
迁移很简单（add_column :category_localizations, :topic_template, :text）；主要工作在于编辑器选择逻辑和管理界面。
考虑过的替代方案：
- 双语单一模板（当前的变通方法）——在遇到功能性 BBCode 块时会失效
- 通过主题组件注入按语言区分的文本——脆弱，缺乏服务器端验证，会导致 API 编辑器出错