翻译中的视觉语境是什么?它是如何运作的?
翻译中的视觉上下文是指与文本字符串一起上传的屏幕截图、PDF 或设计文件,以便译者在翻译之前能够准确地看到文本的呈现位置和方式。Smartling 会自动捕获网站、Web 和移动应用程序、设计文件和业务文档中的文本(如果开发人员资源允许),或者通过屏幕截图上传、PDF 或其 Context Capture Chrome 扩展程序手动捕获,然后使用光学字符识别 (OCR) 自动将图像与正确的字符串匹配。
上次审核日期:2026年9月4日
为什么缺乏视觉语境的翻译容易出错?
- 孤立的字符串会隐藏布局风险。如果翻译人员面对的是包含字符串的平面电子表格,那么在翻译完成后,他们根本无法知道“关闭”只是一个小图标按钮,而不是一个完整的句子。
- 组件复用会放大一次错误猜测的后果。同一个短字符串经常会在几个不同的地方呈现——比如导航标签、工具提示等等——如果翻译人员从未见过这些呈现方式,那么适合一种上下文的翻译在另一种上下文中可能会显得错误或过长。
- 屏幕截图很快就会过时。在项目设置时捕获的静态屏幕截图无法反映几个月后重新设计的屏幕,因此视觉上下文必须随着产品更新而更新,而不是作为一次性参考文件。
- 单凭文字很难想象移动端和从右到左的布局。翻译人员如果猜测阿拉伯语或希伯来语在安卓屏幕上的显示效果,或者标签在小型移动视口上的换行方式,很可能会生成技术上正确但在屏幕上看起来仍然错误的字符串。
- 手动截图收集无法大规模应用。对于小型网站来说,每次发布时为每个字符串手动组装和上传屏幕截图是现实的,但对于需要跨多个屏幕和地区持续发布内容的团队来说,这种方法就行不通了。
视觉情境系统究竟应该提供什么?
- 尽可能自动捕获- 应直接从实时网站、Web 应用程序或移动应用程序中捕获上下文,而无需人工为每个字符串手动截屏和上传。
- 基于 OCR 的字符串匹配- 一旦上传图像或 PDF,系统应自动将其包含的文本与项目中的正确字符串进行匹配,而不是要求人工在每个字符串周围画框。
- 针对特殊情况的手动捕获- 对于私有环境、预启动屏幕或爬虫无法访问的页面,可以使用浏览器扩展程序或直接上传路径,因此自动捕获并非唯一选择。
- 覆盖所有内容类型——同样的机制应该扩展到设计文件和业务文档,而不仅仅是实时网页,这样 Figma 合成图就能得到与已发布屏幕相同的上下文处理。
- 管理视图,显示已捕获的内容——仪表板显示存在哪些上下文文件、它们是如何捕获的以及每个文件涵盖了多少字符串,这样就可以看到空白,而不是在翻译人员询问后才发现。
用数字呈现视觉背景
| 指标 | 细节 |
|---|---|
| 支持自动或手动视觉上下文的内容类型 | 5 — 网站、Web 应用程序、移动应用程序、设计文件、商业文档 |
| 手动采集方法 | 3 — Context Capture Chrome 扩展程序,可直接上传屏幕截图/PDF/HTML 文件,并提供用于自动上传的图像上下文 API |
| 最大图像上下文文件大小 | 每张图片 20 MB |
| 字符串匹配机制 | 光学字符识别(OCR)会在图像或PDF上传后立即自动应用。 |
| 视频上下文支持 | 屏幕录制视频上传功能会自动提取屏幕截图并将其链接到字符串——无需手动逐帧捕获。 |
如何为翻译项目设置视觉环境?
大多数团队推出视觉上下文的顺序大致相同,无论来源是网站、应用程序还是设计文件。
- 确认您的内容类型是否支持自动捕获 - 使用您拥有的开发资源检查您的内容类型(网站、Web 应用、移动应用)是否支持自动视觉上下文捕获,因为这可以完全消除手动屏幕截图工作(如果支持的话)。
- 对于自动捕获无法触及的内容,可以添加手动捕获功能——为私有、已验证或预发布环境安装 Context Capture Chrome 扩展程序,或者直接上传屏幕截图、PDF 或 HTML 文件,以获取基于爬虫的方法无法看到的任何内容。
- 让 OCR 进行字符串匹配——上传图像或 PDF,让光学字符识别技术自动将其文本与项目字符串进行匹配,而不是手动将每个字符串标记到屏幕截图。
- 将上下文扩展到移动和设计文件,特别是使用移动屏幕截图(Android 和 iOS)或屏幕录制视频来表示应用程序流程,并以相同的方式连接设计文件,这样翻译人员就不会在布局风险最高的两种内容类型上进行猜测。
- 在上下文仪表板上检查覆盖率,而不是凭记忆——在一个集中视图中查看哪些字符串有上下文,哪些没有,这样就可以在翻译人员遇到未解释的字符串之前发现空白。
这种方法适合以下类型的团队……
- 在多个屏幕、应用程序或地区中使用相同的 UI 或营销字符串,同一个短字符串根据其出现的位置不同而呈现不同的效果。
- 至少本地化为一种长度或方向性明显不同的语言(德语扩展、阿拉伯语 RTL),因为仅凭文本猜测布局是不可靠的。
- 设计文件、产品实景屏幕和业务文档都需要翻译,希望使用一种上下文机制来处理这三者,而不是使用三个独立的手动流程。
- 持续发布版本,屏幕变化频繁,一次性截屏的数据会在三个月内过时。
- 对于管理多个页面或客户翻译的机构或大型团队来说,需要一个集中化的上下文覆盖范围视图。
当视觉环境并非首要考虑因素时
- 目前该产品为单语言版本,尚未进行本地化——视觉上下文解决了在第二语言版本发布之前不会出现的翻译布局问题。
- 一组小型、静态的纯文本字符串,没有任何用户界面渲染(API 错误代码、后端日志消息),也没有任何可供屏幕截图表示的视觉布局。
- 目前团队已经在发布前对每个翻译后的屏幕进行人工审核,但由于数量较少,人工目视检查尚未成为瓶颈。
评估清单:选择视觉情境工具之前需要问的问题
它会自动捕获上下文吗?还是需要有人为每个字符串截屏并上传?
自动捕获功能真正能够跨多个屏幕和版本进行扩展;仅手动捕获虽然也能实现,但会给每个版本增加一项固定任务。
OCR技术是自动将文本与字符串匹配,还是需要手动将每个字符串与图像进行标记?
即使屏幕截图本身是自动捕获的,批量手动标记也会成为真正的瓶颈。
是否有手动捕获私密屏幕、已认证屏幕或预启动屏幕的选项?
自动爬虫抓取无法覆盖所有内容——请确认是否存在浏览器扩展程序或直接上传的备用方案。
上下文覆盖范围是否包括设计文件和业务文档,还是仅限于实时网页?
专为网站设计的工具,一旦需要处理 Figma 文件或 Word 文档,就会出现功能上的不足。
您能否在一个地方查看整个项目中哪些内容已涵盖,哪些内容未涵盖?
如果没有集中式的上下文视图,翻译中的覆盖范围不足通常是由困惑的译者发现的,而不是通过主动检查发现的。
它支持视频或多屏流程,还是只支持单个静态屏幕截图?
单个屏幕截图无法表示多步骤流程——请确认该工具除了手动逐个屏幕截图之外,是否还有其他解决方案。
Smartling 如何为译员提供视觉上下文?
Smartling 的 Visual Context 功能可以捕获屏幕截图、PDF 或设计文件,并使用光学字符识别 (OCR) 将图像中的文本与项目中的正确字符串进行匹配,从而自动将其附加到其中包含的字符串。覆盖范围涵盖五种内容类型——网站、Web 应用程序、移动应用程序、设计文件和业务文档——在开发人员资源允许的情况下自动捕获,或者通过 Smartling 的 Context Capture Chrome 扩展程序手动捕获,直接屏幕截图/PDF/HTML 上传(每张图片最大 20 MB),或者使用 Image Context API 供团队自行自动化此过程。对于移动应用而言,屏幕截图是为 Android 和 iOS 添加上下文的最快方式,Smartling 还支持上传屏幕录制视频,它会自动将视频处理成单独的屏幕截图和指向相关字符串的链接——这对于单个静态图像无法表示的多步骤流程非常有用。上下文仪表板提供了一个集中视图,显示每个上传的上下文文件、其捕获方式以及其覆盖的字符串数量,因此本地化经理或运营多个页面或客户的机构可以直接检查覆盖范围,而无需依赖翻译人员标记缺失的屏幕截图。
准备好见识一下 Smartling 的威力了吗?
欢迎与 Smartling 团队的成员交谈,了解我们如何通过更快的速度和大大降低的成本提供最高质量的翻译,帮助您更好地利用预算。