WordPress Polylang AI 翻译全自动化实践笔记

从手动操作 85 分钟，到 Bash 脚本 10 秒，再到 AI 全自动翻译 30 秒 —— 一次 WordPress 多语言站点的自动化升级之旅

背景与动机

痛点

在运营多语言 WordPress 站点时，使用 Polylang 插件虽然功能强大，但手动操作极其繁琐：

创建一篇英文文章（5 分钟）
复制到翻译工具翻译（10 分钟）
为每种语言创建新文章（5 分钟 × 5 语言 = 25 分钟）
在 Polylang 后台逐个关联翻译（2 分钟 × 5 = 10 分钟）
为每个语言版本设置 SEO 元数据（5 分钟 × 5 = 25 分钟）
检查和修正格式问题（10 分钟）

总计：每篇文章需要 85 分钟！

效率对比

方案	耗时	效率提升	翻译质量	SEO 优化	技术栈
手动操作	85 分钟	-	取决于人工	手动编写	WordPress 后台
Bash 脚本	10 秒	510 倍	无翻译	无	Bash + WP-CLI
AI 自动翻译	30 秒	170 倍	GPT-4o 专业翻译	自动生成	TypeScript + Bun + AI

目标

实现一键全自动化：

✅ 创建一篇英文文章
✅ 运行一条命令
✅ 自动翻译到 6 种语言
✅ 自动生成 SEO 元数据
✅ 自动配置 Polylang 关联
✅ 智能跳过已翻译内容
✅ 保护 HTML 标签和格式

从 85 分钟到 30 秒，效率提升 170 倍。

第一步：研究 Polylang 的数据结构

先用 WP CLI 查看 Polylang 配置了哪些语言：

bash

wp term list language --format=table

结果发现 Polylang 使用了两个 taxonomy：

language - 标识文章的语言（en/zh/es）
post_translations - 存储翻译关联关系

关键发现：翻译组机制

查看翻译组的数据：

bash

wp term list post_translations --format=table --fields=slug,description,count

输出示例：

plaintext

slug                  description                                          count
pll_694d3ae12e0f4    a:3:{s:2:"en";i:47;s:2:"zh";i:48;s:2:"es";i:49;}    3

核心机制：

每个翻译组是一个 term
Slug 格式：pll_[随机十六进制]
Description 存储 PHP 序列化数组，映射语言代码到文章 ID
所有语言版本共享同一个翻译组 term

这就是 Polylang 关联翻译的核心！

第二步：手动测试流程

先用 WP CLI 手动创建一篇文章试试：

bash

# 创建英文文章
EN_ID=$(wp post create \
  --post_title="Test Article" \
  --post_name="test-article" \
  --post_content="Content here..." \
  --post_status=publish \
  --post_author=1 \
  --porcelain)

# 分配语言
wp post term set $EN_ID language en

重要踩坑：最开始没加 --post_author=1，结果文章的 post_author 是 0，导致中文和西班牙语版本访问时出现 404 错误！

英文版本能访问，但其他语言都 404。排查了很久才发现是作者字段的问题。

解决方案：创建文章时必须指定 --post_author。

bash

# 正确的方式
wp post create --post_author=1 --post_title="..." --post_status=publish --porcelain

创建翻译组并关联

bash

# 创建中文版本
ZH_ID=$(wp post create \
  --post_title="测试文章" \
  --post_name="test-article-zh" \
  --post_author=1 \
  --post_status=publish \
  --porcelain)

wp post term set $ZH_ID language zh

# 创建西班牙语版本
ES_ID=$(wp post create \
  --post_title="Artículo de Prueba" \
  --post_name="test-article-es" \
  --post_author=1 \
  --post_status=publish \
  --porcelain)

wp post term set $ES_ID language es

# 创建翻译组
TRANS_GROUP="pll_$(openssl rand -hex 6)"
wp term create post_translations "$TRANS_GROUP" \
  --slug="$TRANS_GROUP" \
  --description="a:3:{s:2:\"en\";i:$EN_ID;s:2:\"zh\";i:$ZH_ID;s:2:\"es\";i:$ES_ID;}"

