软件与应用本地化

纯JSON不支持注释和复数形式——英语可以应付,但一旦译员添加弯引号(' vs ')、法语标点周围的窄不间断空格或德语书名号(»、«),脆弱的JSON解析器就会在生产环境中崩溃。法语译员使用正确的排版撇号书写L'application能通过语言质量检查,却会破坏脆弱的JSON解析器。我们在导入时规范撇号,验证UTF-8 BOM是否存在,并在任何语言环境交付前进行语法检查。

Android将撇号存储为\',将&符号存储为&。译员经常粘贴Microsoft Word的弯引号,外观相同但实际不同——直到运行时布局渲染出乱码。我们对Android资源使用自定义XLIFF往返流程,译员无需接触原始XML,导出时自动重新转义。

经典问题是复数规则。iOS通过.stringsdict使用CLDR复数类别(zero、one、two、few、many、other)。不熟悉的译员会将文件视为一对一翻译并丢失复数变体——您的德语应用随后会显示"1 Nachrichten"(语法错误)。我们使用复数感知编辑器,根据目标语言环境的要求显示每个CLDR类别,如果任何类别缺失则拒绝导出。

.resx接受XML注释和嵌入式代码引用;.properties默认使用ISO-8859-1(现代工具链支持UTF-8,但错误的组合仍会输出\uXXXX转义序列,令译员困惑)。我们在导入时强制使用UTF-8,仅在构建时生成原生转义序列。

只要可能,我们将源文件提取为XLIFF 1.2或2.0,在编辑器内翻译并附带上下文,然后重新合并。这让译员能看到源注释、截图和约束条件(字符限制、ICU复数形式、RTL镜像标志),而无需接触源文件。构建管线将内容合并回开发人员提交的格式。

