Delphi程序之多语言支持

    最近在做一个多语言的项目，感想颇深，写出来与大家分享。

 

    首先抱怨一下，谁让这个程序是Delphi的呢，用C#或者Java写根本不会有那么多问题，唉......

 

1.现状

  Delphi直到2007才支持Unicode,但是事实是大部分的Delphi程序依然用Delphi6 & Delphi7编写。 指望通过Unicode来解决问题还是有相当难度的，要考虑的问题太多。

  如果是简单的多语言界面支持，难度就小了很多，目前有很多比较成熟的框架可以借鉴，解决方案大致分为三种，这里不详述了。

  第三方的技术框架提供了一种解决思路，但是更大的工作量体现在代码的重构与规范中。因为以前编写的Delphi代码由于没有考虑到多语言支持，在上了多语言框架后会有很多问题，因此需要规范此类代码。

 

 

2.技术方案

  1)最近我做的项目用的是CnPack的多语言框架，这个框架可以解析Delphi的dfm文件，从而将界面上所有可视化界面元素的字符串信息抽取出来，然后保存在文本文件中。另外，它提供了运行时遍历所有控件并更改控件字符显示的功能，因此我们只需要把注意力集中在翻译和其他一些特殊问题上就可以了。

  2)字符串常量的处理

  Cnpack抽取界面元素时无法处理字符串常量，因此需要将所有的resourcestring, string const, static string 全部变成 variable,并试用类似于 CnTranslationMgr.TransString(...)的调用在运行时为这些字符串赋值，从而使得这部分也能被翻译到。当然，字符串常量也需要在翻译的语言文件里添加。

  3)执行机制

  光有多语言翻译框架是不会让应用程序支持多种语言显示的，我们必须编写一些代码来完成这个任务。当一个窗体被创建时，它大部分的界面元素已经被创建了（动态创建的除外），最简单的办法是让所有的窗体从支持多语言的base form继承下来，或者调整让base form在其他基类之上。在Form的Loaded事件中加上CnTranslationMgr.TransForm(...)即可。对于字符串常量，在每个项目的开始加上TransConst函数即可。

  4)字体问题

  不同的语言有不同的默认字体，例如英文是Tahoma 8,中文是宋体 9。不过Cnpack已经支持了在语言文件中自定义字体格式，因此这个问题得以解决。

  5)字符长度问题

  不同的语言中单词的长度是不一样的，所以在设计界面时需要考虑到这点。通常需要将控件设置成左对齐或者右对齐，同时留出一定的空间（某些语言会比英文还要长，某些则很简短，比如说中文）以防止界面不美观。当然，最终还是需要做一些微调才可以。

  6)字符集问题

  由于Delphi程序不支持Unicode，所以某些语言需要特定字符集的支持，例如韩文，日文等。这个依赖于操作系统的设置，因此对客户系统环境提出的一些要求。

  7)动态创建组件问题

  上面所说的所有都是静态的界面元素，某些界面元素是动态创建的，这时就需要修改代码去支持多语言的显示。

 

   至此，一个多语言程序基本已经完成了，虽然不是很完美，但是已经可以应付大多数的需要了。

 

 

3.缺点

  这个方案也有一些缺点。

  1)对动态创建组件的支持不够理想

  2)语言文件维护比较复杂