MDN/Guidelines/Writing_style_guide 以下を削除 (#1600)

- MDN/Guidelines/Writing_style_guide 以下を削除 - 関連るする文書も最小限の修正を実施
author: Masahiro FUJIMOTO <mfujimot@gmail.com> 2021-07-30 13:36:23 +0900
committer: GitHub <noreply@github.com> 2021-07-30 13:36:23 +0900
commit: 20f40b42cd50b62ee767cdeea5022d8066512ec6 (patch)
tree: db04a34cc339b7e5a7c95c6367af025a703c2129 /files
parent: 1e548ca157861d80e5447962cc576f8681580f4e (diff)
download: translated-content-20f40b42cd50b62ee767cdeea5022d8066512ec6.tar.gz
translated-content-20f40b42cd50b62ee767cdeea5022d8066512ec6.tar.bz2
translated-content-20f40b42cd50b62ee767cdeea5022d8066512ec6.zip
5 files changed, 126 insertions, 635 deletions
diff --git a/files/ja/_wikihistory.json b/files/ja/_wikihistory.json
index 768153c5b6..0819bd037a 100644
--- a/files/ja/_wikihistory.json
+++ b/files/ja/_wikihistory.json
@@ -48372,22 +48372,6 @@
       "mantaroh"
     ]
   },
