設計一種方便在線編輯的文件組織方式

[lotem]

Rime 詞典（我傾向於改日規範一下術語，叫他「韻書」）通常包含上萬字條、詞條，文件的篇幅較長，這導致兩處不便： 瀏覽、查找單字較爲費時，一些編輯器會卡頓； GitHub 無法在網站上直接顯示文件內容，因此也無法使用在線編輯功能。

設想制定一種或幾種可選的分類方法（好比圖書管理員的工作），把大文件拆分爲若干篇幅較小的文件。從而方便瀏覽和編輯。（但移動條目和全局排序、去重等操作比單個文件複雜）

現有的碼表引用機制可以利用。 或者，加一個編譯步驟，把源文件合併成單個用來部署的詞典文件（那還不勝直接編譯成二進制文件）。

（待議？）爲方便用腳本工具處理碼表，提議碼表文件用純粹的 TSV，省略 YAML 語法的文件頭。Rime 詞典文件則只包含 YAML 部分。

[lotem]

另一種解決方案是： 做一個軟件（或在線的工具），專門用來編輯詞典。（呵呵）

[ZoomQuiet]

On Tue, Jun 14, 2016 at 11:55 AM, 佛振 notifications@github.com wrote:

另一種解決方案是： 做一個軟件（或在線的工具），專門用來編輯詞典。（呵呵）

以 MVP ~ 最小可用产品 形式开始吧, 先发布一组最基础的 RESTful 接口, 可以令程序猿首先通过 CLI 开始高速在本地完成编辑/修订/搜索

证明可用后, 发布到线上, 然后,用 CLI/GUI/web/mobile 来包装成软件就好... 当然,最后这步社区来完成就好.

Life's Pathetic, Let's Pythonic! 人生苦短, Python是岸! 俺: http://zoomquiet.io 授: http://creativecommons.org/licenses/by-sa/2.5/cn/ 怒: 冗余不做,日子甭过!备份不做,十恶不赦! KM keep growing environment culture which promoting organization be learnning!

[kunki]

我人为在明月拼音和地球拼音中分开了单字和词组，每次处理时这两部分是分开处理然后再贴进去的。 做成单字和词组两个词典即可，再细分的话有必要吗？

[ShikiSuen]

線上編輯模式確實是個好主意，至少大家不用都非得走 Git 的流程。

[lotem]

@kunki 單字本身也太多了。還需要細分。 可以參考寫程序的做法，大於500行的源程序宜拆分爲更小的模塊。 讓每一個文件都能在 GitHub 在線閱讀和編輯。

[lotem]

@ZoomQuiet 看到不少用 GitHub 寫書、譯書的協作項目，還有各種妙用／濫用 issues 和 wiki 的。 如果能摸索出一套高效利用 GitHub 的方式，就可以省掉很多開發成本。 我感覺關鍵在設計一套流程和編碼規範，而不是用什麼形式的工具。

[ghost]

GitHub 本身就不太適合非程序員使用，而且只有英文。假如分開放置後依然是在 GitHub 上編輯，我是沒什麼興趣。

[ghost]

不過我支持把 YAML 和 TSV 數據分開放，而且把 YAML 的內容轉移到 schema.yaml。

[lotem]

用 GitHub 是上手最快的，不需要搭建任何生產環境。而且在線編輯的話可以直接發起 Pull Request，方便廣大非技術員貢獻代碼，比如加詞、除錯這種小任務，門檻低才能有更多人參與。

當然，我不是說＊只能＊用 GitHub 訪問。完全可以用 git 命令行工具、代碼編輯器和本地腳本製作一個專門的工具包。

[ZoomQuiet]

2016-06-15 16:35 GMT+08:00 佛振 notifications@github.com:

用 GitHub 是上手最快的，不需要搭建任何生產環境。而且在線編輯的話可以直接發起 Pull Request，方便廣大非技術員貢獻代碼，比如加詞、除錯這種小任務，門檻低才能有更多人參與。

當然，我不是說＊只能＊用 GitHub 訪問。完全可以用 git 命令行工具、代碼編輯器和本地腳本製作一個專門的工具包。

