稿子翻成波兰语之前先在英语站停了一趟,卸下去的那些东西没人清点

稿子翻成波兰语之前先在英语站停了一趟,卸下去的那些东西没人清点
张文保 更新 36 分钟阅读 2,789 阅读
本文目录
  1. 你的十几种语言,中间是不是都在英语这一站停过?
  2. 一家乐器配件站的波兰语页面,问题只在几个词尾上
  3. 差别不在译员,在链路上少了一样东西
  4. 中转这件事没人决定过,它是被采购价选出来的
  5. 先把自己的链路图画出来,这一步比什么都重要
  6. 英语这一站有几个格子,源语言的东西装不装得下?
  7. 换乘站只能转运它自己有格子装的东西
  8. 信息在这一站被合并,而合并是不可逆的
  9. 哪些维度会掉,可以列成一张清单
  10. 这张清单要按你自己的语言组合裁剪
  11. 下一站必须填上的那个值,是从哪儿来的?
  12. 目标语言不允许留空,这是问题的关键
  13. 第一个来源是目标语言的默认值
  14. 第二个来源是译员的个人习惯
  15. 第三个来源是机器翻译的统计倾向
  16. 补出来的句子在语法上完全合法
  17. 为什么所有质量关卡都不会报警?
  18. 术语检查只看词,不看词形
  19. 回译在这件事上帮的是倒忙
  20. 母语审校能查出来,但通常不会被这么用
  21. 唯一有效的检查是回到源语言比对
  22. 用户的查询也在换乘,这一侧同样有一次损失
  23. 跨语言检索会把查询翻过去再匹配
  24. 生成式回答那一侧的链路更长
  25. 提示词那一侧也在做同一件事
  26. 这一侧你控制不了,但可以用它反推该做什么
  27. 哪几对语言最不该走中转,怎么判?
  28. 判据只有一条:两端共有而英语没有的维度有几个
  29. 近亲语言之间本来可以直接对应
  30. 敬语系统是另一个必须直译的信号
  31. 承诺型内容不管什么语言组合都别走中转
  32. 不走中转要多花多少钱,这笔账怎么算?
  33. 先算差价,通常没有想象中那么吓人
  34. 不必全站直译,按页面类型分档就够
  35. 关键词表必须用源语言到目标语言直接做
  36. 已有的中转内容要不要全部重做
  37. 把换乘站换成别的语言,问题会不会小一点?
  38. 枢轴的选择标准不是它有多大
  39. 换枢轴的代价在供给这一侧
  40. 区域枢轴还能顺带解决另外两件事
  41. 什么情况下老老实实用英语就行
  42. 链路改短之后,怎么确认真的改善了?
  43. 动手之前先把基线存下来
  44. 最先会动的是这三个数
  45. 对照组要在同一语族里选
  46. 三个月看不出变化时该怀疑什么
  47. 这跟十份译文出自同一篇原文不是一回事
  48. 一个是横着看的多样性,一个是竖着看的保真度
  49. 两者的修法不一样
  50. 诊断顺序建议先查损失再查同源
  51. 哪些事不归这一层管
  52. 常见问题解答
  53. 怎么快速知道自己站上的某一门语言是不是走了中转?
  54. 用大模型做翻译,还存在中转损失吗?
  55. 不懂目标语言,怎么验收这几个维度选得对不对?
  56. 关键词表也走了中转,重建的成本有多大?
  57. 供应商说他们是母语译员,是不是就没有中转问题了?
  58. 中转损失和翻译质量差,怎么区分?
  59. 这件事该由谁牵头推动?
  60. 权威参考资料

摘要:多语言项目十有八九是这么跑的:内容先做成英语,再从英语分发到各语种。这条路省钱,代价藏在换乘那一站——源语言里有而英语里没有语法位置的东西会被整个卸下去,比如名词的性别、名词算不算活的、动词是自动还是他动、敬语的档位。到了目标语言这些格子又必须填上,而填的人手里已经没有原件,只能按默认值猜。猜出来的句子完全合法,术语对得上,回译也能通过,所有关卡一路放行。检索那一侧同样在换乘。本文讲清哪些维度会掉、补值从哪儿来、为什么关卡查不出来、哪几对语言最不该走中转,以及那笔钱该怎么花。

你的十几种语言,中间是不是都在英语这一站停过?

一家乐器配件站的波兰语页面,问题只在几个词尾上

有个客户做乐器配件,吉他弦、拾音器、谱架、管乐清洁套件这些。

总部在国内,内容先写中文,再翻成英语作为母版,然后从英语分发到十一种语言。

这条链路跑了三年,供应商稳定,交付准时,质量抽检的分数一直不错。

波兰语站上线两年之后,团队发现一个反常现象:品类页的表现明显低于同期的捷克语站。

两个市场规模接近,投入一样,内容是同一批,唯独波兰语这边始终起不来。

把波兰语页面的标题拉出来一批看,问题落在词尾上:几乎所有商品名都用的是词典原形,而波兰语用户在搜索框里打的形态跟原形不一样。这本身是屈折语的老问题,但真正让保哥停下来的是另一件事——同一批内容的捷克语版没有这个毛病。同一条链路、同一批译员管理流程,为什么两门同族语言的结果差这么多。

