Growth/Personalized first day/Structured tasks/Copyedit/ja

このページで解説する「文の編集」タスクとは、Growth チームが編集初学者のホームページに提供する予定の構造化タスクのひとつです. このページでは主要なアセット、設計、未決の課題、意思決定について述べます. 進捗状況で増えた更新のほとんどは一般向けのGrowthチームの更新ページに、このページには特定の大規模または詳細な更新をそれぞれ掲載します.

現状

 * 2021-07-19: プロジェクトページを開設して背景調査を開始.
 * 2022-08-12: add initial research results.
 * Next: complete manual evaluation.

要約
構造化タスクの目的は、編集作業（タスク）を細かな段階に分解し、それぞれのワークフロー単位を新規参加者にわかりやすく、モバイル環境に適した形にまとめることです. Growth チームではこれらの新しいタイプの編集ワークフローを導入するとウィキペディアに新規に参加しようとする人がもっと増えて、より複雑な編集を覚えるきっかけ作りとコミュニティへの参加の糸口になると期待しています. 構造化タスクの発案をさまざまなコミュニティと協議したのち、チームでは1番目の構造化タスクのビルドは「リンクの追加」に決まりました.

その1番目のタスクを作成する段階さえ、次にどんな構造化タスクを設けるか考えていました. 新規編集者には複数の種類のタスクから選べるようにして、それぞれがおもしろそうだと感じるタスクを見つけること、またどんどん難易度の高いものに挑戦できるようにしたいと考えました. 作業中のタスクの2番目は、「画像の追加」です. しかしながら、構造化タスクに関するコミュニティとの初期の協議では、コミュニティがもっとも 要望するタスクとは文の編集 -- スペルや用字、文法や句読点、文の口調などでした. この件を検討した当初、コミュニティの皆さんとの協議をこちらの初期のメモにまとめてあります.

これがどのように有効になるか、まだ未対応の質問がたくさんあること、うまくいかないという予測には複数の理由があることを承知しています. では、ここで言う文の編集とは、具体的にどんなものでしょうか？ スペルや誤字脱字か、それ以上か？ どんな対象言語でもうまく作動するアルゴリズムは既にあるかどうか？ これらの質問があるからこそ、広くコミュニティの皆さんから意見をお聞きして、プロセスの決定段階と並行して協議を 続けたいと考えます.

目標

 * アルゴリズムで補佐できるタスクとして、どのような文の編集があるか知ることが課題です.
 * 特定の種類の文の編集を記事内で提案するアルゴリズムで、さまざまな言語で有効なものを求めます.
 * アルゴリズムの性能を調べたいです（例＝既存のモデルを比較すると最良のものはどれか）.

文意の評価

 * 文の編集と言っても、さらに分解すると何があるか？
 * 変動範囲を許容すると文の編集とはどんな要素で成り立つか. 誤字脱字、スペルや用語、文法、記述法、語調
 * ウィキペディアでは現状、どのようなアプローチで文を編集しているか？
 * コミュニティとしては原稿編集集団Guild of Copy Editors あるいは誤字対策チーム Typo Team などが活動中.
 * 管理用テンプレートの例として文の編集用テンプレート copyedit-template
 * 誤字検出に使う moss-tool などのツール（アラビア語版ウィキペディアには JarBot あり）
 * 公開のツールで、誤字脱字やスペル間違いなどの対策用に人気があるのはどんなものか、たとえばハンスペル hunspell、言語ツール LanguageTool あるいはグラマリー Grammarly など？
 * アルゴリズムの透明性、つまり、おすすめ編集は何に基づいて提示されるか誰にでもわかるようにするのがコミュニティの理想であると理解しています.
 * NLP と ML の調査からどんなモデルが既にあるか、文法の誤りの修正 Grammatical Error Correction と呼ばれるタスクを例にします.