-  "conflicting/Mozilla/Developer_guide": {
-    "modified": "2019-03-23T23:49:07.432Z",
-    "contributors": [
-      "teoli",
-      "Kohei",
-      "Mgjbot"
-    ]
-  },
-  "conflicting/Mozilla/Developer_guide/How_to_Submit_a_Patch": {
-    "modified": "2019-01-16T15:43:30.635Z",
-    "contributors": [
-      "Shoot",
-      "Kohei",
-      "Mgjbot"
-    ]
-  },
   "conflicting/Mozilla/Firefox/Releases": {
     "modified": "2020-07-16T22:35:56.505Z",
     "contributors": [
diff --git a/files/ja/conflicting/mozilla/developer_guide/how_to_submit_a_patch/index.html b/files/ja/conflicting/mozilla/developer_guide/how_to_submit_a_patch/index.html
deleted file mode 100644
index ce086786b1..0000000000
--- a/files/ja/conflicting/mozilla/developer_guide/how_to_submit_a_patch/index.html
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: Hacking Mozilla
-slug: conflicting/Mozilla/Developer_guide/How_to_Submit_a_Patch
-tags:
-  - Developing Mozilla
-original_slug: Hacking_Mozilla
----
-<p>このページは、Mozilla の CVS リポジトリにプログラムコードをチェックインする方法を知りたい方のために設けられました。もしあなたが、今まで一度も Mozilla をビルドしたことがなければ、<a href="ja/Mozilla_Source_Code_(HTTP%2f%2fFTP)">ソースコード</a> のページを参照して、ビルドすることから始めた方がよいでしょう。そして <a href="ja/Mozilla_Hacker's_Getting_Started_Guide">Mozilla のハックを始めるためのガイド</a> を調べてみてください。
-</p>
-<h3 id=".E3.83.91.E3.83.83.E3.83.81.E3.81.AE.E3.83.A9.E3.82.A4.E3.83.95.E3.82.B5.E3.82.A4.E3.82.AF.E3.83.AB"> パッチのライフサイクル </h3>
-<p>もし、パッチ作成に関心があれば、以下のガイドラインが役に立つでしょう
-</p>
-<ul><li> 私達の基本的な設計思想の一つは、私達のプログラムコードが様々なプラットフォーム上で動作するようにするということです。必ずしも最新の標準の全てをサポートしていないようなコンパイラを使って、小さなプラットフォームに Mozilla を移植している人々もいます。もしあなたがコンパイルされたコード (C, C++) を書いているのであれば、私達の <a href="index.php?title=ja/C%2b%2b_Portability_Guide">C++ 移植ガイド</a> に従い、できる限りの警告出力を有効にしてコンパイルを行うことで、それらのプラットフォームを助けてください。いつの日かあなたは、あなたが書いたプログラムコードが、ケーブルテレビの受信機や携帯電話のような本当に小さなプラットフォーム上で動作しているのを見つけることでしょう。
-</li><li> あなたのコードは <a class="external" href="http://www.mozilla.org/projects/l10n/customizable-code.html">ローカリゼイション</a> にも気を付けてください。62の <a class="external" href="http://www.mozilla.org/projects/l10n/mlp_status.html#projects">登録されたプロジェクト</a> があり、そのうち 7 〜 10 個は現在もアクティブです。
-</li><li> <a href="ja/Mozilla_Coding_Style_Guide">Mozilla コーディングスタイルガイド</a> にも注意してください。
-</li><li> カスタマイズ性を考慮してください。Mozilla テクノロジの最大の利点の一つは、カスタマイズ性です。Mozilla のベンダやディストリビュータは彼らのニーズに向かって Mozilla を仕立てる特別な要件があるでしょう。Mozilla のディストリビュートを円滑にするために、機能を追加、削除、修正を容易に出来るように、是非カスタマイズ性を考慮してください。
-</li><li> 私達の <a class="external" href="http://www.mozilla.org/roadmap.html">開発ロードマップ</a> を読んでください。それは、Mozilla が目標としているアーキテクチャの概説であり、Mozilla をハックする全ての人にとって良い読みものです。
-</li><li> 新しいソースファイルを作るときには、適切な <a class="external" href="http://www.mozilla.org/MPL/boilerplate-1.1/">boilerplate (テンプレート)</a> のライセンスヘッダを加え、空欄を埋めてください。また、修正したファイルのライセンスヘッダの contributors (貢献者) 欄にあなた自身を加えるべきならばそうしてください。
-</li><li> パッチは現在の CVS に対して書くべきです。また、ソースファイルを開くことなくパッチを理解してもらうために、なるべく前後に十分な行を加えるべきです。標準のガイドラインとしては、最低限 <code>cvs diff -u8pN</code> を使用することが推奨されます。理解しやすいパッチを作るためにもっと前後の行を増やしたいなら、数字の 8 をもっと大きい数字に変えてください。
-</li></ul>
-<p>もし、あなたがパッチを持っていたら、それを <a class="link-https" href="https://bugzilla.mozilla.org/">Bugzilla</a> へのバグ報告に添付してください。私たちはコードレビューに大きな信頼を置いています。なので、CVS リポジトリにコードをチェックインする前に、適切な <a class="external" href="http://www.mozilla.org/owners.html">モジュールオーナー</a> か、その同僚によるレビューを受ける必要があります。モジュールは完全には直接 Bugzilla コンポーネントに対応しません。しかし、強い相関があります。レビューを受けるには：
-</p>
-<ul><li> <a class="external" href="http://www.mozilla.org/owners.html">該当モジュールのモジュールオーナーか peer (代行者)</a> に、パッチに <code>?</code> というレビューフラグを立て (このフラグはレビューが求められていることを示します)、レビューをお願いしたい人のメールアドレスを記入して、レビューを明示的に依頼してください (あなたが指名されたのでなければ)。
-</li><li> バグナンバと、パッチを添付している事実と、レビューしてほしいことに言及して、モジュールオーナーか代行者に直接メールを送ることも出来ます。しかし、Bugzilla の依頼機能を使った方が見落とされる可能性は低いです。
-</li></ul>
-<p>いくつかのケースで、次の数日以内に返答を受け取ることが出来るでしょう。不幸にして、忙しすぎるので彼らのバグ情報すべてに追いつけていない人々もいます。なので、あなたが 1 週間以内に返事を受け取れなくて、あなたがそのパッチに (言うならば、1 年やそこらでなく) すぐに対応する価値があると考えるなら、このようなことが出来ます。
-</p>
-<ul><li> そのコンポーネントのバグに対するパッチをレビューしたことのある誰か他の人を Bugzilla で探し、かわりにその人にレビューを依頼してください。
-</li><li> IRC の <a class="link-irc" href="irc://irc.mozilla.org/#developers">#developers</a> で適切なレビューワが誰かを聞いてください。注意：レビュー依頼は IRC ではなく、E-Mail で
-</li></ul>
-<p>レビューワはあなたが取り組んでほしいあなたのパッチに対してコメントするでしょう。彼らが満足したとき、かれらはパッチをレビュー済みと印付けし、バグ (訳注：Bugzilla) で "r=&lt;user&gt;"と言うでしょう。
-</p><p>たいていの場合、"スーパーレビュー"として知られる追加のレベルのレビューが必要です。<a class="external" href="http://www.mozilla.org/hacking/reviewers.html">スーパーレビュー</a> ドキュメントはスーパーレビューを受けるために何をすべきかについて詳しく述べています。また、スーパーレビューはパッチに変更を求めるかもしれません。彼らが満足すると、バグ (Bugzilla) の中でそう言うでしょう。
-</p><p>レビューとスーパーレビューを受けて、パッチが十分な水準に達していたら、ツリーにチェックインできます。あなたが CVS アカウントを持っていない場合、代わりにチェックインしてくれる人を探さなければなりません。これは実に簡単です。<code>checkin-needed</code> キーワードをバグに追加するだけです。数少ないコミッターがこのキーワードの検索を設定しており、ちょくちょく調べてはコミットされていないパッチをコミットします。通常はキーワードが追加されてから 1 ～ 2 週間のうちにはコミットされるでしょう。2 週間以上たってもコミットされない場合、IRC に行って誰かにあなたのパッチをコミットするように (そして <code>checkin-needed</code> が付いたバグを調べるように、それらのバグにパッチを提供した人たちも同じように待たされているでしょうから) 言ってみる価値はあるでしょう。
-</p><p>時折、ツリーはリリースを試みるために少しより厳重にロックされ、"approval" (承認) と呼ばれる第三段階がチェックインのために必要になります。それらの時期には、<a class="external" href="http://tinderbox.mozilla.org/">Tinderbox</a> は approval が必要であると先頭でうたって注意を促します。approval を依頼するには、パッチ添付ファイルを変更して approval フラグに <code>?</code> をセットしてください。もし、approval が断られた場合、リリースが行われるか、リリースへ向けての開発がブランチとなるまで、1 週間程度パッチのチェックインを待たなければなりません。
-</p><p>これらのプロセスの中で、他に問題を抱えているか、ガイドが必要なら、<a class="link-mailto" href="mailto:gerv@mozilla.org">Gerv</a> にメールすることです。
-</p>
-<h3 id="CVS_Commit_Access_.E3.83.AB.E3.83.BC.E3.83.AB"> CVS Commit Access ルール </h3>
-<p>あなたがパッチでの貢献を頻繁に行って、品質の良いコードについて定評のある業績を残したとき、<a class="external" href="http://www.mozilla.org/hacking/getting-cvs-write-access.html">CVS コミット権限を得る</a> のプロセスを始めることが出来ます。CVS コミット権限は、以下のルールが伴います。
-</p><p>もっとも重要なルールは、ビルドのプロセスに関してです。それを無視することは、多くの人々の時間を浪費することになります。図々しい違反者は、ルールに従う事に悩まされるでしょう。抵抗は無駄です。
-</p>
-<ul><li> <a class="external" href="http://www.mozilla.org/hacking/rules.html">follow the tree rules</a> を学びましょう。私達のビルドの手順は、柔軟で、人の手の介入を最小限しか必要とせず、数百人の技術者に対しても調整可能です。人々がこの単純なルールに従う限り、この手順は動作し続けるでしょう。
-</li><li> リポジトリにチェックインする人は全て、ツリーの担当する部分がきれいに保たれているようにしなくてはいけません。あなたのプログラムコードをチェックイン<b>する前に</b>、他のプラットフォームでビルドできることを確かめてください。チェックイン後は、Tinderbox があなたのプログラムコードを正常にビルドできるようにすることと、ビルド時や実行時の予期しない問題に対応できるようにすることは、あなたの責任です。多くの人にとって、<a class="external" href="http://groups.google.com/groups?oi=djq&amp;as_umsgid=mcmullen-2404991952090001%40h-208-12-40-136.mcom.com">ツリーの破損は時間の損失</a> となります。決してしないでください。
-</li><li> <a class="external" href="http://tinderbox.mozilla.org/">Tinderbox</a> の活用について学んでください。Tinderbox を使って、ツリーについての全ての情報を入手することができます。誰かがプログラムコードをツリーにチェックインしている場合、あなたは Bonsai を使って、ツリーがオープンされているかどうかや、計画されているクローズがあるかどうかなど、そのツリーについての情報を調べなくてはいけません。
-</li><li> 新しいディレクトリを作成する際には、そのディレクトリの親ディレクトリの所有者の許可を得てください。"mozilla" のトップディレクトリに新しいディレクトリを追加する際には、mozilla.org の <a class="link-mailto" href="mailto:staff@mozilla.org">スタッフ</a> に連絡してください。私達は、相当な理由がない限りは、新しいトップレベルディレクトリの追加を望みません。ほとんどの新しいプロジェクトは、ツリーにすでにあるどこかのフォルダ、例えば components におさまるでしょう。
-</li></ul>
-<p>Happy hacking!
-</p>
-<div class="originaldocinfo">
-<h2 id=".E5.8E.9F.E6.96.87.E6.9B.B8.E3.81.AE.E6.83.85.E5.A0.B1"> 原文書の情報 </h2>
-<ul><li> 最終更新日: October 1, 2007
-</li><li> 著作権: Portions of this content are © 1998–2007 by individual mozilla.org contributors; content available under a Creative Commons license | <a class="external" href="http://www.mozilla.org/foundation/licensing/website-content.html">詳細</a>
-</li></ul>
-</div>
-<div class="noinclude">
-</div>
-{{ languages( { "en": "en/Hacking_Mozilla" } ) }}
diff --git a/files/ja/conflicting/mozilla/developer_guide/index.html b/files/ja/conflicting/mozilla/developer_guide/index.html
deleted file mode 100644
index 9b36931e59..0000000000
--- a/files/ja/conflicting/mozilla/developer_guide/index.html
+++ /dev/null
@@ -1,144 +0,0 @@
----
-title: Mozilla Hacker's Getting Started Guide
-slug: conflicting/Mozilla/Developer_guide
-tags:
-  - Developing Mozilla
-original_slug: Mozilla_Hacker's_Getting_Started_Guide
----
-<p>もし、このドキュメントについて、誤りを見つけたとか、更新に貢献したいとか、セクションを追加したいとか、そういうときには <a class="link-mailto" href="mailto:kaie@kuix.de">Kai Engert</a> までコンタクトを。</p>
-<h3 id="Mozilla_.E3.81.A8.E3.81.AF.EF.BC.9F" name="Mozilla_.E3.81.A8.E3.81.AF.EF.BC.9F">Mozilla とは？</h3>
-<p>Mozillaは オープンソースプロジェクトであり、クロスプラットフォームのインターネットクライアントソフトウェアを開発する組織です。ソースコードごとに定められた (MPL、NPL、GPL、LGPLが混在している) <a class="external" href="http://www.mozilla.org/MPL/">ライセンス</a> に従う必要があるとはいえ、Mozilla がオープンソースであるために、ソースコードは誰にでも利用可能です。</p>
-<p>Mozilla.org は、このプロジェクトの開発者を助けるための基盤を提供する組織の名前です。<a class="external" href="http://www.mozilla.org/">mozilla.org</a> は Mozilla プロジェクトのための中心となる Web サイトのアドレスでもあります。</p>
-<h3 id=".E5.8B.95.E6.A9.9F" name=".E5.8B.95.E6.A9.9F">動機</h3>
-<p>Mozilla は最大規模のオープンソースプロジェクトの一つです。Mozilla は 何百万行のコードで作られています。そのため、この巨大プロジェクトに参加するのは簡単ではありません。このドキュメントの意図は、Mozilla をハックするために何に気を付けなくてはならないかについての概要を示すことにあります。このドキュメントで Mozilla プロジェクトで使われている多くの異なったテクノロジーの間の橋渡しをしようとしています。</p>
-<p>私が Mozilla の内部に目を向け始めたとき、私はこのようなドキュメントがあればと願いました (^^)</p>
-<h3 id=".E5.AF.BE.E8.B1.A1.E8.80.85" name=".E5.AF.BE.E8.B1.A1.E8.80.85">対象者</h3>
-<p>このドキュメントは第一に Mozilla のどの部分かで作業できることを望む開発者のために書かれました。参加希望者は、オブジェクト指向プログラミングについて十分な理解が求められます。そして、特に、このプロジェクトで主にプログラム言語で用いられている C言語と C++ についての経験が求められます。</p>
-<p>しかし、もしあなたが、例えば JavaScript と XUL UI (XUL ユーザインタフェース) だけのように、コードの一部でだけ作業することを望んでいるとしても、この文書は参考になるでしょう。</p>
-<h3 id=".E3.81.93.E3.81.AE.E3.83.89.E3.82.AD.E3.83.A5.E3.83.A1.E3.83.B3.E3.83.88.E3.81.AE.E7.AF.84.E5.9B.B2" name=".E3.81.93.E3.81.AE.E3.83.89.E3.82.AD.E3.83.A5.E3.83.A1.E3.83.B3.E3.83.88.E3.81.AE.E7.AF.84.E5.9B.B2">このドキュメントの範囲</h3>
-<p>このドキュメントは以下の疑問に答えようとしています。</p>
-<ul>
- <li>どのようにソースコードは組織化されているか？</li>
- <li>どんなテクノロジーが使われているか？</li>
- <li>参加するにはどこから手をつければ良いか？</li>
- <li>コンポーネントは相互にどのように働いているか？</li>
- <li>どんなツールがあり、どのように便利なのか？</li>
- <li>参加するために従う必要のあるどんなルールがあるのか？</li>
-</ul>
-<h3 id="Netscape_.E7.A4.BE.E3.81.AF.E3.81.93.E3.81.AE.E3.83.97.E3.83.AD.E3.82.B8.E3.82.A7.E3.82.AF.E3.83.88.E3.81.AB.E4.BD.95.E3.82.92.E3.81.99.E3.81.B9.E3.81.8D.E3.81.AA.E3.81.AE.E3.81.8B.EF.BC.9F" name="Netscape_.E7.A4.BE.E3.81.AF.E3.81.93.E3.81.AE.E3.83.97.E3.83.AD.E3.82.B8.E3.82.A7.E3.82.AF.E3.83.88.E3.81.AB.E4.BD.95.E3.82.92.E3.81.99.E3.81.B9.E3.81.8D.E3.81.AA.E3.81.AE.E3.81.8B.EF.BC.9F">Netscape 社はこのプロジェクトに何をすべきなのか？</h3>
-<p>Mozilla が創造された時、それは Netscape のものでした。ある時期に、会社としての Netscape は、会社が所有していて、他者の著作権に抵触しないソースコードの部分を公開することにしました。</p>
-<p>Mozilla は完成された製品ではありませんでした。なので、Mozilla プロジェクトはたくさんのコードを新たに書かなくてはなりませんでした。それに加えて、多くの部分を書き直しました。他のコンポーネントのいくつかは維持され、拡張されました。これが、このドキュメントや、Mozilla プロジェクトについて議論するときに Netscape という単語を目にする、耳にする機会があるの理由の一つです。</p>
-<h3 id="C.2B.2B_.E3.81.A8_JavaScript" name="C.2B.2B_.E3.81.A8_JavaScript">C++ と JavaScript</h3>
-<p>Mozilla では幅広く使われているため、Mozilla のソースコードで JavaScript と C++ が互いにどう関係しているかを説明するのは意味のあることです。C++ はコンパイル型の言語で、JacaScript はインタプリタ型の言語です。JavaScript は Web サイトをインプリメントするのに使われるテクノロジーとして最も共通のものとして知られています。しかし、Mozilla 開発者は、Mozilla ソースコード自身を両方の言語の混合で成り立たせることを選びました。</p>
-<p>Mozilla ブラウザを起動したとき、C言語 と C++ のコンポーネントがまず開始します。しかし、起動処理の速い時点で XPConnect と呼ばれるテクノロジーが実行時にインタプリタ解釈された JavaScript を使用可能に初期化します。実際、Mozilla ブラウザは、コンパイルされた C++ と、コンパイルされない JavaScriptの両方で構成されています。</p>
-<p>JavaScript は、OS によって直接に実行できるようにコンパイルすることが出来ないことに注意してください。そのために、われわれは C言語と C++ をプログラムのバックエンドで使用し、JavaScript は Mozilla の内部で動作します。</p>
-<p>そして、JavaScript を使用した Web ページをネットサーフするとき、その JavaScript はサンドボックス (隔離された安全地帯) の範囲内で動作し、Mozilla の内部オブジェクトにアクセスすることは出来ないことも覚えておいてください。DOM (ドキュメント・オブジェクト・モデル Document Object Model) によって露出したオブジェクトだけが アクセス可能です。</p>
-<p>このドキュメントで JavaScript に言及がある時はいつでも、Mozilla 内部の機能性に寄与するテクノロジーを意味します。JavaScript は、ユーザインタフェースイベント (ユーザの操作によるブラウザの動作) の処理を行うソースコードの部分に最もよく使われています。以下のドキュメントのほとんどは、アプリケーションの C++ 部分の概観について説明します。</p>
-<h3 id="NSPR_-_Netscape_.E3.83.9D.E3.83.BC.E3.82.BF.E3.83.96.E3.83.AB.E3.83.BB.E3.83.A9.E3.83.B3.E3.82.BF.E3.82.A4.E3.83.A0" name="NSPR_-_Netscape_.E3.83.9D.E3.83.BC.E3.82.BF.E3.83.96.E3.83.AB.E3.83.BB.E3.83.A9.E3.83.B3.E3.82.BF.E3.82.A4.E3.83.A0">NSPR - Netscape ポータブル・ランタイム</h3>
-<p>Mozilla プロジェクトでのソフトウェア開発のために第一に必要なのは、例えば、特定の OS に制限されてはいけないなどのように、クロスプラットフォームであることです。</p>
-<p>C++ がポータブルな言語を意図している一方、そのポータブル性の概観は、一般的なプログラミングロジックとデータ構造に限られます。もし、特定の OS のためのソフトウェアを書きたいならば、その OS の特有の機能を使う必要があります。しばしば、すべての OS 上で同じ機能を使いたくなりますが、それをするためにはプラットフォーム毎に特有のコードを書かなくてはなりません。</p>
-<p><a href="ja/NSPR">NSPR</a> の意図するところは、OS と Mozilla ソースコードの間に、Mozilla ソースコードの他のエリアのコードをシンプルにしやすくするためのレイヤー (層) を提供することです。C言語のライブラリ関数を利用しようとするとき、まずはクロスプラットフォームなインプリメントのものが NSPR により提供されていないかチェックすることが必要です。</p>
-<h3 id=".E3.82.B9.E3.83.AC.E3.83.83.E3.83.89" name=".E3.82.B9.E3.83.AC.E3.83.83.E3.83.89">スレッド</h3>
-<p>Mozilla はマルチスレッドアプリケーションです。Mozilla のコードにトライするまえに、それが何を意味するかを知る必要があります。</p>
-<p>NSPR はマルチスレッドプログラムのための OS 非依存の機能を提供しています。例えば、すべてのネットワークデータ転送はデータ転送をしている間にも、ユーザインタフェースが応答可能なままとするために、スレッドごとに行われます。</p>
-<p>C++ コードのために必要なことの一つは、マルチスレッド対応 (スレッドセーフ) であることです。</p>
-<h3 id=".E3.82.AA.E3.83.96.E3.82.B8.E3.82.A7.E3.82.AF.E3.83.88.E6.8C.87.E5.90.91.E3.83.97.E3.83.AD.E3.82.B0.E3.83.A9.E3.83.9F.E3.83.B3.E3.82.B0_&amp;_.E3.83.A2.E3.82.B8.E3.83.A5.E3.83.BC.E3.83.AB.E5.8C.96" name=".E3.82.AA.E3.83.96.E3.82.B8.E3.82.A7.E3.82.AF.E3.83.88.E6.8C.87.E5.90.91.E3.83.97.E3.83.AD.E3.82.B0.E3.83.A9.E3.83.9F.E3.83.B3.E3.82.B0_&amp;_.E3.83.A2.E3.82.B8.E3.83.A5.E3.83.BC.E3.83.AB.E5.8C.96">オブジェクト指向プログラミング &amp; モジュール化</h3>
-<p>Mozilla の C++ ソースコードは、OOP (オブジェクト指向プログラミング) のルールに従うことを意図しています。そのルールには、モジュール化コンポーネント設計も含まれており、そこでは、あなたのクラスの public なインターフェースを使用した場合のみ、内部データ (変数) に対するアクセスが許可される、あるいは可能になります。</p>
-<p>たいていのシンプルな C++ プロジェクトにおいて、これはそれだけの意味です。クラスを適切に public/protected/private を使い分けるのには注意深くデザインするというだけの意味です。しかし、すべてのソースコードはどこでも利用可能な状態のままです。例えば、いつでも、クラスのコンポーネントを private から public へ変更することが出来ます。そうすると、それはプロジェクトの中の他の箇所から利用可能となります。これは、Mozilla には当てはまりません。Mozilla では、よりモジュール化することが望まれます。</p>
-<p>Mozilla のソースコードは分離されたコンポーネントで組織されています。一つのコンポーネントの中に限れば、前段落に記した単純なプロジェクトのように、すべてが自由ですが、複数のコンポーネント間においては、同じレベルの柔軟性はありません。</p>
-<p>コンポーネント同士が通信するとき、コンポーネント・オブジェクト・モデル (COM component object model) を使ったうまく定義されたインタフェースだけを使って行います。</p>
-<h3 id=".E3.82.A4.E3.83.B3.E3.82.BF.E3.83.95.E3.82.A7.E3.83.BC.E3.82.B9" name=".E3.82.A4.E3.83.B3.E3.82.BF.E3.83.95.E3.82.A7.E3.83.BC.E3.82.B9">インタフェース</h3>
-<p>インタフェースのコンセプトは、CORBA テクノロジーで使われているもののようなものです。例えば、CORBA も Mozilla もインタフェースを記述するのに XPIDL (IDL とはインタフェース定義言語を意味します Interface Definition Language) という同様の言語を用いています。</p>
-<p>CORBA 環境を使用する事は、制限が多く難しいものです。なぜならば、Mozilla では頻繁には用いないようなプロセス間、ネットワーク間通信を伴うためです。正式に流通している CORBA 環境ではインタフェースのコンポーネントを変更するのは同時にしばしば実行しているシステムすべてを入れ替えることが出来ないために困難です。何か変更を加えたいとき、新しいバージョンのインタフェースを定義しなくてはなりません。しかし、前のバージョンのサポートも続けることが求められます。</p>
-<p>Mozilla は本稿執筆時点において正式に流通しているアプリケーションではないので、現在のところ多くのインタフェースは開発プロセスの必要に応じて変更することが可能です。しかし、Mozilla ブラウザはいくつかの環境に埋め込まれて実行されるので、それらの環境は確定したインタフェースを信頼できなくてはなりません。したがって、インタフェースは凍結されることができます。この状況は、しばしば、インターフェースが定義されている状態で表されます。時間の経過とともに Mozilla が安定化する、または、魔法のパージョン番号 1.0 に近づくにつれ、凍結されていないインタフェースに対する凍結されているものの割合は増えるでしょう。</p>
-<p>Mozilla ビルドする一つのステップは、インタフェース定義ファイルを自動的に C言語 /C++ ヘッダファイルに翻訳することです。これは Mozilla の持つ IDL コンパイラである xipdl の仕事です。</p>
-<p>メソッドとメンバデータに加えて、インタフェースは追加の属性を持っています。インタフェースは UUID というインタフェースごとに唯一に識別可能な番号を持っています。インタフェースはスクリプト記述可能な属性を持つことが出来ます。これは、インタフェースに JavaScript のコードからもアクセス可能であるということです。スクリプト記述可能なインタフェースは JavaScript ランタイムの範囲内で有効なパラメータのためのデータタイプを使うためだけに限定されています。</p>
-<h3 id="XPCOM_.2F_nsISupports_.2F_nsCOMPtr" name="XPCOM_.2F_nsISupports_.2F_nsCOMPtr">XPCOM / nsISupports / nsCOMPtr</h3>
-<p>XPCOM は Mozilla 自身の COM (コンポーネント・オブジェクト・モデル component object model) のインプリメンテーションです。名前の頭につく XP は、それがクロスプラットフォームであることを意味します (この XP がつくということを、特定の OS 製品のためのように見えるので、XP のつくこの名前で混乱しないこと)。実際のところ、クロスプラットフォームであるので、XPCOM は、他の形の COM より、用途は広いです。</p>
-<p>最終的には、mozilla.org にある紹介ドキュメント <a href="ja/XPCOM">XPCOM</a> を読むべきでしょう。ハックを始めるためには、XPCOM は COM のコンセプトを働かすエンジンだということができます。これは、オブジェクト仲介人の役割を演じることも含まれています。</p>
-<p>一般に、インタフェースはジョブを行うために使われることのできるオブジェクトを記述します。もし、しなければならないジョブがあるなら、インタフェースで提供される インプリメントをリクエストする必要があります。そのインプリメントは他のコンポーネントの範囲内に属することが出来ます。あなたの望む特定のインプリメントに決定するために、テキストベースの識別子である規約 ID を利用しています。規約 ID は、細部まで定義されたインターフェースを使用することで利用しやすくなる、インプリメントの動作上の契約です。XPCOM ランタイムシステムは、どのクラスが規約 ID でインプリメントされているか、どのコンポーネントがそれを提供しているかを知っています。</p>
-<p>たとえ、あなたのコードが単独のコンポーネント内だけのものであり、COM の使用が必要条件ではないとしても、COM はいずれにせよとてもしばしば使われます。一つの理由は柔軟さにあります。他の理由として、JavaScript を利用してインプリメントされた Mozilla のロジックのある部分と機能を共有することを許すためです。Mozilla は実行時にインタプリタ言語の JavaScript と コンパイル言語の C++ の間でコミュニケーション可能とする XPConnect と呼ばれる技術を提供しています。</p>
-<p>実行時に COM オブジェクトのインスタンスが必要なときにはいつでも、クラスオブジェクトは作成され、インタフェースのポインタが与えられます。いくつかの理由でこれらのインスタンスが参照をカウントされることが決められました。一つの理由は効率です。そのために、オブジェクトの不要なコピーは省かれるべきです。他の理由は、データオブジェクトはスレッド間で渡されるべきですが、すべてがメモリ上の同じデータオブジェクトに対するポインタを維持するためです。だからです。最後に、同じデータオブジェクトは多数のコンポーネントに参照されたり、多数のリストに貯えられたりすべきだからです。</p>
-<p>参照の生存期間は異なるため、どのくらいしばしば現在何かに参照されているという状態であるか覚えておくためには、それぞれのオブジェクトが参照のカウントを保持するのが最も簡単な方法です。オブジェクトから参照されたとき (XPCOM エンジンによる直接参照もしくは、関数呼び出しによって)、リファレンスのカウントのケアを確実にする必要があります。オブジェクトへの参照を維持するかどうかや、参照を終えられるかどうかを教え、参照を削除しなくてはなりません。そのように、オブジェクトはそれがまだ必要とされているかどうかを自分自身で判断することが出来ます。オブジェクトがもう不要なら、自分自身でメモリから削除します。</p>
-<p>この一般的な機能を満たすために、インタフェースをインプリメントする Mozilla のすべてのクラスは参照カウント機能と自動破棄機能を備えた nsISupports という共通基礎クラスを共有しています。このような共通基礎クラスは、どんな COM のインプリメントにも存在します。</p>
-<p>あなたが割り当てたものは、あなたが掃除 (削除) しなければならない、という一般的なルールがあります。例えば、参照を追加したいとき、もう不要となったときすぐさま参照を解放することを強く促します。そうしなければメモリリークといった問題を引き起こすことになるでしょう。</p>
-<p>C++ では、nsISupports 基本クラスのメソッドの明白なメソッド呼び出しによって行われます。しかし、それらのメソッド呼び出しは、忘れやすいだけでなく、コードの可読性も低下させます。特に多くの関数やメソッドは複数の出口を持っているからです (例：return 文など)。</p>
-<p>関数やメソッドの出口毎にすべてのオブジェクトへの参照を解放することを確実にしなければなりません。これを楽にするために、解放の呼び出しを繰り返さなくて良いために、一般的な補助クラスは <a href="ja/NsCOMPtr">nsCOMPtr</a> という名前の COM オブジェクトへのポインタを扱うために提供されています。これは XPCOM の特徴の一つで、COM コーディングをより楽にします。これは、特定のオペレータのオーバーライドを通してポインタをシミュレートします。いくつかの例外的ケースがありうるにも関わらず、このような一般的なルールはほとんどすべてのコードで守られています。：ポインタ変数 "interface*" をインタフェースをインプリメントしたオブジェクトとして使うつもりがあるときにはいつでもローカル "nsCOMPtr&lt;interface&gt;" 変数をかわりに使う。このポインタが "スコープ範囲外" となったらすぐに、可能ならデストラクタが自動的に参照カウントを減らします。</p>
-<p>インタプリタ言語の JavaScript では、これはコード上で簡単に行えます。それは、ガベージコレクションのためです。可能なときに参照を自動的に減少させる魔法があるのです。しかし、この魔法は循環参照しないことを必要とします。例えば、もし、二つのオブジェクトがあり、お互いへの参照を含んでいても、他のオブジェクトがそれらを参照していないとき、それらのオブジェクトは検出されません。それらのオブジェクトはプログラム実行の残りの間メモリに存在しつづけます。</p>
-<h3 id=".E4.BE.8B.E5.A4.96_.2F_nsresult" name=".E4.BE.8B.E5.A4.96_.2F_nsresult">例外 / nsresult</h3>
-<p>コード実行が実行時に失敗することもあります。失敗を扱うプログラミングメカニズムが例外 (エクセプション) を用いることです。Mozilla では JavaScript 部分で例外を使っており、C++ 部分では使っていません。以前やったことがスタックの中にあるため、例外はいつでもポータブルというわけではないというのが、そのいくつかの理由のうちの一つです。Mozilla の C++ のコードは戻り値で例外を真似ています。つまり、JavaScript の中では、tyr-catch のブロックを使うことが出来、C++ の中では、インタフェースのメソッドを使う場合はいつでも戻り値を見なくてはなりません。その戻り値は nsresult 型です。このため、IDL ファイルで定義されている論理的な戻り値型は、C++ コードの中の追加のメソッドのパラメータにマッピングされています。</p>
-<p>nsresult 型は、失敗理由の付加情報も運ぶことを意図しています。成功か失敗かという単純なレポートの代わりに、整数型を使い、多くの異なったエラーコードを定義することを許しています。</p>
-<p>いくつかの戻り値があります。例えば、NS_OK は、何事もうまくいっていて、そのままプログラムを続けることが出来るという場合に使われ、NS_ERROR_FAILURE は、何か異常が発生しているけれども、今のところそれ以上の詳細は必要ないといった場合に使われます。</p>
-<p>それに加え、互いのコンポーネントはアプリケーションの他のエリアで使用していない失敗コードを上書きしないエラーコードの定義をするために、独自の範囲の整数をリクエストすることが出来ます。詳細な情報は mozilla/xpcom/base/nsError.h を参照のこと。</p>
-<h3 id="C.2B.2B_.E3.81.AB.E3.81.8A.E3.81.91.E3.82.8B.E6.96.87.E5.AD.97.E5.88.97" name="C.2B.2B_.E3.81.AB.E3.81.8A.E3.81.91.E3.82.8B.E6.96.87.E5.AD.97.E5.88.97">C++ における文字列</h3>
-<p>多くのアプリケーションやクラスライブラリでは、単なる簡単な string (文字列) クラスを使用することを決めている中で、Mozilla 開発者は、文字列により強力な機能を求めました。実行時の動的な振る舞いを異なったシチュエーションのために最適化することを許すために、いくつかの文字列クラス階層をインプリメントしました。時には文字列のサイズを変更するだけでしょうし、時には、自動的にサイズが大きくなる文字列が必要でしょう。そのため、たとえば、ただの平坦な文字列ではなく、断片化された文字列型も使用可能です。</p>
-<p>さらなる要求としては、Mozilla は完全な多言語対応をしなくてはならないということです。ユーザにみせる情報を扱う文字列は、そのためにマルチバイトな Unicode 文字列を使っています。</p>
-<p>文字列型はテンプレートに基づき、可変型のような文字列型を伴い、通常文字列と Unicode 文字列を使うのを同じロジックで扱えるようにしています。</p>
-<p>多くの文字列クラスを持つというアプローチは多くの柔軟性を意味する一方、欠点としてMozilla の文字列クラスを学ぶのが易しい作業ではなくなる、ということがあります</p>
-<h3 id="GUI_.28.E3.82.B0.E3.83.A9.E3.83.95.E3.82.A3.E3.82.AB.E3.83.AB.E3.83.BB.E3.83.A6.E3.83.BC.E3.82.B6.E3.83.BB.E3.82.A4.E3.83.B3.E3.82.BF.E3.83.95.E3.82.A7.E3.83.BC.E3.82.B9.29_.2F_XUL" name="GUI_.28.E3.82.B0.E3.83.A9.E3.83.95.E3.82.A3.E3.82.AB.E3.83.AB.E3.83.BB.E3.83.A6.E3.83.BC.E3.82.B6.E3.83.BB.E3.82.A4.E3.83.B3.E3.82.BF.E3.83.95.E3.82.A7.E3.83.BC.E3.82.B9.29_.2F_XUL">GUI (グラフィカル・ユーザ・インタフェース) / XUL</h3>
-<p>たいていの OS では、GUI を開発するための独自の方法を定義していて、それぞれたいてい異なっています。</p>
-<p>Mozilla のようなクロスプラットフォームアプリケーションにとっては、アプリケーションのロジックから OS 依存のロジックを隠すテクノロジーをもつということは、重大なことです。</p>
-<p>今までに、多くの C 言語と C++ のライブラリはクロスプラットフォームに書かれてきました。私の知るところによると、それらは Mozilla には使われていません。またしても、独自のグラフィックシステムを作りました。</p>
-<p>GUI のレイアウトを定義するとき、二つの可能性のいずれかを共にするかを選ぶことが出来ます。まず、表示させたいそれぞれの UI (ユーザ・インタフェース： user interface) 要素の絶対位置を定義する方法があります。この方法は、実際に多くの GUI ライブラリで選ばれています。しかし、これには欠点があります。エレメントが加わってレイアウトが変わったとき、十分な柔軟性がないことです。それは、すべての要素を新しい位置に計算し直す必要があるからです。それは、どのエレメントが重なっているかなどのフィードバックをいちはやく得るために、よりグラフィカルにしなくてはなりません。しかし、いまだ、UI は異なるメトリクスをもつフォントが使われなくてはならないとき、意図したように見えないかもしれません。このことは、UI が使い物にならないと判断させます。</p>
-<p>Mozilla の開発者は、より柔軟性のあるものを求めました。Mozilla はクロスプラットフォームなので、フォントにより注意を払う柔軟性を備えることが必要です。</p>
-<p>Mozilla 開発者は、論理的なもので UI のコンテンツがデザインされたところというアプローチを使うことを選びました。現在は UI エディタを使っていません。UI がどうみえるべきかを指示するファイルを書きました。実行時にレイアウトエンジンはどのフォントが利用可能か決定し、UI 詳細に定義されたすべての要求を考慮し、実際の UI を動的に生成します。これは、Web ブラウザが Web ページをどのように表示するかと似ています。</p>
-<p>Web は大部分がテキストベースのシステムから多くのプログラムのようなユーザインタフェースをもつとてもグラフィカルで裕福な環境へ移り変わってきました。そのため、Web ブラウザにとって、独自のユーザインタフェースを定義するために Web 言語を使うことはもっとも自然なことです。XUL(extensible user-interface language 拡張ユーザインタフェース言語) と呼ばれる UI 内容の記述のための XML ベースの文法を選びました (XUL についての良いリファレンスとして <a class="external" href="http://www.xulplanet.com/">XULPlanet</a> が利用できます)。</p>
-<p>XUL ファイルは、どの要素が UI を構成しているか、どこに要素が現れているかを記述します。XUL 言語は制御に反応してどういう働きがあるかをプログラマが定義することを許す属性を定義します。動的なアプリケーションのふるまいを定義するために、ある場合には特定のユーザインタフェースイベントが発生したときに呼ばれる JavaScript 関数を定義することが出来ます。それらの JavaScript 関数の中では、直接アプリケーションのふるまいを記述するか C++ で定義されたロジックを含む COM オブジェクトの利用可能な他のアプリケーションロジックを呼び出すかすることが出来ます。</p>
-<p>UI の論理的表現に加え、人々は UI のかわいらしい見た目を望んだりもします。UI の詳細な特徴を定義するために、例えば特定の UI 要素を表示するのに使われる画像を定義する CSS を使うこともあります。これは、"テーマ"や"スキン"を参照するアプリケーションのための追加の"ルックス"の定義を柔軟にします。Mozilla には、現在 Mozilla 開発者によって活発にメンテナンスされている「クラシック」と「モダン」という２つの「テーマ」が定義されています。Mozilla のための追加のテーマが存在するということは、それだけのバージョンの Mozilla が存在するということです。UI に毎日起こるすべての変化に同期をとりつづけることは、「テーマ」のデザイナにとって大きな仕事です。</p>
-<h3 id=".E3.83.93.E3.83.AB.E3.83.89.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0.E3.81.A8.E3.83.84.E3.83.AA.E3.83.BC" name=".E3.83.93.E3.83.AB.E3.83.89.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0.E3.81.A8.E3.83.84.E3.83.AA.E3.83.BC">ビルドシステムとツリー</h3>
-<p>現在、Mozilla は主に実行時に必要に応じて動的にロードされた多くの共有ライブラリの集まりのように使われています。COM システムによって、ソースコードの複数の場所を変更した場合でも、再コンパイルする必要があるのはアプリケーションの一部だけで良い場合が多い、という開発環境が可能となっています。これは、とても便利な開発環境です。しかし、これは実行の速度低下を意味します。一方、内部コンポーネントの大部分を静的にリンクした Mozilla バイナリを作ることも可能です。アプリケーションのサイズのため、このリンクステップには多くの時間がかかります。ディストリビューション向けのパッケージを準備するときに、この意味が良くわかるでしょう。</p>
-<p>それぞれのコンポーネントはその独自のディレクトリを Mozilla のルートディレクトリの中に持ちます。それはまた、呼び出したモジュールの範囲内でサブのコンポーネントを持つということです。Mozilla をどのようにビルドするか教えるツリーの全体にわたるメイクファイル (Make File) があります。</p>
-<p>プラットフォーム依存のコードのほとんどは、ツリーの少しの場所にだけ含まれます。OS と Mozilla の他のコードの間にあるレイヤーはこのコードによってインプリメントされたインタフェースです。ビルドが発生するものの中のプラットフォームを準備するプラットフォーム依存のコードだけがビルドされます。</p>
-<p>OS からのメッセージはプラットフォーム依存のコードによって集められています。そして、同じ方法でプラットフォームに独立したコードへ送られます。</p>
-<p>Mozilla プロジェクトに関する部品はプラットフォーム依存のレンダリング技術を使って書かれた OS 独立の部品です。</p>
-<p>ツリーの範囲内で、public と名づけられたディレクトリはたいていインタフェースのヘッダを含み、src と名づけられたディレクトリはたいていインタフェースのインプリメントやインタフェースのヘッダでないものを含みます。</p>
-<p>このプログラムのビルドはこのように大きなプロジェクトに慣れない人をひるませるかもしれません。ビルドには、パワフルなワークステーションで 20 分、古い PC なら 2 時間はかかるでしょう。まず、ソースを入手しなくてはなりません。そして、<a href="ja/Build_Documentation">ビルド資料</a> に含まれるルールを使ってそれをビルドします。ビルドしている間、ヘッダファイルのディレクトリを特に指定する必要がないように、すべてのヘッダファイルは dist/include ディレクトリに移動するでしょう。(集合としては chrome と呼ばれる) XUL 、画像、JavaScript ファイルもすべて chrome ディレクトリ (Mozilla のバイナリを含むディレクトリの子ディレクトリ) にコピーされるでしょう。これらは jar.mn と呼ばれるファイルの中で定義される <a class="external" rel="freelink">chrome://</a> という URL にマッピングされます。Mozilla のリリースバージョンでは、chrome ディレクトリは、.jar ファイルだけが含まれるでしょう。</p>
-<p>Mozilla をビルドするというのは、プロセスの一部に過ぎません。もし、開発したければ、<a class="external" href="http://www.cvshome.org/">CVS</a> と呼ばれるプログラムを使ったツリーのメンテナンスをしなくてはなりません。ビルドに失敗した時には、あなたのツリーの中のファイルとレポジトリの中のファイルとの結合が失敗した際に生じた競合を解消しなくてはなりません。また、ツリーをハックするとき、修正したツリーの部分をビルドしなくてはなりません。時折、depending と呼ばれるプロセスを使ってツリー全体を再ビルドしなくてはならないでしょう。ソースファイル間の依存を決定しなくてはならないからです。また、時折、ツリーを再ビルドするでしょう。たいていは、これをしている間、ツリーへの自身の行った変更をメンテナンスしていて、他人の変更と同期をとろうとしているでしょう。</p>
-<h3 id=".E3.82.A2.E3.83.97.E3.83.AA.E3.82.B1.E3.83.BC.E3.82.B7.E3.83.A7.E3.83.B3.E3.81.AE.E9.96.8B.E5.A7.8B" name=".E3.82.A2.E3.83.97.E3.83.AA.E3.82.B1.E3.83.BC.E3.82.B7.E3.83.A7.E3.83.B3.E3.81.AE.E9.96.8B.E5.A7.8B">アプリケーションの開始</h3>
-<p>Mozilla の COM システムは、タイプライブラリと、実行可能なコンポーネントの内部レジストリと、インタフェースに頼っています。アプリケーションを開始している間、レジストリが今も最新のものかのチェックが行われます。もし、変更されたライブラリを検知したとき、レジストリは更新されます。それぞれのコンポーネントはそのレジストレーションフェーズの間に初期化を行うことが許されます。もし、変更されたライブラリを検知したとき、それらはロードされ、初期化ロジックが実行されます。変更ライブラリに加え、それらのアプリケーションコンポーネントだけが必要とされたようにロードされます。</p>
-<h3 id=".E5.86.85.E9.83.A8.E9.80.9A.E7.9F.A5.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0" name=".E5.86.85.E9.83.A8.E9.80.9A.E7.9F.A5.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0">内部通知システム</h3>
-<p>このセクションでは Mozilla 内部で利用可能な機構について記述します。めったにこれは必要になりません。しかし、特定のイベントに対処する必要のある時には、このシステムを知ることが助けとなるでしょう。OOP (オブジェクト指向プログラミング) の考え方は、各々が各々自身の役割を果たすことというものです。しかし、それはしばしば他のコンポーネントがコンポーネント B で起きたあるアクションの引き金を引くとき、コンポーネント A がそれに対応しなくてはなりません。しかし、コードは部分で分離されているほうが好ましいため、B はそれを起こすのに何が必要かの詳細を知るべきではないのです。ここで必要なのは、次のような事です。もし、他のコンポーネントが B のアクションに反応する必要があるのであれば、B はそのアクションに対する引き金が引かれたら通知を送信するように拡張されるべきです。それに加え、B は誰が通知されるのを待っているか覚えているリストを実行時に動的に保持します。実行時に、A が初期化されたとき、A は B に通知リストの対象に加えてほしいと告知します。</p>
-<p>これをより一般化するため、中央観察サービス (central observer service) を使うことを決めました。コンポーネント B がアクションの引き金を引いたとき、観察サービスにすぐに通知し、記述的にイベントの名前を明確にします。A のようなコンポーネントは観察サービスに観察したいイベントの名前をもらえるよう申請します。その原則を使用し、観察サービスだけがイベントを見るコンポーネントのリストを扱わなくてはなりません。観察サービスはイベントの通知を受けると、その通知を、そのイベントへのすべてのコンポーネントリストに引き渡します。詳細は nsIObserver を参照のこと。</p>
-<h3 id=".E3.83.AD.E3.83.BC.E3.82.AB.E3.83.A9.E3.82.A4.E3.82.BC.E3.83.BC.E3.82.B7.E3.83.A7.E3.83.B3" name=".E3.83.AD.E3.83.BC.E3.82.AB.E3.83.A9.E3.82.A4.E3.82.BC.E3.83.BC.E3.82.B7.E3.83.A7.E3.83.B3">ローカライゼーション</h3>
-<p>Mozilla は人間の言語からコードを分離するデザインがされています。ユーザに見せる必要があるためにテキスト文字列が必要なときはいつでも JavaScript や C++ ファイルの中に直接文字列を保存することは許されません。かわりに、C++ や JavaScript のコードで使われるテキストのために記述的識別子を定義します。その識別子をキーとして使い、実際のテキストを取り出すための文字列集合インタフェースのメンバーを呼び出します。テキスト自身はテキストだけ格納された分離されたファイルに格納されます。Mozilla はモジュールの集合であるため、多くのファイルがあり、分離されたモジュールにそれぞれ所属します。その分離にともなって、翻訳者がテキストファイルの言語別バージョンを作るのが簡単なのです。</p>
-<p>UI を定義するとき、2 種類の文字列があります。ある文字列は、入力フィールドのテキストやヘルプの中にだけ出てくるテキストのようにアプリケーションがコンパイルされ、パッケージ化されたその時に知られるもので、またある文字列は、実行時に動的に組み立てられます。</p>
-<p>実行時にアクセスされる必要のないテキストを定義するときはいつでも、DTD ファイルの中に定義してください。XUL ファイルの中でそのテキストを直接参照することが出来ます。</p>
-<p>実行時にテキストを伴った動作が必要なとき、例えばテキストが実行時に入力される必要のあるユーザ名のための代替文字列を含むとき、properties ファイルにテキストを定義してください。</p>
-<h3 id=".E3.82.B3.E3.83.BC.E3.83.87.E3.82.A3.E3.83.B3.E3.82.B0.E3.81.A8.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.81.AE.E3.83.AB.E3.83.BC.E3.83.AB" name=".E3.82.B3.E3.83.BC.E3.83.87.E3.82.A3.E3.83.B3.E3.82.B0.E3.81.A8.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.81.AE.E3.83.AB.E3.83.BC.E3.83.AB">コーディングとレビューのルール</h3>
-<p>Mozilla ダウンロード、コードの変更、独自の変更を含むバージョンでの作業などがフリーで行えます。</p>
-<p>しかし、Mozilla で使われているオープンソースの背後にある一つの考え方に次のようなものがあります。ソースをフリーで入手できるかわりに、ソースに変更を加えたら、コミュニティに何がしかの還元を考えるべきです。そうすることにより、貢献者となるのです。</p>
-<p>しかし、Mozilla コミュニティは公開の中央 Mozilla コードに組み込まれるという変更をただ受け入れることは出来ないと決定しました。自分のコードをその中の一部にしたければ、次のようなルールに従わなければなりません。それは法律のようなものではありません。しかし、基本的に、あなたは、あなたの変更が良いものであると他の人々が認めるよう説得しなければなりません。</p>
-<p>この考え方は、Mozilla のコードをより正しい状態にするために作られた多くの効果があります。Mozilla のコードはどのソフトウェアの一部と同様に、完璧からはほど遠く、人々は保守性を低下させるものは何でも取り除こうとし、正しいと思われるコードだけを受け入れます。</p>
-<p>これを達成するために、Mozilla コミュニティはすべてのコードは他のすでによく知られた Mozilla ハッカーたちに受け入れられる必要があると決めました。ここに２つの段階のレビューがあります。まず、コード変更希望者は、変更したいコードの部分の所有者から最初のレビュー (r=) を受ける必要があります。要求された修正を行うことが期待されます。そうでなければここで終わりです。もし、最初のレビューが終われば、たいていの場合スーパーレビュー (sr=) と呼ばれるレビューを受ける必要があります。限られたメンバーである " Mozilla 導師 " という、どのコードがよく、どこを変更するべきかについての判断が優れていると認められている人々がいます。一度、両方のレビューを受ければ、ほとんどの場合、コードはチェックインされます。ある特定の事例では、他のレベルのレビューがあり、それは別の場所に記述されます。</p>
-<p>多くの人々が Mozilla を変えています。みんなが Mozilla をよりよくしようとする一方、どの変更も思いがけない面への影響というリスクがあります。これは、変更の結果、アプリケーションの機能が動かなくなるといったものから、Mozilla ソースコードがコンパイルできなくなるといった単純な問題にまで及びます。後者は、"ツリーが壊れている、燃え上がっている、赤い"と表現され、ここでツリーとは CVS リポジトリの事です。</p>
-<p>ある OS とコンパイラの組み合わせの上でだけ開発をしていて、移植性について (Mozilla.org のドキュメント参照のこと) 注意を払っていないとき、ツリーは簡単に壊れてしまいます。ツリーを壊さないためにベストを尽くす必要があり、レビューを受けることで、願わくば、変更点をチェックインするより早く潜在的な問題を発見したいのです。</p>
-<p>ツリーが壊れてしまったとき、Mozilla コミュニティは、ツリーが壊れている間ほかのチェックインを許さないというルールを決定します。これは、この問題を修正する人を助けます。ほかの変更を許すことは、新しいチェックインがあたらしい問題を含んでいるかもしれないために、問題のほんとうの原因を見つけることを難しくします。</p>
-<h3 id=".E3.83.9E.E3.82.A4.E3.83.AB.E3.82.B9.E3.83.88.E3.83.BC.E3.83.B3" name=".E3.83.9E.E3.82.A4.E3.83.AB.E3.82.B9.E3.83.88.E3.83.BC.E3.83.B3">マイルストーン</h3>
-<p>数週間ごとに、Mozilla.org はソースレポジトリの新しいスナップショットを出します。この考え方は、世界の人々が現在のスナップショットを試してみて、彼らの見つけた問題 (バグ) を報告すべきだというものです。しかし、Mozilla.org はそれらのマイルストーンはテスト目的だけのために出されたということを強調したいのです。</p>
-<p>より安定したマイルストーンを準備するために、ソースコードレポジトリを変更するためのルールは、新しいマイルストーンを準備する前にはより厳格なものになります。Mozilla.org は、スケジュールを引き、マイルストーン目標日の前の２日間、Mozilla.org の"ドライバ"と呼ばれる人たちに認可されたチェックインだけが許されます。ドライバは、Mozilla レポジトリに関して、最高の権限をもっている人の集団です。ドライバはまた、マイルストーンが準備できているのか、よりマイルストーンを安定させるためにマイルストーンを出すためより多くの修正を許すために日程を遅らせるかどうかも決定します。</p>
-<h3 id="Bugzilla" name="Bugzilla">Bugzilla</h3>
-<p><a class="link-https" href="https://bugzilla.mozilla.org/">Bugzilla</a> は Mozilla.org の Web ベースのバグ追跡システムです。問題に遭遇したときはいつでも、ユーザは新しいバグ (時には問題に切符を切ることとして知られてもいます) を、よく詳細に何が起こったかとともに申し立てるよう依頼されます。バグが公表されるなり、番号を発給するなりします。この番号は問題について話されるときに使われます。開発者は"バグ"について署名し、コメントします。そして、修正方法を知っていればどのように問題の修正方法を提案するかを見せるために、パッチを添付するでしょう。レビューも、このシステムの内部で進みます。</p>
-<p>バグという単語はしばしばソフトウェアのエラーという意味にみなされます。しかし、Bugzilla の内部では、バグは追跡されるべきものとなります。これはソフトウェアのエラーから、機能拡張のリクエストに及びます。例えば、このドキュメントの発展は {{ Bug(123230) }} で追跡されています。</p>
-<p>もし、C++ の開発者でないなら、Bugzilla で貢献できます。これは、簡単なバグ報告ツールとして出発し、ほかのプロジェクト (例えば <a class="external" href="http://www.redhat.com/">Redhat</a> のような) まで多くのユーザに使われる機能的な複雑なシステムにすっかり変わりました。</p>
-<h3 id="Webtools_.2F_LXR_.2F_Bonsai" name="Webtools_.2F_LXR_.2F_Bonsai">Webtools / LXR / Bonsai</h3>
-<p>Webtools は情報を貯えるツールをベースとしたサーバで、その情報を表示されることやときに操作することまで許します。そのシステムには Mozilla のように Web ブラウザを使ってアクセスできます。</p>
-<p>Mozilla 開発者は開発を容易にするためにいくつかのツールを作りました。すでにお話した Bugzilla もそうです。</p>
-<p><a class="external" href="http://lxr.mozilla.org/">LXR</a> は Mozilla のソースコードのためのハイパーテキスト検索エンジンです。識別子やテキストを調べることが出来、Mozilla の中のどこでそれが使われているかを見られるでしょう。検索結果項目をクリックすることで、直接現在のソースコードが得られます。コードはページに表示され、識別子にはハイパーリンクがはられ、それはクリックすると、その識別子についての LXR 検索結果を得られます。LXR はソースコードを表示し、それを通してすぐにナビゲートするのに使うことが出来ます。これは、Linux プロジェクトの glimpse のエンジンに内部修正を加えたものをベースにしています。</p>
-<p><a class="external" href="http://tinderbox.mozilla.org/">Tinderbox</a> はソースコードレポジトリの現在の状況を表示するツールです。Mozilla.org は、多くの異なった OS のために、繰り返し、絶え間なく中央レポジトリから新しいソースコードを手に入れ (チェックアウトし)、コンパイルを試みるマシンをホストしています。コンパイルが終わったとき、プログラムがまだ正しく動作するかをチェックするためのいくつかの自動テストが実行されます。コンパイルとテストの結果は中央の Tinderbox システムにレポートされます。Tinderbox ページにアクセスすると、ソースコードレポジトリが現在いい状態にあるかどうかこの数時間の間にどんな変化があったのかを見ることが出来ます。Tinderbox は縦軸が時間を示し、横軸が OS ごとの状態を示すグラフを表示します。それぞれのコンパイル・テストフェーズはビルドの要求された時間で定義されたバーで表されます。</p>
-<p>バーは色付けられています。緑は Good を示します。黄色はコンパイル中であることを示します。オレンジはコンパイルとビルドが終わったけれども自動テストに失敗したことを示します。赤はソースコードのコンパイルが成功していないことを示します。もしツリーが赤になると、開発を停滞させます。</p>
-<p>Tinderbox はとても有用なツールで、ソースコードレポジトリに変更を加える人は誰でも、例えば、自分の変更がなにか問題を起こしていないかのような"ツリーを見る" ことを期待できます。</p>
-<p>より援助とするため、追加の情報が Tinderbox ページで利用できます。チェックインしたときに、その人の名前がページに現れます。行われた変更の一覧へのリンクがあります。もし、コンパイルかテストが失敗したとき、ボックスはコンパイル失敗理由を示すコンパイラからのアウトプットへのリンクも含みます。ページのいつかのテキストはパフォーマンス測定の結果も示します。</p>
-<p>ほかの Web ツールとして、<a class="external" href="http://bonsai.mozilla.org/">Bonsai</a> があります。Bonsai はソースコードレポジトリのすべての変更を追跡します。誰かの行ったすべての変更の一覧を取り出すことが出来ます。Bonsai は変更一覧の問い合わせのための強力なインタフェースも提供します。</p>
-<h3 id=".E6.9B.B4.E3.81.AA.E3.82.8B.E6.83.85.E5.A0.B1.E3.82.92.E6.8E.A2.E3.81.99" name=".E6.9B.B4.E3.81.AA.E3.82.8B.E6.83.85.E5.A0.B1.E3.82.92.E6.8E.A2.E3.81.99">更なる情報を探す</h3>
-<p>一般的なプログラミング技術について述べられたものについてもっと知りたければ、Web でフリーのドキュメントを捜し求めることを勧めます。うまくいけば、そのドキュメントでの言及が導いてくれるでしょう。もし、本を読むことをより好むなら、一般的な説明を著者が試みている本であって、いくつかの特定の OS に集中していない本を選ぶことを勧めます。</p>
-<p>Mozilla に関するたいていのドキュメントは www.mozilla.org の Web サイトに掲載されています。もし、探しているものがなければ、サーチエンジンを使うことを試してみてください。いくつかのポピュラーなサーチエンジンは、特定の Web サイトに限定して検索することのできる上級 (詳細) 検索オプションを提供しています。</p>
-<div class="originaldocinfo">
- <h2 id=".E5.8E.9F.E6.96.87.E6.9B.B8.E3.81.AE.E6.83.85.E5.A0.B1" name=".E5.8E.9F.E6.96.87.E6.9B.B8.E3.81.AE.E6.83.85.E5.A0.B1">原文書の情報</h2>
- <ul>
-  <li>著者: Kai Engert</li>
-  <li>最終更新日: September 24, 2004</li>
-  <li>著作権: Portions of this content are © 1998–2007 by individual mozilla.org contributors; content available under a Creative Commons license | <a class="external" href="http://www.mozilla.org/foundation/licensing/website-content.html">詳細</a></li>
- </ul>
-</div>
-<div class="noinclude">
-  </div>
diff --git a/files/ja/mdn/guidelines/does_this_belong_on_mdn/index.html b/files/ja/mdn/guidelines/does_this_belong_on_mdn/index.html
index 64d4de378a..1b8f12161e 100644
--- a/files/ja/mdn/guidelines/does_this_belong_on_mdn/index.html
+++ b/files/ja/mdn/guidelines/does_this_belong_on_mdn/index.html
@@ -1,5 +1,5 @@
 ---
-title: これは MDN Web Docs に掲載するものですか？
+title: MDN Web Docs に掲載するものであるかどうか
 slug: MDN/Guidelines/Does_this_belong_on_MDN
 tags:
   - Guide
@@ -9,11 +9,9 @@ translation_of: MDN/Guidelines/Does_this_belong_on_MDN
 ---
 <div>{{MDNSidebar}}</div>
 
-<div>{{IncludeSubnav("/ja/docs/MDN")}}</div>
-
 <p><span class="seoSummary">この記事では、ある主題やコンテンツの種類を MDN Web Docs に載せるべきかどうかを決定する方法について説明します。</span>また、詳細ではありませんが、コンテンツを配置する可能性のある他の場所についても検討します。</p>
 
-<h2 id="The_question" name="The_question">問い</h2>
+<h2 id="The_question">問い</h2>
 
 <p>何らかの文書をまとめる準備をしている場合、その情報を MDN Web Docs に載せるどうか考えるかもしれません。加えて、ソースコード内の文書を維持したり、その文書を <a href="https://wiki.mozilla.org/">Mozilla wiki</a> や、git リポジトリー内の readme ファイルに置いたりすることを検討しているかもしれません。この記事の目的は、あなたのコンテンツが、これらのオプションのどれにふさわしいのかを決めるのに役立つことです。</p>
 
@@ -24,55 +22,55 @@ translation_of: MDN/Guidelines/Does_this_belong_on_MDN
  <li>文書の性質 (これはどんな種類の文書か)</li>
 </ul>
 
-<p>MDN への寄稿は、すべて特定のオープンソースライセンスに該当することに注意してください。これは <a href="/en-US/docs/MDN/About">MDN について</a>ページに<a href="/ja/docs/MDN/About#Copyrights_and_licenses">詳細に記されています</a>。</p>
+<p>MDN への寄稿は、すべて特定のオープンソースライセンスに該当することに注意してください。これは <a href="/en-US/docs/MDN/About">MDN について</a>ページに<a href="/ja/docs/MDN/About#copyrights_and_licenses">詳細に記されています</a>。</p>
 
 <div class="note">
-<p><strong>注</strong>: MDN Web Docs を利用したり、投稿したりする際には、Mozilla の<a href="https://www.mozilla.org/en-US/about/legal/terms/mozilla/">ウェブサイトおよびコミュニケーション利用規約</a>が適用されることに注意してください。この文書を確認して、Mozilla のサイトで投稿できること、できないことを確認してください。</p>
+<p><strong>注</strong>: MDN Web Docs を利用したり、投稿したりする際には、Mozilla の<a href="https://www.mozilla.org/en-US/about/legal/terms/mozilla/">ウェブサイトおよびコミュニケーション利用規約</a>が適用されることに注意してください。この文書を確認して、 Mozilla のサイトで投稿できること、できないことを確認してください。</p>
 </div>
 
-<h2 id="What_topics_belong_on_MDN_Web_Docs" name="What_topics_belong_on_MDN_Web_Docs">どのようなトピックが MDN Web Docs に載るのか</h2>
+<h2 id="What_topics_belong_on_MDN_Web_Docs">どのようなトピックが MDN Web Docs に載るのか</h2>
 
 <p>一般的には、オープンなウェブ向きの技術であれば、MDN 上で文書化します。これは、現在および近い将来にサイトやアプリケーションを作成するウェブ開発者が使用できる機能を意味します。複数のブラウザーで実装されていて、標準として受け入れられているか、標準化に向けて進んでいるものであれば、そうですね。もしそれがまだ非常に実験的で、複数のブラウザーで実装されておらず、変更される可能性がある場合、それでも載せるのに適してはいますが、ライターのチームが取り組むべき優先事項とは見なされないかもしれません。</p>
 
 <p>主にフロントエンドのウェブ技術に重点を置いています。</p>
 
 <ul>
- <li><a href="/ja/docs/Web/HTML" title="HTML">HTML</a></li>
- <li><a href="/ja/docs/Web/CSS" title="CSS">CSS</a></li>
- <li><a href="/ja/docs/Web/JavaScript" title="JavaScript">JavaScript</a></li>
- <li><a href="/ja/docs/Web/SVG" title="SVG">SVG</a></li>
+ <li><a href="/ja/docs/Web/HTML">HTML</a></li>
+ <li><a href="/ja/docs/Web/CSS">CSS</a></li>
+ <li><a href="/ja/docs/Web/JavaScript">JavaScript</a></li>
+ <li><a href="/ja/docs/Web/SVG">SVG</a></li>
  <li><a href="/ja/docs/Web/API">Web APIs</a></li>
- <li><a href="/ja/docs/Web/API/WebGL_API" title="WebGL">WebGL</a></li>
+ <li><a href="/ja/docs/Web/API/WebGL_API">WebGL</a></li>
  <li>など</li>
 </ul>
 
 <div class="note">
-<p><strong>Note</strong>: バックエンドテクノロジーには、別の文書化の場所があり、MDN はこれにとって変わるつもりはありませんが、<a href="/ja/docs/Learn/Server-side">いくつかの例外はあります</a>。</p>
+<p><strong>Note</strong>: バックエンドテクノロジーには、別の文書化の場所があり、 MDN はこれにとって代わるつもりはありませんが、<a href="/ja/docs/Learn/Server-side">いくつかの例外はあります</a>。</p>
 </div>
 
 <p>また、複数の技術にまたがるが、以下のようなウェブ開発に関連したトピックも歓迎します。</p>
 
 <ul>
- <li><a href="/ja/docs/Web/Accessibility" title="Accessibility">Accessibility</a></li>
+ <li><a href="/ja/docs/Web/Accessibility">Accessibility</a></li>
  <li><a href="/ja/docs/Web/Guide/AJAX">AJAX</a></li>
  <li><a href="/ja/docs/Web/Guide/Graphics">ウェブグラフィック</a></li>
  <li><a href="/ja/docs/Web/Progressive_web_apps">プログレッシブウェブアプリ</a></li>
- <li><a href="/ja/docs/Games/">ウェブベースのゲーム</a></li>
+ <li><a href="/ja/docs/Games">ウェブベースのゲーム</a></li>
 </ul>
 
 <div class="note">
 <p><strong>注:</strong> MDN は、ウェブに公開されていて、特に一般的に使われている場合には、一部の標準外の機能をカバーしています。例えば、WebKit 固有の CSS プロパティのドキュメントがあります。MDN は、ウェブ開発者にとって十分に有用であると考えられる場合には、ウェブ標準以外の技術もカバーしています。<a href="/ja/docs/Related">ウェブ関連技術</a>のセクションを参照してください。</p>
 </div>
 
-<h2 id="What_topics_dont_belong_on_MDN_Web_Docs" name="What_topics_dont_belong_on_MDN_Web_Docs">MDN Web Docs に掲載しない主題</h2>
+<h2 id="What_topics_dont_belong_on_MDN_Web_Docs">MDN Web Docs に掲載しない主題</h2>
 
 <p>一般医、オープンなウェブ標準ではないものはすべて、MDN に掲載するものではありません。以下にもっと具体的に示します。</p>
 
-<h3 id="Mozilla_products" name="Mozilla_products">Mozilla 製品</h3>
+<h3 id="Mozilla_products">Mozilla 製品</h3>
 
 <p>このカテゴリーの文書には、 Mozilla 製品に対して開発者として作業する方法と、これらのオープンソースプロジェクトに貢献する方法との、両方があります。</p>
 
-<p>MDN には Mozilla 製品の文書が大量にありますが、新規コンテンツ開発の重点はオープンウェブに置いています。MDN に Mozilla 製品の文書を新規作成することは推奨されません。Mozilla 製品 (やそうなるかもしれない製品) の作業を進めている場合は、<a href="https://wiki.mozilla.org/Engagement/MDN_Durable_Team">MDN スタッフチーム</a>のメンバーに話して、その製品の文書化の道を議論してください。また、下記の<a href="#Cases_for_documenting_elsewhere">他の場所に文書化する場合</a>も見てください。</p>
+<p>MDN には Mozilla 製品の文書が大量にありますが、新規コンテンツ開発の重点はオープンウェブに置いています。MDN に Mozilla 製品の文書を新規作成することは推奨されません。Mozilla 製品 (やそうなるかもしれない製品) の作業を進めている場合は、<a href="https://wiki.mozilla.org/Engagement/MDN_Durable_Team">MDN スタッフチーム</a>のメンバーに話して、その製品の文書化の道を議論してください。また、下記の<a href="#cases_for_documenting_elsewhere">他の場所に文書化する場合</a>も見てください。</p>
 
 <ul>
  <li><a href="/ja/docs/Mozilla/Firefox">Firefox ブラウザー</a>
@@ -93,7 +91,7 @@ translation_of: MDN/Guidelines/Does_this_belong_on_MDN
  </li>
 </ul>
 
-<h3 id="What_else" name="What_else">それ以外</h3>
+<h3 id="What_else">それ以外</h3>
 
 <p>その他の MDN Web Docs のトピックとして適切ではないものの例です。</p>
 
@@ -103,7 +101,7 @@ translation_of: MDN/Guidelines/Does_this_belong_on_MDN
  <li>エンドユーザー向け文書。Mozilla 製品では、こうした文書は <a href="https://support.mozilla.org">Mozilla サポートサイト</a>に載っています。</li>
 </ul>
 
-<h2 id="What_types_of_documents_belong_on_MDN" name="What_types_of_documents_belong_on_MDN">MDN に掲載する文書の種類</h2>
+<h2 id="What_types_of_documents_belong_on_MDN">MDN に掲載する文書の種類</h2>
 
 <p>一般に、MDN は<em>プロダクト</em>のドキュメントであり、<em>プロジェクト</em>や<em>プロセス</em>のドキュメントではありません (<a href="/ja/docs/MDN">MDN 自体について</a>を除く)。そのため、もしドキュメントが「どのように使うか」や「どのように動作するか」 (「どの」とは下記で記述されている特定のカテゴリのことです) なら MDN に掲載しましょう。しかし、「誰が開発したか」や「開発プランについて」などは MDN にふさわしくありません。Mozilla 傘下で開発されているものの場合は <a href="https://wiki.mozilla.org/Main_Page">Mozilla project wiki</a> に掲載するといいでしょう。</p>
 
@@ -114,89 +112,5 @@ translation_of: MDN/Guidelines/Does_this_belong_on_MDN
  <li>設計書</li>
  <li>プロジェクト提案書</li>
  <li>仕様書や標準</li>
- <li>プロモーション素材、広告、<a href="#About_your_profile">個人情報</a></li>
+ <li>プロモーション素材、広告、<a href="#about_your_profile">個人情報</a></li>
 </ul>
-
-<h2 id="Advantages_to_documenting_on_MDN" name="Advantages_to_documenting_on_MDN">MDN で文書化する利点</h2>
-
-<p>もし書きたいドキュメントの内容や種類が MDN に適していると判断したとしても、MDN が最適な場所かどうか迷っているのであれば、読んでみてください。MDN でドキュメントを作成する利点はたくさんあります。</p>
-
-<h3 id="Lots_of_writers_and_translators" name="Lots_of_writers_and_translators">たくさんの執筆者と翻訳者</h3>
-
-<p>MDN コミュニティは巨大です。MDN のコンテンツの作成や保守に参加している人がたくさんいます。すべての大陸に (南極ではないかもしれませんが、それ以外には) 執筆者や編集者がいて、執筆者の数の多さには価値があります。</p>
-
-<ul>
- <li>雇用している本職の執筆者がいて、できるだけコンテンツをより良いものにする<strong>ミッション</strong>が与えられています。</li>
- <li>ボランティアの中心となるコミュニティがあり、あなたを手助けするかなりの量のコンテンツに協力しています。</li>
- <li>MDN チームは、あなたの文書化プロジェクトに十分人を配置することを保証すべく、一緒に作業してくれます。</li>
- <li>広大な MDN コミュニティは大量に貢献します。誤字の修正からコンテンツの編集レビューまで、助けてくれます。</li>
- <li><a href="https://chat.mozilla.org/#/room/#mdn:mozilla.org">MDN Web Docs チャットルーム</a>が <a href="https://wiki.mozilla.org/Matrix">Matrix</a> にあり、ライターコミュニティに話してアドバイスを得る場や、コンテンツ作成や維持を助ける人を採用する場を提供します。</li>
- <li>全世界に協力者がいるため、問題を見ていたり直したりする人がいつも周りにいます。</li>
- <li>ボランティアコミュニティには、多くの言語へ翻訳する人がいて、ドキュメントのローカライズを手伝っています。</li>
-</ul>
-
-<p>あなたの開発チームが、文書作成に全責任を負うことを望みますか？その場合はおそらく他の場所で文書を維持するべきでしょう。</p>
-
-<h3 id="Maintenance" name="Maintenance">保守</h3>
-
-<p>投稿者の数が非常に多いため、通常、コンテンツに問題がないかどうかを監視するために、誰かが常駐していま。スパム対策からコピー編集まで、24時間体制で対応しています。ここでは、私たちのチームができることのほんの一例をご紹介します。</p>
-
-<dl>
- <dt>スパム削除</dt>
- <dd>スパムは発生します。それに対処します。</dd>
- <dt>文章の推敲</dt>
- <dd>文章が思うようにはっきりしていなくても、正確でなくても心配する必要はありません。散文を、他の人が読めるような文章に仕上げます。</dd>
- <dt>スタイルの一貫性</dt>
- <dd>コンテンツが、それ自体だけでなく、その周りにある他のドキュメントとスタイル的に一貫していることを確認します。</dd>
- <dt>コンテンツ管理</dt>
- <dd>私たちのチームは、ドキュメントが他の関連資料とクロスリンクされ、記事が適切な場所に配置され、メニューやその他のインフラストラクチャが構築されているかどうかを確認し、フォローしやすく、理解しやすいように支援します。</dd>
- <dt>サイトとプラットホームの維持</dt>
- <dd>MDN には、サイトの稼働、運営、安全性を維持するITチームと、コンテンツが表示されるプラットフォームを維持、強化するプラットフォーム開発チームの両方があります。ドキュメントのインフラに自分のリソースや追加のリソースを割く必要はありません。</dd>
-</dl>
-
-<h2 id="Cases_for_documenting_elsewhere" name="Cases_for_documenting_elsewhere">他の場所で文書化した場合</h2>
-
-<p>MDN 以外のどこかで成果を文書化するのを考える理由も少しあります。その理由のいくつかと、利点や欠点をそれぞれ示します。</p>
-
-<h3 id="Plans_and_processes" name="Plans_and_processes">計画書や手順書</h3>
-
-<p>計画書や手順書や提案書は、決して MDN に載せてはいけません。これはとても単純なことです。製品が Mozilla のものなら、<a href="https://wiki.mozilla.org/Main_Page">Mozilla project wiki</a> に置くことができます。</p>
-
-<h3 id="The_project_is_on_GitHub" name="The_project_is_on_GitHub">Github 上のプロジェクト</h3>
-
-<p>Mozilla の製品のいくつかは Github にホストされていて、Github では wiki 的な文書化システムが提供されています。文書をそこに作成するチームもあります。文書を作成するには確実にフェアで便利ですが、次に注意してください。</p>
-
-<ul>
- <li>MDN はたぶんあなたを手助けできません。一般的に我々は MDN 以外の文書作業には加わりしません。例外はあるものの、まれです。</li>
- <li>あなたの文書と、関連する他の素材をクロスリンクするのは、困難だったり、不可能になるかもしれません。</li>
- <li>コンテンツが他の文書と一貫したスタイルが持てなくなります。</li>
- <li>他の (ウェブや Mozilla の) 文書の外にあるため、文書の発見しやすさが失われます。</li>
-</ul>
-
-<p>もちろん、これらのことが困ることではなかったり、問題にならなかったりする可能性もあります。チームによっては、自分たちでドキュメントを書いたりメンテナンスしたりすることを気にしない、あるいは最低限のドキュメントの必要性があるコードに取り組んでいるチームもあります。</p>
-
-<h3 id="You_want_to_keep_docs_in-source" name="You_want_to_keep_docs_in-source">ソース内に文書を置きたい場合</h3>
-
-<p>一部のチームでは、ドキュメントをソースツリーに配置したがることがあります。これは特にプロジェクトの内部やライブラリプロジェクトでよく見られます。</p>
-
-<p>このアプローチにはいくつかの利点があります。</p>
-
-<ul>
- <li>これにより、開発者が技術をコーディングしながらドキュメントを作成することができ、ドキュメントがコードを常に最新の状態に保つことができるようになります。</li>
- <li>ドキュメントは、バージョン管理を含め、コードと同じ開発とリリースのプロセスに従うことができます。</li>
-</ul>
-
-<p>欠点もあります。</p>
-
-<ul>
- <li>MDN Web Docs チームはあなたを助けることができません。コードが Mozilla のソースリポジトリー内にあっても、レビューとチェックインのシステムにより、docs チームが参加することは現実的ではありません。</li>
- <li>他の関連文書とのクロスリンクを行うための簡単なツールがありません。クロスリンクは、読者にコンテキストと追加の重要な情報の両方を提供します。</li>
- <li>ドキュメントが、他のドキュメントの中に存在しないことで発見可能性を失います。</li>
- <li>変換ツール (JavaDoc など) を使ってウェブで読めるドキュメントを作っても、MDN Web Docs でできるものほど魅力的なものにはならないでしょう。</li>
-</ul>
-
-<p>それでも、これはいくつかの種類のプロジェクト、特に小さなものや、あまり興味を持たれることが期待されていないものに対しては、実行可能な選択肢 (良い選択肢である可能性もあります) になるでしょう。</p>
-
-<h2 id="About_your_profile" name="About_your_profile">自分のプロフィールについて</h2>
-
-<p>MDN のプロフィールページには、限られた個人情報を掲載しても構いません。ユーザーのプロフィールは、企業や組織ではなく、人間を反映したものであるべきです。適度な自己 PR は OK ですが、リンクスパムは不可です。個人的な写真やその他の無関係なファイルをアップロードするためにプロフィールを使用<em>しない</em>でください。</p>
diff --git a/files/ja/mdn/guidelines/writing_style_guide/index.html b/files/ja/mdn/guidelines/writing_style_guide/index.html
index dd842145ce..0e9d715f87 100644
--- a/files/ja/mdn/guidelines/writing_style_guide/index.html
+++ b/files/ja/mdn/guidelines/writing_style_guide/index.html
@@ -2,45 +2,40 @@
 title: 執筆スタイルガイド
 slug: MDN/Guidelines/Writing_style_guide
 tags:
+  - Documentation
+  - Guide
+  - Guidelines
   - MDN
   - MDN Meta
   - MDN Web Docs
-  - MDN スタイルガイド
-  - ガイド
-  - ガイドライン
-  - スタイルガイド
-  - ドキュメンテーション
-  - 執筆スタイルガイド
+  - MDN style guide
+  - Style guide
+  - Writing style guide
 translation_of: MDN/Guidelines/Writing_style_guide
 ---
 <div>{{MDNSidebar}}</div>
 
-<div>{{IncludeSubnav("/ja/docs/MDN")}}</div>
-
 <p><span class="seoSummary">整理され、標準化され、読みやすい書き方でドキュメンテーションを示すために、 MDN Web Docs スタイルガイドはテキストがどのような体系、表記、書式などに従うべきかを説明します。これらは厳密な規則というのではなくガイドラインです。</span>形式よりも内容が重要であり、このため貢献する前にガイドラインを学ばなければならないと重荷に感じたりしないでください。とはいえ、真面目な他のボランティアが、あとであなたの成果をガイドラインに添うように書き換えても、びくびくしたり、ぎょっとしたりもしないでください。</p>
 
 <p>このガイドにおける言語的な観点は主に英語のドキュメンテーションに向けられたものです。その他の言語については独自のスタイルガイドを持っているかもしれません (是非つくってください)。これは多国語化チームのページのサブページとして公開してください。</p>
-
 <div class="note">
 <p>2017年12月現在、日本語独自コンテンツとしてのスタイルガイドは未作成だが、下記の資料が参考になります。</p>
-
 <ul>
  <li><a href="https://github.com/mozilla-japan/translation/wiki/L10N-Guideline">Mozilla 関連独自の L10N ガイドライン</a></li>
  <li><a href="https://github.com/mozilla-japan/translation/wiki/Editorial-Guideline">Mozilla 関連のドキュメントの表記ガイドライン</a></li>
 </ul>
 </div>
+<p>MDN 以外のサイトの記事での標準的なスタイルを知りたければ、<a href="https://www.mozilla.org/en-US/styleguide/">One Mozilla style guide</a>を参照してください。</p>
 
-<p>MDN 以外のサイトの記事での標準的なスタイルを知りたければ、<a href="http://www.mozilla.org/en-US/styleguide/" title="http://www.mozilla.org/en-US/styleguide/">One Mozilla style guide</a>を参照してください。</p>
-
-<h2 id="Basics" name="Basics">基本事項</h2>
+<h2 id="Basics">基本事項</h2>
 
 <p>よく普及しているスタイルガイドでは、始めるのに最適な場所は、文書の一貫性を維持するのに役立つような、とても基本的なテキストの取り決めです。以下のセクションでは、その基本のアウトラインを示します。</p>
 
-<h3 id="Page_titles" name="Page_titles">ページタイトル</h3>
+<h3 id="Page_titles">ページタイトル</h3>
 
 <p>ページタイトルは検索結果や、ページの先頭にあるパンくずリストのページ階層を構造化するために使用されます。 (ページの先頭や検索結果に表示される) ページタイトルは、ページの「スラッグ」とは異なっていても構いません。「スラッグ」とは、ページの URL の "<em>&lt;locale&gt;/docs/</em>" に続く部分のことです。</p>
 
-<h4 id="Title_and_heading_capitalization" name="Title_and_heading_capitalization">タイトルと見出しの大文字・小文字の使用</h4>
+<h4 id="Title_and_heading_capitalization">タイトルと見出しの大文字・小文字の使用</h4>
 
 <p>ページタイトルセクションの見出しは文スタイルの大文字化 (文頭と固有名詞の始めの1字だけを大文字にします) を用いるべきです。一般的な見出しスタイルの大文字化は用いません。</p>
 
@@ -51,32 +46,28 @@ translation_of: MDN/Guidelines/Writing_style_guide
 
 <p>この表記法が確立するより前の古い記事が多くあります。必要により気軽に書き換えてください。だんだん新しいやり方に慣れていくでしょう。</p>
 
-<h4 id="Choosing_titles_and_slugs" name="Choosing_titles_and_slugs">タイトルとスラッグの決め方</h4>
+<h4 id="Choosing_titles_and_slugs">タイトルとスラッグの決め方</h4>
 
 <p>ページのスラッグは短くするべきです。つまり新しい階層を作るとき、スラッグは1つか2つの単語で構成されるようにしましょう。</p>
 
 <p>一方で、タイトルは常識的な範囲で好きなだけ長くして構いません。また記事の内容がよくわかるものであるべきです。</p>
 
-<h4 id="Creating_new_subtrees" name="Creating_new_subtrees">サブツリーの新規作成</h4>
+<h4 id="Creating_new_subtrees">サブツリーの新規作成</h4>
 
 <p>ある主題とその周辺についていくつかの記事を追加する必要があるとき、ふつうはランディングページを作ってから各記事をサブページとして追加します。ランディングページは1つか2つの段落で、トピックやテクノロジーについての説明をします。つぎにそれぞれのページについて説明するサブページ一覧を付け加えます。我々が用意したマクロを利用すれば、一覧にページを追加する作業を自動化できます。</p>
 
 <p>例えば、<a href="/ja/docs/Web/JavaScript">JavaScript</a> ガイド を見てみましょう。以下のような構造になっています。</p>
 
 <ul>
- <li><a href="/ja/docs/Web/JavaScript/Guide" title="JavaScript/Guide">JavaScript/Guide</a> – メインの目次となるページ</li>
- <li><a href="/ja/docs/Web/JavaScript/Guide/JavaScript_Overview" title="JavaScript/Guide/JavaScript_Overview">JavaScript/Guide/JavaScript Overview</a></li>
- <li><a href="/ja/docs/JavaScript/Guide/Functions" title="JavaScript/Guide/Functions">JavaScript/Guide/Functions</a></li>
- <li><a href="/ja/docs/JavaScript/Guide/Details_of_the_Object_Model" title="JavaScript/Guide/Details_of_the_Object_Model">JavaScript/Guide/Details of the Object Model</a></li>
+ <li><a href="/ja/docs/Web/JavaScript/Guide">JavaScript/Guide</a> – メインの目次となるページ</li>
+ <li><a href="/ja/docs/Web/JavaScript/Guide/Introduction">JavaScript/Guide/JavaScript Overview</a></li>
+ <li><a href="/ja/docs/Web/JavaScript/Guide/Functions">JavaScript/Guide/Functions</a></li>
+ <li><a href="/ja/docs/Web/JavaScript/Guide/Details_of_the_Object_Model">JavaScript/Guide/Details of the Object Model</a></li>
 </ul>
 
 <p>階層の最上位部に自分の記事を配置しないようにしましょう。サイトのパフォーマンスを下げ、検索とサイト探索を非効率にします。</p>
 
-<div class="blockIndicator note">
-<p>メモ: 記事を追加するには、<a href="/ja/docs/MDN/Contribute/Howto/Create_and_edit_pages#Getting_page-creation_permissions">ページ作成特権</a>が必要です。</p>
-</div>
-
-<h3 id="General_article_content_guidelines" name="General_article_content_guidelines">全般的な記事内容のガイドライン</h3>
+<h3 id="General_article_content_guidelines">全般的な記事内容のガイドライン</h3>
 
 <p>どんな文書を書くときも、どれくらいの量を言えばいいのかを知ることが重要です。あまりにも長い文章になってしまったり、過剰な詳細を提供してしまったりすると、読むのが面倒になってしまい、誰も使ってくれなくなってしまいます。網羅する量を正しく把握することは、いくつかの理由から重要です。特に、読者が本当に必要な情報を見つけられるようにすること、そして検索エンジンが記事を適切に分析してランク付けできるように十分な質の高い素材を提供することです。</p>
 
@@ -84,17 +75,17 @@ translation_of: MDN/Guidelines/Writing_style_guide
 
 <p>ここでの目標は、読者が必要としている情報を全て含めたページを、あまり長くせずに書くことです。この分野では、いくつかの推奨事項があります。</p>
 
-<h4 id="Consider_your_audience" name="Consider_your_audience">読み手を意識する</h4>
+<h4 id="Consider_your_audience">読み手を意識する</h4>
 
 <p>これらはガイドラインであることを覚えておいてください。これらのヒントの中には、すべての場合で適用されない場合があります。記事の読者層を意識してください。高度なネットワーク技術に関する記事では、基本的なネットワーキングの概念について、例えばネットワークを使用したコーディングに関する典型的な記事のように詳細に説明する必要はありません。</p>
 
-<h4 id="有益な概要を提供する">有益な概要を提供する</h4>
+<h4 id="Provide_a_useful_summary">有益な概要を提供する</h4>
 
 <p>記事の概要、すなわち、最初の見出しの前の段落は、自分が読みたいと思っていることを記事がカバーしているかどうか、読者が理解するのに十分な情報を提供していることを確認してください。</p>
 
 <p>ガイドやチュートリアルのコンテンツでは、概要は、どのような主題が取り上げられるのか、必要であれば、読者が事前に何を知っておくべきかを読者に知らせなければなりません。文書化または議論されている技術や API について言及し、それらへのリンクを記載し、どのような状況で記事の内容が役に立つかのヒントを提供しなければなりません。</p>
 
-<h5 id="Example_Too_short!" name="Example_Too_short!">あまりにも短い例</h5>
+<h5 id="Example_Too_short!">あまりにも短い例</h5>
 
 <p>この要約の例は、あまりにも短すぎます。 "stroke" Textについてや、テキストが描画される場所や、正確に何を意味するのかなど、あまりにも多くの情報を除外しています。</p>
 
@@ -102,7 +93,7 @@ translation_of: MDN/Guidelines/Writing_style_guide
 <p><strong><code>CanvasRenderingContext2D.strokeText()は、文字列を描画します。</code></strong></p>
 </div>
 
-<h5 id="Example_Too_long!" name="Example_Too_long!">長すぎる例</h5>
+<h5 id="Example_Too_long!">長すぎる例</h5>
 
 <p>ここで、概要を更新しましたが、今度は長すぎます。あまりにも詳細な内容が含まれていて、他のメソッドやプロパティにテキストが入り込みすぎています。</p>
 
@@ -122,48 +113,48 @@ translation_of: MDN/Guidelines/Writing_style_guide
 <p><strong><code>fillText()</code></strong> メソッドを呼び出すことで、文字列の輪郭のみを描画するのではなく、文字列の文字を色で塗りつぶすことができます。</p>
 </div>
 
-<h5 id="Example_Much_better!" name="Example_Much_better!">はるかに良い例</h5>
+<h5 id="Example_Much_better!">はるかに良い例</h5>
 
 <p>ここで、 <code>strokeText()</code> メソッドのより良い概要を見てみましょう。</p>
 
 <div class="example-good">
 <p>{{domxref("CanvasRenderingContext2D")}} の <code><strong>strokeText()</strong></code> メソッドは、 <a href="/en-US/docs/Web/API/Canvas_API">Canvas 2D API</a> の一部で、指定された文字列の文字の輪郭を、指定された X 座標と Y 座標で示された位置に描画します。テキストは、コンテキストの現在の {{domxref("CanvasRenderingContext2D.font", "font")}} を使用して描画され、 {{domxref("CanvasRenderingContext2D.textAlign", "textAlign")}}, {{domxref("CanvasRenderingContext2D.textBaseline", "textBaseline")}}, {{domxref("CanvasRenderingContext2D.direction", "direction")}} の各プロパティに従って揃えられます。</p>
 
-<p>詳細とさらなる例については、学習エリアの<a href="/ja/docs/Learn/JavaScript/Client-side_web_APIs/Drawing_graphics">図形の描画</a>の<a href="/ja/docs/Learn/JavaScript/Client-side_web_APIs/Drawing_graphics#Text">テキスト</a>や、このテーマに関するメインの記事「<a href="/ja/docs/Web/API/Canvas_API/Tutorial/Drawing_text">テキストの描画</a>」を参照してください。</p>
+<p>詳細とさらなる例については、学習エリアの<a href="/ja/docs/Learn/JavaScript/Client-side_web_APIs/Drawing_graphics">図形の描画</a>の<a href="/ja/docs/Learn/JavaScript/Client-side_web_APIs/Drawing_graphics#text">テキスト</a>や、このテーマに関するメインの記事「<a href="/ja/docs/Web/API/Canvas_API/Tutorial/Drawing_text">テキストの描画</a>」を参照してください。</p>
 </div>
 
-<h4 id="Include_all_relevant_examples" name="Include_all_relevant_examples">関連するすべての例を含める</h4>
-
-<p>例があるページは、ないページよりも多くなるべきです。実際、多くのページには複数の例があるはずです。</p>
+<h4 id="Include_all_relevant_examples">関連するすべての例を含める</h4>
 
 <p>重要なことは、例を使用して、すべての引数が何のために使用されるのかを明確にし、存在する可能性のある希少な例を明確にすることです。また、一般的なタスクの解決策を示すために例を使用し、発生する可能性のある問題の解決策を示すために例を使用する必要があります。</p>
 
+<p>In general it is expected that most of the pages will include examples, and that most of them will include more than one example.</p>
+
 <p>それぞれの例は、例を読んだり試してみたりする前に、その例が何をするのか、読み始める前に読者が知っておくべきことは何かを説明する文章が必要です。</p>
 
-<h5 id="Code_Examples" name="Code_Examples">コードの例</h5>
+<h5 id="Code_Examples">コードの例</h5>
 
 <p>コードの各部分では、それがどのように動作するかを説明する必要があります。大きなコードを小さな部分に分割して、個別に説明できるようにしたほうが理解しやすいかもしれないということに留意してください。</p>
 
 <p>コードの各部分に続く文章は、適切なレベルの詳細を使用して、関連性のあるものを説明する必要があります。</p>
 
 <ul>
- <li>If the code is very simple and doesn't really feature anything directly related to the API being documented, you may only give a quick summary of what it is and why it's there.</li>
+ <li>If the code is very simple and doesn't really use directly anything related to the API being documented, you may only give a quick summary of what it is and why it's there.</li>
  <li>If the code is intricate, uses the API being documented, or is technically creative, you should provide a more detailed explanation.</li>
 </ul>
 
-<p>When using the live sample system, it's helpful to be aware that all of the {{HTMLElement("pre")}} blocks in the area that contains the sample are concatenated together before running the example, which lets you break any or all of the HTML, CSS, and JavaScript into multiple segments, each optionally with its own descriptions, headings, and so forth. This makes documenting code incredibly powerful and flexible.</p>
+<p>When adding <a href="/en-US/docs/MDN/Structures/Live_samples">live samples</a>, it's helpful to be aware that all of the {{HTMLElement("pre")}} blocks in the area that contains the sample are concatenated together before running the example, which lets you break any or all of the HTML, CSS, and JavaScript into multiple segments, each optionally with its own descriptions, headings, and so forth. This makes documenting code incredibly powerful and flexible.</p>
 
 <h4 id="Overly-short_articles_are_hard_to_find">Overly-short articles are hard to find</h4>
 
-<p>If an article is "thin"—that is, too short—it may not be indexed properly (or at all) by search engines. As a rule of thumb, the article's body text should be at least 250–300 words. Don't artificially inflate a page, but treat this guideline as a minimum target length when possible.</p>
+<p>If an article is "thin"—that is, too short—it may not be indexed properly (or at all) by search engines. As a rule of thumb, the article's body text should be at least 250–300 words. Don't artificially inflate a page, but treat this guideline as a minimum target length when possible.</p>
 
-<h3 id="Sections.2C_Paragraphs.2C_Newlines" name="Sections.2C_Paragraphs.2C_Newlines">セクション、段落、改行</h3>
+<h3 id="Headings">見出し</h3>
 
 <p>降順に見出しレベルを使い分けてください。 {{HTMLElement("h2")}}, {{HTMLElement("h3")}}, {{HTMLElement("h4")}} という順に、途中を飛ばさず使って下さい。</p>
 
 <p>H2 が最高の見出しレベルなのは H1 がページタイトルのために用意されているからです。H3 、H4 より深いレベルの見出しが必要になったときは、小さい記事に分割し、ランディングページにまとめて{{TemplateLink("Next")}}, {{TemplateLink("Previous")}}, {{TemplateLink("PreviousNext")}} マクロでリンクすることを考慮してみてください。</p>
 
-<h4 id="Heading_dos_and_donts" name="Heading_dos_and_donts">見出しで行うことと行ってはいけないこと</h4>
+<h4 id="Heading_dos_and_donts">見出しで行うことと行ってはいけないこと</h4>
 
 <ul>
  <li>単独のサブセクションを作らないでください。トピックを一つに分割するというのは意味のわからないことです。2つ以上のサブ見出しを用意するか、まったくないかのどちらかです。</li>
@@ -172,15 +163,13 @@ translation_of: MDN/Guidelines/Writing_style_guide
  <li>見出しの後に内容のテキストをはさまずに小見出しが続く、 "bumping heads" を作らないようにしましょう。これは見栄えが悪く、読者には外側のセクションの最初に何の説明もないままになってしまいます。</li>
 </ul>
 
-<p>キーボードで <kbd>Enter</kbd> (または <kbd>Return</kbd>) キーを押すと、新たな段落が始まります。新しい段落ではなく改行を挿入するには (つまり、 {{HTMLElement("br")}} を {{HTMLElement("p")}} の代わりに生成する場合は)、 <kbd>Shift</kbd> キーを押しながら <kbd>Enter</kbd> キーを押してください。</p>
-
 <h3 id="Lists">Lists</h3>
 
-<p>Lists should be formatted and structured uniformly across all contributions. Individual list items should be written with suitable punctuation, regardless of the list format. However, depending on the type of list you are creating, you will want to adjust your writing as described in the sections below.</p>
+<p>Lists should be formatted and structured uniformly across all pages. Individual list items should be written with suitable punctuation, regardless of the list format. However, depending on the type of the list you are creating, you will want to adjust your writing as described in the sections below.</p>
 
 <h4 id="Bulleted_lists">Bulleted lists</h4>
 
-<p>Bulleted lists should be used to group related pieces of concise information. Each item in the list should follow a similar sentence structure. Phrases and sentences in bulleted lists should include standard punctuation. Periods must appear at the end of each sentence in a bulleted list, including the item's final sentence, just as would be expected in a paragraph.</p>
+<p>Bulleted lists should be used to group related pieces of concise information. Each item in the list should follow a similar sentence structure. Phrases and sentences in bulleted lists should include standard punctuation. A period must appear at the end of each sentence in a bulleted list, including the item's final sentence, just as would be expected in a paragraph.</p>
 
 <p>An example of a correctly structured bulleted list:</p>
 
@@ -208,15 +197,15 @@ translation_of: MDN/Guidelines/Writing_style_guide
 <ol>
  <li>Open with a heading or brief paragraph to introduce the instructions. It's important to provide the user with context before beginning the instructions.</li>
  <li>Start creating your instructions, and keep each step in its own numbered item. Your instructions may be quite extensive, so it is important to write clearly and use correct punctuation.</li>
- <li>After you have finished your instructions, close off the numbered list with a brief summary or explanation of the expected outcome upon completion.</li>
+ <li>After you have finished your instructions, follow the numbered list with a brief closing summary or explanation about the expected outcome upon completion.</li>
 </ol>
 
 <p>This is an example of writing a closing explanation. We have created a short numbered list that provides instructive steps to produce a numbered list with the correct formatting.</p>
 </div>
 
-<p>Note how the items in numbered lists read like short paragraphs. Because numbered lists are routinely used for instructional purposes, or to walk someone through an orderly procedure, be sure to keep each item focused: one item per number or step.</p>
+<p>Note how the items in numbered lists read like short paragraphs. Because numbered lists are routinely used for instructional purposes, or to walk someone through an orderly procedure, be sure to keep each item focused: one numbered item per step.</p>
 
-<h3 id="Text_Formatting" name="Text_Formatting">テキストの書式とスタイル</h3>
+<h3 id="Text_formatting">テキストの書式とスタイル</h3>
 
 <p>「スタイル」ドロップダウンリストを使うと、あらかじめ設定されたスタイルを選択範囲に適用できます。</p>
 
@@ -226,26 +215,26 @@ translation_of: MDN/Guidelines/Writing_style_guide
 
 <p>特別に指示された場合でない限り、 HTML の <code>style</code> 属性を手作業で付加<em>しない</em>ようにしてください。既存のクラスでうまくいかなければ、 <a href="https://discourse.mozilla.org/c/mdn">MDN discussion forum</a> で質問してみてください。</p>
 
-<h3 id="Code_sample_style_and_formatting" name="Code_sample_style_and_formatting">コードサンプルのスタイルと書式</h3>
+<h3 id="Code_sample_style_and_formatting">コードサンプルのスタイルと書式</h3>
 
-<div class="note">
+<div class="note notecard">
 <p><strong>メモ</strong>: この節では、 MDN の記事に表示されるコードのスタイルや書式について扱います。実際にコード例を書くためのガイドラインが必要な場合は、 <a href="/ja/docs/MDN/Contribute/Guidelines/Code_samples">コード例のガイドライン</a> を参照してください。</p>
 </div>
 
-<h4 id="Tabs_and_line_breaks" name="Tabs_and_line_breaks">タブと改行</h4>
+<h4 id="Tabs_and_line_breaks">タブと改行</h4>
 
 <p>タブは空白2つで統一して下さい。コードは綺麗にインデントしてください。始めの中括弧（"<code>{</code>"）は行頭に置きません。ブロック宣言の直後に配置します。</p>
 
-<pre class="brush: js notranslate">if (condition) {
+<pre class="brush: js">if (condition) {
   /* handle the condition */
 } else {
   /* handle the "else" case */
 }
 </pre>
 
-<p>Long lines shouldn't be allowed to stretch off horizontally to the extent that they require horizontal scrolling to read. Instead, break at natural breaking points. Some examples follow:</p>
+<p>Long lines shouldn't be allowed to stretch off horizontally to the extent that they require horizontal scrolling to read. Instead, break long lines at natural breaking points. Some examples follow:</p>
 
-<pre class="brush: js notranslate">if (class.CONDITION || class.OTHER_CONDITION || class.SOME_OTHER_CONDITION
+<pre class="brush: js">if (class.CONDITION || class.OTHER_CONDITION || class.SOME_OTHER_CONDITION
        || class.YET_ANOTHER_CONDITION ) {
   /* something */
 }
@@ -254,54 +243,17 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
                            .createInstance(Components.interfaces.nsIToolkitProfileService);
 </pre>
 
-<h4 id="Inline_code_formatting" name="Inline_code_formatting">インラインコードの書式</h4>
+<h4 id="Inline_code_formatting">インラインコードの書式</h4>
 
 <p>「コード」ボタン ("&lt;&gt;" という山括弧記号が付いています) を使ってください。インライン コード スタイルの書式を関数名、変数名、メソッド名に適用することができます (これは、 {{HTMLElement("code")}} 要素を使います)。例えば、 "<code class="js plain">frenchText()</code> 関数" のようにします。。</p>
 
-<p>メソッド名の後には括弧をつけるべきです: <code>doSomethingUseful()</code> のように。括弧があることでメソッドとその他のコードの用語を区別できます。</p>
-
-<h4 id="Syntax_highlighting" name="Syntax_highlighting">構文の強調表示</h4>
+<p>メソッド名の後には <code>doSomethingUseful()</code> のように括弧をつけるべきです。括弧があることでメソッドとその他のコードの用語を区別できます。</p>
 
-<p><img alt="Screenshot of the 'Syntax Highlighter' menu." src="https://mdn.mozillademos.org/files/12682/Language%20list.png" style="border-style: solid; border-width: 1px; float: right; margin: 2px 4px;">コード行全体（もしくは数行のコード）は構文の強調表示によってフォーマットされるのが好ましく、{{HTMLElement("code")}}要素は使われるべきではありません。ツールバーの"pre"ボタンをクリックしてください。書式設定されたコンテンツボックスが挿入されます。そこにコードを入力しましょう。それからテキスト入力カーソルをコンテンツボックス内に置いたまま、右図のように"pre"ボタンの右にあるリストボタンから適切な言語を選択しましょう。以下の例は JavaScript の書式です。</p>
+<h4 id="Syntax_highlighting">構文の強調表示</h4>
 
-<div class="note">
-<p><strong>メモ:</strong> {{HTMLElement("code")}} 要素を {{HTMLElement("pre")}} ブロック内で使用<em>しない</em>でください。</p>
-
-<p>この構造はいくつかのサイトで使用されていますが、 MDN では使用していません。これらの要素を入れ子にすると、私たちのスタイル付けの一部が壊れます。</p>
-</div>
-
-<p>The following example shows text with JavaScript formatting:</p>
-
-<div class="line number2 index1 alt1">
-<pre class="brush: js notranslate">for (let i = 0, j = 9; i &lt;= 9; i++, j--)
-  document.writeln("a[" + i + "][" + j + "]= " + a[i][j]);</pre>
-</div>
-
-<p>探している言語が見当たらなければ、言語を指定せずに<code> pre</code> タグを利用して下さい (リストの"No Highlight"を選びます)。</p>
-
-<pre class="brush: plain notranslate">x = 42;</pre>
-
-<h4 id="Syntax_definitions" name="Syntax_definitions">構文の定義</h4>
-
-<p>構文の定義を挿入する場合には、エディターのツールバーの「スタイル」ドロップダウンメニューから、 <em>"Syntax Box"</em> を選択してください。これは、他のコードブロックとは別に、構文定義専用の特別に書式化されたボックスを作成します。</p>
-
-<h4 id="コードを参照しないブロック">コードを参照しないブロック</h4>
-
-<p>There are a few use cases where a <code>&lt;pre&gt;</code> block does not refer to code and doesn't have syntax highlighting nor line numbers. In such cases you should add a <code>&lt;pre&gt;</code> without a <code>class</code> attribute. Those cases include things like tree structures:</p>
-
-<pre class="notranslate">root/
-
-  folder1/
-    file1
-
-  folder2/
-    file2
-    file3
-</pre>
+<p>1 行または複数行のコードは、 {{HTMLElement("code")}} 要素ではなく、<a href="/ja/docs/MDN/Guidelines/CSS_style_guide#code_syntax_highlighting">構文強調</a>を使用して整形されます。</p>
 
-<p>To create preformatted content without syntax highlighting and line numbers click the "pre" button in the toolbar. Then start to type the text.</p>
-
-<h4 id="Styling_mentions_of_HTML_elements" name="Styling_mentions_of_HTML_elements">HTML 要素に言及する際のスタイル</h4>
+<h4 id="Styling_mentions_of_HTML_elements">HTML 要素に言及する際のスタイル</h4>
 
 <p>HTML 要素について記述する際に従うべき特定の規則があります。これらの規則によって、要素とその構成部分についての説明に一貫性が生まれます。また、詳細な説明への適切なリンクを保証することもできます。</p>
 
@@ -317,9 +269,9 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <dd>例: 「<code>&lt;input&gt;</code> 要素の <code>type</code> 属性が <code>email</code> または <code>tel</code> に設定されている場合...」</dd>
 </dl>
 
-<h3 id="Latin_abbreviations" name="Latin_abbreviations">ラテン文字の略記</h3>
+<h3 id="Latin_abbreviations">ラテン文字の略記</h3>
 
-<h4 id="In_notes_and_parentheses" name="In_notes_and_parentheses">注釈と括弧内で</h4>
+<h4 id="In_notes_and_parentheses">注釈と括弧内で</h4>
 
 <ul>
  <li>よく使われるラテン語の略記（etc.、i.e.、e.g.）は括弧や注釈の中で使用できます。略記にはピリオドを使用してください。
@@ -332,7 +284,7 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  </li>
 </ul>
 
-<h4 id="In_running_text" name="In_running_text">通常の文で</h4>
+<h4 id="In_running_text">通常の文で</h4>
 
 <ul>
  <li>通常の文では（つまり注釈や括弧の外で）、英語における同等の表現を使用してください。
@@ -345,7 +297,7 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  </li>
 </ul>
 
-<h4 id="Meanings_and_English_equivalents_of_Latin_abbreviations" name="Meanings_and_English_equivalents_of_Latin_abbreviations">ラテン語の略記表現と対応する英語表現</h4>
+<h4 id="Meanings_and_English_equivalents_of_Latin_abbreviations">ラテン語の略記表現と対応する英語表現</h4>
 
 <table class="fullwidth-table">
  <thead>
@@ -400,9 +352,9 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
 <p>使用する<em>あなた</em>が正しく使用することを肝に銘じてください。例えば、 "e.g." と "i.e." の取り違えはよくある間違いです。</p>
 </div>
 
-<h3 id="Acronyms_and_abbreviations" name="Acronyms_and_abbreviations">頭字語と略語</h3>
+<h3 id="Acronyms_and_abbreviations">頭字語と略語</h3>
 
-<h4 id="Capitalization_and_periods" name="Capitalization_and_periods">大文字とピリオド</h4>
+<h4 id="Capitalization_and_periods">大文字とピリオド</h4>
 
 <p>頭字語と略語において、全て大文字とし、ピリオドは使用しないでください。組織の略称もこれに含まれます。"US"や"UN"などです。</p>
 
@@ -411,7 +363,7 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: X.U.L.; Xul</li>
 </ul>
 
-<h4 id="Expansion" name="Expansion">略語の展開</h4>
+<h4 id="Expansion">略語の展開</h4>
 
 <p>ある用語についてページ内で初めて言及がある場合は、ユーザにとって馴染みがないと思われる略語を展開しましょう。よく分からなければ、展開するかもしくは記事や、用語の説明をする <a href="/en-US/docs/Glossary">glossary</a> の項目へのリンクを貼りましょう。</p>
 
@@ -420,9 +372,11 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><strong>間違い</strong>: "XUL is Mozilla's XML-based language..."</li>
 </ul>
 
-<h4 id="Plurals_of_acronyms_and_abbreviations" name="Plurals_of_acronyms_and_abbreviations">頭字語と略語の複数形</h4>
+<h4 id="Plurals_of_acronyms_and_abbreviations">頭字語と略語の複数形</h4>
+
+<p>頭字語と略語の複数形については、<em>s </em>を末尾に付加するだけにしてください。</p>
 
-<p>頭字語と略語の複数形については、<em>s </em>を末尾に付加するだけにしてください。アポストロフィは使用しないでください。絶対に。お願いします。</p>
+<p>アポストロフィは使用しないでください。絶対に。お願いします。</p>
 
 <ul>
  <li><span class="correct"><strong>正しい</strong></span>: CD-ROMs</li>
@@ -439,13 +393,19 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>Incorrect</strong></span>: this versus that</li>
 </ul>
 
-<h3 id="Capitalization" name="Capitalization">大文字の使用</h3>
+<h3 id="Capitalization">大文字の使用</h3>
 
-<p>Use standard English capitalization rules in body text, and capitalize "World Wide Web." It is acceptable to use lower case for "web" (used alone or as a modifier) and "internet;" this guideline is a change from a previous version of this guide, so you may find many instances of "Web" and "Internet" on MDN. Feel free to change these as you are making other changes, but editing an article just to change capitalization is not necessary.</p>
+<p>Use standard English capitalization rules in body text, and capitalize "World Wide Web." It is acceptable to use lower case for "web" (used alone or as a modifier) and "internet".</p>
 
-<p>Keyboard keys should use sentence-style capitalization, not all-caps capitalization. For example, "Enter" not "ENTER." The only exception is that if you wish to abbreviate the name of the "Escape" key, you may use "ESC".</p>
+<div class="notecard note">
+<p><strong>Note</strong>: This guideline is a change from a previous version of this guide, so you may find many instances of "Web" and "Internet" on MDN.</p>
+
+<p>Feel free to change these as you are making other changes, but editing an article just to change capitalization is not necessary.</p>
+</div>
 
-<p>Certain words should always be capitalized (such as trademarks which include capital letters), or words derived from the name of a person (unless it's being used within code, and the rules of the language in which the code is written mandate lower-casing). Some examples:</p>
+<p>Keyboard keys should use sentence-style capitalization, not all-caps capitalization. For example, "<kbd>Enter</kbd>" not "<kbd>ENTER</kbd>". The only exception is that you can use "<kbd>ESC</kbd>" to abbreviate he "<kbd>Escape</kbd>" key.</p>
+
+<p>Certain words should always be capitalized (such as trademarks which include capital letters), or words derived from the name of a person (unless it's being used within code, and code’s syntax requires lower-casing). Some examples:</p>
 
 <ul>
  <li>Boolean (named for English mathematician and logician {{interwiki("wikipedia", "George Boole")}})</li>
@@ -453,11 +413,11 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li>Python, TypeScript, Django, and other programming languages and framework names</li>
 </ul>
 
-<h3 id="Contractions" name="Contractions">短縮形</h3>
+<h3 id="Contractions">短縮形</h3>
 
 <p>書体はカジュアルで構いません。なので気軽に短縮形を使ってください (例えば、"don't"、"can't"、"shouldn't")。無理にとは言いません。</p>
 
-<h3 id="Pluralization" name="Pluralization">複数形</h3>
+<h3 id="Pluralization">複数形</h3>
 
 <p>英語におけるやり方にしてください。ラテン語やギリシア語に影響を受けた形は使わないでください。</p>
 
@@ -466,68 +426,50 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: syllabi, octopi</li>
 </ul>
 
-<h3 id="Hyphenation" name="Hyphenation">ハイフンを用いた複合語</h3>
+<h3 id="Hyphenation">ハイフンを用いた複合語</h3>
 
 <p>接頭辞と後に続く語間で同じ母音が連続する場合にハイフンを使用してください。</p>
 
 <ul>
- <li><font color="green"><strong>正しい</strong></font>: email, re-elect, co-op</li>
- <li><font color="red"><strong>間違い</strong></font>: e-mail, reelect, coop</li>
+ <li><span class="correct"><strong>正しい</strong></span>: email, re-elect, co-op</li>
+ <li><span class="incorrect"><strong>間違い</strong></span>: e-mail, reelect, coop</li>
 </ul>
 
-<h3 id="Gender-neutral_language" name="Gender-neutral_language">性別に中立な言葉</h3>
+<h3 id="Gender-neutral_language">性別に中立な言葉</h3>
 
 <p>主題に性別が関係ない場合には、性別に中立な言葉を使って、できるだけ包括的な文章にするのが良いでしょう。例えば、特定の男性の行動について話している場合は、 "he"/"his" を使用しても問題ありませんが、主語がどちらでもありうる場合は、 "he"/"his" は適切ではありません。<br>
  <br>
  以下に例をあげましょう。</p>
 
-<blockquote>
-<p>A confirmation dialog appears, asking the user if he allows the Web page to make use of his Web cam.</p>
-</blockquote>
+<p><em>A confirmation dialog appears, asking the user if he allows the Web page to make use of his Web cam.</em></p>
 
-<blockquote>
-<p>A confirmation dialog appears, asking the user if she allows the Web page to make use of her Web cam.</p>
-</blockquote>
+<p><em>A confirmation dialog appears, asking the user if she allows the Web page to make use of her Web cam.</em></p>
 
-<p>どちらも性的に偏りがある表現です。性別に中立な代名詞に修正しましょう:</p>
+<p>どちらも性的に偏りがある表現です。性別に中立な代名詞に修正しましょう。</p>
 
-<blockquote>
-<p>A confirmation dialog appears, asking the user if they allow the Web page to make use of their Web cam.</p>
-</blockquote>
+<p><em>A confirmation dialog appears, asking the user if they allow the Web page to make use of their Web cam.</em></p>
 
-<div class="note">
+<div class="note notecard">
 <p>MDN では、このとても一般的な構文 (これは使用法の権威の間で論争の的となっている) を使用して、英語の中性的な性別の欠如を補うことを許可しています。</p>
 
 <p>三人称複数型を中性名詞として使う (つまり、"they"、"them"、"their"、"theirs" を使う) ことは許容されるやり方で、一般には "<a href="http://en.wikipedia.org/wiki/Singular_they">単数形の 'they'</a>" として知られています。</p>
 </div>
 
-<p>両方の性についての記述することもできます。</p>
-
-<blockquote>
-<p>A confirmation dialog appears, asking the user if he or she allows the web page to make use of his/her web cam.</p>
-</blockquote>
-
 <p>ユーザを複数とするとこうなります。</p>
 
-<blockquote>
-<p>A confirmation dialog appears, asking the users if they allow the web page to make use of their web cams.</p>
-</blockquote>
+<p><em>A confirmation dialog appears, asking the users if they allow the web page to make use of their web cams.</em></p>
 
 <p>もちろん一番良い解決法は、代名詞を使用しないよう書き直すことです。</p>
 
-<blockquote>
-<p>A confirmation dialog appears, requesting the user's permission for web cam access.</p>
-</blockquote>
+<p><em>A confirmation dialog appears, requesting the user's permission for web cam access.</em></p>
 
-<blockquote>
-<p>A confirmation dialog box appears, which asks the user for permission to use the web cam.</p>
-</blockquote>
+<p><em>A confirmation dialog box appears, which asks the user for permission to use the web cam.</em></p>
 
 <p>最後の手段がおそらく、より良い手段と言えるでしょう。これは文法的に正しいだけでなく、性別の規則が大きく異なる可能性のある異なる言語間で、性別の取り扱いに関連した複雑さを軽減することができます。この解決策は、読者と翻訳者の両方にとって、翻訳をより簡単にすることができます。</p>
 
-<h3 id="Numbers_and_numerals" name="Numbers_and_numerals">数字と数詞</h3>
+<h3 id="Numbers_and_numerals">数字と数詞</h3>
 
-<h4 id="Dates" name="Dates">日付</h4>
+<h4 id="Dates">日付</h4>
 
 <p>日付については（コード中の日付は関係ありません）、 "January 1, 1990" のような書式を使用してください。</p>
 
@@ -543,7 +485,7 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: 02/24/2006; 24/02/2006; 02/24/06</li>
 </ul>
 
-<h4 id="Decades" name="Decades">年代の表現</h4>
+<h4 id="Decades">年代の表現</h4>
 
 <p>年代の表現には、 "1990s" の書式を使って下さい。アポストロフィはいりません。</p>
 
@@ -552,7 +494,7 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: 1990's</li>
 </ul>
 
-<h4 id="Plurals_of_numerals" name="Plurals_of_numerals">数詞の複数形</h4>
+<h4 id="Plurals_of_numerals">数詞の複数形</h4>
 
 <p>数詞の複数形には"s"を付加してください。アポストロフィはいりません。</p>
 
@@ -561,7 +503,7 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: 486's</li>
 </ul>
 
-<h4 id="Commas" name="Commas">カンマ</h4>
+<h4 id="Commas">カンマ</h4>
 
 <p>通常の文では、5桁以上の数字にだけカンマを使用してください。</p>
 
@@ -570,9 +512,9 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: 4,000; 54000</li>
 </ul>
 
-<h3 id="Punctuation" name="Punctuation">句読点</h3>
+<h3 id="Punctuation">句読点</h3>
 
-<h4 id="Serial_comma" name="Serial_comma">Serial Comma（連続のカンマ）</h4>
+<h4 id="Serial_comma">Serial Comma（連続のカンマ）</h4>
 
 <p><strong>Serial comma（連続のカンマ）を使用してください</strong>。 Serial Comma または "Oxford" comma（オックスフォードカンマ）としても知られるこのカンマは、3つ以上の文を並列する際に接続詞の直前に置きます。</p>
 
@@ -581,11 +523,7 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: I will travel on trains, planes and automobiles.</li>
 </ul>
 
-<div class="note">
-<p><strong>注記:</strong> これは <a href="http://www.mozilla.org/en-US/styleguide/" title="http://www.mozilla.org/en-US/styleguide/">One Mozilla style guide</a> のやり方とは対対照的です。Serial Comma （連続のカンマ）は使われないと明記しています。MDN のやり方はこのルールの例外です。</p>
-</div>
-
-<h4 id="Apostrophes_and_quotation_marks" name="Apostrophes_and_quotation_marks">引用符と疑問符</h4>
+<h4 id="Apostrophes_and_quotation_marks">引用符と疑問符</h4>
 
 <p><strong>「曲がった」引用符と疑問符を使用しないで下し。</strong> MDN では、直線の引用符とアポストロフィのみを使用してください。</p>
 
@@ -601,7 +539,7 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>Incorrect</strong></span>: Please don’t use “curly quotes.”</li>
 </ul>
 
-<h3 id="Spelling" name="Spelling">綴りの統一</h3>
+<h3 id="Spelling">綴りの統一</h3>
 
 <p>綴りにゆれがある単語については、常にアメリカ英語の綴りを使用してください。</p>
 
@@ -612,9 +550,9 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: localise, behaviour</li>
 </ul>
 
-<h3 id="Terminology" name="Terminology">用語</h3>
+<h3 id="Terminology">用語</h3>
 
-<h4 id="HTML_elements" name="HTML_elements">HTML 要素</h4>
+<h4 id="HTML_elements">HTML 要素</h4>
 
 <p>HTML や XML の要素を表すには「要素」を使用し、「タグ」を使用しないでください。加えて、基本的に常に「&lt;&gt;」で囲んで記述し、 {{HTMLElement("code")}} スタイルの中に入れてください。</p>
 
@@ -625,11 +563,11 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: the span tag</li>
 </ul>
 
-<h4 id="Parameters_vs._arguments" name="Parameters_vs._arguments">parameter と argument</h4>
+<h4 id="Parameters_vs._arguments">parameter と argument</h4>
 
 <p>MDN で推奨する用語は <strong>parameter</strong> です。一貫性のためにできるだけ "argument" の用語は使用しないでください。</p>
 
-<h4 id="User_interface_actions" name="User_interface_actions">ユーザーインターフェイス操作</h4>
+<h4 id="User_interface_actions">ユーザーインターフェイス操作</h4>
 
 <p>一連の作業を記述する際には、命令調でインターフェイスでの操作を指示しましょう。ユーザインターフェイスの要素をラベルと種類ではっきりと指定しましょう。</p>
 
@@ -638,177 +576,32 @@ var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-ser
  <li><span class="incorrect"><strong>間違い</strong></span>: Click Edit.</li>
 </ul>
 
-<h3 id="Voice" name="Voice">能動態と受動態</h3>
+<<h3 id="Voice">能動態と受動態</h3>
 
 <p>能動態が一般的には好ましいですが、MDN の堅苦しくない雰囲気から考えると受動態も問題ありません。けれど、どちらか首尾一貫させる意識は必要です。</p>
 
-<h2 id="Wiki_のマークアップとその用法">Wiki のマークアップとその用法</h2>
-
-<h3 id="リンク">リンク</h3>
-
-<p>wikiが協力な学習・教育ツールとなるのに、大半はリンクのおかげです。以下にいくつかの基本情報がありますが、完全なガイドは編集ガイド内の <a href="https://developer.mozilla.org/ja/docs/MDN/Contribute/Editor/Links">MDNでリンクを作成・編集する</a> で見る事ができます。</p>
-
-<p>We encourage you to create appropriate links among articles; they help improve navigation and discoverability of content, and they provide important context to search engines like Google to help them provide better results. Every page should have a good set of links from words or phrases to other pages that expand upon the relevant ideas. This can be used both to define terms and to provide more in-depth or detailed documentation about a topic, or to connect to a related page that offers examples or information that may be of further interest.</p>
-
-<p>You can easily create links not only among pages on MDN (internal links) but also to pages outside MDN (external links).</p>
-
-<p>There are two ways to create links: you explicitly create a link using the Link button in the editor's toolbar—or by pressing <kbd>Ctrl</kbd>+<kbd>K</kbd> (<kbd>Cmd</kbd>-<kbd>K</kbd> on the Mac)—or you can use MDN's powerful macro system to generate links automatically or based on an input value.</p>
-
-<p>When deciding what text to use as a link, there are a few guidelines you can follow:</p>
-
-<ul>
- <li>Whenever a macro exists which will create the link you need, and you are able to do so, please do. <a href="/en-US/docs/MDN/Contribute/Editor/Links#Using_link_macros">Using macros to create links</a> will not only help you get it right, but will allow future improvements to MDN to automatically be applied to your link.</li>
- <li>For an API name, use the entire string of the API term as written in your content. The easiest way to do this is to <a href="/en-US/docs/MDN/Contribute/Editor/Links#Linking_to_documentation_for_APIs">use the appropriate macro</a> to construct a properly-formatted link for you.</li>
- <li>For a term for which you're linking to a page defining or discussing that term, use the name of the term and no additional text as the link's text. For example:
-  <ul>
-   <li><span class="correct"><strong>Correct</strong></span>: You can use <a href="/en-US/docs/Web/JavaScript">JavaScript</a> code to create dynamic applications on the Web.</li>
-   <li><span class="incorrect"><strong>Incorrect</strong></span>: You can use <a href="/en-US/docs/Web/JavaScript">JavaScript code</a> to create dynamic applications on the Web.</li>
-  </ul>
- </li>
- <li>Otherwise, when adding a useful link to prose, try to choose an action and object phrase, such as:
-  <ul>
-   <li><span class="correct"><strong>Correct</strong></span>: If you'd like to <a href="/en-US/docs/Mozilla/Developer_guide">contribute to the Firefox project</a>, your first step is to <a href="/en-US/docs/Mozilla/Developer_guide/Build_Instructions">download and build Firefox</a>.</li>
-   <li><span class="incorrect"><strong>Incorrect</strong></span>: <a href="/en-US/docs/Mozilla/Developer_guide">If you'd like to contribute to the Firefox project</a>, your first step is to <a href="/en-US/docs/Mozilla/Developer_guide/Build_Instructions">download and build</a> Firefox.</li>
-  </ul>
- </li>
-</ul>
+<h2 id="Other_references">その他のリファレンス</h2>
 
-<h4 id="URL_schemes" name="URL_schemes">URL スキーム</h4>
-
-<p>セキュリティの理由から、下記のスキームを使用したリンクだけを作成すべきです:</p>
-
-<ul>
- <li><code>http://</code></li>
- <li><code>https://</code></li>
- <li><code>ftp://</code></li>
- <li><code>mailto:</code></li>
-</ul>
-
-<p>これ以外は動作したりしなかったりしますが、サポートされません。おそらく編集スタッフによって削除されるでしょう。</p>
-
-<div class="note">
-<p>特に、 <code>about:</code> や <code>chrome://</code> スキームは、動作しないので使用しないでください。同様に <code>javascript:</code> スキームは現代のたいていのブラウザーからブロックされ、<code>jar:</code> も同様です。</p>
-</div>
-
-<h3 id="Page_tags" name="Page_tags">ページタグ</h3>
-
-<p>タグはページについてのメタ情報を提示するか、内容に改善すべき点があるということを示します。あるいはその両方です。 Wiki のどのページもタグづけする必要があります。</p>
-
-<p>タグ付けのやり方については<a href="/ja/docs/MDN/Contribute/Howto/Tag">適切にタグづけする方法</a>のガイドに詳しい説明があります。</p>
-
-<p>タグのインターフェイスは編集モードにおいて、ページ下部で機能しています。以下のような感じです。</p>
-
-<p><img alt="Screenshot of the UX for adding and removing tags on MDN" src="https://mdn.mozillademos.org/files/7859/tag-interface.png" style="border-style: solid; border-width: 1px; height: 167px; width: 863px;"></p>
-
-<p>タグを追加するには、タグリスト末尾の編集ボックスをクリックしてタグ名を入力します。タグには補完機能があります。Enter (かreturn) キーで新規タグを投稿できます。どの記事も必要なだけタグを追加してよいです。例えば、AJAX プログラミングにおける JavaScript の記事には "JavaScript" と "AJAX" のどちらのタグも必要でしょう。</p>
-
-<p>タグを削除するには、タグアイコンの "X" をクリックしてください。</p>
-
-<h4 id="手を加える必要がある記事にタグをつける">手を加える必要がある記事にタグをつける</h4>
-
-<p>記事の品質と内容についての情報を示すためだけでなく、ある種の作業が必要な記事にもタグをつけることがあります。</p>
-
-<h4 id="古くなったページにタグをつける">古くなったページにタグをつける</h4>
-
-<p>現状に即していない記事には以下のタグをつけてください。</p>
-
-<dl>
- <dt>Junk</dt>
- <dd>スパム記事、誤って作られたページ、見る価値の無い劣悪なページにはこのタグをつけて下さい。このタグがつけられたページは定期的に削除されます。</dd>
- <dt>Obsolete</dt>
- <dd>技術的に既に古いが、ある文脈上では使用されうることについての記事にはこのタグをつけて下さい。例えば、 HTML5 では時代遅れな HTML 要素も HTML 4.01 ではまだ有効です。そのトピックについて <span class="nowiki">{{TemplateLink("obsolete_header")}}</span> マクロを使って目印をつけることができます。</dd>
- <dt>Archive</dt>
- <dd>技術的に既に古く、もはや役に立たないものにはこのタグをつけてください。できれば、読者にもっと新しい記事を読むように促す注記をつけてください。例えば、 Mozilla CVS リポジトリをどのように使うかについての記事は Mercurial リポジトリについての新しい記事に読者を誘導するべきでしょう (対応する記事が存在しなければ、<em>NeedsUpdate </em>タグをつけてください。そして Talk ページに説明を加えて下さい)。 Archive タグのつけられた記事はそのうち、 MDN の主要部分から <a href="/ja/docs/Archive">Archive</a> セクションへと移されます。</dd>
-</dl>
-
-<h3 id="SEO_summary">SEO summary</h3>
-
-<p>SEO summary は簡潔なページの概要です。サイトを巡回するプログラムに記事の概要として渡され、ページの検索結果として表示されます。 MDN のランディングページの作成を自動化するマクロにも利用されます。 (すなわち、 SEO ためだけのものではありません。)</p>
-
-<p>デフォルトでは、ページ最初の段落が SEO summary として利用されます。しかし、<a href="/ja/docs/Project:MDN/Contributing/Editor_guide/Editing#Formatting_styles">WYSIWYGエディタ内の "SEO summary" スタイル</a>を利用してセクションをマークすることで上書きすることができます。</p>
-
-<h3 id="ランディングページ">ランディングページ</h3>
-
-<p><strong>ランディングページ</strong> はサイトにおける、ある分野の起点となるページです。例えば <a href="/ja/docs/CSS" title="CSS">CSS</a> や <a href="/ja/docs/HTML" title="HTML">HTML</a> のメインページです。下記の３エリアからなる標準的なフォーマットがあります。</p>
-
-<ol>
- <li>その技術がどういうもので、どのように使用されるかについての簡潔な（大抵はひとつのパラグラフからなる）概観。詳しくは {{anch("Writing a landing page overview")}} を参照してください。</li>
- <li>適切に見出しがつけられた、2段組のリンクリスト。{{anch("Creating a page link list")}} のガイドラインを参照してください。</li>
- <li>ページ最下部の "ブラウザの互換性" は<strong>任意</strong>です。</li>
-</ol>
-
-<h4 id="ページリンクリストの作成">ページリンクリストの作成</h4>
-
-<p>MDN ランディングページのリンクリストセクションは２段組からなります。下記の HTML コードによって生成されます。</p>
-
-<pre class="brush: html notranslate">&lt;div class="row topicpage-table"&gt;
-  &lt;div class="section"&gt;
-    ... left column contents ...
-  &lt;/div&gt;
-  &lt;div class="section"&gt;
-    ... right column contents ...
-  &lt;/div&gt;
-&lt;/div&gt;</pre>
-
-<p>左の段は記事のリストになります。<code>上部の &lt;h2&gt;</code> ヘッダはとあるトピック（例えば、"Documentation and tutorials about foo"）についての記事のリストであることを説明します。つまり、このヘッダは CSS の "Documentation" クラスを使用するべきです。その下には、記事の <code>&lt;dl&gt;</code> リストが続きます。リストには各記事へリンクした <code>&lt;dt&gt;</code> ブロックと、1行から2行程度の記事の概要に対応した<code> &lt;dd&gt;</code> ブロックがあります。</p>
-
-<p>右の段は以下のセクションをひとつ以上含む必要があります。順に、</p>
-
-<dl>
- <dt>コミュニティの協力を得る</dt>
- <dd>これは Matrix チャットルームと、トピックについて役に立つメーリングリストの情報を提供します。見出しには "Community" クラスを利用するべきです。</dd>
- <dt>ツール</dt>
- <dd>このMDNセクションに記述された技術を使う時に、ユーザの助けになるツールの一覧です。見出しには "Tools" クラスを利用するべきです。</dd>
- <dt>関係するトピック</dt>
- <dd>その他の、関係する技術についてのランディングページへのリンクリストです。見出しには "Related_Topics" クラスを利用するべきです。</dd>
-</dl>
-
-<p><strong>{{TODO("Finish this once we finalize the landing page standards")}}</strong></p>
-
-<h2 id="Using_and_inserting_images" name="Using_and_inserting_images">画像の使用と挿入</h2>
-
-<p>自分で作成した記事や修正した記事の中に画像を入れておくと、特に技術的な内容の記事の場合に便利なことがあります。画像を利用するには、次のようにします。</p>
-
-<ol>
- <li>画像をアップロードする前に、 <a href="https://imageoptim.com/mac">ImageOptim</a> (macOS)、 <a href="https://tinypng.com/">TinyPNG</a> (ウェブサービス)、 <a href="https://trimage.org/">Trimage</a> (Linux) などの画像最適化ツールを使って、できるだけ小さくしてください。</li>
- <li>適切な画像ファイルを記事に添付しましょう (編集モードで記事の最下部にてできます)。</li>
- <li>WYSIWYG エディターで画像を作成します。</li>
- <li>WYSIWIG エディターの添付ファイルのドロップダウンリストから、新規作成した、がウの添付ファイルを選択します。</li>
- <li>OK を押してください。</li>
-</ol>
-
-<div class="warning">
-<p><strong>重要:</strong> 記事に添付ファイルをアップロードする前に、変更した内容を保存することを忘れないでください。アップロード処理中はエディターが閉じられており、現在のところ、アップロード時に画像を保存するかどうかは<em>確認されません</em>。</p>
-</div>
-
-<h2 id="Other_references" name="Other_references">その他のリファレンス</h2>
-
-<h3 id="Preferred_style_guides" name="Preferred_style_guides">おすすめのスタイルガイド</h3>
+<h3 id="Preferred_style_guides">おすすめのスタイルガイド</h3>
 
 <p>ここで取り扱われていない用法とスタイルについて疑問があれば、 <a href="https://docs.microsoft.com/en-us/style-guide/welcome/">Microsoft Writing Style Guide</a> を、それでもダメなら <a href="https://www.amazon.com/Chicago-Manual-Style-16th/dp/0226104206">Chicago Manual of Style</a> を参照してください。 <a href="https://faculty.cascadia.edu/cma/HIST148/cmscrib.pdf">非公式の crib sheet for the Chicago Manual of Style</a> がオンラインで利用できます。</p>
 
-<h3 id="Preferred_dictionary" name="Preferred_dictionary">おすすめの辞書</h3>
+<h3 id="Preferred_dictionary">おすすめの辞書</h3>
 
 <p>単語の綴りでわからないことがあれば、 <a href="http://www.dictionary.com/">Dictionary.com</a> を参照してください。このサイトのスペルチェッカはアメリカ英語を基準にしています。それ以外の表記を使用しないでください (例えば <em>colour</em> でなく <em>color</em> です)。</p>
 
 <p>何度もガイドが拡張されることになるでしょう、ですからこのドキュメントで取り扱われていないことについて知りたければ、その質問を <a href="https://discourse.mozilla.org/c/mdn">MDN discussion forum</a> に投稿してください。MDNの協力者が追加すべき記事を知ることができます。</p>
 
-<h3 id="MDC-specific" name="MDC-specific">MDN 固有の内容について</h3>
-
-<ul>
- <li>MDN の<a href="/ja/docs/MDN/Contribute/Structures/Macros/Commonly-used_macros" title="Project:en/Custom_Templates">MDN Commonly-used macros</a> に説明があります。</li>
-</ul>
-
-<h3 id="Language_grammar_spelling" name="Language_grammar_spelling">言語、文法、綴り</h3>
+<h3 id="Language_grammar_spelling">言語、文法、綴り</h3>
 
 <p>記事の執筆と編集スキルを磨きたければ、以下のリソースが役立つことでしょう。(英語の情報)</p>
 
 <ul>
- <li><a href="http://www.amazon.com/Writing-Well-30th-Anniversary-Nonfiction/dp/0060891548">On Writing Well</a>, by William Zinsser (Amazon link)</li>
- <li><a href="http://www.amazon.com/Style-Basics-Clarity-Grace-4th/dp/0205830765/" title="http://www.amazon.com/Style-Lessons-Clarity-Grace-Edition/dp/0321898680">Style: The Basics of Clarity and Grace</a>, by Joseph Williams and Gregory Colomb (Amazon link)</li>
+ <li><a href="https://www.amazon.com/Writing-Well-30th-Anniversary-Nonfiction/dp/0060891548">On Writing Well</a>, by William Zinsser (Amazon link)</li>
+ <li><a href="https://www.amazon.com/Style-Basics-Clarity-Grace-4th/dp/0205830765/">Style: The Basics of Clarity and Grace</a>, by Joseph Williams and Gregory Colomb (Amazon link)</li>
  <li><a href="https://brians.wsu.edu/common-errors-in-english-usage/">Common Errors in English</a></li>
- <li><a href="http://www-personal.umich.edu/~jlawler/aue.html">English Grammar FAQ</a> (alt.usage.english)</li>
- <li><a href="http://www.angryflower.com/bobsqu.gif">Bob's quick guide to the apostrophe, you idiots</a> (funny)</li>
- <li><a href="http://www.amazon.com/Merriam-Websters-Concise-Dictionary-English-Usage/dp/B004L2KNI2" title="http://www.amazon.com/Merriam-Websters-Concise-Dictionary-English-Usage/dp/B004L2KNI2">Merriam-Webster's Concise Dictionary of English Usage</a> (Amazon link): Scholarly but user-friendly, evidence-based advice; very good for non-native speakers, especially for preposition usage.</li>
- <li><a href="http://english.stackexchange.com/">English Language and Usage StackExchange</a>: Question and answer site for English language usage.</li>
+ <li><a href="https://www-personal.umich.edu/~jlawler/aue.html">English Grammar FAQ</a> (alt.usage.english)</li>
+ <li><a href="https://www.angryflower.com/bobsqu.gif">Bob's quick guide to the apostrophe, you idiots</a> (funny)</li>
+ <li><a href="https://www.amazon.com/Merriam-Websters-Concise-Dictionary-English-Usage/dp/B004L2KNI2">Merriam-Webster's Concise Dictionary of English Usage</a> (Amazon link): Scholarly but user-friendly, evidence-based advice; very good for non-native speakers, especially for preposition usage.</li>
+ <li><a href="https://english.stackexchange.com/">English Language and Usage StackExchange</a>: Question and answer site for English language usage.</li>
 </ul>
author	Masahiro FUJIMOTO <mfujimot@gmail.com>	2021-07-30 13:36:23 +0900
committer	GitHub <noreply@github.com>	2021-07-30 13:36:23 +0900
commit	20f40b42cd50b62ee767cdeea5022d8066512ec6 (patch)
tree	db04a34cc339b7e5a7c95c6367af025a703c2129 /files
parent	1e548ca157861d80e5447962cc576f8681580f4e (diff)
download	translated-content-20f40b42cd50b62ee767cdeea5022d8066512ec6.tar.gz translated-content-20f40b42cd50b62ee767cdeea5022d8066512ec6.tar.bz2 translated-content-20f40b42cd50b62ee767cdeea5022d8066512ec6.zip