deleted

(帖子被作者删除,如无标记将在 24 小时后自动删除)

5 Likes

1、所有的mdx编译工具:编译源文件后,词条的先后排序信息丢失,以致无法还原。这对于中文等存在多音字的情形就是个灾难,无法正确还原;对于图片词典等更是糟糕,特别是按照笔画、或先按某个机制分类再按拼音排序等非字母排序的图片词典来说,前人辛苦整理的词条,就难以被正确还原,从而无法充分地重新利用了。

案例:https://www.pdawiki.com/forum/forum.php?mod=viewthread&tid=41323

2、与1好像是相关的问题:pdawiki的众多词条提取工具(input词头,output完整的词条内容),无法按照原始的Input词条顺序,输出相同顺序的词条内容,几乎都是按拼音顺序重排了,这很不便于学习应用。

这里置顶的众多工具都有此类问题:词库制作交流区 - Dictionary-Making - Powered by Discuz!

3、图片词典制作工具 MdxSourceBuilder 虽然开源,但采用vimscript编写,非python等大众语言,阻碍了更广泛的应用。

2 Likes

第2条输出顺序混乱,是因为打包工具重排了,没有原始的顺序。

详细说明一下,我所说的第2条问题与您理解的还是有点不一样:

原始词条顺序(A,比如按笔画顺序排)==>词典顺序(B,很可能是按字母顺序排),我现在input一个词条列表(C,可能是某个课程的词条,可以是任意排序,其不同于A的排序),希望导出的顺序也是C(注意:不是A,也不是B。仅仅是提取出txt源文件,没有经过再次的mdx编译),但得到的却是D(通常是按字母排序,与B的排序好像一样)。

这个C==》D的问题与从A==》B的问题,虽然有点类似(两者的处理方式好像都是不管原始的排序,通通转换为按字母排序),但又不是一回事:这是由两个独立的程序(mdx编译、词条提取),分别出现的问题,不能都怪到mdx编译程序。

1 Like

可以指定导出词条列表?只用过 mdxexport 和 mdict-utils,不都一起全导出的吗。

很多工具都可以导出指定的词条列表。

我见过的最好用的是这个,它会按提供的顺序输出,没有上述问题,而且可以输出html\pdf等各种格式:

1 Like

补充一个:

诸如 A@@@LINK=B,B@@@LINK=A 的循环引见的情形其实是有真实需求的,
因为A另有具体的定义,B也另有具体的定义。但这种循环引用会造成一些词典程序的崩溃。

这种使用规范应该有较为明确的定义,避免不同词典程序的兼容性问题。

1 Like

还是应该避免循环引用的情况。要是有工具能检测就好了!

这个就不清楚了,只知道有的软件支持得好一些,有的则经常崩溃。

MDict碰到这种情况直接卡死。

ubersoft 兄:
若借鑑 Babylon or Lingoes 詞頭的格式是否可行,

abandoned child|Child
abandoned child
foundling, orphan

abandoned, deserted|abandon|abandoned|deserted
abandoned, deserted
forlorn

abandoned ship|abandoned|ship
abandoned ship
hulk

abandon (enthusiasm)|abandon|enthusiasm
abandon (enthusiasm)
elan, exuberance, spontaneity, wantonness

abandon, give up|abandon|give|give up
abandon, give up
relinquish

abandon idea, habit, friendship|abandon|abondon idea|friendship|habit|idea
abandon idea, habit, friendship
renounce, repudiate

嗯嗯,我誤解了以為是架構異動且以自動生成為標地

灵格斯对重复的词头是怎么处理的?

good|well|best
n. 好; 慷慨的行为; 好事
good
adj. 好的, 上等的, 优良的

mdx 可以指向重复的词头。

well
@@@LINK=good
best
@@@LINK=good

道理一樣的,只是若是把詞頭這樣編輯,較不會弄混,只要弄個程序去自動處理成@@@LINK 就好了,且,除了可以放形容詞比較級,動詞的三態和分詞, 也可放重要的thesaurus ,也就是編輯歸編輯,生成MDX 要用的,歸mdx 要用的,編輯的模式可以規劃幾種不同的型式來生成,交流也就用編輯的模式來當原稿,這樣不就解決了嗎?

1 Like

格式也不是什麼重點,只是大家想要有原始的編輯原稿而已,以利除錯和再次加功或擴充,那不如規劃幾種通用的模型,甚至打包時把原始的text打包在mdd內,那解壓時也就能再次依此加工

灵格斯的格式更容易弄混。

good|well|best|goodness
n. 好; 慷慨的行为; 好事
good
adj. 好的, 上等的, 优良的

语法上看, goodness,更倾向指向名词的 good,而不是形容词的 good。

brother n_ogizaka46
good<==well | best | goodness

只是借鑒用此編輯的方式來轉跳到good 這樣也集中一點,至於要轉跳的詞頭則編輯的人來自行決定
然後再經一個程序去轉換 成mdx要生成的格式

这种语法上有歧义的跳转,会让打包解包程序很困惑。打包的时候,不知道 goodness 应该指向所有 good,或者名词性 good。假设打包的时候指向所有 good,解包的时候所有 good 可能都会加上 goodness,或者加在错误的 good 上,无法正常还原。

数据与HTML混在一起,很难二次利用,比如在Vim查询词典,若出来的都是HTML标签,那就没法看了。

1 Like

Vim 兄,您說的沒錯,最好的解決方法還是弄成像mrp 或 erp 表單的處理方法,以數據庫建資料,每一欄的欄欄位以幾種 html 的標簽來包裝輸出,但這樣處理又頗費功夫,但好處是,每欄可以成為一個Key的篩選和輸出想要的資料
當要導出時也是導到數據庫的格式,這樣就可以比較符合您的想法,只是一開始要洗數據,把數據弄到不同的欄位並非易事,且資料庫並不太好定義,因數據呈現的方式太雜,不是很好規划,最多只能弄幾個通用的模型來規範,先轉換舊的mdx檔,若順了,才比較有可能順著一個模型操作下去