# 关联所有文章到翻译组
wp post term set $EN_ID post_translations "$TRANS_GROUP"
wp post term set $ZH_ID post_translations "$TRANS_GROUP"
wp post term set $ES_ID post_translations "$TRANS_GROUP"

# 刷新 rewrite rules
wp rewrite flush

测试通过！所有语言版本都能访问，Polylang 也能正确识别翻译关系。

第三步：开发批量创建脚本

既然手动流程跑通了，开始写脚本自动化。

脚本 1：批量创建多语言文章

文件：create-multilang-posts.sh

功能：

输入数量 N，自动创建 N 组文章（每组 3 篇：en/zh/es）
自动生成翻译组并关联
自动分配特色图片

核心代码片段：

bash

# 自动获取作者
get_author_id() {
  wp user list --format=csv --fields=ID | tail -n +2 | head -1
}

# 创建单个文章组
create_multilang_post_set() {
  # 创建 EN 版本
  EN_ID=$(wp post create --post_title="$title" --post_author=1 --porcelain)
  wp post term set $EN_ID language en

  # 创建 ZH 版本
  ZH_ID=$(wp post create --post_title="$zh_title" --post_author=1 --porcelain)
  wp post term set $ZH_ID language zh

  # 创建 ES 版本
  ES_ID=$(wp post create --post_title="$es_title" --post_author=1 --porcelain)
  wp post term set $ES_ID language es

  # 创建翻译组
  TRANS_GROUP="pll_$(openssl rand -hex 6)"
  wp term create post_translations "$TRANS_GROUP" \
    --description="a:3:{s:2:\"en\";i:$EN_ID;s:2:\"zh\";i:$ZH_ID;s:2:\"es\";i:$ES_ID;}"

  # 关联
  wp post term set $EN_ID post_translations "$TRANS_GROUP"
  wp post term set $ZH_ID post_translations "$TRANS_GROUP"
  wp post term set $ES_ID post_translations "$TRANS_GROUP"
}

使用：

bash

bash create-multilang-posts.sh 3  # 创建 3 组（共 9 篇文章）

第四步：智能补全脚本

有时候我会先手动创建一篇英文文章，然后需要补全其他语言版本。所以需要一个智能脚本。

脚本 2：智能翻译补全

文件：create-missing-translations.sh

核心功能：

输入一个文章 ID
自动检测它是什么语言
动态查询系统配置了哪些语言（不硬编码）
判断缺少哪些语言版本
自动创建缺失的语言版本并关联

关键技术点：

1. 动态语言检测

bash

# 获取系统所有配置的语言
get_all_languages() {
  wp term list language --format=json --fields=slug | \
    grep -o '"slug":"[^"]*"' | cut -d'"' -f4
}

# 获取文章的语言
get_post_language() {
  wp post term list $1 language --format=csv --fields=slug | tail -1
}

这样无论系统有 3 个、5 个还是 10 个语言，脚本都能自动识别。

2. 检查现有翻译组

bash

# 获取翻译组
get_translation_group() {
  wp post term list $1 post_translations --format=csv --fields=slug | tail -1
}

# 解析已有的翻译（从 description 中）
get_existing_translations() {
  local desc=$(wp term list post_translations --format=csv | grep "^$1,")
  # 去除 CSV 引号转义
  desc=$(echo "$desc" | sed 's/^"//; s/"$//' | sed 's/""/"/g')
  # 提取语言代码
  echo "$desc" | grep -o 's:2:"[^"]*"' | cut -d'"' -f2
}

踩坑：CSV 输出的 description 字段会有引号转义，比如：

plaintext

"a:3:{s:2:""en"";i:66;s:2:""zh"";i:67;}"

需要先去除 CSV 引号才能正确解析。

3. Bash 3.2 兼容性问题

macOS 默认的 Bash 是 3.2 版本，不支持关联数组（declare -A）。

解决方案：用空格分隔的 “lang:postid” 格式存储映射：

bash

# 不用关联数组
# declare -A TRANSLATION_MAP  # ❌ Bash 3.2 不支持

# 用字符串存储
TRANSLATION_PAIRS="en:66 zh:67 es:68"

