大家好呀, 我是一名个人开发者, 很多年一直在开发和适配一款全平台( iOS / Android / Mac / Windows / Web )支持 mdx 的词典和语言学习的 app
除了尽可能地支持 mdx/mdd 的各种特性, 也尝试了一些提升查词体验方式:
为了避免广告, 此处不提及 app 的名字。发这个帖子的主要是一直想要和大家讨论一些问题：
-
由于app开发工作强度比较大, 本人几乎已丧失任何社交属性。在扩展语种支持的过程中，对词典包的采纳我采取了最讨厌的拿来主义，对于释义详尽的词典包，拿来即用，没有进行任何对词典包作者的申请和沟通。唯一心安理得的理由是，app 坚持对词典功能永不收费的初心。接下来会尽可能地去和词典原作者取得沟通，在这里也挂一下我自己。
-
可以在本社区发布 app 吗? 很多细枝末节的功能，如果能及时地讨论，对于开发者和使用者都会产生极大的帮助。
-
app 功能再华丽，离不开一个本源：词典数据的完整性和准确性，才是一个词典的灵魂和根基。纵然强如欧路，Moji，稍微细致地推敲，依然存在很多错误。在过去，我写了一个简略纠错逻辑，用户可以圈选文字进行纠错，收集到大量的词条纠错反馈。但是这个功能的存在一些硬伤：
用户提交的纠错反馈，质量不一，可能是错上加错，甚至可能把本来正确的内容改错。
同时, 由于纠错机制基于词典功能运行逻辑后的结果进行纠错，随着 app 的迭代，纠错范围可能错乱，导致纠错词条失效。如果在纠错时直接展示原文数据，对于用户是一种极大的心理负担。如果根据纠错结果反推到原文，对于开发者也是一种极大的精力和心理负担。所以正确之法是适当地采取纠错内容, 并加以审查, 然后将原文数据打包成新的词典。如果这个步骤进行顺利，未来会在 Github 发布基于纠错和词条优化编撰的词典包版本更新。
-
当我开始着手词条编撰时, 对于这件无比艰辛的事情有了具象化的认知。这些浩瀚的辞海，在作者无数个日夜挑灯校对下，浓缩成一个精简的数据包。然而我看到的是，除了在词典论坛存在具体的讨论和关注外，它们被流转于淘宝咸鱼店铺批量打包，在小红书评论区被无数遍地私私私, 没人关心这些词典包的来源, 更不会知道背后的作者是谁。词典作者们的大爱无私，我看不懂，但大为震撼。
-
目前 app 比较成熟支持的语种有意大利语, 日语。接下来我会开始法语，西语，韩语的语言特性支持和词条编撰。本人也是干中学，期待能和志同道合的朋友一起走下去。
11 个赞
如果获取许可, 会公开 app 名字, 已经上线啦。
目前DictTango和深蓝相较高下，也非常期待楼主的东西。好东西多多益善。
amob
8
有必要吗，mdx作者又没有著作权，大家都是小偷。
你真要取得沟通，不如和原书作者取得沟通。
3 个赞
谢谢大家！！截图和 App 说明来啦, 都在图片里了。还有很多App开发和运营方面的问题想和大家交流，但是今天可能要写代码了。上午的朋友试用英语直接卡住，实在惭愧。
对于不同语种的支持，请随意评论交流！！需求越急开发越快，最近在参加西语角可能最近会写西语。
1 个赞
MDX 的生态大家都懂，哪怕是现在如日中天的 AI 后面不也是偷嘛。
开这个帖子的意义是看看能不能遇到真正厉害的大佬，一起把这件事情好好做下去。比如联系原书作者这件事。
现在的互联网风气都流行辛辛苦苦剪一周无人问津，随时一拍火爆全网。实在让人泄气 (礼貌用法)。
1 个赞
amob
11
你们没做简繁互查吗？
日语完全能基于形态素分析库做变形活用的查询。
1 个赞
有做, 日语截图里就是用 “勉强” 简中查询的, 库的作者（NoHeartPen / Kanji2Hanzi）也在论坛里, 一直没联系。
活用形的显示和反查也做了, 后续还会推出变形练习。(做的过程发现, 有意思的是某知名日语词典的很多变形竟然是错误的, 我记得好像有 “しる”)
这是之前写的稿一直没发
1 个赞
建议桌面版默认禁用文本选择，需要文本选择的地方再另外设置样式：
/* make it more native-ish */
*,
*::after,
*::before {
user-select: none;
-webkit-user-select: none;
}
1 个赞
amob
14
测试了下，第三方辞典导入貌似不加载css和mdd？
这个社区用习惯了mdict、goldendict、dicttango直接去安装mdx作者发布的辞典，原始的css效果无法实现的话，不太迎合这里用户的习惯。
应用内似乎也没找到加载js的地方。
以下都是我安装的社区词典，直接应用内下载的，居然没人反馈过问题？
这么看来，之前的用户应该都主要简单使用内置的几本辞典？原生的那几本效果挺不错的。
1 个赞
amob
15
我会用了，mdx、mdd和css要一个个点击添加，太不人性化了吧。。。没有任何一个辞典软件这么做。
不支持多个mdd也是硬伤啊，这么看来也不大可能支持一个词典用好几个css。
css要求和mdx、mdd必须同名？不知道是从谁开始流传出这种说法。我刚入门当小白的时候也听从这种说法，把所有文件改成一个名字，css和js全失效没加载。。。
作为开发者是否要反思下自己会有这种误导性的说法？开发者是没有制作过和解包过词典吗？或者是没当过网页前端？没见过html文件和css文件一定要同名的要求。而且绝大多数的mdx词典都不是mdx和css同名的。。。
社区词典里的文件杂乱也没有维护，mdd和css大半是缺的。
基本的词典功能都有问题，主要开发目标是背单词吧？
1 个赞
感谢提供诸多问题的反馈! 强度很大! 压力上来了!
-
目前的确不支持 js 和多 mdd, 我接触的样本也比较少。不过今天见识到了。会尽快适配。
-
大部分时间在优化主词典的适配，结合不同语言特性，优化词典和学习的 App 逻辑和交互逻辑。
-
目前的目标用户 90% 不知道 app 还可以添加扩展词典, 也不知道 mdx 是什么。连 app 本身也没什么人知道，即使有少用用户交流，大多也都是学习问题而不是词典问题。词典方面，我平时几乎无人可交流，所以来论坛深入交流和探讨问题。
-
强制要求同一词典的各个文件需要保持统一的文件名，只是一个糟糕的妥协策略，可以探讨一些可行的方案：
前提: 据我所知 mdx 词典没有 BundleID 这样的机制 (大概? 欢迎指正) 来保证词典的唯一性和关联性。唯一可用的信息是 mdx / mdd 词头 Title 里的词典名。
可能问题: 同名词典如何处理 / 同一本词典的版本更新, 如何处理
可能方案:
- 支持一次性选中多个文件, 或持续选择文件的交互提示
- 验证多个文件是否属于同一词典
- 创建一个类似文件夹的页面, 管理同一词典的多个文件
- 创建版本管理机制
-
社区词典: 这个模块可能会下架，因为在 app 做好合规问题之前，这个模块做得越好，app 死得越快。接下来会考虑一下, 到底是不怕死的好好维护这个模块，还是直接下掉。像现在这样确实尴尬。
amob
18
你想多了，加载什么css和js本来就会写在mdx的html的引用内。只需要要求mdx和mdd同名就行了，css和js放在那里不用管的。
xwang / mdict-analysis — Bitbucket
自己把mdx的逆向源码读一遍。那么长的头部设计，还不方便你检查唯一性？我不理解关联性是什么意思？
amob
19
问这些问题前你应该去把同类软件都用一遍。
我自己加的第三方词典怎么更新？下载了覆盖文件不就行了。
读源码你要搞死我? 
我多测试一些样本吧, 理论上 mdx / mdd 词头信息的 hash 是一致的, 得看样本测试结果。如果词典作者每次更新有加入版本信息，版本问题也可以解决。
这个功能的别扭的核心原因在于没有用户，没有反馈。有需求的话可以打磨好的。
css/js 资源的问题, 因为方格单词架构的原因, 不读文件系统的文件夹, 没有路径的概念, css/js 是直接注入的, 因此文件名不重要. 目前加入同名的限制, 确实会导致破坏 mdx 内容里内联文件名的规范, 导致别的 app 读取异常，存在误导倾向。
hua
21
还挺好看的，要想将 MDX 支持好的话是挺困难的，可以将先内置词典打磨完善，可以走“精”的路线。
MDX 的结构不算复杂，看到这儿最下面的结构图了吗，尽在此图中了。
