机器翻译成泰语常见的错误，以及如何检查

下面列出五类能通过语法检查的错误，并给出一套不懂泰语的人也能在每批译文上执行的审校流程。最后说明经过这套审校后，机器译文在哪些场景已经可以直接上线。示例使用 Paxa Translate Lite 及其字段，这些检查也适用于任何引擎的输出。

语体漂移#

每个泰语句子都处在某一正式程度上，这体现在句末语气词、代词和动词上。一个产品往往分批翻译，前后持续几个月，每批译文的正式程度都由引擎根据该批文本推断。客服话术译得礼貌，新手引导译得随意，服务条款译得正式。每批单独看都没错，合在一起，产品就有了三种口吻。

上面两行都是通顺的泰语。第一行适合聊天应用，第二行适合银行，一个产品若在订单页显示其中一行、在邮件里显示另一行，语体就已经漂移了。礼貌程度一文详细讲解了三种语体。解决漂移的办法是作出一个决定，写下来，随每个请求一起发送。

用错代词#

英语里“我”只有 I，“你”只有 you。泰语里这两类词各有十几个，一句话选用的那一对代词，表明了谁在对谁说话。用第一人称写的客服话术，译出来常常是 ฉัน，这是个人在日常口语中的自称。公司自称 เรา 或自己的名字，称读者为 คุณ。ท่าน 再高一级，用于致政府机关的信函或正式公告。

第二行还换掉了表示收款的动词。泰语说退款“到账”（ยอดเงินจะเข้า），不说读者“看到”退款。这种修改，母语读者读一遍就能做出，检查清单永远发现不了。因此，后面的审校流程仍安排一位读者审读客户最常看到的字符串。

一个外来词，三种拼写#

泰语不断借用英语词，其中很多有不止一种拼写。泰国皇家学术院公布一种拼写，报纸和应用使用另一种，聊天中又用第三种。见过三种拼写的引擎会逐句挑选，结果一个产品的同一屏上出现两种拼写的 email。

每个产品选定一列并坚持使用。正式内容默认用皇家学术院拼写最稳妥，常见变体在面向消费者的应用里读起来更自然。无论选哪一列，都把选定的拼写放进 glossary，引擎就会照用。指南的外来词一节讲解 borrowed_words 字段，它决定尚无通行泰文写法的词是音译还是保留拉丁字母。

词典里有，但没人这么说#

仿译逐词翻译，产出的说法在泰国没有哪家服务会用。บำรุงรักษา 的意思是维护，指的是技师保养发动机。网站停机维护时用的是 ปิดปรับปรุง，字面意思是“关闭以改进”。两个说法词典里都有，在泰国的服务状态页上出现过的只有一个。

仿译集中出现在系统消息、错误提示和状态页里，因为这些字符串很短，没有给引擎任何上下文。在 context 里说明使用场景，比如状态页或推送通知，引擎就会从词典里的说法转向实际使用的说法。对于反复出现的短语，术语表条目也能起到同样作用。指南的翻译指令一节讲解了这些字段。

跨语言时改变的格式#

语言一换，好几条格式规则也跟着变。泰语没有复数形式，CLDR 复数规则只给它一个类别。书面泰语用空格结束句子，不用句号。泰文里很少用泰铢符号，数字后面写 บาท 一词。日期按佛历印出，即公历年份加 543，打印 2026 的收据沿用了原文的历法。

带有 one、few 和 other 分支的 ICU 消息，在泰语里只剩 other，保留英语分支的文件里装着泰国用户永远看不到的文本。{count} 这样的占位符必须连同花括号完整保留，标签也必须在原处闭合。发送富文本字符串时，把 format 设为 "html" 或 "markdown"，引擎就会保留其结构。指南的标记一节说明了哪些内容会被保留。

第一轮检查由引擎自己完成。每个交付的分段都会对照请求的要求检查，未通过检查的分段带有一个 review 成员，写明原因。审校一节列出了全部原因。标记从不导致请求被拒绝，译文无论如何都会交付。先读这些标记，再看其他内容。

