引擎设计跟踪(九.14.2j) TableView工具填坑以及多国语言

Blade的UI都是预定义的接口, 然后由插件来负责实现, 目前只有MFC的插件. 最近加上了TableView的视图, 用于一些文件的查看和编辑, 比如前面在文件包的笔记中提到需写一个package exploerer, 以及多国语言相关的笔记中需要的lang-edit-tool, 目前Blade还没有简化的二进制数据表, 如果有的话, 这个视图也可以用用于Database的编辑, 同时这个view也已经加到了max导出插件中, 用于定义多个导出动画.

 

设计的思路是用MVC, 记得以前还想专门写一些代码来"练习MVC", 但实际上是, 代码写多了, 不经意间就会用MVC, 而且这次是写完以后发现竟然用的是MVC, 当然实际中未必跟标准的MVC完全一样.

这个TableView在Blade中叫ITableEditorWindow : IEditorWindow, 是一个公开的接口, 其具体实现注册到Factory<IEditorWindow>, 客户代码使用工厂创建对象.

他对应了一个controller, 用于实现导航. Blade内置了一个controller, 其导航方式类似Exel, Enter下一行, Tab下一列列, Shift+Enter和Shift+Tab相反等等, 一般情况下客户代码不需要自己实现controller, 因为内置的这个已经足够用了,当然如果有复杂的需求可能需要定制controller.

 

窗口视图上的工具栏, 是客户代码负责添加, 并绑定对应的功能, UI只负责添加工具, 与业务逻辑无关, 比如下面两种文件, 使用的是同一个view, 工具栏(浏览导航和翻译查找等)是插件自己负责添加的.

这主要是接口设计的问题. 对于翻译工具, 可以选择多个可视列, 用于对比和参考, 这个主要是用于翻译的.

 

 

下面主要备忘多国语言的问题, 前面提到了大致思路, 思路是很简单, 实现起来是还是有很多问题的.

blade的lang-build tool是一个CLI工具, 它会把所有的源文件(.h,.hpp,.c, .cpp,.cc,.cxx等等), 甚至包括了win32下的rc文件, 全部读取并扫描出可翻译的原始字符串, 保存到字典. 然后就可以用lang-edit插件来翻译了.

可翻译的字符串前面已经提到过, 使用一个宏, 比如XLANG("Hello"), 这样就可以识别XLANG这个宏, 并扫描字符串了.

XLANG宏定义是一个开关, 如果开启多国语言, 就会调用接口来翻译, 如果关掉多国语言, 那么就使用原始字符串.

遇到的问题:

1.同一个单词, 在不同语境下意思不同.

这个问题一开始就遇到了, 但是不太好解决. 比如Parent, 翻译为"父节点"还是"父空间"等等. 注意如果是整句话的时候, 这个情况一般是不会出现的, 因为一句话本身就有包含了自己的语境. 目前的解决方案是: 如果两个文件中发现相同的字符串, 而且两个文件的工程路径比较远, 就报错. 这样用来提醒程序员, 这两个词可能会有歧义, 需要修改.

比如把简化的"Parent"改为"Parent Space" 和"Parent Node".

当然相同意思的字符串本身可以在不同文件中共享使用, 但不能直接使用, 因为会当做错误报错. 只能用过预定义宏来使用, 比如

#define EDIT "Edit", 所有文件中都可以使用XLANG(EDIT)来使用这个字符串.

这种方式很黑(hacky), 不太好, 用起来也不友好, 而且并不能真正完全解决问题. 好在lang-buid-tool已经集成到了VS工程, 并且报错的时候会有原文件和行号, 跟编译错误一样, 可以双击直接跟踪, 方便修改.

 

更好的方式: 添加语境上下文. 比如类似于TEXT("Parent", "transform space"), TEXT("Parent", "node hierarchy") 第二个字符串就是context, 他会被收集起来用于翻译, 运行时也作为sub Key来索引翻译项.