这个对照后来成了整件事最有力的证据。两个市场的其它条件几乎一致,内容出自同一批中文原稿,投放节奏也一样,唯一的差别就是中间那一站。拿这组对照去申请预算,比讲任何原理都管用,因为它把一个语言学问题变成了一个可以量化的差额。

差别不在译员,在链路上少了一样东西

追下去发现,捷克语那一侧的供应商是中文直接翻译的,波兰语走的是英语中转。

这个差别在项目文档里根本没写,它是采购时按报价选出来的自然结果。

中文原稿里,商品是被购买的对象,这一层关系在中文里靠语序和量词表达。

翻成英语之后,这层关系变成了一个宾语位置,词形上不留任何痕迹。

再翻成波兰语时,译员要为每个名词选一个格形态,而他手里只有英语那份没有痕迹的稿子。

波兰语的宾格还要看这个东西算不算活的,这条线画得很微妙,波兰语给笔记本电脑用的是买猫那个词尾那篇专门算过它在电商词表上的代价。链路里少的不是能力,是信息:英语那一站从来没有装过这个维度。

要说清楚的是,这不是译员水平的问题。那位波兰语译员的母语能力毫无问题,他产出的句子地道自然。他只是在为每个名词选形态的时候,手里没有任何依据可用,于是按最常见的那一种填。换任何一位同样优秀的译员,结果都一样。

中转这件事没人决定过,它是被采购价选出来的

问项目组谁定的这条链路,通常没人答得上来。

因为它不是一次决策,是十几次独立的供应商选择叠出来的结果。

每一次选择看的都是单价、交期和这家能不能接这个语种。

中文直译到小语种的译员稀缺、报价高、交期长,英语中转的供给则充足得多。

于是每一次都选了后者,而十几次同样的选择合起来变成了一条全站的架构。

这是这件事最典型的形态:它从来不出现在架构评审里,只出现在采购单里。等到有人开始查为什么某几门语言长期落后,链路图才被第一次画出来,而画完往往就能看懂一半。

这类由多次局部选择叠出来的架构,在多语言项目里不止这一处。语言标签怎么配、地址结构怎么定、模板由谁维护,很多都是这么长出来的。共同特征是每一次单看都合理,合起来却没人能解释为什么是现在这个样子。发现它们的唯一办法就是定期把全景画一次。

先把自己的链路图画出来,这一步比什么都重要

画法很简单,一行一门语言,写清楚这门语言的稿子是从哪份稿子翻过来的。

把中文直译的标一种颜色,英语中转的标另一种。

再加一列写清楚这一门是人工翻译、机器翻译加人工审校,还是纯机器。

两列一交叉,哪几门语言处在最脆弱的格子里立刻就看得出来。

这张图画完通常只要一个下午,而它能解释掉过去两年里好几个说不清楚的现象。

英语这一站有几个格子,源语言的东西装不装得下?

换乘站只能转运它自己有格子装的东西

把翻译链路想成货运换乘会很直观:每一站的分拣能力决定了什么能被转下去。

英语的语法系统里,名词不分性别,不变格,不区分算不算活的。

动词不分自动他动,没有敬语层级,也没有专门的形态表示这话是听来的。

这些东西在英语里不是被省略了,是压根没有对应的位置。

没有位置意味着译员在第一段翻译时,连保留它的动机都不存在。

这句话值得多说一句:如果英语只是习惯性省略,那还能靠规范要求译员补注;而它是结构性缺位,任何规范都无法要求一个人在没有格子的表格里填一个值。所以这不是流程能修的问题,是链路本身决定的。

顺带说一句,这个比喻里有一处不太贴切但值得点破:货运换乘至少会留下一张清点单,你知道少了什么。语言这一站连清单都没有,因为丢掉的东西在英语的世界观里根本不构成一个类目,没有人会为一个不存在的类目做记录。

信息在这一站被合并,而合并是不可逆的

源语言里两个不同的词,到英语可能变成同一个词。

日语里表示东西自己坏了和表示人把东西弄坏了,是两个不同的动词。

英语用同一个词兼两职,靠句子结构区分,词形上完全一样。

翻回去的时候,译员要从一个词里重新选出两个中的一个。

这两组词在用户那一侧对应完全不同的搜索场景,用户搜的是症状你写的是服务那篇拆过这条错位的商业后果。

合并的方向还有个规律:源语言里区分得越细的维度,在英语里被合并得越彻底。日语的自动他动是两个词合成一个,敬语的三四个档位合成一个中性表达,斯拉夫语的六七个格合成一个介词加名词。区分越细的地方,损失越大,这跟直觉正好相反。

哪些维度会掉,可以列成一张清单

名词的语法性别,英语没有,德语法语俄语波兰语都有。

名词的格,英语只在代词上留了残迹,斯拉夫语族和芬乌语族全都有。

生命度,英语完全没有,斯拉夫语族用它决定宾格形态。

敬语层级,英语靠词汇和句式表达,日语韩语是语法强制的。

动词的体、双数、定指标记、话题标记,同样一个都装不下。

