一句话概括
WPML 产出翻译任务 → QueueLingo 自动监听并接管 → 解析 XLIFF/HTML 可翻译节点 → 调用机器翻译或 LLM → 生成回写结果 → 推送回 WPML → 任务完成并记录消费明细。
1. 整体流程（从“发起任务”到“自动交付”）
下面是典型的全链路：
WPML 创建翻译任务
你在 WPML 中为文章/页面/字符串创建翻译任务后，WPML 会将其进入翻译队列，并生成对应的 XLIFF（或可映射为 XLIFF 的结构化任务）。QueueLingo 自动监听队列
插件会持续监听 WPML 翻译队列的任务变化，识别出“待处理”的任务并接管处理（托管翻译）。拉取任务并解析内容结构
QueueLingo 获取到任务后，会解析内容结构，定位可翻译节点，并准备翻译输入。执行翻译（MT 或 LLM）
免费用户：走免费神经网络翻译（MT），提供服务商包含google，edge，zov
订阅用户：可用 AI大模型翻译(LLM)（也可以自定义第三方LLM引擎不走平台额度）
生成翻译结果并回写到任务
翻译完成后，将目标语言文本写回对应节点，保持原有结构/占位符/标签尽量不变。自动交付回 WPML
完成的任务会被自动推送回 WPML，WPML 接收后就能进入后续的审核/发布流程。记录任务与消费明细
后台会生成消耗记录
翻译任务记录（状态、耗时、失败原因等）
任务消费明细（引擎/模型、token、扣费口径）
2. 为什么我们更省 token（优势）
QueueLingo 不会把整篇网页/整段 HTML 原样丢给翻译引擎，而是采用“只翻译需要翻译的部分”的策略：
2.1 翻译任务：精确提取翻译节点
网页内容被拆分成很多“翻译单元”。
QueueLingo 会从 内容结构进行解析定位这些单元，只把真正需要翻译的文本送去翻译引擎。
2.2 HTML/富文本内容：自动抽取可翻译文本再替换回去
对于包含 HTML 的内容（例如带标签、链接、格式化文本）：
系统会抽取可翻译的可见文本（而不是标签、属性、结构代码）
翻译后再将文本精准替换回原结构
这通常能显著减少：
发送给模型的无效 token（HTML 标签、重复结构）
模型“误翻标签/破坏结构”的概率
结果：在保证译文质量的同时，实际 token 消耗更节省，成本也更可控。