Help:Extension:Linter/ja

 拡張機能は修正が必要あるいは可能なパターンのウィキテキストがあるページを検出し、パターンの問題点と解決法を示すガイドを提供します.

エラーは特別ページ:LintErrorsにタイプごとにまとめられています. このページではこれらの問題が原因で達成できない目的と比較して、リントの問題の重大度に応じて分類します. Special:Expandtemplatesを使うと、これらの問題のいくつかを見つけやすくなります. 詳細情報および議論は下記を参照してください.

今後も機能の改善を続け、ノイズの除去やバグ修正によりlinter の検出結果をより処理しやすくしていきます. ただし現在の検出結果を利用しても対処できます.

修正の対象と理由
今後の計画として、解析担当チームではLinterの拡張機能を活用してウィキテキストの以下のパターンを特定していく予定です： これらすべての対処が急がれるのではなく、場合によっては（利用者がエラーを我慢できれば）対処の必要がないものもあります. 上記のLinterの課題は、サブセットごとに個別にゴールを設定して対処していきます. 私たち解析担当チームはそれらのゴールをなるべく透明化（公開）し、どの課題を解決するとどのゴールが達成されるか、ガイダンスを提供していこうとしています.
 * エラー（例：偽の画像オプション – 通常、原因は入力ミスか、あるいはMediaWikiのメディアオプション解析の脆弱性）
 * 非推奨（例：self-closing tags）
 * 解析のパイプライン変更により壊れるもの（例：TidyからRemexHTMLへ移行）
 * HTML5では無効になるもの（例：centerやfontなど古いタグ）
 * 一時的に壊れており、編集者の意図しない形に誤って解析される可能性のあるもの（例：閉じていないHTMLタグ、入れ子が正しくないHTMLタグ）

'''説明を簡略化してよくある質問のページで提供しています. '''

目標: Tidy からの移行
MediaWikiの解析パイプラインに対する技術的な疑問を明らかにするため、TidyからHTML5へ移行する準備を進めてきました. ところが、それを実現すると、ウィキテキストの特定のパターンを修正しない限り、ページの少数のサブセットは解析に失敗することになります. 具体的に問題となるカテゴリは、削除可能なテーブルタグ とpwrapのバグ回避 、自己閉鎖タグ とTidyの空白バグ 、html5の入れ子のエラー とTidyのフォントのエラー です. Tidyからの移行が必要以上に先延ばしされないよう、これらはすべて優先度の高い問題に指定しました.

目標: PHP パーサと Parsoid のレンダリングの標準適合性を改善
現状ではページの表示にはPHPパーサーが生成したHTMLを使い、編集ツールやAndroidアプリなどいくつかの用途ではParsoidが生成したHTMLが使われています. 解析担当チームの長期目標の一環として、ページの表示も編集もParsoidの出力で行えるようにしたいと考えています. ParsoidとRemexHTMLは両方ともHTML5のツールなので、RemexHTMLの解析結果を左右するlint（エラー）はParsoidの解析にも影響を与えます. 現在のところ、Parsoidの解析を揺るがすそれ以外の新しいエラーは発見されていませんが、見つかり次第、この一覧を更新していきます.

目標: HTML5 出力の標準適合性
この目標はやや複雑な要素があり、目標達成の重要度あるいはどこまで到達すればよいのか、まだ把握できていません. それに加え、この目標に向けて活用する仕組みもまだ明確ではありません. たとえばUser:Legoktm/HTML+MediaWikiはさまざまな場での議論に基づき、html5で廃止されたビッグタグを扱うという提案をまとめています. いずれの場合も廃止タグ と自己閉鎖タグ のカテゴリの問題を解決すると、この目標に近づけます. そもそも目標が明確ではないので、廃止タグのカテゴリは優先度の低い目標としました.

目標: 編集者の意図を明確化する
正確にマークアップするのは難しく、どうしてもエラーが起きてしまいます. パーサーはこれらのエラーの回復に最善を尽くすものの、実際には編集者の本来の意図を反映していなさそうな場合も多く見られます. そこで最善策として、ここで特定した問題の修正には、編集者の意図を明確にすることを推奨します. この目標達成に影響が大きいカテゴリとは、具体的には間違った画像オプション やテーブル内など記述位置の間違い 、入れ子タグの間違い や閉じるタグの欠落 があげられます. 編集者の意図を明確にするという目標はかなり重要なため、前出のカテゴリのほとんどに中程度の優先度を付けています. ただし、大部分のケースでパーサーはかなり正確に回復しているように見えるので、閉じるタグの欠落のカテゴリは優先度の低いものとしてマークしました. そうは言いつつ、他の人間の編集者やツールにわかりやすいかどうかではなく、修正に多大な労力を費やさなくてもよいエラ－を修正作業の対象にすることをお勧めします.

目標: クリーンなマークアップの実現
マークアップの訂正は手間がかかります. たとえエラーが存在しても、ほとんどの場合、パーサーは本来、そのマークアップが目指したであろう解析結果に沿って、かなりいい仕事をします. ただし、誤字脱字や句読点あるいは細かな文法エラーを見逃せない編集者と同様に、編集者や開発者の感覚があるユーザーは、前出のような細かいエラーを見逃せないと感じるかもしれません. そのようなエラーの修正にとんでもなく長い時間を費やすことはお奨めしませんし、多くの場合、ボットでも修正に対応できるのです. むしろ、解析のゴール達成を難しくするエラーのカテゴリとは、入れ子タグの間違い 、閉じるタグの不足 とふぞろいのタグ （訳注：ペアの片方が不足）なのです.

特定のページの lint エラーの更新時期
現状ではリント（構文エラー）のカテゴリはすべて、ページの解析中にParsoidが識別したエラーから生成されます. ページ（またはページ上に複製されたテンプレート）が編集されると、ChangePropはそのページの再解析を要求し、Parsoidは新しい結果をLinter拡張に送ります.

つまり新しいカテゴリが導入されると（もしくは従来のカテゴリが訂正されると）、すべての解析結果の修正には時間がかかるかもしれないということです（特にほとんど修正されないページの場合）. もし編集をまったくしなければ、個別の処理はスピードアップします（訳注：理論上は）. 原則はそうであっても、T161556ではすべてのページを再解析する方法を検討中です.

X という名前空間 (例: 議論) のページは修正の対象かどうか
修正の優先順位が高いのはコンテンツの名前空間のページです. その他はウィキごとに異なります. サンドボックスとして使われるページが大量にあり、そこではエラーは放置されています.

ツール

 * w:User:PerfektesChaos/js/lintHint - その時点の LintErrors (Parsoid メッセージ) をリスト化する JavaScript のガジェット
 * WPCleaner - Linter のインタフェースとして機能する Java プログラムで、一部のエラー検出も可能
 * ja:User:MawaruNeko/ShowPageLintError.js - ページ単位でlintエラーをまとめるユーザースクリプト
 * Bot（作成者：User:星耀晨曦）書式指定終了タグの不足エラー multiple-unclosed-formatting-tagsを修正

関連項目

 * Parsoid/API#Wikitext to lint – ウィキテキストからlintを抽出
 * Parsing/Replacing Tidy – Tidyの置き換え
 * Parsing/Replacing Tidy/FAQ – Tidyの置き換えに関してよくある質問
 * ja:Wikipedia:Linter