清单之外还有一类不属于语法但同样会掉的东西:文化预设。中文原稿里默认读者知道的常识、默认的礼貌距离、默认的推荐语气,翻成英语时会被英语的默认值替换一次,再翻到目标语言时又被替换一次。这一类更难量化,但方向是一致的。

这张清单要按你自己的语言组合裁剪

通用清单没用,有用的是你那几门语言各自缺哪几格。

做法是把源语言和每一门目标语言的语法特征列出来,对照着找差集。

这件事不需要语言学训练,公开的语法特征标注体系已经把各语言标好了。

把两门语言的特征表并排放,英语那一列是空的而两端都有值的那几行,就是会掉的东西。

这张表做一次能用很多年,因为语言的语法特征不会变,变的只是你做哪些市场。

做这张表的时候有个省事的顺序:先列目标语言有而英语没有的维度,再看源语言在这些维度上有没有对应表达。两边都有的那几行才是真正的损失点。只有目标语言有的那些行不算损失,因为源语言里本来也没有,译员从任何链路都得靠推断。

下一站必须填上的那个值,是从哪儿来的?

目标语言不允许留空,这是问题的关键

如果目标语言允许不填,这件事就只是信息量减少,不至于出错。

但语法是强制的:你写一个德语名词就必须带冠词,写波兰语宾语就必须选一个格。

译员不能写一个没有性别的德语名词,就像不能写一个没有时态的英语动词。

于是缺失的信息在这一步被强制补全,而补全的依据不是原文。

这就是整条链路上最关键的一次转换:一次有损压缩,接着一次必须给出确定值的解压。

这也是它跟一般翻译损失最本质的区别。一般的翻译损失表现为信息变少,读者能感觉到句子干瘪。这一类损失表现为信息被替换成了一个确定的错值,读者感觉不到任何缺失,因为句子是完整的、具体的、语法正确的,只是那个值不是原文的意思。

第一个来源是目标语言的默认值

每门语言在拿不准的时候都有一套默认倾向。

性别拿不准就用阳性,数量拿不准就用单数,视角拿不准就用他动词。

敬语拿不准就用中性偏客气的档位,这在日语里意味着一整套词形。

默认值本身没错,问题在于它是统一的,而原文里那些值是各不相同的。

统一的默认值会让整批内容往同一个方向偏,偏移量不大但覆盖面是全站,这比零散的错误更难被发现。

默认值的方向还可以预测,这对排查很有用。性别默认阳性、数默认单数、视角默认施事、语气默认中性偏正式、体默认完成。知道方向之后,抽检时就不必随机抽,直接去查那些原文本来应该是非默认值的句子,命中率会高得多。

第二个来源是译员的个人习惯

同一批稿子换一个译员,补出来的值会不一样。

这在单篇上看不出来,在批量交付上就变成了前后不一致。

前后不一致比一直错更伤,因为一直错读起来像外国人写的,不一致读起来像几个人拼的。

品牌名的语法性别是这类不一致的重灾区,同一个站里出现三种冠词是常事。

这件事在品牌名进德语市场比怎么拼更早要定的那件事那篇里拆得最细,而中转链路会让它发生的概率成倍上升。

这类不一致有个很实用的检测办法:把同一个词在全站所有页面上的形态列出来做频次统计。真正统一的词只会出现一两种形态,出现三种以上的基本可以断定是不同批次不同译员补出来的。这个统计不需要懂那门语言,字符串比对就够。

第三个来源是机器翻译的统计倾向

链路里如果有机器翻译这一环,补值就交给了训练数据里的高频形式。

高频形式在多数情况下是对的,这正是它难查的原因。

它在职业名词、家庭角色、专业身份这几类词上偏得最明显。

低资源语言上这种偏移更大,因为可用语料本来就少。

机器翻译直接发布的整体风险在机器翻译发上线省下的那道审校,最后是拿收录和排名分期还的那篇里列过,中转链路相当于把这份风险乘以链路的段数。

还有一层要注意:链路里的机器翻译经常是隐性的。供应商用工具做预翻译再人工润色,这在行业里是常规操作,通常不会写进交付说明。润色的人只改读起来别扭的地方,而默认值补出来的句子读着不别扭,于是原样保留。

补出来的句子在语法上完全合法

这一点必须单独说,因为它决定了所有检查工具的表现。

猜错的性别、猜错的格、猜错的动词,产出的都是合乎语法的句子。

拼写检查通过,语法检查通过,可读性评分甚至可能更高。

只有母语用户读到具体那一句时才会觉得别扭,而他不会来告诉你。

更常见的情况是他连别扭都感觉不到,只是在搜索结果里没找到你,然后去了别家。

这条性质决定了一件事:任何以合法性为判据的自动检查都拦不住它,加多少道工具都没用。要拦住它,判据必须涉及原文,也就是必须有人拿着源语言的稿子逐句对。这是整件事里唯一一个不能自动化的环节,也是为什么它在流程上一直是个空白。

为什么所有质量关卡都不会报警?

术语检查只看词,不看词形

术语库比对的是词条是否被正确使用,比对的对象是词干或者原形。

形态变化和语法特征不在它的检查范围内,它也没有能力检查。

于是一份每个术语都用对、每个词形都选错的稿子,术语检查是满分。

