如何设计双语CMS系统？博客类内容同步及数据库实现方案问询

我来分享几个在多语言CMS里处理博客类动态内容的成熟方案，都是实际项目里验证过的：

对于博客这类需要编辑的动态内容，双标签页切换是最直观的方案。比如在文章编辑页顶部，放「English」「Russian」两个标签，切换时能保留当前编辑的上下文（比如光标位置、已编辑内容）。

可以加几个实用细节：

• 给未完成翻译的标签加个「待翻译」小红标，提醒编辑/译者；
• 新增「同步基础字段」按钮，比如把标题、摘要的原文一键复制到目标语言版本，译者再做针对性修改，减少重复输入；
• 如果是多人协作（作者写原文，译者译另一语言），可以加版本锁定，避免同时编辑同一语言版本导致冲突。

根据你的业务规模和扩展需求，有两种主流方案可选：

方案一：单表多字段（适合语言数量固定、少语言场景） #

在博客主表中直接为每种语言添加对应字段，比如：

CREATE TABLE posts (
    id INT PRIMARY KEY AUTO_INCREMENT,
    slug VARCHAR(255) UNIQUE NOT NULL, -- 全局唯一的URL标识，和语言无关
    publish_date DATETIME NOT NULL,
    author_id INT NOT NULL,
    status ENUM('draft', 'published') NOT NULL,
    -- 多语言字段
    title_en VARCHAR(255) NOT NULL,
    content_en TEXT NOT NULL,
    excerpt_en TEXT,
    title_ru VARCHAR(255),
    content_ru TEXT,
    excerpt_ru TEXT,
    FOREIGN KEY (author_id) REFERENCES users(id)
);

优点：查询速度快，不需要关联表，代码逻辑简单；缺点：新增语言时需要修改表结构，扩展性较差。

方案二：主表+翻译表关联（推荐，适合长期扩展） #

用主表存储博客的公共非语言相关数据，子表存储每种语言的翻译内容，结构如下：

-- 主表：存公共数据
CREATE TABLE posts (
    id INT PRIMARY KEY AUTO_INCREMENT,
    slug VARCHAR(255) UNIQUE NOT NULL,
    publish_date DATETIME NOT NULL,
    author_id INT NOT NULL,
    status ENUM('draft', 'published') NOT NULL,
    FOREIGN KEY (author_id) REFERENCES users(id)
);

-- 翻译表：存多语言内容
CREATE TABLE post_translations (
    id INT PRIMARY KEY AUTO_INCREMENT,
    post_id INT NOT NULL,
    language_code VARCHAR(5) NOT NULL, -- 用'en'/'ru'这种标准码
    title VARCHAR(255) NOT NULL,
    content TEXT NOT NULL,
    excerpt TEXT,
    translator_id INT, -- 可选：记录译者信息
    translated_at DATETIME, -- 可选：记录翻译时间
    FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE,
    UNIQUE KEY (post_id, language_code) -- 确保同一帖子同一语言只有一条翻译
);

优点：扩展性极强，新增语言不需要改表；能存储更多翻译相关的元数据；缺点：查询时需要关联两张表，但只要给post_id和language_code加好索引，性能完全没问题。

针对博客内容的同步需求，可以做这些逻辑：

• 新建帖子时：先创建主表的公共数据，自动生成对应语言的翻译记录（可以留空，标记为「待翻译」），或者让用户先填写一种语言的内容，再一键复制到另一语言版本做修改；
• 公共字段同步：修改发布日期、状态、作者这类公共字段时，直接更新主表，所有语言版本自动同步生效；
• 翻译更新提示：当其中一种语言的内容更新后，在另一语言的编辑页弹出提示：「English版本已更新，是否同步最新内容？」，用户可以选择一键复制原文到目标语言，再做翻译调整；
• 发布校验：可以设置规则，比如必须两种语言都完成翻译才能发布，或者允许单语言发布（根据你的业务需求灵活调整）。

静态内容（关于我们、联系方式）用数组存的方式可以保留，只需要和动态博客内容的语言标识统一（比如都用'en'/'ru'作为语言码）：

• 前端路由统一用语言前缀，比如/en/blog/post-slug、/ru/blog/post-slug，根据路由中的语言码去查询对应翻译表的内容；
• 站点语言切换时，根据当前页面的slug，自动跳转到对应语言的博客版本（如果存在），不存在则提示「该内容暂无此语言版本」；
• 把静态i18n数组和动态博客内容的查询逻辑，封装到同一个语言工具类里，确保整个站点的语言切换逻辑一致。

这些方案里，主表+翻译表的关联方式是大部分成熟多语言CMS（比如WordPress多语言插件、Strapi）的通用思路，灵活性和扩展性都更好，推荐优先考虑。

内容的提问来源于stack exchange，提问作者Vladislav Sorokin