支持这个想法,这其实也是 github 生态成长这么快的原因, 通过统一的简单的 git 命令接口,来持续的扩展一切必须的功能.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Life's Pathetic, Let's Pythonic! 人生苦短, Python是岸! 俺: http://zoomquiet.io 授: http://creativecommons.org/licenses/by-sa/2.5/cn/ 怒: 冗余不做,日子甭过!备份不做,十恶不赦! KM keep growing environment culture which promoting organization be learnning!

[ghost]

依然不太贊同，即使有 git，貢獻者得注冊 GitHub 帳戶跑到 GitHub 用不了解的 Markdown 編輯器來討論，通過 email 也可以，但得先關注 issue 和收到通知郵件。

[ghost]

我認爲一般用戶只要能輕易做到這幾點就夠了：

• 同步最新方案和詞庫
• 确認沒有錯誤配置
• 确認錯字錯拼并非来自用戶詞典（有點麻煩，但對缺詞問題無影響）
• 快速上報錯漏至开发者並能得到回應（可以用 git 或更小巧的 diff 生成 patch 發送郵件）

[lotem]

@jakwings 也有道理。 不過這越來越像是商業軟件的做法了。開發者需要做更多的工作。 我之前提出的設想，畢竟假定「用戶」是積極的開源參與者，目標之一是讓用戶分擔開發者的成本。並且可以「去中心化」，每一名貢獻者都可以經過同樣的流程做到同樣的事情。用戶和開發者之間沒有了截然的界線，項目就活了，我好坐看大家來開發 Rime :)

[ghost]

@lotem GitHub 的界面操作也要學習成本，也很難想象普通人快速上手 git 的分支操作，想增加 review 的人數實在不容易。再加上不了解各個輸入方案的 review 有多嚴格，merge 的時候得解決衝突（只有場面熱閙時才會發生），最終負責 merge 的人可能也僅有少數。

因此我不認爲開發者能輕鬆多少。假如能把 diff、review、patch 的過程盡可能簡化就能使得學習成本大幅降低，一般用戶就比較好上手了，開發者只須負責 merge 並調解各個 patch 之間的衝突就行了。將這些提交做成任務列表會是這樣的：

• [x] 對 CommitXXXX 的修改：修改原因（查看 diff）
• [x] 對 CommitXXXX 的修改：修改原因（查看 diff）
• [ ] 對 CommitXXXX 的修改：修改原因（查看 diff）（等待审核）
• [ ] 對 CommitXXXX 的修改：修改原因（查看 diff）（审核通過）

用戶同步最新方案時將相關 commit 信息保留，用戶作出修改後將 commit 信息附到 patch 中提交到任務列表，並參與討論。

至於被 diff 的原文件該怎麼查看，且不卡頓，Windows 用戶可能比較方便，爲強大的 Notepad++ 做個插件就好，用戶基數應該也比較大。Linux 用戶想必能折騰，盡快讓他們學會 git 是最好了。Mac 用戶的話，還沒想到什麼小巧的工具能幫得上忙。 把大詞庫折分也行，不過我看了一下 luna_pinyin.dict.yaml，發現詞條是按 Unicode 編號排列的，檢索不便。除此之外，沒有相關工具也不便從多個小詞庫查詢，所以便民工具是少不了了。那還要不要分拆詞庫呢？

[LEOYoon-Tsaw]

我的建議是學習蘋果，把詞典文件變成一個文件夾，還叫「xxx.dict」，然後在文件夾裏放置各字典組份和字典屬性文件。 組份文件可以按常用字/非常用字分類，也可以按編碼序分類，不過不需要限制，讓作者自己決定就好。

[LEOYoon-Tsaw]

@jakwings 你說的這些都是工具，而這裏談的是文件組織方式。你對新工具感興趣很好，但請不要在不相關的話題下討論，這樣很浪費其它人看Issue的時間。我建議你另開一個Issue以討論工具。

[ghost]

@LEOYoon-Tsaw 拜託你了解一下 lotem 之所以要拆分詞庫的初衷。GitHub 上各種愚䘄的 issue 見得多了，你是不是也要搞精英主義？

[kunki]

@lotem 目前词库文件行数太多，没法在github上直接显示出来，这的确是个问题。 但是细分成几十个小文件的话，对于维护者来说似乎不太友好。若是要排重，或是批量修复某一单字读音，需要检查所有文件，客观上增加了开支。 除非能想到比较可行的方案解决这个问题，否则我是不太赞成这么做的。

[LEOYoon-Tsaw]