这跟锚文本报告里精确匹配那一栏的数字是假的属于同一种失真。

口径要从字符串换成词干还是换成别的,屈折语站的锚文本报告精确匹配那一栏是假的那篇给过一套换法。

术语库还有一个更隐蔽的副作用:它会给人一种已经检查过了的踏实感。看到术语一致性报告是满分,很少有人会追问这份报告到底检查了什么。报告的覆盖范围写在工具文档里,但没人会为一份满分的报告去翻文档。

回译在这件事上帮的是倒忙

回译是把译文再翻回源语言,看意思有没有跑偏,很多团队拿它当兜底。

但中转损失恰好是往返对称的:去程丢掉的维度,回程同样不需要它。

波兰语译文里的性别猜错了,翻回英语时性别本来就不出现,回译结果完美一致。

于是回译不但查不出来,还会给出一个一切正常的强信号。

母语审校的验收该看哪几层,一句读着自然不能当成验收通过的判据那篇列过一份清单,回译的能力边界在那篇里已经点过,这里是它失效得最彻底的一个场景。

回译还有一个更麻烦的性质:它给出的是强阳性信号。如果它只是查不出来,最多是漏检;而它实际给出的是一切正常的结论,这会让团队主动关闭其它检查渠道。一个失效的检查工具比没有工具更危险,因为它占据了本该由别的办法填补的位置。

母语审校能查出来,但通常不会被这么用

母语审校当然读得出别扭,问题在于他被交代的任务是什么。

大多数审校简报写的是检查通顺度和术语一致性,没写检查语法特征选得对不对。

审校看到一个合法的句子,默认它是对的,除非读起来明显不自然。

而默认值补出来的句子恰恰读起来相当自然,它只是跟原意不一致。

要让审校查出来,必须给他原文,而中转链路的审校手里通常只有英语版。

改法很简单:在审校简报里加一句,要求逐项确认名词的格与性别、动词的视角、承诺句的强度是否与原文一致。加这一句的成本是零,而它把审校从通顺度检查变成了一致性检查,这两件事的产出完全不同。

唯一有效的检查是回到源语言比对

把中文原稿和波兰语译文并排放,请一个懂两头的人抽检十句。

抽检的问题要具体:这句里的这个名词,原文说的是活的还是不是活的。

问得越具体,不懂那门语言的人也能组织这次检查。

十句抽检就能判断这条链路有没有系统性偏移,因为偏移是全局的不是零散的。

成本是半天,而这半天买到的是这条链路值不值得继续用的答案。

抽检的句子怎么挑也有讲究。优先挑三类:带商品名的标题、含承诺的政策句、以及常见问题里的问答对。这三类的共同点是短、密度高、而且直接影响检索和转化。挑长段落做抽检看起来更认真,实际上信息密度低,性价比反而差。

用户的查询也在换乘,这一侧同样有一次损失

跨语言检索会把查询翻过去再匹配

搜索这一侧近些年多了一条路径:本地语言的查询被翻译成其它语言去检索。

搜索引擎公开说明过它会为部分查询提供翻译后的结果,这条路径是明示的。

翻译查询和翻译内容的损失机制完全一样,只是方向反过来。

用户打的那个带格尾的波兰语词,翻成英语之后格尾消失了。

再拿英语去匹配英语内容,能匹配上的正好是那些没有格的表达。

这条路径对你的实际影响取决于本地语言内容的供给量。本地内容充足的市场,引擎没有理由去翻译别的语言给用户看;本地内容稀缺的市场,翻译路径的占比就高。所以它同时是一个市场成熟度的指标:翻译结果出现得越多,说明这个语种的原生内容缺口越大。

生成式回答那一侧的链路更长

用小语种提问,模型可能用英语检索资料,再用小语种把答案写出来。

这条链路里有两次换乘,一次在检索前,一次在生成时。

答案读起来很流畅,因为生成那一步的语言能力确实不错。

但它引用的来源是哪门语言,跟它回答用的语言不是一回事。

这两个字段该分开记,回答用的是你的语言引用的来源却是一水儿的英文页面那篇给过实测的做法。

这条链路上还有一层容易被忽略:模型给出的答案可能是从英语资料翻译过来的,而那份英语资料本身可能又是从别的语言翻过去的。链条一长,最初那个语言的语法信息早就不知道在哪一站掉光了,而最终读者看到的是一段流畅的本地语言文字。

提示词那一侧也在做同一件事

做跨语言监控的时候,很多团队把同一句提示词翻成十几种语言去问。

翻译提示词等于在监控环节又引入了一次同样的损失。

问出来的差异有一部分来自模型,有一部分来自你自己的翻译。

把这两部分混在一起,得到的结论会指向错误的动作。

提示词的翻译等价性问题在品牌名在俄语里是西里尔在日语里是片假名,你那个数提及次数的脚本一个都认不出来那篇里讨论过,做监控的人要先把自己这一侧的损失扣掉。

解决办法不是不翻译提示词,而是把翻译这一步固定下来并留档。同一句提示词的各语言版本一次定稿,之后每次监控都用同一批,这样至少保证了历次结果之间可比。变的是模型,不变的是你的问法,这是做任何纵向监控的前提。

