总的说来，这种方式有很大进步，但为了用ini文件，大家还要费力的破解64k的限制，更专业的方式是使用自定义的文件格式。
在简单性方面，无疑是这种自定义的转换引擎，[旧字串]=[新字串]的文件格式来得方便，借助字典管理工具，字典文件可以重复使用，也可以提供给专业翻译公司翻译。那么剩下的问题在引擎上，如何方便，最好用户不写一行代码;如何扩展性强，支持任意的第三方元件;如何有弹性，同一个画面有多种语言的文字，同一个词可以转换成不同的意思
4、给每个元件类继承一个子类，在子类的Loaded方法里转换文字。由于要处理的都是叶级元件（虽然TLabel、TPanel都是从TCustomControl来，但不能只处理TCustomControl），工作量比较大;对旧有程序除了换元件无能为力。
5、为每个元件类注册一个转换函数，引擎遍历Container，为每个元件找到血源最近的转换函数，调用这个函数转换这个元件的文字。这样可以不必处理叶结点，只需在恰当的元件层上注册函数;不必改动旧有程序。設計時Form上只需要放一個轉換元件，這個元件在Loaded后開始掃描Form上的元件，從for I:=0 to ComponentCount-1或從for i:=0 to ControlCount-1遞歸，找到一個元件就去查找其血緣最近的註冊函數，然後調用這個函數替換其文字。因爲註冊函數是額外加上去的，所以不會動到舊的代碼，對任意第方元件都可以擴展支持，且也不用去修改人家第3方元件的代碼。
我认为第5种方法很优雅，看起来比较干净。用GOF的设计模式来套，这属于Mediator pattern(中介者模式)。多年前，我们使用一个叫TXPMenu的元件来获得XP风格的界面，也是感觉到它很干净，一个元件就搞定一切，不用TLabel换成TFlatLabel,TButton换成TFlatButton我记得《程序员》上还有文章专门称赞这个元件。但那个元件没有使用中介者模式，不能很好的扩展对第3方元件的支持。
最后，我们畅想一下，如果我是Borland，如何在Delphi里完整支援多语言。Delphi提供了一个区块定义的关键字“ResourceString”，在这个区块定义的字串常量，编译器会把它编译在exe文件的资源区，运行时用LoadStringA这个Windows API来读取，因此有些外部转换工具可以直接从exe文件读取这些资源字串，再写入转换后的字串;内嵌的转换引擎也可以拦截这个API函数来转换文字。但是如果exe里的字串资源化不彻底，就无能为力，这个不彻底恰恰来自Delphi的DFM文件，Delphi把DFM文件整个作为一项资源放在exe里，其上的字串就没法决定是否要don`t resource（Delphi源码里很多常量字串都有这个提示）了。
如果除了string,widestring,ansistring等等这些数据类型，delphi增加一种数据类型multistring，然后修改vcl元件定义（拜托Borland连同Unicode一起解决了吧），像TLabel.Caption定义成MultiString，对MultiString类型，有一种专门的处理方法，如类似ResourceString用LoadString API来处理，每次读取就转换一次，但应该比这个内容更多，比如要传出instance，然后提供一个全局的ApplicationMulti元件，类似ApplicationEvent，让外面能捕捉到。至于字典，只能外部用户提供（当然可以制定一个标准格式让delphi人都可以共享交换）。
此法看起来可行，但还有个效率问题要考虑，（1）每次读取都转换，对频繁draw的东西效率低;（2）比如一个ToolBar有好多的ToolButton，批次更新时一般都会用BeginUpdate/EndUpdate，vcl如何告知后代来提高这种效率。（补记：效率看起来不是问题，
