关于词典新格式的讨论

目前使用最广泛的格式是mdx,而mdx有如下几个“痛点”:

  • 不能实时修改,改动需要重新打包,成本高昂
  • 格式不完全开放,相关工具链不完善
  • 索引和排序混乱
  • 动态交互支持性不足,索引“不可编程”
  • 软件生态的支持参差不齐
  • 松散混乱的数据结构,不方便“再利用”和统一化
  • 不方便多人协作编辑

当然,mdx的好处是:

  • 高压缩率
  • HTML 的自由排版

鉴于此,本人打算利用现有的技术开发出新的词典格式和相关工具链,并完全开放底层设计和工具源代码。所需要实现的基本功能有:(原括号内是可行的技术实现,若不清楚可以忽略)【方括号内是相关技术的参考来源】

  1. 规范化的数据结构兼顾HTML的自由排版
    (JSON存储+渲染模板)【静态网站生成、大数据】
    注:绝大部分在线词典都使用的是这项技术,其中渲染采用的是服务端渲染(server-side rendering),故用户端看到的只有生成的HTML,而看不到后台的JSON(储存在数据库中)

  2. 完善的css样式框架,方便排版和统一样式,同时兼顾不同词典的特色板块,自带默认样式,无需编写css即可实现美观的样式
    (css重置、预设库)【前端框架】
    注:如今绝大多数现代网站都是采用了开源或者自制的框架,因此样式一旦设计好,便可以自由发挥,不同的板块也能统一样式,并且无需重复编写css。诸如scss等也使得css可以互相引用、定义变量、缩写等等。

  3. 支持实时编辑,图形界面编辑、实时预览,无需重新打包,兼顾尽可能高的压缩率
    (tar+zip存储,或者引入File System in File)【非关系型数据库,大数据存储,科学数据存储,热备份】
    注:说白了就是编辑JSON,渲染引擎已经有现成的了,实现实时预览完全不是问题。压缩方案等早有现成的实现。

  4. 完善的索引系统,可编程
    注:这里涉及到一些算法,难度较高,不做展开。

  5. 基本的动态交互库,诸如折叠,隐藏,切换等基本的操作无需编写js代码即可实现
    注:同2,提供基本的js框架,参考jQuery

  6. 可与主流编程语言无缝交互

  7. 支持版本管理、跟踪和多人协作
    注:多媒体数据属于“冷数据”,无需频繁改动,直接打包即可。而词条数据、渲染模板属于“热数据”,作为原始JSON进行编辑和版本管理,直接套用git实现协作管理。而HTML作为渲染数据,是程序生成,用户不可见、不必编辑、不必跟踪管理,直接解决了HTML不方便编辑的痛点。

以上功能的实现已有可行的想法,若能得到大部分人的支持,同时愿意有擅长技术的加入进来,进行软件或者插件的编写,本项目将会在不久之后开始。

9 Likes

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

提供规范的数据结构,class是自动生成的,用户不接触HTML相关的编辑,包括tag,class,id都是程序生成。类似于写c++代码,用户无需关心具体CPU所需的机器码一样。

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

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

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

举个简化版的例子,类似于静态网页生成,

首先我们有一个规范的JSON,包含的是词条信息:

{
    "lemma": "test",
    "stems": ["tests", "tested"]
    "type": "noun",
    "def": "a procedure intended to establish the quality, performance, or reliability of something, especially before it is taken into widespread use."
}

和一个渲染模板:

{{lemma}}
<div class="{{key}}" for item in root if item.key != 'lemma'>{{value}}</div>

程序便会生成

<div id="lemma">test</div>
<div class="stems">
  <span class="item">tests</span>
  <span class="item">tested</span>
</div>
<div class="type">noun</div>
<div class="def">
  a procedure intended to establish the quality, performance, or reliability of something, especially before it is taken into widespread use.
</div>

对于本来获得的是HTML的数据,规范化也相当容易实现。需要注意的是:获得的HTML几乎都是程序按照上面的方法生成的,那么我们就反过来还原出JSON就行了。这样的程序我早就写好了,类似的工具也不少。

给个数据规范的参考:https://dictionaryapi.com/products/json
关于渲染模板,这个很像Vue.js这种框架

并不浩大,重要的在于能不能得到支持

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

顺便提一句,我制作的所有词典(很多因为技术测试没有公开),从数据抓取、存储到生成,都是按照上面的思路来的,因而都是流程化作业,编辑的过程从未涉及到HTML。其中不乏不规范甚至有错误的网页。重要的在于工具的便捷性,重复洗数据并非易事。

当然还包括基础的库,例如抓取无索引数据的word list,phrase list,启发式抓取模式,跟踪抓取模式,基本的限制绕过等等。相关工具传送门:https://github.com/alirezamika/autoscraper

为什么要洗数据呢?这才是问题的核心,它无非就是两个原因:

  1. 数据获得时,处理的方式就不正确(本应该同时解析HTML,但是大部分人没有,各种框架的标记都还没删除,就一股脑直接扔进了mdx,甚至!!!广告的div和iframe都还在。)
  2. 数据本身有少量错误,这当然是后期协同完善该做的事情,因为现在没有完善的协同编辑和版本管理,所以很混乱。用户反馈错误不方便,作者修改打包很头疼。

规范地处理HTML应当普及开来,工具已经有不少了,缺少的是一种交流和共识。(例如该删除的就不应该用css隐藏)

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

让人感觉复杂的原因,主要是工具不完善,还有制作者中没有普及这样的技术。既然实现了多人协作,不妨将不同的工作分开?抓取、解析、完善、订正这些,并不需要作者一人完成。

普及这样的技术也并非难事。

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

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

LaTeX和字体属于渲染技术了,则需要对词典软件做一些修改,有的词典软件采用的内核很旧(或者某些奇葩原因?)所以不支持。渲染技术早就不是什么问题了,支持起来很容易,关键是有人参与开源词典软件的维护,这是词典格式所解决不了的。

第一点很重要,其实也是这一问题的初衷。很多人可能觉得HTML转JSON再转HTML是多此一举,或者难度很大,然而事实正好相反。举个例子:若要合并两个不同来源、不同类型的词典,若有规范的JSON,这太轻松不过了!

解决的方案在于普及意识完善工具。就我了解,词典制作社区对HTML的认识大多不够,不是技术方面,而是HTML的使用方面

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

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

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

个人之前观点参见

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

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

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

这点非常赞同,关于后续的具体实现可以讨论。

JSON只是作为当今前端的主流而优先采用,并没有强求先进行转换,或者不妨用程序自动实现?技术小白只需点点鼠标。

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