[WIP]yandodさんから提供してもらった文字チェックタスクを追加してみた

[gosyujin]

遅まきながら @yandod さんにご教授いただいた文言チェックスクリプトを試してみました。
(REJECTファイルもそのままつっこんだだけなので、これをマージするわけにもいかないのでいったんWIPで)

これ便利ですね！

ちょっと気になるところ

• そろそろRakefileがボリューム的にも重くなってきた
• ルートディレクトリのファイル数も…
• 原文をコメントアウトしているため、 <!--original --> 内はチェックしないようにしないといけない

[gosyujin]

実行イメージはこんな感じになります。

$ rake check
(略)
------------------------------------- _docs/pages.md
全て # すべて
あなたが遭遇するほぼ全ての Web サーバの設定では、

人々 # 人たち
一部の人々はファイル名の拡張子のようなものがなくても URL を維持したいと思ってい
ます。

人々 # 人たち
このアプローチは、すべての人々にはあわないかもしれませんが、

人々 # 人たち
それはきれいな URL を好む人々のために簡単に動作します。

もっとも
Page を追加するもっとも単純な方法は、ルートディレクトリ内に

ヘッダー
    共通のコンテンツは、ヘッダーそしてフッターのように、

アプローチ # 手法
このアプローチは、すべての人々にはあわないかもしれませんが、

フォルダ # ディレクトリ
サイトのルートフォルダで(慣例により) `index.html` と呼ばれる HTML ファイルを探し、

フォルダ # ディレクトリ
- サイトのルートフォルダ内に各々の Page として 配置した HTML ファイル

フォルダ # ディレクトリ
- サイトのルートに各々の Page としてフォルダを作成し、各々の Page のフォルダ内に配置した index.html ファイル

[gosyujin]

refs #153

[harupong]

👍 これのユースケースですが、

1. 【厳密運用】REJECTをきちっと絞り込んで、該当したらCIでfail
2. 【まったり運用】 「ローカルでrake checkしてみてね～」
3. 【よしなに運用】CIの出力を元にGitHubで修正要否を都度検討（botがCIのrake check出力をGitHubのコメントに書いてくれると便利かも）

まずは2.でゆくゆくは1.ってところでしょうか。

[gosyujin]

ありがとうございます！

個人的には1.CIでfailするまではやらなくてもいいかなと思うです。
ただCIで回すのは賛成なので、Travisのログを見て何か差異があったら
今回はそのままマージするけど、Issue立てておいて修正するという感じでよいのかなー

[harupong]

どうなんでしょうね。REJECTをある程度絞りこまないと、マージのつど「rake check 修正」のissueを立てることになる気がします 😓

[gosyujin]

REJECTは一回まっさらにして、とりあえずWikiとかに乗せていた用語から追加してみようと思います。
少しずつ足す感じでいくと、追えるかな…

[yandod]

たまに一掃するみたいな運用もありえますね

[ghost]

👍 私も2.の運用でいいと思います。

[yandod]

これサービス化できそう。翻訳の進捗度とか差分の数を表示するバッチ付きで。