Parsing/Replacing Tidy/FAQ/ja

Tidy とは?
Tidy は、現在ウィキのページにあるいくつかの HTML エラーを修正するため、MediaWiki によって使用されているライブラリです. wiki ページには、編集者がテンプレートやページ自体に HTML タグを使用したことが原因で、マークアップの形式が間違ったものをよく見かけます（例:  に対する   がないなど HTML タグが閉じていないエラーが多発. ）場合によると MediaWiki から正しくない HTML が生成されることもあります. Tidy はこれらのマークアップエラーを修正するものの、正確さ確保には不要な他の「クリーンアップ」も独自に行います. たとえば空の要素を削除して HTML タグの間に空白を追加すると、ときどきレンダリングが変更されてしまいます. 意味論としてHTML4 に基づく Tidy が、HTML5 に移行済のweb に誤った変更をいくつか加えてきました. 一例として処理として認められてはいるものの、Tidy は予期せずに表キャプションから箇条書きリストを移動したりします.

なぜ、何と置き換えるのですか?
Tidyの技術は、ブラウザが標準化されていなかった1990年代のものです. Tidyの動作は大まかにHTML4の意味論に基づいているものの、現代のどのブラウザとも対応していません. メンテナンスを積極的にしないまま何年も経ったTidyですが、今までとは全く違う振る舞いをする「tidy-html5」として復活しました. 旧版の Tidy の展開は終了しました. 既に通知したように Tidy はエラー修正以外の HTML クリーンナップも行います. 両方をあわせるとこれらの課題が原因で Phabricator に大量のバグが提出され、少なくとも2013年以降、置き換えの要望が出ていました. 現在は HTML5 が標準であり、パーシングのアルゴリズムも明確に定義されていることから、どのブラウザともその他のライブラリとも互換性が確保されています. またアルゴリズムは壊れたマークアップの修正方法も規定します. この新しい技術面の見通しにおいて、Tidy を HTML5 パーサと確実に置き換えると、マークアップのエラー修正や、有効で正しく構成された HTML マークアップの生成が実現します. しかしながら、ウィキメディアのウィキには Tidy の修正法に依拠する膨大なページのコーパスが存在します. もし急激に、なんの準備的処理もしないまま、Tidy からサードパーティによる HTML5 ベースのツールに置き換えようとしても実行不可能です. HTML5 ベースのツールではマークアップエラーの修正方法が異なるため、ページの表示が同じにならないからです. そのため Tidy を HTML5 仕様に基づく独自のツールと置き換えながら、その影響を最小限に抑えるため、Tidy 互換の回避策をいくつか追加しています. 3種類のソリューションをテストした結果、PHPベース の HTML5 パーサには RemexHTML を設定して Tidy 互換のパスを記述し、今時点は必要な Tidy の動作を再現しました. 将来的には RemexHTML を使用してMediaWiki の新しいコア機能を有効にすることもできます. 例えばセクション編集をもっと堅牢にしたり、テンプレートをバランスよくサポートしたり、編集後のテンプレートによって、効率的なページ更新が実現するなどです. 疑問に思うかもしれませんので説明すると、tidy-html5 を使用してもマークアップエラーの修正が必要なことに変わりはありません. なぜなら HTML4 から HTML5 に意味論を変更する必要があるためです. 社内ツールが好まれる理由とは、変更の管理のためであり、上記のような他の機能を有効にするためでもあります.

技術面のその他の詳細に関心がある場合はhttps://phabricator.wikimedia.org/T89331あるいは Replacing Tidy (Tidy を置き換える) を参照してください.

