国际化3

跳转到主要内容

• 登录 (或注册)
• 中文
• [userid]
• 

这是您第一次登陆到 developerWorks，已经自动为您创建了您的概要文件。 选择您概要文件中可以公开的信息的信息（如姓名、国家/地区，以及公司），这些信息同时也会与您所发布的内容相关联。您可以随时更新您的 IBM 账号。

所有提交的信息确保安全。

• 

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

 

昵称：

单击提交则表示您同意developerWorks 的条款和条件。查看条款和条件.

所有提交的信息确保安全。

• 

My developerWorks:

• 我的首页
• 我的概要信息
• 我的社区
• 设置

我的通知：

• {[num_notify] 个新通知}([num_notify] 个新通知)
• {[num_invite] 个网络请求}([num_invite] 个网络请求)

• 退出

• 

选择语言：

• English
• 中文
• 日本語
• Русский

• Português (Brasil)
• Español
• Việt

• 

• IBM 主页
• 解决方案
• 软件

• 支持门户
• 产品文档
• Redbooks（英文）

• 

• 

• 技术主题
• 软件下载
• 社区
• 技术讲座

技术主题

• Agile transformation
• AIX and UNIX
• Big data
• Cloud computing

• IBM i
• Information management
• Java technology
• Linux

• Lotus
• Mobile development
• Open source
• Rational

  软件下载

  • Information management
  • Lotus
  • Rational

  • Tivoli
  • WebSphere

  • 

  社区

  • 我的首页
  • 概要信息
  • 群组
  • 博客

  • 论坛
  • Wiki
  • 活动

  • 

  技术讲座

  • 技术讲座
  • 多媒体课堂
  • 网络广播（英文）
  • 查找活动（技术讲座，网络广播，会议等）（英文）

  • 

• developerWorks 中国
• Linux
• 文档库

开放源码项目: 国际化 Eclipse 插件

如何编写适合国际市场的 Eclipse 插件

Dan Kehn, Eclipse ISV 启用小组, EMC

Dan Kehn 是美国北卡罗莱纳州 Research Triangle Park 的 IBM 高级软件工程师。他对面向对象编程的兴趣要追溯到 1985 年，当时这种技术还不象现在这样广为接受。他拥有广泛的软件经验，从事过开发工具（如 VisualAge for Smalltalk）、操作系统性能和内存分析和用户界面设计。Dan 作为面向对象开发项目的顾问走遍了美国，并且还在欧洲工作过四年。他最近的兴趣包括面向对象分析／设计、编程工具，以及使用 WebSphere Application Server 进行 Web 编程。去年，他加入了 Eclipse Jumpstart 小组，这个小组的主要目标是帮助 ISV 创建基于 Eclipse Platform 的商业产品。在其余时间，Dan 撰写了关于几篇关于各种 Smalltalk 主题的文章，如元编程、团队开发和内存分析。可以在Eye on SmallTalk 上找到这些文章。

Scott Fairbrother, Eclipse ISV 启用小组, EMC

Scott Fairbrother在美国北卡罗莱纳州 Research Triangle Park 的 IBM Eclipse Jumpstart 小组工作。他是一位拥有 20 多年经验的软件开发人员。他开发过面向对象的业务过程管理应用程序框架。他为 Windows 2000 上的 IBM 中间件编写了规范，还撰写了关于 Microsoft Visual Studio .NET 的文章。

Cam-Thu Le, Eclipse ISV 启用小组, EMC

Cam-Thu Le在 1983 年加入 IBM。Cam 的经验跨越了软件创建的许多方面：开发、测试以及本地语言支持（NLS）规划和协调。Cam 使 IBM 产品的本地语言版本可以全球同步上市，包括 4690 Point of Sales 产品和 VisualAge for Smalltalk。Cam 去年加入了 Eclipse Project，作为 NLS 联络人。Cam 协调 Eclipse Workbench 和 WebSphere Studio Workbench 本地语言版本的构建和测试。

简介： 本文是为编写进入国际市场的 Eclipse 插件而准备的路线图。首先，我们将简短回顾国际化的动机和技术问题，然后逐步说明国际化插件的步骤。最后，我们将说明如何将这些步骤应用到 Eclipse Platform 本身的国际化过程中。

发布日期： 2002 年 6 月 01 日
级别： 初级
访问情况 ： 7179 次浏览
评论： 0 (查看 | 添加评论 - 登录)

平均分 (6个评分)
为本文评分

在国际化社区中，有一个流传了很久的笑话：

“会说三种语言的人称为“三语人”。会说两种语言的人称为“双语人”。那么把只会说一种语言的人称为什么呢？”

“美国人。”

现在，从可用性、质量、市场营销和（在某些情况下）法律的观点来看，只提供英语版本的软件已不再受欢迎了。让您的产品能够用于国际市场只是为了增加经济效益。这个启用过程比较简单，就象本文所呈现的一样。

在开始之前，要谈几点注意事项。由于 Eclipse Platform 采用了 Java SDK 提供的国际化实现，因此在继续阅读本文之前先阅读 Java Tutorial: Internationalization 系列会有所帮助。该教程很好地概述了过程中涉及的问题和步骤。我们将假设您已经阅读了该教程，因此我们可以在本文中着重说明要点，阐述其它值得注意的事项并涵盖 Eclipse 特定的问题和步骤。当遇到本文中不熟悉的术语或缩略语时，请立即查阅词汇表。

国际化概述

国际化是创建适合于国际市场的软件的过程。除了经济利益之外，某些国家或地区要求产品在进入其市场之前通过政府设置的某些本地化要求。

国际化 Eclipse Platform 的过程分两步完成：

1. NLS 启用的产品。
   这一步涵盖了编码技术和用户界面设计问题。启用产品的本地语言支持（National Language Support (NLS)）确保了产品是为本地语言功能设计的，并且产品使用适当的 API 来处理本地语言数据。在这一步骤中，必须权衡并考虑智能编码的做法（如避免硬编码字符串、使输入缓冲区足够大可以容纳可翻译的文本、正确地解析包含非拉丁字符的字符串、不对作为文件格式一部分保存的字符串进行本地化，以及从程序代码中分离本地语言元素），这样投入最小的费用和精力就可以完成翻译。
   
2. 翻译产品。
   这一步涉及到将本国语言元素翻译成外语。如同单词和短语一样，图片和符号在各种文化背景下也有不同的解释。在翻译验证步骤期间，要复查所有翻译以确保上下文正确性，要修改图标或剪贴画以确保不会造成用户误解，还要检查页面布局以避免无意的文本截断。当在翻译之后验证产品的功能完整性时，这个步骤还会寻找隐含的文化冲突。
   

---

回页首

国际化影响什么？

