MDX词典制作工具研究[长期施工]

计划分三期完成:

  • 探讨制作词典时碰到的实际问题:

    • 各路制作工具的优劣对比,特别是writemdict.py的发展历史,及面对闭源mdx的尴尬处境
    • 各平台客户端goldendict, mdict, 欧路,对mdx的兼容性问题和差异
    • 讨论实际解决方案
  • 探讨周边工具:

    • 在线查词
    • 数据标注,统一样式
    • 实时编辑修订的可能性
    • 可订制的导入导出,如导出词头,导入anki
  • 新世代的诞生,参与推动下世代词典制作工具的诞生进程。

4 Likes

如果不考虑出新格式的话,这些问题就只能对症(各异的 mdx)下药。。。个人感觉还是数据差异性太大,导致软件的处理差异。

这是一个浩大的工程,我早已立项,无奈时间和水平都不够。这个项目我已搁置了。这个能解决

这个统一样式就需要人工的力量了,需要熟悉 CSS 的人来洗排版。

支持集思广益讨论。

关于统一样式这一点,我曾经也想把常用字典的外观统一起来(当然改css是上手难度低花费时间长的做法),随着对词典认识的加深,现在已经放弃这个强迫症了。原因:
一是各家大词典的编撰理念不同,词条内容独具特色,如牛津高阶的Which Word? / word finder / Homophones / See also / Vocabulary Building / More Like This / British/American等等等等栏目,导致其HTML标签的数量繁杂差异很大,很多标签是独有的。
二是样式多样化不是坏事。用多了之后,查阅词条一眼即可辨别是来自于哪一部词典,这个词典的特色长处是什么、这些地方需要特别多加关注。所以说,有区分度后查阅效率可能会更高。
当然,原始网站的css排版往往很难看,这时候选择你看得顺眼的网友改版css、在其基础上做微调是最省时间的。希望能把自己的时间用在刀刃上。

最后转引之前的回帖供参考。

并不是说不需要改进mdx不透明的打包方式,也就是说可以设计一种新的开源打包方式:
1、继续采用Web技术(HTML+CSS+JavaScript),最好跟现有mdx打包前的源文本一样,把规范表述清楚全面。因为各大词典上线网页是这个结构,app数据底层也是,这大大方便了电子词典的爬虫转换制作,而且也降低了一般人修改完善词典的门槛。
2、提供新的、开源方便的打包解包工具。
3、新的打包格式需要goldendict等软件支持。
4、要能解决mdx现有的痛点以吸引用户。比如,可以方便导出某词条内容(源文本及相关js & css)、方便修改某词条内容的编辑功能(错别字)、方便手动增加词条间跳转功能(也是一种编辑),等等。

1 Like

要实现对单个mdx词条的校对修改,
可否基于mdict-utils 将mdx解开为源txt文本(一个词条一个txt,可增加单个词条的txt),这样修改或增加词条只要打开相应txt。编译mdx时,可选择合并所有词条再编译、或者仅编译当前词条的源txt。如果不满意当前词条,返回相应txt 修改即可。
貌似主要的功能都有现成模块,麻烦在于GUI 界面设计。

实时编辑词典的需求很怀疑,HTML本身就不方便普通人编辑,容易打乱词条HTML的结构和层次,不适合分享,也不利于其他词典作者的二次加工提取数据重新制作,还是报错反馈让作者统一修改更好。

mdx 的解包,很多开源工具都做的很好,但打包都有排序黑盒的问题,部份词条stripkey后的排序结果和 mdxbuilder 的并不一致(skywind3000 和 lgmcw 有讨论过类似问题),如果词典软件依赖 mdx 本体里的索引去搜索词条,结果也会不一样,这点 gd 做的最好,重建了索引。

这点非常认同,统一样式很困难。

主要是有些词典想边看边改错,还想顺手加上跳转链接。目前来来回回的全编译有点麻烦。