这一侧你控制不了,但可以用它反推该做什么

检索侧的换乘不是你能改的,它发生在别人的系统里。

能做的是让自己的页面在两条路径上都站得住。

一条是本地语言的直接匹配,需要页面上真的写着用户打的那些形态。

另一条是翻译后的匹配,需要页面的语义结构清晰、事实明确。

两条路都要走通,而第一条只有本地语言原生内容能做到,翻译过来的内容天然吃亏。

还有一个可操作的推论:越是本地语言原生内容稀缺的市场,你做原生内容的相对收益越高。因为在那种市场里,检索侧不得不依赖翻译路径,而你是少数几个能提供直接匹配的来源之一。这跟通常按市场规模排优先级的思路正好互补。

哪几对语言最不该走中转,怎么判?

判据只有一条:两端共有而英语没有的维度有几个

源语言和目标语言都有某个语法维度,而英语没有,这个维度就会白白损失。

两端共有的这类维度越多,中转的代价越大。

中文到波兰语看起来差得很远,但中文的很多信息本来就要靠上下文推断,损失反而没那么集中。

俄语到波兰语则不一样,两门语言共享性别、格、生命度、体四个维度,全部要在英语那一站被丢掉。

越近的两门语言走中转越亏,这是个反直觉但很硬的结论。

这条判据还能反过来用在供应商谈判上。当你能说清楚这两门语言之间有四个维度会在中转时损失,直译的溢价就有了具体的依据,而不再是一句质量更好。采购最怕的就是没有量化依据的质量论证,而这件事恰好可以数出来。

近亲语言之间本来可以直接对应

俄语的六个格和波兰语的七个格之间有相当稳定的对应关系。

直接翻译的译员可以逐格映射,几乎不需要判断。

走英语中转之后,这套现成的对应关系被彻底浪费掉,每一格都要重猜一次。

捷克语和斯洛伐克语之间的复用判据在捷克语和斯洛伐克语分家之后关键词就再没合并回同一套那篇里算过,那套判据的前提正是两门语言可以直接对照。

把近亲语言拆进两条各自经过英语的链路,等于亲手把这份天然的红利丢掉。

近亲语言之间还有一层红利同样被中转浪费掉:术语和固定搭配可以大面积复用,只需要按规律做形态调整。走中转之后,两门语言各自从英语出发,产出的术语选择常常不一致,于是本来能共享的一套词表分裂成了两套,维护成本翻倍。

敬语系统是另一个必须直译的信号

日语和韩语都有语法化的敬语,英语没有对应结构。

从日语翻到韩语,敬语档位可以近似对应,中转之后只能凭默认值重建。

敬语档位选错不影响排名但明显影响转化,这一层在日语页面写得越客气跟用户搜的那串字差得越远那篇里量化过。

东亚这几门语言之间的内容如果要互相复用,直译几乎是唯一选项。

好消息是这几门语言之间的直译译员供给远比欧洲小语种之间充足。

东亚这几门语言之间还有一个额外的复用点是汉字词。同一个概念在中日韩里常有共享的汉字词根,直译时这层对应关系是现成的,走英语中转之后完全消失,译员会从英语的通用词重新选一个本地说法,结果往往是一个更口语但检索量更低的词。

承诺型内容不管什么语言组合都别走中转

退货政策、保修条款、合规声明这几类,句子里的强度是有法律含义的。

情态词的强度刻度在各语言之间本来就不一致,多过一道手只会更偏。

承诺被译软这件事在退货政策那句承诺译成日语之后字面写出来是不这么做就不行那篇里拆过机制。

常见问题区里的否定问句同样危险,答反了一个字都挑不出错。

那类问答的极性验收清单在那句日语回答一个错都挑不出来只是把能退货答成了不能退那篇里给过,走中转的链路要把这份清单的执行频率提高一档。

这几类内容还有个共同特点:它们的字数在全站占比很低,通常不到百分之几。把它们单独抽出来走直译,成本增量几乎可以忽略,而它们恰好是法律风险和转化影响最集中的那部分。这是整篇里投入产出比最高的一个建议。

不走中转要多花多少钱,这笔账怎么算?

先算差价,通常没有想象中那么吓人

中文直译到小语种的单价高于英语中转,这是事实。

但差价要放在整页成本里看,翻译费在一个页面的全生命周期成本里占比不高。

把设计、开发、图片、维护摊进去之后,翻译差价往往只是个位数百分比。

而它影响的是这批内容能不能被搜到,那是零和一的差别。

用这个口径去谈预算,比单纯说直译质量更好要有说服力得多。

算这笔账的时候记得把返工成本算进去。走中转的内容将来一旦要修,修的是已经上线的页面,要重新走审校、重新上线、重新等收录,成本远高于第一次就做对。把返工概率乘进去之后,直译的差价往往在账面上直接就抹平了。

不必全站直译,按页面类型分档就够

转化型页面和承诺型页面直译,说明型和辅助型页面可以接受中转。

品类页、商品页、退货政策、常见问题划进第一档。

博客、资讯、帮助文档划进第二档。

这样直译的量通常只占全站的两三成,成本立刻降到可谈的范围。