# 辅助函数
has_lang_in_pairs() {
  for pair in $1; do
    local lang=$(echo "$pair" | cut -d':' -f1)
    if [ "$lang" = "$2" ]; then
      return 0
    fi
  done
  return 1
}

使用：

bash

# 给定一个只有英文版本的文章 ID
bash create-missing-translations.sh 100

# 脚本会自动：
# 1. 检测到是 en 语言
# 2. 发现系统有 zh、es 语言
# 3. 创建缺失的 zh、es 版本
# 4. 关联到翻译组

幂等性：如果文章已经有完整的翻译，脚本会检测到并直接退出，不会重复创建。

bash

bash create-missing-translations.sh 66  # 已经有完整翻译

# 输出：
# [SUCCESS] All language versions already exist! Nothing to do.

第五步：翻译层架构

最后一步，设计了一个翻译层，为接入 AI 翻译 API 做准备。

翻译层接口

在 create-missing-translations.sh 中添加了清晰的翻译函数：

bash

################################################################################
# TRANSLATION LAYER
################################################################################

# 标题翻译
translate_title() {
  local source_lang=$1
  local target_lang=$2
  local source_title=$3

  # 当前：占位符实现
  case "$target_lang" in
    "zh") echo "${source_title} - 中文版" ;;
    "es") echo "${source_title} - Español" ;;
    *) echo "${source_title} - [${target_lang}]" ;;
  esac

  # 生产环境：替换为 AI API 调用
  # curl https://api.openai.com/v1/chat/completions \
  #   -H "Authorization: Bearer $OPENAI_API_KEY" \
  #   -d '{"model":"gpt-4","messages":[...]}'
}

# 内容翻译
translate_content() {
  local source_lang=$1
  local target_lang=$2
  local source_content=$3

  # 当前：添加翻译标记
  case "$target_lang" in
    "zh") echo "[已翻译为中文] $source_content" ;;
    "es") echo "[Traducido al español] $source_content" ;;
    *) echo "[Translated] $source_content" ;;
  esac
}

业务逻辑调用

bash

# 读取源文章内容
SOURCE_TITLE=$(wp post get $SOURCE_POST_ID --field=post_title)
SOURCE_CONTENT=$(wp post get $SOURCE_POST_ID --field=post_content)

# 对每个缺失的语言
for lang in "${MISSING_LANGUAGES[@]}"; do
  # 调用翻译层
  new_title=$(translate_title "$SOURCE_LANG" "$lang" "$SOURCE_TITLE")
  new_content=$(translate_content "$SOURCE_LANG" "$lang" "$SOURCE_CONTENT")

  # 创建翻译后的文章
  new_post_id=$(create_post "$new_title" "$new_slug" "$new_content" "$AUTHOR_ID")
done

接入真实 AI 翻译

要启用真实翻译，只需要：

设置 API Key：export OPENAI_API_KEY="sk-..."
替换 translate_title() 函数为 API 调用
替换 translate_content() 函数为 API 调用
安装 jq：brew install jq

预计工作量：30 分钟

最终成果

完整工作流程

场景 1：批量创建测试数据

bash

bash create-multilang-posts.sh 5
# → 创建 5 组文章（15 篇），自动关联翻译

场景 2：补全现有文章

bash

# 在后台手动创建一篇英文文章（ID: 200）
bash create-missing-translations.sh 200
# → 自动创建中文、西班牙语版本并关联

自动化效果

之前（仅创建空白文章，不含翻译）：

创建 1 篇英文文章：5 分钟
创建中文版本：5 分钟
创建西班牙语版本：5 分钟
在后台关联翻译：2 分钟
总计：17 分钟/组

现在（Bash 脚本自动化）：

创建 1 篇英文文章：5 分钟
运行脚本：10 秒
总计：约 5 分钟/组

时间节省：从 17 分钟降到 5 分钟，节省 70% 时间

关键收获

Polylang 翻译机制：
- 双 taxonomy 系统（language + post_translations）
- 翻译组用 PHP 序列化数组存储映射
- 所有版本共享一个翻译组 term
WP CLI 的坑：
- 必须设置 --post_author，否则 404
- CSV 输出需要处理引号转义
- Bash 3.2 不支持关联数组
架构设计：
- 翻译层分离，易于扩展
- 动态语言检测，不硬编码
- 幂等性设计，安全可重复运行

