居戎氏

> 那就是说截图软件把自身的层级设置的太高了是吗？ 沒用過。不瞭解。

Same issue: https://github.com/rime/home/issues/870

```yaml patch: translator/enable_completion: true ```

_From @ShikiSuen on November 27, 2015 4:58_ 擊/击，ㄐㄧˊ，單獨敲這個音的話會找不到這個字。

_From @ShikiSuen on November 27, 2015 6:44_ 和（ㄏㄢˋ）已被修正： https://github.com/rime/brise/commit/2d271a28666e150ecedf55c21af8ce57f23492fa

_From @jakwings on November 27, 2015 6:56_ https://github.com/rime/home/issues/

coding 匠的普遍信念是，很多難纏的問題可以通過技術手段化解。 突然想到，應該設計完善碼表的標註功能，指明讀音的來源、性質，還可以提示出對應的正音，這樣即使是錯音謬音都可以放心收錄了。

回顧過去，這個話題上的討論集中在以下幾點： ## 技術選型 須衡量： * 開發成本 * 跨平臺支持（也是考慮開發成本的一個因素） * 安裝使用成本 * 衆包（腳本化）的難易 ## 數據的下載、升級 須實現： * 本地文件管理 * 下載內容與用戶自定義內容的整合、與部署程序的交互 ## 數據的組織與發佈 涉及如何向安裝工具提供下載內容列表，如何組織數據文件，以及如何長期維護這個列表和數據文件。 數據文件的組織方式主要有 * 集中收錄輸入方案 * 配方化與數據的分佈式管理 --- 題主兩個方案，提出了兩種不同的介面交互設計，這個問題比較細節。我現在說不準哪種設計更合理、更易用，等實現出來再對交互做調整也不遲。 過去嘗試一些跨平臺的圖形介面技術，如...

> ### 网站下载的可能性 > 我发现我有点困在了client side，没有想到website的可能性。作者你认为有没有可能让rime的server收录方言方案去让用户自行下载并且帮他们保存在default folder里面。这样当他们打开小狼毫设定/鼠须管重新部署的时候作者你的程序就可以检测到方言方案然后提供用户勾选。我觉得这样比在client side重新去implement GUI界面和逻辑更为方便。作者你觉得呢？ 我覺得這不就是現在小狼毫的實現嘛。用戶自行下載之後，本地就可用了。額外的GUI是無必要的。 題主您在研究了GUI的方案之後也換到了/plum/現在的實現思路上。 server： https://rime.im/download/#%E5%AE%89%E8%A3%9D%E6%9B%B4%E5%A4%9A%E8%BC%B8%E5%85%A5%E6%96%B9%E6%A1%88 其實不需要專門的server，用github就完全足夠。 如果說還要「幫他們保存到」本地的一個指定位置，這個無法從server控制，可以用到 /plum/ 的[Windows啓動工具包](https://github.com/rime/plum#windows-bootstrap-script) 把要下載的github鏈接拖到快捷方式圖標上，完成「下载並保存」這一步。

@laubonghaudoi 基本同意。感謝您的不懈努力。 我希望延伸您的提議如下： > 在小狼毫安裝包中無需自帶所有方案，只需要記錄一個列表，即所有配方地址 「在小狼毫安裝包中無需自帶所有方案」是目前的方向。 甚至更進一步，只自帶滿足開機體驗（指安裝輸入法之後立即開始工作）的最基本數據（`minimal`），包含一個精簡的拼音方案。鼠鬚管已經採用了這種打包方式。這樣做的想法是，輸入方案都是不斷更新的，勤於輸入法程序的更新，因此沒有必要讓用戶下載安裝（越來越）陳舊的數據文件。（目前還不成立，因爲配方下載和管理的功能不到位） 而配方列表，我也希望在安裝時取得最新的，畢竟要下載安裝方案就必須聯網，沒有必要打包一份陳舊的列表文件。這樣可以支持最近添加到列表的新配方，以及配方地址的變動。 再進一步，安裝包只需要包含一個URL，指向配方列表的列表，這個元配方表是相對穩定的。 我對方言拼音方案全集這個項目的期待是，最終簡化爲維護一份配方列表、並包含圍繞這個項目的流程文檔的輕量級代碼庫（不是必須的：安裝時只須下載配方列表文件，但代碼庫體量小可能方便協作，協作者能快速clone下來修改、交PR。https://github.com/rime/brise 這樣改造過，包含衆多方案的歷史記錄留在`archive`分支，新建了一個只維護配方列表和工具腳本的分支，最終這個新分支的代碼移到了 https://github.com/rime/plum 因爲巨大的代碼庫會拖慢其他（輸入法前端）項目的編譯。） （不是必須的：如果希望在拆分的代碼庫裏保留變更履歷還得用一組複雜的git操作如 https://github.com/rime/brise/blob/master/scripts/split-packages.sh ） 再解釋一下「配方列表的列表」的設想（尚未落實到plum的實現，下面會說到其他的現實問題和計劃）。 我認爲按照專業和興趣維護一組有共性的輸入配方，比維護一個「大一統」的窮盡式配方列表要現實。This is my feeling. 除了方言輸入方案，還可以有專注於字形輸入法的，專注於少數民族語言的，甚至只專注於一個比較窄的領域、滿足個人、小團體的興趣愛好。這種自治管理，放在整個互聯網的尺度下是比較有效的。他們只須向「元配方列表」註冊一次，而不必針對每次改動向集中式數據庫發PR。 好的GUI，除了展示各個配方列表的內容，還應提供另一個入口，允許用戶指定未收錄的配方地址，方便未登記團體做小範圍的分享測試。 我們接下來要做的是設計、規範這套流程，並開發所需的工具。 GUI在我的設想中是最後一步，否則當如何組織配方中的文件、如何獲取配方的詳細信息沒有規範的話，GUI就只能提供有限的選項，並面臨不斷修改擴充功能還要保持向前兼容的被動局面。 現實問題是bash腳本的實現目前用戶接受度不夠好，批處理腳本又比bash實現功能弱，不足以支持未來的升級。我打算忙完現在的項目（語言模型插件）之後，用「嚴肅」編程技術重寫配置管理器，保證個平臺下無依賴運行，作爲最終GUI的後端。 至於GUI，針對具體平臺開發也行，我傾向於實現一個本地webserver，借助用戶的瀏覽器做GUI，免除GUI庫的安裝依賴，或可節省開發成本，但還這個方案還沒確定。 另外，我申請了一個域名 rime.io 將來可以用作瀏覽元配方表的用戶入口。...