@jakwings 你上面說的一堆對本問題沒有任何幫助。初衷也不是問題的核心所在，不管用甚麼文件組織方式都可以開發更好用的工具，你說的那些更多是針對Github不方便之處所提，而並非是Rime詞典格式造成的。 另外，我不明白這和精英主義有甚麼關係，你要扣這樣一個帽子給我？ 如果你只會對人，不會對事討論的話，這裏不歡迎你。

[LEOYoon-Tsaw]

@kunki 這個可以寫兩個腳本實現，一個負責把分散的文件合併，另一個負責以某個標記爲準把大詞典拆成小的。

[ghost]

@osfans @xiaoqun2016 @boboIqiqi @Kahaani 歡迎參與討論。

---

是誰偷偷摸地删了我的评论？那我補充一下：

@LEOYoon-Tsaw 你的觀點十分鮮明而堅決，我想聽更多人的意見。

[ghost]

@kunki 修改我之前的提議內容時可以說一聲嗎，我不知道你改了什麼。

[ghost]

關於上面提案補充一句，以免有太多誤會：任務列表可以是 GitHub 本身提供的 issue/pull request 功能，我主要是建議簡化流程罷了。

[lotem]

不要吵架。不要吵架。Rime 獨門絕活都有啥？誰答對了我就支持他。（《韻坷垃》）:-D

---

有用的討論。贊成集思廣益。 確實可以分成兩個（相關的）問題：一是設計和改進 Rime 使用的文件格式，二是改進該文件格式的「用戶介面」，即瀏覽、編輯、分享代碼的工具。

---

就文件格式而言，正巧我有計劃改造配置文件的實現，使得 YAML 文件之間、節點之間可以更方便地相互引用。並且取消打補丁後保存到文件的設計。 這項改進會影響今後組織大量 YAML 代碼的方式。@jakwings 提到把 *.dict.yaml YAML 部分合併到 *.schema.yaml 。這在目前並不合適，至少會造成多方案共用的詞典中的配置參數被反覆抄寫。而未來可以把任意一段共享的代碼另存爲一個 YAML 文件，在各個方案中引用。介時 *.dict.yaml 可以只爲方便共享而存在，語法上可以等同於寫在方案文件裏，把 translator/dictionary 擴展爲一個 map。

而碼表保存爲獨立的 TSV 文件，解析和用腳本處理都更方便了。只要稍加改造，讓詞典配置部分 import_tables 支持導入 TSV 文件就可以實現。並且，import_tables 本身就支持導入多個碼表文件，具體怎樣組織碼表，方案作者可以自由掌握。 我拆分碼表爲多個文件的設想：有些方案的碼表可能比較容易拆分，比如中古漢語按照廣韻的編排方式，相同韻目的小韻排列在一起，二百零六韻各對應一個文件。字形輸入法可以按字首的取碼拆分，等等。關鍵是要有一個界限明確且爲編寫者熟知的規則。

---

我也想要一個好的工具，但不知需求大不大，現在只敢想想。簡單說說吧。 大概是，前面提出了那麼複雜的格式，還要劃分文件什麼的，開發者的業務水平接近對程序員要求。 也許有一個好的用戶界面，能夠按照後臺編制好的索引檢索、排序，那麼研究音韻、方言的同學們都可以用他維護碼表——不僅是得到了輸入法碼表。簡直可以成爲一個開放式的《韻典網》，導出爲輸入方案只是其中一項功能。（可想而知還要添加很多，比如添加任意註解的能力，彙總多音字等）我已註冊了域名 rime.io 預備做這個。具體做成什麼樣，還沒設計好。

[boboIqiqi]

支持一下 @lotem 大大。 虽然还没有完全搞明白， 我们是要做一个开放的词库编辑共享平台， 像搜狗输入法那样，可以定时更新细胞词库。 像wiki一样，让大家都可以编辑添加词库，这样我们也有一个不断演进的词库。

挺好的，建议还是做成一个工具，集成到小狼毫里。 可以随时本地编辑以后，更新到云端。这样参与的人会更多。

简单的beta版，后台可以直接装个git软件。（反正现在硬盘内存都足够大了） 我们提供一个简单的前台图形化界面，但是所有后台操作，都在通过调用git. 这个过程对用户是透明的，这样可以解决易用性问题。 所有的同步操作，都在本地通过命令行调用git的接口实现，