第六步：完整 AI 翻译系统（升级版）

经过前面的基础搭建，我开发了一个生产级的完整翻译系统 translate-complete.ts，实现了真正的 AI 自动翻译。

技术栈升级

从 Bash 脚本升级到 TypeScript + Bun runtime：

bash

# 安装 Bun runtime
curl -fsSL https://bun.sh/install | bash

# 配置 AI API Key
export AI_API_KEY="your-api-key-here"

核心功能特性

✅ 并行翻译 - 同时翻译到多个语言，速度快

typescript

// 并行调用 API，一次性翻译到 5 种语言
const translations = await Promise.all(
  targetLangs.map(lang => translateContent(content, lang))
);

✅ 智能跳过已翻译 - 自动检测避免重复

typescript

// 检查每个语言是否已有翻译版本
const existingTranslations = await getExistingTranslations(postId);
const missingLangs = targetLangs.filter(lang => !existingTranslations[lang]);

✅ SEO 自动生成 - 每个语言版本独立优化

typescript

// 为每个语言生成专业的 SEO 元数据
const seo = await generateSEO(title, content, targetLang);
// { title: "...", description: "..." }

✅ HTML 完美保护 - 保留所有标签和格式

typescript

// AI 翻译时明确指令保护 HTML
const prompt = `Translate the following HTML content.
IMPORTANT: Keep all HTML tags exactly as they are...`;

✅ 日期随机化 - 翻译文章发布日期随机偏移 1-7 天

typescript

// 避免所有语言版本同一天发布
const randomDays = Math.floor(Math.random() * 7) + 1;
const newDate = new Date(originalDate);
newDate.setDate(newDate.getDate() + randomDays);

✅ 多语言支持 - 支持 6 种语言

🇨🇿 Czech (捷克语)
🇩🇪 German (德语)
🇪🇸 Spanish (西班牙语)
🇵🇹 Portuguese (葡萄牙语)
🇷🇺 Russian (俄语)
🇨🇳 Chinese Simplified (简体中文) - 可选

使用方式

基本用法：

bash

bun translate-complete.ts 28112
# 翻译文章 28112 到所有语言（自动跳过已翻译）

指定语言：

bash

bun translate-complete.ts 28112 --langs=es,pt,de
# 只翻译到西班牙语、葡萄牙语、德语

包含中文：

bash

bun translate-complete.ts 28112 --include-zh
# 翻译到所有语言，包括中文

批量翻译：

bash

# 翻译多篇文章
for id in 28112 26918 26373; do
  bun translate-complete.ts $id
done

# 翻译所有英文文章
wp post list --post_type=post --lang=en --field=ID | while read id; do
  bun translate-complete.ts $id
done

工作流程

完整的翻译流程自动化：

读取原文 - 获取文章标题、内容、摘要、元数据
检查已有翻译 - 避免重复翻译已存在的语言版本
并行翻译 - 同时翻译标题、内容、摘要到所有目标语言
创建文章 - 为每个语言创建新文章，设置 slug 后缀
生成 SEO - 为每个语言版本生成专业的 SEO 元数据
配置关联 - 更新 Polylang 翻译关系，关联所有语言版本

实际效果

翻译速度：

之前（手动）：创建 + 翻译 + SEO 优化 = 85 分钟/篇
现在（AI 自动）：约 30 秒（并行翻译）

效率提升：从 85 分钟降到 30 秒，提升 170 倍

翻译质量：使用 GPT-4o 模型，针对行业术语优化，翻译准确度高，SEO 友好。

关键技术要点

1. API 并发控制

typescript

// 使用 Promise.all 实现真正的并行翻译
const [titleTrans, contentTrans, excerptTrans] = await Promise.all([
  translateTitle(title, targetLang),
  translateContent(content, targetLang),
  translateExcerpt(excerpt, targetLang)
]);

2. Polylang Term ID 更新

typescript