分档这件事跟机器翻译的四档处理策略是同一套思路,只是分档依据从质量风险换成了信息损失。

分档还有一个执行上的好处:它让这件事变成一条可以写进流程的规则,而不是每次都要讨论的判断题。规则写清楚哪几类页面必须直译,采购下单时按类目走,不需要每次都请一个懂语言学的人来拍板。

关键词表必须用源语言到目标语言直接做

就算正文接受中转,关键词表这一件事绝对不能中转。

词表走中转的后果是整张表都是词典原形,因为英语那一侧没有形态。

而用户搜的恰恰是各种形态,这正是本文开头那个波兰语站的病根。

词表要用目标语言的真实数据建,工具没数据的时候有一套土办法可用,工具返回的那个零是数据缺口不是需求缺口那篇里写了三条。

这是整篇里最值得先做的一件事:词表的重建成本远低于正文重译,而它带来的变化最直接。

更准确地说,词表根本不该走翻译流程,它该走调研流程。翻译流程的输入是一份稿子,调研流程的输入是目标市场的真实数据。这两件事被混在一起,是很多多语言站词表质量差的根源,而中转链路只是把这个根源暴露得更明显。

顺带一提,用目标语言直接做词表还会捞出一批走中转永远捞不到的词,其中有一类比较特殊:查得到量、也知道用户在搜、页面上却不能写,那个词每月几万次搜索却印在别人的商标证上那篇讲的就是这一类怎么标怎么用。

已有的中转内容要不要全部重做

不要,按流量和转化排序,先重做头部那批。

重做的时候优先修标题、商品名、常见问题这几处,正文可以放在后面。

这几处的字数少、杠杆大,改动量跟收益完全不成比例。

剩下的长尾内容可以维持现状,等到下一次改版再一起处理。

全站重译听起来彻底,实际上会把预算耗在收益最低的地方,还容易半途而废。

重做的时候有个顺序上的技巧:先改词表和标题,观察一到两个月,再决定要不要动正文。多数情况下前者带来的变化已经能满足预期,正文重译可以无限期推迟。这个顺序还能保护预算,因为它先花小钱验证了方向对不对。

把换乘站换成别的语言,问题会不会小一点?

枢轴的选择标准不是它有多大

很多人默认英语当枢轴是因为它资源最多,这个理由本身没错。

但从信息损失的角度看,枢轴该选的是跟两端共有维度最多的那门语言。

做罗曼语族的多语言站,用西班牙语当枢轴比英语损失小,因为性别和数至少保住了。

做斯拉夫语族的站,用俄语或波兰语当枢轴能同时保住性别、格和生命度。

这条判据很少被写进本地化方案,因为方案通常是按供应链而不是按语法写的。

这条标准还能解释一个经常被误解的现象:为什么有时候从中文直接翻到某些小语种,质量反而比从英语中转好,尽管中文和那门语言差得更远。因为距离远近不重要,重要的是中间那一站有没有把两端共有的维度丢掉。

换枢轴的代价在供给这一侧

用西班牙语当枢轴的前提是你能找到西语到各小语种的译员。

这个供给确实比英语差,但在罗曼语族内部并没有差到不可行。

斯拉夫语族内部同理,俄语到波兰语、捷克语的译员供给相当充足。

所以这件事在语族内部是可行的,跨语族才真正回到英语。

换句话说,正确的架构不是一个全球枢轴,而是几个按语族分的区域枢轴。

区域枢轴还有一个现实的落地方式:不必换供应商,只需要换派单的源文件。很多本地化服务商本身就有多语种能力,你把西班牙语版而不是英语版作为源稿发过去,链路就变了。这个改动小到可以先在一两门语言上试。

区域枢轴还能顺带解决另外两件事

同一语族内的市场,用词习惯和文化预设也更接近。

近亲语言之间的假朋友和意图漂移,用同族枢轴处理时更容易被发现。

两个市场的关键词表可以一字不差而落地页要拆开,这类判断在同族之间才做得准,关键词表可以一字不差落地页却得拆成两种那篇讲的正是这层。

审校资源也能共享,一个懂两门近亲语言的人可以同时看两个市场的稿子。

所以区域枢轴不只是省下了信息损失,还顺带把审校成本降了一档。

要注意的是同族枢轴也有它的风险:假朋友在近亲语言之间最密集,译员容易因为两门语言长得像而放松警惕,直接照搬那些看着一样意思却不同的词。所以换成区域枢轴之后,审校的重点也要跟着换,从形态一致性转到假朋友核查。

什么情况下老老实实用英语就行

两端本来就没有共同的语法维度时,中转的损失确实很小。

比如中文到印尼语,两门语言都不变格不分性别,英语这一站没什么可丢的。

再比如中文到越南语、泰语,形态都很轻,损失集中在别处而不在语法上。

这类组合完全可以走中转,把省下来的预算投到真正会掉东西的那几门语言上。

东南亚三国在语言层的差异集中在别的地方,越南泰国印尼被放进同一张预算表语言层三家没有一处能共用那篇拆过它们各自的成本结构。

