实际问题分析
任何寻求在国外市场开展业务的公司都知道语言技术对于成功至关重要。 合同,产品手册,小册子,广告活动以及与公司沟通有关的所有其他事项,都必须进行调整,以适应要进行商业运营的每种不同文化。
本文是对XML在本地化中的使用的介绍。 其目的是为将来的文章提供基础,这些文章将解释相关XML标准的技术方面。
本地化工作流程
一个本地化项目包括几个步骤,涉及许多参与者。
图1分五个阶段说明了传统过程。 (图形中的蓝色框表示内部进行的过程;黄色框表示由翻译公司完成的任务。)
图1.传统的本地化过程
第一步是创建需要翻译的文档。 例如,典型的软件产品可能包含:
- 存储在RC文件(C / C ++资源文件)中的程序GUI
- 用桌面出版软件编写的产品手册
- HTML格式的帮助文件
- PDF手册
其他类型的产品(例如,电器或汽车)可能没有RC文件,但可能需要对诸如复杂的网站,幻灯片或广告脚本之类的内容进行其他翻译。
准备好文档后,会将其发送给翻译机构或几个独立的翻译人员。 此阶段在图1中标识为“翻译提供者”。
通常,您需要翻译多种文档格式。 这可能有问题,原因有两个:
- 并非所有的翻译机构都能处理所有格式。
- 可以将一种格式的文本部分复制为另一种格式(如上例中HTML帮助文件和产品手册)。 如果发生这种情况,翻译费用很可能也会被重复。
如果要降低成本,您的首要任务是减少文档格式的数量。
翻译后,通常必须重新格式化文件:文本的长度因语言而异,因此小册子或合同通常需要进行调整。 此阶段称为翻译后桌面发布。 通常由翻译机构或第三方专家来处理,因为通常这些专家具备处理多种语言的能力。
重新格式化的文档应由翻译人员审核,以确保DTP运营商不会无意间引入任何错误。 进行必要的更正后,翻译后的文档最终将交付给制造商。
将翻译问题交给专门的第三方的传统方法可能会增加成本,并给项目增加不必要的复杂性。
另一个令人关注的问题是向翻译人员泄露机密信息。 公司是否应该公开其源代码? 这可能是一个困难的决定,但是如果仅为翻译机构提供需要翻译的文本以及提供上下文所需的最少机密信息,管理人员通常会感觉更好。
修改后的工作流程
这是另一种方法:
- 从原始文档中提取所有可翻译的文本。
- 将提取的字符串存储在特殊的XML文档中。
- 发送XML文档进行翻译。
- 从XML文档中提取翻译后的字符串,然后将其重新插入原始文档中。
通过使用这种替代方法,公司可以保留对过程及其组成部分的更大控制权。 此外,使用优质的计算机辅助翻译(CAT)工具进行文本提取可以帮助减少对翻译后DTP的需求。
图2总结了上述步骤。
图2.替代本地化工作流程
第二阶段(“翻译准备”)包括将字符串转换为特殊的XML词汇表,并在可用的情况下重用现有的翻译。 这是使用CAT工具或定制的文本过滤器完成的。
翻译机构返回翻译后的XML文档后,所有字符串都会重新插入原始文档中。 此过程称为反向转换 ,使用步骤1中使用的相同工具执行。
XML标准:XLIFF和TMX
上述过程不是新的。 许多软件公司都遇到由多种文档格式引起的问题,因此他们正在寻找基于XML的解决方案。
2001年,包括Novell,Oracle,Sun和IBM在内的数家IT公司成立了一个技术委员会,负责编写XML本地化交换文件格式(XLIFF)规范,该规范由结构化信息促进组织正式发布。标准(OASIS)在2002年。
XLIFF,一种通用格式
XLIFF的优点之一是相对简单。 XLIFF文件可以描述为翻译单元的集合。 每个翻译单元在一个名为<source>
的元素中包含从原始文档中提取的一个句子或段落,而翻译人员必须用适当的翻译填充<target>
元素。
可以使用<alt-trans>
元素将以前项目的旧版翻译添加到新的翻译单元中。 译者可以将这些翻译用作指导。 有时<alt-trans>
元素中的翻译是完美的,翻译者要做的就是接受建议的文本。
图3显示了翻译单元不同组件之间的关系。
图3.翻译单元的组成
清单1是一个实际的翻译单元:
清单1.翻译单元
<trans-unit approved="no" id="1" resname="res1" xml:space="preserve">
<source xml:lang="en">Corporate Headquarters</source>
<target xml:lang="es">Casa Central de la Compañía</target>
<alt-trans match-quality="100" origin="web" tool="TM Search">
<source xml:lang="en">Corporate Headquarters</source>
<target xml:lang="es">Casa Central de la Compañía</target>
</alt-trans>
<alt-trans match-quality="92" origin="web" tool="TM Search">
<source xml:lang="en">"Corporate Headquarters"</source>
<target xml:lang="es">"Casa Central de la Compañía"</target>
</alt-trans>
</trans-unit>
图4显示了XLIFF编辑器的真实实现,其中包含源文本,目标文本和建议的翻译。
图4. XLIFF编辑器的实现
有关此格式的更多详细信息,请参阅链接到XLIFF规范相关主题 。
使用TMX重用翻译
XLIFF文件的<alt-trans>
元素中包含的可能翻译是从翻译记忆库(TM)数据库中提取的。 翻译记忆库是一种语言技术,可通过在数据库中搜索相似的句段并建议在数据库中找到的匹配项来翻译文档的句段(句子,段落或短语)。 例如,可以构建一个TM,将来自XLIFF文件的翻译后的<source>/<target>
对存储在关系数据库或专门设计的TM服务器中。
技术手册,法律合同和公司网站通常包含在每个已发布版本中重复的文本。 因此,最好保留TM数据库并尽可能重用其内容。 好的TM系统可以帮助您在本地化项目中大幅降低成本。
容器/内容允许重用开放标准(OSCAR)组将TMX定义为通用标准,以使用户在使用不同的CAT工具或翻译提供商时可以更有效地重用文本。
从TMX网站:
TMX(翻译记忆库交换)是与供应商无关的开放XML标准,用于交换由计算机辅助翻译(CAT)和本地化工具创建的翻译记忆库(TM)数据。 TMX的目的是允许在工具和/或翻译供应商之间更轻松地交换翻译记忆库数据,而在此过程中不会丢失或丢失关键数据。
XLIFF和TMX这两个规范均包含以XML格式存储源文档格式信息的所有必要元素。 一个好的CAT工具将允许翻译人员在翻译RTF格式文档时重用HTML页面中的句子,从而保持文本布局的完整性。 这就是为什么应使用TMX格式作为XLIFF的补充的关键原因。
像XLIFF文件一样,TMX文件是翻译单元的集合。 每个单元由一个<tu>
元素表示,并包含至少两个翻译单元变体或<tuv>
元素。 每个<tuv>
元素都以给定语言指定文本。 清单2显示了清单1中使用的候选翻译之一。
清单2.清单1中使用的候选翻译
<tu tuid="1090682451312" creationdate="20040313T224601Z">
<tuv xml:lang="en">
<seg>Corporate Headquarters</seg>
</tuv>
<tuv xml:lang="es">
<seg>Casa Central de la Compañía</seg>
</tuv>
</tu>
随附的.zip文件包含完整的XLIFF和TMX示例(请参阅参考资料 )。
由于XLIFF和TMX都是XML词汇表,因此可以使用XSL转换将XLIFF文件转换为TMX格式。 (请参阅相关信息的链接霍加皮框架的XSL工具的集合,旨在加强与翻译相关的XML资料的操作。)
翻译记忆是宝贵的资产。 本地化项目完成后,所有翻译内容均应纳入公司维护的记忆中。 通过这样做,该公司将增加每个项目中重复使用文本的百分比。
管理词汇表
词汇表是专业术语的集合,这些术语及其含义以及(可选)它们的翻译。
合同和技术手册通常包含与特定上下文相关的具有特定含义的术语。 将文档发送给翻译人员时,通常会附带一个词汇表,并且如果词汇表中包含首选翻译,则希望译者使用提供的首选翻译。
词汇表可以任何格式编写。 具有两列的电子表格可能足以列出术语及其翻译。 但是,如果公司专注于术语一致性,那么仅列出一个清单是不够的。
重申一下,在给定的上下文中限制了某些术语的含义。 词汇表中的条目应针对每种可能的上下文进行解释,针对每种感兴趣的语言提供首选的翻译,以及负责文档的人员需要的任何其他属性。 如果没有良好的词汇表,翻译人员可能将复杂的技术手册变成毫无价值的文档。
如果术语表可供翻译人员或翻译公司使用,则应采用有用的格式。 编写TMX标准(OSCAR)的小组还编写了TermBase eXchange(TBX)的规范,该规范是一种基于XML的通用格式,几乎被普遍接受为该标准。
TermBase或术语数据库是一种特殊的词汇表,其中术语通过用户定义的属性分为几类。 TBX是术语数据库内容的XML格式的一种可能表示形式。
从技术上讲,TBX是术语标记框架(TMF) ,它是一种符合ISO 12200标准(称为MARTIF )的标记语言。
TBX与TMX和XLIFF一样,提供了不同术语工具之间的可移植性,并允许与工具供应商的某些独立性。
软件本地化
翻译常规散文时,翻译的长度很少。 例如,德语句子通常比英语句子长,而短篇小说用德语比英语长一两页也没关系。
使用最广泛的编程语言是C和C ++。 在C / C ++中,GUI文本通常存储在资源文件 (纯文本文件)中,这些文件有助于提取文本以进行翻译。 但是,作者(或视觉工具)根据原始语言中文本的大小来定义对话窗口的大小。 如果翻译后文本的长度发生变化,则布局将受到影响。 如果标签的译文比原始译文更长,则文本可能会被截断; 如果更短,则对话可能以不希望的空白结束。
幸运的是,XLIFF标准包括一些属性,这些属性用于指定对话中的字符串位置,用于文本的字体类型和大小以及许多其他详细信息。 专为软件本地化设计的工具可用于在翻译过程中直观地调整对话框的布局。
Java技术是继C / C ++之后使用最广泛的语言,其目的是促进软件国际化。 准备进行本地化的Java应用程序将GUI文本存储在资源包中 ,这些纯文本文件像C / C ++对应文件一样,使文本提取成为一项简单的任务。 但是,Java技术比C / C ++有一个优势:GUI对象可以在执行时根据该对象包含的文本的长度进行动态调整。 此功能使Java语言成为开发多语言应用程序的更好选择之一。
摘要
本地化和全球化的各个方面在很大程度上取决于技术。 这篇介绍性文章简要介绍了本地化行业中使用的最相关的XML标准-XLIFF,TMX和TBX-并给出了其用法的提示。 XML技术不是新技术,但是其在翻译相关任务中的创新应用正在稳步增长,超越了公司环境,并吸引了一些希望在全球市场取得成功的小型公司。
本系列的下一篇文章将探讨转换为XLIFF以及使用Java技术转换为普通文件格式(如纯文本或HTML)的详细信息。 我将包括一个用于Java资源包的完整转换工具。
翻译自: https://www.ibm.com/developerworks/xml/library/x-localis/index.html
实际问题分析