在mdx里词头key和释义(record)是分开储存的,mdx前半段是key,后面段是所有record。但是key并不是唯一的,mdx允许同一个key出现多次,但是出现一次必须要有record对应。但是python的dictionary就不是如此,key是唯一的,对应唯一的content。我为了应付key重复的情况,把content定义成一个list,这样如果有多个对应的record,会把他们按顺序存入content list里。mdict软件对于每个词条的排序很讲究的,稍微排不好你就查不全dot,DoT,DOT这些样子的单词。
因为我需要自定义排序,而且原厂的mdxbuilder的会强行乱排序,mdxbuilder肯定是不能用了,所以我用writemdict来生成mdx文件。writemdict是开源的python代码,可以转mdx。原版的writemdict python代码,并不支持一key对多record的操作,你只能合并多出来的的释义在一条释义里,但这样弄的话,同时有释义和跳转的词就会失效,并且实际使用时会代码会漏显示出来在屁股后面挂一个@@@LINK这种。所以我动手改了writemdict的python代码,让他可以读我这种稍高级的content是个list的dictionary。这个改动可以顺利生成mdx文件。
然而关键的问题来了,在mdx二进制文件里的header里有一个字段表明了词头的数量。这个字段在writemdict原版里在代码很开始的部分被很随意地直接写作dictionary的key数量,这个在原版里确实没有任何问题,但是在我这儿就并不适用了,因为词条数是content里面record之和,而不是key数量。转出来的文件,goldendict并不读取这个字段,所以不报错,所以在goldendict里面没有任何问题。而安卓MDict读取mdx校验发现和实际不一致,有的版本直接闪退,闪退。ios MDict有的版本不闪退但不可以查后面的词,仅仅是后面的词查不到。导致报错的具体原因是有些词头(key)对应多个解释(Record)。但是python字典解构必须是一一对应,所以一个key下面对应一个数组,数组里每一条包含这多个Record。
相较于writemdict原版我主要改了两个地方:1. 在原版代码里,以前一个字典的key只能对应唯一个value。而MDict完全支持多个相同词头对应多个意思。所以我改了一下生成mdx的python代码,让他不只take一个record,而是用一个for loop 遍历take所有的record,让一个字典的key可以对应多个value。2. 修改排序算法。原版是用的默认python排序,输出的文件在MDict简直不能查,GD勉强能查。
不知道后面哪一步和我这个代码改动不合拍,结果就这样了。

  • GoldenDict 默认读取全部词条,然后存储在自己的缓冲区中,查询在缓冲区中进行,可以对全部词条搜索
  • MDict 严重依赖于词典自身排序,根据排序规则查找词条所在扇区块,然后再找到词条。如果排序不符合他的规则,即使有这个词条,但不能找到正确的扇区块,也不能定位词条
  • ecdic 更怪,他也依赖于词典自身排序,基本规则与 MDict 相同,但遇到特殊字符时,如 空格 减号 等,有时能查出,有时不能。闭源的软件,没办法…

词序排列的问题可参看这里

1 Like

用开源的 python 实现打包 mdx,在欧路上问题特别多,writemdict 本身的代码问题好解决,但 stripkey 的黑盒问题解决不了,preview 最初也实现了 mdx 的打包,后面就是因为这个原因去掉了,词典作者们要正式发版,推荐还是用 mdxbuilder3.0。

重复 key 乱序问题,倒是没想过,第一次看到。

jonah_w:好像默认是strip key的,这貌似会导致像’s -'s 之类的词条在打包后可能无法查询 链接

不知道作者后来解决没有。

如果继续拘泥在 MDX 这个格式上的话,就会补丁摞补丁,不同软件有不同实现和渲染方式,最后谁也搞不懂谁。

闭源不谈,MDX 也不是一种好的词典格式,只是历史沉淀太过深厚,改变不了而已。

1 Like

显然mdx 格式并不完美,但为什么它能流行这么广、持续这么长时间?这甚至超过了原作者的设计,因为他开发的格式4.0都 没能这么成功。

在我看来,技术门槛不高,能吸引新鲜血液的广泛、不断加入是最重要的原因。当然,问题是,现在某些方面需要统一的规范,但又不能一下子限制太多,建议慢慢来。