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

[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 的方式，就可以省掉很多開發成本。
我感覺關鍵在設計一套流程和編碼規範，而不是用什麼形式的工具。

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

不過我支持把 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!

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

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

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

[lotem]

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

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

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

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

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

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

[LEOYoon-Tsaw]

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