HTML 翻译如何保留标签：多语言产品页发布前的检查清单

为什么直接翻译整段网页容易出问题？

一篇产品页里，真正需要翻译的往往是可见文字与部分描述属性。标签、链接、产品型号和模板变量则有不同用途。把整段源码当作普通文案改写，可能让网页看起来已经翻译，却损坏了链接、变量或结构。

迅龙 HTML 与文本翻译提供独立 HTML 模式。它调用 Google Cloud Translation NMT 进行翻译，并对结构与保护内容做检查；它不是让 Gemini 重新编写产品事实。普通单次翻译与付费批量任务也分别管理，使用前先查看页面限制和报价。

第一步：先整理需要保持原样的内容

翻译前准备一份简短的保护清单：品牌名、系列名、具体型号、客户要求保持的术语，以及模板变量。不要把未核实的认证、尺寸或性能交给翻译服务“补充完善”。

下面是一个虚构的源码示例：

<article>
  <h2>{{product_name}}</h2>
  <p>Model LW-DEMO-01 is available for project review.</p>
  <a href="https://shop.example/products/demo">View specifications</a>
  <img src="/images/demo.jpg" alt="Front view of the sample unit">
</article>

这里的 LW-DEMO-01、{{product_name}}、链接地址和图片路径需要单独核对；标题、段落、链接文案和 ALT 是否翻译，应由发布目的决定。示例域名和参数不是实际产品承诺。

第二步：把“标签没坏”和“译文正确”分开验证

结构保护能帮助发现丢失的标签、链接或占位符，但不能证明翻译已经表达了所有商业含义。数字一致，也不能证明单位、否定词、适用条件和贸易条款没有问题。

可以先用HTML 格式化工具整理待检查的源码，再在测试页面查看实际展示。不要因为代码缩进整齐就跳过语义复核。

第三步：明确属性翻译范围

图片 ALT 应描述图片本身，而不是堆满关键词。链接标题、辅助标签和页面描述也要与对应元素和页面目的相符。迅龙允许按设置处理部分 SEO 与可访问性属性；提交前核对选项，完成后再检查结果。

Google Cloud Translation 对 HTML 的处理方式及接口参数，见官方文本翻译文档。服务支持 HTML 输入，并不意味着整站模板逻辑、客户端脚本和业务变量都能自动获得验证。

第四步：翻译完成后，再配置语言页面关系

翻译正文只是多语言发布的一部分。中文页和英文页还需要各自稳定的公开网址、正确的语言声明，以及匹配实际版本的 canonical 和语言关联。

hreflang 应指向实际存在、内容相对应的语言版本，并保持互相引用。不要把中文文章和英文首页强行配成同一篇翻译，也不要为尚未发布的英文稿生成对应链接。具体规则见 Google 多语言版本文档。

如果图片和内部链接需要指向当地语言页面，应在自己的发布流程里逐项核对。翻译接口不会自动完成这些 CMS 业务决策。

批量翻译：条数和消耗不是同一个限制

批量任务适合已经整理好的页面集合。先用少量代表性 HTML 验证结构与术语，再提交更大的批次。长文章、多个目标语言与选中属性会影响实际上游字符量，不能只按“有多少篇”估算全部成本。

迅龙后台的批量 HTML 翻译要求有效付费会员，并先确认积分预占。任务条数、输入字符和语言份数分别限制；使用成功部分按实际计量结算。文章、译文与导出有保留期限，完成后及时下载并保存发布记录。

建议保留一份自己的发布台账：原页面、目标语言、任务编号、校对人或核对记录、最终公开 URL、上线时间。对关键产品页，可以把同一份规格表作为多个语言版本共同的事实来源。

上线前的最后一轮检查

1. 在测试页面确认结构、手机显示和图片加载。
2. 对照原资料核对型号、数字、单位及限制条件。
3. 逐个检查核心产品链接和询盘入口。
4. 确认 canonical 与真实翻译版本关联。
5. 发布后重新检查公开页面，保留可回溯的版本记录。

需要开始单篇翻译时，使用HTML 翻译工具；需要整理源码或交接说明时，可配合Markdown 编辑器与网站综合诊断。

本文由 AI 辅助整理，依据迅龙当前翻译流程与所列官方资料核对。示例中的产品、域名及型号仅用于说明；机器翻译仍需结合真实业务资料审阅。