我发现在国际化软件开发中，普遍缺乏对产品国际化重要性的认识，这给软件工程开发的效率带来了消极影响。
一个典型的例子：一家大中型公司决定进军电子商务，他们准备开发一个强大的Web或智能软件，以提高他们的市场份额。他们很快决定招募一个强大的开发团队或将项目外包给一家知名的软件公司。在软件开发方面，他们最关注的是：强大和稳定的应用程序、强大的功能、良好的布局和用户友好的环境。 但是没有关于国际化(I18N)的任何需求！常见的借口有：没有足够的时间，需要额外的成本或只用在后期进行国际化！一旦这个公司决定将业务扩大到不同语言和文化的国家和地区，那么这种漠视将会带来实际的技术和经济问题。
什么是国际化（i18n）？简单来说，国际化就是使应用程序显示当地语言、货币、日期格式、数字和界面布局（从右到左或从左到右）的一个过程。
应什么时候开始国际化呢？最好的做法是在分析阶段时开始国际化过程，并在应用程序 （用户界面、业务、数据层和数据库）各层级的开发过程中同时进行国际化。
为什么不能将国际化拖到后期开发阶段？在后期进行国际化肯定是可以的，但是这可能需要重构应用程序的某些主要部分，例如，如数据库、数据层、前端，第三方控件，脚本等。显然，相比从项目一开始时开始国际化，后期进行国际化将需要更多的时间、精力和成本。后期国际化，意味着要回头再进行部分开发，并且要重新测试，最终还可能带来程序稳定性问题。
举一些简单的例子。比较：（例如，一个简单的应用程序）
| 延迟/忽略国际化 | 从一开始即重视国际化 |
| 分析（主要需求） | 分析（需求，国际化准备） |
| 数据库开发 (传统结构) | 数据库开发，考虑国际化 |
| 基于上述步骤的数据层 | 基于上述步骤的数据层（包括国际化） |
| 基于前面步骤的业务逻辑层 | 基于前面步骤的业务逻辑，包括国际化 |
| 前端开发 | 基于国际化规则的前端开发 |
| 不同类型的测试 | 不同类型的测试 |
| 测试版 | 测试版 |
| 发行版 | 发行版 |
| 马上需要国际化 | 程序国际化已就绪 |
| 重新分析整体应用程序 | 不适用 |
| 数据库部分重构 | 不适用 |
| 根据数据库结构变化调整数据层 | 不适用 |
| 业务层调整 | 不适用 |
| 前端国际化调试，例如，使所有嵌入字符串外部化到外部库，对第三方组件、脚本（若需要）和其他方面进行同样的调整。 | 不适用 |
| 完整的重新测试（所有测试类型） | 不适用 |
| 第二个测试版 | 不适用 |
| 第二个发行版 | 不适用 |
根据上述比较，网站或软件开发周期初期引入国际化可以减少几乎一半的时间、精力和费用。
本文摘译自国外博客。