表記の揺れ(過去に作業された)を手軽に調べる方法

[uakms]

結論

速くて使いやすいツール or 方法をご存知でしたら教えてください

とりあえずこのようなものがあったらいいなぁと

問題点

みなさんの協力によって翻訳作業が進んでおります。指をくわえて見ることしかできず申し訳ありません。

さて、協業ということで訳者の癖がどうしても出てしまい、かつて統一され(使わないとされ)た用語が再び使われてしまうことがありました。これは仕方のないことで、今後も発生していくことを前提とした何かが必要だと思います。

私の把握している範囲で、統一されてきた用語の一覧を #37 に貼りつけました。80 程度ですが、翻訳の作業中にこれを確認することはあるでしょうか？(いや無い)

機械的にある程度の確認はできるので、自分は Ruby や Python3 でツールを作成して見つけているのですが、これがやけに遅い。Ruby は 12 sec 程度、Python3 は 0.4 sec 程度かかってしまいます(たぶん Python3 の方はスクリプトが間違っているのだと思う、結果は同じなのだが)。

語彙が増えるにつれて計算量も増える(trie とかわからんし)ので、みなさんの使っているツールや方法を使わせてもらいたいなぁと。

それと一覧の管理、Wiki とかの方が良いのでしょうか？再利用できるような管理方法がいいですね。

[koron]

trie がご入り用で? ただ、最後の「ー」が無いケースとかの検出には、ちょっと手を入れないといけないからなぁ…

[koron]

あとでちょっと検討する予定。

[tyru]

JavaScriptで実装するんですか？
Travis CIに乗っけやすい言語のが良くないでしょうか？

[rhysd]

使えるかわかりませんが，proofreading ツールならこういうのありますよ

• textlint
  • https://github.com/textlint/textlint
• redpen
  • https://github.com/redpen-cc/redpen
• prh
  • https://github.com/vvakame/prh

ご参考までに．

[koron]

vimdoc-jaに限って言えば、trie + ahocorasick + migemo の一部でやるのがよさげ。

一応昔golangで作った
https://github.com/koron/gelatin/tree/master/ahocorasick
で実験してみたけど、やはりこれそのままじゃダメそう。
というのは ユーザー に対して ユーザ と ユーザー 両方が連続してマッチしてしまうから。

たしか最長一致を検出する何かも作った記憶があるので、探してみる。

[uakms]

KoRoN さん、すみません、適当なこと言いましたっ。かなり昔のことになりますが、文字列の検索置換ツールに perl で実装された drpl というものがあり、これが trie を使ったものらしく、すこぶる速かった記憶があったもので……。線形探索とか二分探索とか形態素解析とか、違いわかってません！

tyru さん、「用語一覧辞書を用いて対象のテキストを検索し発見する」ということを説明するためにあのページを作りました(パスが決め打ちですが Ruby と Python3 のスクリプトも上げときます)。言語は何でも良いと思います。情報技術の教育を受けた人の手によるものなら何でも安心だと思います。継続的インテグレーション！

rhysd さん、校正システムの情報ありがとうございます！ものすごく本格的なものがありますね。時代は進化してますね(自分の頭が止まっているとも言う……)。

用語一覧については近頃 mattn さんがコミットログに日本語で統一した用語を書いてくれているので収集しやすくなりました。

[koron]

trie ってのは、あってると思います。
あとは私の興味の範囲と被ってるので、やってみるというだけの話w

ちなみに Java版もあった。 https://github.com/koron/ugmatcha

[koron]

あとはpatricia-trieだなぁ…

[koron]

やはり効率で言えば trie + ahocorasick で最適化した状態遷移図作って、回すのが良さげな案件だった。

patricia-trieは、ちょっとだけ方向性が違う。

[mattn]

とりあえず mecab で分割して種別で分割して sort すれば、隣り合ったのが検出できるんじゃないすかね

[koron]

とりあえず s/出来/でき/ しておいたw

[koron]

とりあえずプロトタイプできた。 https://github.com/koron/nvcheck

こんな辞書 (dict.yml) を用意する。キーが正しい用語で、値はそのバリエーションの配列になってる。

ユーザー: [ ユーザ ]
サーバー:
  - サーバ

以下の様なテキスト test.txt を用意して

このユーザーはOKです。
このユーザはNGです。
このサーバーはOKです。
このサーバはNGです。
行マタギのユー
ザを検出できるかのチェック。
行マタギのユー
ザーを検出できるかのチェック。

$ nvcheck test.txt

って感じで実行すると、以下の様な修正データが得られる。

ユーザ >> ユーザー at 38
サーバ >> サーバー at 99
ユーザ >> ユーザー at 137

数字はゆらぎを修正すべき単語のファイル先頭からのバイトオフセットのつもり(あってるかは確認してない)。
表示方法ほか’諸々が要工夫。

[tyru]

@koron ++
表記ラベルでまとまってるから過去の表記ゆれの発掘も簡単ですね…
https://github.com/vim-jp/vimdoc-ja/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3A%E8%A1%A8%E8%A8%98+

[uakms]

KoRoN さんすごい！リターンキーを押したら一瞬で答えが返ってきました！
そして go get 初めて使いました。Golang 勉強しょ……

• pi_netrw.jax の「サーバ(書籍名なのでそのまま残してある)」1 個所
• syntax.jax の「コアスキーマ」(アスキーに引っかかる)1個所
• いっぱい.jax の「(こそあど)んなに」という、「何」にできない「なに」5個所

これらは nvcheck で得られたデータをラッパー側で表示する・しないをコントロールした方が良いですよね。

[rbtnn]

:cexprでさっとqfに読み込める表示方法が良さそう。

[koron]

どなたか、先行して dict.yml にPRくれませんかね?
nvcheck のデフォルトdict.ymlはそのままvimdoc-ja用にしちゃって良いと考えています。

出力フォーマットは @rbtnn さんの言うとおり、grep に寄せて quickfix で使えるように、最終的にはします。
(が、いまは検出に使ってる方式の関係で、先頭位置を取るのがめんどくてできてないw)(

[koron]

いっぱい.jax の「(こそあど)んなに」という、「何」にできない「なに」5個所

これはもしかしたら辞書に

こんなに: [ こん何 ]
そんなに: [ そん何 ]
あんなに: [ あん何 ]
どんなに: [ どん何 ]

が登録されていれば、回避するようにできるかも。
just idea

[koron]

おけ。書き換えるべき単語の位置を、バイトオフセットで開始と終了について正しく取れるようになりました。
間に改行や空白があっても取れるはず。

結果、以下のように信頼できる出力ができるようになりました。

example/test.txt:2: ユーザ >> ユーザー
example/test.txt:4: サーバ >> サーバー
example/test.txt:5: ユーザ >> ユーザー
example/test.txt:9: サーバ >> サーバー

[uakms]

dict.yml の形式は https://github.com/nakinor/vdjsample/blob/gh-pages/dict.yml こんな感じで良いのでしょうか？

[koron]

9e9808b とりあえず作りました。

[koron]

@nakinor nvcheck ができたことでこのissueは完了ってことで良いでしょうか?

[uakms]

オッケーです。
ありがとうございます。
(別のことにも使えそうですっ！)

[koron]

どうぞ使ってやってください 👍