这一档语言还有一个附带的判断:既然中转损失小,那这几门语言的问题多半在别的层面上,比如分词、书写系统、本地平台生态。把精力放对地方,比在链路上做无用功重要得多。诊断的价值一半在于确认哪些方向不用查。

链路改短之后,怎么确认真的改善了?

动手之前先把基线存下来

这类改动的效果是渐进的,没有基线就永远说不清楚它有没有用。

要存的第一份是这几门语言的品类页表现,按语言分开,别看全站汇总。

第二份是词表本身,把改之前那一版完整留档,将来要靠它算覆盖率的变化。

第三份是一批代表性页面的原文快照,二三十个页面就够,用来做前后对照。

三份材料加起来半天能存完,而没存的团队通常在三个月后开始互相说服对方效果存在与否。

最先会动的是这三个数

第一个是站内搜索的零结果率,词表改对之后它掉得最快,通常几周就能看出来。

第二个是长尾查询的覆盖数量,也就是有多少个不同的查询词能给你带来访问。

第三个才是流量本身,它动得最慢,因为页面和查询之间的关联需要时间重建。

按这个顺序看数,能避免在最该有耐心的时候下错结论。

这三个数还有一个共同的好处:它们都不依赖排名工具,站内日志和站长后台就有,小语种上尤其可靠,因为第三方工具在这些语言上的数据本来就薄。

对照组要在同一语族里选

最理想的对照是同语族的两门语言,一门改链路一门不改。

这类对照能把市场因素、季节因素、算法波动全部抵消掉。

本文开头那家乐器配件站的波兰语和捷克语就是天然的一对,只是当时没人打算拿它做实验。

找不到同语族对照的时候,退一步用同一门语言的不同页面类型做对照也行。

要避免的是拿改动前后的全站数据直接比,那里面混进来的变量太多,得出的结论既不可信也说服不了任何人。

三个月看不出变化时该怀疑什么

先怀疑改动有没有真的落地,尤其是标题和商品名这些由模板生成的位置。

再怀疑词表改完之后有没有同步到筛选器、面包屑和内链锚文本。

然后才怀疑这门语言的问题不在链路上,可能是内容量本身不够。

还有一种情况是这个市场的搜索需求本来就小,语言层修得再好也撑不起预期。

把这几个怀疑按顺序排一遍,通常在第二条就能找到答案,因为词表下游的那几处几乎总有一处没跟上。

这跟十份译文出自同一篇原文不是一回事

一个是横着看的多样性,一个是竖着看的保真度

十种语言的内容都翻自同一篇英文,问题是这十份资料在信息上等于一份。

这件事伤的是引用价值:谁把它们并排放,都会发现口径高度一致却没有独立来源。

本文讲的是另一件事:每一份译文自己内部就有信息损失。

前者是横向的,问的是你有几个独立信源;后者是纵向的,问的是这一份还剩多少原意。

两件事可以同时发生,而且经常同时发生,因为它们出自同一条链路。

两者还有一个共同的成因值得点出来:都是为了省钱而做的架构选择。用一份英文稿分发到十几种语言,同时省下了内容生产成本和翻译成本,代价分别落在多样性和保真度上。这两笔代价当年都没被记账,多年之后才以流量的形式被追讨。

两者的修法不一样

同源问题的解法是加原生内容,让至少一部分市场有本地采写的资料。

损失问题的解法是缩短链路,让翻译从源语言直接到目标语言。

前者是加法,后者是改路径,预算科目都不一样。

同源那一层的判断办法在十种语言里十份口径一致的资料回头一查是同一篇英文翻出来的那篇里有完整的自查流程。

把两件事分开谈,跟管理层要资源的时候才说得清楚要的是什么。

预算科目不同这件事在实际推进中很关键。缩短链路的钱出在本地化预算里,通常由项目经理就能决定;新增原生内容的钱要走内容生产预算,往往需要更高层级的批准。所以前者能立刻开始做,后者要排进下一个预算周期,这也决定了两件事的先后。

诊断顺序建议先查损失再查同源

损失问题更便宜也更快见效,改词表和改标题就能出结果。

同源问题要新增内容生产,周期以季度计。

先做见效快的那件事,也能给后面那件事争取到预算。

而且损失修完之后,同源问题的严重程度会重新评估一遍,有些市场可能没那么急。

顺序反过来的团队,通常在原生内容还没产出的时候就把耐心用完了。

还有一个顺带的好处:修完损失之后,团队对这几门语言的实际潜力会有更准确的判断。有些市场在语言层修好之后表现直接上来了,说明它本来就有需求;有些修完仍然不动,那才说明问题在需求侧,值得重新考虑要不要继续投。

哪些事不归这一层管

供应商怎么招、怎么议价、怎么做质量考核,那是采购和供应商管理。

内容本身写得好不好、选题对不对,那是内容策略。

页面模板、地址结构、语言标签怎么配,那是站点架构层的事。

这一篇只回答一件事:从源语言到目标语言这条路上,有哪些语法信息掉在了中间那一站。

把这件事单独拎出来,最大的好处是它有明确的判据和明确的修法,不像质量这个词那样人人都能有一套说法。

常见问题解答

怎么快速知道自己站上的某一门语言是不是走了中转?