只熟悉单一语言的人注意事项：这是灵敏度训练的开始。本文结尾处可能还会有测验。:-)

让我们从 Java 国际化教程（请参阅本文后面的 参考资料）中提供的与文化相关的数据列表摘录入手，该列表已根据一般开发人员遇到的可能性进行了重新排序，而且每项后面还附带了详细信息：

1. 文本
   GUI 组件上的消息、标签
   联机帮助（*.html），插件清单（plugin.xml）
   
2. 数据格式
   数字、日期、时间、货币
   电话号码、邮递地址
   
3. 地区和个人称谓
   度量衡
   尊称和个人头衔
   
4. 多媒体考虑事项

文本

消息、GUI 组件上的标签
资源束很好地处理了与语言有关的文本。其策略是将所有字符串一次装入 ResourceBundle 子类，或者单独检索它们。Eclipse Java 开发工具（Java Development Tooling (JDT)）版本 2.0 提供了支持检测可翻译字符串的向导。我们马上将在国际化步骤中讲到它们。

将已翻译的字符串装入内存只是第一步。下一步是将它们传递给用于显示的适当的控件（如标签、文本域、菜单选项等）。页面设计人员和程序员必须合作以确保所选布局允许适当地重新调整对话框大小和重新布局对话框。标准小窗口工具箱（Standard Widget Toolkit (SWT)）库中的布局支持极大程度依赖于程序员指定对域大小做出适当反应的布局描述才能“正确行事”。eclipse.org 网站上的文章“Understanding Layout in SWT”（请参阅参考资料）详细地讨论了实现问题。

由于在翻译期间文本长度会增加，因此这特别重要。英语短语通常比其意义相同的译文短，通常短 40% 左右。为了适应本地语言，可能还需要修改字体大小。

联机帮助（*.html），插件清单（plugin.xml）
这些形式的文本内容比简单的面向键／值的特性文件涉及更多，因此它们的外向化步骤稍微复杂一些。

以清单文件为例，它与类似命名的特性文件 plugin.properties 配对，只包含外向化的文本。对于 plugin.xml 和 fragment.xml 之类的清单文件必须特别小心，因为标记的属性可能包含已翻译和未翻译文本。考虑以下这个良好的示例：

清单 1. 插件清单文件，翻译之前

   <plugin     name="Java Development Tools UI"     id="org.eclipse.jdt.ui"     version="2.0.0"     provider-name="Object Technology International, Inc."     class="org.eclipse.jdt.internal.ui.JavaPlugin"> 

这里，我们看到一个可翻译文本、不可翻译文本和“灰色区域”可翻译文本的混合体，它们都是标记属性。显然， id 和 class 属性是不可翻译的，因为它们表示编程标识。同样，可以肯定应该翻译name 属性。

您也许会考虑翻译 version 属性（由于与语言环境相关的十进制分隔符）或 provider 属性（由于与语言环境相关的法律属性“Inc.”），因为将向最终用户显示它们。但是，版本号通常是不翻译的，有两个原因：最终用户不关心数值的意义，程序员有时编写的代码希望版本号是类似于“3.5.4”的复合字符串。将版本信息存储成单独的数字（如主、次和服务更新）以避免需要解析版本字符串，这大概是一个更好的设计决策，但这个讨论已经超出了本文的范围。

provider-name 也不翻译，因为“Inc.”具有法律意义，因而难以精确翻译。在标识了需要外向化哪些文本之后，现在示例如下所示：

清单 2. 插件清单文件，翻译之后

  <plugin    name="%plugin.name"    id="org.eclipse.jdt.ui"    version="2.0.0"    provider-name="Object Technology International, Inc."    class="org.eclipse.jdt.internal.ui.JavaPlugin"> 

其中 plugin.properties 包含了外向化的字符串，即与键 plugin.name 相关联的“Java Development Tools UI”。

这个简单示例演示了翻译不只是为文本提供意义相同的单词或短语；它还涉及到理解本地文化考虑事项和潜在的法律冲突。这就是为什么需要专职翻译人员以及翻译验证测试。

数据格式

数字、日期、时间、货币
Java 库包括可以处理数字（十进制分隔符、千分位分隔符、集合）、日期（MDY、DMY、工作周的第一天）、时间（12 或 24 小时制、分隔符）和货币（当地货币符号、作为后缀还是前缀、有无前导分隔符）的必需格式的一些类。

电话号码、邮递地址
这些都是更细微且不常见的文本翻译问题，却仍然值得注意。许多应用程序只允许自由格式的电话号码项，因为各地的差异实在太多。邮递地址比较简单：添加“省／直辖市（State/Province）”字段并考虑到多个地址行通常就行了。

地区和个人称谓

尊称和个人头衔
虽然在美国不常用，但适当使用尊称（先生、太太、博士）仍被看作是绝对必要的，以免失礼。

度量衡
这些不常见到。这涉及到用相应的换算来替换度量表示（例如，英里与公里）。在许多情况下，用户需要同时以不同的单位或者以它们之间一种简便的换算方法显示一项度量。

多媒体考虑事项

通常，产品应该选择与地域无关的声音、颜色、图形和图标。

这意味着 Homer Simpson 的“D'oh!”声音与错误消息没有关系。如果您认为不会有大的开发组织会做这样的事，那么就看看下面这个典型的被提议和拒绝的图标：

开发人员要使用 66 号公路（一条从芝加哥到洛衫矶，横穿美国的国道）的符号来比喻“IP 路由器”。大多数美国人都会明白这个隐喻；想想这给倒霉的非美国用户造成的混淆。

同样，下面的图像对于许多北美用户也许很直观：

但在识别性调查中，美国以外的其他用户都猜这是个鸟房。以下是一个更广为接受的邮件图像：

要避免会产生混淆和可能令人不快的图像，最好的做法是聘请了解文化问题的专职图形艺术家。

---

回页首

国际化步骤

现在，让我们着手国际化 Eclipse 插件的实际步骤：

1. 将可翻译字符串移到 *.properties 文件中
2. 分离与表示相关的参数
3. 使用正确的语言环境敏感的数据格式、替代 API
4. 以本国语言进行测试
5. 创建初始已翻译插件片段
6. 准备和发送本国语言材料以供翻译
7. 重新封装和验证已翻译的材料
8. 部署各个片段

我们将详细讨论每一步。

第 1 步：将可翻译字符串移到 *.properties 文件中

幸好，Eclipse 的 Java 开发工具为正确地分隔可翻译字符串提供了很多帮助。包上下文菜单中的 Find Strings to Externalize 选项显示了Externalize Strings向导。这个向导将引导您完成一系列步骤，以便寻找代码中的硬编码字符串、将它们分成可翻译或不可翻译，然后在适当的情况下修改代码以使用资源束。

