Traduora 介绍与选型指南

一、Traduora 是什么

Ever® Traduora 是 Ever Co. LTD 旗下的开源翻译管理平台（Translation Management Platform，TMS），面向需要对产品、应用、网站进行多语言本地化（i18n / l10n）的开发团队与内容团队。平台提供 Web 管理界面 + REST API，支持 JSON、YAML、Gettext（.po）、XLIFF、Android XML 等十多种翻译格式的导入导出，自带团队协作、词条搜索、批量导入导出等核心能力。

Traduora 的定位是「开发者友好的翻译基础设施」——与面向纯翻译团队的重量级商业 TMS 不同，它强调与 CI/CD 流水线集成（通过 REST API 自动同步翻译词条）、支持多格式无缝切换、5 分钟快速部署，适合中小团队和技术驱动的本地化场景。

💡 翻译管理平台（TMS） 是一类专门管理多语言翻译流程的系统，核心能力包括：词条（term）集中管理、多语言翻译存储、导入导出、工作流审批、团队协作。市场上主要分为商业 TMS（Smartling、Transifex、POEditor）和开源 TMS（Traduora、Tolgee、Weblate、Pootle）两类。Traduora 属于后者中更偏向开发者场景的一员——它原生提供 REST API，方便与代码仓库、构建流水线对接，而非纯 Web 人工翻译工作台。

官方定位（官网 traduora.co，2026-10-27 查询）：Open Translation Management Platform for teams，核心产品 AGPL-3.0 开源。

二、技术栈与架构

2.1 技术栈

⚠️ 注意：多个批次任务书曾标注 Traduora 为「Go + Vue.js」技术栈，属历史信息。本文档以 2026-10-27 GitHub 仓库 ever-co/ever-traduora 的 package.json（version 0.23.0）和源码实查为准：后端为 Node.js + TypeScript（NestJS），前端为 Vue.js，数据库默认 better-sqlite3。

2.2 架构概览

Traduora 采用经典的前后端分离但打包一体化的架构：

• API Server（NestJS）：提供 /api/v1/ 下所有 REST 端点，处理认证、项目管理、词条/翻译 CRUD、导入导出任务等业务逻辑
• Web App（Vue.js SPA）：打包后的前端静态文件由 NestJS 后端在同端口（默认 8080）下的根路径提供服务
• 数据库：TypeORM 连接，自动迁移（TR_DB_AUTOMIGRATE=true），应用启动时自动执行 pending migrations
• 入口脚本：单容器通过 docker-entrypoint.sh 启动 NestJS，前端已嵌入 public/ 目录

┌─────────────────────────────────────────────┐
│              everco/ever-traduora           │
│  ┌──────────────┐  ┌──────────────────────┐ │
│  │  NestJS API  │  │  Vue.js SPA (public) │ │
│  │  :8080 API   │  │  :8080 / (Web UI)    │ │
│  └──────┬───────┘  └──────────────────────┘ │
│         │                                    │
│    TypeORM                                   │
│         │                                    │
│  ┌──────▼───────┐                            │
│  │  Database    │  SQLite/MySQL/PostgreSQL   │
│  └──────────────┘                            │
└─────────────────────────────────────────────┘

2.3 API 资源模型

Traduora REST API（基础路径 /api/v1/）的核心资源层级：

User
  └─ Project
       ├─ ProjectUser (协作者，角色 Admin/Editor/Viewer)
       ├─ ProjectClient (API 客户端，client_credentials 认证)
       ├─ ProjectInvite (邀请链接)
       ├─ Term (词条，带 label 标签)
       │    └─ Translation (按 locale 分类)
       ├─ Label (词条/翻译分组标签)
       ├─ Import / Export (批量操作任务)
       ├─ Stats (项目统计)
       └─ Plan (套餐，默认 open-source)

Locale (语言注册表，/api/v1/locales)

三、功能全景

3.1 核心功能清单

3.2 支持的翻译格式（11 种）

Traduora 支持以下格式的导入和导出，覆盖前端、后端、移动端常见本地化场景：

3.3 API 客户端与集成

Traduora 项目内建「Project Client」概念——每项目可创建多个 API 客户端，用 client_credentials 授权类型获取 token。这意味着：

• CI/CD 流水线可在构建时通过 API 拉取最新翻译值
• 翻译更新可通过 Webhook 或定时任务自动推送到代码仓库
• 不需要真实用户登录即可执行导入导出、词条 CRUD

社区还提供了非官方 CLI：github.com/iilei/traduora-cli。

四、版本与社区现状

4.1 版本时间线（重要变化）

⚠️ 重要安全变更（0.23.0）：之前版本存在公开已知的默认密码（如 sTr0ngP@ssw0rd!2025），自 0.23.0 起这些密码首次登录后会被自动失效。生产部署必须显式设置 TR_SECRET（openssl rand -hex 32 生成）和 TR_ADMIN_PASSWORD。

