游戏人生

不积跬步,无以至千里;不积小流,无以成江海。

My Links

Blog Stats

引擎设计跟踪(九.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, 工具栏(浏览导航和翻译查找等)是插件自己负责添加的.

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

 

 

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

bladelang-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扫描文件时按照时间戳排序就可以了. 唯一的问题是为了处理MBCSWCS的问题, 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), 这个翻译问题也有想过, 简单写了接口但是还没有真正去做.

posted on 2015-12-13 19:19 crazii 阅读(...) 评论(...) 编辑 收藏