在使用该向导之 前，我们通过一个标准的“Hello World”来介绍 Externalize Strings向导：

清单 3. Hello world，翻译之前

  package com.jumpstart.nls.example.helloworld;  public class HelloWorld {     static public void main(String[] args) {       System.out.println("Copyright (c) IBM Corp. 2002.");       System.out.println("Hello.");       System.out.println("How are you?");       System.out.println("Goodbye.");   }}

从包上下文菜单中选择 Find Strings to Externalize 将显示一个选择对话框，其中显示了包中可能包含可翻译文本的所有编译单元。因为我们现在只有一个 Java 文件，因此从 HelloWorld.java 文件中直接选择Externalize Strings 比较简单。它会显示 Externalize Strings 向导：

图 1. Externalize Strings 向导

通过从表中选择一项，然后选择右边的一个按钮，可以将字符串标记成以下三种情况之一：

• Translate
  操作：将一项添加到特性文件中；自动生成的键和访问代码就代替代码中原来的字符串。已经用注释标记符（如“ // $NON-NLS-1$ ”）将用于指定键的字符串标记成不可翻译的
  
• Never Translate
  操作：用注释标记符将字符串标记成不可翻译的。 Externalize Strings向导在以后的操作中不会把它标志成未翻译的。
  
• Skip
  操作：不做修改。 Externalize Strings向导后面的操作会将字符串标志成可能可以翻译。

注： // $NON-NLS-1$ 注释标记符中的尾数表示在一行中有几个字符串的情况下，哪个字符串无需翻译。例如：

x.foo("Date", "TOD", "Time"); // $NON-NLS-2$

这里，中间的参数被标志成无需 NLS。其它两个则被跳过。

回到我们的示例，请注意，在列表的下面汇总了每个类别的字符串总数。外向化字符串的键名称是根据字符串值自动生成的，但可以在表中直接对其重命名。此外，可以指定一个可选的前缀（在下面的示例中是S_ ）。

图 2. Externalize Strings 向导

提示：单击给定行的第一列中的图标将前进到下一个选项：Translate、Never Translate 或 Skip。

既然我们已经标识了哪些字符串是可翻译的，那么继续到下一步，选择如何对其外向化。这里是选择 Next之后显示的页面； Property file name和资源束取值方法 Class name被修改成包含比缺省值更特殊的值：

图 3. Externalize Strings 向导

资源束取值方法类将包含用于装入特性文件的代码，以及从文件中取出字符串的静态方法。向导会生成这个类，或者您可以指定自己现有的备用实现。在后一种情况下，您也许要取消选择Use default substitution choice，并指定用于检索外向化字符串的备用代码模式。如果取值方法类在包外部（例如，集中式资源束取值方法类），您可以有选择地对底层源代码指定Add [an] import declaration。

Externalize Strings向导使用了 JDT Refactoring 框架，这样下两个页面看起来就很熟悉。首先，会显示一列警告：

图 4. Externalize Strings 向导

最后，一一显示了建议的更改：

图 5. Externalize Strings 向导

选择了 Finish之后，向导会执行源代码修改、创建资源束取值方法类，并生成初始的特性文件。以下是标准资源束取值方法类的代码：