• 修改本地词库，就是commit本地github仓库
• 更新到云端的操作，就会push到github仓库，发pull request
• 帐户，每人申请一个，提交的词库文件用它自己的用户名命名。

然后管理员，定期对所有提交上来的词库和词频进行整合。然后，更新服务器的下发给普通用户

• 普通用户每天会从远程仓库 pull来更新本地词库

这样做的好处就是，不用考虑云存储，版本管理，在线同步等问题。

反正beta版，大家测试，建个临时仓库，内部人员先试试用一用。 功能最重要。后期用户多了，可以考虑更好更安全的方式

@jakwings 你是我的第二老师，仅次于 @xiaoqun2016

[kunki]

@jakwings 我啥都沒修改，就是對候選框有些好奇，點了然後又取消了。

[boboIqiqi]

关于码表编辑，我试着用 Excel编辑码表，发现Excel不支持不带bom的utf-8格式的文件。带bom后，\t <tab>键又识别不了。 后来，就照网上说的，把改成ANSI编码，就可以用Excel打开编辑。

改成TSV,当然比较好，码表本来就是一个表格。 ID可以通过文件名指定来引用，不用文件头也可以，还避免了数据的重复和不一致。

但是编码格式不能用excel打开，还是比较麻烦的。 Excel主要的好处就是直观，有很多函数可以使用，主要是用来排序（按编码，按词频，按汉字）和进行筛选。去重什么，删除低频词汇等等。

对普通用户可能会比较好，但是，码表太大，也确实是一个问题。

要定义一下我们的数据结构，互相的引用关系

[kunki]

@boboIqiqi 建議用 notepad++、vim、EmEditor、sublime 等（我平常使用的編輯器）打開碼表文檔，再貼到 Excel 裏頭加工，而不是直接轉爲 ANSI。否則所有的擴展區的字會變成問號。

[kunki]

@LEOYoon-Tsaw 就你說的「另一個負責以某個標記（我姑且稱之爲「錨點」）爲準把大詞典拆成小的」而言，在匯總後的大文檔中這些錨點的相對順序是不能打亂的，導致我不能愉快地使用 Linux 裏的sort、uniq、grep、awk 等工具來處理碼表。 其體驗會比沒有錨點糟糕多了。

[boboIqiqi]

@kunki 谢谢， 这个是好办法，直接复制，不是转文件格式。 你们说的锚点是yaml中 用 &id定义， 用*引用，再用 <<: *id合并 我以前看yaml格式说明的时候，有关于这个的介绍，不知道Rime现在支持吗？

还有，我用陈桥五笔，发现它自带一个工具，可以对本地的文件和指定的网页网站，进行分词学习，从而生成一个词库。我们也可以学习一下。先自动生成一个词典，在手动进行编辑，但是词频，我就不知道怎么弄了。

[ghost]

我覺得還是另開 issue 分開討論碼表修改和新網站構思吧，轉移到 rime/home 會比較好。這裏太偏僻了。

[LEOYoon-Tsaw]

@kunki 寫一個vim script生成標記就行了

[kunki]

@LEOYoon-Tsaw 那索性不要标记，直接500行自动切分文件就好了。（不过这样对于每个小文件来说，每次或多或少有偏移，提交后的diff会很丑）

[boboIqiqi]

我之前提出的設想，畢竟假定「用戶」是積極的開源參與者，目標之一是讓用戶分擔開發者的成本。並且可以「去中心化

赞一个 这个也可以通过后台调用github 实现，多建几个仓库。分领域维护。每个领域有几句权威的审核员。 用户可以加载词库源时指定多个信息源，就是仓库。我们定期发布权威仓库的地址

对于用户学习github 成本高，可以前台封个简单的界面，但是具体实现都是后台调git, 这样用户可以在本地随意编辑，用文本或者表格

关于佛振老大 @lotem 的问题，rime 的独门绝技。 我发了一个帖子，请老大指正 rime 的独门绝技 菜鸟书评

[shyangs]

git 絕對是門檻，上次 @wenketel 想幫我翻譯MeihuaCC簡中語系, 問我怎麼做，我說這不是 clone 一下再編輯就好了嗎, 最後他直接在網路上貼給我一篇翻譯文字.

附註： wenketel 是有能力寫長篇教學文的，請見 貼吧 Firefox吧