これまでにどんなテストを実施したのですか?
Tidy を HTML5 ベースのツールと置き換えた場合の影響を識別するため、テスト戦略を採用し (「VisualDiff」というツールを使用) 、MediaWiki に Tidy を有効にした場合と無効にした場合それぞれの処理イメージを、詳細にピクセル単位で比較しました. 早い段階で共通の違いは小さな垂直方向の whitespace（ホワイトスペース）の変更であるとわかりました. これが顕著か見過ごしても構わないかどうかという判断に基づき、「UprightDiff」というツールを書いて画像内の垂直方向の動きの識別と縮小という自動テストの目的を果たしました. このツールはまた、差異に数値スコアを割り当て、最も重大な違いを容易に特定することもできます. ウィキメディアのさまざまなウィキから、ウィキペディアとウィキソース、ウィクショナリーとウィキボヤージュから選んだ合計40件を含む約6万4,000件の記事をエクスポートしました. 一部は「最近の更新」ストリームから、残りはアトランダムに選択しており、Tidy と RemexHTML でレンダリングした後、「UprightDiff」で結果を分析しました. これには多くのCPUサイクル、メモリおよびディスクスペースが必要で、テストを1ラウンド完了するのに2日間かかります. これによりテストコーパスのサイズは制限されるものの、必要な修正の種類を把握するには64Kのサンプルは十分に大きいと判断しました.

To minimize the differences and reduce the impact of fixes that would be needed from editors, we added some additional Tidy-compatibility fixups. Since we found that self-closing tags were extremely common on wikimedia wikis, we added a compatibility fix to treat them as empty tags (i.e.  is treated as  ). We added some other compatibility passes as well. After all these fixes were in place and we repeated our tests, we found that 93.4% of pages had no changes in rendering. And, 96.9% of pages had either no pixel diffs (93.4%) or insignificant vertical whitespace shifts only (3.5% = 96.9 - 93.4). The remaining 3.1% pages (100 - 96.9) showed pixel differences that had other reasons.

