软件本地化项目正式实施的初始阶段是进行软件资源文件工程处理。包括评估与准备、资源文件抽取、标识资源文件、检查翻译后的资源文件、调整用户界面尺寸、编译本地化软件、修复软件缺陷等。

1、抽取资源文件（Leverage）

为了便于工程处理，需要本地化的源语言的资源文件包含在翻译数据库（TDB）中，由软件供应商提供。

为了抽取和重复利用已经翻译的资源，需要使用正确版本的本地化工具软件对源语言翻译数据库进行工程处理。有些软件供应商使用它们自己开发的本地化工具，也有的使用业界专业的本地化工具，例如Alchemy Catalyst 和Pass Passolo等。

在进行资源文件抽取和重复利用前，要准备好前一版本的已经翻译过的翻译数据库。如果是第一次进行软件本地化，由于一些本地化工具软件支持术语表的导入，则在软件供应商确认的情况下，尽可能利用软件供应商的其它软件产品的术语表和本地操作系统的术语表。

在进行抽取和重复利用时，应该对本地化工具进行正确的设置，例如，源语言、目标语言、代码页、默认目标字体、提取选项、前一版本的已经翻译的翻译数据库等。

经过抽取和重复利用处理得到的翻译数据库，只包含新增的和更新的需要翻译的源语言字符。除了提供这个数据库，还要使用本地化工具的统计功能，提供全部需要翻译字符的数量（包含新增的和更新的），以便翻译团队估计任务量，分配翻译资源。

2、标识资源文件（Mark）

如果源语言软件进行了很好的国际化设计，那么资源文件中包含了全部需要翻译的内容。但是，实际上不少软件的国际化设计并不完美，相应地，资源文件中包含了一些不需要翻译的内容，例如，变量和命令选项。另外，资源文件中的某些条目可能需要根据不同的目标区域语言，分别进行不同的本地化处理。因此，在将抽取处理的翻译数据库进行翻译前，软件工程师需要对这些不需要翻译的和需要特殊处理的条目，添加标识注释。

通常添加的标识类型如下：

• 不需要翻译。
• 不要超过n个字符长度。
• 重复利用操作系统中的翻译，需要审阅。
• 本字符串与ID:xx字符串组成串联字符串。
• 不要删除热键符号。
• 保留字符结尾的空格。
• 不要改变变量的顺序。

3、检查资源文件（Validate）

本地化工程师要在编译本地化软件前，对资源文件的翻译语言质量进行检查。由于资源文件通常使用翻译记忆软件进行翻译，因此翻译数据库中标识的内容，通常不能导出到适合翻译的文档中，从而这些标识的条目可能不能被正确处理。因此，应该重点检查标识部分的翻译的正确性。另外，在翻译数据库导出/导入到翻译记忆工具软件支持的文件格式过程，以及翻译过程中，可能会引起翻译格式和内容的错误。

检查方法首先是利用软件本地化工具的检查功能，例如，Alchemy Catalyst的Validate Expert （检查专家）。其次，人工检查翻译数据库中被标识的内容。

需要检查的元素如下：

• 文件是否完全翻译？
• 文件的格式是否正确？
• 资源文件的标点符号是否正确？例如，是否丢失了前引号或后引号？是否添加了多余的引号？
• 热键是否与源语言一致？例如，是否有丢失、重复、错误的热键？
• 是否丢失了需要保留的字符串的尾部的空格？
• 是否翻译了不应该翻译的字符？
• 是否添加、删除了软件变量？
• 是否添加、删除了控制符？

4、调整用户界面尺寸（Resizing）

本地化工程师要在编译本地化软件前，对资源文件的用户界面（例如，对话框）的控件大小和位置进行调整，以便适应本地化用户界面的实际大小和位置。例如，如果按钮上的文字翻译后，超过了按钮的宽度，应该增大按钮的宽度使全部文本显示出来。

