delete_______

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

12 Likes

不同词典的标签,class 属性值都不一样,怎么实现这个呢?

感觉是一个浩大的工程,相当于做两件事:第一制定一个规范;第二实现一个规范。如果能完成,那必定是巨大的贡献。

我是说,现有数据很多都是来自网站,而网站的数据是已经生成好了的。

你的 规范的数据结构 怎么去规范不同的网站数据呢?

这就是强制制作者洗一遍数据。我预感难度很大。

为什么不洗数据呢,这就是mdx成功的原因——简单。

支持,技术上我不懂,从需求和使用上来说希望能 支持/具备 这些 功能/特性:

  • 尽量让词典制作更加简单。这样能让更多的非技术人员也能上手学习制作,这对词典社区的扩张和持续的生命力有百利而无一害。
  • 能轻易自定义字体。这对解决特殊字符和生僻字有好处,也方便喜欢自定义字体的朋友。
  • 希望能支持 LaTeX。这对不少理工科词典的文本化有好处。

提取JSON这块没明白,像提取 MWU2020这种数据困难吗?现在清洗数据还是用正则。

这个论坛讨论过多次了,因为大家都对mdx由于没有统一规范而产生的问题(有打包工具环节、也有词典软件环节的)深感不便。

这么多讨论下来,感觉步子迈的越小越好,渐进式改进。因为见过太多过于宏大的计划要么搁浅(工作量太大),要么没反响(技术过于脱离现状)。最大的建议,要方便刚刚入门的新手从抓下来的HTML网页制作成词典。一个圈子门槛过高,来来去去之后如果缺少新鲜血液的加入,那肯定不会有多少活力,而最终归于沉寂。

个人之前观点参见

目前的一大痛点是,现有mdx打包工具writemdict(或基于writemdict的mdict-utils)的排序缺陷

这些帖子还有其他人的真知灼见,不妨看一下。

因为你繁琐的转换做在前面了。。

A 词典 例句在 <div class='liju'></div> 里面, B 词典例句在 <p class='ex'></p> 里面。C 词典例句在 <span></span> 里面。

楼主和我刚入圈时的想法差不多,浪费了我很多精力,新格式确实要有,但一定和 mdx 类似。

部份词典的结构已经修乱了,还有如oed,mwu这样的大型词典,分析 html 结构定义 json都很困难。

渲染模板有个兼容性的问题,科普也是个问题。

实时编辑我认为是伪需求,文本编辑器+正则,已经被那些词典大佬们,用的出神入化了。

有多少人参与是个问题,词典真是个很小的圈子,都还各有所爱。

2 Likes

常用的模板渲染引擎都试过,像vue,jinja2 在goldendict qt5上报错,handlebars 在 qt4 上报错,如果要输出静态 html 导出别的格式,前后端渲染的api还有兼容性差异问题,有些特性,后端不支持,比如jinja2的各种 filter,给用户科普这些差异也很麻烦。

如果真考虑做这块,推荐最简单的mustache,ie7也支持。

很怀疑。oed 这种,程序怎么分析?提取 json,是你后面所有一切的大前提。

我觉得讨论这些问题,有时候有点像在思考开源项目和社区的成败得失、正反经验哈。

MdxBuilder 3.0 确实容错性很强,听说有些txt用其他开源工具编译失败但用官方的可以成功编译。

不过,其同key词条排序确实很有问题。
比如两个key均为elder的两个词条,在 txt 原文本中的顺序为


编译后查询elder显示为

这种情况的出现不止一个key如此,而且貌似是随机的。在对别的词条进行编辑后,下次再编译成mdx,这个elder的顺序有可能又正常了或者仍然不正常。

这种情况一种不是解决方法的办法见

1 Like

这个想法不错,不需要懂技术即可把json 转成 html

没想过 GUI 可以这么搞,感谢指教。如果这一步实现,后面所有词典都可以这么来,那就是造福社区了。

期待楼主大作!

mdict-utils 已经解决这些问题了