五、选型决策：Traduora vs 同类方案

5.1 同类方案对比矩阵

5.2 选型建议（按场景）

选 Traduora 的场景：

• ✅ 中小团队（50 项目内、10 万字符串内，默认为 open-source 套餐上限，可改）
• ✅ 开发者为主，需要 REST API 嵌入 CI/CD 流水线（client_credentials 认证特别方便）
• ✅ 快速启动：5 分钟内 Docker Compose 拉起（SQLite 模式）
• ✅ 技术栈偏好 Node.js 生态
• ✅ AGPL-3.0 许可可接受

选 Tolgee 的场景：

• ✅ 同样自托管 + 开源
• ✅ 自带机器翻译（Google / DeepL / Azure）原生集成
• ✅ Go 技术栈偏好
• ✅ Apache-2.0 许可更宽松

选 Weblate 的场景：

• ✅ 需要最丰富的格式支持（40+ 种）
• ✅ 大型社区项目翻译协作
• ✅ 有 Python / Django 技术栈偏好

选商业 SaaS 的场景：

• ✅ 完全不想运维（POEditor / Smartling）
• ✅ 需要企业级 SSO、工作流审批、专业服务
• ✅ 海量翻译（百万级字符串）

排除 Traduora 的场景：

• ❌ 需要原生机器翻译集成（规划中，当前版本无）
• ❌ 超大规模项目（需评估 open-source 套餐上限）
• ❌ 团队纯译员无技术背景（Traduora 的 Web UI 简洁但不如 POEditor 丰富）

5.3 Traduora 的优势与劣势

优势：

• 极简部署：SQLite 模式下 Docker Compose 一条命令启动，无需单独数据库
• REST API 覆盖全面，client_credentials 认证天生适合 CI/CD 集成
• TypeORM 自动迁移，版本升级平滑
• 格式覆盖主流开发场景（前端 JSON/YAML、后端 PO/Properties、移动端 Android XML/Strings）
• AGPL-3.0 核心产品永远免费无限制

劣势：

• 社区规模不如 Weblate（~1.5k vs ~5k stars）
• 无内建机器翻译（需第三方法接）
• open-source 套餐有 100k 字符串上限（可通过配置覆盖，但属未文档化操作）
• 生产部署仍需 MySQL/PostgreSQL + 反向代理 TLS（官方明确警告 JWT token 安全）
• 0.23.0 起强制安全配置，绕过易踩坑

六、适用人群与规模建议

open-source 套餐默认上限（可通过 TR_DEFAULT_PROJECT_PLAN 配置覆盖）：

• 每用户最多 100 个项目
• 每项目最多 100,000 字符串（term + translation 合计）
• 无时间或团队人数限制

七、合规与安全要点

1. JWT 必走 HTTPS：Traduora 使用 JWT Bearer Token，官方强烈建议放在 TLS 终止的反向代理之后
2. TR_SECRET 必须设置：0.23.0 起，NODE_ENV=production 时未设置 TR_SECRET 直接启动失败；即使 dev 环境，也会拒绝公开已知默认值
3. TR_ADMIN_PASSWORD 必须设置：0.23.0 起无默认管理员密码，必须显式配置
4. 登录失败锁定：TR_LOGIN_ATTEMPTS_MAX 默认 3 次，900 秒 TTL
5. API 速率限制：TR_AUTH_THROTTLE_LIMIT 生产默认 100/min，开发环境 10/min
6. 邮件验证：Google OAuth 和邮箱注册可选启用（TR_AUTH_GOOGLE_*、TR_SIGNUPS_ENABLED）
7. 数据隐私：自托管模式下翻译数据完全在自有数据库中，符合 GDPR 等隐私法规

八、快速体验

# 5 分钟快速体验（SQLite，无需单独数据库）
git clone https://github.com/ever-co/ever-traduora
cd ever-traduora
export TR_SECRET=$(openssl rand -hex 32)
export TR_ADMIN_PASSWORD=q1w2e3r4
docker compose -f docker-compose.demo.yaml up -d

# 浏览器访问
open http://localhost:8080
# 默认管理员：local.admin@ever.co / q1w2e3r4

九、延伸阅读

• 《Ubuntu 22.04 安装 Traduora 0.23 指南》：裸机从零安装全流程
• 《Traduora 0.23 Docker Compose 部署指南》：SQLite/MySQL/PostgreSQL 三种 Compose 方案
• 《Traduora 0.23 配置参数详解》：30+ 环境变量逐项说明
• 《Traduora 0.23 REST API 详解》：API v1 全部端点 + curl 示例

十、信息来源