initial commit

author: Peter Bengtsson <mail@peterbe.com> 2020-12-08 14:40:17 -0500
committer: Peter Bengtsson <mail@peterbe.com> 2020-12-08 14:40:17 -0500
commit: 33058f2b292b3a581333bdfb21b8f671898c5060 (patch)
tree: 51c3e392513ec574331b2d3f85c394445ea803c6 /files/ja/mdn/structures
parent: 8b66d724f7caf0157093fb09cfec8fbd0c6ad50a (diff)
download: translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.gz
translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.bz2
translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.zip
20 files changed, 2826 insertions, 0 deletions
diff --git a/files/ja/mdn/structures/api_references/api_reference_sidebars/index.html b/files/ja/mdn/structures/api_references/api_reference_sidebars/index.html
new file mode 100644
index 0000000000..6695ab0969
--- /dev/null
+++ b/files/ja/mdn/structures/api_references/api_reference_sidebars/index.html
@@ -0,0 +1,132 @@
+---
+title: API リファレンスサイドバー
+slug: MDN/Structures/API_references/API_reference_sidebars
+tags:
+  - API
+  - Documentation
+  - Guide
+  - MDN
+  - MDN Meta
+  - Reference
+  - groupdata
+  - metadata
+  - onboarding
+  - sidebars
+translation_of: MDN/Structures/API_references/API_reference_sidebars
+---
+<div>{{MDNSidebar}}</div>
+
+<p class="summary">API リファレンスページにカスタムサイドバーを追加して、関連するインターフェイス、チュートリアル、およびその API に関連する他のリソースへのリンクを表示することができます。この記事ではその方法を説明します。</p>
+
+<h2 id="Creating_a_sidebar" name="Creating_a_sidebar">サイドバーの作成</h2>
+
+<p>API サイドバーを作成するには、次の3つの手順を実行する必要があります。</p>
+
+<ol>
+ <li>API リファレンスページを作成します</li>
+ <li>特定の API の項目を <a href="https://github.com/mdn/kumascript">KumaScript リポジトリ</a>の <code>GroupData.json</code> データファイルに追加します</li>
+ <li>{{TemplateLink("APIRef")}} マクロを使用して、表示したい各ページにサイドバーを挿入します</li>
+</ol>
+
+<p>これらのステップを順番に実行しましょう。この記事で参照する例は、<a href="/ja/docs/Web/API/Fetch_API">Fetch API</a> です。</p>
+
+<h3 id="Creating_your_API_reference_pages" name="Creating_your_API_reference_pages">API リファレンスページの作成</h3>
+
+<p>サイドバーをページに追加する前に、ページ自体を作成する必要があります (詳細については、<a href="/ja/docs/MDN/Contribute/Structures/API_references/What_does_an_API_reference_need">API リファレンスに必要なもの</a>ガイドを参照してください)。</p>
+
+<h3 id="Adding_an_entry_to_GroupData.json" name="Adding_an_entry_to_GroupData.json">GroupData.json への項目の追加</h3>
+
+<p><code><a href="https://github.com/mdn/kumascript/blob/master/macros/GroupData.json">GroupData.json</a></code> ファイルには、API 参照サイドバーに表示されるリンクに関するすべてのデータが格納されます。呼び出されると、{{TemplateLink("APIRef")}} マクロは引数として与えられた API 名を取り、<code>GroupData.json</code> でその名前を検索し、適切なサイドバーを作成してページに挿入します。</p>
+
+<p><code>GroupData.json</code> に項目を追加するには、以下を行う必要があります。</p>
+
+<ol>
+ <li><a href="https://github.com/">GitHub</a> アカウントを持っていることを確認します</li>
+ <li>KumaScript リポジトリをフォークし、新しいブランチを作成して変更を保存し、リポジトリをローカルにクローンします</li>
+ <li>作業を開始する前に新しいブランチをチェックアウトし、作業が終わったら変更を押してください</li>
+ <li>プルリクエストを作成して、MDN チームがあなたの作業をレビューし、必要に応じて変更を求めることができるようにします</li>
+</ol>
+
+<p>GitHub の使用についてサポートが必要な場合は、<a href="/ja/docs/MDN/Contribute/Structures/Compatibility_tables#The_new_way_The_browser_compat_data_repo_and_dynamic_tables">互換性一覧表</a>に詳細なガイドがあります。</p>
+
+<p><code><a href="https://github.com/mdn/kumascript/blob/master/macros/GroupData.json">GroupData.json</a></code> ファイルは、KumaScript リポジトリの macros ディレクトリ内にあります。それを見ると、巨大な JSON 構造があり、それぞれの API に独自のメンバーがあります。名前は API 名で、値は生成するサイドバーリンクを定義するいくつかのサブメンバーを含むオブジェクトです。</p>
+
+<p>たとえば、MDN の <a href="/ja/docs/Web/API/Fetch_API">Fetch API</a> ページを見てください。 <code>GroupData.json</code> の対応する項目は次のようになります。</p>
+
+<pre class="brush: json notranslate">"Fetch API": {
+    "overview":   [ "Fetch API"],
+    "interfaces": [ "Body",
+                    "Headers",
+                    "Request",
+                    "Response",
+                    "FetchController",
+                    "FetchObserver",
+                    "FetchSignal",
+                    "ObserverCallback" ],
+    "methods":    [ "WindowOrWorkerGlobalScope.fetch()" ],
+    "properties": [],
+    "events":     []
+},</pre>
+
+<p>ご覧のとおり、名前には "Fetch API" を使用し、オブジェクト値の内側には多数のサブメンバーが含まれています。</p>
+
+<h4 id="Sub-members_to_include_inside_a_GroupData_entry" name="Sub-members_to_include_inside_a_GroupData_entry">GroupData 項目内に含めるサブメンバー</h4>
+
+<p>この節では、<code>GroupData</code> 項目に含めることができるすべてのサブメンバーを一覧表示します。</p>
+
+<p>リストされたサブメンバーの中に含まれる値のほとんどは、リンクテキストと、表示されるリンクの最終的な URL を生成するためのメイン API インデックスページ — <code>https://developer.mozilla.org/<em>&lt;language-code&gt;</em>/docs/Web/API</code> — の最後に追加されたスラッグの両方に相当することに注意してください。そのため、例えば "Body" とすると、 <em>en-US</em> ロケールではこのようなリンクが生成されます。</p>
+
+<pre class="brush: html notranslate">&lt;li&gt;&lt;a href="https://developer.mozilla.org/en-US/docs/Web/API"&gt;Body&lt;/a&gt;&lt;/li&gt;</pre>
+
+<p>いくつかの例外があります。例えば "guides" サブメンバーには、関連するガイド/チュートリアルへのリンクを定義するリンク情報 (タイトルとスラッグ) が1つ以上含まれています。この場合、スラッグは MDN の docs ルート — https://developer.mozilla.org/<em>&lt;language-code&gt;</em>/docs — の最後に追加され、MDN のどこにでも記事を含めることができます。</p>
+
+<p>以下が利用可能なメンバーです。それぞれの場合、ロケールが <em>en-US</em> であると仮定した例が含まれています。これらはすべて技術的にはオプションですが、これらを省略する代わりに空の配列を含めることを強く推奨します。</p>
+
+<ol>
+ <li>
+  <p><code>"overview"</code> — 値は配列で、 API 概要ページがあればその中にスラッグを含めます。"Fetch API" の場合、 <a href="/en-US/docs/Web/API/Fetch_API">https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API</a> へのリンクが生成されます。</p>
+ </li>
+ <li>
+  <p><code>"interfaces"</code> — 値は配列で、その API の一部を構成するすべてのインターフェイスをリストアップする必要があります。 "Body" の場合は <a href="/en-US/docs/Web/API/Body">https://developer.mozilla.org/en-US/docs/Web/API/Body</a> へのリンクが生成されます。</p>
+ </li>
+ <li>
+  <p><code>"methods"</code> — 値は、 {{domxref("Navigator")}} や {{domxref("Window")}} で生成されたインスタンス化メソッドなど、仕様が他の API に関連付けられたインターフェイスに追加するメソッドを含む配列です。膨大な数のメソッドがある場合は、最も人気のあるものだけをリストアップするか、リストの先頭に置くことを検討するとよいでしょう。 "WindowOrWorkerGlobalScope.fetch()" を実行すると <a href="/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch">https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch</a> へのリンクが張られます。同じ API が所有するインターフェイスのメンバーであるメソッドを重複してリストアップしないようにしましょう。</p>
+ </li>
+ <li>
+  <p><code>"properties"</code> — 値は、 API に関連付けられたすべてのプロパティを含む配列です。これには API 仕様で定義されているインターフェイスのメンバーであるプロパティや、API が他のインターフェイス上で定義しているプロパティを含めることができます。膨大な数のプロパティがある場合は、最も人気のあるものだけをリストアップするか、リストの先頭に配置することを検討するとよいでしょう。 "Headers.append" を実行すると、 <a href="/en-US/docs/Web/API/Headers/append">https://developer.mozilla.org/en-US/docs/Web/API/Headers/append</a> へのリンクが生成されます。</p>
+ </li>
+ <li>
+  <p><code>"events"</code> — 値は、 API の仕様やその他の場所で定義されている API に関連するすべてのイベントを含む配列です。膨大な数のイベントがある場合は、最も人気のあるものだけをリストアップするか、リストの先頭に置くことを検討するとよいでしょう。 "animationstart" を実行すると、 <a href="/en-US/docs/Web/Events/animationstart">https://developer.mozilla.org/en-US/docs/Web/Events/animationstart</a> へのリンクが生成されます。</p>
+ </li>
+ <li>
+  <p><code>"guides"</code> — 値は、API の使用方法を説明するガイドへのリンクを定義する1つ以上のオブジェクトを含む配列です。各オブジェクトは、ガイド記事を指す部分的な URL を含む "url" と、リンクのリンクテストを定義する "title" の2つのサブメンバーを含みます。例として、次のようなオブジェクトがあります。</p>
+
+  <pre class="brush: json notranslate">{ "url":   "/docs/Web/API/Detecting_device_orientation",
+"title": "Detecting device orientation" }</pre>
+
+  <p>"Detecting device orientation" というタイトルのリンクを生成し、 <a href="/en-US/docs/Web/API/Detecting_device_orientation">https://developer.mozilla.org/en-US/docs/Web/API/Detecting_device_orientation</a> を指します。</p>
+ </li>
+ <li>
+  <p><code>"dictionaries"</code> — API の一部であるすべての辞書を一覧にした文字列の配列。一般的に、特別な意味がある場合や、複数のページから参照する必要がある場合を除き、複数のプロパティやメソッドで使用される辞書のみをここにリストアップすべきです。 "RTCConfiguration" の場合は <a href="https://developer.mozilla.org/en-US/docs/Web/API/RTCConfiguration">https://developer.mozilla.org/en-US/docs/Web/API/RTCConfiguration</a> へのリンクを表示します。</p>
+ </li>
+ <li>
+  <p><code>"types"</code> — API で定義されている型定義子と列挙型の配列。リストを短くするために、特別に重要なものや複数のページから参照されるものだけをリストアップすることもできます。 "RTCCodecType" は <a href="https://developer.mozilla.org/en-US/docs/Web/API/RTCCodecType">https://developer.mozilla.org/en-US/docs/Web/API/RTCCodecType</a> へのリンクを生成します。</p>
+ </li>
+ <li>
+  <p><code>"callbacks"</code> — 値は、その API で定義されているすべてのコールバック型のリストを含む配列です。コールバック型を含む API であっても、このグループを使用する必要はないと思われるかもしれません。文字列 "RTCSessionDescriptionCallback" を含むこの配列の項目は、 <a href="https://developer.mozilla.org/en-US/docs/Web/API/RTCSessionDescriptionCallback">https://developer.mozilla.org/en-US/docs/Web/API/RTCSessionDescriptionCallback</a> へのリンクが生成されます。</p>
+ </li>
+</ol>
+
+<h2 id="Tags_used_by_sidebars" name="Tags_used_by_sidebars">サイドバーで使用されるタグ</h2>
+
+<p>サブメンバーによっては、ページタグに基づいて子ページから自動的に発見されるものがあります。最上位 API 以下のページはサイドバーがレンダリングされるたびにクロールされ、メソッド ("Method" タグ)、プロパティ ("Property" タグ)、コンストラクター ("Constructor"タグ) の項目が自動的に生成されます。</p>
+
+<p>サブメンバーにも、タグに基づいた警告アイコンが自動的に表示されます。実験的な ("Experimental" タグ)、標準外 ("Non Standard" または "Non-standard" タグ)、非推奨 ("Deprecated" タグ)、廃止 ("Obsolete" タグ) サブメンバーには装飾が追加されます。</p>
+
+<p>タグベースの処理に関する詳細情報は、 <a href="https://github.com/mdn/kumascript/blob/master/macros/APIRef.ejs">APIRef ソースの中</a>にあります。</p>
+
+<h2 id="Inserting_the_sidebar" name="Inserting_the_sidebar">サイドバーの挿入</h2>
+
+<p><code>GroupData.json</code> に API の項目を追加してプルリクエストとして送信し、その変更がメインリポジトリに受け入れられたら、 {{TemplateLink("APIRef")}} マクロを使用して API リファレンスページに設置することができ、 GroupData の API に引数として使用されます。例として、 <a href="/ja/docs/Web/API/WebVR_API">WebVR API</a> のサイドバーは、各ページに次のように設置されています。</p>
+
+<pre class="notranslate">\{{APIRef("WebVR API")}}</pre>
diff --git a/files/ja/mdn/structures/api_references/index.html b/files/ja/mdn/structures/api_references/index.html
new file mode 100644
index 0000000000..c1d806b234
--- /dev/null
+++ b/files/ja/mdn/structures/api_references/index.html
@@ -0,0 +1,58 @@
+---
+title: API リファレンス
+slug: MDN/Structures/API_references
+tags:
+  - API
+  - Contribute
+  - Guide
+  - Reference
+translation_of: MDN/Structures/API_references
+---
+<div>{{MDNSidebar}}</div>
+
+<div>{{IncludeSubnav("/ja/docs/MDN")}}</div>
+
+<p class="summary">クライアント側の JavaScript API は、ウェブ上で利用可能な技術の大部分を占めています。MDN には、これらの API で使用できる機能とその使用方法を説明する広範囲な参考資料が含まれています。このガイドセットでは MDN で API リファレンス資料を作成する方法について説明します。</p>
+
+<h2 id="Prerequisite_resources" name="Prerequisite_resources">事前に準備するリソース</h2>
+
+<p>API の文書化を開始する前に、次のものが必要です。</p>
+
+<ol>
+ <li><strong>最新の仕様:</strong> W3C 勧告か初期の編集者の草稿かどうかに関わらず、その API をカバーする仕様の最新の草稿 (またはその仕様を参照) を参照する必要があります。通常それはウェブ検索で見つかります。最新のバージョンは「最新草稿」、またはそれに類するものの下にリストされている仕様のすべてのバージョンからリンクされることがよくあります。</li>
+ <li><strong>最新のウェブブラウザー:</strong> <a href="https://nightly.mozilla.org/">Firefox Nightly</a>/<a href="https://www.google.com/intl/en/chrome/browser/canary.html">Chrome Canary</a> のような実験的/アルファ版のものが、あなたが文書化している機能をサポートする可能性が高いはずです。これは初期の/実験的な API を文書化している場合に特に関係します。</li>
+ <li><strong>デモ/ブログ記事/その他の情報:</strong> できるだけ多くの情報を探しましょう。主なインターフェイス/プロパティ/メソッドが何であるか、主要な用途は何であるか、そしてそれを使って簡単な機能を書く方法を学ぶことで、API の仕組みに慣れるための時間を費やすことから始めておくと便利です。</li>
+ <li><strong>有益なエンジニアリングの連絡先:</strong> 仕様、API の標準化に携わっている人、またはブラウザでの実装について質問するためのフレンドリーなエンジニアリング担当者を見つけることは本当に便利です。見つけるのに適した場所は次のとおりです。
+  <ul>
+   <li>関連会社に勤めている場合は、社内のアドレス帳。</li>
+   <li>Mozilla の <a href="https://lists.mozilla.org/listinfo/dev-platform">dev-platform</a> や <a href="https://lists.mozilla.org/listinfo/dev-webapi">dev-webapi</a> のリスト、<a href="https://lists.w3.org/Archives/Public/public-webapps/">public-webapps</a> のような W3C のリストなど、その API の議論に関係する公開メーリングリスト。</li>
+   <li>仕様そのもの。たとえば、 <a href="https://webaudio.github.io/web-audio-api/">Web Audio API</a> の仕様書では著者とその連絡先の詳細が上部に表示されています。</li>
+  </ul>
+ </li>
+</ol>
+
+<h2 id="High_level_structure" name="High_level_structure">高水準の構造</h2>
+
+<dl>
+ <dt><a href="/ja/docs/MDN/Contribute/Structures/API_references/What_does_an_API_reference_need">What does an API reference need?</a></dt>
+ <dd>この記事では完全な API リファレンスに必要なページについて説明します。</dd>
+ <dt><a href="/ja/docs/MDN/Contribute/Structures/Page_types">Page types</a></dt>
+ <dd>MDN に繰り返し使用されるいくつかの種類のページがあります。この記事では、これらのページ種別とその目的、および新しいページを作成するときに使用する各テンプレートとテンプレートの例について説明します。</dd>
+</dl>
+
+<h2 id="Individual_page_features" name="Individual_page_features">個々のページの特徴</h2>
+
+<p>これらの記事では、API リファレンスページに必要な個々のページの特徴を作成する方法について説明します。</p>
+
+<dl>
+ <dt><a href="/ja/docs/MDN/Contribute/Structures/API_references/API_reference_sidebars">API リファレンスサイドバー</a></dt>
+ <dd>MDN API リファレンス記事にサイドバーを含めると、その API に関連する関連インタフェース、チュートリアル、その他のリソースへのリンクが表示されるようにカスタマイズできます。この記事では、この方法について説明します。</dd>
+ <dt><a href="/ja/docs/MDN/Contribute/Structures/Syntax_sections">構文の節</a></dt>
+ <dd>MDN リファレンスページの構文の節には、その機能が持つ正確な構文 (例えば、どのような引数を受け付けるか、どの引数がオプションかなど) を定義する構文ボックスが含まれています。</dd>
+ <dt><a href="/ja/docs/MDN/Contribute/Structures/Code_examples">コード例</a></dt>
+ <dd>MDN には、ウェブプラットフォーム機能の使用方法を示すために、ページ全体に挿入された多数のコード例があります。この記事ではコードの例をページに追加する際に使用できるさまざまなメカニズムと、使用する必要があるものとそのタイミングについて説明します。</dd>
+ <dt><a href="/ja/docs/MDN/Contribute/Structures/Specification_tables">仕様書一覧表</a></dt>
+ <dd>MDN のすべてのリファレンスページは、その API または技術が定義されている仕様または仕様に関する情報を提供する必要があります。この資料では、これらのテーブルの外観とその構成方法について説明します。</dd>
+ <dt><a href="/ja/docs/MDN/Contribute/Structures/Compatibility_tables">互換性一覧表</a></dt>
+ <dd>MDN には、公開されているウェブ文書の互換性一覧表の標準フォーマットがあります。つまり、すべてのブラウザーで共有されているDOM、HTML、CSS、JavaScript、SVG などの技術の文書です。この記事では、機能を使用して MDN ページに互換性データを追加する方法について説明します。</dd>
+</dl>
diff --git a/files/ja/mdn/structures/api_references/what_does_an_api_reference_need/index.html b/files/ja/mdn/structures/api_references/what_does_an_api_reference_need/index.html
new file mode 100644
index 0000000000..952c49ed70
--- /dev/null
+++ b/files/ja/mdn/structures/api_references/what_does_an_api_reference_need/index.html
@@ -0,0 +1,168 @@
+---
+title: API リファレンスには何が必要ですか？
+slug: MDN/Structures/API_references/What_does_an_API_reference_need
+tags:
+  - API
+  - ページ
+  - リファレンス
+translation_of: MDN/Structures/API_references/What_does_an_API_reference_need
+---
+<div>{{MDNSidebar}}</div>
+
+<p class="summary">この記事では、完全な API リファレンスに必要なページについて説明します。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: API リファレンスで作業しているときに書いたり更新したりする必要があるドキュメントのリストを作成し、完了したらチェックを外すことをお勧めします。</p>
+</div>
+
+<h2 id="API_ページの概要">API ページの概要</h2>
+
+<p>An API reference will generally contain the following pages. You can find more details of what each page contains, examples, and templates, in our <a href="/en-US/docs/MDN/Contribute/Structures/Page_types">Page types</a> article.</p>
+
+<ol>
+ <li>Overview page</li>
+ <li>Interface pages</li>
+ <li>Constructor pages</li>
+ <li>Method pages</li>
+ <li>Property pages (including event handlers properties)</li>
+ <li>Event pages</li>
+ <li>Concept/guide pages</li>
+ <li>Examples</li>
+</ol>
+
+<div class="note">
+<p><strong>Note</strong>: We'll be referring to the <a href="/en-US/docs/Web/API/Web_Audio_API">Web Audio API</a> for examples in this article.</p>
+</div>
+
+<div class="note">
+<p><strong>Note</strong>: To create a page as specified below, the easiest way is to go to the parent page you want it to hang off, and choose <em>Cog icon &gt; New sub-article</em>. If you haven't got this option available on your MDN interface, you'll need to request this privilege (ask at <code>mdn-admins@mozilla.org</code>), or ask another MDN contributor to create them for you.</p>
+</div>
+
+<h3 id="概要ページ">概要ページ</h3>
+
+<p>A single API overview page is used to describe the role of the API, its top-level interfaces, related features contained in other interfaces, and other high level details. Its name and slug should be the name of the API plus "API" on the end. It is placed at the top level of the API reference, as a child of <a href="/en-US/docs/Web/API">https://developer.mozilla.org/en-US/docs/Web/API</a>.</p>
+
+<p>例:</p>
+
+<ul>
+ <li>Title: <em>Web Audio API</em></li>
+ <li>Slug: <em>Web_Audio_API</em></li>
+ <li>URL: <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API</a></li>
+</ul>
+
+<h3 id="インターフェイスページ">インターフェイスページ</h3>
+
+<p>Each interface will have its own page too, describing the purpose of the interface, listing any members (constructors, methods, properties, etc. it contains), and showing what browsers it is compatible with. A page's name and slug should be the name of the interface, exactly as written in the spec. Each page is placed at the top level of the API reference, as a child of <a href="/en-US/docs/Web/API">https://developer.mozilla.org/en-US/docs/Web/API</a>.</p>
+
+<p>例:</p>
+
+<ul>
+ <li>Title: <em>AudioContext</em></li>
+ <li>Slug: <em>AudioContext</em></li>
+ <li>URL: <a href="https://developer.mozilla.org/en-US/docs/Web/API/AudioContext">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext</a></li>
+</ul>
+
+<ul>
+ <li>Title: <em>AudioNode</em></li>
+ <li>Slug: <em>AudioNode</em></li>
+ <li>URL: <a href="https://developer.mozilla.org/en-US/docs/Web/API/AudioNode">https://developer.mozilla.org/en-US/docs/Web/API/AudioNode</a></li>
+</ul>
+
+<div class="note">
+<p><strong>Note:</strong> We document every member appearing in the interface. You should bear the following rules in mind:</p>
+
+<ul>
+ <li>We document methods defined on the <u>prototype</u> of an object implementing this interface (instance methods), and methods defined on the actual class itself (static methods). On the rare occasions that they both exist on the same interface, you should list them in separate sections on the page (Static methods/Instance methods). Usually only instance methods exist, in which case you can put these under the title "Methods".</li>
+ <li>We do not document inherited properties and methods of the interface: they are listed on the respective parent interface. We do hint at their existence though.</li>
+ <li>We do document properties and methods defined in mixins, though we use the mixin name as interface name. (This is not optimal as the mixin name will not appear in the console, but it prevents the duplication of documentation. We may revisit this in the future.)</li>
+ <li>Special methods like the stringfier (<code>toString()</code>) and the jsonizier (<code>toJSON()</code>) are also listed if they do exist.</li>
+ <li>Named constructors (like <code>Image()</code>  for {{domxref("HTMLImageElement")}} ) are also listed, if relevant.</li>
+</ul>
+</div>
+
+<h3 id="コンストラクタページ">コンストラクタページ</h3>
+
+<p>Each interface has 0 or 1 constructors, documented on a subpage of the interface's page. It describes the purpose of the constructor and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the constructor, which is exactly the same as the interface name, and the title is interface name, dot, constructor name, then parentheses on the end.</p>
+
+<p>Example:</p>
+
+<ul>
+ <li>Title: <em>AudioContext.AudioContext()</em></li>
+ <li>Slug: <em>AudioContext</em></li>
+ <li>URL: <a href="https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/AudioContext">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/AudioContext</a></li>
+</ul>
+
+<h3 id="プロパティページ">プロパティページ</h3>
+
+<p>Each interface has zero or more properties, documented on subpages of the interface's page. each page describes the purpose of the property and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the property, and the title is interface name, dot, then property name.</p>
+
+<p>Examples:</p>
+
+<ul>
+ <li>Title: <em>AudioContext.state</em></li>
+ <li>Slug: <em>state</em></li>
+ <li>URL: <a href="/en-US/docs/Web/API/AudioContext/state">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/state</a></li>
+</ul>
+
+<ul>
+ <li>Title: <em>AudioContext.onstatechange</em></li>
+ <li>Slug: <em>onstatechange</em></li>
+ <li>URL: <a href="/en-US/docs/Web/API/AudioContext/onstatechange">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/onstatechange</a></li>
+</ul>
+
+<div class="note">
+<p><strong>Note:</strong> Event handler properties are treated in the same way as regular properties; they are generally listed in a separate section on the interface page though.</p>
+</div>
+
+<ul>
+</ul>
+
+<h3 id="メソッドページ">メソッドページ</h3>
+
+<p>Each interface has zero or more methods, documented on subpages of the interface's page. each page describes the purpose of the method and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the method, and the title is interface name, dot, method name, then parentheses.</p>
+
+<p>Examples:</p>
+
+<ul>
+ <li>Title: <em>AudioContext.close()</em></li>
+ <li>Slug: <em>close</em></li>
+ <li>URL: <a href="/en-US/docs/Web/API/AudioContext/close">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/close</a></li>
+</ul>
+
+<ul>
+ <li>Title: <em>AudioContext.createGain()</em></li>
+ <li>Slug: <em>createGain</em></li>
+ <li>URL: <a href="/en-US/docs/Web/API/AudioContext/createGain">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/createGain</a></li>
+</ul>
+
+<h3 id="イベントページ">イベントページ</h3>
+
+<p>Each event handler property you create will have a corresponding event page, describing the event that causes the handler to fire, documented on a subpage of <a href="/en-US/docs/Web/Events">https://developer.mozilla.org/en-US/docs/Web/Events</a>. Each page describes the purpose of the event and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug and title is the name of the event.</p>
+
+<p>Example:</p>
+
+<ul>
+ <li>Title: <em>statechange</em></li>
+ <li>Slug: <em>statechange</em></li>
+ <li>URL: <a href="/en-US/docs/Web/Events/statechange">https://developer.mozilla.org/en-US/docs/Web/Events/statechange</a></li>
+</ul>
+
+<h3 id="Conceptguide_pages">Concept/guide pages</h3>
+
+<p>Most API references have at least one guide and sometimes also a concept page to accompany it. At minimum, an API reference should contain a guide called "Using the <em>name-of-api</em>", which will provide a basic guide to how to use the API. More complex APIs may require multiple usage guides to explain how to use different aspects of the API.</p>
+
+<p>If required, you can also including a concepts article called "<em>name-of-api</em> concepts", which will provide explanation of the theory behind any concepts related to the API that developers should understand to effectively use it.</p>
+
+<p>These articles should all be created as subpages of the API overview page. For example, the Web Audio has four guides and a concept article:</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/API/Web_Audio_API/Using_Web_Audio_API">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Using_Web_Audio_API</a></li>
+ <li><a href="/en-US/docs/Web/API/Web_Audio_API/Visualizations_with_Web_Audio_API">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Visualizations_with_Web_Audio_API</a></li>
+ <li><a href="/en-US/docs/Web/API/Web_Audio_API/Web_audio_spatialization_basics">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Web_audio_spatialization_basics</a></li>
+ <li><a href="/en-US/docs/Web/API/Web_Audio_API/Porting_webkitAudioContext_code_to_standards_based_AudioContext">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Porting_webkitAudioContext_code_to_standards_based_AudioContext</a></li>
+ <li><a href="/en-US/docs/Web/API/Web_Audio_API/Basic_concepts_behind_Web_Audio_API">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Basic_concepts_behind_Web_Audio_API</a></li>
+</ul>
+
+<h3 id="例">例</h3>
+
+<p>You should create some examples that demonstrate at least the most common use cases of the API. You can put these anywhere that is appropriate, although the recommended place is the <a href="https://github.com/mdn/">MDN GitHub repo</a>.</p>
diff --git a/files/ja/mdn/structures/banners_and_notices/index.html b/files/ja/mdn/structures/banners_and_notices/index.html
new file mode 100644
index 0000000000..54cce6a78f
--- /dev/null
+++ b/files/ja/mdn/structures/banners_and_notices/index.html
@@ -0,0 +1,56 @@
+---
+title: バナーと通知
+slug: MDN/Structures/Banners_and_notices
+tags:
+  - MDN Meta
+  - ガイド
+  - 構造
+translation_of: MDN/Structures/Banners_and_notices
+---
+<div>{{MDNSidebar}}</div>
+
+<div>{{IncludeSubnav("/ja/docs/MDN")}}</div>
+
+<p><span class="seoSummary">場合によっては、記事に特別な通知が必要になることがあります。これは、プロダクションコードで使用すべきではない古い技術やその他の資料がページに含まれている場合に発生する可能性があります。この記事では最も一般的なケースについて説明します。</span></p>
+
+<h2 id="How_to_add_notice_boxes">How to add notice boxes</h2>
+
+<p>In most cases, you apply these notices by adding a macro call to inject an appropriate banner into the page content, and by adding a tag to the page's list of tags. Also, if the page includes a compatibility table (most API reference pages do, for example), you should update that table to reflect any compatibility changes.</p>
+
+<p>To do this, you open the editor, then insert the macro call at the top of the article, and change the browser <a href="/en-US/docs/Project:Compatibility_tables" title="/en-US/docs/Project:Compatibility_tables">compatibility table</a> (if any); the table should be near the end of the article. Once that's done, scroll to the bottom of the article to find the tag list, and add the new tag to the list. Once you've done that, click the Save Changes button near the top of the window to commit your updates. From then on, an appropriate banner will appear on the page, and any macros that reference page tags when looking for up-to-date articles will know that the page you've updated is obsolete.</p>
+
+<ul>
+ <li>To learn more about editing, see the <a href="/en-US/docs/Project:MDN/Contributing/Editor_guide" title="/en-US/docs/Project:MDN/Contributing/Editor_guide">MDN editor guide</a>.</li>
+ <li>For more information about tagging, see our <a href="/en-US/docs/Project:MDN/Contributing/Tagging_standards" title="/en-US/docs/Project:MDN/Contributing/Tagging_standards">Tagging standards</a> guide.</li>
+ <li>To discover more of our custom macros, see the article <a href="/en-US/docs/Project:MDN/Contributing/Custom_macros" title="/en-US/docs/Project:MDN/Contributing/Custom_macros">Custom macros for MDN</a>.</li>
+</ul>
+
+<p>Sometimes, you might want to flag just a single item in a list of items, or in a table, as obsolete, deprecated, or the like. There are special versions of each of the following macros for that; simply change "_header" to "_inline" to the end of the macro's name.</p>
+
+<h2 id="Obsolete_content">Obsolete content</h2>
+
+<p>If you come across an article whose content is obsolete -- meaning that everything on that page is out of date and shouldn't be used -- you can mark the page as such by adding the {{TemplateLink("obsolete_header")}} macro at the top of the article. Just open the page's editor and insert this at the top of the article:</p>
+
+<pre class="notranslate">\{{obsolete_header}}</pre>
+
+<p>You should also add the tag "Obsolete" to the tag list at the bottom of the page.</p>
+
+<div class="note">
+<p><strong>Note:</strong> If the article covers a Mozilla-specific technology, you can add the Gecko version in which the technology was removed from Gecko as a parameter to the {{TemplateLink("obsolete_header")}} macro, like this:</p>
+
+<pre class="notranslate">\{{obsolete_header(21)}}</pre>
+
+<p>This will make the banner specificy that the technology became obsolete in Gecko 21, with a link to the article <a href="/en-US/docs/Mozilla/Firefox/Releases/21" title="/en-US/docs/Mozilla/Firefox/Releases/21">Firefox 21 for developers</a>.</p>
+</div>
+
+<p>Eventually, once something is very, very obsolete (that is, it's so obsolete that reading the material might actually cause serious problems), we can move content into our <a href="/en-US/docs/Archive">Archive</a> section. If you see material that you think should be archived, <a href="mailto:mdn-admins@mozilla.org?subject=Archival%20of%20content&amp;body=%3C%3CPlease%20list%20the%20page%20to%20archive%20and%20why%20you%20think%20it%20should%20be%20archived%20here%3E%3E">contact an MDN administrator</a>.</p>
+
+<h2 id="Deprecated_content">Deprecated content</h2>
+
+<p>Deprecated content is content that covers a technology or idea that is in the process of becoming obsolete. It's no longer recommended, and is expected to be removed from browsers in the relatively near future. You can mark pages as deprecated using the {{TemplateLink("deprecated_header")}} macro. Just like with obsolete content, you can specify the Gecko version in which the technology was deprecated as a parameter, if the technology is Gecko-specific.</p>
+
+<p>You should also add the tag "Deprecated" to the page.</p>
+
+<h2 id="Non-standard_content">Non-standard content</h2>
+
+<p>Non-standard content is any content not yet part of a Web standard; this includes any technology that isn't even proposed as a draft specification, even if it's implemented by multiple browsers. You should use the {{TemplateLink("non-standard_header")}} macro on these pages, and tag the pages with "Non-standard".</p>
diff --git a/files/ja/mdn/structures/code_examples/index.html b/files/ja/mdn/structures/code_examples/index.html
new file mode 100644
index 0000000000..e6a25a49ec
--- /dev/null
+++ b/files/ja/mdn/structures/code_examples/index.html
@@ -0,0 +1,218 @@
+---
+title: コード例
+slug: MDN/Structures/Code_examples
+tags:
+  - Code
+  - Landing
+  - Live
+  - MDN Meta
+  - Static
+  - Structures
+  - インタラクティブ
+  - 例
+translation_of: MDN/Structures/Code_examples
+---
+<div>{{MDNSidebar}}</div>
+
+<div>{{IncludeSubnav("/ja/docs/MDN")}}</div>
+
+<p class="summary">MDN には、Web プラットフォーム機能の使用方法を示すために、多数のコード例がページ全体に挿入されています。この記事では、コード例をページに追加する際に使用できるさまざまなメカニズムと、使用する必要があるものとそのタイミングについて説明します。</p>
+
+<h2 id="どのような種類のコード例が利用できますか？">どのような種類のコード例が利用できますか？</h2>
+
+<p>There are four types of code example available on MDN:</p>
+
+<ul>
+ <li>Static examples — plain code blocks, possibly with a screenshot to statically show the result of such code if it were to be run.</li>
+ <li>Traditional MDN "live samples" — A macro that takes plain code blocks, dynamically puts them into a document inside an {{htmlelement("iframe")}} element, and embeds it into the page to show the code running live.</li>
+ <li>GitHub "live samples" — A macro that takes a document in a GitHub repo inside the <a href="https://github.com/mdn/">mdn organization</a>, puts it inside an {{htmlelement("iframe")}} element, and embeds it into the page to show the code running live.</li>
+ <li>Interactive examples — Our system for creating <a href="https://github.com/mdn/interactive-examples">live interactive examples</a> that show the code running live but also allow you to change code on the fly to see what the effect is.</li>
+</ul>
+
+<p>We'll discuss each one in later sections.</p>
+
+<h2 id="いつそれらを使うべきですか？">いつそれらを使うべきですか？</h2>
+
+<p>Each type of code example has it own use cases. When should you use each one?</p>
+
+<ul>
+ <li>Static examples are useful if you just need to show some code, and it isn't super important to show what the live result is. Some people just want something to copy and paste. Maybe you are just showing an intermediate step, or the source code is enough. (For example, the article is for an advanced audience, and they just need to see the code.) Also, you might be demonstrating an API feature that doesn't work well as an embedded example, which might need its own separate page to link to.</li>
+ <li>Traditional live samples are useful if you want to show source code on a page, then show it running, and you’re not that bothered about it being accessible as a standalone example. This approach also has the advantage that if you are showing source code and live examples side by side, you only need to update the code once to update both. They can however be awkward to edit and get working.</li>
+ <li>GitHub live samples are useful when you’ve got an existing example you want to embed, don’t want to show the source code for, and/or you want to make sure the example is available in standalone form. They have a better contribution workflow, but it does require you to know GitHub. Also because on-page code and source code are in two different places, it is easier for them to get out of sync.</li>
+ <li>The new interactive examples are great as readers can modify values on the fly — this is very valuable for learning. However, they are more complex to set up than the other forms, with more limitations, and are intended for specific purposes.</li>
+</ul>
+
+<p>If you are not sure which one to use, you should default to traditional or GitHub live samples, depending on which one you are most comfortable with. You are also welcome to ask for advice on our <a href="https://discourse.mozilla.org/c/mdn">Discourse forum</a>.</p>
+
+<h2 id="一般的なガイドライン">一般的なガイドライン</h2>
+
+<p>Aside from the specific system for presenting the live samples, as summarized above, there are style and content cconsiderations to keep in mind when adding or updating samples on MDN?</p>
+
+<ul>
+ <li>When placing samples on a page, try to ensure that all of the features or options of the API or concept you're writing about are covered. At a minimum, at least the most-common options or properties should be included in examples.</li>
+ <li>Precede each example with an explanation of what  the example does and why it's interesting or useful.</li>
+ <li>Follow each piece of code with an explanation of what it does.</li>
+ <li>When possible, break large examples into smaller pieces. For instance, the "live sample" system will automatically concatenate all your code together into one piece before running the example, so you can actually break your JavaScript, HTML, and/or CSS into smaller pieces with descriptive text after each piece if you choose to do so. This is a great way to help explain long or complicated stretches of code more clearly.</li>
+ <li>Go beyond just demonstrating how each piece of the API or technology works. Consider possible real-world use cases you might try to demonstrate.</li>
+</ul>
+
+<h2 id="静的サンプル">静的サンプル</h2>
+
+<p>By static examples, we are talking about static code blocks that show how a feature might be used in code. These are put on a page using the <strong>PRE</strong> and <strong>Syntax Highlighter</strong> buttons on the MDN editor UI. An example result might look like this:</p>
+
+<pre class="brush: js notranslate">// This is a JS example
+var test = "Hello";
+console.log(test);</pre>
+
+<div class="note">
+<p><strong>Note</strong>: For more details on adding code blocks to MDN pages, see our <a href="/en-US/docs/MDN/Contribute/Editor/Syntax_highlighting">Syntax highlighting</a> article.</p>
+</div>
+
+<p>Optionally, you might want to show a static image of the code's resulting output. For example:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/15523/console-example.png" style="border-style: solid; border-width: 1px; display: block; margin: 0px auto;"></p>
+
+<div class="note">
+<p><strong>Note</strong>: For more details on adding images to MDN pages, see our <a href="/en-US/docs/MDN/Contribute/Editor/Images">Images</a> article.</p>
+</div>
+
+<h2 id="従来のライブサンプル">従来のライブサンプル</h2>
+
+<p>Traditional live samples are inserted into the page using the <span class="templateLink"><code><a class="external external-icon" href="https://github.com/mdn/kumascript/blob/master/macros/EmbedLiveSample.ejs">EmbedLiveSample</a></code></span> macro. An \{{EmbedLiveSample}} call dynamically grabs the code blocks in the same document section as itself and puts them into a document, which it then inserts into the page inside an {{htmlelement("iframe")}}. This is most easily demonstrated with an example, so let's look at one in this section and the next.</p>
+
+<ol>
+ <li>The easiest way is to press the <strong>Insert Code Sample Template</strong> button, which asks us for a title. For the example in the "{{anch("test")}}" section below, we entered "test" for the title, and the button generated the entire section for us.</li>
+ <li>Next, we entered some very simple sample code into the HTML, CSS, and JavaScript code blocks.</li>
+ <li>Finally, we published the page; the \{{EmbedLiveSample('test')}} call you can see in the edit view was replaced with an <code>&lt;iframe&gt;</code> containing the code running live.</li>
+</ol>
+
+<p>If you look at the source inside the <code>&lt;iframe&gt;</code>, you'll see this:</p>
+
+<pre class="brush: html notranslate">&lt;!DOCTYPE html&gt;
+&lt;html&gt;
+  &lt;head&gt;
+    &lt;link href="https://developer.cdn.mozilla.net/static/build/styles/samples.37902ba3b7fe.css"
+          rel="stylesheet" type="text/css"&gt;
+
+    &lt;style type="text/css"&gt;
+      h1 {
+        color: blue;
+      }
+    &lt;/style&gt;
+  &lt;/head&gt;
+  &lt;body&gt;
+    &lt;h1&gt;Your example?&lt;/h1&gt;
+
+
+    &lt;script type="text/javascript"&gt;
+      document.querySelector('h1').onclick = function() {
+        document.querySelector('h1').textContent = 'Your example?';
+      };
+    &lt;/script&gt;
+
+  &lt;/body&gt;
+&lt;/html&gt;</pre>
+
+<h3 id="その他のマクロパラメータ">その他のマクロパラメータ</h3>
+
+<p>The call we've used in the below example only uses one parameter — \{{EmbedLiveSample('test')}}. This simply defines which section of the document the code blocks should be grabbed from — <code>test</code> is the ID defined on the heading "test" below, so the macro will will grab all the code blocks inside that heading. Put another way, it will grab all the blocks below that heading, up until another {{htmlelement("h2")}} is encountered.</p>
+
+<p>There are some other optional parameters available too. You can include a second and third parameter, which will be a set width and height for the <code>&lt;iframe&gt;</code>. For example \{{EmbedLiveSample('test', '100%', '100px')}}. You can use pixel values or percentage values. Reasonable defaults are used if you omit these.</p>
+
+<p>There are also optional fourth and fifth parameters available, a screenshot URL that points to a screenshot showing the example should look like, and a page slug that points to another page on MDN —this is only used if you want to embed an example from another page. You won't use these two very often.</p>
+
+<p>See <a href="/en-US/docs/MDN/Contribute/Structures/Live_samples#EmbedLiveSample_macro">EmbedLiveSample macro</a> for more details on all these parameters.</p>
+
+<h3 id="伝統的なライブサンプルを使用するためのヒント">伝統的なライブサンプルを使用するためのヒント</h3>
+
+<ul>
+ <li>You don't need to use the <strong>Insert Code Sample Template</strong> button — but it is easier when you are getting used to using it. It is possible to just insert a \{{EmbedLiveSample('test')}} macro call inside any section of your page that contains code blocks, and it will work — as long as you set the first parameter to the ID of the document section it is inside.</li>
+ <li>You don't need the <em>HTML</em>, <em>CSS</em>, <em>JavaScript</em>, and <em>Result</em> headings, but it is considered best practice to include them where appropriate as it makes it easier to see what is going on. If you don't include them, you should include descriptive text to tell the reader what is happening.</li>
+ <li>You don't need HTML, CSS, and JavaScript code blocks — you can embed any combination you like — HTML and CSS, HTML and JavaScript, or even HTML only.</li>
+ <li>Another approach is to wrap your code blocks inside a block-level element with an ID, and then give the macro call that ID. For example, you could put your code blocks inside <code>&lt;div id="test"&gt;&lt;/div&gt;</code>, then use \{{EmbedLiveSample('test')}}.</li>
+ <li>In fact, this is a better option when you have a complex document hierarchy, and you are having trouble getting just the right code blocks to be embedded. In a complex document, this can be troublesome.</li>
+</ul>
+
+<div class="note">
+<p><strong>Note</strong>: You can find a lot more information about traditional Live samples in our <a href="/en-US/docs/MDN/Contribute/Structures/Live_samples">Live samples</a> article.</p>
+</div>
+
+<h2 id="テスト">テスト</h2>
+
+<h3 id="HTML">HTML</h3>
+
+<pre class="brush: html notranslate">&lt;h1&gt;My example?&lt;/h1&gt;</pre>
+
+<h3 id="CSS">CSS</h3>
+
+<pre class="brush: css notranslate">h1 {
+  color: blue;
+}</pre>
+
+<h3 id="JavaScript">JavaScript</h3>
+
+<pre class="brush: js notranslate">document.querySelector('h1').onclick = function() {
+  document.querySelector('h1').textContent = 'Your example?';
+};</pre>
+
+<h3 id="結果">結果</h3>
+
+<p>{{EmbedLiveSample('test')}}</p>
+
+<h2 id="GitHub_ライブサンプル">GitHub ライブサンプル</h2>
+
+<p>GitHub live samples are inserted into the page using the <span class="templateLink"><code><a class="external external-icon" href="https://github.com/mdn/kumascript/blob/master/macros/EmbedGHLiveSample.ejs">EmbedGHLiveSample</a></code></span> macro. An \{{EmbedGHLiveSample}} call dynamically grabs the document at a specified URL (which has to be inside the <strong>mdn</strong> GitHub organization), and inserts into the page inside an {{htmlelement("iframe")}}.</p>
+
+<p>These work in a very similar way to the {{anch("Traditional live samples")}}, but they are a lot simpler:</p>
+
+<p>You don't have to worry about placement of code blocks on the page — it simply grabs an HTML document in a GitHub repo, and puts it in the <code>&lt;iframe&gt;</code>.</p>
+
+<p>The macro only has three parameters:</p>
+
+<ol>
+ <li>The URL of the document to embed — this is relative to the mdn organization, the top level directory of which is at <span class="pl-s1"><span class="pl-s"><code>https://mdn.github.io/</code>. So this parameter needs to contain the part of the URL after that, e.g. </span></span><code>my-subdirectory/example.html</code>. You can omit the filename if it is called <code>index.html</code>.</li>
+ <li>The width of the <code>&lt;iframe&gt;</code>, which can be expressed as a percentage or in pixels.</li>
+ <li>The height of the <code>&lt;iframe&gt;</code>, which can be expressed as a percentage or in pixels.</li>
+</ol>
+
+<p>Let's look at an example. Say we wanted to embed the code at <a href="https://mdn.github.io/learning-area/css/styling-boxes/backgrounds/">https://mdn.github.io/learning-area/css/styling-boxes/backgrounds/</a>. We could use the following call:</p>
+
+<p>\{{EmbedGHLiveSample("learning-area/css/styling-boxes/backgrounds/", '100%', 100)}}</p>
+
+<p>This looks like so when rendered:</p>
+
+<p>{{EmbedGHLiveSample("learning-area/css/styling-boxes/backgrounds/", '100%', 100)}}</p>
+
+<h3 id="GitHub_ライブサンプルを使用するためのヒント">GitHub ライブサンプルを使用するためのヒント</h3>
+
+<ul>
+ <li>You obviously need to get a suitable code sample onto the <a href="https://github.com/mdn/">mdn GitHub organization</a> first. This needs to be done using Git. If you are not familiar with Git, check out our <a href="/en-US/docs/Learn/Common_questions/Using_Github_pages">How do I use GitHub Pages?</a> article, and <a href="/en-US/docs/MDN/Contribute/Structures/Compatibility_tables#Preparing_to_add_the_data">Preparing to add the data</a> for more advanced uses.</li>
+ <li>Your code sample needs to be suitable to show what you are trying to demonstrate — it should contain one simple example that does one thing well, should have no offensive content in it, and should follow the MDN <a href="/en-US/docs/MDN/Contribute/Guidelines/Code_samples">Code sample guidelines</a>.</li>
+</ul>
+
+<h2 id="インタラクティブな例">インタラクティブな例</h2>
+
+<p>The newest form of live example available on MDN is interactive live examples. These provide a step up from live examples, because the reader can edit the code and the live example updates on the fly. This is great for learning and experimentation.</p>
+
+<p>The interactive examples are intended to be used at the top of MDN reference pages — we are aiming to provide these to improve their value to beginners and other readers who want to just grab and play with an example quickly before seeing all the details of whatever they are looking up. There are a few important limitations to note about the interactive examples:</p>
+
+<ul>
+ <li>They are specialised for a particular technology — the UI for JavaScript is different from the UI for CSS, and they only illustrate one technology in isolation. They are not appropriate if you want to show, for example, how to combine a particular HTML/CSS/JS structure.</li>
+ <li>The interactive live examples are currently only set up to show CSS and JavaScript. For other technologies, you'll just have to wait.</li>
+ <li>The UI is more performance-intensive than other code examples; you shouldn't put more than one on each MDN article you apply them to.</li>
+ <li>They are not intended for large code examples — the UI supports a range of fixed sizes, which only really work for short (say, 10–15 line) examples.</li>
+</ul>
+
+<p>If you want to submit an example, you can find out how at the <a href="https://github.com/mdn/interactive-examples/blob/master/CONTRIBUTING.md">interactive examples repo Contribution guide</a>.</p>
+
+<p>If you find a page that doesn't have an associated interactive example, you are welcome to contribute one! The <a href="https://discourse.mozilla.org/c/mdn">MDN Discourse forum</a> is a good place to ask for help or advice.</p>
+
+<h3 id="インタラクティブなサンプルデモ">インタラクティブなサンプルデモ</h3>
+
+<p>The <code>\{{EmbedInteractiveExample}}</code> macro is used to embed finished examples into MDN pages. For example, the macro call <code>\{{EmbedInteractiveExample("pages/js/array-push.html")}}</code> displays the following code example:</p>
+
+<div>{{EmbedInteractiveExample("pages/js/array-push.html")}}</div>
+
+<div> </div>
+
+<div>Try adjusting the code to see what happens, and playing with the controls.</div>
diff --git a/files/ja/mdn/structures/compatibility_tables/index.html b/files/ja/mdn/structures/compatibility_tables/index.html
new file mode 100644
index 0000000000..e93cfb04d2
--- /dev/null
+++ b/files/ja/mdn/structures/compatibility_tables/index.html
@@ -0,0 +1,476 @@
+---
+title: 互換性一覧表とブラウザー互換性データリポジトリ (BCD)
+slug: MDN/Structures/Compatibility_tables
+tags:
+  - MDN Meta
+  - ガイド
+  - ブラウザー互換性
+  - 互換性テーブル
+  - 互換性一覧表
+  - 構造
+translation_of: MDN/Structures/Compatibility_tables
+---
+<div>{{MDNSidebar}}</div>
+
+<p class="summary"><span class="seoSummary">MDN には、オープンなウェブ文書のための互換性一覧表の標準形式があります。これは、すべてのブラウザーにわたって共有される DOM, HTML, CSS, JavaScript, SVG などの技術の文書で使用されます。</span>この記事は、作成した互換性一覧表をデータベースにどのように追加して維持するか、また、一覧表を記事に統合する方法についての「始め方」のガイドです。</p>
+
+<p class="summary">より高度なドキュメントや、データを表現するために使用される手続きや JSON スキーマの最新の変更点については、データリポジトリの <a href="https://github.com/mdn/browser-compat-data/blob/master/docs/contributing.md">contributor guide</a> や <a href="https://github.com/mdn/browser-compat-data/blob/master/docs/data-guidelines.md">data guidelines guide</a> をご覧ください。</p>
+
+<p class="summary">質問がある場合や問題を発見した場合は、 <a href="https://discourse.mozilla-community.org/c/mdn">MDN ディスカッションフォーラム</a>で相談してください。</p>
+
+<h2 id="How_to_access_the_data_repository" name="How_to_access_the_data_repository">データリポジトリにアクセスする方法</h2>
+
+<p>データは GitHub リポジトリに保存されています - <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> を参照してください。アクセスするには GitHub アカウントを取得し、 browser-compat-data を自分のアカウントで<ruby>フォーク<rp> (</rp><rt>fork</rt><rp>) </rp></ruby>し、フォークしたものをローカルマシンに<ruby>クローン<rp> (</rp><rt>クローン</rt><rp>) </rp></ruby>する必要があります。</p>
+
+<h2 id="Preparing_to_add_the_data" name="Preparing_to_add_the_data">データを追加する準備</h2>
+
+<p>新しいデータを追加する前に、フォークがメインリポジトリの最新である (同じ内容を含む) ことを確認し、フォーク内に追加を格納するための新しい<ruby>ブランチ<rp> (</rp><rt>ブランチ</rt><rp>) </rp></ruby>を作成し、そのブランチをローカルのクローンにプルすれば、その中で作業を始めることができます。</p>
+
+<p>フォークが最新であることを、次のように簡単な方法で確認してみましょう。</p>
+
+<h3 id="Adding_the_main_browser-compat-data_repo_as_a_remote" name="Adding_the_main_browser-compat-data_repo_as_a_remote">メインの browser-compat-data リポジトリをリモートとして追加</h3>
+
+<p>端末またはコマンドラインでフォークをローカルにクローンした場所へ行き、次のようにしてリモートにメイン (upstream) リポジトリを指すよう追加します (これを行う必要があるのは一度だけです)。</p>
+
+<pre class="brush: bash notranslate">git remote add upstream https://github.com/mdn/browser-compat-data.git</pre>
+
+<p>もしこれをしたか不明確であれば、次のようにリポジトリがどのリモートを指しているかを確認することができます。</p>
+
+<pre class="brush: bash notranslate">git remote -v</pre>
+
+<h3 id="Updating_your_fork_with_the_remotes_content" name="Updating_your_fork_with_the_remotes_content">リモートのコンテンツでフォークを更新する</h3>
+
+<p>では、フォークを更新したいときは、次のようにできます。</p>
+
+<ol>
+ <li>
+  <p>master ブランチにいることを確認します。</p>
+
+  <pre class="brush: bash notranslate">git checkout master</pre>
+ </li>
+ <li>
+  <p>以下のように更新されたリポジトリのコンテンツを<ruby>フェッチ<rp> (</rp><rt>fetch</rt><rp>) </rp></ruby>します。</p>
+
+  <pre class="brush: bash notranslate">git fetch upstream</pre>
+ </li>
+ <li>
+  <p>ローカルの master の内容をメイン (upstream) リポジトリの master の内容に<ruby>リベース<rp> (</rp><rt>rebase</rt><rp>) </rp></ruby>します。</p>
+
+  <pre class="brush: bash notranslate">git rebase upstream/master</pre>
+ </li>
+ <li>
+  <p>以下のようにしてここまでの変更をあなたがフォークしたリモートへ反映します。</p>
+
+  <pre class="brush: bash notranslate">git push</pre>
+ </li>
+</ol>
+
+<h3 id="Creating_a_new_branch_to_do_your_work_in" name="Creating_a_new_branch_to_do_your_work_in">作業用の新しいブランチの作成</h3>
+
+<p>次に、自分のリモートフォーク (普通は<code>https://github.com/<em>自分のユーザー名</em>/browser-compat-data</code>) へ行き、以下の手順で新しいブランチを作成します。変更したい内容をここに追加していくことになります。</p>
+
+<ol>
+ <li>"Branch: Master" ボタンをクリックします。</li>
+ <li>新しいブランチの名前を "Find or create a branch..." と書かれたところに入力します。</li>
+ <li>"Create branch <em>ブランチ名</em> from Master" と書かれたボタンを押します。</li>
+</ol>
+
+<p>例えば、 WebVR API についてデータを追加したい場合 "webvr" という名前がブランチ名として考えられるでしょう。</p>
+
+<h3 id="Switching_to_the_new_branch" name="Switching_to_the_new_branch">新しいブランチへの切り替え</h3>
+
+<p>ここから先は作業が端末またはコマンドラインに戻ります。ローカルにクローンしたものを更新して新しく作成したブランチを使えるようにするには、下のコマンドを使います。</p>
+
+<pre class="brush: bash notranslate">git pull</pre>
+
+<p>そして以下のように新しく作成したブランチに切り替えます。</p>
+
+<pre class="brush: bash notranslate">git checkout <em>name-of-branch</em></pre>
+
+<p>これでデータを追加するための準備が完了しました！</p>
+
+<h2 id="Adding_the_data" name="Adding_the_data">データの追加</h2>
+
+<p>データを追加するには、新たに互換性データを書いたファイルを作成する必要があります。作成する必要があるファイルは、どの技術分野について作業しようとするかによって異なります。</p>
+
+<ul>
+ <li><strong><a href="/ja/docs/Web/HTML">HTML</a>:</strong> HTML の要素ごとに一つのファイルが<a href="https://github.com/mdn/browser-compat-data/tree/master/html/elements">browser-compat-data/html/elements</a>に格納されています。ファイル名は要素の名前をすべて小文字でつけるべきです。 例) <code>div.json</code></li>
+ <li><strong><a href="/ja/docs/Web/CSS">CSS</a>:</strong> CSS のプロパティないしセレクターごとに一つのファイルが <a href="https://github.com/mdn/browser-compat-data/tree/master/css">browser-compat-data/css</a> 以下の適切なディレクトリに格納されています。ファイル名はその機能の名前をすべて小文字でつけてください。 例) <code>background-color.json</code>, <code>hover.json</code></li>
+ <li><strong><a href="/ja/docs/Web/JavaScript">JS</a>:</strong> JavaScriptオブジェクトごとに一つのファイルが<a href="https://github.com/mdn/browser-compat-data/tree/master/javascript/builtins">browser-compat-data/javascript/builtins</a>に格納されています。ファイル名は大文字小文字を含めて完全にオブジェクト名と一致させてください。 例) <code>Date.json</code>, <code>InternalError.json</code></li>
+ <li><strong><a href="/ja/docs/Web/API">APIs</a>:</strong> API のインターフェイスごとに一つのファイルが<a href="https://github.com/mdn/browser-compat-data/tree/master/api">browser-compat-data/api</a>に格納されています。ファイル名は大文字小文字を含めて完全にインターフェイス名と一致させてください。 例) WebVR API には<code>VRDisplay.json</code>や<code>VRDisplayCapabilities.json</code>などがあります</li>
+</ul>
+
+<p>あなたが作成するファイルは、このリポジトリに含まれているスキーマで定義されている構造に従わなければなりません。<a href="https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md">詳細なスキーマの説明はこちら</a>で見ることができます。</p>
+
+<h3 id="Basic_compat_data_structure" name="Basic_compat_data_structure">基本的な互換性データの構造</h3>
+
+<p>では例を見ていきましょう。例として CSS プロパティの JSON ファイルに求められる基本構造を次に示します。</p>
+
+<pre class="brush: json notranslate">{
+  "css": {
+    "properties": {
+      "border-width": {
+        "__compat": {
+          ...
+        }
+      }
+    }
+  }
+}</pre>
+
+<p>まず <code>css</code> オブジェクトがあります。その中に <code>properties</code> オブジェクトがあります。 <code>properties</code> オブジェクトの中には、互換性データとして定義したい特定の機能につき一つのメンバーが必要です。それぞれのメンバーは <code>__compat</code> をメンバーに持ち、この中に実際のデータを記述します。</p>
+
+<p>上記のデータは <a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/border-width.json">border-width.json</a> にあります。 <a href="/ja/docs/Web/CSS/border-width#Browser_compatibility">MDN で表示された border-width の表</a>と見比べてみてください。</p>
+
+<p>他の種類の機能についても同様ですが、ただしオブエジェクトの名前が異なります。</p>
+
+<ul>
+ <li>CSS セレクターは CSS プロパティと基本的に同様ですが、最上位のオブジェクト構造が <code>css.properties</code> ではなく <code>css.selectors</code> になります。例として <a href="https://github.com/mdn/browser-compat-data/blob/master/css/selectors/cue.json">cue.json</a> を見てください。</li>
+ <li>HTML についても基本的に同様ですが、最上位のオブジェクト構造が <code>html.elements</code> です。例として <a href="https://github.com/mdn/browser-compat-data/blob/master/html/elements/article.json">article.json</a> を見てください。</li>
+ <li>JavaScript の組込みオブジェクトについての最上位のオブジェクト構造は <code>javascript.builtins</code> です。例として <a href="https://github.com/mdn/browser-compat-data/blob/master/javascript/builtins/Array.json">Array.json</a> を見てください。</li>
+</ul>
+
+<div>
+<p>HTML や CSS、 JavaScript のページにおいては、普通一つだけの機能について記述するでしょう。しかし API インターフェイスについては少し事情が異なります。なぜなら常に複数のサブ機能を持つからです (下の {{anch("Sub-features", "サブ機能")}} を参照してください)。</p>
+
+<h3 id="Basic_structure_inside_a_feature" name="Basic_structure_inside_a_feature">機能内の基本構造</h3>
+
+<p>機能の <code>__compat</code> メンバーの中には、以下のメンバーを記述する必要があります。</p>
+
+<ul>
+ <li><code>mdn_url</code>: MDN 上のこの機能の参照ページの URL を指定します。これは、ロケールのディレクトリを含めずに記述する必要があることに注意してください。例えば、 <code>/docs/...</code> であり、 <code>/ja/docs/...</code> ではありません。これは、ローカライゼーションのために、データがページに置かれるときにマクロで追加されます。</li>
+ <li><code>support</code>: 報告したいすべての各ブラウザーにおける、この機能のブラウザーの対応情報を表すメンバーが含まれています。</li>
+ <li><code>status</code>: この機能の標準化過程の状態を報告するメンバーが含まれています。</li>
+</ul>
+
+<p>ブラウザーメンバーの名前はスキーマで定義されています (<a href="https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#browser-identifiers">Browser identifiers</a> を参照してください)。現在定義されている識別子の完全な一覧のもの使用してください。他のブラウザーを追加したい場合は、広範な影響があり、慎重に考えずに行うべきではありませんので、まず私たちに相談してください。</p>
+
+<p>基本的なブラウザーの compat データファイルでは、ブラウザー識別子のメンバーの中に "version_added" を含めるだけでよいでしょう (後ほど {{anch("Adding_data_Advanced_cases", "データの追加: 高度な場合")}} で説明します)。記述することができる値は以下の通りです。</p>
+
+<ul>
+ <li>バージョン番号: ブラウザーがその機能に対応し始めた正確なバージョンが分かる場合は、その番号を表す文字列を使用してください。例) <code>"47"</code>.</li>
+ <li><code>true</code>: ブラウザがその機能に対応しているが、正確なバージョン番号がわからない場合は、 <code>true</code> の値を使用してください。</li>
+ <li><code>false</code>: ブラウザーがその機能に対応していない場合は、 <code>false</code> の値を使用してください。</li>
+ <li><code>null</code>: ブラウザーがその機能に対応しているかどうかわからない場合は、 <code>null</code> の値を使用してください。</li>
+</ul>
+
+<p><code>status</code> メンバーの内容には、以下の3つのサブメンバーの記述してください。</p>
+
+<ul>
+ <li><code>experimental</code>: この機能が<a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">実験的</a>であれば <code>true</code> を設定し、そうでない場合は <code>false</code> を設定してください。</li>
+ <li><code>standard_track</code>: この機能が何らかの標準化過程 (最も有名なものは W3C/WHATWG ですが、他にも Khronos, TC39, など) にある場合は <code>true</code> を設定し、そうでない場合は <code>false</code> を設定してください。</li>
+ <li><code>deprecated</code>: この機能が<a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">非推奨</a>であれば <code>true</code> に設定し、そうでない場合は <code>false</code> を設定してください。</li>
+</ul>
+
+<p><a href="/ja/docs/Web/CSS/border-width#Browser_compatibility">border-width</a> の機能データ (<a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/border-width.json">border-width.json</a> も参照) を一例として以下に示します。</p>
+
+<pre class="brush: json notranslate">"__compat": {
+  "mdn_url": "https://developer.mozilla.org/docs/Web/CSS/border-width",
+  "support": {
+    "chrome": {
+      "version_added": "1"
+    },
+    "webview_android": {
+      "version_added": "2"
+    },
+    "edge": {
+      "version_added": true
+    },
+    "edge_mobile": {
+      "version_added": true
+    },
+    "firefox": {
+      "version_added": "1"
+    },
+    "firefox_android": {
+      "version_added": "1"
+    },
+    "ie": {
+      "version_added": "4"
+    },
+    "ie_mobile": {
+      "version_added": "6"
+    },
+    "opera": {
+      "version_added": "3.5"
+    },
+    "opera_android": {
+      "version_added": "11"
+    },
+    "safari": {
+      "version_added": "1"
+    },
+    "safari_ios": {
+      "version_added": "3"
+    }
+  },
+  "status": {
+    "experimental": false,
+    "standard_track": true,
+    "deprecated": false
+  }
+}</pre>
+
+<h4 id="Adding_a_description" name="Adding_a_description">説明の追加</h4>
+
+<p><code>__compat</code> メンバーには、4つ目のオプションのメンバである、<code>description</code>があります。これを使用することで、その機能に関する人間にとって読みやすい説明を含めることができます。これを含めるべきなのは、データを少し見ただけではその機能が何であるかがわかりにくい場合だけです。例えば、データ構造を見ただけではコンストラクタが何であるかわからないかもしれないので、次のような記述を含めることができます。</p>
+
+<pre class="brush: json notranslate">{
+  "api": {
+    "AbortController": {
+      "__compat": {
+        ...
+      },
+      "AbortController": {
+        "__compat": {
+          "mdn_url": "https://developer.mozilla.org/docs/Web/API/AbortController/AbortController",
+          "description": "&lt;code&gt;AbortController()&lt;/code&gt; constructor",
+          "support": {
+            ...
+          }
+        }
+      }
+
+      ... etc.
+    }
+  }
+}</pre>
+
+<h3 id="Sub-features" name="Sub-features">サブ機能</h3>
+
+<p>互換性一覧表が複数の行を持つページでは、各行の情報を定義するために、各機能の中に複数の副機能が必要になります。これは、例えば、ある機能の基本的なサポートが一つの行に格納されていても、そのしばらく後に、その機能が新しいプロパティや値の型を持つようになった場合などに起こります。</p>
+
+<p>例として、<code>background-color</code>プロパティの<a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/background-color.json">互換性データ</a> と <a href="/ja/docs/Web/CSS/background-color">対応するMDNページ</a> を参照してください。基本的なサポートは上で説明したように <code>__compat</code> オブジェクトの中に存在しており、ブラウザの "16進数値のアルファチャンネル "のサポートするに関する追加の行は、それ自身の<code>__compat</code> オブジェクトを含んでいます。</p>
+
+<pre class="brush: json notranslate">{
+  "css": {
+    "properties": {
+      "background-color": {
+        "__compat": {
+          ...
+        },
+        "alpha_ch_for_hex": {
+          "__compat": {
+            ...
+          },
+        }
+      }
+    }
+  }
+}</pre>
+
+<p>API の場合、上位 2 つのレベルを <code>api.<em>name-of-the-interface</em></code> として定義し、次に上位の <code>__compat</code> セクションでインターフェイスの全体的なブラウザ互換性を定義し、インターフェイス内に含まれるメソッド、プロパティ、およびコンストラクタのそれぞれのサブ機能を定義します。基本的な構造は以下のようになります。</p>
+
+<pre class="brush: json notranslate">{
+  "api": {
+    "VRDisplay": {
+      "__compat": {
+        ...
+      },
+      "cancelAnimationFrame": {
+        "__compat": {
+          ...
+        }
+      },
+      "capabilities": {
+        "__compat": {
+          ...
+        }
+      },
+
+      ... etc.
+
+    }
+  }
+}</pre>
+
+<p>完全な例は、<a href="https://github.com/mdn/browser-compat-data/blob/master/api/VRDisplay.json">VRDisplay.json</a>を参照してください。</p>
+</div>
+
+<h2 id="Adding_data_Advanced_cases" name="Adding_data_Advanced_cases">データの追加: 高度な場合</h2>
+
+<p>ブラウザの互換性データには、いくつかの高度な機能があります。このセクションの目的は、最も一般的なものをリストアップし、それぞれの例を提供して、あなた自身の互換性データにそれらを実装する方法を示すことです。</p>
+
+<h3 id="Including_a_footnote" name="Including_a_footnote">脚注を含める</h3>
+
+<p>しばしば互換性一覧表には、有益な詳細や、開発者にとって有用な奇妙な動作を説明する、特定のエントリに関連した脚注が含まれています。例として、{{domxref("VRDisplay.capabilities")}} (<a href="https://github.com/mdn/browser-compat-data/blob/master/api/VRDisplay.json">VRDisplay.json</a>も参照) の Chrome Android エントリには、(執筆時点では)"現在はGoogle Daydreamのみでサポートされています "という脚注がありました。これを互換性データに含めるために、関連する "chrome_android "サブメンバーの中に "notes "サブメンバーを追加しました。これはこのようになります。</p>
+
+<pre class="brush: json notranslate">"chrome_android": {
+  "version_added": true,
+  "notes": "Currently supported only by Google Daydream."
+}</pre>
+
+<h3 id="Including_a_vendor_prefix" name="Including_a_vendor_prefix">ベンダープレフィックスを含める</h3>
+
+<p>ある機能が、あるブラウザでベンダープレフィックス付きでサポートされている場合、ブラウザの互換性データでそのことを明確にしたいと思うでしょう。Firefoxにおいて、 <code>-moz-</code> プレフィックスによりサポートされている機能を想像してください。互換性データでこれを指定するには、該当する "firefox" サブメンバーの中に "prefix" サブメンバーを追加する必要があります。これは次のようになります。</p>
+
+<pre class="brush: json notranslate">"firefox": {
+  "version_added": true,
+  "prefix": "-moz-"
+}</pre>
+
+<h3 id="Including_browser_preferences_or_flags" name="Including_browser_preferences_or_flags">ブラウザーの設定やフラグを含める</h3>
+
+<p>いくつかの機能はブラウザでサポートされているかもしれませんが、それらは実験的なものであり、デフォルトではオフになっています。ユーザがこの機能を使いたい場合は、環境設定/フラグを使ってオンにする必要があります。</p>
+
+<p>互換性データでこれを表現するには、関連するブラウザ識別子サブメンバーの中に "flags" サブメンバーを追加する必要があります。flags" の値は、3つのメンバを含むオブジェクトの配列です。</p>
+
+<ul>
+ <li><code>type</code>: フラグやプリファレンスのタイプ。最も一般的な値は "preference"で、これはブラウザ内部で設定されます(例えば、Firefoxではabout:config、Chromeではchrome://flagsを使用します)が、時には "compile_flag "という、ブラウザのビルドがコンパイルされるときに設定される値を使用することもあります。</li>
+ <li><code>name</code>: これは、値を設定する必要がある設定の名前を表す文字列です。例えば、"Enable Experimental Web Platform Features" はChromeに存在する環境設定で、Chromeでは<code>chrome://flags</code>にあります。</li>
+ <li><code>value_to_set</code>: 設定する値を表す文字列で、例えば "true "などです。</li>
+</ul>
+
+<p>つまり、ある機能のChromeのサポートに環境設定/フラグを追加するには、次のようにします。</p>
+
+<pre class="brush: json notranslate">"chrome": {
+  "version_added": "50",
+  "flags": [
+    {
+      "type": "preference",
+      "name": "Enable Experimental Web Platform Features",
+      "value_to_set": "true"
+    }
+  ]
+},</pre>
+
+<p>もしその機能が2つ以上のフラグの元にある場合、この例のように "flags"配列にオブジェクトを追加することができます。</p>
+
+<pre class="brush: json notranslate">"firefox": {
+  "version_added": "57",
+  "flags": [
+    {
+      "type": "preference",
+      "name": "dom.streams.enabled",
+      "value_to_set": "true"
+    },
+    {
+      "type": "preference",
+      "name": "javascript.options.streams",
+      "value_to_set": "true"
+    }
+  ]
+},</pre>
+
+<h3 id="Including_a_version_where_support_was_removed" name="Including_a_version_where_support_was_removed">対応が削除されたバージョンを含める</h3>
+
+<p>あるブラウザのバージョンで追加された機能が、非推奨となったために再び削除されることがあります。これは、削除されたバージョン番号を表す文字列を値として受けとる、"version_removed" サブメンバーを使えば簡単に表現できます。例えば、以下のようになります。</p>
+
+<pre class="brush: json notranslate">"firefox": {
+  "version_added": "35",
+  "version_removed": "47",
+},</pre>
+
+<h3 id="Including_multiple_support_points_for_the_same_browser_entry" name="Including_multiple_support_points_for_the_same_browser_entry">同じブラウザーの項目に複数の対応ポイントを含む</h3>
+
+<p>同じブラウザの複数のサポートデータポイントを、同じ機能の中に追加したい場合もあるでしょう。</p>
+
+<p>例えば、 {{cssxref("text-align-last")}} プロパティ（<a href="https://github.com/mdn/browser-compat-data/blob/master/css/properties/text-align-last.json">text-align-last.json</a>も参照）は、バージョン35でChromeに追加され、プレフィックス付きでサポートされました。</p>
+
+<p>上記のサポートはバージョン 47 で削除されましたが、バージョン 47 でもデフォルトで <code>text-align-last</code> が有効になるようにサポートが追加されました。</p>
+
+<p>これらのデータポイントの両方を含めるために、"chrome "サブメンバーの値を、単一のサポート情報オブジェクトではなく、2つのサポート情報オブジェクトを含む配列にすることができます。</p>
+
+<pre class="brush: json notranslate">"chrome": [
+  {
+    "version_added": "47"
+  },
+  {
+    "version_added": "35",
+    "version_removed": "47",
+    "flags": [
+      {
+        "type": "preference",
+        "name": "Enable Experimental Web Platform Features",
+        "value_to_set": "true"
+      }
+    ]
+  }
+],</pre>
+
+<div class="blockIndicator note">
+<p><strong>注:</strong> 配列の中には、最新または重要なサポートポイントを最初に配置するべきです。こうすることで、単に最新の情報を取得したい人にとって読みやすいデータとなります。</p>
+</div>
+
+<h3 id="Including_an_alternative_name" name="Including_an_alternative_name">別名を含める</h3>
+
+<p>時々、ブラウザが仕様とは異なる名前で機能をサポートすることがあります。これは例えば、あるブラウザがある機能の実験的なサポートを早くから追加していて、仕様が安定する前に名前が変わってしまったというような場合が考えられます。</p>
+
+<p>このようなケースをブラウザの互換性データに含めるには、"alternative_name"メンバの中に代替名を指定するサポート情報ポイントを含めます。</p>
+
+<div class="blockIndicator note">
+<p><strong>注:</strong> 代替名は正確なエイリアスではないかもしれません。標準バージョンとは異なる動作をするかもしれません。</p>
+</div>
+
+<p>では例を見てみましょう。{{cssxref("border-top-right-radius")}} プロパティ（<a href="https://github.com/mdn/browser-compat-data/blob/2a0cc3f6bb17aa4345441bed47a059dffd847793/css/properties/border-top-right-radius.json">border-top-right-radius.json</a>も参照）のFirefoxでのサポートは以下の通りです。</p>
+
+<ul>
+ <li>バージョン 4 以降では <code>border-top-right-radius</code> という標準的な名前でサポートされています。</li>
+ <li>バージョン 49 以降では、ブラウザの互換性を考慮し、<code>-webkit-</code>プレフィクスと共に使用されます。</li>
+ <li>バージョン 1 以降では <code>-moz-border-radius-topright</code> という代替名を使用しています。このエイリアスのサポートはバージョン12で削除されました。</li>
+</ul>
+
+<p>これをデータで表現するために、以下のJSONを使用しました。</p>
+
+<pre class="brush: json notranslate">"firefox": [
+  {
+    "version_added": "4",
+    "notes": "Prior to Firefox 50.0, border styles of rounded corners were always rendered as if &lt;code&gt;border-style&lt;/code&gt; was solid. This has been fixed in Firefox 50.0."
+  },
+  {
+    "prefix": "-webkit-",
+    "version_added": "49",
+    "notes": "From Firefox 44 to 48, the &lt;code&gt;-webkit-&lt;/code&gt; prefix was available with the &lt;code&gt;layout.css.prefixes.webkit&lt;/code&gt; preference. Starting with Firefox 49, the preference defaults to &lt;code&gt;true&lt;/code&gt;."
+  },
+  {
+    "alternative_name": "-moz-border-radius-topright",
+    "version_added": "1",
+    "version_removed": "12"
+  }
+],</pre>
+
+<h2 id="Pushing_a_change_back_to_the_main_repo" name="Pushing_a_change_back_to_the_main_repo">変更のメインリポジトリへの反映</h2>
+
+<p>互換性データの追加が終わったら、まず以下のコマンドを使ってテストしてみてください。</p>
+
+<ul>
+ <li><code>npm run lint</code> — すべての互換性データをテストして、JSONが有効であること、正しいスタイルで書かれていること、例えば正しいインデント、カンマの欠落がないことなどを確認します。ファイル名とテスト結果の長いリストが表示されます。エラーが見つかった場合、リンターは見つかったファイルに対してエラーをスローし、行番号やエラーメッセージなどのデバッグに役立つ情報を表示します。</li>
+ <li><code>npm run show-errors</code> — JSON をデータスキーマと照らし合わせて検証し、無効なブラウザのバージョン番号が使用されているなどのエラーをハイライトします。</li>
+</ul>
+
+<p>問題がなさそうであれば、コミットして、GitHub上のあなたのリモートフォークにプッシュする必要があります。これは、以下のようなターミナルコマンドで簡単に行うことができます。</p>
+
+<pre class="brush: bash notranslate">git add .
+git commit -m 'adding compat data for <em>name-of-feature</em>'
+git push</pre>
+
+<p>リモートフォーク (URLの例: <code>https://github.com/<em>your-username</em>/browser-compat-data</code>) に行くと、ファイルリストの一番上 (「最近プッシュしたブランチ」の下) にあなたのプッシュに関する情報が表示されているはずです。プルリクエスト（あなたのリモートフォークをメインリポジトリに取り込むための、最初の過程のことです）を作成するには、"Compare &amp; pull request" ボタンを押して、続く画面の簡単なプロンプトに従ってください。</p>
+
+<p>これが終われば、ただ待つのみです。レビュアーがあなたのプルリクエストをレビューし、メインリポジトリにマージします。そうでない場合は、変更を依頼します。変更が必要な場合は、変更を加えて、プルリクエストが受理されるまで再度投稿してください。</p>
+
+<h2 id="Inserting_the_data_into_MDN_pages" name="Inserting_the_data_into_MDN_pages">MDN ページへのデータの挿入</h2>
+
+<p>一度あなたの新しいデータがメインリポジトリに含められたら、{{TemplateLink("Compat")}} マクロを使って、MDNページ上でそのデータに基づいてブラウザの互換性一覧表を動的に生成することができます。これは、JSONデータを探索して、互換性一覧表を生成したい機能を表すオブジェクトを見つけるために必要なドット記法を唯一のパラメータとして受け取ります。</p>
+
+<p><br>
+ マクロ呼び出しの上に、他のコントリビューターにとって使いやすくするために、編集モードのMDNでコントリビューターにのみ表示される隠しテキストを追加します。</p>
+
+<pre class="brush: html notranslate">&lt;div class="hidden"&gt;
+The compatibility table on this page is generated from structured data.
+If you'd like to contribute to the data, please check out
+&lt;a href="https://github.com/mdn/browser-compat-data"&gt;https://github.com/mdn/browser-compat-data&lt;/a&gt;
+and send us a pull request.
+&lt;/div&gt;</pre>
+
+<p>例として、HTTPヘッダーに関するページである {{HTTPHeader("Accept-Charset")}} では、マクロの呼び出しは次のようになっています。 <code>\{{Compat("http.headers.Accept-Charset")}}</code>リポジトリ内の<a href="https://github.com/mdn/browser-compat-data/blob/master/http/headers/accept-charset.json">accept-charset.json</a>ファイルを見ると、これが JSON データにどのように反映されているかがわかると思います。</p>
+
+<p>別の例として、{{domxref("VRDisplay.capabilities")}} プロパティの互換性一覧表は、 <code>\{{Compat("api.VRDisplay.capabilities")}}</code>を使用して生成されます。マクロ呼び出しにより、以下の表（および対応する一連の注釈）が生成されます。</p>
+
+<hr>
+<div class="hidden">このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> をチェックアウトしてプルリクエストを送信してください。</div>
+
+<p>{{Compat("api.VRDisplay.capabilities")}}</p>
+
+<div class="blockIndicator note">
+<p><strong>注:</strong> ファイル名は、JSON 構造体内のインターフェイスに与えられたラベルと一致することがよくありますが、必ずしもそうとは限りません。マクロ呼び出しがテーブルを生成するときには、使用する JSON を見つけるまですべてのファイルを探索するので、ファイル名はそれほど重要ではありません。そうは言っても、常に可能な限り直感的な名前を付けるべきです。</p>
+</div>
diff --git a/files/ja/mdn/structures/index.html b/files/ja/mdn/structures/index.html
new file mode 100644
index 0000000000..a3118f3080
--- /dev/null
+++ b/files/ja/mdn/structures/index.html
@@ -0,0 +1,16 @@
+---
+title: 文書の構造
+slug: MDN/Structures
+tags:
+  - Landing
+  - MDN Meta
+  - Structures
+translation_of: MDN/Structures
+---
+<div>{{MDNSidebar}}</div><div>{{IncludeSubnav("/ja/docs/MDN")}}</div>
+
+<p>MDN 全体で見ると、MDNの記事内で統一的な情報の提示を行うために、繰り返し使われている様々な文書の構造があります。ここにあるのは、それらの構造について述べた記事です。これは文書を書いたり、編集したり、翻訳したりするのにふさわしい構造であると、MDN の執筆者であるあなたが気づき、適用し、そして変更できるものです。</p>
+
+<p>（訳注：下位の各ページを和訳すると、ここに表示されます）</p>
+
+<p>{{LandingPageListSubPages()}}</p>
diff --git a/files/ja/mdn/structures/live_samples/index.html b/files/ja/mdn/structures/live_samples/index.html
new file mode 100644
index 0000000000..b45feb16a9
--- /dev/null
+++ b/files/ja/mdn/structures/live_samples/index.html
@@ -0,0 +1,258 @@
+---
+title: ライブサンプル
+slug: MDN/Structures/Live_samples
+tags:
+  - Intermediate
+  - MDN Meta
+  - Structures
+  - ガイド
+translation_of: MDN/Structures/Live_samples
+---
+<div>{{MDNSidebar}}</div>
+
+<p><span class="seoSummary">MDN は、記事に表示されているサンプルコードを、実際に見ている実行可能なサンプルに変換することをサポートしています。これらのライブサンプルには、HTML、CSS、およびJavaScriptを任意の組み合わせで含めることができます。</span>「ライブ」サンプルはインタラクティブではありません。ただし、実際にコードサンプルによって生成されるため、サンプルの表示出力はサンプルのコードと正確に一致します。</p>
+
+<h2 id="How_does_the_live_sample_system_work" name="How_does_the_live_sample_system_work">ライブサンプルシステムの仕組み</h2>
+
+<p>ライブサンプルシステムは、グループ内のすべてのコードを集め、1 つの HTML ファイルにマージし、その HTML を {{HTMLElement("iframe")}} にレンダリングします。このためライブサンプルは2つの部分で構成されています。</p>
+
+<ul>
+ <li>コードブロックのグループ</li>
+ <li>コードブロックの結果を表示する (フレームまたはリンクを作成する) マクロ</li>
+</ul>
+
+<p>このコンテキストでは、コードブロックの「グループ」は、見出しまたはブロック要素 ( {{HTMLElement("div")}} など) の ID によって識別されます。</p>
+
+<ul>
+ <li>ID がブロック要素に属する場合、そのグループは、その ID が使用される囲むブロック要素内のすべてのコードブロックを含む。</li>
+ <li>ID が見出しに属する場合、その見出しの後ろで同じ見出しレベルの次の見出しの前にあるすべてのコードブロックがグループに含まれます。指定された見出しの小見出しのコードブロックはすべて使用されていることに注意してください。これがあなたが望む効果でない場合は、代わりにブロック要素に ID を使用してください。</li>
+</ul>
+
+<p>このマクロでは、特別な URL を使用して、<code>http://<em>url-of-page</em>$samples/<em>group-id</em></code> (<code>group-id</code> はコードが配置されている見出しまたはブロックの ID) という特定のグループのサンプルコードを取得します。</p>
+
+<p>結果として得られるフレーム (またはページ) はサンドボックスで保護されており、技術的にはウェブ上で動作するものすべてを行う可能性があります。もちろん、実際の問題として、コードはそのページの要点に貢献しなければなりません。MDN 上で実行されているランダムなものは、エディターコミュニティによって削除されます。</p>
+
+<div class="note">
+<p><strong>注意:</strong> ライブサンプルの出力を表示するには、マクロを使用する<strong>必要があります。</strong>MDN のエディターは、セキュリティを確保するために <code>&lt;iframe&gt;</code> 要素の直接使用を取り除きます。</p>
+</div>
+
+<p>サンプルのコードを含む各 {{HTMLElement("pre")}} ブロックには、HTML、CSS、または JavaScript コードのいずれかを示すクラスがあり、それぞれ「brush:html」、「brush:css」、「brush:js」です。これらのクラスは、wiki が正しく使うために、対応するコードブロック上になければなりません。幸いにも、各クラスはエディターのツールバーで構文ハイライト機能を使用すると自動的に追加されます。</p>
+
+<p>ライブサンプルシステムには多数のオプションが用意されており、少しずつ見ていきます。</p>
+
+<h3 id="Live_sample_macros" name="Live_sample_macros">ライブサンプルのマクロ</h3>
+
+<p>ライブサンプルを表示するために使用できるマクロは 2 つあります。</p>
+
+<ul>
+ <li><span class="templateLink"><code><a href="https://github.com/mdn/kumascript/blob/master/macros/EmbedLiveSample.ejs">EmbedLiveSample</a></code></span> はライブサンプルをページに埋め込みます。</li>
+ <li><span class="templateLink"><code><a href="https://github.com/mdn/kumascript/blob/master/macros/LiveSampleLink.ejs">LiveSampleLink</a></code></span> はライブサンプルを新しいページに開くリンクを作成します。</li>
+</ul>
+
+<p>多くの場合、<span class="templateLink"><code><a href="https://github.com/mdn/kumascript/blob/master/macros/EmbedLiveSample.ejs">EmbedLiveSample</a></code></span> や <span class="templateLink"><code><a href="https://github.com/mdn/kumascript/blob/master/macros/LiveSampleLink.ejs">LiveSampleLink</a></code></span> マクロは、追加の作業をほぼ全くすることなくページに追加することができます。サンプルが見出しの ID で識別されるか、ID を持つブロックに含まれていれば、マクロを追加するだけでその作業が行われるはずです。</p>
+
+<h4 id="EmbedLiveSample_macro" name="EmbedLiveSample_macro">EmbedLiveSample マクロ</h4>
+
+<pre class="syntaxbox notranslate"> \{{EmbedLiveSample(<em>block_ID</em>, <em>width</em>, <em>height</em>, <em>screenshot_URL</em>, <em>page_slug</em>)}}</pre>
+
+<div class="Note">
+<dl>
+ <dd>見出しが翻訳されている場合、その ID 属性が自動的に翻訳されたテキストに合わせてアップデートされます。そのため、マクロ内で呼び出される <em>block_ID</em> の値を変更しなくていけません。{{訳注("日本語では見出し要素には <code>name</code> 属性を追加して英語版と同じ ID となるようにしています。")}}</dd>
+</dl>
+</div>
+
+<dl>
+ <dt>block_ID</dt>
+ <dd>必須: コードを描画する見出しまたは囲みブロックの ID。適切な ID であるかどうかを確認する最善の方法は、ページの目次のセクションの URL を見ることです。<strong>注記:</strong> 見出しが翻訳されている場合、その ID 属性が自動的に翻訳されたテキストに合わせてアップデートされます。そのため、マクロ内で呼び出される <em>block_ID</em> の値を変更しなくていけません。 {{訳注("日本語では見出し要素には <code>name</code> 属性を追加して英語版と同じ ID となるようにしています。")}}</dd>
+ <dt>width</dt>
+ <dd>作成する {{HTMLElement("iframe")}} の幅で、<code>px</code> で指定します。これはオプションで、省略すると合理的なデフォルト幅が使用されます。特定の幅を使用する場合は、height パラメーターも指定する<em>必要があります。</em></dd>
+ <dt>height</dt>
+ <dd>作成する {{HTMLElement("iframe")}} の高さで、<code>px</code> で指定します。これはオプションで、省略すると合理的なデフォルトの高さが使用されます。特定の高さを使用する場合は、width パラメーターも指定する<em>必要があります。</em>どちらか一方しか使用しない場合は、デフォルトのフレームサイズが使用されます。</dd>
+ <dt>screenshot_URL</dt>
+ <dd>ライブサンプルの外観を示すスクリーンショットの URL。これはオプションですが、新しいテクノロジが動作しないユーザのブラウザに対して役立つ可能性があるため、サンプルがブラウザーでサポートされている場合の様子を確認できます。このパラメータを含めると、ライブサンプルの横に、適切な見出し付きのスクリーンショットが表示されます。</dd>
+ <dt>page_slug</dt>
+ <dd>サンプルが入っているページのスラグ。これはオプションで、指定されていない場合はマクロが使用されている同じページからサンプルが引き出されます。</dd>
+</dl>
+
+<ol>
+</ol>
+
+<h4 id="LiveSampleLink_macro" name="LiveSampleLink_macro">LiveSampleLink マクロ</h4>
+
+<pre class="syntaxbox notranslate"> \{{LiveSampleLink(<em>block_ID</em>, <em>link_text</em>)}}</pre>
+
+<dl>
+ <dt>block_ID</dt>
+ <dd>コードを引っ張ってくる見出しまたは囲みブロックの ID。正しいIDであるかどうかを確認する最善の方法は、ページの目次のセクションの URL を見ることです。<strong>注記:</strong> 見出しが翻訳されている場合、その ID 属性が自動的に翻訳されたテキストに合わせてアップデートされます。そのため、マクロ内で呼び出される <em>block_ID</em> の値を変更しなくていけません。{{訳注("日本語では見出し要素には <code>name</code> 属性を追加して英語版と同じ ID となるようにしています。")}}</dd>
+ <dt>link_text</dt>
+ <dd>リンクテキストとして使用する文字列。</dd>
+</dl>
+
+<h2 id="Using_the_live_sample_system" name="Using_the_live_sample_system">ライブサンプルシステムを使用する</h2>
+
+<p>以下のセクションでは、ライブサンプルシステムの一般的な使用例をいくつか説明します。</p>
+
+<p>これらのすべてのケースでライブサンプルの結果を表示するには、エディターで<strong>公開</strong>をクリックする必要があります (編集モードから離れます)。ライブサンプルには<a href="https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%82%BB%E3%83%97%E3%82%B7%E3%83%A7%E3%83%B3">インセプション</a>のように再帰的な性質があるため、<strong>プレビュー</strong>機能でライブサンプルを表示することは<em>できません。</em></p>
+
+<h3 id="Turning_snippets_into_live_samples" name="Turning_snippets_into_live_samples">スニペットをライブサンプルにする</h3>
+
+<p>よく使用されるケースの 1 つは、既に MDN に表示されている既存のコードスニペットを実際のサンプルに変換することです。</p>
+
+<h4 id="Prepare_the_code_samples" name="Prepare_the_code_samples">コードサンプルを準備する</h4>
+
+<p>最初のステップでは、コードスニペットを追加するか、既存のサンプルをコンテンツやマークアップの観点からライブサンプルとして使用できるようにします。コードスニペットは、まとめて実行可能な完全な例を構成する必要があります。たとえば、既存のスニペットに CSS のみが表示されている場合は、CSS が操作する HTML のスニペットを追加する必要があります。<br>
+ <br>
+ それぞれのコードは {{HTMLElement("pre")}} ブロックにあり、各ブロックはブロックごとに言語ごとに適切にマークされていなければなりません。ほとんどの場合、これは既に行われていますが、コードの各部分が正しい構文で構成されていることを確認することは、常に二重チェックしておく価値があります。ツールバーの <strong>PRE</strong> アイコンの隣には、MDN が構文強調表示を行うさまざまな言語のドロップダウンメニューアイコン (ツールヒント: 構文ハイライター) があります。構文の強調表示のためにブロックの言語を設定することで、ライブサンプルシステムの目的のための言語と関連付けられます。</p>
+
+<div class="note">
+<p><strong>注意:</strong> 複数の言語のブロックが独立していて、すべて一緒に連結する場合があるかもしれません。コードの塊りに続いて、動作原理の説明があって、また次の塊り、…という構成ができます。これにより、説明テキストを交えたライブサンプルを利用するチュートリアルなどを作成することがより容易になります。</p>
+</div>
+
+<p>HTML、CSS、JavaScript コードの {{HTMLElement("pre")}} ブロックがそれぞれの言語の構文強調表示に対して正しく設定されていることを確認してください。</p>
+
+<div class="note">
+<p><strong>注意:</strong> MDN にコンテンツを貼り付ける際には、意図せず不要なスタイルやクラスを取り込む可能性のあるスタイル付きコンテンツ (たとえば、別のサイトからコピーされたコードの構文強調を含む) を貼り付けることを意識してください。こうならないように注意してください。必要に応じて、ソースモードで編集内容を確認し、不要なスタイルやクラスを削除してください (貼り付ける前に確認するか、代わりに「プレーンテキストとして貼り付け」オプションを使用してください)。</p>
+</div>
+
+<h4 id="Insert_the_live_sample_macro" name="Insert_the_live_sample_macro">ライブサンプルマクロを挿入する</h4>
+
+<p>コードが配置され、各ブロックの言語を識別するように適切に構成されたら、iframeを作成するマクロを挿入する必要があります。</p>
+
+<ol>
+ <li>ツールバーの<strong>コードサンプルの iFrame を挿入</strong>ボタン (<img alt="" src="https://mdn.mozillademos.org/files/5383/insert-live-sample-btn.png" style="height: 18px; width: 19px;">) をクリックします。<br>
+  ライブサンプルフレームを設定するためのダイアログボックスが開きます<br>
+  <img alt="" src="https://mdn.mozillademos.org/files/5385/sample-finder.png" style="height: 358px; width: 405px;"></li>
+ <li><strong>ドキュメント</strong>に埋め込みたいサンプルが含まれている記事のタイトルを入力します。<br>
+  デフォルトでは現在編集中の記事ですが、MDN の別の場所で記事を選択することもできます。これにより、必要に応じて複数ページのサンプルを再利用することができます。(このフィールドに新しいテキストを入力すると、部分的に一致するページのメニューが表示され、必要なページのタイトルを選択します)</li>
+ <li><strong>ドキュメント内のセクション</strong>メニューで、埋め込みたいサンプルのコードブロックを含む記事のセクションを選択します</li>
+ <li><strong>OK</strong>ボタンをクリックして、サンプルフレームを作成するマクロ呼び出しを生成して挿入します。マクロ呼び出しは次のようになります<br>
+  <strong>\{{ EmbedLiveSample('Live_sample_demo') }}</strong></li>
+</ol>
+
+<h3 id="Adding_a_new_live_sample" name="Adding_a_new_live_sample">新規ライブサンプルを追加する</h3>
+
+<p>新しいページを作成していて、ライブサンプルとして提示したいコードを挿入したい場合は、さらに多くの作業をエディターで行うことができます！</p>
+
+<ol>
+ <li>ツールバーの<strong>コードサンプルテンプレートを挿入</strong>ボタン (<img alt="" src="/files/4265/live-sample-button.png" style="height: 19px; width: 21px;">) をクリックします。<br>
+  ライブサンプルに名前を付けるよう求める簡単なダイアログが表示されます。<br>
+  <img alt="" src="https://mdn.mozillademos.org/files/5387/insert-live-sample-template.png" style="height: 155px; width: 251px;"></li>
+ <li>サンプルのタイトルを入力します。これはサンプルの見出しとして使用されます。このタイトルがページの文脈の中で意味が通ることを確認してください。</li>
+ <li>入力したタイトルの新しい見出しが、HTML、CSS、およびJavaScript用のサブ見出しと空のコードブロックとともに作成されます。</li>
+ <li>必要のない見出しやコードブロックを削除してください。</li>
+ <li>適切なコードブロックでサンプルを構成するコードを入力します。</li>
+ <li><a href="#conventions">取り決めを確認します。</a></li>
+</ol>
+
+<h3 id="Using_the_Sample_Finder" name="Using_the_Sample_Finder">サンプルファインダーを使う</h3>
+
+<p>前述のように、サンプルファインダーは、<strong>コードサンプルの iFrame を挿入</strong>アイコンをクリックするとアクティブになります。残念なことに、サンプルファインダーは編集しないと<strong>使用できない</strong>マクロを生成することがあります。必要に応じて慎重にチェックして編集すべき 2 つの問題エリアがあります。</p>
+
+<ol>
+ <li><strong>ドキュメント</strong>フィールド。このフィールドは入力時に検索され、入力した文字列にマッチするドキュメントのリストが表示されます。しかし、提示されたリストにはサブページは<strong>含まれません</strong>。たとえば、メインページの <a href="https://developer.mozilla.org/ja/docs/Web/CSS/@counter-style">@counter-style</a> の下にある <a href="https://developer.mozilla.org/ja/docs/Web/CSS/@counter-style/negative">Negative </a>のサブページで作業しているとします。サンプルファインダーでの検索では Negative は見つかりませんが、メインページの @counter-style が検索されます。@counter-style を選択すると、フィールドの背景が緑色に変わります。このことによる問題については以下を参照してください。</li>
+ <li><strong>ドキュメントのセクション</strong>。ドキュメント内のプルダウンメニューのセクションに、必要なセクションが表示されないことがあります。例のように、ただ一つ選択して簡単な編集をすることで修正することができます。</li>
+</ol>
+
+<p>サンプルファインダーは次のようになりました。</p>
+
+<pre class="notranslate"><code>\{{ EmbedLiveSample('Examples', '', '', '', 'Web/CSS/@counter-style') }}</code></pre>
+
+<p>このマクロは動作しません。block_ID が Examples となっていますが、この場合は Example でなければなりません。(このセクションのソース ID を調べて、使用する必要のある block_ID を確認してください。) 同様に page_slug が @counter-style になっていますが、@counter-style/negative となるべきです。これらの修正は、編集ページで直接行うことができます。</p>
+
+<p>編集すると、マクロは次のようになります。</p>
+
+<pre class="notranslate"><code>\{{ EmbedLiveSample('Example', '', '', '', 'Web/CSS/@counter-style/negative') }}</code></pre>
+
+<p>この編集されたマクロは動作します。マクロが正常に動作している場合は、<strong>Open in CodePen </strong>ボタンが表示されます。この例のサムネイルは、<strong>Open in CodePen</strong> ボタンの上に表示されます。ボタンがあるがサムネイルがない場合は、少し待ってください。サーバーがこれを生成するには時間がかかることがあります。</p>
+
+<h2 id="Live_sample_demo" name="Live_sample_demo">更新が必要なサンプルを検索する</h2>
+
+<p>既存のサンプルを探して更新する場合は、更新の主な 3 つの種類があります:</p>
+
+<ul>
+ <li>既存の非ライブサンプルスニペットをライブサンプルに変換。</li>
+ <li>既存のライブサンプルのバグを修正。</li>
+ <li>既存のライブサンプルを改善、または、技術の変化に基づいてサンプルを更新。</li>
+</ul>
+
+<div class="note">
+<p><strong>注意:</strong> ライブサンプルシステムを使用するために更新が必要なサンプルがある記事を見つけた場合は、タグ「NeedsLiveSample」をページに追加してください。</p>
+</div>
+
+<h3 id="Finding_samples_to_turn_into_live_samples" name="Finding_samples_to_turn_into_live_samples">ライブサンプルに変換するサンプルを検索する</h3>
+
+<p>MDN にはライブサンプルシステムをまだ使用していない古いサンプルがたくさんあります。私たちの目標は、これらのほとんどまたはすべてをライブサンプルに更新することです。これにより、一貫性とユーザビリティが向上します。MDN を日常的に使用するときには、これらの多くがほぼ確実に見つかるでしょう。しかし、あなたが特にそれらを更新しようと探している場合、それらを見つけることができますか？残念ながら簡単な方法はありません。ですが、それらを追跡するのに役立つガイドラインがいくつかあります：</p>
+
+<ul>
+ <li>まず、<a href="/ja/docs/tag/NeedsLiveSample">「NeedsLiveSample」というタグが付けられたこのページのリスト</a>を見てみましょう。これらは、ユーザーが更新が必要とマークしたページです。ライブサンプルを使用するように更新する必要のあるページが表示されてもすぐに修正する時間がない場合は、このタグを自分で追加する必要があります。</li>
+ <li><a href="/ja/docs/Web/JavaScript/Guide">JavaScript ガイド</a>、<a href="/ja/docs/Web/HTML">HTML ドキュメント</a>、<a href="/ja/docs/Web/CSS/Reference">CSS リファレンス</a>などのサンプルが含まれている可能性のあるドキュメントツリーを参照してください。</li>
+ <li>「<a href="/search?q=example">example</a>」や 「<a href="/search?q=sample">sample</a>」のような用語を検索し、更新するページがないか、検索結果を調べます。</li>
+</ul>
+
+<h2 id="Live_sample_demo" name="Live_sample_demo">ライブサンプルのデモ</h2>
+
+<p>このセクションは、ライブサンプルテンプレートボタンを使用してメイン見出し (「ライブサンプルデモ」) だけでなく、HTML、CSS、および JavaScript コンテンツのサブ見出しも作成した結果です。それぞれのブロックに限定されませんし、さらに、特定の順序である必要はありません。</p>
+
+<p>削除したいものを削除することもできます。スクリプトが必要ない場合は、その見出しとその {{HTMLElement("pre")}} ブロックを削除してください。コードブロック (HTML、CSS、または JavaScript) の見出しは、ライブサンプルマクロでは使用されないため、削除することもできます。</p>
+
+<p>テンプレートが挿入されたので、いくつかのコード、さらには説明テキストを挿入することができます。</p>
+
+<h3 id="HTML" name="HTML">HTML</h3>
+
+<p>この HTML は、メッセージの配置とスタイルに役立つ段落とブロックを作成します。</p>
+
+<pre class="brush: html notranslate">&lt;p&gt;A simple example of the live sample system in action.&lt;/p&gt;
+&lt;div class="box"&gt;
+  &lt;div id="item"&gt;Hello world! Welcome to MDN&lt;/div&gt;
+&lt;/div&gt;
+</pre>
+
+<h3 id="CSS" name="CSS">CSS</h3>
+
+<p>CSS コードは、ボックスとその内部のテキストのスタイルを設定します。</p>
+
+<pre class="brush: css notranslate">.box {
+  width: 200px;
+  height: 100 px;
+  border-radius: 6px;
+  background-color: #ffaabb;
+}
+
+#item {
+  width: 100%;
+  font-weight: bold;
+  text-align: center;
+  font-size: 2em;
+}
+</pre>
+
+<h3 id="JavaScript" name="JavaScript">JavaScript</h3>
+
+<p>このコードは非常に簡単です。クリックすると警告が表示されるテキスト「Hello world!」にイベントハンドラーをアタッチするだけです。</p>
+
+<pre class="brush: js notranslate">var el = document.getElementById('item');
+el.onclick = function() {
+  alert('Owww, stop poking me!');
+}
+</pre>
+
+<h3 id="結果">結果</h3>
+
+<p>下記は <code>\{{EmbedLiveSample('Live_sample_demo')}}</code> を通じて、上のコードブロックを実行した結果です。<br>
+ <br>
+ {{EmbedLiveSample('Live_sample_demo')}}</p>
+
+<p>下記は <code>\{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}</code> を通じて、これらのコードブロックを経由して呼び出される結果のリンクです。</p>
+
+<p>{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}</p>
+
+<h2 id="Conventions_regarding_live_samples" name="Conventions_regarding_live_samples"><a id="conventions" name="conventions">ライブサンプルに関する取り決め</a></h2>
+
+<dl>
+ <dt>コードブロックの順序</dt>
+ <dd>ライブサンプルを追加する場合、コードブロックは最初のものがこのサンプルのメイン言語に対応するようにソートする必要があります。たとえば、HTML リファレンスのライブサンプルを追加する場合、最初のブロックは HTML でなければならず、CSS リファレンスのライブサンプルを追加するときは CSS でなければなりません。</dd>
+ <dt>見出しの名前付け</dt>
+ <dd>曖昧さがない場合 (例: サンプルが「Examples」セクションの下にある場合)、見出しは対応する言語の唯一の名前である HTML、CSS、JavaScript、SVG など (上記参照) で直接的に表します。「HTML コンテンツ」や「JavaScript コンテンツ」のような見出しは使用しないでください。しかし、そのような短い見出しがコンテンツを不明瞭にする場合、より思慮深いタイトルを使用することができます。</dd>
+ <dt>「Result」ブロックを使用する</dt>
+ <dd>異なるコードブロックの後、<code>EmbedLiveSample</code> マクロを使用する直前に、「Result」ブロックを使用してください (上記参照)。このようにして、この例の意味は、読者とページを解析するツール (スクリーンリーダー、ウェブクローラーなど) の両方にとってより明確になります。</dd>
+</dl>
diff --git a/files/ja/mdn/structures/live_samples/simple_live_sample_demo/index.html b/files/ja/mdn/structures/live_samples/simple_live_sample_demo/index.html
new file mode 100644
index 0000000000..9e550d81ac
--- /dev/null
+++ b/files/ja/mdn/structures/live_samples/simple_live_sample_demo/index.html
@@ -0,0 +1,37 @@
+---
+title: ライブコードサンプルの簡単なデモ
+slug: MDN/Structures/Live_samples/Simple_live_sample_demo
+tags:
+  - MDN Meta
+  - Structures
+  - 例
+translation_of: MDN/Structures/Live_samples/Simple_live_sample_demo
+---
+<div>{{MDNSidebar}}</div>
+
+<h2 id="The_example" name="The_example">例</h2>
+
+<p id="Simple_example_of_a_live_demo">これは、MDN でライブデモを行う方法を示す非常に簡単な例です。詳細については、<a href="/ja/docs/MDN/Contribute/Structures/Live_samples">ライブサンプル</a>を参照してください。</p>
+
+<pre class="brush: html notranslate">&lt;form&gt;
+  &lt;label&gt;Try me&lt;input type="text" name="name"&gt;&lt;/label&gt;
+  &lt;input type="submit" value="go"&gt;
+&lt;/form&gt;</pre>
+
+<pre class="brush: css notranslate">form {
+  border-radius: 10px;
+  background: powderblue;
+}</pre>
+
+<pre class="brush: js notranslate">var f = document.querySelector('form');
+
+f.addEventListener('submit', function(ev) {
+  ev.preventDefault();
+  document.querySelectorAll('input')[1].value = 'sending';
+}, false);</pre>
+
+<p>{{ EmbedLiveSample('The_example', '', '', '') }}</p>
+
+<div class="blockIndicator note">
+<p>注: ローカライズしたページでは、最初の引数の値は、サンプルを含む見出しの ID と同じにしてください．</p>
+</div>
diff --git a/files/ja/mdn/structures/macros/commonly-used_macros/creating_templates_for_multi-languages/index.html b/files/ja/mdn/structures/macros/commonly-used_macros/creating_templates_for_multi-languages/index.html
new file mode 100644
index 0000000000..a22ce9c70e
--- /dev/null
+++ b/files/ja/mdn/structures/macros/commonly-used_macros/creating_templates_for_multi-languages/index.html
@@ -0,0 +1,12 @@
+---
+title: creating templates for multi-languages
+slug: >-
+  MDN/Structures/Macros/Commonly-used_macros/creating_templates_for_multi-languages
+---
+<div>{{MDNSidebar}}</div>
+<div class="note"><strong>註：</strong>　このページは執筆中です。</div>
+<h2 id="執筆用memo">執筆用memo</h2>
+<ul> <li>span 要素を使って言語版毎にテンプレートを用意するタイプの「ページ・プロパティ」は「なし（デフォルト）」にする。「English」などにするとテンプレートが英語版とその言語版とで二重に表示される現象が起きる。</li>
+</ul>
+<h2 id="テンプレートの_2_つのタイプ">テンプレートの 2 つのタイプ</h2>
+<h2 id="page.langage_を使わない">page.langage を使わない</h2>
diff --git a/files/ja/mdn/structures/macros/commonly-used_macros/index.html b/files/ja/mdn/structures/macros/commonly-used_macros/index.html
new file mode 100644
index 0000000000..f7cc685313
--- /dev/null
+++ b/files/ja/mdn/structures/macros/commonly-used_macros/index.html
@@ -0,0 +1,210 @@
+---
+title: よく使われるマクロ
+slug: MDN/Structures/Macros/Commonly-used_macros
+tags:
+  - CSS
+  - Macros
+  - Reference
+  - Structures
+translation_of: MDN/Structures/Macros/Commonly-used_macros
+---
+<p>{{MDNSidebar}}</p>
+
+<p><span class="seoSummary">このページには MDN で使うために作られた汎用のマクロがたくさん掲載されています。これらのマクロの使い方については、<a href="/ja/docs/MDN/Contribute/Structures/Macros"> マクロの使い方</a> と <a href="/ja/docs/MDN/Contribute/Editor/Links#Using_link_macros">リンクを生成するマクロ</a> を見てください。</span> <a href="/ja/docs/MDN/Contribute/Structures/Macros/Other">その他のマクロ</a> には、めったに使われないマクロ、特殊な文脈でのみ使われるマクロ、使用が推奨されないマクロについての情報が書かれています。また、<a href="/en-US/dashboards/macros">MDNで使用できるマクロの完全な一覧</a>もあります。</p>
+
+<p><a href="/ja/docs/MDN/Contribute/Guidelines/CSS_style_guide">CSS スタイルガイド</a>も見てください。</p>
+
+<h2 id="Linking" name="Linking">リンク</h2>
+
+<h3 id="Creating_a_single_hyperlink" name="Creating_a_single_hyperlink">単一のハイパーリンクを作成する</h3>
+
+<p id="To_another_MDN_page_or_its_section_(anch_SectionOnPage_manch_Link_LinkItem_LinkItemDL)">一般的に、単なるリンクを作成するためにマクロを使う必要はありません。エディターインターフェイスにある <strong>リンク</strong> ボタンを使えば、リンクを作成できます。</p>
+
+<ul>
+ <li>{{TemplateLink("Glossary")}} マクロは MDN <a href="/ja/docs/Glossary">用語集</a>の中の指定した用語のエントリへのリンクを作成するのに使います。このマクロは、1つの必須の引数または2つの任意の引数を受け付けます。
+
+  <p>例:</p>
+
+  <ol>
+   <li>用語の名前 (例えば "HTML")</li>
+   <li>用語の名前の代わりに記事内に表示するテキスト (これはあまり使用するべきではありません)。 {{Optional_Inline}}</li>
+   <li>この引数が指定されており 0 以外である場合、用語集へのリンクに使われるカスタムスタイルが適用されません。{{Optional_Inline}}</li>
+  </ol>
+
+  <ul>
+   <li><code>\{{Glossary("HTML")}}</code> の表示は {{Glossary("HTML")}} となり、</li>
+   <li><code>\{{Glossary("CSS", "カスケーディングスタイルシート")}}</code> の表示は {{Glossary("CSS", "カスケーディングスタイルシート")}} となり、</li>
+   <li><code>\{{Glossary("HTML", "", 1)}}</code> の表示は {{Glossary("HTML", "", 1)}} となります。</li>
+  </ul>
+ </li>
+ <li>{{TemplateLink("anch")}} - ページ内の節へのリンクを生成
+  <ul>
+   <li><code>\{{anch("Linking to pages in references")}}</code></li>
+   <li>
+    <p>デモ: {{anch("Linking to pages in references")}}</p>
+   </li>
+  </ul>
+ </li>
+</ul>
+
+<h3 id="Linking_to_pages_in_references" name="Linking_to_pages_in_references">リファレンス内のページへのリンク</h3>
+
+<p>いろいろなマクロがあり、MDN の指定したリファレンスエリア内のページへのリンクを作成することができます。</p>
+
+<ul>
+ <li>{{TemplateLink("cssxref")}} は、<a href="/ja/docs/Web/CSS/Reference">CSS リファレンス</a>のページにリンクします。<br>
+  例: <code>\{{CSSxRef("cursor")}}</code> の結果は {{CSSxRef("cursor")}} になります</li>
+ <li>{{TemplateLink("domxref")}} は DOM リファレンス内のページにリンクします。最後にカッコを入れると、関数名のようにリンクが表示されます。たとえば、<code>\{{DOMxRef("document.getElementsByName()")}}</code> は {{DOMxRef("document.getElementsByName()")}} になります。<code>\{{DOMxRef("Node")}}</code> は {{DOMxRef("Node")}} になります</li>
+ <li>{{TemplateLink("event")}} は DOM イベントリファレンスのページにリンクします。たとえば、<code>\{{Event("change")}}</code> は {{Event("change")}} になります</li>
+ <li>{{TemplateLink("HTMLElement")}} は HTML リファレンスの HTML 要素にリンクします</li>
+ <li>{{TemplateLink("htmlattrxref")}} は HTML 属性にリンクします。属性のみを指定する場合はグローバル属性の、属性名と要素名を指定する場合は特定の要素に関連付けられた属性の説明にリンクします。たとえば、<code>\{{HTMLAttrxRef("lang")}}</code> は {{HTMLAttrxRef("lang")}} のリンクを生成します。<code>\{{HTMLAttrxRef("type","input")}}</code> は {{htmlattrxref("type","input")}} のリンクを生成します。</li>
+ <li>{{TemplateLink("jsxref")}} は <a href="/ja/docs/Web/JavaScript/Reference">JavaScript リファレンス</a>のページにリンクします。</li>
+ <li>{{TemplateLink("SVGAttr")}} は特定の SVG 属性にリンクします。たとえば、<code>\{{SVGAttr("d")}}</code> は {{SVGAttr("d")}} のリンクを生成します。</li>
+ <li>{{TemplateLink("SVGElement")}} は SVG リファレンスの SVG 要素にリンクします。</li>
+ <li>{{TemplateLink("HTTPHeader")}} は <a href="/ja/docs/Web/HTTP/Headers">HTTP ヘッダー</a>にリンクします。</li>
+ <li>{{TemplateLink("HTTPMethod")}} は <a href="/ja/docs/Web/HTTP/Methods">HTTP リクエストメソッド</a>にリンクします。</li>
+ <li>{{TemplateLink("HTTPStatus")}} は <a href="/ja/docs/Web/HTTP/Status">HTTP レスポンスステータスコード</a>にリンクします。</li>
+</ul>
+
+<h3 id="Linking_to_bugs" name="Linking_to_bugs">バグへのリンク</h3>
+
+<ul>
+ <li>バグ
+  <ul>
+   <li>{{TemplateLink("bug")}} を使うと、 bugzilla.mozilla.org に登録されているバグへのリンクを簡単に作ることができます。文法は <code>\{{Bug(123456)}}</code> です。 {{Bug(123456)}} のようなリンクになります。</li>
+   <li>{{TemplateLink("WebkitBug")}} は WebKit バグのデータベースへのリンクを挿入します。例えば <code>\{{WebkitBug(31277)}}</code> は {WebkitBug(31277)}} のようになります。</li>
+  </ul>
+ </li>
+</ul>
+
+<h3 id="Navigation_aids_for_multi-page_guides" name="Navigation_aids_for_multi-page_guides">複数のページからなるガイドのためのナビゲーション補助</h3>
+
+<p>{{TemplateLink("Previous")}}、{{TemplateLink("Next")}}、{{TemplateLink("PreviousNext")}} は、一連の記事の中でのナビゲーションコントロールを提供します。一方向用のテンプレートでは、 前の または 次の 記事の Wiki 位置を指す1つの引数が必要です。{{TemplateLink("PreviousNext")}} については、前の記事、次の記事を指す 2つの引数を取ります。最初の引数が前の記事を指し、2番めの引数が次の記事を指します。</p>
+
+<h2 id="Code_samples" name="Code_samples">コードのサンプル</h2>
+
+<h3 id="Live_samples" name="Live_samples">Live サンプル</h3>
+
+<ul>
+ <li>{{TemplateLink("EmbedLiveSample")}} はコードサンプルの出力をページに埋め込むのに使います。解説は <a href="/ja/docs/MDN/Contribute/Structures/Live_samples">Live サンプル</a>のページにあります</li>
+ <li>{{TemplateLink("LiveSampleLink")}} はコードサンプルの出力を含むページへのリンクを作成します。解説は <a href="/ja/docs/MDN/Contribute/Structures/Live_samples">Live サンプル</a>のページにあります</li>
+</ul>
+
+<h2 id="Sidebar_generation" name="Sidebar_generation">サイドバーの生成</h2>
+
+<p>ほぼすべての大きなページの集まりについて、雛形があります。典型的には、リファレンス、ガイド、チュートリアルでメインページに戻るためのリンク (パンくずリストではできないことがある) を提供し、記事を適切なカテゴリに配置します。</p>
+
+<ul>
+ <li>{{TemplateLink("CSSRef")}} は CSS リファレンスページのサイドバーを生成します</li>
+ <li>{{TemplateLink("HTMLRef")}} は HTML リファレンスページのサイドバーを生成します</li>
+ <li>{{TemplateLink("APIRef")}} は Web API リファレンスページのサイドバーを生成します</li>
+</ul>
+
+<h2 id="General-purpose_formatting" name="General-purpose_formatting">汎用の書式</h2>
+
+<h3 id="Inline_indicators_for_API_documentation" name="Inline_indicators_for_API_documentation">API 文書のためのインラインインジケーター</h3>
+
+<p>{{TemplateLink("optional_inline")}} と {{TemplateLink("ReadOnlyInline")}} は API 文書の中で通常、オブジェクトのプロパティまたは関数の引数のリストを記述するのに使われます。</p>
+
+<p>用法: <code>\{{optional_inline()}}</code> または <code>\{{ReadOnlyInline}}</code>. 例:</p>
+
+<dl>
+ <dt><code>isCustomObject</code>{{ReadOnlyInline}}</dt>
+ <dd><code>true</code> の場合、オブジェクトはカスタムオブジェクトであることを示します。</dd>
+ <dt><code>parameterX</code>{{Optional_Inline}}</dt>
+ <dd>ごにょごにょごにょ...</dd>
+</dl>
+
+<h2 id="Status_and_compatibility_indicators" name="Status_and_compatibility_indicators">状態と互換性についての表示</h2>
+
+<h3 id="Inline_indicators_with_no_additional_parameters" name="Inline_indicators_with_no_additional_parameters">インラインインジケーター (追加引数なし)</h3>
+
+<h4 id="Non-standard" name="Non-standard">標準外のもの</h4>
+
+<p>{{TemplateLink("non-standard_inline")}} は、その API が標準化されておらず、また標準化の予定もないことを示すインラインマークを付けます。</p>
+
+<h5 id="Syntax" name="Syntax">構文</h5>
+
+<p><code>\{{Non-standard_Inline}}</code></p>
+
+<h5 id="Examples" name="Examples">例</h5>
+
+<ul>
+ <li>アイコン: {{Non-standard_Inline}}</li>
+</ul>
+
+<h4 id="Experimental" name="Experimental">実験的なもの</h4>
+
+<p>{{TemplateLink("experimental_inline")}} は、その API が広く実装されておらず、また将来変更される可能性があることを示すインラインマークを付けます。</p>
+
+<h5 id="Syntax_2" name="Syntax_2">構文</h5>
+
+<p><code>\{{Experimental_Inline}}</code></p>
+
+<h5 id="Examples_2" name="Examples_2">例</h5>
+
+<ul>
+ <li>アイコン: {{Experimental_Inline}}</li>
+</ul>
+
+<h3 id="Inline_indicators_that_support_specifying_the_technology" name="Inline_indicators_that_support_specifying_the_technology">特定の技術の対応状況を表すインラインインジケーター</h3>
+
+<p>これらのマクロにパラメータを指定する場合は、"html", "js", "css", "gecko",のうちの1つにバージョン番号を加えたものとなります。</p>
+
+<h4 id="Deprecated" name="Deprecated">非推奨のもの</h4>
+
+<p>{{TemplateLink("deprecated_inline")}} はインラインの非推奨(deprecated) マークを付け、その API が公式には非推奨であり、使用を控えるべきであることを示します。<strong>注:</strong> 非推奨 (deprecated) が意味するのは、その項目はもう使用されるべきではないが、まだ機能するものであることです。もう機能しないものを示す用語としては、廃止 (obsolete) を使ってください。</p>
+
+<p>ブラウザー特有の記述 (HTML, API, JS, CSS, …) では、引数を使用しないでください。</p>
+
+<h5 id="Syntax_3" name="Syntax_3">構文</h5>
+
+<p><code>\{{Deprecated_Inline}}</code> または <code>\{{Deprecated_Inline("gecko5")}}</code></p>
+
+<h5 id="Examples_3" name="Examples_3">例</h5>
+
+<ul>
+ <li>アイコン: {{Deprecated_Inline}}</li>
+ <li>バッジ: {{Deprecated_Inline("gecko5")}}</li>
+</ul>
+
+<h4 id="Obsolete" name="Obsolete">廃止</h4>
+
+<p>{{TemplateLink("obsolete_inline")}} はインラインの廃止 (obsolete) マークを付け、例えばその関数、メソッド、またはプロパティ等を使用してはいけないことを示します。</p>
+
+<p>ブラウザー特有の記述 (HTML, API, JS, CSS, …) では、引数を使用しないでください。</p>
+
+<h5 id="Syntax_4" name="Syntax_4">構文</h5>
+
+<p><code>\{{Obsolete_Inline}}</code> または <code>\{{Obsolete_Inline("js1.8.5")}}</code></p>
+
+<h5 id="Examples_4" name="Examples_4">例</h5>
+
+<ul>
+ <li>アイコン: {{Obsolete_Inline}}</li>
+ <li>バッジ: {{Obsolete_Inline("js1.8.5")}}</li>
+</ul>
+
+<h3 id="Template_badges" name="Template_badges">テンプレートバッジ</h3>
+
+<p>これらのマクロはほとんど <a href="/ja/docs/Web/API">WebAPI</a> ページで使われます。{{anch("Creating new badges")}} に新しいバッジを作成するための情報があります。</p>
+
+<h3 id="Page_or_section_header_indicators" name="Page_or_section_header_indicators">ページまたはセクションのヘッダーを示すインジケーター</h3>
+
+<p>これらのテンプレートが示すのは、上記の対応するインラインマークと同じものです。テンプレートはリファレンスページのメインページタイトルの (または、パンくずリストがあるならばその) 直下に置きます。ページ内のセクションをマークアップすることもできます。</p>
+
+<ul>
+ <li>{{TemplateLink("non-standard_header")}}: <code>\{{Non-standard_Header}}</code> {{Non-standard_Header}}</li>
+ <li><a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">実験的な機能</a>を説明するページでは {{TemplateLink("SeeCompatTable")}} を使用する必要があります。例: <code>\{{SeeCompatTable}}</code> {{SeeCompatTable}}</li>
+ <li>{{TemplateLink("deprecated_header")}}: <code>\{{Deprecated_Header}}</code> {{Deprecated_Header}}</li>
+ <li>{{TemplateLink("deprecated_header")}} with parameter: <code>\{{Deprecated_Header("gecko5")}}</code> {{Deprecated_Header("gecko5")}} ブラウザーに依存しない領域 (HTML、API、JS、CSS など) でこの引数を使用しないでください</li>
+ <li>{{TemplateLink("obsolete_header")}}: <code>\{{Obsolete_Header}}</code> {{Obsolete_Header}}</li>
+ <li>{{TemplateLink("obsolete_header")}} with parameter: <code>\{{Obsolete_Header("gecko30")}}</code> {{Obsolete_Header("gecko30")}} ブラウザーに依存しない領域 (HTML、API、JS、CSS など) でこの引数を使用しないでください</li>
+ <li>{{TemplateLink("secureContext_header")}}: <code>\{{SecureContext_Header}}</code> {{SecureContext_Header}}</li>
+</ul>
+
+<h3 id="Indicating_that_a_feature_is_available_in_web_workers" name="Indicating_that_a_feature_is_available_in_web_workers">ウェブワーカーで使用できる機能であることを示す</h3>
+
+<p>{{TemplateLink("AvailableInWorkers")}} マクロは、その機能が<a href="/ja/docs/Web/API/Web_Workers_API">ウェブワーカー</a>のコンテキストで有効であることを示すためのローカライズされた注記ボックスを挿入するのに使われます。</p>
+
+<p>{{AvailableInWorkers}}</p>
diff --git a/files/ja/mdn/structures/macros/index.html b/files/ja/mdn/structures/macros/index.html
new file mode 100644
index 0000000000..40cddcf091
--- /dev/null
+++ b/files/ja/mdn/structures/macros/index.html
@@ -0,0 +1,46 @@
+---
+title: マクロ
+slug: MDN/Structures/Macros
+tags:
+  - Guide
+  - Kuma
+  - KumaScript
+  - MDN Meta
+  - Structures
+translation_of: MDN/Structures/Macros
+---
+<div>{{MDNSidebar}}</div><p><span class="seoSummary">MDN が動作している <a href="/ja/docs/MDN/Kuma" title="/en-US/docs/Project:MDN/Kuma">Kuma</a> プラットフォームは、幅広い作業の自動化を可能にする強力なマクロシステムである <a href="/ja/docs/MDN/Contribute/Tools/KumaScript" title="/en-US/docs/Project:MDN/Kuma/KumaScript_guide">KumaScript</a> を提供しています。この記事は MDN のマクロを記事中で呼び出す方法について情報を提供します。</span></p>
+
+<p><a href="/ja/docs/MDN/Contribute/Tools/KumaScript" title="/en-US/docs/Project:MDN/Kuma/KumaScript_guide">KumaScript ガイド</a>では MDN 上でマクロを利用する方法について詳細な情報を提供しているので、このセクションではむしろ全体の簡潔なまとめをします。</p>
+
+<h2 id="How_macros_are_implemented" name="How_macros_are_implemented">マクロはどのように実装されているか</h2>
+
+<p>MDN 上で動作するマクロは、サーバーで実行される <a href="/ja/docs/Web/JavaScript" title="/ja/docs/Web/JavaScript">JavaScript</a> コードを使用して実装され、 <a href="https://nodejs.org/en/" title="https://nodejs.org/en/">Node.js</a> によって解釈されます。そのうえ数多くのライブラリを用意しており、 Wiki 風のサービスを提供します。また、 Wiki プラットフォームとそのコンテンツを、マクロと連携させる機能を提供します。もっと詳細に興味があるのであれば、 <a href="/ja/docs/MDN/Contribute/Tools/KumaScript" title="/en-US/docs/Project:MDN/Kuma/KumaScript_guide">KumaScript ガイド</a>を参照して下さい。</p>
+
+<h2 id="Using_a_macro_in_content" name="Using_a_macro_in_content">コンテンツでのマクロの利用</h2>
+
+<p>実際にマクロを使うには、マクロの呼び出しを二重の中括弧で囲むだけです。引数があれば括弧で囲みます。つまり以下のようになります。</p>
+
+<pre class="notranslate">\{{macroname(parameter-list)}}</pre>
+
+<p>マクロ呼び出しに関するいくつかのポイント</p>
+
+<ul>
+ <li>マクロ名は大文字と小文字を区別します。それに関するエラーはよくあるので幾つかののパターンがあります。例えば、マクロ名に大文字があるのに全て小文字で入力しているかもしれません。また、小文字から始まる所を大文字にしてしまっているのかもしれません。</li>
+ <li>引数はコンマで区切ります。</li>
+ <li>引数が無ければ括弧は取ってしまって構いません。 <code>\{{macroname()}}</code> と <code>\{{macroname}}</code> はまったく同等です。</li>
+ <li>数値の引数は引用符で囲む必要がありませんが、囲んでも構いません（ただし、複数のピリオドを含むバージョン番号を渡す場合などは、引用符で囲む必要があります）。</li>
+ <li>エラーが発生した場合は、コードを丁寧に読み返して下さい。何が問題なのかそれでも特定できなかった場合には、 <a href="/ja/docs/MDN/Kuma/Troubleshooting_KumaScript_errors">KumaScript エラーのトラブルシューティング</a>を参照して下さい。</li>
+</ul>
+
+<p>マクロは高度にキャッシュ化されています。どの入力値についても（引数や、マクロを動作させる URL といった環境変数のいずれでも）、その結果は記憶され再利用されます。つまり、入力が変化した時だけマクロは実行されます。</p>
+
+<div class="note">
+<p><strong>注:</strong> ブラウザーでページを強制的に再読み込み（つまり、 Shift を押しながら再読み込み）すると、そのページのマクロを再評価することが出来ます。</p>
+</div>
+
+<p>マクロは大きなテキストブロックを挿入したり、 MDN の他記事からの内容で置き換えたりするようなシンプルなこともできますし、サイトを走査して目次をまるごと作り上げたり、出力のスタイリングをしたり、リンクを張ったりといった複雑なこともできます。</p>
+
+<p>最もよく使われるマクロについて<a href="/ja/docs/MDN/Contribute/Structures/Macros/Commonly-used_macros" title="/ja/docs/Project:MDN/Contributing/Custom_macros">良く使われるマクロ</a>のページで学習することが出来ます。また、<a href="https://developer.mozilla.org/ja/docs/templates" title="https://developer.mozilla.org/en-US/docs/templates">マクロの完全なリスト</a>もあります。そして多くのマクロには最上部のコメントとして、ソースに説明が組み込まれています。</p>
+
+<p>{{EditorGuideQuicklinks}}</p>
diff --git a/files/ja/mdn/structures/page_types/api_event_subpage_template/index.html b/files/ja/mdn/structures/page_types/api_event_subpage_template/index.html
new file mode 100644
index 0000000000..d211a4606f
--- /dev/null
+++ b/files/ja/mdn/structures/page_types/api_event_subpage_template/index.html
@@ -0,0 +1,121 @@
+---
+title: API イベントサブページのテンプレート
+slug: MDN/Structures/Page_types/API_event_subpage_template
+tags:
+  - API
+  - Event
+  - Event subpage
+  - Template
+  - reference page
+translation_of: MDN/Structures/Page_types/API_event_subpage_template
+---
+<div>{{MDNSidebar}}</div>
+
+<div class="note">
+<h2 id="Remove_before_publishing" name="Remove_before_publishing">公開前に削除してください</h2>
+
+<h3 id="Title_and_slug" name="Title_and_slug">タイトルとスラッグ</h3>
+
+<p>API イベントサブページの<em>タイトル</em>は、 <em>所属するインターフェイス名 + ": " + イベント名 + " イベント"</em>としてください。例えば、 <a href="/ja/docs/Web/API/Window/vrdisplaypresentchange_event">vrdisplaypresentchange</a> イベントが <a href="/ja/docs/Web/API/Window">Window</a> インターフェイスに所属している場合は、<em>タイトル</em>は <em>Window: vrdisplaypresentchange イベント</em>となります。</p>
+
+<p><em>スラッグ</em> (URL の最後の部分) は、<em>イベント名 + "_event"</em> としてください。したがって、 <code>vrdisplaypresentchange</code> のスラッグは <em>vrdisplaypresentchange_event</em> です。</p>
+
+<h3 id="Top_macros" name="Top_macros">先頭で使用するマクロ</h3>
+
+<p>既定では、テンプレートの先頭に5つのマクロ呼び出しがあります。以下のアドバイスに従って、更新や削除をしてください。</p>
+
+<ul>
+ <li>\{{draft()}} — this generates a <strong>Draft</strong> banner that indicates that the page is not yet complete, and should only be removed when the first draft of the page is completely finished. After it is ready to be published, you can remove this.</li>
+ <li>\{{SeeCompatTable}} — this generates a <strong>This is an experimental technology</strong> banner that indicates the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">experimental</a>). If the technology you are documenting is not experimental, you can remove this. If it is experimental, and the technology is hidden behind a pref in Firefox, you should also fill in an entry for it in the <a href="/ja/docs/Mozilla/Firefox/Experimental_features">Experimental features in Firefox</a> page.</li>
+ <li>\{{securecontext_header}} — this generates a <strong>Secure context</strong> banner that indicates the technology is only available in a <a href="/ja/docs/Web/Security/Secure_Contexts">secure context</a>. If it isn't, then you can remove the macro call. If it is, then you should also fill in an entry for it in the <a href="/ja/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts">Features restricted to secure contexts</a> page.</li>
+ <li>\{{deprecated_header}} — this generates a <strong>Deprecated</strong> banner that indicates the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">deprecated</a>. If it isn't, then you can remove the macro call.</li>
+ <li>
+  <div>\{{APIRef("<em>GroupDataName</em>")}} — this generates the left hand reference sidebar showing quick reference links related to the current page. For example, every page in the <a href="/ja/docs/Web/API/WebVR_API">WebVR API</a> has the same sidebar, which points to the other pages in the API. To generate the correct sidebar for your API, you need to add a GroupData entry to our KumaScript GitHub repo, and include the entry's name inside the macro call in place of <em>GroupDataName</em>. See our <a href="/ja/docs/MDN/Contribute/Structures/API_references/API_reference_sidebars">API reference sidebars</a> guide for information on how to do this.</div>
+ </li>
+</ul>
+
+<h3 id="Tags" name="Tags">タグ</h3>
+
+<p>In an API event subpage, you need to include the following tags (see the <em>Tags</em> section at the bottom of the editor UI): <strong>API</strong>, <strong>Reference</strong>, <strong>Event</strong>, <em>the name of the API</em> (e.g. <strong>WebVR</strong>), the name of the parent interface (e.g. <strong>Window</strong>), <strong>Experimental</strong> (if the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">experimental</a>), <strong>Secure context</strong> (if it is available in a secure context only), and <strong>Deprecated</strong> (if it is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">deprecated</a>).</p>
+
+<p>Optionally, you can elect to include some other tags that effective represent terms people might search for when looking for information on that technology. For example on WebVR interface pages we include <strong>VR</strong> and <strong>Virtual reality</strong>.</p>
+
+<h3 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの互換性</h3>
+
+<p>To fill in the browser compat data, you first need to fill in an entry for the API into our <a href="https://github.com/mdn/browser-compat-data">Browser compat data repo</a> — see our <a href="/ja/docs/MDN/Contribute/Structures/Compatibility_tables#The_new_way_The_browser_compat_data_repo_and_dynamic_tables">guide on how to do this</a>.</p>
+
+<p>Once that is done, you can show the compat data for the method with a \{{Compat()}} macro call.</p>
+</div>
+
+<div>{{draft}}{{SeeCompatTable}}{{securecontext_header}}{{deprecated_header}}{{APIRef("GroupDataName")}}</div>
+
+<p class="summary">The summary paragraph — start by naming the event, saying what interface it is part of, and saying what it does. This should ideally be 1 or 2 short sentences. You could copy most of this from the property's summary on the corresponding API reference page.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">バブリング</th>
+   <td>あり/なし</td>
+  </tr>
+  <tr>
+   <th scope="row">キャンセル</th>
+   <td>可/不可</td>
+  </tr>
+  <tr>
+   <th scope="row">インターフェイス</th>
+   <td>イベントが発生する親インターフェイスへのリンクです。例えば {{domxref("VRDisplayEvent")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">イベントハンドラープロパティ</th>
+   <td>イベントに対応するイベントハンドラープロパティへのリンクです。例えば {{domxref("Window/onvrdisplaypresentchange", "onvrdisplaypresentchange")}}</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Examples" name="Examples">例</h2>
+
+<p>Fill in a simple example that nicely shows a typical usage of the event, then perhaps some more complex examples (see our guide on how to add <a href="/ja/docs/MDN/Contribute/Structures/Code_examples">code examples</a> for more information).</p>
+
+<pre class="brush: js notranslate">my code block</pre>
+
+<p>And/or include a list of links to useful code samples that live elsewhere:</p>
+
+<ul>
+ <li>x</li>
+ <li>y</li>
+ <li>z</li>
+</ul>
+
+<h2 id="Specifications" name="Specifications">仕様書</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">仕様書</th>
+   <th scope="col">状態</th>
+   <th scope="col">備考</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{SpecName("NameOfSpecificationfromSpecName","#document-fragment-linking-directly-to-event-definition","NameOfTheEvent")}}</td>
+   <td>{{Spec2('NameOfSpecificationFromSpec2')}}</td>
+   <td>初回定義</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility_2" name="Browser_compatibility_2">ブラウザーの互換性</h2>
+
+<div class="hidden">このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> をチェックアウトしてプルリクエストを送信してください。</div>
+
+<p>{{Compat("path.to.feature.NameOfTheEvent_event")}}</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li>Include list of</li>
+ <li>other links related to</li>
+ <li>this API that might</li>
+ <li>be useful</li>
+</ul>
diff --git a/files/ja/mdn/structures/page_types/api_method_subpage_template/index.html b/files/ja/mdn/structures/page_types/api_method_subpage_template/index.html
new file mode 100644
index 0000000000..f418b66752
--- /dev/null
+++ b/files/ja/mdn/structures/page_types/api_method_subpage_template/index.html
@@ -0,0 +1,124 @@
+---
+title: API メソッドサブページのテンプレート
+slug: MDN/Structures/Page_types/API_method_subpage_template
+tags:
+  - API
+  - Method
+  - Template
+  - method subpage
+  - reference page
+translation_of: MDN/Structures/Page_types/API_method_subpage_template
+---
+<div>{{MDNSidebar}}</div>
+
+<div class="blockIndicator note">
+<h2 id="Remove_before_publishing" name="Remove_before_publishing">公開前に削除してください</h2>
+
+<h3 id="Title_and_slug" name="Title_and_slug">タイトルとスラッグ</h3>
+
+<p>API メソッドサブページの<em>タイトル</em>は、<em>インターフェイス名</em> + "." + <em>メソッド名</em> + "()" としてください。例えば、 <a href="/ja/docs/Web/API/IDBIndex">IDBIndex</a> インターフェイスの <a href="/ja/docs/Web/API/IDBIndex/count">count()</a> メソッドの<em>タイトル</em> は "IDBIndex.count()" です。</p>
+
+<p><em>スラッグ</em> (URL の最後の部分) は、<em>メソッド名</em>を括弧なして記述してください。ですから <code>count()</code> のスラッグは "count" です。</p>
+
+<h3 id="Top_macros" name="Top_macros">先頭で使用するマクロ</h3>
+
+<p>既定では、テンプレートの先頭に5つのマクロ呼び出しがあります。以下のアドバイスに従って、更新や削除をしてください。</p>
+
+<ul>
+ <li>\{{APIRef("<em>GroupDataName</em>")}} — this generates the left hand reference sidebar showing quick reference links related to the current page. For example, every page in the <a href="/ja/docs/Web/API/WebVR_API">WebVR API</a> has the same sidebar, which points to the other pages in the API. To generate the correct sidebar for your API, you need to add a GroupData entry to our KumaScript GitHub repo, and include the entry's name inside the macro call in place of <em>GroupDataName</em>. See our <a href="/ja/docs/MDN/Contribute/Structures/API_references/API_reference_sidebars">API reference sidebars</a> guide for information on how to do this.</li>
+ <li>\{{Draft}} — this generates a <strong>Draft</strong> banner that indicates that the page is not yet complete, and should only be removed when the first draft of the page is completely finished. After it is ready to be published, you can remove this.</li>
+ <li>\{{SeeCompatTable}} — this generates a <strong>This is an experimental technology</strong> banner that indicates the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">experimental</a>). If the technology you are documenting is not experimental, you can remove this. If it is experimental, and the technology is hidden behind a pref in Firefox, you should also fill in an entry for it in the <a href="/ja/docs/Mozilla/Firefox/Experimental_features">Experimental features in Firefox</a> page.</li>
+ <li>\{{SecureContext_Header}} — this generates a <strong>Secure context</strong> banner that indicates the technology is only available in a <a href="/ja/docs/Web/Security/Secure_Contexts">secure context</a>. If it isn't, then you can remove the macro call. If it is, then you should also fill in an entry for it in the <a href="/ja/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts">Features restricted to secure contexts</a> page.</li>
+ <li>\{{Deprecated_Header}} — this generates a <strong>Deprecated</strong> banner that indicates the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">deprecated</a>. If it isn't, then you can remove the macro call.</li>
+</ul>
+
+<h3 id="Tags" name="Tags">タグ</h3>
+
+<p>In an API method subpage, you need to include the following tags (see the <em>Tags</em> section at the bottom of the editor UI): <strong>API</strong>, <strong>Reference</strong>, <strong>Method</strong>, <em>the name of the API</em> (e.g. <strong>WebVR</strong>), the name of the parent interface (e.g. <strong>IDBIndex</strong>), the name of the method (e.g. <strong>count()</strong>), <strong>Experimental</strong> (if the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">experimental</a>), <strong>Secure context</strong> (if it is available in a secure context only), and <strong>Deprecated</strong> (if it is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">deprecated</a>).</p>
+
+<p>Optionally, you can elect to include some other tags that effective represent terms people might search for when looking for information on that technology. For example on WebVR interface pages we include <strong>VR</strong> and <strong>Virtual reality</strong>.</p>
+
+<h3 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの互換性</h3>
+
+<p>To fill in the browser compat data, you first need to fill in an entry for the API into our <a href="https://github.com/mdn/browser-compat-data">Browser compat data repo</a> — see our <a href="/ja/docs/MDN/Contribute/Structures/Compatibility_tables#The_new_way_The_browser_compat_data_repo_and_dynamic_tables">guide on how to do this</a>.</p>
+
+<p>Once that is done, you can show the compat data for the method with a \{{Compat()}} macro call.</p>
+</div>
+
+<p>{{APIRef("GroupDataName")}}{{Draft}}{{SeeCompatTable}}{{SecureContext_header}}{{Deprecated_Header}}</p>
+
+<p class="summary">The summary paragraph — start by naming the method, saying what interface it is part of, and saying what it does. This should ideally be 1 or 2 short sentences. You could copy most of this from the method's summary on the corresponding API reference page.</p>
+
+<h2 id="Syntax" name="Syntax">構文</h2>
+
+<pre class="syntaxbox notranslate">Fill in a syntax box, according to the guidance in our <a href="/ja/docs/MDN/Contribute/Structures/Syntax_sections">syntax sections</a> article.</pre>
+
+<h3 id="Parameters" name="Parameters">引数</h3>
+
+<dl>
+ <dt>parameter1{{Optional_Inline}}</dt>
+ <dd>Include a brief description of the parameter and what it does here. Include one term and definition for each parameter. If the parameter is not optional, remove the \{{optional_inline}} macro call.</dd>
+ <dt>parameter2</dt>
+ <dd>etc.</dd>
+</dl>
+
+<h3 id="Return_value" name="Return_value">返値</h3>
+
+<p>Include a description of the method's return value, including data type and what it represents. If the method doesn't return anything, just put "Void".</p>
+
+<h3 id="Exceptions" name="Exceptions">例外</h3>
+
+<dl>
+ <dt>Exception1</dt>
+ <dd>Include a list of all the exceptions that the method can raise, along with descriptions of how that exception is raised. Include one term and definition for each exception.</dd>
+ <dt>Exception2</dt>
+ <dd>etc.</dd>
+</dl>
+
+<h2 id="Examples" name="Examples">例</h2>
+
+<p>Fill in a simple example that nicely shows a typical usage of the method, then perhaps some more complex examples (see our guide on how to add <a href="/ja/docs/MDN/Contribute/Structures/Code_examples">code examples</a> for more information).</p>
+
+<pre class="brush: js notranslate">my code block</pre>
+
+<p>And/or include a list of links to useful code samples that live elsewhere:</p>
+
+<ul>
+ <li>x</li>
+ <li>y</li>
+ <li>z</li>
+</ul>
+
+<h2 id="Specifications" name="Specifications">仕様書</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">仕様書</th>
+   <th scope="col">状態</th>
+   <th scope="col">備考</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{SpecName("NameOfSpecificationfromSpecName", "#document-fragment-linking-directly-to-method-definition", "NameOfTheMethod")}}</td>
+   <td>{{Spec2("NameOfSpecificationFromSpec2")}}</td>
+   <td>初回定義</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility_2" name="Browser_compatibility_2">ブラウザーの互換性</h2>
+
+<div class="hidden">このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> をチェックアウトしてプルリクエストを送信してください。</div>
+
+<p>{{Compat("path.to.feature.NameOfTheMethod")}}</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li>Include list of</li>
+ <li>other links related to</li>
+ <li>this API that might</li>
+ <li>be useful</li>
+</ul>
diff --git a/files/ja/mdn/structures/page_types/api_property_subpage_template/index.html b/files/ja/mdn/structures/page_types/api_property_subpage_template/index.html
new file mode 100644
index 0000000000..f24015fa8e
--- /dev/null
+++ b/files/ja/mdn/structures/page_types/api_property_subpage_template/index.html
@@ -0,0 +1,107 @@
+---
+title: API property subpage template
+slug: MDN/Structures/Page_types/API_property_subpage_template
+tags:
+  - API
+  - Property
+  - Template
+  - property subpage
+  - reference page
+  - テンプレート
+translation_of: MDN/Structures/Page_types/API_property_subpage_template
+---
+<p>{{MDNSidebar}}</p>
+
+<div class="note">
+<h2 id="Remove_before_publishing" name="Remove_before_publishing">公開前に削除してください</h2>
+
+<h3 id="Title_and_slug" name="Title_and_slug">タイトルとスラッグ</h3>
+
+<p>API プロパティサブページの<em>タイトル</em>は、<em>インターフェイス名</em> + "." + <em>プロパティ名</em>としてください。例えば、 <a href="/ja/docs/Web/API/VRDisplay">VRDisplay</a> インターフェイスの <a href="/ja/docs/Web/API/VRDisplay/capabilities">capabilities</a> プロパティの<em>タイトル</em> は <em>VRDisplay.capabilities</em> です。</p>
+
+<p><em>スラッグ</em> (URL の最後の部分) は、<em>プロパティ名</em>を記述してください。ですから <code>capabilities</code> のスラッグは <em>capabilities</em> です。</p>
+
+<h3 id="Top_macros" name="Top_macros">先頭で使用するマクロ</h3>
+
+<p>既定では、テンプレートの先頭に5つのマクロ呼び出しがあります。以下のアドバイスに従って、更新や削除をしてください。</p>
+
+<ul>
+ <li>\{{APIRef("<em>グループデータ名</em>")}} — これは左端にあるサイドバーを生成し、現在のページに関連するクイックリファレンスのリンクを表示します。例えば、 <a href="/ja/docs/Web/API/WebVR_API">WebVR API</a> の中の各ページは同じサイドバーを持ち、この API 内の他のページを指します。 API で正しいサイドバーを生成するには、 KumaScript の GitHub リポジトリにグループデータの項目を追加し、マクロ呼び出しの中で<em>グループデータ名</em>のところに項目名を入れる必要があります。これを行う方法についてのガイドは <a href="/ja/docs/MDN/Contribute/Structures/API_references/API_reference_sidebars">API リファレンスサイドバー</a>を参照してください。</li>
+ <li>\{{Draft}} — this generates a <strong>Draft</strong> banner that indicates that the page is not yet complete, and should only be removed when the first draft of the page is completely finished. After it is ready to be published, you can remove this.</li>
+ <li>\{{SeeCompatTable}} — this generates a <strong>This is an experimental technology</strong> banner that indicates the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">experimental</a>). If the technology you are documenting is not experimental, you can remove this. If it is experimental, and the technology is hidden behind a pref in Firefox, you should also fill in an entry for it in the <a href="/ja/docs/Mozilla/Firefox/Experimental_features">Experimental features in Firefox</a> page.</li>
+ <li>\{{SecureContext_Header}} — this generates a <strong>Secure context</strong> banner that indicates the technology is only available in a <a href="/ja/docs/Web/Security/Secure_Contexts">secure context</a>. If it isn't, then you can remove the macro call. If it is, then you should also fill in an entry for it in the <a href="/ja/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts">Features restricted to secure contexts</a> page.</li>
+ <li>\{{Deprecated_Header}} — this generates a <strong>Deprecated</strong> banner that indicates the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">deprecated</a>. If it isn't, then you can remove the macro call.</li>
+</ul>
+
+<h3 id="Tags" name="Tags">タグ</h3>
+
+<p>In an API method subpage, you need to include the following tags (see the <em>Tags</em> section at the bottom of the editor UI): <strong>API</strong>, <strong>Reference</strong>, <strong>Property</strong>, <em>the name of the API</em> (e.g. <strong>WebVR</strong>), the name of the parent interface (e.g. <strong>VRDisplay</strong>), the name of the method (e.g. <strong>capabilities</strong>), <strong>Experimental</strong> (if the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">experimental</a>), <strong>Secure context</strong> (if it is available in a secure context only), and <strong>Deprecated</strong> (if it is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">deprecated</a>).</p>
+
+<p>Optionally, you can elect to include some other tags that effective represent terms people might search for when looking for information on that technology. For example on WebVR interface pages we include <strong>VR</strong> and <strong>Virtual reality</strong>.</p>
+
+<h3 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの互換性</h3>
+
+<p>To fill in the browser compat data, you first need to fill in an entry for the API into our <a href="https://github.com/mdn/browser-compat-data">Browser compat data repo</a> — see our <a href="/ja/docs/MDN/Contribute/Structures/Compatibility_tables#The_new_way_The_browser_compat_data_repo_and_dynamic_tables">guide on how to do this</a>.</p>
+
+<p>Once that is done, you can show the compat data for the method with a \{{Compat()}} macro call.</p>
+</div>
+
+<p>{{APIRef("GroupDataName")}}{{Draft}}{{SeeCompatTable}}{{SecureContext_Header}}{{Deprecated_Header}}</p>
+
+<p class="summary">The summary paragraph — start by naming the property, saying what interface it is part of, and saying what it does. This should ideally be 1 or 2 short sentences. You could copy most of this from the property's summary on the corresponding API reference page. Include whether it is read-only or not.</p>
+
+<h2 id="Syntax" name="Syntax">構文</h2>
+
+<pre class="syntaxbox notranslate">Fill in a syntax box, according to the guidance in our <a href="/ja/docs/MDN/Contribute/Structures/Syntax_sections">syntax sections</a> article.</pre>
+
+<h3 id="Value" name="Value">値</h3>
+
+<p>Include a description of the property's value, including data type and what it represents.</p>
+
+<h2 id="Examples" name="Examples">例</h2>
+
+<p>Fill in a simple example that nicely shows a typical usage of the property, then perhaps some more complex examples (see our guide on how to add <a href="/ja/docs/MDN/Contribute/Structures/Code_examples">code examples</a> for more information).</p>
+
+<pre class="brush: js; notranslate">my code block</pre>
+
+<p>And/or include a list of links to useful code samples that live elsewhere:</p>
+
+<ul>
+ <li>x</li>
+ <li>y</li>
+ <li>z</li>
+</ul>
+
+<h2 id="Specifications" name="Specifications">仕様書</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">仕様書</th>
+   <th scope="col">状態</th>
+   <th scope="col">備考</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{SpecName("NameOfSpecification", "#document-fragment-linking-directly-to-property-definition", "NameOfTheProperty")}}</td>
+   <td>{{Spec2("NameOfSpecification")}}</td>
+   <td>初回定義</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility_2" name="Browser_compatibility_2">ブラウザーの互換性</h2>
+
+<div class="hidden">このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> をチェックアウトしてプルリクエストを送信してください。</div>
+
+<p>{{Compat("path.to.feature.NameOfTheProperty")}}</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li>Include list of</li>
+ <li>other links related to</li>
+ <li>this API that might</li>
+ <li>be useful</li>
+</ul>
diff --git a/files/ja/mdn/structures/page_types/api_reference_page_template/index.html b/files/ja/mdn/structures/page_types/api_reference_page_template/index.html
new file mode 100644
index 0000000000..e59690ef30
--- /dev/null
+++ b/files/ja/mdn/structures/page_types/api_reference_page_template/index.html
@@ -0,0 +1,148 @@
+---
+title: API reference page template
+slug: MDN/Structures/Page_types/API_reference_page_template
+tags:
+  - API
+  - Template
+  - reference page
+  - テンプレート
+translation_of: MDN/Structures/Page_types/API_reference_page_template
+---
+<p>{{MDNSidebar}}</p>
+
+<div class="blockIndicator note">
+<h2 id="Remove_before_publishing" name="Remove_before_publishing">公開前に削除してください</h2>
+
+<h3 id="Title_and_slug" name="Title_and_slug">タイトルとスラッグ</h3>
+
+<p>API リファレンスページでは、<em>そのページで説明しているインターフェイスの名前</em>を<em>タイトル</em>にしてください。例えば、 <a href="/ja/docs/Web/API/Request">Request</a> インターフェイスのページでは、<em>タイトル</em> を <em>Request</em> にしてください。</p>
+
+<p><em>スラッグ</em> (URL の最後の部分) も、<em>そのページで説明しているインターフェイスの名前</em>にしてください。したがって、 <code>Request</code> のスラッグは <em>Request</em> です。これはふつう、自動的に設定されます。</p>
+
+<h3 id="Top_macros" name="Top_macros">先頭で使用するマクロ</h3>
+
+<p>既定では、テンプレートの先頭に5つのマクロ呼び出しがあります。以下のアドバイスに従って、更新や削除をしてください。</p>
+
+<ul>
+ <li>\{{APIRef("<em>グループデータ名</em>")}} — これは左端にあるサイドバーを生成し、現在のページに関連するクイックリファレンスのリンクを表示します。例えば、 <a href="/ja/docs/Web/API/WebVR_API">WebVR API</a> の中の各ページは同じサイドバーを持ち、この API 内の他のページを指します。 API で正しいサイドバーを生成するには、 KumaScript の GitHub リポジトリにグループデータの項目を追加し、マクロ呼び出しの中で<em>グループデータ名</em>のところに項目名を入れる必要があります。これを行う方法についてのガイドは <a href="/ja/docs/MDN/Contribute/Structures/API_references/API_reference_sidebars">API リファレンスサイドバー</a>を参照してください。</li>
+ <li>\{{Draft}} — this generates a <strong>Draft</strong> banner that indicates that the page is not yet complete, and should only be removed when the first draft of the page is completely finished. After it is ready to be published, you can remove this.</li>
+ <li>\{{SeeCompatTable}} — this generates a <strong>This is an experimental technology</strong> banner that indicates the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">experimental</a>). If the technology you are documenting is not experimental, you can remove this. If it is experimental, and the technology is hidden behind a pref in Firefox, you should also fill in an entry for it in the <a href="/ja/docs/Mozilla/Firefox/Experimental_features">Experimental features in Firefox</a> page.</li>
+ <li>\{{SecureContext_Header}} — this generates a <strong>Secure context</strong> banner that indicates the technology is only available in a <a href="/ja/docs/Web/Security/Secure_Contexts">secure context</a>. If it isn't, then you can remove the macro call. If it is, then you should also fill in an entry for it in the <a href="/ja/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts">Features restricted to secure contexts</a> page.</li>
+ <li>\{{Deprecated_Header}} — this generates a <strong>Deprecated</strong> banner that indicates the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">deprecated</a>. If it isn't, then you can remove the macro call.</li>
+ <li>\{{Interface_Overview("<em>GroupDataName</em>")}} {{Experimental_Inline}} — this generates the main body of the page (Constructor, Properties, Methods and Evenets)</li>
+</ul>
+
+<h3 id="Tags" name="Tags">タグ</h3>
+
+<p>In an API reference page, you need to include the following tags (see the <em>Tags</em> section at the bottom of the editor UI): <strong>API</strong>, <strong>Reference</strong>, <strong>Interface</strong>, <em>the name of the API</em> (e.g. <strong>WebVR</strong>), the name of the interface (e.g. <strong>Request</strong>), <strong>Experimental</strong> (if the technology is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Experimental">experimental</a>), <strong>Secure context</strong> (if it is available in a secure context only), and <strong>Deprecated</strong> (if it is <a href="/ja/docs/MDN/Contribute/Guidelines/Conventions_definitions#Deprecated_and_obsolete">deprecated</a>).</p>
+
+<p>Optionally, you can elect to include some other tags that effective represent terms people might search for when looking for information on that technology. For example on WebVR interface pages we include <strong>VR</strong> and <strong>Virtual reality</strong>.</p>
+
+<h3 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの互換性</h3>
+
+<p>To fill in the browser compat data, you first need to fill in an entry for the API into our <a href="https://github.com/mdn/browser-compat-data">Browser compat data repo</a> — see our <a href="/ja/docs/MDN/Contribute/Structures/Compatibility_tables#The_new_way_The_browser_compat_data_repo_and_dynamic_tables">guide on how to do this</a>.</p>
+
+<p>Once that is done, you can show the compat data for the interface with a \{{Compat(…)}} macro call.</p>
+</div>
+
+<p>{{APIRef("GroupDataName")}}{{Draft}}{{SeeCompatTable}}{{SecureContext_Header}}{{Deprecated_Header}}</p>
+
+<p class="summary">The summary paragraph — start by naming the interface, saying what API it is part of, and saying what it does. This should ideally be 1 or 2 short sentences. You could copy most of this from the Interface's summary on the corresponding API landing page.</p>
+
+<p>{{InheritanceDiagram}}</p>
+
+<h2 id="Constructor" name="Constructor">コンストラクター</h2>
+
+<dl>
+ <dt>{{DOMxRef("NameOfTheInterface.NameOfTheInterface")}}</dt>
+ <dd>Creates a new instance of the {{DOMxRef("NameOfTheInterface")}} object.</dd>
+</dl>
+
+<h2 id="Properties" name="Properties">プロパティ</h2>
+
+<p><em>Also inherits properties from its parent interface, {{DOMxRef("NameOfParentInterface")}}.</em> (Note: If the interface doesn't inherit from another interface, remove this whole line.)</p>
+
+<dl>
+ <dt>{{DOMxRef("NameOfTheInterface.property1")}}{{ReadOnlyInline}} {{Deprecated_Inline}}</dt>
+ <dd>Include a brief description of the property and what it does here. Include one term and definition for each property. If the property is not readonly/experimental/deprecated, remove the relevant macro calls.</dd>
+ <dt>{{DOMxRef("NameOfTheInterface.property2")}}</dt>
+ <dd>etc.</dd>
+</dl>
+
+<h2 id="Methods" name="Methods">メソッド</h2>
+
+<p><em>Also inherits methods from its parent interface, {{DOMxRef("NameOfParentInterface")}}.</em> (Note: If the interface doesn't inherit from another interface, remove this whole line.)</p>
+
+<dl>
+ <dt>{{DOMxRef("NameOfTheInterface.method1()")}} {{Experimental_Inline}} {{Deprecated_Inline}}</dt>
+ <dd>Include a brief description of the method and what it does here. Include one term and definition for each method. If the method is not experimental/deprecated, remove the relevant macro calls.</dd>
+ <dt>{{DOMxRef("NameOfTheInterface.method2()")}}</dt>
+ <dd>etc.</dd>
+</dl>
+
+<h2 id="Events" name="Events">イベント</h2>
+
+<p>Listen to these events using <code><a href="/ja/docs/Web/API/EventTarget/addEventListener">addEventListener()</a></code> or by assigning an event listener to the <code>on<em>eventname</em></code> property of this interface.</p>
+
+<dl>
+ <dt><code><a href="#">eventname1</a></code></dt>
+ <dd>Fired when ... include description of when event fires<br>
+ Also available via the <code><a href="#">oneventname1</a></code> property.</dd>
+ <dt><code><a href="#">eventname2</a></code></dt>
+ <dd>Fired when ... include description of when event fires<br>
+ Also available via the <code><a href="#">oneventname2</a></code> property.</dd>
+ <dt>etc.</dt>
+</dl>
+
+<h2 id="Examples" name="Examples">例</h2>
+
+<p>Fill in a simple example that nicely shows a typical usage of the interfaces, then perhaps some more complex examples (see our guide on how to add <a href="/ja/docs/MDN/Contribute/Structures/Code_examples">code examples</a> for more information).</p>
+
+<pre class="brush: js notranslate">my code block</pre>
+
+<p>And/or include a list of links to useful code samples that live elsewhere:</p>
+
+<ul>
+ <li>x</li>
+ <li>y</li>
+ <li>z</li>
+</ul>
+
+<h2 id="Specifications" name="Specifications">仕様書</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">仕様書</th>
+   <th scope="col">状態</th>
+   <th scope="col">備考</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{SpecName("NameOfOtherSpecification", "#document-fragment-linking-directly-to-feature-definition", "NameOfTheFeature")}}</td>
+   <td>{{Spec2("NameOfOtherSpecification")}}</td>
+   <td>Defines blah blah feature. If no other specs define specific subfeatures of this interface, you can delete this table row.</td>
+  </tr>
+  <tr>
+   <td>{{SpecName("NameOfSpecification", "#document-fragment-linking-directly-to-interface-definition", "NameOfTheInterface")}}</td>
+   <td>{{Spec2("NameOfSpecification")}}</td>
+   <td>初回定義</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility_2" name="Browser_compatibility_2">ブラウザーの互換性</h2>
+
+<div class="hidden">このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> をチェックアウトしてプルリクエストを送信してください。</div>
+
+<p>{{Compat("path.to.feature.NameOfTheInterface")}}</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li>Include list of</li>
+ <li>other links related to</li>
+ <li>this API that might</li>
+ <li>be useful</li>
+</ul>
diff --git a/files/ja/mdn/structures/page_types/index.html b/files/ja/mdn/structures/page_types/index.html
new file mode 100644
index 0000000000..818c365cf7
--- /dev/null
+++ b/files/ja/mdn/structures/page_types/index.html
@@ -0,0 +1,239 @@
+---
+title: ページの種類
+slug: MDN/Structures/Page_types
+tags:
+  - MDN Meta
+  - ガイド
+  - ドキュメンテーション
+  - 構造
+translation_of: MDN/Structures/Page_types
+---
+<div>{{MDNSidebar}}{{IncludeSubnav("/ja/docs/MDN")}}</div>
+
+<p class="summary">MDN に繰り返し使用されるいくつかの種類のページがあります。この記事では、これらのページの種類とその目的、および新しいページを作成するときに使用するそれぞれのテンプレートの例と使用方法について説明します。</p>
+
+<p>MDN には大きく分けて3種類のページがありますが、いくつかの種類のページはは複数のカテゴリに分類されます。</p>
+
+<ul>
+ <li><strong>リファレンス</strong>ページは何かの詳細を記述し、記述されているものの構造に従って編成されています</li>
+ <li><strong>ガイド</strong>ページには、何かを行う方法や使う方法が書かれており、読者の目標に基づいて編成されています</li>
+ <li><strong>ナビゲーションページ</strong>は、主に関連するトピックに関する他のページへのリンクを提供するために存在します</li>
+</ul>
+
+<h2 id="Creating_a_new_page" name="Creating_a_new_page">新しいページの作成</h2>
+
+<p>MDN に新しいページを作成するには、まず「ページ作成者」のアクセス許可が必要です。これを持っていない場合は、MDN 管理チームのメンバーからリクエストできます (<a href="/ja/docs/MDN/Contribute/Structures/mdn-admins@mozilla.org">mdn-admins メーリングリスト</a>を使用してください)。これを取得したら、いくつかの方法で新しいページを作成することができます：</p>
+
+<ul>
+ <li>いずれのページでも、ギアメニューの [新しいサブ記事] オプションを使用して新しいサブページを作成できます。<img alt="options or gear menu on mdn, which includes the new sub-article option " src="https://mdn.mozillademos.org/files/15912/171EA6E3-FEA6-4B2D-AFF7-31E52A1FEA09.png" style="border-style: solid; border-width: 1px; display: block; height: 300px; margin: 0px auto; width: 233px;"></li>
+ <li>また、マクロ呼び出しで作成された赤いリンク (まだ存在しないページへのリンク。例えば a \{{domxref()}}) をたどって新しいページを作成することもできます</li>
+</ul>
+
+<p>これは新しいページの UI で、そこで新しいページへのコンテンツの入力を開始できます。</p>
+
+<h2 id="How_to_use_the_templates" name="How_to_use_the_templates">テンプレートの使い方</h2>
+
+<p>When creating a new page you can ensure that you've used the right page structure/contents by using one of our page templates (see the sections below).</p>
+
+<p>These page templates don't make much sense as published pages, but if you view them in edit view you'll see that they contain a lot of helpful comments, placeholders, and hints detailing how to fill in the missing information and create your page.</p>
+
+<p>At the top of each template you'll find a section entitled <em>Remove before publishing</em> — this contains information on how to fill in the page title, slug, sidebar menu, and tags (e.g. information that doesn't actually appear in the body of the article). You need to delete this section after you've followed the instructions in it, before the page can be considered finished.</p>
+
+<p>To use a template, currently you just have to copy the source of the template out of its edit view and paste the contents into the <em>New document</em> page you are creating your new article in. In the future, we hope to update the editor UI to allow you to choose templates directly from there.</p>
+
+<h2 id="Old-style_page_layouts" name="Old-style_page_layouts">古い形式のページレイアウト</h2>
+
+<p>Sometimes you will come across old-style reference pages that look markedly different from the templates presented here. For example, old-style interface pages had all the interfaces' member details on a single page, and individual method/property/constructor/event listener pages didn't exist.</p>
+
+<p>If you come across an old-style set of pages, we'd love for you to update them to the new style! However, we do appreciate that this could be a large amount of work. If the information to update is not too large, and you have some free time, by all means try updating it to the new style.</p>
+
+<p>If the work is more significant, then you should consider a few factors when prioritising the work:</p>
+
+<ul>
+ <li>How out-of-date is the information?</li>
+ <li>How low quality is the information?</li>
+ <li>How popular is the feature? How sought after is the information?</li>
+</ul>
+
+<p>If you want to get a team together to work on an update, or you just want to report or discuss some content needing an update, <a href="https://discourse.mozilla.org/c/mdn">send us a message on discourse</a>.</p>
+
+<h2 id="API_landing_page" name="API_landing_page">API ランディングページ</h2>
+
+<p>An <strong>{{Glossary("API")}} landing page</strong> provides an overview of what a particular API does, as well as links to the documentation for each of the interfaces, globals, functions, etc. offered by the API. It does not link directly to specific methods or properties within the API's classes, except in the context of the overview text. It is primarily a <em>navigation</em> page, but also functions as an at-a-glance <em>reference</em> page for the API.</p>
+
+<p>There are some instances where multiple APIs exist that are distinct, and are defined in their own specifications, but they closely related and therefore would make sense to cover with a single API landing page. For example, the <a href="https://www.w3.org/TR/generic-sensor/">Generic Sensor API</a> cover general sensor concerns, but more specific concerns are covered in other APIs such as <a href="https://www.w3.org/TR/ambient-light/">Ambient Light Sensor</a>, <a href="https://www.w3.org/TR/motion-sensors/">Motion Sensor</a>, etc. In such cases, many of the high level concepts are the same, so it makes no sense to repeat those over multiple landing pages. In such a case, it would make more sense in terms of repetition and findability to cover them all under a single "Web sensors" landing page.</p>
+
+<h3 id="Example" name="Example">例</h3>
+
+<ul>
+ <li><a href="/ja/docs/Web/API/WebVR_API">WebVR API</a></li>
+</ul>
+
+<h3 id="Templates" name="Templates">テンプレート</h3>
+
+<ul>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/API_landing_page_template">API landing page template</a></li>
+</ul>
+
+<h2 id="API_reference_page" name="API_reference_page">API リファレンスページ</h2>
+
+<div class="note">
+<p><strong>メモ:</strong> Also known as an <em>Interface landing page.</em></p>
+</div>
+
+<p>An <strong>API reference page</strong> lists all the methods, properties, events, and so forth that are members of a particular interface or class. It provides an overview of what the class or interface does or is used for, and gives links to the documentation for each of these members. It is more granular than an API landing page, which typically links to multiple API reference pages.</p>
+
+<h3 id="Example_2" name="Example_2">例</h3>
+
+<ul>
+ <li><a href="/ja/docs/Web/API/Request">Request interface</a> of the <a href="/ja/docs/Web/API/Fetch_API">Fetch API</a>.</li>
+</ul>
+
+<h3 id="Templates_2" name="Templates_2">テンプレート</h3>
+
+<ul>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/API_reference_page_template">API reference page template</a></li>
+</ul>
+
+<h2 id="API_reference_subpage" name="API_reference_subpage">API リファレンスサブページ</h2>
+
+<p>An <strong>API reference subpage</strong> is a child of an API reference page. It documents a single interface member in detail.</p>
+
+<h3 id="Examples" name="Examples">例</h3>
+
+<ul>
+ <li><a href="/ja/docs/Web/API/IDBIndex/count"><code>count()</code> method</a> of the <a href="/ja/docs/Web/API/IDBIndex">IDBIndex</a> interface (part of the <a href="/ja/docs/Web/API/IndexedDB_API">IndexedDB API</a>)</li>
+ <li><a href="/ja/docs/Web/API/VRDisplay/capabilities">capabilities property</a> of the <a href="/ja/docs/Web/API/VRDisplay">VRDisplay</a> interface (part of the <a href="/ja/docs/Web/API/WebVR_API">WebVR API</a>)</li>
+ <li><a href="/ja/docs/Web/API/Request/Request">Request() constructor</a> of the <a href="/ja/docs/Web/API/Request">Request</a> interface (part of the <a href="/ja/docs/Web/API/Fetch_API">Fetch API</a>)</li>
+ <li><a href="/ja/docs/Web/API/Window/onvrdisplaypresentchange">onvrdisplaypresentchange event handler</a> (part of the <a href="/ja/docs/Web/API/WebVR_API">WebVR API</a>, which hangs off the <a href="/ja/docs/Web/API/Window">Window</a>) interface</li>
+</ul>
+
+<h3 id="Templates_3" name="Templates_3">テンプレート</h3>
+
+<ul>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/API_method_subpage_template">API method subpage template</a></li>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/API_property_subpage_template">API property subpage template</a></li>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/API_constructor_subpage_template">API constructor subpage template</a></li>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/API_event_subpage_template">API event subpage template</a></li>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/API_event_handler_subpage_template">API event handler subpage template</a></li>
+</ul>
+
+<h2 id="HTML_element_reference_page" name="HTML_element_reference_page">HTML 要素リファレンスページ</h2>
+
+<p>An <strong>HTML reference page</strong> lists all the attributes that are available on an HTML element, explains the element's purpose and usage, and provides examples, browser compatibility information, and other important data.</p>
+
+<h3 id="Example_3" name="Example_3">例</h3>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTML/Element/ol"><code>&lt;ol&gt;</code> element</a></li>
+</ul>
+
+<h3 id="Templates_4" name="Templates_4">テンプレート</h3>
+
+<ul>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/HTML_element_page_template">HTML element page template</a></li>
+</ul>
+
+<h2 id="SVG_element_reference_page" name="SVG_element_reference_page">SVG 要素リファレンスページ</h2>
+
+<p>An <strong>SVG reference page</strong> lists all the attributes that are available on an SVG element, explains the element's purpose and usage, and provides examples, browser compatibility information, and other important data.</p>
+
+<h3 id="Example_4" name="Example_4">例</h3>
+
+<ul>
+ <li><a href="/ja/docs/Web/SVG/Element/g">&lt;g&gt; element</a></li>
+</ul>
+
+<h3 id="Templates_5" name="Templates_5">テンプレート</h3>
+
+<ul>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/SVG_element_page_template">SVG element page template</a></li>
+</ul>
+
+<h2 id="CSS_feature_reference_page" name="CSS_feature_reference_page">CSS 特性リファレンスページ</h2>
+
+<p>A <strong>CSS reference page</strong> lists all the available syntax for a CSS feature such as a selector or property, and explains the feature's purpose and usage. It also provides examples, browser compatibility information, and other important data.</p>
+
+<h3 id="Examples_2" name="Examples_2">例</h3>
+
+<ul>
+ <li><a href="/ja/docs/Web/CSS/background-color">background-color property</a></li>
+ <li><a href="/ja/docs/Web/CSS/:hover">:hover pseudo-class</a></li>
+ <li><a href="/ja/docs/Web/CSS/@media">@media at-rule</a></li>
+</ul>
+
+<h3 id="Templates_6" name="Templates_6">テンプレート</h3>
+
+<ul>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/CSS_property_page_template">CSS property page template</a></li>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/CSS_selector_page_template">CSS selector page template</a></li>
+</ul>
+
+<h2 id="HTTP_header_reference_page" name="HTTP_header_reference_page">HTTP ヘッダーリファレンスページ</h2>
+
+<p>An <strong>HTTP header reference page</strong> lists all the available directives that an HTTP header can contain, and explains the header's purpose and usage. It also provides examples, browser compatibility information, and other important expl.</p>
+
+<h3 id="Example_5" name="Example_5">例</h3>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/Headers/Cache-Control">Cache-Control header</a></li>
+</ul>
+
+<h3 id="Templates_7" name="Templates_7">テンプレート</h3>
+
+<ul>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/HTTP_header_page_template">HTTP header page template</a></li>
+</ul>
+
+<h2 id="Conceptual_page" name="Conceptual_page">概念のページ</h2>
+
+<p>A <strong>conceptual page</strong> is a <em>guide</em> page that explains or teaches something. Generally, if a page contains primarily prose, and doesn't fall into another page type, it's probably a conceptual page. An extended discussion of a topic might be spread across multiple conceptual pages, and linked using <a href="https://github.com/mdn/kumascript/blob/master/macros/Next.ejs">Next</a> and <a href="https://github.com/mdn/kumascript/blob/master/macros/Previous.ejs">Previous</a> macros.</p>
+
+<h3 id="Examples_3" name="Examples_3">例</h3>
+
+<ul>
+ <li><a href="/ja/docs/Web/API/WebVR_API">Using the WebVR API</a></li>
+ <li><a href="/ja/docs/Web/API/Web_Audio_API">Creating visualizations with the Web Audio API</a></li>
+ <li><a href="/ja/docs/Learn/CSS/Introduction_to_CSS/Cascade_and_inheritance">Cascade and inheritance in CSS</a></li>
+</ul>
+
+<h2 id="Glossary_page" name="Glossary_page">用語集のページ</h2>
+
+<p>A <strong>glossary page</strong> contains a brief explanation of a term, topic, or concept. The first paragraph should be a simple, self-contained description of the term, no more than a couple sentences. This can be followed by links to further information in the <strong>Learn more</strong> section. If the page grows to more than a screenful or so, it's too long and should be converted to a conceptual page. See <a href="/ja/docs/MDN/Contribute/Howto/Write_a_new_entry_in_the_Glossary">How to write and reference an entry in the glossary</a> for more details.</p>
+
+<h3 id="Examples_4" name="Examples_4">例</h3>
+
+<ul>
+ <li><a href="/ja/docs/Glossary/DOM">DOM</a></li>
+ <li><a href="/ja/docs/Glossary/Exception">Exception</a></li>
+ <li><a href="/ja/docs/Glossary/Hyperlink">Hyperlink</a></li>
+</ul>
+
+<h3 id="Templates_8" name="Templates_8">テンプレート</h3>
+
+<ul>
+ <li><a href="/ja/docs/MDN/Contribute/Structures/Page_types/Glossary_page_template">Glossary page template</a></li>
+</ul>
+
+<h2 id="Landing_page" name="Landing_page">ランディングページ</h2>
+
+<p>A <strong>landing page</strong> serves as a menu, of sorts, for its subpages, and is therefore primarily a <em>navigation</em> page. A landing page layout is typically used for the root page of a tree of pages about a particular topic. It opens with a brief summary of the topic, then presents a structured list of links to its subpages, and optionally, additional material that be useful to the reader.</p>
+
+<p>The list of subpages can be generated automatically using the templates {{TemplateLink("SubpagesWithSummaries")}}, {{TemplateLink("SubpageMenuByCategories")}}, and {{TemplateLink("LandingPageListSubpages")}}. However, in more complex cases, the list may need to be created (and maintained!) by hand.</p>
+
+<p>If you use one of the page list macros, it may be worthwhile to edit the page properties and set a non-zero value for "Rendering max age." This value is the maximum amount of time that MDN will let elapse between fully re-rendering the page, including re-running all macros. By setting an appropriate, reasonable time you can help ensure that the landing page is never out of date for more than a short time.</p>
+
+<p>Choose an interval that makes sense based on the likelihood of the content to change. For an area which is under constant work, such as a new API in the process of being documented, a low value such as 2 hours could make sense. The value should be higher if the content won't change often; 3 days, for example.</p>
+
+<p>Try to remember to reset the interval to 0 hours, 0 minutes, and 0 seconds once the content reaches a relatively stable state, to let MDN cache the pages over a longer period of time.</p>
+
+<h3 id="Examples_5" name="Examples_5">例</h3>
+
+<ul>
+ <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/API">Web APIs</a></li>
+ <li><a href="/ja/docs/Web/JavaScript">JavaScript</a></li>
+ <li><a href="/ja/docs/Learn">Learning area</a></li>
+ <li><a href="/ja/docs/MDN/Contribute">Contributing to MDN</a></li>
+</ul>
diff --git a/files/ja/mdn/structures/quicklinks/index.html b/files/ja/mdn/structures/quicklinks/index.html
new file mode 100644
index 0000000000..b5c001a827
--- /dev/null
+++ b/files/ja/mdn/structures/quicklinks/index.html
@@ -0,0 +1,68 @@
+---
+title: クイックリンク
+slug: MDN/Structures/Quicklinks
+tags:
+  - Guide
+  - MDN Meta
+  - Structures
+  - ガイド
+  - 構造
+translation_of: MDN/Structures/Quicklinks
+---
+<div>{{MDNSidebar}}</div>
+
+<p><span class="seoSummary">MDN はページへのクイックリンクの追加に対応しています。これらのボックスは、 MDN 上の他のページやサイト外のページへの階層的なリストを含むことができます。この記事では、クイックリンクボックスの生成方法を解説します。</span></p>
+
+<p>ページには、左側のサイドバーに表示されるクイックリンクボックスが1つしかない場合があります。このサイドバーは、任意で、ユーザーがサイドバーの上部にある「このサイドバーを隠す」リンクをクリックすることで非表示にすることができます。</p>
+
+<h2 id="Quicklinks_syntax" name="Quicklinks_syntax">クイックリンクの構文</h2>
+
+<p>ページのクイックリンクは、 "Quick_Links" という ID を持つ {{HTMLElement("section")}} ブロックを作成することによって提供されます。次に、セクション内のクイックリンクボックスに入るコンテンツを配置します。これらは {{HTMLElement("ol")}} 順序付きリスト (ネストも可) として整形する必要があります。これは、エディターツールバーの番号付きリストボタンを使用して行うことができます。たとえば、このページにはいくつかの便利なページにつながるクイックリンクボックスがあります。その HTML は次のようになります。</p>
+
+<pre class="brush: html notranslate">&lt;section id="Quick_Links"&gt;
+  &lt;ol&gt;
+    &lt;li&gt;&lt;a href="http://docs.ckeditor.com/"&gt;CKEditor documentation site&lt;/a&gt;&lt;/li&gt;
+    &lt;li&gt;&lt;a href="http://mxr.mozilla.org/"&gt;MXR: Mozilla source cross-reference&lt;/a&gt;&lt;/li&gt;
+    &lt;li class="toggle"&gt;
+      &lt;details&gt;&lt;summary&gt;Style guides&lt;/summary&gt;
+      &lt;ol&gt;
+        &lt;li&gt;&lt;a href="http://www.economist.com/research/StyleGuide/"&gt;The Economist style guide&lt;/a&gt;&lt;/li&gt;
+        &lt;li&gt;&lt;a href="http://www.amazon.com/gp/product/0226104036/"&gt;The Chicago manual of style&lt;/a&gt;&lt;/li&gt;
+        &lt;li&gt;&lt;a href="http://www.answers.com/library/Dictionary"&gt;Answers.com dictionary&lt;/a&gt;&lt;/li&gt;
+        &lt;li&gt;&lt;a href="http://www.wsu.edu/~brians/errors/"&gt;Common Errors in English&lt;/a&gt;&lt;/li&gt;
+      &lt;/ol&gt;
+      &lt;/details&gt;
+    &lt;/li&gt;
+  &lt;/ol&gt;
+&lt;/section&gt;
+</pre>
+
+<p>注意すべき重要事項:</p>
+
+<ul>
+ <li>リストは順序付きリストである<strong>べき</strong>です。</li>
+ <li>別な順序付きリストを含んだ {{HTMLElement("details")}} を同じ {{HTMLElement("li")}} ブロックの<strong>中</strong>で使用すると、階層構造のリストを持つことができます。</li>
+</ul>
+
+<h2 id="Using_macros_to_create_quicklinks" name="Using_macros_to_create_quicklinks">クイックリンクを生成するマクロの使用</h2>
+
+<p class="mainArticle" style=""><em>メイン記事: <a href="/ja/docs/MDN/Contribute/Howto/Use_navigation_sidebars">ナビゲーションサイドバーを使うには</a></em></p>
+
+<p>言うまでもなく、マクロを使用してクイックリンクを生成することができます (また、しばしば<strong>するべき</strong>です)。複数のページで同じクイックリンクを使用する必要がある場合は、マクロにするべきです。たとえば、このページでは {{TemplateLink("MDNSidebar")}} マクロを使用してクイックリンクボックスを生成しています。 <a href="/ja/docs/Project:MDN/Contributing/Editor_guide">MDN エディターガイド</a>の他の各ページも同様です。</p>
+
+<p>マクロは、必要に応じて単純なものでも複雑なものでもかまいません。上記の{{anch("Quicklinks_syntax", "クイックリンクの構文")}}と同様の HTML を出力するだけです。</p>
+
+<h3 id="Standard_quicklinks_macros" name="Standard_quicklinks_macros">標準のクイックリンクマクロ</h3>
+
+<p>私たちのクイックリンクを生成する標準マクロの一覧です。</p>
+
+<dl>
+ <dt>{{TemplateLink("CSSRef")}}</dt>
+ <dd>CSS リファレンスページの標準クイックリンクを作成します。</dd>
+ <dt>{{TemplateLink("HTMLRef")}}</dt>
+ <dd>HTML リファレンスページの標準クイックリンクを作成します。</dd>
+ <dt>{{TemplateLink("MakeSimpleQuicklinks")}}</dt>
+ <dd>MDN 上のページのリストが与えられた場合、このマクロは、ページのタイトルをリンクテキストとして使用し、その概要をツールチップとして使用するクイックリンクボックスを作成します。これは階層リストを作成しません。</dd>
+ <dt>{{TemplateLink("QuickLinksWithSubpages")}}</dt>
+ <dd>現在のページ (または指定したページ) の子を宛先として使用して、クイックリンクのセットを作成します。これにより、最大2レベルの階層リストが作成されます。ページのタイトルをリンクテキストとして使用し、その概要をツールチップとして表示します。</dd>
+</dl>
diff --git a/files/ja/mdn/structures/specification_tables/index.html b/files/ja/mdn/structures/specification_tables/index.html
new file mode 100644
index 0000000000..924d8e10dd
--- /dev/null
+++ b/files/ja/mdn/structures/specification_tables/index.html
@@ -0,0 +1,82 @@
+---
+title: 仕様書表
+slug: MDN/Structures/Specification_tables
+tags:
+  - Guide
+  - MDN Meta
+  - Structures
+translation_of: MDN/Structures/Specification_tables
+---
+<div>{{MDNSidebar}}</div>
+
+<div>{{IncludeSubnav("/ja/docs/MDN")}}</div>
+
+<p>MDN 上のすべてのリファレンスページでは、 API または技術が定義されている仕様書に関する情報を提供するようにしてください。この記事ではこれらの表の外見を示し、構築方法を説明します。</p>
+
+<p>このような表は、少し<a href="/ja/docs/MDN/Contribute/Structures/Compatibility_tables">互換性一覧表</a> (こちらも仕様書表があるすべてのページで示すようにしてください) と似ています。</p>
+
+<h2 id="Format" name="Format">書式</h2>
+
+<p>仕様書表は、従来から3つの列で構成されています。</p>
+
+<dl>
+ <dt>仕様書</dt>
+ <dd>その技術が定義されている仕様書の名前やリンクです。</dd>
+ <dt>状態</dt>
+ <dd>仕様書の状態です (例えば、編集者草稿であるか勧告候補であるかなど)。</dd>
+ <dt>備考</dt>
+ <dd>関連する何らかの追加情報です。これは特に、 API が複数の仕様書にまたがって定義された場合に有用で、それぞれの仕様書が API のどの部分のもとになっているのかを短く説明することができます。</dd>
+</dl>
+
+<p>MDN で見られる大部分の表は上記の列から構成されていますが、構造を更新する進行中の計画があり、あちこちで異なる構造のものを見かけることがあるかもしれませんが、最終的な目標は<a href="https://github.com/mdn/browser-compat-data">ブラウザー互換データリポジトリ</a>に仕様書の定義のリンクを格納して、そこから表を自動生成させることです。公開議論の文書は <a href="https://docs.google.com/document/d/1eL8YtslVZAnIAGb7rcZGbvXndkcR7lb9rhDpvGpGaWs/edit#">Improving MDN Specification tables</a> にあります。</p>
+
+<h2 id="Which_specs_should_be_included" name="Which_specs_should_be_included">どの仕様書を含めるべきか</h2>
+
+<p>表の中では1行あたり1件の API または技術が基づく仕様書が記述されます。</p>
+
+<p>それぞれの表にどの仕様書を含めるかは、どの機能が当該リファレンスページで記述されているかによります。</p>
+
+<ul>
+ <li>ある仕様書の単一機能についての記述である場合、普通、その機能を定義している最新の仕様書を記述した1行を含めることだけが必要です。例えば <a href="/ja/docs/Web/API/AudioContext/close#Specifications"><code>AudioContext.close()</code> の仕様書</a>のような書き方です。</li>
+ <li>複数の仕様書で定義された複数の部分 API のランディングページ (拡張機能など) である場合、参照している複数の仕様書を複数行にわたって記述する必要があります。簡潔で明確な例としては <a href="/ja/docs/Web/API/Gamepad_API#Specifications">Gamepad API の仕様書</a>を参照して下さい。</li>
+</ul>
+
+<h3 id="Different_types_of_specs" name="Different_types_of_specs">様々な種類の仕様書表</h3>
+
+<p>「ライブ仕様書」で定義された技術 (例えば、<a href="https://html.spec.whatwg.org/multipage/">HTML</a> や <a href="https://dom.spec.whatwg.org/">DOM</a>) の場合、おそらくリンクする必要があるのは単一の仕様書だけであり、その技術が定義されている正式な単一の場所としてのものです。</p>
+
+<p>他の仕様書表 (通常は WebAPI 仕様書) では、常に最新の編集者草稿を指す単一の URL を、仕様書ごとに (同じ仕様書とは限らないが) 入れる必要があるのが普通でしょう。このような場合、普通は最新の編集者草稿にリンクしたほうが、仕様書が変更された時にリンクが正しくあり続けます。 — 最新の編集者草稿は、最新の機能がすべて定義されており、ブラウザーベンダーがよりどころとしているものです。したがって、これはリンクするのに最も興味深い場所であり、多くの場合は最新情報です。この例としては、 <a href="https://w3c.github.io/IndexedDB/">IndexedDB draft</a>, <a href="https://webaudio.github.io/web-audio-api/">Web Audio API draft</a>, 等があります。最新の草稿へのリンクが、仕様書表の一番上に見られます。</p>
+
+<p>他の仕様書表には、一つの仕様書で定義された中心機能がありますが、機能が拡張されることがあり、例えば、 Credential Management 仕様書は Web Authentication 仕様書によって拡張されています (<a href="/ja/docs/Web/API/Credential_Management_API#Specifications">仕様書表を見る</a>)。</p>
+
+<p>CSS の仕様書表については、そのように単純ではありません。 — CSS の仕様書はふつう、新しい機能を導入する複数のレベルに分割されています。 — 例えば、 <a href="https://drafts.csswg.org/mediaqueries-4/">Media Queries Level 4</a> と <a href="https://drafts.csswg.org/mediaqueries-5/">Media Queries Level 5</a> といった具合です。多くの場合、複数の仕様書にリンクして、機能の動作が定義されているすべての場所を示す必要があります。</p>
+
+<p>MDN に仕様書表を追加するとき (方法は以下参照)、上記の考えを意識しておいてください。ライブの仕様書を表現するには技術の名前のみです (例えば "HTML")。最新の仕様書の草稿は <em>WebAPI 名</em>草稿とします (例えば "IndexedDB 草稿")。複数の仕様書が必要な場合は、仕様書の正確な名前を使用してください。</p>
+
+<h3 id="What_not_to_include" name="What_not_to_include">含めるべきではないもの</h3>
+
+<p>MDN の多くの仕様書表が、ある機能を定義したすべての仕様書を過去にさかのぼって含めています。例えば、 <a href="/ja/docs/Web/CSS/color#Specifications">CSS の color プロパティの仕様書表</a>のようにです。これは CSS レベル1まですべてをさかのぼっていますが、おそらく表の下3行は必要ないでしょう。色がアニメーション可能であることについての部分を除いて、レベル4ですべてが定義されています。</p>
+
+<p>特に、廃止とされた仕様書を参照する必要はありません。これは役に立ちません。</p>
+
+<p>また、 <a href="https://www.w3.org/2019/04/WHATWG-W3C-MOU.html#transition">W3C が WHATWG Living Standard で扱っている技術仕様書のスナップショットの発行をやめることに合意しました</a>。 — 両方で扱っていた技術については、 WHATWG の仕様書を並べるだけでよくなります。</p>
+
+<h2 id="Macros" name="Macros">マクロ</h2>
+
+<p>これらの表を、適切な書式で標準の書式で構築しやすくするために、 KumaScript マクロを使用しています。使い方を知っておく必要がある物は2つあります。</p>
+
+<h3 id="SpecName" name="SpecName"><code>\{{SpecName}}</code></h3>
+
+<p>{{TemplateLink("SpecName")}} マクロは、「仕様書」列の内容を生成するために使います。3つの引数を受け付けます。</p>
+
+<ol>
+ <li>仕様書の名前。</li>
+ <li>任意で、リンクされた仕様書内のアンカー。これは、例えば複数のオブジェクトやインターフェイスを定義している仕様書の中で、特定の章にリンクできるようになります。なお、この引数は任意ですが、強く推奨します。読み手は生成されたリンクをクリックしたとき、仕様書のその概念が定義されている詳細な位置に届くことを期待するからです。</li>
+ <li>ツールチップ内で使用するプロパティまたはエンティティの名前です。これは、仕様書内で特定のインターフェイスにリンクする時にも使用されます。この引数も任意ですが、追加して概念の名前を設定することを強く推奨します。</li>
+</ol>
+
+<p>仕様書に指定する名前は、マクロ内の <code>specList</code> オブジェクトで見られます。リンクしたい仕様書にマクロが対応していない場合、 <a href="https://github.com/mdn/kumascript/blob/master/macros/SpecData.json">SpecData</a> ファイルを更新するプルリクエストを提案してください。</p>
+
+<h3 id="Spec2" name="Spec2"><code>\{{Spec2}}</code></h3>
+
+<p>{{TemplateLink("spec2")}} マクロは、指定されれた仕様書の名前から、「状態」列で仕様書の状態を示すウィジェットを生成し挿入します。こちらも <a href="https://github.com/mdn/kumascript/blob/master/macros/SpecData.json">SpecData</a> ファイルからデータを取得します。こちらも、リンクしたい仕様書にマクロが対応していない場合は、プルリクエストを提案してください。</p>
diff --git a/files/ja/mdn/structures/syntax_sections/index.html b/files/ja/mdn/structures/syntax_sections/index.html
new file mode 100644
index 0000000000..19b5bf3ee1
--- /dev/null
+++ b/files/ja/mdn/structures/syntax_sections/index.html
@@ -0,0 +1,250 @@
+---
+title: 構文の節
+slug: MDN/Structures/Syntax_sections
+tags:
+  - API
+  - CSS
+  - HTML
+  - MDN Meta
+  - Structure
+  - Syntax
+  - onboarding
+  - 進行中
+translation_of: MDN/Structures/Syntax_sections
+---
+<div>{{MDNSidebar}}</div>
+
+<p class="summary">MDN リファレンスページの構文の節には、機能が持つ正確な構文を定義する構文ボックスがあります (例えば、どのような引数が受け入れられるか、どれがオプションかなど)。この記事では、リファレンス記事の構文ボックスの書き方を説明します。</p>
+
+<h2 id="API_reference_syntax" name="API_reference_syntax">API リファレンスの構文</h2>
+
+<p>API リファレンスページの構文の節は手作業で書かれ、設置するページの種類によって異なります。しかし、共通事項もあります。いずれも節には「構文」という題名を付け、リファレンスページの最上部、導入部分のすぐ下に設置します。</p>
+
+<p>加えて、それぞれの構文の節はその機能の正確な構文を紹介する「構文」ブロックを、 "Syntax Box" ブロックスタイルを使用してスタイル付けしたもので始める必要があります。</p>
+
+<pre class="syntaxbox notranslate">A syntax block example</pre>
+
+<h3 id="General_style_rules" name="General_style_rules">全般的なスタイル規則</h3>
+
+<p>構文ブロック内をマークアップするために従うべき規則がいくつかあります。</p>
+
+<ul>
+ <li>構文ブロック内では (MDN のコード例の中でも) {{HTMLElement("code")}} を使用<em>しない</em>でください。これは一般的に意味がないだけでなく、これを含めると望み通りの表示が行われないので、マークアップしてほしくありません。</li>
+ <li>
+  <p>構文ブロック内でプログラマーに依存する部分は、 {{HTMLElement("em")}} を使用してイタリック体にしてください (エディターのツールバーの「斜体」ボタン)。</p>
+
+  <pre class="syntaxbox notranslate"><em>responseStr</em> = <em>element</em>.querySelector(<em>selector</em>);</pre>
+
+  <p>ここで、 <code>responseStr</code> は返値 (開発者が付ける変数名) であり、 <code>element</code> は {{DOMxRef("Element")}} オブジェクトを参照する変数のプレイスホルダーであり、 <code>selector</code> はメソッドの入力引数のプレイスホルダーです。</p>
+
+  <p>ページによっては <code>&lt;var&gt;</code> が <code>&lt;em&gt;</code> の代わりに使用されているのを見かけるかもしれません。これでも良いのですが、一般に <code>&lt;em&gt;</code> を推奨します。</p>
+ </li>
+</ul>
+
+<h3 id="Constructors_and_methods" name="Constructors_and_methods">コンストラクターやメソッドの場合</h3>
+
+<h4 id="Syntax_block" name="Syntax_block">構文ブロック</h4>
+
+<p>構文ブロックは、次のように始めてください ({{DOMxRef("IntersectionObserver.IntersectionObserver", "IntersectionObserver constructor")}} ページを参照)。</p>
+
+<pre class="syntaxbox notranslate">var <em>observer</em> = new IntersectionObserver(<em>callback</em>, <em>options</em>);</pre>
+
+<p>または、次のようにします ({{DOMxRef("WindowOrWorkerGlobalScope.fetch")}} を参照)。</p>
+
+<pre class="syntaxbox notranslate"><em>promiseResponse</em> = fetch(<em>input</em>, <em>init</em>);</pre>
+
+<p>構文は形式文法の表記を使用して書かれることもあります。例えば以下の {{jsxref("Array.prototype.slice()")}} を参照してください。</p>
+
+<pre class="syntaxbox notranslate">arr.slice([begin[, end]])</pre>
+
+<p>角括弧は内部の引数が省略可能であることを表します。これは読者の多くを混乱させるため、推奨しません。代わりに角括弧を外して、構文ブロックの下にある<em>引数</em>の節で、これらの引数が省略可能であることを説明したほうがいいでしょう。</p>
+
+<h5 id="Multiple_lines" name="Multiple_lines">複数行での表記</h5>
+
+<p>メソッドが複数の形式で使用されることがあるため、複数の行で記述したい場合があるでしょう。例えば、この ({{DOMxRef("CanvasRenderingContext2D.drawImage")}}) の例をご覧ください。</p>
+
+<pre class="syntaxbox notranslate">void <em>ctx</em>.drawImage(<em>image</em>, <em>dx</em>, <em>dy</em>);
+void <em>ctx</em>.drawImage(<em>image</em>, <em>dx</em>, <em>dy</em>, <em>dWidth</em>, <em>dHeight</em>);
+void <em>ctx</em>.drawImage(<em>image</em>, <em>sx</em>, <em>sy</em>, <em>sWidth</em>, <em>sHeight</em>, <em>dx</em>, <em>dy</em>, <em>dWidth</em>, <em>dHeight</em>);</pre>
+
+<p><code>slice()</code> の構文の例も、すべての変化形を表示し理解しやすくするために、次のように書き直すことができます。</p>
+
+<pre class="syntaxbox notranslate"><var>arr</var>.slice()<var>
+arr</var>.slice(<var>begin</var>)
+<var>arr</var>.slice(<var>begin</var>, <var>end</var>)</pre>
+
+<p>他の複数行の例として、 {{jsxref("Date")}} コンストラクターのページでは、取りうる引数の組み合わせが全く異なる形でたくさんあることを示しています。</p>
+
+<pre class="syntaxbox notranslate">new Date();
+new Date(<var>value</var>);
+new Date(<var>dateString</var>);
+new Date(<var>year</var>, <var>monthIndex</var> [, <var>day</var> [, <var>hours</var> [, <var>minutes</var> [, <var>seconds</var> [, <var>milliseconds</var>]]]]]);
+</pre>
+
+<p>ただし前述の通り、角括弧を外し、<em>引数</em>の節で引数が省略可能であることを明確にするべきでしょう。</p>
+
+<h5 id="Concise_syntax_blocks" name="Concise_syntax_blocks">構文ブロックは簡潔に</h5>
+
+<p>構文ブロックを簡潔にし、その機能の構文の定義の曖昧さをなくすために — 無関係な構文を含めないでください。例えば、このサイトの多くの場所で、 Promise を説明するために次のような形をよく見かけます。</p>
+
+<pre class="syntaxbox notranslate"><em>caches</em>.match(<em>request</em>, <em>options</em>).then(function(<em>response</em>) {
+  // Do something with the response
+});</pre>
+
+<p>しかし、次のものははるかに簡潔で、余計な {{JSxRef("Promise.prototype.then()")}} メソッド呼び出しを含んでいません。</p>
+
+<pre class="syntaxbox notranslate"><em>promiseResponse</em> = <em>caches</em>.match(<em>request</em>, <em>options</em>);</pre>
+
+<h4 id="Parameters_section" name="Parameters_section">引数の項</h4>
+
+<p>次に、「引数」の項を設置して、それぞれの引数が何であるべきかを説明リストの形で説明してください。複数のメンバーを含むことができるオブジェクトの引数は、入れ子の説明リストで記述し、その中にそれぞれのメンバーが何であるべきかを記述してください。省略可能な引数は、説明する用語の名前の隣に \{{optional_inline}} マクロでマークしてください。</p>
+
+<p>リスト内の各引数の名前は {{HTMLElement("code")}} ブロックの中に含めてください。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: その機能が何も引数を取らない場合は、「引数」の項を設置する必要はありませんが、中身を「なし」として設置しても構いません。</p>
+</div>
+
+<h4 id="Return_value_section" name="Return_value_section">返値の項</h4>
+
+<p>その次に、「返値」の項を設置して、コンストラクターやメソッドの返値が何であるかを説明してください。 <code>undefined</code> の場合にも記述します。例については前述のリンクを参照して下さい。</p>
+
+<h4 id="Exceptions_section" name="Exceptions_section">例外の項</h4>
+
+<p>最後に、「例外」の項を設置して、コンストラクターやメソッドの呼び出し時に問題が発生した場合にどの例外が発生するかを説明してください。発生する原因としては、引数名の綴りが間違っていたり、間違ったデータ型の値が与えられたり、呼び出された環境に問題があったり (例えば、安全なコンテキストで実行する機能を安全でないコンテキストで実行しようとした場合など)、その他の理由であったりする場合などです。</p>
+
+<p>メソッドで発生する例外を特定するには、仕様を十分に精査する必要があります。機能がどのように動作するかについて、仕様書の1つ1つの説明を調べると、一般に例外とそれが発生する状況の確実な一覧を得ることができます。</p>
+
+<p>例外の名前と説明を説明リストに記述してください。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: その機能で発生する例外がない場合は「例外」の項を設置する必要はありませんが、中身を「なし」として設置しても構いません。</p>
+</div>
+
+<h3 id="Properties" name="Properties">プロパティの場合</h3>
+
+<h4 id="Syntax_block_2" name="Syntax_block_2">構文ブロック</h4>
+
+<p>次のように構文ブロックで始めてください ({{DOMxRef("IntersectionObserver.root")}} を参照)。</p>
+
+<pre class="syntaxbox notranslate"><var>var <em>root</em> = IntersectionObserver</var>.root;</pre>
+
+<p>読み取り専用のプロパティではない場合は、二行を使ってプロパティの取得と設定の両方を示すのもいいでしょう ({{DOMxRef("AudioParam.value")}} を参照)。</p>
+
+<pre class="syntaxbox notranslate"><em>gain</em> = <em>gainNode</em>.gain.value;
+<em>gainNode</em>.gain.value = 0;</pre>
+
+<h4 id="Value_section" name="Value_section">値の項</h4>
+
+<p>構文ブロックの下に「値」の項を設置する必要があり、そこでプロパティの値を — データ型とその用途について — 説明してください。</p>
+
+<h4 id="Exceptions_section_2" name="Exceptions_section_2">例外の項</h4>
+
+<p>プロパティにアクセスする際に例外が発生する可能性がある場合、「例外」の項を設置してそれぞれの例外を説明してください。これは前述のメソッドやコンストラクターの説明と同様のことをしてください。</p>
+
+<h3 id="Event_handlers" name="Event_handlers">イベントハンドラーの場合</h3>
+
+<p>イベントハンドラープロパティは確かにプロパティですが、構文の節の中ではいくらかの違いがあります。</p>
+
+<h4 id="Syntax_block_3" name="Syntax_block_3">構文ブロック</h4>
+
+<p>次のように構文ブロックで始めてください ({{DOMxRef("Window.onvrdisplaypresentchange")}} を参照)。</p>
+
+<pre class="syntaxbox notranslate"><em>window</em>.onvrdisplaypresentchange = <em>functionRef</em>;</pre>
+
+<p>以上で十分です。 — イベントハンドラープロパティは常に設定可能で、常に関数が設定されるため、これ以上の情報は不要です。</p>
+
+<h2 id="JavaScript_reference_syntax" name="JavaScript_reference_syntax">JavaScript リファレンスの構文</h2>
+
+<p>JavaScript 組込みオブジェクトのリファレンスページは、 API リファレンスページと同様の基本規則に従います。例えばメソッドやプロパティについてです。多少の違いが見られることがあります。</p>
+
+<ul>
+ <li>組込みオブジェクトで単一のコンストラクターを持つものは、コンストラクターの構文がオブジェクトのランディングページに含まれていることが良くあります。例えば {{JSxRef("Date")}} を参照してください。 (<code>Date</code> オブジェクト自身が持つ) 静的メソッドは、「メソッド」の下の「Date.prototype メソッド」で記述されていることが分かるでしょう。</li>
+ <li>また、引数も例外もないメソッドは、 JavaScript リファレンスページにこれらの節が全く含まれていないことに気が付くでしょう。例えば {{JSxRef("Date.getDate()")}} や {{JSxRef("Date.now()")}} を参照してください</li>
+</ul>
+
+<h2 id="CSS_reference_syntax" name="CSS_reference_syntax">CSS リファレンスの構文</h2>
+
+<h3 id="Properties_2" name="Properties_2">プロパティ</h3>
+
+<p>CSS プロパティページには「構文」の節があり、ふつうはページの先頭にありますが、次第に、機能の典型的な使用方法を示すブロックを含む節や、その機能が何を行うかを説明するライブデモ (例えば {{CSSxRef("animation")}} を参照) の下に見られるようになっています。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: このようにしているのは、 CSS の形式文法が複雑であり、 MDN の読者の多くが必要としておらず、初心者にとってとっつきにくいからです。実際の構文と例が多くの人にとってより有用です。</p>
+</div>
+
+<p>構文の節の中には、次のような内容が見られるでしょう。</p>
+
+<h4 id="Optional_explanation_text" name="Optional_explanation_text">説明文は任意</h4>
+
+<p>CSS プロパティによってはそれ自体が説明的であり、それ以上の説明が本当に必要ない場合があります (例えば {{CSSxRef("color")}})。一方、より複雑で、複数の値などを含む構文の順序の説明が必要なものもあります ({{CSSxRef("animation")}} を参照)。そのような場合、項が始まる前に追加の説明を加えることができます。</p>
+
+<h4 id="Values_section" name="Values_section">値の項</h4>
+
+<p>次に、「値」の項を入れてください。 — これには説明リストが入り、プロパティの値を構成する値の型を説明します。値の型はそれぞれ山括弧で囲み、その値の型を説明する MDN のリファレンスページがあれば、そこへリンクしてください。例えば、 {{CSSxRef("border")}} プロパティのリファレンスを参照してください。 — これは3つの値の型を参照しており、そのうちの一つ ({{CSSxRef("&lt;color&gt;")}}) だけがリンクになっています。</p>
+
+<h4 id="Formal_syntax" name="Formal_syntax">形式文法</h4>
+
+<p>最後の項、「形式文法」は <a href="https://github.com/mdn/data">MDN data リポジトリ</a>の CSS ディレクトリにあるデータから自動的に生成されます。タイトルの下で {{TemplateLink("CSSSyntax")}} マクロ呼び出しを記述するだけで、残りのことはマクロがやってくれます。</p>
+
+<p>唯一の問題は、必要なデータが存在することを確認することです。 <a href="https://github.com/mdn/data/blob/master/css/properties.json">properties.json</a> ファイルに、文書化しているプロパティの項目が含まれている必要があり、 <a href="https://github.com/mdn/data/blob/master/css/types.json">types.json</a> ファイルには、プロパティの値で使用されるすべての値の型の項目が含まれている必要があります。</p>
+
+<p>これを行うには、 <a href="https://github.com/mdn/data">MDN data リポジトリ</a>をフォークし、フォークをローカルにクローンし、新しいブランチに変更を行い、上流のリポジトリに向けてプルリクエストを送信してください。 <a href="/ja/docs/MDN/Contribute/Structures/Compatibility_tables#Preparing_to_add_the_data">Git の使用についての詳細はこちらにあります</a>。</p>
+
+<h3 id="Selectors" name="Selectors">セレクター</h3>
+
+<p>セレクターのリファレンスページの「構文」の節は、プロパティページよりもずっと簡潔です。ここには "Syntax Box" を使用してスタイル付けされたブロックが1つ入り、ここでセレクターの基本的な構文を、単純なキーワードだけ (例えば {{CSSxRef(":hover")}}) または引数を取るより複雑な関数値 (例えば {{CSSxRef(":not", ":not()")}}) のどちらかで示します。引数を構文ブロックの中の別な項目で説明している場合もあります (例えば {{CSSxRef(":nth-last-of-type", ":nth-last-of-type()")}} を参照してください)。</p>
+
+<p>このブロックは、 <a href="https://github.com/mdn/data">MDN data リポジトリ</a>の CSS ディレクトリにあるデータから自動的に生成されます。題名の下で {{TemplateLink("CSSSyntax")}} マクロ呼び出しを追加するだけで、残りのことはマクロがやってくれます。</p>
+
+<p>唯一の問題は、必要なデータが存在することを確認することです。 <a href="https://github.com/mdn/data/blob/master/css/selectors.json">selectors.json</a> ファイルに、文書化しているセレクターの項目が含まれている必要があります。</p>
+
+<p>これを行うには、 <a href="https://github.com/mdn/data">MDN data リポジトリ</a>をフォークし、フォークをローカルにクローンし、新しいブランチに変更を行い、上流のリポジトリに向けてプルリクエストを送信してください。 <a href="/ja/docs/MDN/Contribute/Structures/Compatibility_tables#Preparing_to_add_the_data">Git の使用についての詳細はこちらにあります</a>。</p>
+
+<h2 id="HTML_reference_syntax" name="HTML_reference_syntax">HTML リファレンスの構文</h2>
+
+<p>HTML リファレンスページには「構文」の節がありません。 — 構文は常に要素名を山括弧で囲んだものであるため、必要ないからです。 HTML 要素について主に知っておかなければならないことは、どのような属性を取りうるか、その値は何になるかであり、これは別の「属性」の節で扱います。例としては、 {{htmlelement("ol")}} や {{htmlelement("video")}} をご覧ください。</p>
+
+<h2 id="HTTP_reference_syntax" name="HTTP_reference_syntax">HTTP リファレンスの構文</h2>
+
+<p>HTTP リファレンスの構文はすべて手作業で作成され、文書化する HTTP の機能によって異なります。</p>
+
+<h3 id="HTTP_headersContent-Security-Policy" name="HTTP_headersContent-Security-Policy">HTTP ヘッダー/Content-Security-Policy</h3>
+
+<p>HTTP ヘッダーの構文 (および Content-Security-Policy) ページ上で二つの節に分けて記述します。 — 「構文」と「ディレクティブ」です。</p>
+
+<h4 id="Syntax_section" name="Syntax_section">構文の節</h4>
+
+<p>「構文」の節は、ヘッダーの構文がどのようなものかを、 "Syntax Box" スタイルを使用してスタイル付けされた構文ブロックを用いて、値にどのディレクティブが含まれるか、どのような順番かなどの形式文法を含めて示します。例えば、 {{HTTPHeader("If-None-Match")}} ヘッダーの構文ブロックは次のようになります。</p>
+
+<pre class="syntaxbox notranslate">If-None-Match: &lt;etag_value&gt;
+If-None-Match: &lt;etag_value&gt;, &lt;etag_value&gt;, …
+If-None-Match: *</pre>
+
+<p>ヘッダーによっては個別にリクエストディレクティブ、レスポンスディレクティブ、拡張構文があることがあります。存在する場合、それぞれの項の下にある個別の構文ブロックの中に設置する必要があります。例としては {{HTTPHeader("Cache-Control")}} をご覧ください。</p>
+
+<h4 id="Directive_section" name="Directive_section">ディレクティブの節</h4>
+
+<p>「ディレクティブ」の節には、構文に現れる可能性があるすべてのディレクティブの名前と解説を記述した説明リストを設定します。</p>
+
+<h3 id="HTTP_request_methods" name="HTTP_request_methods">HTTP リクエストメソッド</h3>
+
+<p>リクエストメソッドの構文は実に単純で、構文ブロックを設置し、 "Syntax Box" スタイルを用いてスタイル付けし、どのようにメソッドの構文を構成するかを示すだけです。 <a href="/ja/docs/Web/HTTP/Methods/GET">GET メソッド</a>の構文は次のようになります。</p>
+
+<pre class="syntaxbox notranslate">GET /index.html</pre>
+
+<h3 id="HTTP_response_status_codes" name="HTTP_response_status_codes">HTTP レスポンスステータスコード</h3>
+
+<p>HTTP レスポンスステータスコードの構文も、実に単純です。 — コードと名前を含む構文ブロックです。例えば次のようになります。</p>
+
+<pre class="syntaxbox notranslate">404 Not Found</pre>
+
+<h2 id="SVG_reference_syntax" name="SVG_reference_syntax">SVG リファレンスの構文</h2>
+
+<h3 id="SVG_elements" name="SVG_elements">SVG 要素</h3>
+
+<p>SVG 要素に構文の節は存在しません。 — HTML 要素の構文の節と同様です。それぞれの SVG 要素のリファレンスページは、その要素に適用することができる属性の一覧を含みます。例えば {{SVGElement("feTile")}} を参照してください。</p>
+
+<h3 id="SVG_attributes" name="SVG_attributes">SVG 属性</h3>
+
+<p>SVG 属性のリファレンスページにも、構文の節はありません。</p>
author	Peter Bengtsson <mail@peterbe.com>	2020-12-08 14:40:17 -0500
committer	Peter Bengtsson <mail@peterbe.com>	2020-12-08 14:40:17 -0500
commit	33058f2b292b3a581333bdfb21b8f671898c5060 (patch)
tree	51c3e392513ec574331b2d3f85c394445ea803c6 /files/ja/mdn/structures
parent	8b66d724f7caf0157093fb09cfec8fbd0c6ad50a (diff)
download	translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.gz translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.bz2 translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.zip