问三个人通常就够:内容负责人、本地化项目经理、以及实际下单给供应商的那个人。第三个人给的答案最准,因为采购单上写着源语言字段。如果三个人的答案不一致,那本身就是个结论——链路没人在管。还有一个不用问人的办法:调出这门语言最近的一批交付文件,看附带的项目文件里源语言写的是什么。

更硬的证据是拿译文本身找痕迹。中转过的稿子有几个常见特征:句子长度分布跟英语高度接近、被动语态比例偏高、复合句结构像英语而不像目标语言。这几项都能用简单的统计脚本跑出来,跟一批本地原生内容做对照,差异往往一眼可见。

用大模型做翻译,还存在中转损失吗?

存在,但形态变了。模型不像人工链路那样必须先产出一份完整的英语稿再翻过去,所以那种硬性的中间落地少了。但训练数据以英语为主这件事没变,模型在处理低资源语言时的内部表示仍然高度依赖英语,学术界很早就在讨论这种以英语为中心的结构会带来什么。实际表现是:源语言里那些英语没有的维度,模型同样容易按目标语言的高频默认值填。

可控的地方在于你能把原文直接给它,不必先经过一份英语稿。所以用模型翻译时最重要的操作是别偷懒走两步:直接从源语言到目标语言,并且在提示里明确交代那几个关键维度的取值,比如这个名词指的是活物、这句话的动作是自己发生的。把这些交代清楚,等于人工替它补上了那个缺失的格子。

不懂目标语言,怎么验收这几个维度选得对不对?

把验收问题设计成是非题,不懂那门语言也能组织。比如挑十个商品名,问审校这个词在这句里用的是不是宾格形态;挑五句退货承诺,问这句的强度是必须还是建议;挑三段常见问题,问这个回答是肯定还是否定。问题越具体,答案越不依赖你的语言能力。

关键是把原文一起给他,而且要给源语言原文不是英语版。中转链路的审校通常只拿到英语版,这一步不改,验收就永远只是在验英语到目标语言这一段,前面那一段的损失一直在盲区里。改动成本几乎为零,只是在派单时多附一个文件。

关键词表也走了中转,重建的成本有多大?

比想象的小。词表重建的主要工作量在数据获取而不在翻译,而数据获取本来就要用目标语言做。真正需要的是找一个母语者把核心品类词的常用形态过一遍,通常一两天能覆盖几百条核心词。相比之下正文重译是按字数计费的,量级完全不同。

顺序上建议先重建词表再动内容,因为词表是下游一切的输入:标题模板、面包屑、筛选器命名、内链锚文本,全都从它继承。词表不改就重译正文,等于拿新译文去凑一套旧的错词,返工两次。这个先后关系在多语言项目里几乎是通用的,只是走中转链路的站受影响更大。

供应商说他们是母语译员,是不是就没有中转问题了?

母语译员说的是译入语是他的母语,这跟他手里拿的是哪一份稿子是两件事。一个波兰语母语译员完全可能拿着英语稿在工作,这在行业里非常普遍,而且并不算偷工减料,因为项目就是这么派的。要确认的问题应该问得更直接:这份稿子的源语言是什么,译员懂不懂源语言。

问的时候要注意用词,问是不是母语译员得到的答案永远是肯定的。有效的问法是要求在项目文件里写明源语言字段,并要求译员具备源语言到目标语言的语言对资质。把这一条写进采购要求,比事后抽检有效得多,成本也只是合同里的一句话。

中转损失和翻译质量差,怎么区分?

判断标准是错误的形态。质量差表现为零散的、不成规律的错误:这里用词不当,那里句子不通,读起来能明显感觉到粗糙。中转损失表现为系统性的、高度一致的偏移:全站的名词都用同一种默认形态,全站的承诺都比原文软一档,全站的动词都站在同一个视角。

所以判别办法是看错误分布而不是看错误严重程度。抽二十个页面,如果同一类问题在二十个页面上以同样的方式出现,那不是译员水平问题,是链路问题。换译员解决不了链路问题,这也是很多团队换了几轮供应商仍然没改善的原因。

这件事该由谁牵头推动?

应该是同时看得到内容和数据的那个人,通常是负责多语言优化的那一位。内容团队看得到质量但看不到搜索表现,采购看得到链路但不知道它的后果,本地化项目经理夹在中间通常只对交期和预算负责。只有把链路图、语法特征差集和各语言的搜索表现放在同一张桌上,这件事才成立。

推动时最有效的材料不是原理讲解,而是一组对照数据:走直译的那几门语言和走中转的那几门语言,在同类页面上的表现差多少。这组数据你站上很可能已经有了,只是从来没按这个维度拆过。拆一次的成本是一个下午,而它通常比任何论证都有说服力。

分享到
标签
版权声明

本文标题:《稿子翻成波兰语之前先在英语站停了一趟,卸下去的那些东西没人清点》

本文链接:https://zhangwenbao.com/minor-language-pivot-english-relay-grammar-loss.html

版权声明:本文原创,转载与引用请注明作者与原文链接。许可协议: CC BY 4.0

继续阅读
发表评论
分享到微信 或在下方手动填写
支持 Ctrl + Enter 提交