清单 4. 标准资源束取值方法类

  package com.jumpstart.nls.example.helloworld;  import java.util.MissingResourceException;  import java.util.ResourceBundle;  public class HelloWorldMessages {  private static final String BUNDLE_NAME =     "com.jumpstart.nls.example.helloworld.HelloWorld"; //$NON-NLS-1$  private static final ResourceBundle RESOURCE_BUNDLE =     ResourceBundle.getBundle(BUNDLE_NAME);  private HelloWorldMessages() {}  public static String getString(String key) {     try {         return RESOURCE_BUNDLE.getString(key);     } catch (MissingResourceException e) {         return '!' + key + '!';     }   }  }

该生成代码中的唯一变化是分配给 static final BUNDLE_NAME 的值。在继续下一步之前，以下是 JDT 小组的 Erich Gamma 和 Thomas Mäder 贡献的一些值得注意的准则。

管理资源束和特性文件的准则

这些准则的设计意图是：

• 减少 NLS 错误的数量，换句话说，在运行时找不到的外向化字符串的值
• 启用代码中引用的键和特性文件中定义的键之间的交叉引用
• 简化外向化字符串的管理。使用集中式特性文件可能导致频繁的更改冲突。此外，它要求使用前缀以使键成为唯一，并使键的管理变得复杂。

要实现这些目标，我们建议以下准则：

1. 每个包使用一个特性文件，按类名称来限定键

例如，JDT 搜索组件的所有字符串都在 SearchMessages.properties 中，其中键／值对如下：

SearchPage.expression.pattern=(? = any character, * = any string) ShowTypeHierarchyAction.selectionDialog.title=Show in Type Hierarchy

2. 使用专用静态资源束取值方法类

让 Externalize Strings 向导生成这个类。它应该与特性文件同名。因此在我们的示例中，它就叫作 SearchMessages。当需要创建格式化的字符串时，将便利方法添加到束取值方法类中。例如：

清单 5. 静态资源束取值方法类

     public static String getFormattedString(String key, Object arg) {          String format= null;          try {              format= RESOURCE_BUNDLE.getString(key);          } catch (MissingResourceException e) {              return "!" + key + "!";//$NON-NLS-2$ //$NON-NLS-1$          }          if (arg == null)              arg= ""; //$NON-NLS-1$          return MessageFormat.format(format, new Object[] { arg });      }     public static String getFormattedString (String key, String[] args) {          return MessageFormat.format(RESOURCE_BUNDLE.getString(key), args);      }

3. 不要使用经过计算的键

没有一种简便方法可以使代码中经过计算的键和特性文件中的键关联起来。尤其是要确定某个键是否不再使用时，这几乎不可能。

4. 键名称的约定是 <classname>.<qualifier>

示例：PackageExplorerPart.title

第 2 步：分离与显示相关的参数

并非所有的外向化文本都只是要翻译成目标语言的单词或短语。其中有些与您的插件实现密切相关。这些示例包括属性、首选项和缺省对话框设置。

这里有一些特殊示例，它们会用于特性文件中：

• 大小或布局约束。例如，不可调整大小的表列的适当宽度
• 取决于语言或操作系统的缺省字体。Latin-1 语言的有效缺省字体对于 DBCS 语言（请参阅 与字体相关的 .properties 文件以获取更多详细信息）是一个无效选项。

对于那些从 AbstractUIPlugin 中分类出来的插件，还可以在其 缺省首选项存储（pref_store.ini）和 对话框设置（dialog_settings.xml）中找到与本地语言相关的参数。Eclipse Workbench 本身并不使用缺省首选项存储，而是选择将缺省值存储到特性文件，然后通过 AbstractUIPlugin 的initializeDefaultPreferences(IPreferenceStore) 方法初始化它们。

第 3 步：使用正确的语言环境敏感的数据格式、替代 API

请参考 Java Tutorial: Internationalization系列中的详细介绍。

第 4 步：以本国语言进行测试

测试是否可以翻译产品是很重要的，但已超出了本文的范围。但是，以后的文章（“测试国际化的 Eclipse 插件”）将提供验证产品的本地语言敏感问题的策略。

第 5 步：创建初始已翻译插件片段

现在，我们可以只把本国语言特性文件复制到同名且带有特定语言环境后缀的文件中（例如，MyMessages_xx.properties，其中 xx 是语言），然后前进到第 6 步，准备和发送本国语言材料以供翻译。在这种情况下，产品是与其代码以及它支持的任何语言都作为一个安装交付的。

但是，这种方法有一些缺点。首先，代码及其本地语言资源都混杂在同一个目录／JAR 文件中。如果翻译比代码交付晚，那么必须更新插件 JAR 文件，尽管底层代码并没有更改。其次，除特性文件之外的其它文件（例如，HTML、XML、图像）本质上并不对语言环境敏感，因此必须将它们分离到每种语言的单独目录中。

为了解决这些问题，Eclipse Platform 引入了另一个与插件相对应的可重用组件的概念，叫作 插件片段。插件片段向其目标插件提供了附加功能。在运行时，这些插件组成部分与所有相关的片段合并在一起。这些组成部分可以包括代码组成部分和与插件相关的资源组成部分，如特性文件和 HTML 文件。换句话说，插件通过其类装入器访问片段的内容。

如何以及为什么使用片段来提供可翻译信息

插件片段是分发已翻译 Eclipse 信息（包括 HTML、XML、INI 和位图文件）的理想方式。由于以非入侵方式交付翻译，所以将 Eclipse Platform 翻译封装到片段 JAR 文件中，然后将其添加到现有 Eclipse 安装中不会更改或修改任何原始的运行时元素。这就引出了语言包（language pack）的概念。

Eclipse Platform 以用片段中的运行时元素增补原始目标插件的方法来合并插件片段。这不会以任何方式移动、除去或修改目标插件。由于类装入器会寻找片段的资源，所以插件开发人员无需知道是从插件的 JAR 文件还是其片段的某个 JAR 文件装入资源。

Eclipse 语言包 JAR

Java 语言带有资源束功能，因此支持语言包的概念。Java 资源束不要求修改应用程序代码来支持另一种语言。*.properties 文件名称空间通过以下命名约定避免冲突：basename_lang_region_variant。在运行时， ResourceBundle 功能会针对当前语言环境寻找适当的特性文件。

在片段中部署文件（如 HTML 和 XML 文件）与在 Java 资源束中部署文件略有不同，因为 Eclipse 片段使用目录结构来区分不同的语言版本。

示例片段内容
插件和插件片段位于可以在 eclipse 子目录下直接找到的单独子目录中。考虑一下我们的示例片段，它部署在德语系统上，我们会看到一个 \nl 文件夹、一个 fragment.xml 和一个 nl1.jar 文件。

图 6. 片段子目录

通常，会根据资源束规则给已翻译的 *.properties 文件添加后缀，并将它们部署到 JAR 文件中。可是，当一个视图需要一种输入文件类型，而文件名称不象资源束一样是语言环境敏感的（如 *.xml），我们就要为文件的每一个语言版本定义一个子目录结构。上面的 de 子目录就是这样一个示例，其中 de = 德语。

片段清单
每个插件文件夹都可以随意地包含一个片段清单文件 fragment.xml。清单文件描述了插件片段，而且与插件清单文件（plugin.xml）几乎相同，只有以下两点除外：

• 没有 class 属性，因为片段没有插件类。它们只遵循其目标的规范。
• 没有相关性，因为片段具有与其目标插件一样的相关性。

用于描述本地语言片段的清单通常很简单，只需指定 <fragment> 和 <runtime>/<library> 标记。以下是完整的示例片段清单文件：

清单 6. 片段清单文件

<?xml version="1.0" encoding="UTF-8"?><fragment   id="com.jumpstart.nls.example.helloworld.nl1"   name="NLS Example Plugin NL Support"   version="1.0.0"   provider-name="IBM"   plugin-id="com.jumpstart.nls.example"   plugin-version="1.0.0"><runtime>   <library name="nl1.jar"/>   <library name="$nl$/"/></runtime></fragment>

<fragment> 标记属性是：

• name ― 可向用户显示的扩展名称。
• id ― 该片段配置的标识。用于唯一标识该片段实例。
• plugin-id ― 对目标扩展点的引用。插件片段与此目标扩展合并。
• plugin-version ― 片段插件的版本。
• version ― major.minor.service 格式的版本规范。

<runtime> 部分包含了组成插件片段运行时的一个或多个库的定义。被引用的库由平台执行机制使用，在此机制中，插件装入、合并和执行它所需的正确代码。每个<library> 子标记都有一个 name 属性。它指定了库文件或目录导出掩码。要将文件夹及其子文件夹的内容包括在库中，可以使用掩码$foldername$/ ，其中 foldername 是要添加到库搜索路径的目录。我们以后会了解到如何使用这个掩码来包括 \nl 文件夹的内容及其子文件夹的内容。

构建片段
Eclipse Workbench 附带了一个在插件开发中使用的工具： 插件开发环境（Plug-in Development Environment (PDE)）。PDE 包含了对开发插件片段的支持。

现在，让我们研究如何使用 PDE 构建用于本地语言翻译的片段。在给定片段中，对语言的数量没有实际的限制。那么片段就是包含一种或多种语言翻译的“语言包”的基础。但是，在这个示例中，我们将语言包限定为德语翻译。

要构建插件片段，启动 New Project 向导（ File> New> Project...），选择 Plug-in Development类别，然后选择 Fragment Project 类型。在 New Fragment 向导的第一页，输入项目名称。请记住，项目名称也将变成片段标识。例如，启动一个向 HelloWorld 示例添加本地语言支持的项目，我们将项目命名成“com.jumpstart.nls.example.helloworld.nl1”。结尾“.nl1”并不是必需的，但确实有助于区分表示“语言包”的片段和添加附加代码和功能的片段。

图 7. 启动片段项目

按 Next。在第二页上，会看到项目的源文件夹和运行时库的缺省值：

图 8. 定义片段文件夹

这些值看上去还算合理，所以再按 Next，就转到了“Fragment Code Generators”页面。选择第二个单选按钮，表示我们要从模板创建片段清单文件，然后从列表中选择Default Fragment Generator向导。

图 9. 选择缺省向导

按了 Next 之后，我们会看到“Simple Fragment Content”页面。这个页面上有两项用于指定某个现有插件上的片段。必须提供插件目标标识和版本。可以使用Browse按钮来选择要展开的插件。

图 10. 为片段指定目标

现在，让我们进入片段清单编辑器，它与插件清单编辑器一样都是多页面编辑器，带有 Overview、Runtime、Extensions、Extension Points 和 Source 页面。

图 11. 片段清单编辑器

请注意与片段 xml 文件的各个节对应的选项卡页面。我们将使用 Runtime 页面将片段类路径指向包含我们的翻译的库。

我们在新建片段向导中指定了 nl1.jar，因此这个片段的类路径已经包含了那个库。此时缺少的东西就是包含在 \nl 文件夹及其子文件夹的内容。要添加新的运行时库，可以从 Overview 页面的 Runtime Libraries 节中选择More，或者转到 Runtime 页面，选择 New...，然后输入文件夹掩码 $ foldername$/。

图 12. 片段运行时信息

看一看片段清单编辑器的 Source 页面，我们会见到 PDE 生成所有描述插件片段所必需的 XML。

图 13. 片段源码

第 6 步：准备和发送本国语言材料以供翻译

准确的翻译需要专门技能，而您必须为此付钱。（虽然您在高中里学了四年德语课，可惜还不合格！）有许多公司都乐意提供具有专业水准的翻译。

对于 Eclipse Platform，这一步分两个阶段完成。第一阶段涉及将所有外向化的文本发送到翻译中心。第一遍翻译是在“脱离环境”的情况下完成的。翻译人员没有看到运行中的产品，也没有特定的产品经验。他们拥有的工具有助于提高翻译速度和保证一致性，但最终还要依赖翻译测试人员来验证以目标语言运行的的产品（第二阶段）。

即将发表的文章（“测试国际化的 Eclipse 插件”）中将讨论脱离环境的翻译带来的风险和后果，其结果有时非常好笑。

第 7 步：重新封装和验证已翻译的材料

翻译了文件之后，我们将它们重新组合到相应的目录／JAR 文件中，这些目录／JAR 文件已在第 5 步 创建初始已翻译插件片段中描述过了。NL1 Fragment 文件夹包含了各种语言版本的 plugin.properties 文件。在将 HelloWorld.properties 文件翻译成德语之后，我们将它重命名成 HelloWorld_de.properties，并将它存储到 NL1 Fragment 源文件夹中。注：nl\de（德语）文件夹是新的，它并不是由 PDE 创建的，而是手工创建的。当我们不断添加各种翻译时，这些特定语言的文件夹隔离了各个版本的非特性文件（如下面显示的 hello.xml）。

图 14. 重新组装的片段项目

请注意已翻译的特性文件很可能包含与代码页相关的重音字符，因此必须将特性文件转换成 PropertyResourceBundle 类所希望的 ISO 8859-1 代码页。native2ascii 实用程序（请参阅 参考资料）会处理代码页转换并插入任何必需的 Unicode 转义符（Unicode escape）。

需要详细说明一下术语 Unicode 转义符。Java SDK 包含的 native2ascii 转换实用程序允许进行源码编码，生成以 ISO 8859-1 编码的输出，并且它将此代码页之外的字符转换成叫作 Unicode 转义符的表示法。这种表示法是 \udddd，其中 dddd = Unicode 代码页中期望字符的代码点。

下面是一个示例。考虑一下法语短语“Son père est allé&#160à l'hôtel”（他父亲去旅馆了）。它包含了四个不属于 Latin-1 代码页的重音字符。用 native2ascii 实用程序转换这条短语会得到：

Son p\u00e8re est all\u00e9 \u00e0 h\u00f4tel

现在不再有任何重音字符，而且组成字符串的所有字符所拥有的代码点都可以在 ISO 8858-1 中找到。但替代用的 \u00e8 、\u00e9 、 \u00e0 和 \u00f4 是什么呢？它们是以 \udddd 表示的重音字符的 Unicode 代码点。

关于使用 native2ascii 实用程序，有一个小的告诫：它假设源码编码与执行它的机器的活动代码页相同。但是，翻译人员通常会用其缺省国家或地区代码页保存翻译，而在每个国家或地区以及每个操作系统中，这个代码页是不同的。因此，负责集成翻译的人需要 (a) 知道翻译人员用哪种代码页保存文件，或者 (b) 要求他们用公共代码页保存文件。当调用 native2ascii 时，可以用指定-encoding 参数指定源代码编码。

提示：如果不能确定源码代码页，可以对照本文后面的 表 3. 常见重音拉丁字符的 Unicode 代码点来抽查 native2ascii 的输出。如果在转换的文件中找到该表中没有的 \udddd 表示法（如 \u0205），那可能是您指定了错误的源码编码。DBCS 语言中没有同样的抽查，实际上已转换文件中的所有字符都是 Unicode 转义符。只要仔细一点，对照正在运行的产品进行验证。

会有一篇专门的文章介绍测试翻译。请等待后续文章（“测试国际化的 Eclipse 插件”），这篇文章将描述在最近的 Eclipse Platform 翻译验证期间学到的经验教训，而且会讨论执行特性文件翻译的快速检查（当然，是 Eclipse 插件）。

第 8 步：部署各个片段

片段源代码与插件源代码相似，也可以封装在 JAR 文件中。使用 PDE 生成 JAR 包，选择“fragment.xml”文件，并从弹出菜单中选择“ Create Fragment JARs...”。向导会指导您创建一个构建脚本以便为片段生成所有必需的 JAR。

图 15. 选择 fragment.xml 文件

要部署这个示例片段，将 fragment.xml、\nl 目录和 JAR 复制到插件目录的 com.jumpstart.example.helloworld.nl1 子目录中。这样就完成了我们的示例以及国际化的步骤。下一节将具体介绍 Eclipse Platform 的可翻译元素、如何组织它们，以及引入另一种语言需要什么。

---

回页首

Eclipse Platform（V 1.0）的国际化

本节的重点不是 Eclipse 国际化的“详细指导”，而是回顾版本 1.0 实现及其与翻译相关的构建过程。在这些主题中，有一些是专门针对平台自身的，它们描述的过程与那些只希望用本地语言启用平台的插件的开发人员无关。本节针对的读者是那些希望了解如何使平台支持本地语言并且要浏览许多构成已翻译产品的文件、子目录和 JAR 的人。

Eclipse Platform 已经实现了国际化，它拥有输入双字节字符和支持双向数据的能力。它提供了以下语言版本：

• 巴西葡萄牙语
• 法语
• 德语
• 意大利语
• 日语
• 韩国语
• 简体中文
• 西班牙语
• 繁体中文

在 IBM，把这些语言统称为 第一集团语言。

已翻译的各种元素是什么，在哪里？

Eclipse Platform 依赖于 Java SDK 中提供的国际化框架。因此，大多数可翻译文本位于 *.properties 文件中。但还有其它文件格式包括可翻译信息，如 HTML、XML 和位图（已在表 2. Eclipse 特有的（非 Java）可翻译资源中概述）。

翻译是一门艺术，需要均衡时间、精力和成本。它考虑到开发产品的速度以及产品投入市场的速度。关于 必须翻译什么以及翻译成什么 好，始终都有分析和协调决策。

简而言之，Eclipse 将其翻译集中到三个主要领域：

• 插件
• 联机帮助
• 欢迎视图

涉及的文件有：

• *.properties 文件
• *.html 文件及其相关的“支持”文件
• welcome.xml 文件

Eclipse 插件：.properties 文件

在 Eclipse 中，每个产品插件都包含特性文件。翻译插件就意味着翻译其特性文件。处理特性文件有两个主要步骤：

与字体相关的 .properties 文件
每个操作系统都使用不同的字体集，某些语言有其自己的字体集（最显著的就是 DBCS 语言）。操作系统推荐缺省字体，但页面设计人员的最佳布局却依赖于特殊字体，因此使用缺省值字体的结果可能会产生格式很差的页面。为了确保正确显示已翻译的文本，Eclipse Workbench 使用特殊的与每种语言／操作系统组合一致的字体集。

注：只有那些正在添加新操作系统或语言的支持的 Eclipse Platform 开发人员才需要创建新的 jfacefonts* 特性文件。切勿修改另一个插件的子目录的内容，包括 Eclipse Platform 附带的 JFace 特性文件中指定的字体。

各种 Eclipse 字体都在 JFace 插件中定义。可以在以下位置找到缺省 Eclipse fonts.properties 文件：

缺省 Eclipse fonts.properties 文件的位置

eclipse\plugins\org.eclipse.ui\workbench.jar    org\eclipse\jface\text\JFaceTextMessages.properties    org\eclipse\jface\resources\jfacefonts.properties （OS 缺省值）    org\eclipse\jface\resources\jfacefonts_linux.properties    org\eclipse\jface\resources\jfacefonts_windows2000.properties    org\eclipse\jface\resources\jfacefonts_windowsnt.properties

每种语言都有四个 org.eclipse.ui jfacefonts 特性文件，都存储在同一个本地语言片段 JAR <eclipse_root>\fragments\org.eclipse.ui.nl1\nl1.jar 中。

例如，意大利语有 jfactfonts_ it.properties、jfactfonts_linux_ it.properties、jfactfonts_windowsnt_ it.properties 和 jfactfonts_windows2000_it.properties。西班牙语有 jfactfonts_ es.properties、jfactfonts_linux_es.properties、jfactfonts_windowsnt_ es.properties 和 jfactfonts_windows2000_es.properties，等等。

要添加对新语言的支持，复制上述的基本 jfacefonts 文件，添加国家或地区代码（如 jfactfont_linux_ xx.properties，其中"xx" 是国家或地区后缀），将新的 jfacefonts 文件插入本地语言片段 JAR 中。

最终用户 messages.properties 文件
要翻译插件的最终用户消息：

1. 翻译 .properties 文件。
2. 将特性文件从本地编码的代码页转换成 PropertyResourceBundle期望的编码。
3. 遵循 Java 资源命名约定，使用正确的语言环境重命名文件（例如，en = 英语、de = 德语、fr = 法语、it = 意大利语）。
4. 将特性文件插回到用 PDE 创建的本地语言片段 JAR 的源目录中。

Java 资源文件命名约定考虑到了语言、地区和变体（basename_language_region_variant），而 Eclipse 只指定语言，只有三种情况例外（葡萄牙语、中文／中国和中文／中国台湾）：

     <name>_<locale>_<region>.properties  

PropertyResourceBundle 在运行时会自动查找与当前语言环境相应的资源文件。例如，以德语为例，最初会将英语 plugin.properties 复制成 plugin_de.properties，以供翻译。

Eclipse 联机帮助：.HTML 和 .properties 文件

Eclipse 有五个联机帮助。基本语言文档是作为插件在其自己的子目录中交付，而翻译版本则作为插件片段交付。“文档”插件的位置如下：

表 1. Eclipse 文档插件的位置

联机帮助位置Workbench User Guideeclipse\plugins\org.eclipse.platform.doc.userJava Development User Guideeclipse\plugins\org.eclipse.jdt.doc.userPlatform Plug-in Developer Guideeclipse\plugins\org.eclipse.platform.doc.isvJDT Plug-in Developer Guideeclipse\plugins\org.eclipse.jdt.doc.isvPDE Guideeclipse\plugins\org.eclipse.pde.doc.user

上述每个目录中的插件清单文件 plugin.xml 都定义了帮助组成部分。在同一个目录中还定义了必需的帮助 信息集和 接线文件。要翻译联机帮助：

1. 翻译每个联机帮助的 doc.properties 文件。
2. 根据本地编码的代码页转换已翻译的 doc.properties，并根据语言环境特定的资源文件命名约定进行重命名。
3. 将特性文件插回到用 PDE 创建的本地语言片段 JAR 的源目录中。
4. 翻译联机帮助的 *.html 文件。
5. 将已翻译的 .html 放入相应的插件片段目录。

如果将联机帮助翻译成多种语言，必须创建一个语言目录结构来保存针对国家和地区翻译的 HTML。这些文件就象特性文件一样，也不是语言环境敏感的，因此必须保留它们原来的文件名和扩展名。例如，要区分日语 .html 文件集和德语文件集，必须将它们保存在不同的目录名下，每个目录表示一个国家或地区。

例如，Workbench User Guide 的德语 *.html 文件集存储位于 eclipse\fragments\org.eclipse.platform.doc.user.nl1\nl\de中。日语 welcome.xml 位于 eclipse\fragments\org.eclipse.platform.doc.user.nl1\nl\ja中。

Eclipse 的“Help >Welcome”菜单选项：welcome.xml 文件

welcome.xml 是在 Workbench 第一次打开或用户选择 Help > Welcome时显示的介绍性视图。它在 eclipse\plugins\org.eclipse.sdk_1.0.0 中。

以下是翻译 welcome.xml 文件的步骤：

1. 翻译 welcome.xml 文件。
2. 将翻译保存成 UTF-8 格式（例如，使用记事本）。如果忘了将它保存成 UTF-8，XML 解析代码在遇到重音字符时（即，一个不属于 UTF-8 代码页的代码点）会显示一个错误。
3. 就象 .html 文件一样，如果将 welcome.xml 翻译成许多语言，就需要将每个 welcome.xml 保存到语言环境特定的目录名下。例如，德语的 welcome.xml 在 eclipse\fragments\org.eclipse.sdk_1.0.0\nl\de 中，而日语的 welcome.xml 在 eclipse\fragments\org.eclipse.sdk_1.0.0\nl\ja中。

---

回页首

结束语和其它参考资料

让您的产品进入国际市场只是为了增加经济效益。上面的步骤表明这个过程比较简单。以下是我们在介绍时提到的测验：

真或假：IBM 遍及全球的软件销售收入的主要部分来自于美国。

假。实际上，IBM 软件收入中超过 50% 来自美国以外。

幸好，使用基于 Eclipse Platform 的产品的那些开发人员可以从已经翻译的基本产品中受益。剩下的就是遵循本文中概括的明确步骤，将您的基于 Eclipse 的产品推向国际市场！

Eclipse 特有的（非 Java）可翻译资源

以下是前面提到的可翻译资源列表的摘要，以及如何处理它们的简要说明。

表 2. Eclipse 特有的（非 Java）可翻译资源

已翻译的内容必需或可选 高级步骤插件文件必需

1. 打包插件 *.properties 文件并发送它们以供翻译，包括 plugin.properties
2. 转换已翻译的 *.properties 文件
3. 将已转换的文件插入本地语言片段的插件目录

插件“关于”文件可选

1. 打包插件 about.html，并发送以供翻译（从 Help > About > Plugin Info... > More Info...中显示）
2. 可以参考外部网站。可能需要更新 about.html 来传送语言指示符或引用国家或地区特定的网站

联机帮助必需

1. 打包 *.html 文件并发送它们以供翻译。
2. 打包联机帮助的 *.properties 文件并发送以供翻译，包括 doc.properties
3. 转换已翻译的 *.properties 文件
4. 将 *.html 打包到 doc.zip 中，然后将它、*.xml 接线文件和 *.properties 文件复制到本地语言片段的联机帮助中

Splash*可选要本地化闪屏（splash screen），需要在 eclipse/splash 下创建语言环境子目录。这些目录的名称要遵循标准 Java 语言环境命名约定。例如，平台寻找美国英语语言环境（en_US）的闪屏的方式如下：

1. eclipse\splash\en_US\<image file>
2. eclipse\splash\en\<image file>
3. eclipse\splash\<image file>

其中 <image file> 是闪屏文件的名称（例如，splash_full.bmp 或 splash_full.xpm）。产品配置*可选

1. eclipse\install\install.properties（表示主要应用程序）
2. eclipse\configurations\configuration_n\install.xml
3. eclipse\dominant_application_plugin_directory\platform.ini（不变的）
4. eclipse\dominant_application_plugin_directory\platform.properties（不变的）

插件产品文件*必需

1. 翻译 eclipse\dominant_application_plugin_directory\product.properties
2. 翻译 eclipse\dominant_application_plugin_directory\welcome.xml
3. 将已翻译的 welcome.xml 保存成 UTF-8 格式（例如，使用记事本）
4. 将已翻译的 welcome.xml 插入本地语言片段

许可证*可选

1. 打包许可证和注意事项，并发送以供翻译：（eclipse 目录中的 license.html、notice.html、cpl-v05.html 和 about.html）
2. 将它们放到本地语言片段的根目录和插件目录中

有关可翻译资源的更多信息，请参阅 eclipse.org 网站上由 Greg Adams 撰写的文章“Creating Product Branding”（请参阅参考资料）。

常见重音拉丁字符的 Unicode 代码点

表 3. 常见重音拉丁字符的 Unicode 代码点

字符\u00e0带沉音符号的 a\u00e1带尖音符号的 a\u00c0带沉音符号的 A\u00c1带尖音符号的 A\u00c2带音调符号的 A\u00e2带音调符号的 a\u00c3带腭化符号的 A\u00e4带分音符号的 a\u00c4带分音符号的 A\u00e8带沉音符号的 e\u00c8带沉音符号的 E\u00e9带尖音符号的 e\u00c9带尖音符号的 E\u00ea带音调符号的 e\u00eb带分音符号的 e\u00cb带分音符号的 E\u00ea带音调符号的 e\u00ca带音调符号的 E\u00ef带分音符号的 i\u00ec带沉音符号的 i\u00ed带尖音符号的 i\u00cc带沉音符号的 I\u00cd带尖音符号的 I\u00ee带音调符号的 i\u00ce带音调符号的 I\u00f6带分音符号的 o\u00d6带分音符号的 O\u00e3带腭化符号的 a\u00f4带音调符号的 o\u00d4带音调符号的 O\u00f2带沉音符号的 o\u00d2带沉音符号的 O\u00f3带尖音符号的 o\u00d3带尖音符号的 O\u00f5带腭化符号的 o\u00d5带腭化符号的 O\u00f1带腭化符号的 n\u00d1带腭化符号的 N\u00f9带沉音符号的 u\u00d9带沉音符号的 U\u00fa带尖音符号的 u\u00da带尖音符号的 U\u00fb带音调符号的 u\u00db带音调符号的 U\u00fc带分音符号的 u\u00dc带分音符号的 U\u00df带升半音符的 s特殊符号\u00ba阳性序数指示符\u00a7章节符号\u00aa阴性序数指示符\u00ac非符号\u00b9上标 1\u00b2上标 2\u00b3上标 3\u00a3英镑符号\u00a2分符号\u00b0度数符号

词汇表

代码点（Codepoint）
可以由一个或多个字节信息表示的字符。代码点是分配给每个图形字符的十六进制值。

代码页（Codepage）
代码页是一个图形字符集或一组图形字符集中的每个图形字符的代码点的规范。在一个给定代码页中，代码点可能只有一个特定含义。可以用 CHCP 命令显示 Windows® 操作系统上的活动代码页（在任何给定时刻，只有一个代码页是活动的）。

编码（Encoding）
与一段给定数据相关的代码页。只能以一个给定代码页对文件“编码”；例如，缺省情况下，在美国英语机器上，记事本以代码页 437 对其数据进行编码。 Save As对话框允许用户选择几种其它可能的编码，其中最著名的是 Unicode 和 UTF-8。

国际化（Internationalization）（有时缩写成“I18N”）
国际化是指在预先不知道要处理的语言、文化数据或字符编码方案的情况下开发程序的过程。在系统术语中，它是指提供一些接口，这些接口可以在运行时使国际化的程序更改其行为以适合特定语言操作。

单字节编码字符集（Single-Byte Coded Character Set (SBCS)）
在单字节编码字符集中，单字节代码点表示集合中的每个字符。通常，SBCS 用于表示英语、欧洲语言、西里尔语、阿拉伯语、希伯来语等语言的字符。

双字节编码字符集（Double-Byte Coded Character Set (DBCS)）
在双字节编码字符集（DBCS）中，双字节代码点表示集合中的每个字符。实质上，这些语言是由表意字构成，如日语、汉语、韩国语，它们拥有的符号超出了 256 个代码点可以表示的范围，因此需要双字节编码字符集。

本地化（Localization）（有时缩写成“L10N”）
本地化是指在特定于每种受支持的语言、文化数据和编码字符集组合的计算机系统中建立信息的过程。

混合字节字符集（Mixed-Byte Character Set）
混合字节编码字符集是包含单字节字符和双字节字符的字符集合。在 MBCS 中，必须检查数据的每个字节，看看它是双字节字符的首字节还是单字节字符的首字节。如果字节在某个范围中（例如，大于 X'80'），那么它就是双字节字符的首字节。

NLS
本地语言支持。

Unicode
直接出自 http://www.unicode.org：“无论是对于何种平台、何种程序、何种语言，Unicode 为每个字符提供了一个唯一的编号。” 注：虽然 Java 文本操作类确实是以 Unicode 为核心的，但存储在程序的保护之外的数据通常却不属于这种情况。必要时，Java 程序员必须考虑通过执行本地代码页到 Unicode 转换进行数据编码。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• Eclipse Platform 采用了 Java SDK 提供的国际化实现，因此阅读 Java Tutorial: Internationalization系列（Sun Microsystems, Inc., 2002）会有所帮助。
  
  
  
• 文章“ Understanding Layouts in SWT”详细讨论了实现问题（ eclipse.org 网站，2001 年 3 月）。
  
  
  
• 另见文章“ Creating Product Branding”以获取关于可翻译资源的更多信息（ eclipse.org 网站，2001 年 11 月）。
  
  
  
• 检查 native2ascii 实用程序（包括在 Java SDK 中），它处理代码页转换并插入任何必需的 Unicode 转义符。
  
  
  
• 从 IBM alphaWorks站点上下载Resource Bundle Manager工具。RBManager 自动执行与创建、更新和管理资源束文件相关的乏味任务；它还防止大多数常见的由于跨束传播产生的错误。这个工具对于从事国际化的应用程序和基于 Web 的服务的开发团队很有帮助。
  
  
  
• Nadine Kano 撰写的 Developing International Software for Windows 95 and Windows NT（Microsoft Press, 1995），ISBN 1-55615-840-8，包含了关于 Win32 的代码页、Unicode 和其它方面问题的大量详细信息。该书还没有针对 Windows 98、Windows NT 4.0 和 Windows 2000 对它进行更新，但大多数材料还是有效的。
  
  
  
• 有关 Eclipse Platform 及其操作方式的介绍，请阅读 Greg Adams 和 Marc Erickson 撰写的文章“ Working the Eclipse Platform”（ developerWorks，2001 年 11 月）。
  
  
  
• 请访问 eclipse.org 网站以获取关于 Eclipse 的更多信息。
  
  

作者简介

Dan Kehn 是美国北卡罗莱纳州 Research Triangle Park 的 IBM 高级软件工程师。他对面向对象编程的兴趣要追溯到 1985 年，当时这种技术还不象现在这样广为接受。他拥有广泛的软件经验，从事过开发工具（如 VisualAge for Smalltalk）、操作系统性能和内存分析和用户界面设计。Dan 作为面向对象开发项目的顾问走遍了美国，并且还在欧洲工作过四年。他最近的兴趣包括面向对象分析／设计、编程工具，以及使用 WebSphere Application Server 进行 Web 编程。去年，他加入了 Eclipse Jumpstart 小组，这个小组的主要目标是帮助 ISV 创建基于 Eclipse Platform 的商业产品。在其余时间，Dan 撰写了关于几篇关于各种 Smalltalk 主题的文章，如元编程、团队开发和内存分析。可以在Eye on SmallTalk 上找到这些文章。

Scott Fairbrother在美国北卡罗莱纳州 Research Triangle Park 的 IBM Eclipse Jumpstart 小组工作。他是一位拥有 20 多年经验的软件开发人员。他开发过面向对象的业务过程管理应用程序框架。他为 Windows 2000 上的 IBM 中间件编写了规范，还撰写了关于 Microsoft Visual Studio .NET 的文章。

Cam-Thu Le在 1983 年加入 IBM。Cam 的经验跨越了软件创建的许多方面：开发、测试以及本地语言支持（NLS）规划和协调。Cam 使 IBM 产品的本地语言版本可以全球同步上市，包括 4690 Point of Sales 产品和 VisualAge for Smalltalk。Cam 去年加入了 Eclipse Project，作为 NLS 联络人。Cam 协调 Eclipse Workbench 和 WebSphere Studio Workbench 本地语言版本的构建和测试。

关闭 [x]

关于报告滥用的帮助

报告滥用

谢谢! 此内容已经标识给管理员注意。

---

关闭 [x]

关于报告滥用的帮助

报告滥用

报告滥用提交失败。 请稍后重试。

---

关闭 [x]

developerWorks：登录

 

IBM ID：
需要一个 IBM ID？
忘记 IBM ID？

密码：
忘记密码？
更改您的密码

保持登录。

单击提交则表示您同意developerWorks 的条款和条件。 使用条款

 

---

当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

关闭 [x]

请选择您的昵称：

 

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

昵称：（长度在 3 至 31 个字符之间）

---

单击提交则表示您同意developerWorks 的条款和条件。 使用条款.

 

---

所有提交的信息确保安全。

为本文评分

错误：提交失败，请重试。

平均分 (6个评分)

1 星1 星
2 星2 星
3 星3 星
4 星4 星
5 星5 星

评论

添加评论:

请 登录 或 注册 后发表评论。

注意：评论中不支持 HTML 语法

有新评论时提醒我剩余1000 字符

共有评论 (0)显示： 最新评论

在检索评论时出错，请稍后刷新。

共有评论 (0)显示： 最新评论

回页首

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=10

Zone=Linux

ArticleID=49626

ArticleTitle=开放源码项目: 国际化 Eclipse 插件

publish-date=06012002

author1-email=

author1-email-cc=

author2-email=

author2-email-cc=

author3-email=

author3-email-cc=

url=http://www.ibm.com/developerworks/cn/linux/opensource/os-i18n/part1/index.html

内容

• 国际化概述
• 国际化影响什么？
• 国际化步骤
• Eclipse Platform（V 1.0）的国际化
• 结束语和其它参考资料
• 参考资料
• 作者简介
• 建议

• 打印此页面

• 分享此页面
• 关注 developerWorks

分享此页面：

关注 developerWorks 中国网站：

• IBM 教育学院教育培养计划
• IBM 创业企业全球扶持计划
• ISV 资源 (英语)