[发明专利]自动检测、校正和翻译非本地化行的方法

说明书

一种在安装的应用程序传播到消息文件(*.po)之前定期检查应用程序源代码中的本地化行的方法。提供了将这些行自动国际化为所有支持的应用程序语言。比对消息文件(PO)来验证这些行以及它们在区域设置文件(JSON)中的翻译。使用本地化标记在源代码中检查非本地化的行。根据APS，将特殊陷阱(即钩子)用于APS msgmake实用程序，以便从用于安装用户界面的aps_command_line_工具的集合中导出本地化数据。这些行被校正并加载回“*.po”文件。

相关申请的交叉引用

本申请是2016年09月20日提交的序列号为No.62/397,051的美国申请的国际申请并要求其优先权，其内容和附图通过引用全部并入本文中。

技术领域

本发明涉及一种用于自动检测非本地化代码行的方法，并且更具体地，涉及对能兼容应用程序打包标准(APS)的应用程序接口中的代码行的检测、校正和翻译。

背景技术

服务自动化系统需要大量的能兼容应用程序打包标准(APS)的应用程序。应用程序打包标准(APS)是一种标准，该标准定义了用于将应用程序软件与托管平台集成在一起的技术。应用程序与这样的托管平台的集成是通过为该应用程序创建APS包来实现，并且在这种情况下该应用程序被称为APS应用程序。在APS平台上的开发允许应用程序通用于不同的托管平台上。这些应用程序也以当地语言和/或方言配置在世界的各个地区。为了使用这些应用程序，有时使用当地语言来配置其图形用户界面(GUI)。例如，当GUI呈现给美国(U.S.)的用户时，GUI可能具有英语的文本元素，当呈现给俄罗斯的用户时，相同的GUI元素可以具有翻译成俄语的相同文本。对GUI元素使用当地语言(与仅使用英语相反)可以实现定制和改进的用户体验。

国际化(i18n)是开发应用程序的过程，使得字符串和其他的地区专属位(例如日期或货币格式)可以从应用程序中抽象出来，以便它们可以容易地针对语言和文化进行本地化。本地化(l10n)是通过为抽象出来的位(bit)提供翻译和本地格式来调整应用程序和文本以使其能够使用在特定文化或语言市场中的过程。例如，使美国应用程序对于澳大利亚或英国用户可访问可能需要多一些拼写校正。但是，为了使美国应用程序能够被日本用户使用，或者使韩国应用程序能够被德国用户使用，将要求该软件不仅以不同语言操作，而且还要使用不同的输入技术和呈现惯例。

为每种语言和每个应用程序开发GUI(以及其中的GUI元素)不是可行的命题。在尝试在世界多个地区配置应用程序时，开发所谓的“语言本土化”GUI所需的时间、精力和金钱可能会是非常繁重的。

为了减轻负担，软件和开发平台(例如APS平台)允许GUI元素被本地化和翻译。这允许GUI在呈现时为该区域(或用户)的本土语言。但是，GUI界面元素的传统翻译和转换呈现得并不一致。这可能是因为：包含一种语言的字母表的字符集与另一种语言不同；空间特征的变化使翻译后语言的文本更大(或更小)；或者有“在翻译中丢词”的含义。

此外，当开发或改进GUI时，在屏幕上呈现给最终用户的数据量可能增加，这包括用户看到的任何文本消息只是一部分GUI。特别地，行的数量、界面元素的标记和屏幕形式都趋于增加。根据APS标准，所有应用程序界面元素都必须进行本地化和国际化。但是，在将界面行和元素包含在应用程序代码中之后，它们并不总是被正确地格式化。因而，最终用户可能会观察到由应用程序内部的消息的部分本地化和翻译引起的故障。

例如，现在参见图1，示出了用于翻译能兼容APS的应用程序的非本地化行的传统方法(通常以100示出)的实施例。该传统方法包括收集源代码的步骤102；通过msgmake挂件(post)导入本地化的步骤104；创建可移植对象(.po)消息文件的步骤106；将msgmake挂件转送给为非本地化行起草译文的技术撰码人的步骤108；添加译文的步骤110；通过在JavaScript Object Notation(JSON)中导出本地化消息来构建APS包的步骤112；形成带有国际化文件的APS包的步骤114。