タスクの定義

 * 文の編集のうち、どの要素を構造化タスクのモデルに採用するか？
 * タスクの種類とは、スペルや誤字脱字、文法、語調や文体
 * 例を考える：ブラウザ内蔵のスペルチェッカーの機能とは？
 * 粒度 -- タスクをどの段階に落とし込むか：単位は記事全体か、見出しごとか、段落か、単文か、単語か、複合語の要素ごとか
 * タスクごとに幅を持たせる
 * 拾い出す対象は既知の項目（例＝テンプレートの対象）または未出の課題を予測するか？
 * 改善が必要と示すか、改善方法まで言及するか？
 * タスクが単純なほど、改善も簡単です.
 * タスクが複雑なら、単に改善作業が必要だと示す単純な対応ができます（例＝文体や語調）
 * 言語のサポート：サポート対象の言語の件数は？
 * 対象はアラビア語、ベトナム語、ベンガリー語、チェコ語、スペイン語とポルトガル語を加えます.
 * 理想としてはあらゆる言語を対象にしたかったのですが、実現可能性に照らすと言語の普及の深度を図り 、それに基づく解決策の評価をする必要があります.

評価用のデータセットを構築

 * 特定のタスクについてテスト用データセットの構築（できるだけ複数言語で実施）により、異なるアルゴリズムの比較対照に使えるようにします. さまざまな実践の取り組み方
 * 既存のベンチマーク用のデータセット、たとえばCoNLL-2014 文法エラー修正の共同タスクまたはコーパス集作成という取り組み（対象はウィキペディア）
 * 変更履歴から独自のデータセットを作成するには、テンプレート（文の編集）または編集要約（誤字）を使う
 * ウィキペディアから抽出した文章を使って実施し、出力モデルケースを手動で評価した結果

Research results
A full summary of Research is available on MetaWiki: Research:Copyediting as a structured task.

Literature Review
Background research and literature review are captured in Copyediting_as_a structured_task/Literature_Review

Main findings:
 * Simple spell- and grammar checkers such as LanguageTool or Enchant are most suitable for supporting copyediting across many languages and are open/free.
 * Some adaptation to the context of Wikipedia and structured task will be required in order to decrease the sensitivity of the models; common approaches are to ignore everything in quotes or text that is linked.
 * The challenge will be to develop a ground-truth dataset for backtesting. Likely, some manual evaluation will be needed.
 * Long-term: Develop a model to highlight sentences that require editing (without necessarily suggesting a correction) based on copyediting templates. This could provide a set of more challenging copyediting tasks compared to spellchecking.

LanguageTool
We have identified LanguageTool as a candidate to surface possible copyedits in articles because:
 * It is open, is being actively developed, and supports 30+ languages
 * The rule-based approach has the advantage that errors come with an explanation why they were highlighted and not just due to a high score from a ML-model. In addition, it provides functionality for adding custom rules by the community https://community.languagetool.org/
 * The copyedits from LanguageTool go beyond spellchecking of single words using a dictionary but also capture grammatical errors and style.

We can get a very rough approximation of how well LanguageTool works for detecting copyedits in Wikipedia articles by comparing the amount of errors in featured articles with those in articles containing a copyedit-template. We find that the performance is reasonable in many languages after applying a post-processing step in which we filter some of the errors from LanguageTool (e.g. those overlapping with links or bold text).

We also compared the performance of simple spellcheckers which are available for more languages than supported by LanguageTool. They can also surface many meaningful errors for copyediting but suffer from a much higher rate of false positives. This can be partially addressed by post-processing steps to filter the errors. Another disadvantage is that spellcheckers perform considerably worse than LanguageTool in suggesting the correct improvement for the error.

One potentially substantial improvement could be to develop a model which assigns a confidence score to the errors surfaced by LanguageTool/spellchecker. This would allow us to prioritize those errors for the structured task copyediting task for which we have a high confidence that they are true copyedits. Some initial thoughts are in T299245.

Read here for more details: Research:Copyediting as a structured task/LanguageTool

Evaluation
We are now working towards building a list with examples of automatically suggested copyedits for manual evaluation by the Growth Ambassadors T315086.