再註：Firefox相關的腳本常用 .js, .json 作為設定檔，也常見使用者漏掉逗號和引號，造成腳本不工作. yaml 似乎沒前述那個問題.

[ShikiSuen]

要不要考虑我这样的辞典格式？： https://github.com/ShikiSuen/MOEChewinTable4macOS/tree/master/MOEDict_Plists

是说这是我给 macOS 内建注音制作的词库纠偏档案， 使用大量正确的定义来淹没 macOS 内建的词库。 但这个辞典格式比较标准化一些（只可惜不包含词频）。

[Prcuvu]

我认为可以参考@ShikiSuen的方法，以第一码分割文件。不过，光是第一码并不一定足以分割到可以在线编辑的程度，需要根据输入方案的特点进行进一步的分割。

不过，正如@kunki所说，

若是要排重，或是批量修复某一单字读音，需要检查所有文件，客观上增加了开支。

GitHub在线编辑的功能有限，为了照顾这些情况，可能要制作并维护更多的工具。问题是如何在人工检查的成本和维护工具的成本之间找到平衡。

[ShikiSuen]

@Prcuvu 說到排重…似乎可以由腳本代勞吧？

[ShikiSuen]

@Prcuvu 另外，竊以為不能僅按照第一碼分類（不然有些條目的內容實在太多）、而是最好按照第一個字的所有可能的注音拼讀來索引。

[lotem]

確實很難保證切分的尺度又直觀又恰到好處。

---

經過這幾天間斷的思考，我傾向於保持現在的文件格局（格式今後應當做擴展），做一個外部工具用於瀏覽和編輯，然後生成 git commit、甚至推送分支、發起拉取請求。這個工具可以實現一個很好的功能：碼表的正則變換，即從一個音系推導另一個有對應關係的音系。做成在線的系統，還可以多人協同編輯和校對。

[boboIqiqi]

顶@lotem 佛振大大。按照佛振大大的想法，如果能够在线编辑多人维护词库，就能充分发挥开源的威力。相当于我们也有了一个实时更新的词库。而且维护人员比搜狗的更多，更广泛。

我觉得我们现在就可以试着按你说的做一做了。 工具是给非github用户使用的，可以逐步完善 程序员可以先试着，然后根据使用效果， 优选那些，重复度高，而且实现代价小的功能，封装起来做成图形化界面 大概的步骤，我写下来，抛砖引玉，

1. 先建好仓库（可以分门别类多建几个，方便管理）
2. 本地编辑，git提交
3. 通过import_tables引用到自己的输入方案中
4. 日常使用，再不断维护

另外，还有一个问题，不同方案间词库共用的问题。 不知道是不是我没有理解清大家的意思，或者缺乏什么知识。 我是想，比如我添加了一个新词”知乎“，我希望不同的输入方案用户都可以受益。 然后就是统计词频的问题了。 现在的码表格式，是比较通用的。但是对于五笔等形码用户来说，不需要一个绝对的词频。 只需要按QQ码表格式，区分一下重码时的词序问题就可以了。

所以，既要兼顾通用方案的词频排序，又要考虑码表编辑者的编辑代价。 这个是一个比较难的问题。 "知乎“，这个词一直没收录，但是，我把它的词频设为多少合适呢？ 对我来说，只要跟重码的那几个词区分来就行了。对于跟我一样用wubi86的也可以接受，但是这样的码表，给了其他输入法用户就不好用了。或者考虑修改的输入方案，比如在手机使用双键的五笔用户，也不好用了。

我能想到的一个解决方案。 添加了新词以后，提示用户重码的词 (可以自动生成编码显示给用户吗？） 然后用户手动编辑，各个词的词序。系统自动生成一个词频，这样就不用输入一个很难确定的绝对的词频了。

可以将这个工作分割开。 有些人专门提交新词，调整好自己方案的重码，就可以用了。 有些人可以对这些新词，进行整理，将它移植到各个常用输入方案。确定词频，或者只是排序，自动生成词频。 或者说大家都以现在有词频为基准，重码时，在它的基础上，+1或者-1。 这样update以后，不需要对原来的码表做改动,只用import_tables就可以用了。

还有一个问题是，update更新的词库与自户现有词库的合并策略。 就是，我将一个词放在前面，但是别人不用将它放在后在。 update下来后，如何在本地合并。 这个不知道有没有什么好的方案。