辞書の管理する仕組み

[azu]

https://github.com/azu/prh.yml
https://github.com/azu/technical-word-rules
とか辞書を管理する仕組みとツールが欲しい。

コンテキスト

• プロジェクト固有の辞書を持つのは正しい
• ただし毎回プロジェクト固有の辞書に汎用の辞書を追加するのは管理が大変
• 辞書は漢字の開きとか、固有名詞とか大文字小文字の統一があり人の好みがでてしまう
  • そのため汎用性がイマイチ
• 辞書はpublicにおいて、バージョニングして管理したい

事例

technical-word-rules

• https://github.com/azu/technical-word-rules はJSer.infoのやつの辞書として開始した
• APIとして常に最新の辞書を取れるようにしてる(ブラウザで動かす辞書として意識されている

prh.yml

• https://github.com/azu/prh.yml は漢字の開きとかよくプロジェクトにコピーして使ってるprhの辞書をまとめる目的で作った
• git subtreeでコピーして使うのが目的で作った
• これは https://github.com/github/gitignore を参考にした

求めるもの

• 大きく分けて2種類
• 何も言わないで全部を取り込んだ形で利用できるもの = オレオレプリセット = technical-word-rules
• 利用者が必要なものだけを選んで利用できるもの = prh.yml

利用方法は2種類あるのだけど、ソースは一つにしておきたいというのが求める仕組み。
(実際の上の辞書はprh.ymlをソースにしてtechnical-word-rulesが生成されている)

類似研究

• コーディングルール
• 翻訳メモリ
• Wikiによる辞書
• IME

[azu]

辞書の典型分類

Date: 2017/05/08

Status

議論の余地があり

Context

prh.ymlを使った場合の辞書には大体の分類が隠れていると思われる。
幾つかのプロジェクトを調査し、典型的な分類をまとめる。

Decision

• https://github.com/asciidwango/js-primer/blob/master/prh.yml
  • ドメイン固有
  • typo
  • 文体
  • 漢字の開き
• https://github.com/azu/JavaScript-Plugin-Architecture/blob/master/test/prh.yml
  • ドメイン
  • typo
  • 漢字の開き
• https://github.com/prh/rules/blob/master/README.ja.md

    languages
        各自然言語固有のルール
    terms
        技術用語のルール
        商標やツールの正式名称などのルール
        各種ツール固有のルール
    media
        各媒体固有のルール

• https://github.com/yamauchi-inochu/demo/blob/master/prh/gis-ja.yml
  • 表記の統一
  • 固有名詞
• https://github.com/kn1kn1/sonic-pi-ja-lint/blob/master/prh.yml
  • typo

Consequences

ドメイン固有、固有名詞、表記揺れ(typo)が主な構成要素に見える。

[azu]

https://github.com/proofdict/proofdict
opinionatedなルールを管理する仕組みを作った。
これをもっと気軽にforkできる形になればいい気がする

[azu]

辞書管理アプリみたいのがあるとよさそう。
だけどその場合はどこにデータを保存するかという問題が起きそう

[azu]

proofdictの仕組みを元に、もっと一般ユーザーが使える仕組みを作りたい。
データはGitHubに公開しておくとメリットがある形にすれば、辞書の再利用性が高まる。
GitHubのリポジトリを管理するコストもあるけど、それを超えるメリットを用意すればもっと良くなりそう。

既存の辞書(prh)などの問題点はローカルにコピーして使うため、プロジェクトごとに毎回コピーしたりして面倒臭いところ。個人ごとにテンプレ的な辞書はあると思うので、そこを補える形にしたい。

辞書のフォーマット

prhをベースにしたもの。
通常の辞書のように品詞に特別な意味を持たせる。
nounならマッチ規則が変わる。(これをtagsにするのかは再度検討が必要そう。カテゴリ?)

• https://github.com/proofdict/proofdict-tester/blob/41b56eb32caba70b67a61df7966f33563f0a0498/src/TagFilter.ts#L4

idは1ファイル=1辞書をしっかりルール化すれば、必須ではなくなるけど自動生成的には合ったほうがよさそう。

# `id` is unique string
id: 01BQ92YYBEFBXEHH8T8HC8RCRD
# `description` is a short comment
description: 'Reference https://www.ecma-international.org/publications/standards/Ecma-262.htm'
# `expected` is expected result
# `$1` ... `$9` reference `patterns`'s capture word
# This is same behavior with RegExp https://github.com/zeeshanu/learn-regex 
expected: ECMAScript $1
# `patterns` are match string or RegExp
# RegExp should be started with `/` and be ended with `/`
# Also, can use `()` for capturing
patterns:
  - /ECMAScript([0-9]+)/i
  - /ECMA Script([0-9]+)/i
# `specs` are test cases
# `specs[n].from` is actual word
# `specs[n].to` is expected word that is replaced result
specs:
  - from: ECMASCRIPT5
    to: ECMAScript 5
# `tags` are keywords
# Some `tag` means special meaning
tags:
  - noun
  - JavaScript

辞書のファイル名

• 任意のファイル名を使える
• 指定ディレクトリにおけばよいというルールにする
• そのためユーザー自身がファイル名の重複を管理する必要がある。

データの管理

• proofdictをベースにした yaml ベースの 1単語 = 1ファイル
• データはJekyllのcollectionを使ってウェブから見られるようにする
  • https://jekyllrb.com/docs/datafiles/#example-organizations
  • Jekyllのテーマを作り _config.yaml に定型文を入れるだけで動くようにする
  • CIなどの特別な設定もなく https://github.com/azu/mini-jekyll ぐらいのファイルにする
• Jekyllのテンプレートを使い、辞書を1ファイルにまとめたJSONを吐く
  • これをAPIとして利用できるようにする
  • https://github.com/proofdict/proofdict/blob/gh-pages/dict.json ではCIでビルドするようにして作っていた。ただこれはCIが必要になるのであんまり優しくない
  • JekyllのテンプレートならCIなくてもAPI的にjsonを返すURLを作れる

データの更新

• 専用のエディタ https://proofdict.github.io/editor/ をJekyllのテーマに組み込む
  • GitHubに対して直接Pushできる
• 専用のアプリ(優先度低め)
  • ローカルにリポジトリに直接更新できる

何かしらのツールを通す意味は、検証済みの辞書を作らないと意味がないため。
直接ファイルを変更した場合に簡単に崩壊するので最初から検証しながら作れるGUIが適している。
( https://github.com/azu/technical-word-rules の経験的にそうしないと上手くいかない。)

Notes: ローカルでのチェック

ローカルでも手動でチェックできるようにproofdict-testerなどを使って簡単なテストを行えるCLIを作る。
CIを通して更新するフローもサポートしたい。

データの使い方

textlint

textlint-rule-proofdictを使い、指定したリポジトリからJSONをダウンロードとして辞書として使えるようにする

• ユーザー的にはリポジトリを更新すれば勝手に辞書が更新されるイメージ

ローカルからも指定したディレクトリ(辞書ファイルのあるディレクトリ)を指定すれば、読み込んで利用できるようにする。
これで、プロジェクトごとにも辞書を持ちやすくする。(更新する手段が少し問題となるので、アプリみたいなものが必要かもしれない)

その他

• 辞書は単なるYAML(単体)
• APIは単なるJSON(集合)

なので他の用途にも汎用的に使えるようにする

[azu]

proofdictをリファインしてる