在本文中，我们将含括在编码阶段期间所能够做的事情和为了使发现问题有效，你应该将你的本地化测试力量集中在何处等问题。

　　翻译应用程序的资源和测试代码与开发平行进行通常是一种较好的方法。这有助于在过程的早期揭露代码，功能设计中的问题，因为那时做变更相对还是比较容易的。

　　这也可以帮助决定什么时候“冻结”用户界面和功能设计。越快越好。设想一下每次用户界面发生变更时，都不得不重新翻译的情况。而且UI的变更也涉及到其他类型必须要修改的文档－在线帮助和指南。

　　记住晚期的变更会给本地化产品的发布带来显著又昂贵的费用和延期。

　　在本地化过程中，记住以下事项将可以帮助你在随后的阶段中节约大量的时间：

　　● 位图（Bitmaps）：应该无字母和标点符号因为它们到处都会发生变化，例如引号。

　　● 本地化中的对话框（Localizing dialog box）：与英语相比，有些语言方面需要为消息和命令名称准备更多的空间。一个30个字符的简单信息在翻译为另一种语言的过程中可以会“增长”40%到60% 。菜单和对话框中的文字可能会溢出。以前为了使文字合适的缩略语可能会无法接受了。

　　● 正文串可能会超出内部的存储量，或覆盖代码或其他的数据。扩展的菜单可能增长的太宽以致于不能在屏幕上显示完全

　　● 应该删除掉在目标语言下不支持的功能，而不应把它变灰，那样只会混淆用户，因为用户可能不理解为什么有些命令从来都不可用。

　　到什么地方查找问题

　　发现没有为本地化正确设计的源代码是很普通的事。极端的案例是硬编码的字符串，常量和在代码中的字符。包含需要被本地化的硬编码元素的文件通常很难处理。翻译不能有效地翻译那些是由开发者编写的源代码文件， 特别是如果代码正在不断地开发过程中。 大多数翻译不是程序员，并且可能会删除掉重要的细节， 例如结束的引号或分号，或者和翻译字符串一样翻译程序关键字，这将导致开发人员要花格外的时间去修复这些类型的问题。

　　一个典型的解决这种问题的办法是将所有可本地化的项目分离到一个或多个文件中，这样可以使本地化变得更容易管理。例如，对于基于Windows的应用程序，简单的方法是使用“资源（resource）”文件。它们很容易编辑，而且你不需要重现编译源代码。

　　此外， 所有本地化的文件， 不管它们包含代码还是用户界面元素，都可以放在一个单独的目录下，这样翻译只需要访问包含本地语言文件的和其负责的已本地化文件的目录

　　以下列出了通常需要本地化和应该是可本地化文件中一部分的要素。

　　● 信息Messages

　　● 常量Constants

　　● 提示Prompts

　　● 对话框Dialogs

　　● 声音Sounds

　　● 宏语言Macro languages

　　● 状态栏Status bars

　　● 菜单Menus

　　● 工具栏Toolbars

　　测试

　　从表面上看起来很简单，但是测试已本地化的产品需要注意一些并非所有的测试小组都准备的细节。