// 使用 term_id 而非 slug 更新关联（更可靠）
const termId = await getTranslationGroupTermId(groupSlug);
await execAsync(`wp post term set ${postId} post_translations ${termId}`);

3. Slug 管理策略

typescript

// 为不同语言添加后缀，避免冲突
// 原文：what-is-pcba
// 西班牙语：what-is-pcba-es
// 德语：what-is-pcba-de
const slug = `${originalSlug}-${targetLang}`;

4. 错误处理和重试

typescript

// API 调用失败时自动重试
async function callAPIWithRetry(payload, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await callAPI(payload);
    } catch (error) {
      if (i === maxRetries - 1) throw error;
      await sleep(1000 * (i + 1)); // 指数退避
    }
  }
}

代码仓库

所有脚本和文档都已整理好：

plaintext

project/
├── translate-complete.ts              # 🔥 完整 AI 翻译系统（生产级）
├── create-multilang-posts.sh          # 批量创建脚本
├── create-missing-translations.sh     # 智能补全脚本（带翻译层）
├── check-translation-status.sh        # 检查翻译状态
├── check-all-posts-translation.sh     # 检查所有文章翻译
├── TRANSLATION-COMPLETE-GUIDE.md      # 完整使用指南
└── PROJECT_LOG.md                      # 详细技术文档

已完成功能

接入 AI API 实现真实翻译（GPT-4o）
并行翻译，速度提升 170 倍
自动生成 SEO 元数据
智能跳过已翻译内容
HTML 标签完美保护
日期随机化
支持 6 种语言
Polylang 完整集成

未来改进方向

支持自定义文章类型（Custom Post Types）
支持分类和标签的翻译
添加翻译质量检查（AI 评分）
支持更多 AI 模型（Claude, Gemini）
添加翻译缓存机制

总结

从手动操作到 AI 全自动翻译，整个项目的演进过程：

第一阶段：手动操作（85 分钟/篇）

在后台逐个创建多语言文章
手动翻译和关联翻译关系
手动编写 SEO 元数据
效率低下，容易出错

第二阶段：Bash 脚本自动化（约 5 分钟/篇）

使用 WP-CLI 批量创建文章
自动配置 Polylang 翻译组
节省 70% 时间，但内容仍需手动翻译

第三阶段：AI 全自动翻译（30 秒/篇）

TypeScript + Bun runtime
GPT-4o 并行翻译到 6 种语言
自动生成 SEO 元数据
相比手动操作，效率提升 170 倍

关键收获

先理解机制：深入研究 Polylang 的数据结构（双 taxonomy 系统），才能准确实现自动化
逐步验证：先手动测试流程，确保每一步都正确，再写脚本
关注细节：post_author 404 问题、CSV 转义、Bash 版本兼容性等小坑都可能导致失败
架构分层：翻译层分离设计，易于扩展和维护
拥抱新技术：Bun runtime 比 Node.js 更快，TypeScript 比 Bash 更可靠
并发优化：并行 API 调用，充分利用异步特性

最终成果

现在只需要一条命令 + 30 秒，就能：

✅ 翻译文章到 6 种语言
✅ 生成每个语言的 SEO 元数据
✅ 自动配置 Polylang 翻译关系
✅ 保护所有 HTML 标签和格式
✅ 智能跳过已翻译内容

这就是自动化和 AI 的力量！从 85 分钟到 30 秒，效率提升 170 倍。

常见问题解答（FAQ）

Q1: 为什么选择 Bun 而不是 Node.js？

A: Bun 的优势：

启动速度快 3-4 倍
内置 TypeScript 支持，无需编译
自带 fetch API，代码更简洁
更低的内存占用

对比测试：

bash

# Node.js + ts-node
time npx ts-node translate.ts 28112  # ~2.5s 启动时间

# Bun
time bun translate.ts 28112          # ~0.3s 启动时间

Q2: AI 翻译的成本是多少？

A: 以 GPT-4o 为例：

输入：$2.50 / 1M tokens
输出：$10.00 / 1M tokens

一篇 2000 字文章翻译到 5 种语言：

输入：~10K tokens × 5 = 50K tokens ≈ $0.125
输出：~10K tokens × 5 = 50K tokens ≈ $0.50
总成本：~$0.625 / 篇

