|
|
2楼
楼主 |
发表于 2015-7-28 09:37:51
|
只看该作者
顺便说说 i-wiki 引擎的一些想法
本帖最后由 imfirefly 于 2016-1-18 09:46 编辑
制作 维基百科、维基文库、维基词典时，目前论坛用的最广泛的应该属于 i-wiki 引擎了吧，不得不说，确实很好用，但本人在此次使用中也发现了一些问题，在这里说一下（当然，这里并没有对 i-wiki 不敬），如果 i-wiki 能改进是最好了。
1.处理效率还可以进一步提升：
目前处理前还需要将单个大 xml 文件拆分为小于 128MB 的小xml文件（这里没有问题），然后 i-wiki 处理的时候是对分割后的小文件一个一个顺序进行处理（这里有优化空间），这个效率太低了。个人觉得此时可以采用多进程处理方式，比如把拆分后中的10个小文件放进进程池里，分5个进程来同时处理5个小文件（当然也可以分更多的进程来同时处理，具体进程数取决于电脑处理能力和总的小文件数目），这样可以加快处理的进度。
程序只能一次处理一个xml文件，对于目前的大内存电脑来说是资源的极大浪费，建议可以指定同时进行几个转换处理，充分利用CPU资源。
观察到 i-wiki 支持多个实例同时运行，因此目前可以用变通的方式来实现多个文件同时处理，那就是将 i-wiki 引擎复制多份，也将拆分后的小文件分别移动到多个 i-wiki 引擎的文件夹下，然后启动各个 i-wiki 引擎，就做到了多个文件同时处理的效果。下面是开了两个 i-wiki （注意: i-wiki 要复制到不同的文件夹下）同时处理两个文件的效果图：
2.没有异常中止后重新运行继续上次进度的功能：
由于词典制作过程中，一般数据量比较大，耗时较长，如果这个过程中出现了转换错误、停电等意外关机、磁盘空间不足等可能导致 i-wiki 引擎异常中止的事件，那么重新启动 i-wiki 引擎，目前是做不到从上次中止的位置继续处理的，如果不手工做一些繁琐的处理，可能那些异常中止的任务就需要从头来过，这无异于噩梦一场。
如果 i-wiki 引擎能对处理进度做一些实时记录，或者能通过对已制作的文件进行分析找到中止前的处理位置，那么这个问题就可以解决。
3.目前的渲染引擎还不能针对手机页面做出自动调整：
据我所知，维基百科官方客户端（Android）在手机端的页面排版效果就非常好，值得借鉴学习。
具体见我以前发过的这篇帖子。
4.生成的MdxBuilder.cfg 文件中默认的词典描述信息的图片标签有问题
详情见这里。
5.处理后只会在data目录下生成中文维基百科的Logo图片( wiki.png)
如果可以智能化地根据xml源文件名分析，生成不同语言、不同中维基资源的Logo 图片最好了，如zh-wikisource.png, en-wikiquote.png等，那就相当方便了！
6.不能定制转换完成/失败后的动作
由于维基百科类词典制作耗时一般比较长，这样就很可能要无人值守运行，什么时候转换完成失败事先无法知道，如果能定制转换完成/失败后执行特定操作（如：运行命令/脚本、发邮件/短信通知、关机/休眠等），那就相当好了。
对于出错的词条，程序直接是出错退出，对于数据量不小的维基百科数据文件来说，批量处理无人值守是常态，目前一旦出错，没有自动化的应对之策。建议这样处理：将出错词条信息（完整的<page>……</page>信息）写入异常文件（便于用户最后手工处理），然后跳过该词条继续处理下一个词条，直至处理完毕。
注：对于出错的词条一般式编辑错误，后续用户可以自行登录维基百科页面申请修改词条，一旦该词条问题解决，后面的处理操作就不需要再手动修改了！
7.没有将单纯的重定向词条转化成MDX词条内部重定向
见这里：https://www.pdawiki.com/forum/fo ... &fromuid=174639
临时的解决方案：https://www.pdawiki.com/forum/fo ... &fromuid=174639
目前，暂时就想到这些。 |
评分
-
1
查看全部评分
-
|
发表于 2015-7-28 09:37:13