• 清点占位符和标签。原文中的每个 {name}、%s 和标签都应在输出中出现一次，markup_changed 和 preserved_span_missing 这两个原因会指出哪些字符串里有占位符或标签移位或丢失。
• 比较长度。在一批译文中，泰语与英语的长度比例相当稳定，远远偏离这个比例的字符串，要么漏了一个分句，要么多了一个。为绑定到按钮或标题的字符串设置 max_length，并查看 too_long 原因。
• 搜索术语表中的词。原文出现某个术语的地方，译文都应出现选定的泰文形式，glossary_term_missing 原因会指出没有出现的分段。
• 仔细看 untranslated 原因。产品名称原样返回是对的。整句原样返回，则是引擎自己报告的失败。
• 用眼睛检查语气词。整批译文中，每个面向客户的陈述句都以同一个语气词结尾，ค่ะ 或 ครับ，涉及金钱的界面里没有任何字符串以 นะ 结尾。不论读者懂哪种文字，这些语气词都一眼可见。
• 检查数字、日期和货币。全部使用阿拉伯数字，บาท 写在金额之后，前面留一个空格，年份使用该界面其他地方所用的纪年。
• 把剩下的部分交给母语读者。客户最常看到的十个字符串、每个界面的顶部内容，以及所有涉及金钱或条款的字符串，每一批都要由母语读者审读。其余内容在第一批抽样审读，之后只读被标记的字符串。

对一批译文做三项统计，即使完全不懂泰语，也能看出它的语体。每项统计都是对输出文件运行的一行脚本，都能在请读者花一小时审读之前发现漂移。

• 统计每个陈述句的最后一个词。语体统一的一批译文，大多数陈述句都以同一个语气词结尾，ค่ะ 或 ครับ。如果一批译文分散在 ค่ะ、นะคะ、นะ 和完全不用语气词之间，那就是一个文件里装着三批译文。
• 统计代词。ฉัน、ผม、ดิฉัน、เรา、คุณ 和 ท่าน 各有用处，面向客户的一批译文应当只有 เรา 和 คุณ，几乎没有别的。客服译文中哪怕只出现一个 ฉัน，也值得打开看看。
• 统计术语表中每个外来词各种拼写的出现次数。选定的拼写应当是唯一出现的那一种，只出现一次的变体，就是术语表没有覆盖到的字符串。

上面第二行和第三行各指出一个需要打开查看的字符串。第一行说明这批译文整体一致，只有 61 个陈述句没有语气词，它们很可能是标签，应该单独统计。对上一批已批准的字符串做同样的统计，新的一批就有了可以对照的数字。

单个字符串语体出错，修改一处即可。整批语体出错，则是因为从没写过需求说明。下面这些字段把每项决定一次性定下来，带着它们发送的一批译文返回后，只要母语读者过一遍，几乎不用再做别的。

有些字符串，直接写比写需求说明更省钱。标题、标语和任何依赖文字游戏的内容，在泰语里和在英语里一样，都是文案写手的工作。这类字符串不到十条时，交给写手比向引擎描述清楚更省成本。量大的交给引擎，口吻交给写手。

各行之间的分界，在于一句错话的代价。客服话术里语气词生硬，代价是客户皱一下眉。条款里一个动词用错，代价是一场纠纷。每一行的审校流程都一样，读者承担的部分随错误的代价增加。

• 按界面分批。一个请求最多可携带 200 个分段，共用同一份上下文，来自同一界面的一批译文就会使用同一种语体。把每个字符串的键作为它的 id 发送，结果会按您文件中的键返回，不依赖顺序。批量请求一节说明了请求格式。
• 每个产品维护一份术语表，放进版本控制，每批都完整发送。只有在文本中出现的术语才会发送给引擎并计费，筛选是自动进行的。
• 先看审校标记，再看母语读者负责的部分，同一标记反复出现时就修改需求说明。每批都出现的标记，意味着缺了一个术语表条目或一条指令。
• 把通过审校的字符串作为下一批的 examples 发回。上一批中十组已批准的配对，比任何一段指令都更能保持口吻。
• 只翻译有变化的内容。为每个原文字符串计算哈希值，只把哈希值变了的字符串作为一批发送。需求说明没变，语体就保持稳定，母语读者需要审读的部分也一直很少。

• 阅读翻译指南了解每个字段，阅读 API 参考了解请求和响应格式。
• 阅读礼貌程度一文，在第一批之前选定语体。
• 阅读翻译费用一文，比较一批译文与翻译公司或自由译者的费用。
• 打开翻译工具，用同一界面的十个真实字符串试一试，再看它返回的标记。