采用外观类进行 软件翻译的内观编辑器系统、程序和方法 本发明总体涉及用于开发国际通用软件的工具，特别是用于多语种软件开发的工具。更具体来说，本发明涉及在计算机软件中进行语言翻译的一种改进的系统。
软件国际化
随着计算机变得更加流行，软件开发商已经开始希望能够向那些不使用软件开发商母语的人们营销他们的产品。特别是希望用英语开发的软件能为美国和世界其它地区不讲英语的人们所用。所以，许多用英语开发的软件应用程序后来被翻译，供不讲英语的人们使用。
将软件包翻译到另一种(或一种以上)语言的过程既费时又耗财。要让用户能操作程序，必须要翻译每一个文本信息、菜单和按钮。这样做的最直接方法是检索出整个程序源代码中的文本串一即要向用户显示的每个字符串，然后将每个字符串翻译成新的语言。
这种方法有几个问题。一个问题是使用这种方法意味着必须针对每种目的语言对软件进行专门的翻译和编译。当然这本身就是一个费用很高的过程，并且意味着源代码中发生任何变动时都要求对代码地每个语言的版本进行编辑和重新编译。
图2表示Java应用程序中硬编码(hardcoded)标签的例子。该图中显示，窗口200有两个图形用户界面(GUI)“按钮”210和230。这些按钮是用硬编码的Java“JButton”调用创建的。例如，代码行220以串参数“Ok”调用JButton，生成带文本标签“Ok”的按钮210。类似地，代码行240以串参数“Cancel”调用JButton，生成带文本标签“Cancel”的按钮230。要翻译采用图中那样的硬编码的串的软件应用程序，必须分析每个代码行，并且必须将每个显示串分别译成目标语言。
这个问题的一种解决方案是使用独立的本地化文件，其中，待显示文本串与可执行代码本身分开存储。执行软件时，只要简单地从本地化文件中读出每个给定显示屏的文本，文本使用的就是文件中存储的语言。这样就能翻译本地化文件中的文本而不干扰可执行程序，就能修改可执行程序而不干扰被翻译的文本(当然，除非待显示的文本改变，这时，本地化文件中的对应项也必须改变)。本地化文件可以有多种格式，包括编译信息目录、Java资源束(resourcebundles)、HTML文件及许多其它格式。
本地化文件的使用提供了一种简易的多重翻译的方法，但又带来另外的问题，即翻译是针对单独文件中的孤立文本进行的，没有任何种类的上下文供翻译者参考。由于这个情况，译文常常含有错误一翻译者若能按出现文本所在的上下文来进行翻译，这些错误原本不会出现。
不管翻译问题是如何处理的，然后都要校对运行程序的每个屏幕，保证翻译后的文本显示得当，保证按显示的上下文正确地翻译文本。因此，通行的作法是雇佣具有其它语言背景的人员来校对被翻译程序的每个屏幕，检查任何显示、语法或其它翻译错误。这个第二阶段被称为翻译验证测试(TVT)。
图3表示的是按照常规方法的翻译和测试周期的示意图。代表性的A公司位于A国，编制供B国使用的应用程序(310)。然后，A公司将应用程序打包并运送到位于B国的B公司(320)。B公司然后将执行该应用程序，检查任何翻译或国际化错误(330)。B公司然后进行TVT测试，记录任何翻译错误，并进行任何必要的重新翻译(340)。B公司然后将更正结果送还给A公司，这个过程一直重复到不再发现错误。
按照这个常规过程，每次在B国更正错误或改动翻译后，该产品都必须在A国被重新编制和重新打包，然后再被重新测试。由于这样，TVT过程必定是个耗资费时的过程。因此，希望提供一种方法来向翻译者提供额外的信息，特别是上下文信息，以便使初次翻译尽可能准确。这样做能减低甚至去除进行TVT测试所需的费用和时间。
Java
Java有两个方面：程序设计语言和平台。一方面，Java是一种高级程序设计语言，其不寻常之处是Java程序既是编译的也是解释的，这使它能在许多平台上使用。Java也是一种在其它基于硬件的平台的顶部上运行的唯软件平台。Java平台有两个组件：Java虚拟机(Java VM)和Java应用程序设计接口(Java API)。
Java VM是Java平台的基础，依靠在各种基于硬件的平台上面。Java API是一系列编制好的软件组件，它们提供许多有用的功能，诸如图形用户界面(GUI)小配件。Java API被分组成相关组件的库(包)。
JavaBeans为Java平台带来组件技术。JavaBeans API支持可重用的、独立于平台的组件。采用符合JavaBeans的应用程序编制器工具，可以将组件组合成小应用程序、应用程序或复合组件。JavaBean组件被称为豆(Bean)。
因此，本发明的一个目的是提供一种用于开发有国际性应用的软件的改进的工具。
本发明的另一个目的是提供一种用于多语言软件开发的改进的工具。
本发明的另一个目的是提供一种用于进行计算机软件中的语言翻译的改进的系统和方法。
本发明的以上及其它目的、功能和优点将显见于以下的详细说明中。
通过提供一种为语言翻译者提供待翻译文本的上下文信息的系统和方法，有可能设计出更有效的翻译过程。翻译者被提供一个基础语言的图形用户界面，然后就能互动地翻译屏幕上的每个文本标签。由于翻译是针对恰当的上下文中的文本进行的，翻译验证测试的时间和费用就会减少甚至消除。编辑应用程序内部文本的能力是通过向软件应用程序本身添加编辑器功能而取得的。应用程序中的每个文本标签被存储在作为“外观(facade)”类的组件的本地化文件中，“外观”类包括Java JComponents并向每个成员组件添加额外特性。额外特性包括每个JComponent的Java资源束名和关键字。当编辑器启动时，翻译者能直接地编辑文本，上下文信息被用来存储译文，供以后使用。
被认为是本发明的特征的新颖功能在后附的权利要求中陈述。然而，本发明本身及其最佳使用方式、其它目的和优点，最好将通过参考以下结合各附图对示例性实施例的详细说明而理解。
图1表示可以在其中实现按照本发明最佳实施例的系统的数据处理系统；
图2是一例带有硬编码文本的GUI显示；
图3表示按照常规方法的翻译和测试过程的框图；
图4是按照本发明最佳实施例的翻译和测试过程的框图；
图5表示按照本发明最佳实施例的一例采用Java资源文件的GUI显示；
图6是按照本发明最佳实施例的软件应用程序的内观工具(introspection tool)的框图；
图7表示按照本发明最佳实施例的Java包装类的框图；
图8是按照本发明最佳实施例的Java包装类的更详细的图示；
图9表示按照本发明最佳实施例的Java外观类的框图。
现在参考各附图，特别是参考图1，该图表示的是一个可以在其中实现按照本发明最佳实施例的系统的数据处理系统。数据处理系统100例如可以是国际商用机器公司(位于美国纽约Armonk)提供的计算机。数据处理系统100包括处理器102和103，在示例性实施例中，它们各自分别与二级(L2)高速缓存103和104相连，高速缓存进而与系统总线106相连。
与系统总线106也相连的是系统存储器108和基本主桥(PHB)122。PHB 122将I／O总线112连接到系统总线106，从一个总线向另一个总线转接和／或变换数据事务。在示例性实施例中，数据处理系统1 00包括与I／O总线112相连的、为显示器120接收用户界面信息的图形适配器118。外围设备通过工业标准体系结构(ISA)桥121与I／O总线相连一外围设备诸如是非易失性存储器114(可以是硬盘驱动器)和键盘／指针设备116(可包括普通鼠标、跟踪球等等)。PHB 122也通过I／O总线122与PCI插槽124相连。
图1所示的示例性实施例只是用来进行解释本发明的，本领域的熟练人员知道，在形式和功能上，许许多多的变化都是可能的。例如数据处理系统100也可能包含光盘只读存储器(CD-ROM)或数字视盘(DVD)驱动器、声卡与扬声器、以及许多其它可选部件。所有这种变化都被认为在本发明的精神和范围之内。数据处理系统100和以下各例图只是为了解释的需要而提供的例子，不是为了暗示结构上的限制。实际上，可以容易地将本方法和系统改编得适合在能执行软件应用程序的任何可编程的计算机系统或系统的网络上使用。
典型的对软件应用程序的翻译过程由两个阶段组成。在第一个阶段中，用于应用程序的人类文本单元(human text elements)的人类语言文本在文本文件中被捕获并被传递给翻译者去翻译。这些翻译者没有见过该应用程序，所以没有关于被翻译文本的实际用途的上下文信息。所以，这个过程在设计上就是易于出错的。要消除这些错误，验证译文，就要进行第二个阶段-翻译验证测试。
最佳实施例通过让开发者合并翻译过程的这两个阶段而简化了翻译过程。这是通过向翻译者提供关于被翻译项的直接的上下文信息而实现的。结果，就能缩短甚至取消耗财费时的TVT阶段。
按照最佳实施例，提供一个内观编辑器，它能使翻译者直接编辑界面组件，将翻译结果保存在文本文件中一在最佳实施例中，该文本文件是个Java资源束。这就为翻译者进行准确翻译提供了必要的上下文，这样，译文可能会更加准确。
参看图4，该图是按照最佳实施例的一个改进的翻译和测试过程的框图。A公司位于A国，编制供B国使用的应用程序(410)。然后，A公司将应用程序打包并运送到位于B国的B公司(420)。B公司然后将执行该应用程序，检查任何翻译或国际化错误(430)。B公司然后进行TVT测试，记录任何翻译错误，并进行任何必要的重新翻译(440)。与上文在图3中所述案例不同的是，由于本实施例允许在上下文环境中进行翻译并将译文在本地存储，B公司能立即重新测试译文(430)，而无需先将产品运回A国去重新编制。结果，该翻译与测试阶段比用常规方法效率要高得多。
当然，在B国的测试阶段有可能将暴露出其它错误，诸如程序设计错误，这些是不在翻译问题中更正的。在这种情况下，就要像常规过程中的那样，将应用程序运回A国去作更正。
按照本文中所述的一些实施例，翻译者将要实际执行其正在翻译的软件应用程序，所述实施例为翻译者提供了直接从屏幕选择文本并实时地编辑文本的方法。由于翻译者实际看着与最终用户将要看到的一样的应用程序，所以译文将会更加准确。
按照最佳实施例，在使用中，内观编辑器以“弹出式”编辑器窗口的形式伴随待译文本一起被显示出来。例如，如果发现待译文本在基于窗口的图形用户界面(GUI)上的“按钮”上，则本地化文件将把关于该按钮的基本上下文信息与该文本本身[just the AEF]一起存储起来。当该文本要被翻译时，上下文信息就被读出，按钮与原始文本一起被显示在屏幕上。当翻译者选择该按钮时，编辑器弹出式窗口就显示出来，翻译者将输入对应该按钮的翻译文本。编辑器将关闭，翻译文本将被存储在本地化文件中一要么是在新文件中存储，要么是通过盖写原始文件中的原始文本而存储。这样，就在最终应用程序中出现按钮所在的上下文中进行了完全的翻译。
在最佳实施例中，用“ctrl-alt-shift”组合关键字来表示要翻译所显示的文本。当GUI窗口显示出来时，翻译者通过按下“ctrl-alt-shift”或者用鼠标或其它指针设备“右点击”显示器上的某文本标签，表示要翻译该文本标签。编辑器窗口打开后，翻译者就能将新文本直接输入编辑器窗口中。当翻译者结束时，新文本被存储起来供将来使用。
通过在软件应用程序的用户界面中直接翻译文本单元，通过向翻译者提供上下文，该方法能去除翻译过程的TVT阶段，由此缩短时间，减少错误。
编辑器之所以被称为“内观”编辑器，是因为它在本实施例中，用Java程序设计语言的内观特性(introspection properties)来察看和编辑带“setText”和“getText”过程的控件。尽管本文中说明了Java、JavaScript、JavaBeans和其它有关Java的工具的有些方面，其它材料可从Sun Microsystems公司获得，(据截至本申请的申请日的资料)也能在httP：／／java．sun．com找到。
每个Java Bean组件都有其自己的特征，包括其特性、过程和事件。这些特征可以由其它Beans通过称为内观(introspection)的过程来检查。Beans以两种方式支持内观：
1．通过在命名Bean特征时遵守称为设计模式的特定
规则。Java．beans．Introspector类检查Beans中的这些设
计模式，以发现Bean特征，Introspector类依赖核心映象API(core reflection API)。
2．通过显式地提供特性、过程和事件信息以相关的Bean信息类。Bean信息类实现BeanInfo接口。BeanInfo类显式地列举要向应用程序编制器工具暴露的那些Bean特征。
特性是能在设计时改变的Bean的外观和行为特点。编制器工具在Bean上内观，以发现其特性，并暴露那些供操纵的特性。
Beans暴露特性，以便能在设计时定制特性。定制是以两种方式支持的：通过使用特性编辑器，或者通过使用更复杂的Bean定制器。Beans用事件与其它Beans通信。想要接收事件的Bean(听者Bean)向发生事件的Bean(源Bean)登记其兴趣。编制器工具能检查Bean，确定该Bean能发生(发送)哪些事件，能处理(接收)哪些。
持久性(persistence)使Beans能保存和恢复它们的状态。一旦你改变了Bean的特性，你就能保存该Bean的状态，在以后恢复该Bean一特性变化原封不动。JavaBeans用Java对象序列化来支持持久性。
Bean的过程与Java过程并无不同，能被从其它Beans或者描述(scripting)环境调用。
尽管Beans是为能被编制器工具理解而设计的，所有重要的API，包括对事件、特性和持久性的支持，也都被设计得能被人类程序员读懂。
Introspector类为工具理解目标Java Bean所支持的特性、事件和过程提供了一个标准方法。对于这三种信息的每一种，Introspector将单独地分析bean的类和超类，搜寻显式的或隐式的信息，并用该信息来编制综合地描述目标bean的BeanInfo对象。
用于翻译的内观编辑器
本实施例提供一种用类域值(class field values)来方便软件文本的翻译的方法。软件显示中的每个文本标签都作为类对象被存储。
在本实施例中，要在例如GUI按钮上显示的实际文本，不是硬编码的，而是存储在Java ResourceBundle本地化文件中。现在参考图5，该图表示的是用Java资源束来显示按钮标签的例子。图中显示，窗口500有GUI按钮510和530。注意到这个窗口对应于图2的窗口200。不过，这里的按钮510是用一个引用ResourceBundle的Java JButton调用520创建的。
本例中，命令“JButton(res．getString(“OK”))”520创建一个GUI按钮，并通过在资源文件中查找应当对应于“OK”按钮的文本来标记它。Java资源文件集体地被表示为550，英语引用文件被表示为560。在文件560中，登记项580指示，对应于“OK”按钮的文本是“Ok”。因此，命令520创建一个文本为“Ok”的GUI按钮。注意到在本例中，为清楚起见，按钮名以大写显示，按钮文本标签以大小写混合的字母表示。
类似地，命令“JButton(res．getString(“CANCEL”))”540创建一个GUI按钮，并通过在资源文件中查找应当对应于“CANCEL”按钮的文本来标记它。在文件560中，登记项570指示，对应于“CANCEL”按钮的文本是“Cancel”。因此，命令540创建一个文本为“Cancel”的GUI按钮530。当然，资源文件560中实际的对应文本可以是任何文字；登记项570可以是{“CANCEL”，“Stop”}，这就会导致每次执行命令540时要创建一个标签为“Stop”的按钮。当然，这种方法不限于GUI按钮，而是可以用来从本地化资源文件查找任何可显示的文本。
由于资源文件存储着要作为Java对象显示的文本，所以Java环境的内观特性能被用来让翻译者用弹出式编辑器直接编辑应用程序文本。
当弹出式编辑器启动时，向目标对象进行getText调用，向编辑器返回当前的文本。向翻译者显示该文本，翻译者然后就可以编辑它。翻译／编辑完成之后，用setText将新文本存储在对象中。
最后，将带有新文本的对象存储回Java ResourceBundle文件中。之后，就能用修改后的对象来执行软件应用程序，然后将在显示器上显示翻译的文本。
现在参看图6，应当注意的是，本实施例中的内观编辑器610是与正被翻译的应用程序650独立的软件程序。编辑器610含有内观应用程序设计接口(API)620、编辑器GUI 630和文件I／O系统620的代码。目标应用程序650存储Java资源文件中含有待翻译文本串的UI对象660。
本实施例中，翻译者同时运行目标应用程序650和内观编辑器610。当使用弹出式编辑器时，内观编辑器检索或存储来自目标应用程序650的对象。
Java包装API
另一种实现能完成与以上所述的相同的上下文翻译结果，但是使用Java UI类的“包装”类。Java包装类能让程序员将一个Java组件“包装”(wrap)成新的组件一新组件具有原始组件的所有属性，加上一个或多个新的或扩展的属性。
本实施例扩展诸如JButton的Java Swing组件，在实例时象中存储资源束名属性和关键字名属性。扩展的组件实现具有这些属性的构造器和get／set(取得／设置)过程。那些属性能在那些组件上的弹出式对话框中显示，用户能在运行时编辑标签。在弹出式对话框中所作的改动，直接反映到应用程序UI组件并在记录文件中保存。
在大型应用程序中，同样的文本(诸如“Save”)可能会在若干资源文件中都定义，不同的对话框可能会使用同一个标签的不同的资源文件。
如果翻译者发现一例如标签“Save”在给定的对话框中必须用另一个词(诸如“Store”)替换，但其它对话框中则依然保留“Save”，翻译者就必须知道实际上被用来显示该标签的是哪个资源文件。翻译者一般能使用资源文件，但不能使用其中提供了GUI组件与资源文件的关联关系的程序资源。翻译者被迫猜测哪个资源文件正在使用一这是一个非常低效、费时和易出错误的步骤。
本实施例提供的一种方法，能让翻译者知道哪个资源文件和哪个关键字用于特定的GUI标签。为此，必须用Java包装类将资源文件名和关键字名添加到GUI组件的实例以及标签本身。这个信息一旦在GUI组件中存储，工具就能向翻译者显示要被编辑的资源名和关键字，或者，工具甚至能用工具所提供的编辑器界面来为翻译者编辑资源文件。
包装以两种方式来扩展Java类。方式之一是增加两个串属性，以存储资源文件名和关键字；另一个方式是提供构造器和过程，以设置／取得这些属性。包装的构造器和过程与父类的那些是非常类似的。
“setText／getText”用来设置和取得基于文本的组件的标签，它总是一个文本项。即使程序写setText(getKey(…))，标签也只是解析的文本(resolved text)，而不含资源文件名和关键字。
采用Java包装类的本实施例，比上述只依赖getText／setText过程的实施例多两个优点：
1．包装能存储资源文件名和关键字，而setText只存储标签。
2．包装的构造器不仅设置标签，也设置资源文件名和关键字。如果没有包装，每当实例化带标签的GUI组件时，开发者就需要调用另一个过程来设置它们，这个步骤在开发中常常被忽视。
如图7中所示，本实施例扩展Java基础类的文本组件一诸如JButton 710、JLabel 720、JCheckBox 730和JMenu 740，生成对应的组件TButton 712、TLabel 722、TCheckBox 732和TMenu 742。当然，也能类似地扩展Java Foundation类的其它组件。各新组件为各组件添加了资源束名(res)和关键字(key)的get／set过程。
现在参看图8，图中显示了对“JButton”类的组件扩展的更详细的示意图。该图中，用Java包装API将JButton类810扩展到TButton类820。TButton类具有与原始JButton类的相同的“标签”属性830，但是增加了资源束名(res)的属性840和关键字的属性850。这些属性便于翻译者能按照关键字来直接提出和编辑每个JButton的标签属性。
采用这个方法，翻译者就能在运行时提出那些组件上的弹出式菜单并直接编辑／翻译标签。对标签的改动，按照类和关键字在记录文件中保存，并且也立即在GUI显示上变化。之后，当软件应用程序遇到这个类和关键字时，被编辑／被翻译的文本就被显示。
应当注意，与上述的内观工具不同的是，本实施例使用包装类，它是正被翻译的软件应用程序的一部分。如果待译的软件应用程序不支持扩展的包装类，这个方法就无效。
外观
最佳实施例能通过创建“外观”类，将每个组件的翻译信息附加到JComponent。在本实施例中，将存取过程和编辑器用户界面逻辑集中于一个“外观”类中，而不是将它们置于各自的包装类中。
应用程序通过这个外观类设置Java UI组件的资源束名和关键字名。这些属性能在这些组件上的弹出式对话框中显示，用户能实时地编辑标签。在弹出式对话框中所作的改动，直接反映到应用程序的UI组件并在记录文件中保存。
这个方法与上述包装方法(wrappcring approach)解决的是同一个问题。这个方法与包装方法相比的优点是：
(1)包装方法中的子类有维护开销(新的和更新过的JComponents要求对导出组件的集合的改动)，
(2)包装招致开发开销，因为要求设计者要么只从可用子类的集合中选择，要么就实现它们自己的，
(3)包装也招致运行时开销，这是因为，必须将编辑器属性编制到每个组件中，
(4)包装实施例中所用的setName()要把所有翻译属性组合成组件的“name”属性，而基于特性的方法(properties-basedapproach)则允许直接访问每个翻译属性，可扩展性更充分(例如对于工具提示文本翻译属性来说)，并且让组件的“name”属性可用于其它用途。
这个实施例提供类“NLSUtility”，它是JFC文本组件(JButton、JLabel、JCheckBox、JRadioButton)的外观，并且实现资源束名和关键字的get／set(获取／设置)过程。这些属性被存储在有存取关键字的clientProperty散列表中。用户能在运行时提出那些组件上的弹出式菜单并编辑标签。对标签的改动，在记录文件中保存，
图9表示按照这个外观类的实施例的框图。这里，外观类900起着JFC文本组件910、920、930、940(以及未予显示的其它部分)的前端的作用，将每个组件与一个客户特性属性相关联。然后，通过使用putClientProperty()950和getClientProperty()960，就能用外观类来读取和编辑潜在的JFC基础类的特性属性。通过使用外观类，能取得与上述包装实施例的相同的结果，但是编辑器功能的开销是嵌入外观类中的，而不是嵌入每个个别组件中的。
值得注意的是，尽管在功能完整的数据处理系统和／和网络的上下文中说明了本发明，本领域的技术人员知道，本发明的机理能以计算机可用的、含有各种形式的指令的媒体的形式传播，不管用来进行实际传播的信号载体的特定类型如何，本发明同样适用。计算机可用的媒体的例子包括：非易失的、硬编码类型的媒体一诸如只读存储器(ROM)或电可擦可编程只读存储器(EEPROM)，可记录类型的媒体-诸如软盘、硬盘驱动器和CD-ROM，传输类型的媒体一诸如数字和模拟通信线路。
尽管结合若干最佳实施例具体表示和说明了本发明，本领域的熟练人员会明白，在其中可以作出各种形式和内容上的改动而不偏离本发明的精神和范围。此外，应当明白，尽管讨论了特定的数据结构、功能和语言，在不偏离本发明的精神和范围的情况下，可以容易地将所披露的技术改编得适合其它程序设计环境。