翻译的瓶颈不在能不能翻出来。机器翻译几秒钟就能处理完两百个产品标题，真正决定成败的是三件事：翻完之后谁来改、商品数据变了译文跟不跟得上、这套东西给前台加了多少负担。按这三个问题去比较方案，比翻插件商店的功能列表和评分有用得多。
第一件事：内容能改到什么颗粒度
先问自己有多少条文案属于错一个词就影响转化的。尺码、材质成分、容量单位、保修年限、法规用语，这几类是典型。机翻在这类词上出错的概率明显更高，而错了之后买家直接来问客服，或者干脆不下单。
没有一条适合所有店铺（光算 · 示意图）
所以第一个要确认的能力是逐字段人工覆盖。能不能只改某一个产品的标题译文、某一个集合的描述译文，还是只能整批重新翻一遍。只有整批重翻的方案，用起来会很快失去控制：改一处就要重跑一次，跑完还得从头校验一遍有没有新的错。
第二个能力是批量导入导出。SKU 上到几百上千，靠后台一条条点不现实，需要能把多语言字段导出成表格、改完再导回去。这个能力在试用阶段就要确认，等到上线之后发现没有，返工成本很高。
抽查的方式也值得定下来。抽样十到二十条译文，找一个母语者只做一件事：挑错。重点看四类东西，数字与单位、否定句、法规与合规用语、品牌名和型号。机翻在否定句和单位上翻车的概率最高，而这两类错了会直接变成售后问题，不是排版难看那么轻。抽查别只看首页，首页文案通常被人手动改过，代表性最差，抽产品描述和集合说明更有用。
平台侧能覆盖的范围也要实际试。Shopify 的 Markets 用 customizations 覆盖店铺默认设置，可覆盖项包括币种、语言、域名、税费和主题内容，官方的 Markets 帮助文档是这么列的；但具体到哪些字段能被翻译、哪些只能改主题代码，文档没有逐字段清单，得在你的后台里真的点一遍才算数。
第二件事：原文改了，译文跟不跟得上
先确定先做哪个语言，这一步不该按哪个好翻来排序。判断依据是需求信号：Search Console 里已经有某个国家带来的曝光和点击，而用户看到的是英文页，那个语言就值得优先做。反过来，一个国内没人搜、也没打算投放的市场，翻得再好也不会自己长出流量，它只会在每次商品更新时消耗你的维护时间。
原文和译文是两套记录，这一点决定了所有同步方案都有缝。产品改名、调整单位、改价格描述、下架合并，这些动作在单语言站上只是编辑，在多语言站上会留下一批过期的译文。更麻烦的是过期不容易被发现，因为页面看起来是正常的，只是说的和原文不一样了。
可行的做法是把同步做成有清单的动作，而不是指望自动更新。
- 定一份必须同步的字段清单：产品标题、描述里的关键句、SEO 标题与描述、尺码表。其余文案允许滞后。
- 每次批量改完商品，把多语言字段导出来和原文对照一遍，找没更新的条目。这一步花的时间比想象中少，比事后翻查便宜太多。
- 下架或合并产品时顺手清理对应的翻译条目，别留下指向空资源的字符串；应用层面的残留问题可以看 卸载插件后的残留清理 里的方法，思路是一样的。
- 每次主题改版后重抽一次源码，确认语言切换链接、hreflang 和 canonical 没被改坏，这部分对齐规则见 Markets 与 hreflang 的 URL 对齐。
第三件事：前台加了多少东西
还差一件容易被跳过的事：记录。译文是谁改的、改的是哪一版、什么时候改的，如果没有任何记录，几个月之后没人说得清哪一条译文是当前有效的。一份简单的表格就够，日期、页面、字段、改动人，写起来不到一分钟，能省掉后面反复对照的时间。
先看能不能改，再看快不快（光算 · 示意图）
翻译内容可以在服务端随 HTML 一起输出，也可以由前台脚本把文本替换掉。后者的体感问题很明显：页面先显示原文，过一会儿变成译文，看起来像是加载了两遍。这种闪烁与视觉稳定性有关，装完之后要在真实设备上看一遍，不能只看桌面浏览器。
判断方式很土但有效：同一条产品页，在预览环境里对比装前装后的第三方脚本数量，再跑一次性能报告。具体差多少必须用自己量到的数字，别人的对比测试和你的主题、脚本组合不一定一样。第三方脚本的取舍原则可以对照 第三方脚本审计 那篇，翻译方案只是其中一类。
按这个顺序选，价格放最后
- 拿十条最难的文案试译，覆盖材质、尺码、法规词，看机翻初稿要改多少。改一半以上的方案，本质上还是要靠人工，评估标准就要换。
- 确认能逐字段人工编辑，并且能批量导入导出。
- 在预览主题上装一遍，记录脚本数量与页面性能的变化，并检查有没有语言闪烁。
- 做一次卸载测试：停用之后前台是否回退原文，有没有留下孤立的字符串或模板片段。
- 最后看价格与计费口径，按月订阅还是按用量计费，以及多语言增加时费用怎么变。
- 拿人工成本对照一下。只有一到两个语言、SKU 数量有限、又有人能写目标语言的情况下，直接在后台把关键字段译完，总成本经常低于常年订阅，改起来也更快。
机翻在搜索里的现实边界
Google 不用 hreflang 判断页面语言，也不用 HTML 的 lang 属性，它用自己的算法判断，这条写在 本地化版本文档 里。所以机翻页面照样会被识别成对应语言，这一点不影响。但被识别不等于有竞争力：同语言市场里的本地站，用词、单位、售后表述都是本地写法，机翻文本很难覆盖这一层。这是经验判断，不是平台规则，别把它当成 Google 的评分标准去引用。
Google 的文档里没有写机翻内容必然降权这类的规则，反过来也没有任何地方承诺翻译完就能拿到该语言市场的排名。排名取决于内容质量、外链和竞争程度，翻译只是入场券。如果你的目标是英语市场，先把英文站的内容做厚通常比铺第三种语言更划算，这类内容工程是我们做 英文 SEO 文章 的范围。
真正有明确规则的是半翻译。只把模板翻译了、正文还是原文，Google 的口径 是这类页面算重复内容。用这种方式凑出五个语言版本，等于给 Google 送五份重复页，占抓取、占索引，还稀释你自己的效果统计。宁可不发布那个语言版本，也不要拿半翻译页面去占位。语言版本之间该怎么处理 canonical，写在 多语言重复内容与 canonical 的处理顺序 里。
翻译之外还有三件事要做
站外的文案也要算进去：订单确认邮件、发货通知、退换货说明、发票抬头用语。这些内容不在主题里，翻译方案能不能覆盖到它们，各家情况不一样，得单独确认。确认之前可以先人工维护一份多语言模板，数量有限，做起来不快但不会出错。落地页之外的客服话术同理，用户看到一封英文的退款通知，语言切换做得再顺也会掉信任。
SEO 字段要跟着翻。产品、集合、博客的 SEO 标题和描述在后台每个页面都能单独改，Shopify 的帮助文档里对应的位置是编辑页面时的搜索预览区域。译文只改正文、不改 SEO 字段，是很多站点的通病，等于把这个页面在本地语言里的标题和摘要留给了机器写。
内链要跟着翻。译文页里的内链如果还指着英文页，读者读完就被送走了；更重要的是，语言版本之间缺少互相指向的入口，抓取器也不好判断它们的关系。这一条比翻译本身更容易被忘。
内容要按市场写，不只是翻译。同一个产品在德国的关注点和在美国不一样，认证、保修、包装、尺寸习惯都有差别，这部分属于分市场的内容规划，可以见 分市场内容规划 的思路。多语言架构放在哪个平台上更合适，是另一个层面的取舍，平台差异参考 Shopify 与 WordPress 在 SEO 上的差别。
不能承诺的五件事
- 不能承诺翻译后拿到该语言市场的排名。翻译是必要条件，不是充分条件。
- 不能承诺收录时间。按 Shopify 的 sitemap 文档，抓取和索引需要时间，Google 不承诺需要多久。
- 不能承诺各个方案的具体性能差异。任何数字都要在自己主题上量，别人的结论只说明存在差别。
- 不能凭介绍页推断功能边界。某个字段能不能翻译、某个字段改了要不要重跑全量，以后台实际行为为准，以你自己抓到的前台源码为准。
- 不能把机翻质量问题说成平台规则。Google 的文档里没有这条规则，把经验判断包装成官方要求，只会让后面的判断越做越乱。