基于Vite + i18n的全栈项目数据库已有条目国际化方案咨询

• 优先读取预存翻译：前端切换语言后，请求后端数据时携带当前语言标识（如?lang=en），后端优先返回对应语言的翻译内容；若该语言翻译不存在，返回原始葡萄牙语文本，同时触发后台异步翻译任务，生成对应语言的翻译并存储，下次请求即可直接返回。
• 前端临时翻译兜底：如果后端未返回目标语言翻译，可在前端调用翻译API临时处理（需注意API调用频率限制），同时提示用户“翻译中”或直接显示原始文本，避免等待。
• 结合i18n的字段映射：不在前端i18n中硬编码动态数据，而是根据当前语言标识，动态渲染接口返回的对应字段（如接口返回name_en则渲染该字段，返回name_pt-BR则渲染原语言字段）。

• 自动翻译API + 缓存存储：
  • 集成成熟翻译API（如DeepL、Google翻译），后端在收到新的葡萄牙语数据时，自动触发批量翻译，将结果预存到数据库（比如优先翻译为英语、西班牙语等主流语言）。
  • 对于未预翻译的语言，前端切换时后端实时调用API翻译，同时将结果写入数据库缓存，避免重复调用。
• 后台异步翻译队列：数据量较大时，不要同步翻译，将任务放入异步队列（如Redis Queue）后台定时处理，避免影响接口响应速度。
• 翻译质量兜底机制：添加translation_status字段（可选值：pending/completed/failed），翻译失败时显示原始文本，同时允许管理员手动修正翻译内容。

根据数据库类型，推荐两种主流方案：

方案1：独立翻译表（关系型数据库优先） #

适合MySQL、PostgreSQL等关系型数据库，结构清晰，查询性能高：

• 主表（entries）：存储非语言相关核心数据

CREATE TABLE entries (
  id INT PRIMARY KEY AUTO_INCREMENT,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

• 翻译表（entry_translations）：存储每个字段的多语言版本

CREATE TABLE entry_translations (
  id INT PRIMARY KEY AUTO_INCREMENT,
  entry_id INT NOT NULL,
  language_code VARCHAR(5) NOT NULL, -- 遵循ISO 639-1标准，如"en", "pt-BR"
  name VARCHAR(255) NOT NULL,
  description TEXT,
  FOREIGN KEY (entry_id) REFERENCES entries(id),
  UNIQUE KEY (entry_id, language_code) -- 确保同一条目同一语言仅存一条翻译
);

查询时关联获取对应翻译：

SELECT et.name, et.description
FROM entries e
JOIN entry_translations et ON e.id = et.entry_id
WHERE e.id = 1 AND et.language_code = 'en';

方案2：JSON字段存储多语言（NoSQL或快速开发场景） #

适合MongoDB等NoSQL数据库，或快速迭代项目，结构灵活：

{
  "id": 1,
  "created_at": "2024-05-20T12:00:00Z",
  "translations": {
    "pt-BR": {
      "name": "Camisa Azul",
      "description": "Camisa de algodão azul tamanho M"
    },
    "en": {
      "name": "Blue Cotton Shirt - Size M",
      "description": "Blue cotton shirt, size M"
    }
  }
}

查询时直接通过translations.en获取对应语言内容，MongoDB支持直接查询JSON字段内的数据。

最佳实践 #

• 统一使用ISO 639-1语言代码（如en、pt-BR），避免语言标识混乱。
• 永久保留原始葡萄牙语内容，作为翻译基准和兜底方案。
• 对高频查询的语言提前预翻译并存储，减少实时翻译依赖。

内容的提问来源于stack exchange，提问作者Rafael Drigo