可以使用软件本地化工具的检查功能，找出需要调整的用户界面控件，例如，Alchemy Catalyst的Validate Expert （检查专家）。

调整用户界面控件的大小和位置时，本地化工程师要掌握用户界面的设计原则，使得调整后的本地化用户界面保持美观、与源语言界面一致。

下面列出一些调整用户界面通用的指导准则：

• 本地化对话框中按钮和选项的数目应该与源语言对话框一致。
• 默认按钮具有默认的大小，例如，“确定”按钮，在所有对话框中，都应该保持相同的大小。另外，一个对话框中的所有按钮，应该尽可能保持相同的大小。
• 确保控件之间不重叠。
• 保持控件原始的对齐方式。例如，左对齐，右对齐，上对齐，下对齐。
• 本地化对话框的选项的Tab键保持原始的跳转顺序。
• 避免使用缩写文本。如果确实因为空间限制而采用缩写，应该向翻译工程师咨询正确的缩写格式。
• 避免减小控件的尺寸。因为有些控件上面的文字是在程序运行后动态改变的，如果减小了控件尺寸，动态改变的长文字可能不能完全显示出来。
• 使对话框的标题适合标题栏的尺寸。
• 尽量避免调整对话框的大小。调整对话框的大小将影响本地化用户界面的屏幕捕捉（Screen Capturing）和桌面出版（DTP）处理。
• 对话框的大小应该适应软件运行时要求的屏幕显示分辨率的大小。

5、编译本地化软件（Compiling）

软件本地化编译的具体实现技术与编译的本地化软件的特点紧密相关。首先，软件编译中提取本地化资源文件的方法不同。根据本地化资源文件的类型，使用不同的本地化工具软件（例如，Alchemy Catalyst或Pass Passolo），提取已经本地化的资源文件。其次，编译实现方式不同。通常，有两种编译本地化软件的方式。第一，直接在开发环境上（例如，Microsoft Visual Studio，Microsoft Visual Studio.Net）将ASCII本地化资源文件（例如，rc文件），编译成二进制的本地化资源文件（例如，dll文件），然后使用软件安装制作工具创建本地化安装程序。第二，以源语言版本（Build）为基础，将二进制的本地化资源文件替换源语言中对应的文件，从而得到本地化的安装程序。第一种方式要由源语言软件的开发人员实现。第二种方式可以由软件本地化服务商的编译工程师完成。随着软件本地化技术的发展，越来越多的本地化软件编译任务由软件本地化服务商完成。因此，本地化服务商，通常采用第二种方式编译本地化软件。

如果软件供应商要求本地化服务商编译本地化软件，通常软件供应商提供编译环境和编译指导文档。本地化工程师在充分理解编译指导文档的基础上，设置编译环境，将经过检查确认的本地化资源文件、联机帮助文档以及其他本地化文档复制到编译环境中，执行相应的编译操作步骤，编译创建本地化软件版本。

设置本地化软件的编译环境是编译本地化软件的关键步骤，包括操作系统变量设置，路径设置，安装编译过程中调用的工具软件，复制全部本地化文档到编译环境。

完成本地化软件的编译后，要执行版本可接受测试（Build Acceptance Test），又叫作冒烟测试（Smoke Testing）。目的是进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等缺陷。另外，确认本地化软件包含了全部的本地化文档。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。

6、修复软件缺陷（Fixing Bug）

本地化工程师负责修复本地化软件测试过程发现和报告的软件缺陷（Bug）。由于本地化软件的缺陷类型较多，本地化工程师只需要修复由于软件本地化产生的错误，例如，翻译错误，用户界面大小和位置错误，因翻译错误引起的本地化软件的功能错误。对于软件的国际化设计错误和功能错误，软件供应商的开发工程师负责处理。

为了保证本地化项目的进度满足项目的计划，应该在当前版本地的测试周期内及时全部修复本地化软件缺陷。