相比人工翻译（$0.05-0.10 / 词），成本降低 90%+。

Q3: 翻译质量如何保证？

A: 多重策略：

专业 Prompt：针对行业术语优化
上下文保留：传入公司背景信息
品牌名保护：明确指令不翻译特定词汇
HTML 保护：保持标签完整性
人工校对：关键文章发布前复核

实际测试：GPT-4o 翻译准确率 95%+，仅需少量人工调整。

Q4: 如何避免 API 请求超时？

A: 实现了多重保护：

typescript

// 1. 设置合理的超时时间
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 60000);

// 2. 自动重试机制
async function callAPIWithRetry(maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await callAPI();
    } catch (error) {
      if (i === maxRetries - 1) throw error;
      await sleep(1000 * (i + 1)); // 指数退避
    }
  }
}

// 3. 进度持久化
// 每翻译完一种语言，立即创建文章
// 即使中途失败，已完成的翻译不会丢失

Q5: 支持哪些 WordPress 版本和插件？

A: 测试环境：

WordPress: 6.0+
Polylang: 3.0+
SEOPress: 6.0+（可选，用于 SEO 元数据）
WP-CLI: 2.6+

Q6: 能否翻译已发布的旧文章？

A: 可以！脚本会：

检测原文章状态（draft/publish）
保持相同状态创建翻译
智能跳过已存在的翻译版本

批量翻译所有英文文章：

bash

wp post list --post_type=post --lang=en --post_status=publish --field=ID | \
  while read id; do
    bun translate-complete.ts $id
    sleep 2  # 避免 API 限流
  done

Q7: 翻译失败如何处理？

A: 内置完善的错误处理：

typescript

try {
  await translatePost(postId);
} catch (error) {
  console.error(`翻译失败: ${error.message}`);
  // 1. 记录错误日志
  await logError(postId, error);
  // 2. 发送通知（可选）
  await sendNotification(error);
  // 3. 不影响其他文章继续翻译
  continue;
}

常见错误和解决方案：

API Key 无效：检查 AI_API_KEY 环境变量
WP-CLI 失败：确认在 WordPress 根目录运行
权限问题：检查文件执行权限 chmod +x translate-complete.ts
内存不足：处理大文章时增加 Node/Bun 内存限制

Q8: 如何自定义翻译的语言列表？

A: 修改配置很简单：

typescript

// translate-complete.ts 第 175 行
const DEFAULT_TARGET_LANGS = ['cs', 'de', 'es', 'pt', 'ru'];

// 修改为你需要的语言
const DEFAULT_TARGET_LANGS = ['fr', 'it', 'ja', 'ko'];

或使用命令行参数：

bash

bun translate-complete.ts 28112 --langs=fr,it,ja

性能优化技巧

1. 批量翻译优化

bash

# ❌ 不推荐：逐个翻译（慢）
for id in 100 101 102 103 104; do
  bun translate-complete.ts $id
done

# ✅ 推荐：并发翻译（快）
echo "100 101 102 103 104" | xargs -n 1 -P 3 -I {} \
  bun translate-complete.ts {}
# -P 3 表示同时运行 3 个进程

2. API 调用优化

typescript

// ✅ 使用连接池复用
const keepAliveAgent = new http.Agent({ keepAlive: true });

// ✅ 压缩请求内容
headers: {
  'Content-Encoding': 'gzip',
}

// ✅ 缓存翻译结果
const cache = new Map();
if (cache.has(cacheKey)) return cache.get(cacheKey);

3. 数据库查询优化

bash

# ❌ 每次都查询数据库
for id in $(wp post list --field=ID); do
  bun translate-complete.ts $id
done

# ✅ 一次性获取所有 ID
IDS=$(wp post list --lang=en --field=ID --format=csv)
echo "$IDS" | xargs -n 1 -P 3 bun translate-complete.ts

安全注意事项

1. API Key 保护

bash

# ❌ 不要直接写在代码里
const API_KEY = "sk-1234567890abcdef";

# ✅ 使用环境变量
const API_KEY = process.env.AI_API_KEY;

