国际化 Eclipse 插件(1)

sapphire01

开放源码项目: 国际化 Eclipse 插件如何编写适合国际市场的 Eclipse 插件

级别： 初级 Dan Kehn, Eclipse ISV 启用小组, IBM Scott Fairbrother, Eclipse ISV 启用小组, IBM Cam-Thu Le, Eclipse ISV 启用小组, IBM 本文是为编写进入国际市场的 Eclipse 插件而准备的路线图。首先，我们将简短回顾国际化的动机和技术问题，然后逐步说明国际化插件的步骤。最后，我们将说明如何将这些步骤应用到 Eclipse Platform 本身的国际化过程中。 在国际化社区中，有一个流传了很久的笑话： “会说三种语言的人称为“三语人”。会说两种语言的人称为“双语人”。那么把只会说一种语言的人称为什么呢？” “美国人。” 现在，从可用性、质量、市场营销和（在某些情况下）法律的观点来看，只提供英语版本的软件已不再受欢迎了。让您的产品能够用于国际市场只是为了增加经济效益。这个启用过程比较简单，就象本文所呈现的一样。 在开始之前，要谈几点注意事项。由于 Eclipse Platform 采用了 Java SDK 提供的国际化实现，因此在继续阅读本文之前先阅读 Java Tutorial: Internationalization 系列会有所帮助。该教程很好地概述了过程中涉及的问题和步骤。我们将假设您已经阅读了该教程，因此我们可以在本文中着重说明要点，阐述其它值得注意的事项并涵盖 Eclipse 特定的问题和步骤。当遇到本文中不熟悉的术语或缩略语时，请立即查阅 词汇表。 国际化概述 国际化是创建适合于国际市场的软件的过程。除了经济利益之外，某些国家或地区要求产品在进入其市场之前通过政府设置的某些本地化要求。 国际化 Eclipse Platform 的过程分两步完成： NLS 启用的产品。 这一步涵盖了编码技术和用户界面设计问题。启用产品的本地语言支持（National Language Support (NLS)）确保了产品是为本地语言功能设计的，并且产品使用适当的 API 来处理本地语言数据。在这一步骤中，必须权衡并考虑智能编码的做法（如避免硬编码字符串、使输入缓冲区足够大可以容纳可翻译的文本、正确地解析包含非拉丁字符的字符串、不对作为文件格式一部分保存的字符串进行本地化，以及从程序代码中分离本地语言元素），这样投入最小的费用和精力就可以完成翻译。 翻译产品。 这一步涉及到将本国语言元素翻译成外语。如同单词和短语一样，图片和符号在各种文化背景下也有不同的解释。在翻译验证步骤期间，要复查所有翻译以确保上下文正确性，要修改图标或剪贴画以确保不会造成用户误解，还要检查页面布局以避免无意的文本截断。当在翻译之后验证产品的功能完整性时，这个步骤还会寻找隐含的文化冲突。 国际化影响什么？ 只熟悉单一语言的人注意事项：这是灵敏度训练的开始。本文结尾处可能还会有测验。:-) 让我们从 Java 国际化教程（请参阅本文后面的 参考资料）中提供的与文化相关的数据列表摘录入手，该列表已根据一般开发人员遇到的可能性进行了重新排序，而且每项后面还附带了详细信息： 文本 GUI 组件上的消息、标签 联机帮助（*.html），插件清单（plugin.xml） 数据格式 数字、日期、时间、货币 电话号码、邮递地址 地区和个人称谓 度量衡 尊称和个人头衔 多媒体考虑事项 文本 消息、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 路由器”。大多数美国人都会明白这个隐喻；想想这给倒霉的非美国用户造成的混淆。 同样，下面的图像对于许多北美用户也许很直观： 但在识别性调查中，美国以外的其他用户都猜这是个鸟房。以下是一个更广为接受的邮件图像： 要避免会产生混淆和可能令人不快的图像，最好的做法是聘请了解文化问题的专职图形艺术家。

[ 本帖最后由 sapphire01 于 2007-11-14 17:20 编辑 ]