{count, plural,
 one {# friend}
 few {# friends}
 many {# friends}
 other {# friends}
}

这在英语、法语和德语中没问题。在阿拉伯语中您需要zero、one、two、few、many、other。在波兰语中,few仅覆盖2-4,且仅当最后一位数字是2-4且数字不是12-14时——波兰语大约有5种复数类别。威尔士语有自己的规则。我们针对每种语言环境的CLDR复数规则集进行翻译,而非依据英语模板。

西班牙语、意大利语和普什图语都需要知道主语是阳性、阴性还是中性以变化动词。"You are invited"的天真翻译会默认为阳性;女性用户在50%的语言环境中会看到语法错误。ICU的select可以处理这个问题:

{gender, select,
 female {Estás invitada}
 male {Estás invitado}
 other {Te han invitado}
}

如果您的数据模型不跟踪性别,安全的做法是使用性别中性的other分支。我们在源审查中标记有性别的字符串,以便您的团队在投入翻译预算前决定是否捕获性别、默认使用中性或发布变体。

App Store和Google Play的评论经常指出复数错误:"应用有错误,显示'1 messages'"。一星评价会累积并降低排名。发布后修复复数形式的成本高于事前使用ICU感知翻译。

最常见的生产错误:开发人员编写margin-left: 16px而非margin-inline-start: 16px。在从左到右的语言环境中两者相同。在阿拉伯语中,前者将边距固定在屏幕左侧;后者则正确翻转到右侧。我们在接触字符串前审计您的样式表,查找物理属性(left、right、padding-left、border-right)。

提及英文品牌名、URL或数字的阿拉伯语段落会成为混合方向字符串。浏览器使用Unicode双向算法处理,但该算法基于启发式,在可预测的情况下会出错——最常见的是句子以拉丁数字或标点结尾时。我们在用户名和产品ID等不透明标记周围插入U+202A/U+202C(LRE/PDF)标记或使用<bdi>标签。

箭头图标、"返回"尖括号、撤销和重做、滑块方向、进度条——每个方向性图标都需要RTL变体或CSS变换。Lucide和Heroicons有RTL感知变体;Material图标集需要镜像类。我们编目您设计系统中的每个方向性图标,在审计中标记任何未镜像的图标。

西方字体栈通常缺少阿拉伯语字形——Helvetica Neue、Inter和Roboto都需要阿拉伯语后备。系统默认字体(iOS上的Geeza Pro、Android上的Noto Naskh Arabic)能渲染,但行高错误且字距不佳。我们在您用户实际使用的设备上测试渲染——而非仅在macOS的Chrome上——并在伪语言环境审查中标记字体栈修复。

阿拉伯语是我们最大的单一语言对。我们的姊妹品牌arabictranslation.co.uk自2012年起就提供阿拉伯语本地化服务。大多数英国机构收取的RTL附加费(20-30%)反映出这对他们是不常见的工作;而这是我们最常做的工作。我们不收取RTL附加费。

适合大多数SaaS团队。GitHub webhook在每次推送到main时触发。我们的服务检查差异中的新增或更改字符串,起草语言环境,发送给语言专家审核,并开启返回PR。分支保护确保PR在审核前无法合并。典型端到端时间:200字符串提交的35种语言在18-24小时内完成。

如果您的团队更喜欢语言环境更改通过构建系统(CircleCI、GitHub Actions、GitLab Runners)流转,我们提供CLI:lingosecure pull在构建步骤中将最新翻译拉入您的代码库,lingosecure push上传任何源字符串更改以供翻译。适用于运行发布列车且不希望翻译PR出现在流程中的团队。

如果您已有TMS,我们乐意作为其中的语言专家层——您的开发人员继续向TMS推送字符串,我们的语言专家在TMS内翻译,TMS同步照常运行。对您的工程师零工作流更改。优势:一家供应商,而非拼凑TMS订阅、自由译员名册和受监管内容的供应商。

所有三种模式共享一个原则:您的翻译记忆库归您所有。每个翻译片段都记录到您的TM中,我们在LingoSecure内托管或按需导出到您的TMS。如果您明年更换供应商,TM随您而去。没有锁定。

我们将翻译记忆库版本固定到产品发布。您的v4.2绝不会意外使用v4.1的翻译字符串。如果您的团队需要回滚发布,TM也随之回滚。这对受监管产品很重要,其中翻译的披露必须与批准的英语版本匹配。

• 截断 — 能容纳"OK"但不能容纳"Aceptar"的按钮
• 硬编码字符串 — 任何未包装在t中的内容
• 拼接错误 — "Hello " + username在词序不同的语言中会出错
• 固定宽度假设 — 日期选择器、下拉菜单、导航标签
• 字体后备 — 因字体不覆盖Latin Extended-A而变成矩形的文本
• RTL翻转错误 — 每个方向性图标和布局在伪RTL中翻转

我们将伪语言环境构建作为Storybook部署或您的QA团队可以测试的功能分支交付。缺陷日志直接进入您的Linear、Jira或GitHub Issues。我们修复语言环境侧的问题;您的团队修复产品侧的问题,在支付任何人工翻译费用之前。

对于成熟产品,我们运行额外的流程:每个屏幕在英语、伪英语、德语、阿拉伯语和中文中捕获,并比较差异。布局退化立即显现。如果需要,同样的工作流可以作为GitHub Action针对每个PR运行。

每个字符串在离开门户前都要经过合格语言专家审核。我们使用我们的专业语言学家加速初稿,但没有任何字符串在没有人工签核的情况下交付。如果您出于成本原因需要原始MT,AWS Translate和我们的管道 API都很出色——我们会帮助您设置,但不会在输出上署我们的名字。

在大多数主要语言环境中,4小时内完成50字符串的紧急修复是现实的。24小时内完成5000字符串的产品发布是不现实的,我们不会承诺。我们从您的发布日期倒推并内置质量保证缓冲;如果您的时间线更短,我们会告诉您实际可行的方案。

大多数英国机构将阿拉伯语路由到开罗或贝鲁特工作室。我们由指定语言专家内部翻译。翻译您v1字符串的人就是翻译v4.7的人。术语一致性是连续性的结果;连续性需要不外包。