# ✅ 使用 .env 文件（不要提交到 Git）
echo "AI_API_KEY=sk-xxx" > .env
echo ".env" >> .gitignore

2. 输入验证

typescript

// 验证文章 ID
if (!postId || isNaN(postId)) {
  throw new Error('Invalid post ID');
}

// 验证语言代码
const VALID_LANGS = ['en', 'cs', 'de', 'es', 'pt', 'ru', 'zh'];
if (!VALID_LANGS.includes(lang)) {
  throw new Error('Invalid language code');
}

3. 数据库备份

bash

# 运行翻译前，先备份数据库
wp db export backup-$(date +%Y%m%d-%H%M%S).sql

# 或使用插件自动备份
wp plugin install updraftplus --activate

4. 测试环境验证

bash

# 1. 在测试环境运行
wp option update siteurl 'https://staging.yoursite.com'

# 2. 翻译测试文章
bun translate-complete.ts 999

# 3. 验证结果
wp post list --lang=es --post_parent=999

# 4. 确认无误后，部署到生产环境

生产环境部署清单

前置准备

安装 Bun runtime (curl -fsSL https://bun.sh/install | bash)
配置 AI API Key (export AI_API_KEY="xxx")
安装 WP-CLI (wp --version)
安装 Polylang 插件 (wp plugin install polylang --activate)
配置语言列表（在 WordPress 后台 Polylang 设置）

功能测试

测试单篇文章翻译 (bun translate-complete.ts 1)
测试指定语言翻译 (bun translate-complete.ts 1 --langs=es)
测试智能跳过功能（重复运行同一文章）
验证 Polylang 关联关系（在后台查看）
验证 SEO 元数据（检查 SEOPress 设置）
验证 HTML 标签完整性（对比原文和译文）

性能测试

测试批量翻译（10 篇文章）
监控 API 调用次数和成本
检查服务器负载（CPU/内存）
测试错误恢复机制

安全检查

API Key 不在代码中硬编码
.env 文件已加入 .gitignore
数据库定期备份
错误日志记录正常
访问权限控制（仅授权用户可执行）

监控告警

设置翻译失败告警
监控 API 调用费用
记录翻译历史日志
定期审查翻译质量

扩展阅读

初稿：2025-12-25 更新：2025-12-26 - 添加 AI 翻译系统、常见问题、性能优化

WordPress + Polylang + AI 翻译完全自动化实践

背景与动机

痛点

效率对比

目标

第一步：研究 Polylang 的数据结构

关键发现：翻译组机制

第二步：手动测试流程

创建翻译组并关联

第三步：开发批量创建脚本

脚本 1：批量创建多语言文章

第四步：智能补全脚本

脚本 2：智能翻译补全

1. 动态语言检测

2. 检查现有翻译组

3. Bash 3.2 兼容性问题

第五步：翻译层架构

翻译层接口

业务逻辑调用

接入真实 AI 翻译

最终成果

完整工作流程

自动化效果

关键收获

第六步：完整 AI 翻译系统（升级版）

技术栈升级

核心功能特性

使用方式

工作流程

实际效果

关键技术要点

代码仓库

已完成功能

未来改进方向

总结

第一阶段：手动操作（85 分钟/篇）

第二阶段：Bash 脚本自动化（约 5 分钟/篇）

第三阶段：AI 全自动翻译（30 秒/篇）

关键收获

最终成果

常见问题解答（FAQ）

Q1: 为什么选择 Bun 而不是 Node.js？

Q2: AI 翻译的成本是多少？

Q3: 翻译质量如何保证？

Q4: 如何避免 API 请求超时？

Q5: 支持哪些 WordPress 版本和插件？

Q6: 能否翻译已发布的旧文章？

Q7: 翻译失败如何处理？

Q8: 如何自定义翻译的语言列表？

性能优化技巧

1. 批量翻译优化

2. API 调用优化

3. 数据库查询优化

安全注意事项

1. API Key 保护

2. 输入验证

3. 数据库备份

4. 测试环境验证

生产环境部署清单

前置准备

功能测试

性能测试

安全检查

监控告警

扩展阅读