Blade没有使用这个方式的原因是多了一个参数, 感觉稍微有点不方便(也不太适用于目前的视图), 而且很多时候明确不许需要context, 比如一个完整句子, 那也必须写一个参数, 即TEXT("blah blah", "")

 

2.扫描源文件, 需要解析条件编译.

首先, 如果真正要扫描一个文件, 需要把它包含的头文件(递归的)全部加入(#include),这个问题比较容易解决.

其次, #if #else/#elif #endif需要选择扫描有效的分支, 这个问题变得更复杂, 因为#if ABC > EFG甚至#if ((ABC*3) <= EFG || (HIJ != OPQ)) && XYZ需要对表达式求值. 

另外, 宏的嵌套. 比如

#define A "A"
#define B A
#define C B
... XLANG(C)
这个时候需要展开宏定义到最终的字符串.

 

整个问题差不多需要手写一个pre-processor, 而我也差一点要做这个功能, 但是想了想还没有这个必要, 所以没有做.

所以目前采用的是暴力的方式, 即不处理#include, 扫描所有文件, 所以, 条件编译以及对应表达式求值还没有解决, 一些#if 0对应的分支, 也会把字符串加入, 会多一些无用的翻译.  而且如果两个文件各自定义了不同的宏定义, 也会冲突.

而我公司因为使用的是公司自己写的编译器, 这个功能已经内置到编译器里去了...所以在pre-processor就把无用的文本strip掉了.

 

3.运行时强制翻译的字符串的收集.

前面提到, 一些字符串是在win32 .rc文件里面, 也是UI显示时强制翻译的. 工厂中的类名不能翻译(翻译了之后创建对象也会跟locale相关), 显示时需要动态翻译, 也就是不适用XLANG()来直接加入词典, 而是在UI模块显示的时候, 手动调用翻译接口.

那么对于这种字符串, 因为没有用XLANG(), 所以lang-build-tool不能识别.  现在的解决方案是, 使用另外一个宏, 比如XLANGRAW() 从而上lang-build-tool识别并收集. 实际上XLANGRAW()并不会调用翻译接口, 只是为了后台工具扫描加入词典.

如果使用context的话, TEXT("String", "NOLOC") 即使用一个特殊的context来标记这个字符串不需要翻译.

 

总结

总的来说, 目前的实现比较简陋, 而且可以预见一些问题, 如果加上context, 就不会有冲突的问题了, 而且复用的单词不需要统一使用宏来定义, 用起来更方便. 最好的方式是XLANG可以接受一个或者两个参数, 通常只用一个参数就可以了, 只有遇到单词冲突时, lang-build-tool报错, 这个时候再加上第二个参数-context都来得及, 这种情况相对少很多. 需要注意的是, 如果一个文件的字符串跟原有文件的冲突, 那么就提示修改过的文件处的错误, 而不是原有文件, 这个在lang-build-tool扫描文件时, 按照时间戳排序就可以了. 唯一的问题是为了处理MBCS和WCS的问题, XLANG必须是一个宏, 如果想要接受不同的参数, 需要使用variadic macro, 这个是C++11才有的特性, 所以目前不考虑. 不使用宏也可以, 使用函数重载:

cosnt TString& XLANG(const char* originalString);

const TString& XLANG(const char* originalString, const char* context); 但是在使用WCS并且关闭翻译时, 需要在runtime, 最起码在第一次使用时, 进行MBCS/WCS的转换: 把原始字符串转换为一模一样的wstring, 效率会有损失. 而且进程镜像中的MBCS常量被浪费了, 需要额外保存WCS字符串, 多耗费了内存.

这个问题准备先放一放, 后面有时间考虑一下再说.

上面只是源代码中文字翻译的处理(以程序员为用户), 实际上一个游戏的文字很可能是由策划使用一个工具来填写(比如大量文字的AVG), 这个翻译问题也有想过, 简单写了接口但是还没有真正去做.