.Net软件国际化自动实现的构想
微软的Visual studio从一开始就提供对项目的国际化和本地化的支持。 其核心思想是把本地化信息独立到资源文件里。 Visual studio2003就已经提供支持了， 随着 Visual studio2005 的发布， 微软在对国际化和本地化的支持的实现发生了很大的变化。 对于Windows应用， 简化了资源读取的代码， 原来自动生成的代码一行只读取一个资源属性， 这样读取资源的代码就很多。 虽然这些代码都是有IDE来维护的， 但毕竟使代码不简洁。 Visual studio 2005只需要使用一行代码就将整个控件的所有资源读取完毕， 代码简洁多了。 当然， 对于开发人员来说，这个变化不是很重要， 因为Windows应用的资源都是有IDE来维护的， 不需要开发人员去维护。
对于Web应用， 资源文件的位置和读取都发生了很大的变化。 在Visual studio 2003里， 一个界面文件里会自动生成一个空的资源文件， 但资源信息如何分离到资源文件和将资源信息从资源文件里读出来， 还是需要由开发人员来完成， 这部分的工作量其实还是很大的。
Visual studio 2005改变了这种做法， 首先， 资源文件独立存放在一个叫做App_LocalResources的目录。 并且通过执行Tool.GenerateLocalResource来支持自动分离， 现在的情况是需要一个一个页面的去做，并且需要将页面切换到设计态， 期待下一个版本能够支持批量分离。当然这个分离只是页面资源信息的一个副本，当页面文件里的资源信息被修改时， IDE是不会自动同步的， 还需要在一次手工操作。 这一点与Windows类型的应用是不同的， Windows应用只有一份资源信息， 不存在同步问题。但WEB控件中的资源信息支持自动读取，不需要开发人员在编写任何代码。
Visual studio 2003 提供了对资源文件的基本管理能力， Visual studio2005 则在Visual Studio 2003的基础上， 基本完成了界面元素资源信息的自动分离和读取，当然自动化程序还可以继续提高 ， 还有就是自动分离用户界面的资源信息现在只实现最基本的资源信息的分离，事实上，还有更多的资源信息类型需要分离，比如Web的图片资源等待。
但资源信息不仅仅存在与界面元素中， 同时也存在于代码中， 只不过不象界面文件中那么集中罢了。 但这也是国际化和本地化必须关注的。 还有一个问题是Web应用的一个页面文件中不仅仅包含服务器控件， 同时也包括一些Html元素， 特别是一些标签，一般在设计的时候不会特别的去做成服务器控件。但这些Html元素也包含一些必须分离的本地化信息。现在的Visual Studio 对上述两个资源信息的分离和读取没有提供支持， 是不是后续版本会支持支持， 现在来看， 可能性不是太大。
本地化，国际化与应用的业务应该是无关的， 既然本地化和国际化与业务没有关系， 那么我们是不是可以将业务与本地化分开来开发呢。 答案是肯定的。分开开发， 可以简化整个应用程序的复杂程度， 特别是业务部分的复杂程序，因为业务往往是最复杂的。同时在简化复杂程度的同时， 可以提高效率和质量， 提高软件的可维护性。
如果业务与本地化分开来开发， 首先需要完成业务方面的开发。当然在业务开发时候适当的为本地化和国际化做考虑， 是可以大大简化后面的开发的， 比如不要使用代码动态的创建控件， 特别是创建那些包含本地化资源的控件， 同时建议缺省的资源信息使用英语语言。 一般来说， 绝大部分翻译工具都支持英语和其他语言的互译， 但并不一定支持任意两个语言的互译， 当然如果就只需要两个语言的版本， 这条就无关紧要了。还有就是需要适当的主要控件的布局， 特别是要防止字符显示不全的问题， 因为不同语言下资源需要占用的屏幕区域很可能是不同的， 还需要注意不用使用本地化资源信息作为判断的依据。当然， 实际上需要特别留意的地方还是很小的， 除了不要使用代码创建控件外， 几乎就没有实质的限制了。
按到正常流程开发完一个项目后， 就可以进行国际和和本地化的开发了，国际化和本地化需要完成一系列的工作， 首先需要分离资源， 并适当的修改代码， 并添加不同语言的切换功能。 然后就是需要翻译了， 翻译完了之后， 需要进行整合和测试 ， 如果使用工具来完成的话， 应该说效率会很高， 不需要花费什么精力，也几乎不会引入回归错误。。
既然国际化和本地化需要一系列的步骤， 一个集成的开发工具就显得很有必要了。因为集成的开发工具可以大大的提高效率。
现在市场上的国际化和本地化没有很好的集成开发工具， 对于.Net类型的应用， 早期使用Visual Studio 来进行开发， 然后使用Trdos之类的翻译工具。
集成的国际化和本地化的开发与翻译和分离的本地化开发与翻译工具相比较， 具有如下特点
1： 集成的效率要比分离的效率高很多。首先， 分离的翻译过程， 翻译完后， 需要将翻译好的资源再次进行集成，哪怕是一次很小的修改。 事实上， 一个成熟的软件， 不论是翻译， 还是开发，修改总是频繁的，所以， 集成就会占去很大的一块时间。在本地化和国际化的过程中， 很有可能需要修改原来已经开发好的代码。分离的过程会使这个过程很耗费时间。
2：集成的翻译能够更好的集成资源， 支持即使语言切换。 现在市场的很多产品， 都是以汉化包的形式进行本地化；即使部分软件能够在安装的时候选定语言， 但一旦安装以后， 就不能在进行语言的切换。 包括本地化和国际化工具本身， 都不能轻易的进行语言切换，这实际上是本地化的一个很大的遗憾。
3：集成的本地化和国际化开发需要源代码，与分离的翻译相比，不利于知识产权的保护。 集成的工具， 在翻译过程中， 是可以脱离源文件工作的。
一个集成的.Net国际化和本地化工具， 应该具备如下特性
1： 与Visual studio集成， 并且与Visual Studio保持一致的风格。
2： 必须支持代码文件中资源信息的自动分离。
3： 必须能够集成一系列的翻译功能。
4： 翻译功能应该与Visual Studio 集成。
湛蓝.Net国际化与本地化工具的特征
1： 与Visual Studio的紧密集成。能够直接调用Visual Studio本身的一部分功能。 比如调用Visual Studio自身的界面原始资源的自动分离， 项目的资源文件的管理等功能。
2：能辅助识别代码文件中的资源， 并支持自动分离。 代码文件中的资源信息识别别界面元素中资源信息的识别难度大很多， 事实上是不可能完全自动识别的， 但工具应该能够识别绝大部分的资源， 并且不能漏识， 但可以比实际的多，但识别的准确程度应该很高。 漏识会导致开发人员需要重新阅读代码， 这不可取。 即宁可多识， 也不可漏识。 识别真正的资源后， 需要能够自动将资源分离到资源文件。 自动分离资源到资源文件， 可能会导致代码的修改。 代码的修改量应该最小， 并且不能导致任何可能的错误。
3：提供对缺省资源的修改和统一管理功能，在开发过程中， 经常会出现提示信息和标签文本不正确， 不统一的情况， 并且很有可能也被测试所漏过。到国际化的时候， 就会发现这些问题， 因此， 湛蓝.Net国际化和本地化工具提供了对缺省资源的统一管理， 能够集中的将这些资源呈现在开发人员面前，并提供修改， 替换等快速维护功能。
4：支持Web页面中Html资源信息的自动分离及其他适应性修改。
5：支持语言自动切换功能，这虽然简单但却很重要。
6：集成的资源文件管理。在完成国际化和本地化的过程中， 需要增加很多的资源文件， 这些资源文件应该能够自动集成到Visual Stuaio的项目文件， 并且被工具自动管理。
7： 编码的自动识别及相关的管理。 由于国际化和本地化会涉及到多种不同的语言文化， 也不同的语言文化也会有自己对应的编码规则。 工具应该能够正确识别所有文件中的编码， 并且可以以任意指定编码的来保存。
8： 一个国际化和本地化工具的核心功能是翻译和对翻译的支持。 翻译主要包括翻译的自动化和翻译的准确程度。 当然翻译不可能完全自动化， 但是工具确实需要尽量的提供翻译的自动化和准确的程度。 如何提高翻译的自动化和准确程序， 关键是翻译词库的大小和翻译的智能化程度， 一般好的国际化工具都有自己的词库， 并且有比较好的智能化算法。其实，关于如何提高翻译的自动化和准确程序， 我个人认为， 国际化和本地化工具并不需要在这方面做太多的工作。 因为网络上有很多的免费翻译资源， 比如Google ， Yahoo， 金山， WorldLingo等等， 他们在这方面的投入很大， 应该说做的很专业了。并且软件的本地化和国际化， 一般都是短语翻译，其翻译的准确度应该说是很高的。不过微软的免费翻译资源不支持自动化接口，比较遗憾。 湛蓝国际化和本地化工具就是集成了上述免费的网络翻译资源的，并且做了一些智能化处理。
现在网上的在线翻译工具主要有Google， Yahoo ， Windows Live ， WorldLinq ， KingSoft。Google 应该说是在线翻译做得最好的， 无论是翻译的质量还是支持的语言。 Yahoo相对来说就差一些；Windows Live现在还处于Beta, 暂时不允许自动获取； WorldLingo不支持中文翻译， 也不支持自动获取，所以暂时意义不大。金山和Google使用同一个翻译引擎，翻译结果与Google完全相同， 就不单独讨论了。 现在来看， 在线翻译这一块， Google是最牛的， 应该以Google的翻译作为首选参考，Yahoo可以作为一个候选的翻译资源；Windows Live现在还不完善， 但凭着微软强大的技术实力， 我们有理由认为Windows Live在不远的将来有良好的表现。
现在的版本已经集成了Google， Yahoo， Windows Live， 金山。 WorldLingo暂时还没有。
现在发布的这个版本已经完成了好几个Windows和Web类型的应用， 应该说在已经完成的应用上继续进行本地化国际化改造， 效率是非常高的， 同时操作也很简单。 如有需要的同仁 ， 可以到http://www.dotnetcoding.net/ResourceCenter/BlueSky.GlobalTool.zip下载
对于Web应用， 资源文件的位置和读取都发生了很大的变化。 在Visual studio 2003里， 一个界面文件里会自动生成一个空的资源文件， 但资源信息如何分离到资源文件和将资源信息从资源文件里读出来， 还是需要由开发人员来完成， 这部分的工作量其实还是很大的。
Visual studio 2005改变了这种做法， 首先， 资源文件独立存放在一个叫做App_LocalResources的目录。 并且通过执行Tool.GenerateLocalResource来支持自动分离， 现在的情况是需要一个一个页面的去做，并且需要将页面切换到设计态， 期待下一个版本能够支持批量分离。当然这个分离只是页面资源信息的一个副本，当页面文件里的资源信息被修改时， IDE是不会自动同步的， 还需要在一次手工操作。 这一点与Windows类型的应用是不同的， Windows应用只有一份资源信息， 不存在同步问题。但WEB控件中的资源信息支持自动读取，不需要开发人员在编写任何代码。
Visual studio 2003 提供了对资源文件的基本管理能力， Visual studio2005 则在Visual Studio 2003的基础上， 基本完成了界面元素资源信息的自动分离和读取，当然自动化程序还可以继续提高 ， 还有就是自动分离用户界面的资源信息现在只实现最基本的资源信息的分离，事实上，还有更多的资源信息类型需要分离，比如Web的图片资源等待。
但资源信息不仅仅存在与界面元素中， 同时也存在于代码中， 只不过不象界面文件中那么集中罢了。 但这也是国际化和本地化必须关注的。 还有一个问题是Web应用的一个页面文件中不仅仅包含服务器控件， 同时也包括一些Html元素， 特别是一些标签，一般在设计的时候不会特别的去做成服务器控件。但这些Html元素也包含一些必须分离的本地化信息。现在的Visual Studio 对上述两个资源信息的分离和读取没有提供支持， 是不是后续版本会支持支持， 现在来看， 可能性不是太大。
本地化，国际化与应用的业务应该是无关的， 既然本地化和国际化与业务没有关系， 那么我们是不是可以将业务与本地化分开来开发呢。 答案是肯定的。分开开发， 可以简化整个应用程序的复杂程度， 特别是业务部分的复杂程序，因为业务往往是最复杂的。同时在简化复杂程度的同时， 可以提高效率和质量， 提高软件的可维护性。
如果业务与本地化分开来开发， 首先需要完成业务方面的开发。当然在业务开发时候适当的为本地化和国际化做考虑， 是可以大大简化后面的开发的， 比如不要使用代码动态的创建控件， 特别是创建那些包含本地化资源的控件， 同时建议缺省的资源信息使用英语语言。 一般来说， 绝大部分翻译工具都支持英语和其他语言的互译， 但并不一定支持任意两个语言的互译， 当然如果就只需要两个语言的版本， 这条就无关紧要了。还有就是需要适当的主要控件的布局， 特别是要防止字符显示不全的问题， 因为不同语言下资源需要占用的屏幕区域很可能是不同的， 还需要注意不用使用本地化资源信息作为判断的依据。当然， 实际上需要特别留意的地方还是很小的， 除了不要使用代码创建控件外， 几乎就没有实质的限制了。
按到正常流程开发完一个项目后， 就可以进行国际和和本地化的开发了，国际化和本地化需要完成一系列的工作， 首先需要分离资源， 并适当的修改代码， 并添加不同语言的切换功能。 然后就是需要翻译了， 翻译完了之后， 需要进行整合和测试 ， 如果使用工具来完成的话， 应该说效率会很高， 不需要花费什么精力，也几乎不会引入回归错误。。
既然国际化和本地化需要一系列的步骤， 一个集成的开发工具就显得很有必要了。因为集成的开发工具可以大大的提高效率。
现在市场上的国际化和本地化没有很好的集成开发工具， 对于.Net类型的应用， 早期使用Visual Studio 来进行开发， 然后使用Trdos之类的翻译工具。
集成的国际化和本地化的开发与翻译和分离的本地化开发与翻译工具相比较， 具有如下特点
1： 集成的效率要比分离的效率高很多。首先， 分离的翻译过程， 翻译完后， 需要将翻译好的资源再次进行集成，哪怕是一次很小的修改。 事实上， 一个成熟的软件， 不论是翻译， 还是开发，修改总是频繁的，所以， 集成就会占去很大的一块时间。在本地化和国际化的过程中， 很有可能需要修改原来已经开发好的代码。分离的过程会使这个过程很耗费时间。
2：集成的翻译能够更好的集成资源， 支持即使语言切换。 现在市场的很多产品， 都是以汉化包的形式进行本地化；即使部分软件能够在安装的时候选定语言， 但一旦安装以后， 就不能在进行语言的切换。 包括本地化和国际化工具本身， 都不能轻易的进行语言切换，这实际上是本地化的一个很大的遗憾。
3：集成的本地化和国际化开发需要源代码，与分离的翻译相比，不利于知识产权的保护。 集成的工具， 在翻译过程中， 是可以脱离源文件工作的。
一个集成的.Net国际化和本地化工具， 应该具备如下特性
1： 与Visual studio集成， 并且与Visual Studio保持一致的风格。
2： 必须支持代码文件中资源信息的自动分离。
3： 必须能够集成一系列的翻译功能。
4： 翻译功能应该与Visual Studio 集成。
湛蓝.Net国际化与本地化工具的特征
1： 与Visual Studio的紧密集成。能够直接调用Visual Studio本身的一部分功能。 比如调用Visual Studio自身的界面原始资源的自动分离， 项目的资源文件的管理等功能。
2：能辅助识别代码文件中的资源， 并支持自动分离。 代码文件中的资源信息识别别界面元素中资源信息的识别难度大很多， 事实上是不可能完全自动识别的， 但工具应该能够识别绝大部分的资源， 并且不能漏识， 但可以比实际的多，但识别的准确程度应该很高。 漏识会导致开发人员需要重新阅读代码， 这不可取。 即宁可多识， 也不可漏识。 识别真正的资源后， 需要能够自动将资源分离到资源文件。 自动分离资源到资源文件， 可能会导致代码的修改。 代码的修改量应该最小， 并且不能导致任何可能的错误。
3：提供对缺省资源的修改和统一管理功能，在开发过程中， 经常会出现提示信息和标签文本不正确， 不统一的情况， 并且很有可能也被测试所漏过。到国际化的时候， 就会发现这些问题， 因此， 湛蓝.Net国际化和本地化工具提供了对缺省资源的统一管理， 能够集中的将这些资源呈现在开发人员面前，并提供修改， 替换等快速维护功能。
4：支持Web页面中Html资源信息的自动分离及其他适应性修改。
5：支持语言自动切换功能，这虽然简单但却很重要。
6：集成的资源文件管理。在完成国际化和本地化的过程中， 需要增加很多的资源文件， 这些资源文件应该能够自动集成到Visual Stuaio的项目文件， 并且被工具自动管理。
7： 编码的自动识别及相关的管理。 由于国际化和本地化会涉及到多种不同的语言文化， 也不同的语言文化也会有自己对应的编码规则。 工具应该能够正确识别所有文件中的编码， 并且可以以任意指定编码的来保存。
8： 一个国际化和本地化工具的核心功能是翻译和对翻译的支持。 翻译主要包括翻译的自动化和翻译的准确程度。 当然翻译不可能完全自动化， 但是工具确实需要尽量的提供翻译的自动化和准确的程度。 如何提高翻译的自动化和准确程序， 关键是翻译词库的大小和翻译的智能化程度， 一般好的国际化工具都有自己的词库， 并且有比较好的智能化算法。其实，关于如何提高翻译的自动化和准确程序， 我个人认为， 国际化和本地化工具并不需要在这方面做太多的工作。 因为网络上有很多的免费翻译资源， 比如Google ， Yahoo， 金山， WorldLingo等等， 他们在这方面的投入很大， 应该说做的很专业了。并且软件的本地化和国际化， 一般都是短语翻译，其翻译的准确度应该说是很高的。不过微软的免费翻译资源不支持自动化接口，比较遗憾。 湛蓝国际化和本地化工具就是集成了上述免费的网络翻译资源的，并且做了一些智能化处理。
现在网上的在线翻译工具主要有Google， Yahoo ， Windows Live ， WorldLinq ， KingSoft。Google 应该说是在线翻译做得最好的， 无论是翻译的质量还是支持的语言。 Yahoo相对来说就差一些；Windows Live现在还处于Beta, 暂时不允许自动获取； WorldLingo不支持中文翻译， 也不支持自动获取，所以暂时意义不大。金山和Google使用同一个翻译引擎，翻译结果与Google完全相同， 就不单独讨论了。 现在来看， 在线翻译这一块， Google是最牛的， 应该以Google的翻译作为首选参考，Yahoo可以作为一个候选的翻译资源；Windows Live现在还不完善， 但凭着微软强大的技术实力， 我们有理由认为Windows Live在不远的将来有良好的表现。
现在的版本已经集成了Google， Yahoo， Windows Live， 金山。 WorldLingo暂时还没有。
现在发布的这个版本已经完成了好几个Windows和Web类型的应用， 应该说在已经完成的应用上继续进行本地化国际化改造， 效率是非常高的， 同时操作也很简单。 如有需要的同仁 ， 可以到http://www.dotnetcoding.net/ResourceCenter/BlueSky.GlobalTool.zip下载