Based on these tests, we identified several classes of markup errors that will render differently between the two. For one class of markup errors (self-closing tags that aren't valid in HTML5), we added a maintenance category that editors have already been using to fix up templates and pages. But, the other classes of markup errors are not easy to detect automatically at this time and editors' assistance is necessary to identify and fix them up.

具体的な変更点と、その実施時期
すでに通知がされたとおり、Tidy を HTML5 ベースのツールと一挙に入れ換えることはしません. マークアップエラーの1クラスに管理カテゴリを追加、編集者が修正しやすくしました. その他のマークアップでも編集者がエラーの識別と修正を楽にできるように、編集中に変更点の比較とマークアップのエラーの修正を行う ParserMigration 拡張機能を構築しました. それとは別に、修正の必要があるエラーの検出用に Linter 拡張機能を作りました.

ParserMigration 拡張機能は2017年3月末時点ですべてのウィキに実装しています. 大規模なウィキすべてに Linter を実装したのは2017年6月20日時点です. これらの拡張機能が編集者によるページ修正をサポートし、2017年中の Tidy からの置換に結びつくことを期待していました. 修正の量が充分に蓄積し、また編集者や閲覧者に対する影響が最小限に抑えられ堪えられると確信できたとき、Tidy からの置換を実行します. ただし、これを無期限に引きずることは望んでいません. そこで、Linter によって優先度が高いと識別された課題を編集者にお願いして順位付けができると理想的です.

それとは別途、Tidy 互換性の修正（前記のとおり）はあくまでも Tidy を置き換えるまでの経過措置であると意図しています. その段階を経てから、同様のテストとツールのサポートの進み方に従い、互換性の修正箇所から徐々に置き換えていきます.

すべきこと
Linter 拡張機能はすべての wiki に実装されました. ヘルプページに示されたように、ご利用の wiki の Special:LintErrors ページにある優先度の高いカテゴリにリストされたwikitext のパターンとテンプレートを修正してください. そのカテゴリの項目にはそれぞれ、修正が必要なものを例示するヘルプページが対応しています. 下記に指示を簡略化してあります.

修正プログラムの確認用に wikitext を移行する編集者を支援するため、ParserMigration拡張機能を展開しました. 個人設定→編集で「ParserMigrationツール」を使用可能にすると、Tidy の現状と期待される出力 (RemexHTML) を並べて表示するリンクが、すべての記事の編集ツールボックスに追加されます. それを有効にすると、変更の前と後の記事を同じ画面上に左右に表示することで、自分が編集した内容がレンダリングをどのように変更/修正したか、確認できます.

自分のウィキへの影響
この情報はwikitext deprecation tool (wikitext 非推奨ツール) を参照してください. ページ数とは影響を受けるページの数なのに、事例によってはテンプレートに起因する問題が起きます. つまり、特定のテンプレートが修正されると、そのテンプレートを含むページはすべてリストから消えてしまうのです. したがって修正対象が数千から数百万ページあると表示されても、実際に修正が必要なテンプレートはほんの一握りという可能性が高くなります. これをもっと明確にしようと取り組んでいます. Parsing/Replacing Tidy/Linter/Stats を使って進捗状況を閲覧でき、また視覚的な違いのテスト結果として、60件のウィキから抽出した最大7万3千点の記事サンプルを右記で参照できます. http://mw-expt-tests.wmflabs.org/

簡易版の解説 - ページの修正のしかた
ここには、優先度の高い linter のカテゴリをすべて対象にした手順を簡単にまとめてあります. WPCleaner など支援ツールの使い方は、リンク先のヘルプページで説明している場合があります.

入れ子の指定が不適切なテーブル - 削除または修正
この例では Tidy は上記の Table 2 (表2) を削除するものの、RemexHTML を使った場合には削除されず、ページの見た目が変わってしまいます. それを防ぐために wikitext を修正し Table 2 を削除します. 以下の行タグの削除は必須ではないものの、削除することを推奨します. テーブルの終わりの table タグはもはや不要なので、それも削除する必要があります.

代わりの修正法として、ネストしたテーブルが必要な場合は、テーブル2の直前の行で、開始行に を書き、明示的なセルを追加します. ページごとに正しい修正法は異なるものの、ほとんどの場合、上記のとおり削除が正解です.


 * Help:Extension:Linter/deletable-table-tag

段落の折り返しでパーサのバグを回避
この linter 警告が出現する最大の原因は、ほとんどのwikiでnowrapまたはnowrap beginテンプレートです. これらの事例の大部分はテンプレートの修正で対処できます. 最も簡単な修正法はソース内の開始 &lt;span＆gt; タグの直前に改行を入れることです.

その他の事例すべてで、div/td 等 (その他の「ブロック」タグすべて) を使い CSS のプロパティに が書いてある場合は、div タグの直後に改行を入れてください.
 * Note that this has the effect of enclosing the whole span in a paragraph element. Here the bug comes from newlines within the div element that cause a new paragraph to be generated for "foo".
 * The alternative, if you don't want a paragraph element automatically inserted (with its additional margins) by MediaWiki to surrounding the "span" inside the "div", is to not use any newline at all in the content of the "div" element, or to "hide" these newlines within HTML comments:


 * Help:Extension:Linter/pwrap-bug-workaround

無効な終了区切り子
&lt;div/> や &lt;span/>、&lt;b/> 等の終了区切り子タグは HTML5 で無効です. 修正するには編集者の意図を守り、例えば &lt;/b> と書こうとして間違えただけの場合は単純な誤字を修正し、そのほかの場合は削除が正しい処理です. あるいはまた、&lt;nowiki/> と置換する必要があります. このカテゴリに関する詳しいヘルプページを参照してください.


 * Help:Extension:Linter/self-closed-tag

Tidy の whitespace（ホワイトスペース）バグ

 * Help:Extension:Linter/tidy-whitespace-bug

HTML5 と Tidy で入れ子のテーブルタグのエラーが不一致
Here is an example to illustrate the problem.

That was just one example to demonstrate the problem. There are other instances -  foobar  (an enwiki talk page) or  \n*x   (many itwiki pages via the use of citazione necessaria template) are other instances.


 * Help:Extension:Linter/html5-misnesting

カラー属性を持つフォントタグで wikilink を挟む
Here is an example to illustrate the problem.

{| class="wikitable" !Wikitext !Tidy !Remex !Proposed Fix
 * or better yet,  などのタグを終了区切り子として使うと、どういう出力結果になりますか?'''
 * or better yet,  などのタグを終了区切り子として使うと、どういう出力結果になりますか?'''
 * or better yet,  などのタグを終了区切り子として使うと、どういう出力結果になりますか?'''
 * or better yet,  などのタグを終了区切り子として使うと、どういう出力結果になりますか?'''
 * or better yet,  などのタグを終了区切り子として使うと、どういう出力結果になりますか?'''

A: T134423で説明があるように、終了区切り子として使える HTML タグは以下に限定されています. 、 、 、 、 、 、 、 、 、 、 、 、 、 、 . 非HTML の終了区切り子タグ (例:  や ) はこの変更の影響を受けません. ただし は例外で、HTML タグでありながら MediaWiki では拡張機能タグとして扱うため影響を受けません. その他の終了区切り子 HTML タグは修正してください (現状、すでに編集者による対処が進行中).

テスト段階でこの使用法が大量のページで見つかっており、予想外のレンダリング効果の防止 (例: が として処理され意図したより太字表示される文字が多い) のため、パーサを修正して空のタグに変換しています (例:  は に変換). ただしこの修正法はあくまでも暫定的であり、この非推奨の利用を見つけたら修正をお願いします.

Q: 英語版以外の言語版あるいは姉妹プロジェクトのテスト結果は?

A: Tidy あるいは RemexHTML が原因で、ウィキペディアあるいは英語版に固有のエラーは起きませんでした. このプロジェクトの基本的な目的は、意味論を HTML4 から HTML5 への変更に伴って、Tidy の HTML を修正することにあります. 変更によりどのプロジェクトも言語版も影響が出ると予想され、それでもプロジェクトや言語版によってはマークアップのエラーが多かったり、ほかよりも終了区切り子を大量に使っていたりする違いはあります.

Q: この置き換えによって、ほかにどんな変更が発生しそうですか?

A: この置換の影響は、基本的に閲覧者に対して現われます. ページの表示が正しくないと気づくかもしれません (例: 改行や折り返しがなく、過度に幅が広いナビゲーションボックス navbox. ) しかしながら、VisualEditor とそれ以外によるレンダリングが一致する可能性はこれまでよりもはるかに大きくなります. これは Parsoid の出力が当初から HTML5 準拠だったためで、いよいよ読み込み出力を HTML5 に移動しています. VisualEditor の編集に影響させないつもりですが、ダーティな差分が報告されたバグには直ちに対処します. さらに、マークアップエラーが修正されていない場合にも、ページに表示するエラーメッセージや警告を増やす予定はありません.

Q: 置換により、ほかのプロジェクトにはどう影響しますか?

A: HTML5 意味論への移行が実現するとコーパスのマークアップが進化し、ウェブの標準に遅れずに対応できるようにするひとつの方法となります. バランスのとれたテンプレート出力をサポートするため、このツールの活用が期待されています. 関連性はあるものの、これとは別途に、Parsoid が既に HTML5 意味論を使用しているので、PHPパーサ（読み込みに使用）とParsoid（VE、コンテンツ翻訳で編集に使用）の処理結果の一貫性がより高まります. 目標の1つは、これら2種類の処理結果を互いに完全に一致させ、パーサ1つで読み取りと編集の両方に対応することです.

--パーシング・チーム (構文解析チーム)

ボランティアを募集中です
''コミュニティ連絡員より、関心のあるウィキメディアンの皆さんにお願いです. コミュニティに関与する活動をサポートしてもよいという皆さんは、下記に利用者名を追加してください. どうぞよろしくお願いします. これまでのイニシアチブと同様に、署名は義務ではありません. '' Parsing/Get_involvedを参照して、ブックマークをお勧めします. 今後、手を貸してほしいというリクエストを発信していくページになります.
 * 1) ParserMigration ツールのテストに参加できます.
 * 2) (ここにあなたの署名を記入)
 * 3) テンプレートの修正ができます.
 * 4) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 5) Samuele2002 (talk)
 * 6) TheDragonFire (talk)
 * 7) Stryn (talk) 14:22, 17 July 2017 (UTC)
 * 8) Already did some in fawiki Ladsgroup (talk) 15:40, 18 September 2017 (UTC)
 * 9) テンプレートの修正について研究や議論に参加します.
 * 10) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 11) 自分のコミュニティで情報を伝えます.
 * 12) (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
 * 13) See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)
 * 1) (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
 * 2) See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)