Remove Mozilla/Developer_guide (#691)

14 files changed, 0 insertions, 1557 deletions

diff --git a/files/ja/mozilla/developer_guide/build_instructions/how_mozilla_s_build_system_works/index.html b/files/ja/mozilla/developer_guide/build_instructions/how_mozilla_s_build_system_works/index.html
deleted file mode 100644
index 9737c6a793..0000000000
--- a/files/ja/mozilla/developer_guide/build_instructions/how_mozilla_s_build_system_works/index.html
+++ /dev/null
@@ -1,196 +0,0 @@
----
-title: How Mozilla's build system works
-slug: Mozilla/Developer_guide/Build_Instructions/How_Mozilla_s_build_system_works
-tags:
-  - Build documentation
-  - Developing Mozilla
-  - 移行
-original_slug: How_Mozilla's_build_system_works
----
-<h2 id=".E6.A6.82.E8.A6.81" name=".E6.A6.82.E8.A6.81">概要</h2>
-
-<p>本ドキュメントは、Mozilla の GNU make ベースビルドシステムを必要とする Mozilla 開発者をターゲットとしています。 本ドキュメントでは、ビルドシステムの基本概念と用語ならびに、コンポーネントのコンパイルや jar ファイルの作成といった共通的作業をどのように行うかを解説しています。</p>
-
-<p>本書は Mozilla をただビルドしたい人を対象にはしていません。その場合は<a href="/ja/docs/Build_Documentation">Build Documentation</a>を参照してください。</p>
-
-<h2 id=".E6.A6.82.E5.BF.B5" name=".E6.A6.82.E5.BF.B5">概念</h2>
-
-<p>Mozilla のビルドシステムは <a class="external" href="http://www.gnu.org/software/make/">GNU Make</a> をベースにしたシステムです。最も基本的なレベルでは、make は<em>ターゲット</em>を自動生成するツールで、ターゲットごとに<em>dependencies</em> と<em>rules</em> を生成します。</p>
-
-<p>Mozilla プロジェクトでは、make はライブラリと実行モジュールのコンパイル、chrome の jar ファイル作成、関係ファイルのコピーに使用されます。我々は、2 パスのビルドシステムを使用しています:</p>
-
-<ul>
- <li><strong>export</strong> フェーズでは、public ヘッダファイルを dist/include へコピーし、IDL ファイルから C++ ヘッダファイルを生成します。</li>
- <li><strong>libs</strong> フェーズでは、ライブラリをコンパイルし、 jar ファイルを作成し、IDL ファイルから typelib ファイルを作成します。</li>
-</ul>
-
-<p>いずれのフェーズでも、ターゲットを make するだけです。これは、それぞれのディレクトリは export ターゲットとともにまず一度横断し、libs ターゲットとともに、再び横断します。 二段階のビルドは、モジュール間の循環的参照のために存在します。最初にすべてのヘッダファイルを export することで、あるモジュール（Ａとする）は、別のモジュール（Ｂ）の public なヘッダファイルをインクルードしながら、モジュール（Ｂ）はモジュール（Ａ）の public なヘッダファイルをインクルードできます。</p>
-
-<p>その他の重要なツールとして、<strong>configure</strong> が挙げられます。これは、ビルドの最初のステップに実行されます。configure スクリプトはシステムやコンパイラの特徴を決定し、オプションを生成します。configure スクリプトから実行される重要な製品が二つあります:</p>
-
-<ul>
- <li>autoconf.mk ファイルは <a class="external" href="http://lxr.mozilla.org/seamonkey/source/config/autoconf.mk.in">autoconf.mk.in</a>から生成されます。このファイルは、グローバルなビルドオプションを制御する<em>make 変数</em> を含みます。</li>
- <li>Makefile ファイルは、ツリーの至る所にある Makefile.in ファイルから生成されます。ビルドを正確に行うため、Makefile.in 中に記述されたソースディレクトリの場所が置換されます。</li>
-</ul>
-
-<p>configure スクリプトは bash シェルベースのものです。このスクリプトは <a class="external" href="http://www.seindal.dk/rene/gnu/">M4</a> とともに書かれた <a class="external" href="http://lxr.mozilla.org/seamonkey/source/configure.in">configure.in</a> と呼ばれるファイルから生成され、最終的なスクリプトを生成するために <a class="external" href="http://www.gnu.org/software/autoconf/">Autoconf</a>を使って処理します。</p>
-
-<h2 id="Makefile_.E3.81.AE.E5.9F.BA.E7.A4.8E" name="Makefile_.E3.81.AE.E5.9F.BA.E7.A4.8E">Makefile の基礎</h2>
-
-<p>Makefile は、非常に複雑にもなり得ますが、Mozilla チームは、大半の Makefile をとてもシンプルにすべく、多数のビルトインルールを提供しています。make についての網羅的な解説は本説明の範囲を超えますので、<a class="external" href="http://www.gnu.org/software/make/manual/make.html">こちら（GNU make）</a>を参照してください。</p>
-
-<p>精通しておくとよいであろう概念の一つとして、make の<em>変数</em>が挙げられます。変数は<code>VARIABLE = VALUE</code> という構文で定義され、その値は<code>$(VARIABLE)</code> と記述することで参照されます。すべての変数は文字列です。</p>
-
-<p>Mozilla のソースコードに含まれる Makefile.in ファイルはすべて同じ基本的なフォーマットで記述されています。</p>
-
-<div>{{ page("/ja/docs/Standard_Makefile_Header") }}</div>
-
-<pre class="eval"># ... Makefile の中心となる本体部分がここに入ります ...
-</pre>
-
-<pre class="eval">include $(topsrcdir)/config/rules.mk
-
-# ... 追加のルールがここに入ります ...
-</pre>
-
-<ul>
- <li><strong>DEPTH</strong> 変数はMakefile.in から Mozilla ディレクトリの最上位への相対パスがセットされます。</li>
- <li><strong>topsrcdir</strong> は configure によって置換されます。これは Mozilla ディレクトリの最上位 を示します。</li>
- <li><strong>srcdir</strong> もまた、configure によって置換されます。これは、現在のディレクトリに対するソースファイルの場所を示します。ソースツリーからのビルドでは、この値は単に "."（カレントディレクトリ）を示すでしょう。</li>
- <li><strong>VPATH</strong> は、make が必須ファイル（例：ソースファイル）を探す対象ディレクトリの一覧です。</li>
-</ul>
-
-<p>この他によく使われる変数の一つとして、特定のビルドターゲットを指定しない <strong>DIRS</strong> があります。DIR は、現在のディレクトリを再帰的に組み込むためのサブディレクトリの一覧です。サブディレクトリは親ディレクトリの<strong>後に</strong>配置されます。以下に例を示します。</p>
-
-<pre class="eval">DIRS = \
-       public \
-       resources \
-       src \
-       $(NULL)
-</pre>
-
-<p>上記の例は、<em>行結合</em>の例でもあります。行の中の最後に現れるバックスラッシュ<span class="comment">（訳注：通常の日本の環境では￥記号に見えることも多いので注意）</span>は、変数定義が次の行にも続いていることを示します。行の継ぎ目の余分な空白は縮められます。終端の $(NULL) は表記に一貫性を持たせる手段です。これにより、行末のバックスラッシュの有無を気にせず行の追加・削除が行えます。</p>
-
-<h2 id="Makefile_examples" name="Makefile_examples">Makefile examples</h2>
-
-<ul>
- <li><a href="/ja/docs/Standard_Makefile_Header">Standard Makefile Header</a></li>
- <li><a href="/ja/docs/Installing_headers_using_EXPORTS">Installing headers using EXPORTS</a></li>
- <li><a href="/ja/docs/Compiling_interfaces_using_XPIDLSRCS">Compiling interfaces using XPIDLSRCS</a></li>
- <li><a href="/ja/docs/Installing_a_JavaScript_component">Installing a JavaScript component</a></li>
- <li><a href="/ja/docs/Building_a_component_DLL">Building a component DLL</a></li>
- <li><a href="/ja/docs/Building_a_static_library">Building a static library</a></li>
- <li><a href="/ja/docs/Building_a_dynamic_library">Building a dynamic library</a></li>
-</ul>
-
-<h2 id=".E3.83.A9.E3.82.A4.E3.83.96.E3.83.A9.E3.83.AA.E3.81.AE.E3.83.93.E3.83.AB.E3.83.89" name=".E3.83.A9.E3.82.A4.E3.83.96.E3.83.A9.E3.83.AA.E3.81.AE.E3.83.93.E3.83.AB.E3.83.89">ライブラリのビルド</h2>
-
-<p>Mozilla のビルドにおけるライブラリは、主として３種に分けられます:</p>
-
-<ul>
- <li><strong>Components</strong> は（静的ビルド時を除いて）共有ライブラリで、 dist/bin/components にインストールされます。Components は他のいかなるライブラリからもリンクされません。</li>
- <li><strong>Non-component shared libraries</strong> には、libxpcom、libmozjs といったライブラリが含まれます。これらのライブラリは dist/bin にインストールされ、<em>リンクもされます</em>。この種のライブラリを新規に作成する必要にせまられることはあまりありません。</li>
- <li><strong>Static libraries</strong> はしばしば共有ライブラリのビルドの中間段階として使われます。 共有ライブラリの一部となるいくつかのディレクトリにソースファイルがある場合などがそれに該当します。静的ライブラリは実行ファイルからリンクされることもあります。</li>
-</ul>
-
-<h3 id="Non-component_shared_libraries" name="Non-component_shared_libraries">Non-component shared libraries</h3>
-
-<p>non-component shared library は、複数のコンポーネントが共有しなければならない共通コードがあり、それを XPCOM を通じて共有することが、適切でないもしくは不可能な場合に有用です。 一例として、libmsgbaseutil 向けの Makefile の一部を見てみましょう。これは、mailnews コンポーネント全体からリンクされます:</p>
-
-<pre class="eval">DEPTH           = ../../..
-topsrcdir       = @top_srcdir@
-srcdir          = @srcdir@
-VPATH           = @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-<a href="/ja/docs/MODULE">MODULE</a>          = msgbaseutil
-<a href="/ja/docs/LIBRARY_NAME">LIBRARY_NAME</a>    = msgbaseutil
-<a href="/ja/docs/EXPORT_LIBRARY">EXPORT_LIBRARY</a> = 1
-<a href="/ja/docs/SHORT_LIBNAME">SHORT_LIBNAME</a>   = msgbsutl
-</pre>
-
-<p>上述した component の例との実際問題としての相違点は、IS_COMPONENT が設定されていない事だけである点に注意してください。この値を設定しない事によって、共有ライブラリが生成され、dist/bin にインストールされるでしょう。</p>
-
-<h3 id="Static_libraries" name="Static_libraries">Static libraries</h3>
-
-<p>上述の通り、静的ライブラリの主要な使用方法としては、大規模ライブラリ（主に component）のビルドの中間段階としての使用が挙げられます。これにより、複数のサブディレクトリにソースファイルを分散させて配置することができます。静的ライブラリは実行可能モジュールにもリンクされることがあります。例として、layout/base/src の Makefile の一部を以下に示します。</p>
-
-<pre class="eval">DEPTH           = ../../..
-topsrcdir       = @top_srcdir@
-srcdir          = @srcdir@
-VPATH           = @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-MODULE          = layout
-LIBRARY_NAME    = gkbase_s
-
-# REQUIRES and CPPSRCS omitted here for brevity #
-
-# we don't want the shared lib, but we want to force the creation of a static lib.
-<a href="/ja/docs/FORCE_STATIC_LIB">FORCE_STATIC_LIB</a> = 1
-
-include $(topsrcdir)/config/rules.mk
-</pre>
-
-<p>ここでは <strong>FORCE_STATIC_LIB</strong> = 1 というキーが設定されています。これにより、（unix の場合)libgkbase_s.a が、Windows の場合はgkbase_s.lib が生成され、dist/lib にコピーされます。では、コンポーネントを作成するために複数の静的ライブラリを合わせてリンクする方法をざっと見てみましょう。</p>
-
-<pre class="eval">DEPTH           = ../..
-topsrcdir       = @top_srcdir@
-srcdir          = @srcdir@
-VPATH           = @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-MODULE          = layout
-LIBRARY_NAME    = gklayout
-EXPORT_LIBRARY = 1
-<a href="/ja/docs/IS_COMPONENT">IS_COMPONENT</a>    = 1
-<a href="/ja/docs/MODULE_NAME">MODULE_NAME</a>     = nsLayoutModule
-
-<a href="/ja/docs/CPPSRCS">CPPSRCS</a>         = \
-                nsLayoutModule.cpp \
-                $(NULL)
-
-<a href="/ja/docs/SHARED_LIBRARY_LIBS">SHARED_LIBRARY_LIBS</a> = \
-                $(DIST)/lib/$(LIB_PREFIX)gkhtmlbase_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)gkhtmldoc_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)gkhtmlforms_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)gkhtmlstyle_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)gkhtmltable_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)gkxulbase_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)gkbase_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)gkconshared_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)gkxultree_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)gkxulgrid_s.$(LIB_SUFFIX) \
-                $(NULL)
-
-include $(topsrcdir)/config/rules.mk
-</pre>
-
-<p><strong>SHARED_LIBRARY_LIBS</strong> は、本共有ライブラリにリンクすべき静的ライブラリを並べて記述します。<strong>LIB_PREFIX</strong> や <strong>LIB_SUFFIX</strong> を使用することで、すべてのプラットフォームで動作させることができることに注意してください。</p>
-
-<h2 id="Jar_.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E3.83.93.E3.83.AB.E3.83.89.E3.81.99.E3.82.8B" name="Jar_.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E3.83.93.E3.83.AB.E3.83.89.E3.81.99.E3.82.8B">Jar ファイルをビルドする</h2>
-
-<p>Jar ファイルは(XUL、JavaScript、CSSといった) chrome ファイルのパッケージングに使用します。Jar パッケージングについてのより詳細な情報は、{{ mediawiki.external('jar-packaging.html このドキュメント') }}で得られます。ここでは、Jar パッケージを行うために Makefile をどのように設定するかのみ述べます。以下に例を示します。</p>
-
-<pre class="eval">DEPTH           = ../../../..
-topsrcdir       = @top_srcdir@
-srcdir          = @srcdir@
-VPATH           = @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-include $(topsrcdir)/config/rules.mk</pre>
-
-<p>そうです。ここでは定義が必要な外部変数は使用されていません。Makefile.in と同じディレクトリに <strong>jar.mn</strong> ファイルがある場合、自動的に処理されるのです。jar.mn と chrome ファイルを含む <strong>resources</strong> ディレクトリを作成するのが通例ですが、ライブラリを作成するディレクトリに jar.mn を設置したいのであれば、これも動作します（処理されます）。</p>
-
-<div class="originaldocinfo">
-<h2 id="著作情報">著作情報</h2>
-
-<ul>
- <li>著作者: Brian Ryner</li>
- <li>著作権情報: Portions of this content are © 1998–2006 by individual mozilla.org contributors; content available under a Creative Commons license</li>
-</ul>
-</div>
diff --git a/files/ja/mozilla/developer_guide/build_instructions/index.html b/files/ja/mozilla/developer_guide/build_instructions/index.html
deleted file mode 100644
index e422ae0498..0000000000
--- a/files/ja/mozilla/developer_guide/build_instructions/index.html
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: Build and Install
-slug: Mozilla/Developer_guide/Build_Instructions
-tags:
-  - Build documentation
-  - Developing Mozilla
-translation_of: Mozilla/Developer_guide/Build_Instructions
-translation_of_original: Build_and_Install
----
-<p>注意：最初に<a href="ja/Configuring_Build_Options">ビルドオプションの設定</a>をしてからビルドしてください！</p>
-
-<h3 id=".E3.83.93.E3.83.AB.E3.83.89" name=".E3.83.93.E3.83.AB.E3.83.89">ビルド</h3>
-
-<p>Mozilla のチェックアウトやビルドには必ず GNU make を使用してください。他の "make" プログラムは好ましくありません。Windows、Mac OS X および GNU/Linux では GNU make を実行するために "make" を使ってください。ほとんどの 非 GNU の unix では "gmake" を使ってください。</p>
-
-<p>Windows、Mac OS X および GNU/Linux では必ずソースディレクトリの最上部 ("mozilla") で make コマンドを実行してください。</p>
-
-<pre class="eval">make -f client.mk build
-</pre>
-
-<p>Mac OS X での注意：ソースの tar ボールを展開したときに作成されるソースディレクトリのパスにスペースが含まれないようにしてください。</p>
-
-<p>ほとんどの非 GNU の unix の場合</p>
-
-<pre class="eval">$ gmake -f client.mk build
-</pre>
-
-<p>手動で configure やビルドをしたい場合は、オブジェクトディレクトリに移動し、configure を実行し、make/gmake を実行してください。configure が .mozconfig ファイルで指定したオプションを拾います。</p>
-
-<h3 id=".E3.81.A7.E3.81.8D.E3.81.9F.E3.83.93.E3.83.AB.E3.83.89.E3.81.AE.E5.AE.9F.E8.A1.8C" name=".E3.81.A7.E3.81.8D.E3.81.9F.E3.83.93.E3.83.AB.E3.83.89.E3.81.AE.E5.AE.9F.E8.A1.8C">できたビルドの実行</h3>
-
-<p>できたビルドをビルドに使われたディレクトリから直接実行することができます。しかし、ビルドディレクトリにはビルドツリーへのシンボリックリンクが含まれます。共有したり移動したりできるスタンドアローンなビルドにするためには、インストールやパッケージングの作業が必要です。</p>
-
-<h4 id="Windows_.E3.81.A8_Linux" name="Windows_.E3.81.A8_Linux">Windows と Linux</h4>
-
-<p>macintosh 以外のビルドシステムでは、ビルドの完成品は<em>objdir</em> /dist/bin にあります。POSIX プラットフォーム（BSD、GNU/Linux、Solaris）ではバイナリの "mozilla-bin" や "firefox-bin" ではなく、"mozilla" や "firefox" というファイルを実行してください。</p>
-
-<h4 id="Mac_OS_X" name="Mac_OS_X">Mac OS X</h4>
-
-<p>macintosh ではビルドシステムによって<em>objdir</em> /dist/<em>AppName</em> .app にアプリケーションバンドルが生成されます。例えば、<em>objdir</em> /dist/Minefield.app です。</p>
-
-<p>--enable-debug 付きでビルドすると、アプリケーションは<em>objdir</em> /dist/<em>AppName</em> Debug.app、例えば<em>objdir</em> /dist/MinefieldDebug.app に配置されますので<strong>注意</strong>してください。</p>
-
-<p>Finder からアプリケーションバンドルを開いたり、またはコマンドラインから次のものを実行したりすることでアプリケーションを実行することができます。</p>
-
-<pre class="eval">$ objdir/dist/AppName[Debug].app/Contents/MacOS/appname
-</pre>
-
-<p>例えば</p>
-
-<pre class="eval">$ objdir/dist/MinefieldDebug.app/Contents/MacOS/firefox
-</pre>
-
-<h3 id=".E3.83.93.E3.83.AB.E3.83.89.E3.81.AE.E3.82.A4.E3.83.B3.E3.82.B9.E3.83.88.E3.83.BC.E3.83.AB" name=".E3.83.93.E3.83.AB.E3.83.89.E3.81.AE.E3.82.A4.E3.83.B3.E3.82.B9.E3.83.88.E3.83.BC.E3.83.AB">ビルドのインストール</h3>
-
-<p>POSIX プラットフォームでは<em>gmake install</em> を実行することによってできたビルドをシステムにインストールすることができます。しかしながら、以下のステップに従って tarball を作り、それを展開したほうがいい場合がよくあります。</p>
-
-<p>ほとんどのアプリケーションでは、アプリケーション特有のディレクトリで make することでビルドの tarball や zip パッケージを作ることができます。</p>
-
-<ul>
- <li>Firefox: $ make -C objdir/browser/installer</li>
- <li>Thunderbird: $ make -C objdir/mail/installer</li>
- <li>SeaMonkey: $ make -C objdir/xpinstall/packager</li>
-</ul>
-
-<p><em>実際の例</em>：<a href="ja/Configuring_Build_Options#Firefox_Optimized_Static"> Firefox の最適化・静的ビルド</a> 用の .mozconfig ファイルを使用する場合、</p>
-
-<ul>
- <li>Firefox: $ make -C ff-opt-static/browser/installer</li>
-</ul>
-
-<p>こうすることで、ff-opt-static/dist ディレクトリ内に、どこにでも展開できる firefox-1.5.0.3.en-US.linux-i686.tar.gz ファイルができます。</p>
-
-<p>windows 用のインストーラを作るためには、上記のディレクトリで "installer" ターゲットを make してください。</p>
-
-<ul>
- <li>Firefox: $ make -C objdir/browser/installer installer</li>
- <li>Thunderbird: $ make -C objdir/mail/installer installer</li>
- <li>SeaMonkey: $ make -C objdir/xpinstall/packager installer</li>
-</ul>
-
-<p><em>注意：</em>Firefox や Thunderbird で使われる圧縮率の高いインストーラを作るためには追加のアプリケーションをインストールする必要があります。</p>
-
-<ul>
- <li><a class="external" href="http://www.7-zip.org/">7-zip</a></li>
- <li><a class="external" href="http://upx.sourceforge.net/">UPX</a>（Windows ユーザへ：このパッケージは <a class="external" href="http://cygwin.com/">Cygwin</a> セットアップで使用できます。Utils カテゴリーから選択し、インストールしてください。DOS バージョンは機能しませんので使用しないでください。）</li>
-</ul>
-
-<p>これらのユーティリティの両方に PATH が通っている必要があります。さらに、MOZ_INSTALLER_USE_7ZIP 環境変数を設定する必要があります。</p>
-
-<div class="noinclude"> </div>
-
-<p>{{ languages( { "en": "en/Build_and_Install", "es": "es/Compilar_e_instalar", "fr": "fr/Compilation_et_installation", "zh-cn": "cn/\u7f16\u8bd1\u4e0e\u5b89\u88c5" } ) }}</p>
diff --git a/files/ja/mozilla/developer_guide/build_instructions/windows_prerequisites/index.html b/files/ja/mozilla/developer_guide/build_instructions/windows_prerequisites/index.html
deleted file mode 100644
index 6a6dba127e..0000000000
--- a/files/ja/mozilla/developer_guide/build_instructions/windows_prerequisites/index.html
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Building with VC8 Express
-slug: Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites
-tags:
-  - Build documentation
-  - Developing Mozilla
-original_slug: Building_with_VC8_Express
----
-<p>
-</p><p>このページは破棄されました。標準の <a href="ja/Windows_Build_Prerequisites">Windows ビルドに必要な環境</a>は現在、Microsoft Visual C++ バージョン 8 Express Edition が使用されています。
-</p>
-<div class="noinclude">
-</div>
-{{ languages( { "en": "en/Building_with_VC8_Express" } ) }}
diff --git a/files/ja/mozilla/developer_guide/callgraph/index.html b/files/ja/mozilla/developer_guide/callgraph/index.html
deleted file mode 100644
index 8bc4e0c2be..0000000000
--- a/files/ja/mozilla/developer_guide/callgraph/index.html
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Callgraph
-slug: Mozilla/Developer_guide/Callgraph
-tags:
-  - Callgraph
-  - Developing Mozilla
-  - NeedsTranslation
-  - TopicStub
-translation_of: Mozilla/Developer_guide/Callgraph
----
-<p>The Callgraph project is intended to produce a complete callgraph covering C and C++ code within Mozilla. This can be used for performing static analysis based on the relationship between functions and methods. For instance, given the C++ code:</p>
-<pre class="eval">int foo() {
-  return good();
-}
-
-int good() {
-  return evil() ? 0 : 1;
-}
-</pre>
-<p>The callgraph would be <code>foo() -&gt; good() -&gt; evil()</code>. Given the knowledge that <code>evil()</code> does evil things, one could then determine <code>foo()</code> also does evil things.</p>
-<p>The Callgraph project uses gcc and <a href="/en/Treehydra" title="en/Treehydra">Treehydra</a> to generate information about function and method calls at compile time, and aggregates it into a sqlite database.</p>
-<h2 id="Documentation">Documentation</h2>
-<dl> <dt><a href="/en/Developing_Mozilla/Callgraph/Installing_Callgraph" title="En/Callgraph/Installing_Callgraph">Installing Callgraph</a></dt> <dd>Download and installation of Callgraph</dd> <dt><a href="/en/Developing_Mozilla/Callgraph/Schema_Reference" title="En/Callgraph/Schema_Reference">Schema Reference</a></dt> <dd>Explanation of the database schema</dd> <dt><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=callgraph" class="link-https">Further details</a></dt> <dd>Implementation ideas for Callgraph</dd>
-</dl>
diff --git a/files/ja/mozilla/developer_guide/callgraph/schema_reference/index.html b/files/ja/mozilla/developer_guide/callgraph/schema_reference/index.html
deleted file mode 100644
index 6bd8d1b191..0000000000
--- a/files/ja/mozilla/developer_guide/callgraph/schema_reference/index.html
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: スキーマリファレンス
-slug: Mozilla/Developer_guide/Callgraph/Schema_Reference
-tags:
-  - Callgraph
-  - Developing Mozilla
-  - リファレンス
-translation_of: Mozilla/Developer_guide/Callgraph/Schema_Reference
----
-<p>The schema used in <code>graph.sqlite</code> is defined by <code>schema.sql</code>. Since Callgraph is new, the schema is fairly simple and is expected to evolve. If you have suggestions or use cases that require changes, please file a bug. (In particular, there are several pending improvements mentioned below.)</p>
-
-<p>The schema contains the following tables:</p>
-
-<ul>
- <li><code>node</code>. This represents a function, and contains the following fields:
-
-  <ul>
-   <li><code>id INTEGER PRIMARY KEY</code>, a unique identifier for the node</li>
-   <li><code>name TEXT</code>, the fully-qualified function or method name, including return type and parameters. See below.</li>
-   <li><code>isPtr INTEGER</code>, 1 if the function call (in this case, the callee) is a function pointer, 0 otherwise.</li>
-   <li><code>isVirtual INTEGER</code>, 1 if the function call is a virtual method, 0 otherwise.</li>
-   <li><code>loc TEXT</code>, the fully-resolved source file containing the declaration or definition of the function. See below.</li>
-   <li><code>UNIQUE (name, loc) ON CONFLICT IGNORE</code></li>
-  </ul>
-
-  <p> </p>
-
-  <p>The fully-qualified method name includes the return value, namespaces, class name, method or function name, and parameter types. For instance, the code</p>
-
-  <pre class="brush: cpp">namespace ns {
-  class cs {
-    int method(float, double);
-  };
-};
-    </pre>
-
-  <p>would result in a <code>name</code> of <code>int ns::cs::method(float,double)</code>. For nonstatic methods, <code>this</code> is excluded from the parameter list, though we may want to denote nonstatic methods with a separate field. The global namespace is indicated by a leading <code>::</code>. (Types are currently not fully-qualified.) The <code>loc</code> refers to the source file in which the declaration or definition appeared. For classes, the declaration context will always be available, and this location will refer to the file containing the declaration (for instance, <code>foo.h</code>). For function calls, this location may refer to the declaration or definition, and cannot presently be used in concert with <code>name</code> as a reliably unique identifier. (This could potentially be solved by implementing linker-style name resolution rules in Callgraph.) For function pointers, it is impossible to determine a location, and <code>loc</code> will be the empty string. (You should guard on this case using <code>isPtr</code>.) For compiler built-ins, <code>loc</code> will be <code>&lt;built-in&gt;</code>. Since symlinks are prevalent in the Mozilla build process, the path in <code>loc</code> is always fully-resolved; that is, it will be an absolute path which is guaranteed to have a one-to-one mapping with a particular file in the source or object tree. (In the case of generated files, such as from xpidlgen, it will point into the object tree. Note also that one can override gcc's notion of the current source file using the <code>#file</code> directive; in the likely case where this file doesn't exist, the resulting <code>loc</code> will not be fully-resolved. Caveat emptor. Thankfully, this practice is uncommon.)</p>
-
-  <p>The <code>(name, loc)</code> pair is intended to be a unique identifier for a given function or method call. (Though this currently breaks down for functions and function pointers.) In the future, we may include a <code>mangledName</code> field in the table, which would allow more consistency with linker rules regarding function name resolution and uniqueness. We may also add a field indicating whether the function definition has been seen (which would distinguish, say, calls into library functions from functions who simply don't call anyone else).</p>
- </li>
- <li><code>edge</code>. This represents a call between functions, and contains the following fields:
-  <ul>
-   <li><code>caller INTEGER REFERENCES node</code>, the <code>id</code> of a <code>node</code> representing the caller function.</li>
-   <li><code>callee INTEGER REFERENCES node</code>, likewise for the callee.</li>
-   <li><code>PRIMARY KEY(caller, callee) ON CONFLICT IGNORE</code></li>
-  </ul>
-
-  <p> </p>
-
-  <p>The primary key is currently unique on caller and callee, meaning that if the caller calls the callee multiple times, only one edge will exist in the table. We may change this if there are cases where the number of calls is relevant.</p>
- </li>
- <li><code>implementors</code>. This table provides information about the inheritance chain of C++ classes, specifically which virtual interface methods are overridden or implemented by which classes.
-  <ul>
-   <li><code>implementor TEXT</code>, the fully-qualified class name of the class which implements the method.</li>
-   <li><code>interface TEXT</code>, the fully-qualified class name of the class which declares the method to be pure virtual. See below.</li>
-   <li><code>method TEXT</code>, the method name (not including return type or arguments).</li>
-   <li><code>loc TEXT</code>, the fully-resolved source file containing the declaration of the interface class.</li>
-   <li><code>id INTEGER PRIMARY KEY</code>, a unique identifier for the entry.</li>
-   <li><code>UNIQUE (implementor, interface, method, loc) ON CONFLICT IGNORE</code></li>
-  </ul>
-
-  <p> </p>
-
-  <p>An interface is considered a class which declares the method in question to be virtual (either pure or non-pure), while an implementor overrides it with a declaration that is non-pure. (Whether the implementor actually defines the function is not considered.) For instance, consider the code</p>
-
-  <pre class="brush: cpp">class iFoo {
-  public:
-    virtual void method1(float) = 0;
-    virtual void method2(float) = 0;
-};
-
-class iBar : public iFoo {
-  public:
-    virtual void method1(float) = 0;
-    virtual void method2(float);
-};
-
-class Bar : public iBar {
-  public:
-    virtual void method1(float);
-    virtual void method2(float);
-};
-</pre>
-
-  <p>The class <code>iBar</code> would be considered an implementor of <code>method2</code>, while class <code>Bar</code> would be an implementor of both <code>method1</code> and <code>method2</code>. For implementor <code>iBar</code>, <code>iFoo::method2</code> would be considered an interface method. For implementor <code>Bar</code>, both methods on <code>iFoo</code> and <code>iBar</code> would be listed as interface methods. Uniqueness is determined by implementor, interface, method, and loc. (Note that the parameter list to the virtual method is also required to determine uniqueness, and will be added.)</p>
- </li>
-</ul>
diff --git a/files/ja/mozilla/developer_guide/code_review_faq/index.html b/files/ja/mozilla/developer_guide/code_review_faq/index.html
deleted file mode 100644
index 53a1401ec6..0000000000
--- a/files/ja/mozilla/developer_guide/code_review_faq/index.html
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: Code Review FAQ
-slug: Mozilla/Developer_guide/Code_Review_FAQ
-tags:
-  - Developing Mozilla
-translation_of: Mozilla/Developer_guide/Code_Review_FAQ
----
-<h3 id=".E3.82.B3.E3.83.BC.E3.83.89.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.81.AE.E7.9B.AE.E7.9A.84.E3.81.AF.E4.BD.95.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> コードレビューの目的は何ですか？ </h3>
-<p>コードレビューは、パッチの設計と実装について検証を行うための、基本的な機構です。沢山のハッカーたちが Mozilla の様々なモジュールに対して行う設計と実装を、常に一貫したレベルのものにするために役立っています。私たちは現在、二段階のレビューを行っています。「レビュー」と「スーパーレビュー」です。
-</p><p>もちろんコードレビューは即座に行えるものではなく、このシステムにはある程度の待ち時間が伴います。私たちは、レビュアーやスーパーレビュアーが彼ら自身のハッキングを行うのを妨げずに、レビューの待ち時間を減らす方法を常に模索しています。私たちのシステムは完璧ではなく、将来も完璧にはならないでしょう。私たちは現在もシステムを発展させている途上であり、もし良い方法があるのなら提案してください。
-</p>
-<h3 id=".E7.A7.81.E3.81.8C.E6.9B.B8.E3.81.84.E3.81.9F.E3.82.B3.E3.83.BC.E3.83.89.E3.81.AE.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.82.92.E8.A1.8C.E3.81.86.E3.81.AE.E3.81.AF.E8.AA.B0.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> 私が書いたコードのレビューを行うのは誰ですか？ </h3>
-<p>あなたは、コードがチェックインされる予定のモジュールの所有者、あるいは指定された「ピア (peer：同格の人)」から承認 ("r={{ mediawiki.external('name') }}") を貰わなくてはなりません。 あなたのコードが複数のモジュールに影響を及ぼす場合には、影響を受けるモジュールのオーナーあるいは指定されたピアから "r={{ mediawiki.external('name') }}" を貰わなくてはなりません。 私たちはこの点に関して合理的であるよう心がけていますので、モジュール所有者全員の承認が必要な場合についての厳密なルールはありません。例えば、文字列クラスの変更や、多数のモジュールで表示されるテキストの変更のように、ツリー全体にまたがる変更の場合、必ずしも全てのモジュール所有者のレビューを必要とはしません。
-</p><p>上記以外の人に、追加のレビューを依頼しても構いません。
-</p>
-<h3 id=".E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.8C.E6.A4.9C.E8.A8.8E.E3.81.99.E3.82.8B.E3.82.82.E3.81.AE.E3.81.AF.E4.BD.95.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> レビュアーが検討するものは何ですか？ </h3>
-<p>レビューでは、パッチの設計と実装、対象となる問題の解決における有用性、そしてモジュールへの適合性に重点が置かれます。レビュアーは、その問題の領域における専門知識を持った人物であるべきです。また、レビュアーは、その領域以外の専門知識を利用して、他の改善案の可能性を指摘することもできます。 レビュアーがコードの改善に関して行うコメントに、固有の制限はありません。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.81.A8.E3.81.AF.E4.BD.95.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビューとは何ですか？ </h3>
-<p>「スーパーレビュー」という名称は、本当は好ましくありません。「インフラストラクチャ・レビュー」または「インテグレーション・レビュー」という名称のほうが、多分正確であり、「スーパー」という魅力的な名称が招く誤解を避けることが出来るでしょう。しかし、この名称は長い間使われてきましたし、当面は「スーパーレビュー」という名称が使用され続けるでしょう。
-</p><p>スーパーレビューでは、単なるレビューとは異なる問題に重点が置かれます。 Mozilla コードベースの幅広い範囲において、パッチがうまく適合するかどうか、ということです。例えば、以下のようなポイントが論点となります。
-</p>
-<ul><li> API の使用に関して
-</li><li> XPCOM の使用に関して
-</li><li> Mozilla のポータビリティ・ガイドラインに忠実であるか
-</li><li> 複数のモジュールへの影響
-</li><li> Mozilla のコーディングの慣例
-</li></ul>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.AB.E3.81.AF.E5.B0.82.E9.96.80.E7.9F.A5.E8.AD.98.E3.81.8C.E5.BF.85.E8.A6.81.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビュアーには専門知識が必要ですか？ </h3>
-<p>いいえ、そのパッチが対象とする分野の専門知識をスーパーレビュアーが持っている必要はありません。 私たちは、スーパーレビュアーに対して、専門知識を持たない領域でレビューを行ってくれるよう頼んでいます。そうしないと、負荷のバランスが取れなくなるのです。専門知識を持ったスーパーレビュアーは、その領域の範囲内のパッチ全てにレビューを行わなければならないと感じるでしょう。これは燃え尽き症候群への道です。さらに、スーパーレビューを行うために重要であるのにも関わらず、誰一人としてその領域に関する幅広い知識を持たない、あるいは持ちたくない領域もあるでしょう。
-</p><p>もちろん、スーパーレビュアーが専門知識を持っていて悪いということはありません。私たちは彼らがスーパーレビューにおいてその専門知識を使ってくれることを望みますし、コードの改善に関してスーパーレビュアーが行うコメントに、固有の制限はありません。専門知識を持ったスーパーレビュアーは、レビューがどの程度複雑になりそうかを迅速に評価し、スーパーレビューをより早く完了させ、そのパッチに対する包括的な評価を与えることができるでしょう。例えて言えば、どんな名シェフでもあなたの料理を改善できますが、あなたがクレオール料理を作ろうとしているのであれば、クレオール料理の名シェフならなお良い、ということです。
-</p><p>ですので、専門知識は付加価値にはなりますが、必須のものではありません。スーパーレビュアーが希望すれば、そのレビューが、専門知識には基づかず、包括的な問題についてのみのレビューであることを注記することができます。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.81.AE.E3.83.89.E3.82.AD.E3.83.A5.E3.83.A1.E3.83.B3.E3.83.88_.E3.81.A7.E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.A8.E5.B0.82.E9.96.80.E9.A0.98.E5.9F.9F.E3.81.8C.E9.96.A2.E9.80.A3.E3.81.A5.E3.81.91.E3.82.89.E3.82.8C.E3.81.A6.E3.81.84.E3.82.8B.E3.81.AE.E3.81.AF.E4.BD.95.E6.95.85.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビューのドキュメント でスーパーレビュアーと専門領域が関連づけられているのは何故ですか？ </h3>
-<p>既に述べた通り、専門知識を持ったスーパーレビュアーはより早く、包括的なレビューを行うことが出来ます。あなたの作業範囲に専門知識を持つスーパーレビュアーがいる場合には、まずその人に連絡を取ってください。できるものであれば、デラックスバージョンのスーパーレビューを受けましょう。
-</p><p>専門知識を持ったスーパーレビュアーがいなかったり、また、いたとしても彼らが忙しすぎるような場合には、別のスーパーレビュアーをあたってください。強力なレビュアーとできるだけ自力で頑張って、スーパーレビュアーがモジュール間の問題に専念できるようにしてください。スーパーレビュアーと専門範囲を関連付けているのは、単に出発点を示すためだけです。どのスーパーレビュアーでもパッチの取り扱いができます。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.8C.E5.95.8F.E9.A1.8C.E3.82.92.E8.A6.8B.E9.80.83.E3.81.97.E3.81.9F.E3.82.89.E3.81.A9.E3.81.86.E3.81.AA.E3.82.8B.E3.81.AE.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビュアーが問題を見逃したらどうなるのですか？ </h3>
-<p>私たちはスーパーレビュアーが、全てを完璧に行うことを期待はしていません。見逃される問題もあることでしょう。スーパーレビュアーは日々新しいことを学んでいるでしょうが、学問に終点はありません。スーパーレビュアーがスーパーレビューを行うことによって、あなたの作業成果に関する責任が発生するわけではないのです。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.81.AE.E5.89.8D.E3.81.AB.E3.81.AF.E5.BF.85.E3.81.9A.E9.80.9A.E5.B8.B8.E3.81.AE.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.82.92.E5.8F.97.E3.81.91.E3.81.AA.E3.81.91.E3.82.8C.E3.81.B0.E3.81.AA.E3.82.8A.E3.81.BE.E3.81.9B.E3.82.93.E3.81.8B.EF.BC.9F"> スーパーレビューの前には必ず通常のレビューを受けなければなりませんか？ </h3>
-<p>いいえ、逆の順序でも構いません。しかしながらスーパーレビュアーは、まず通常のレビューが終了してからスーパーレビューを始めたい、と決めることが出来ます。例えば、パッチの目的をどのようにして実現するかで議論が分かれており、パッチが完成するまでに大幅な変更があるかもしれないような場合です。
-</p>
-<h3 id=".E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.82.84.E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.81.AE.E7.B5.90.E6.9E.9C.E3.81.AF.E3.81.A9.E3.81.AE.E3.82.88.E3.81.86.E3.81.AB.E4.BC.9D.E3.81.88.E3.82.89.E3.82.8C.E3.81.BE.E3.81.99.E3.81.8B.EF.BC.9F"> レビューやスーパーレビューの結果はどのように伝えられますか？ </h3>
-<p>パッチがレビューやスーパーレビューを通った場合には、バグレポートのアタッチメントテーブルが "{{ mediawiki.external('name') }}:review+" や、 "{{ mediawiki.external('name') }}:super-review+" の状態になります。レビューを通らなかった場合には、"{{ mediawiki.external('name') }}:review-"、 "{{ mediawiki.external('name') }}:super-review-" となります。レビュアーがレビューフラグを設定する場合には、レビューの内容に関するコメントがそのバグに追記されることが多いでしょう。
-</p>
-<h3 id=".E3.81.A9.E3.82.8C.E3.81.8F.E3.82.89.E3.81.84.E3.81.AE.E6.99.82.E9.96.93.E3.81.A7.E8.BF.94.E7.AD.94.E3.82.92.E8.B2.B0.E3.81.88.E3.81.BE.E3.81.99.E3.81.8B.EF.BC.9F"> どれくらいの時間で返答を貰えますか？ </h3>
-<p>あなたが特定のレビュアーにスーパーレビューを依頼した場合、24 時間以内になんらかの返答をもらえるでしょう。最低限、次のような事項に関する返答があるはずです。(a) スーパーレビュアーがレビューを行えるかどうか、(b) もし可能な場合、完了までの時間。 スーパーレビュアーが要求どおりスーパーレビューを行うことが出来ないというだけの返答をもらうのに 24 時間も待つのは長すぎるということはわかっていますので、要求されたスーパーレビューを行えない場合には、できるだけ早く返事を出すよう、スーパーレビュアーにお願いしています。
-</p><p>多くのパッチには、有意義なコメントが 24 時間以内に付くでしょう。しかし、スーパーレビュアーには、24 時間以内にレビューを行う義務はありません。 スーパーレビュアーが後になってスーパーレビューを行えそうにない、あるいは時間的見通しを誤ったのに気付いた場合には、迅速にスーパーレビュアーからその旨を連絡されるでしょう。
-</p><p>自分のパッチが単純かつ小さなもので、スーパーレビューは必要無いと確信できる場合は、その旨のリクエスト ("requesting 'rs= '") を行ってください。スーパーレビュアーはパッチに「ゴム印」を付ける決定権を持っています。つまり、スーパーレビュアーはパッチが非常に基本的なものであり、スーパーレビューを飛ばしても構わないと合意したことになります。この場合、「ゴム印」の付いたパッチはすみやかに受理されるでしょう。
-</p>
-<h3 id=".E8.BF.94.E7.AD.94.E3.82.92.E8.B2.B0.E3.81.88.E3.81.AA.E3.81.84.E5.A0.B4.E5.90.88.E3.81.AB.E3.81.AF.E3.81.A9.E3.81.86.E3.81.99.E3.82.8C.E3.81.B0.E8.89.AF.E3.81.84.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> 返答を貰えない場合にはどうすれば良いですか？ </h3>
-<p>スーパーレビュアーが度忘れをしてパッチを受け付けない、ということもありえます。彼らは完璧ではなく、往々にしてオーバーワークです。24 時間以内に返答がない場合には再度 Ping (問い合わせ) を行ってください。または他のスーパーレビュアーをあたってください。この問題が頻繁に起こるのであれば、具体的なデータを mozilla.org のスタッフに知らせてください。(データ抜きで苦情をよこさないでください。「これに一週間かかりました」だけで、具体的なデータの量が充分でなければ、問題の原因を探り出すことはできません。) 私たちはトラッキングシステムを使用しているのですから、より良い解決策を見つけることができるでしょう。
-</p>
-<h3 id="24_.E6.99.82.E9.96.93.E4.BB.A5.E5.86.85.E3.81.AB.E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.82.92.E5.8F.97.E3.81.91.E3.82.89.E3.82.8C.E3.82.8B.E8.A6.8B.E8.BE.BC.E3.81.BF.E3.81.AF.E3.81.82.E3.82.8A.E3.81.BE.E3.81.99.E3.81.8B.EF.BC.9F"> 24 時間以内にスーパーレビューを受けられる見込みはありますか？ </h3>
-<p>それは、あなたのパッチと、スーパーレビュアーの作業負荷によります。各スーパーレビュアーの作業のやり方は人によって少しずつ異なっているので、スーパーレビュアーがコーディング、スーパーレビュー、そしてその他の作業に対してどのような優先順位を付けるのか、そしてあなたのパッチがそのどこに該当するか、を一つの型にはめることはできません。仕事が中断されることに慣れていて、簡単なレビューのためならすぐに本業を中断できるスーパーレビュアーもいるでしょう。別のスーパーレビュアーは、まず本業を完了させてからスーパーレビューにかかるでしょう。簡単にレビューでき、かつ重大問題を解決するようなパッチが関心を引きやすいということは確かです。また、数時間の濃密なレビューを必要とするような大きなパッチには時間がかかるということも明らかでしょう。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.82.92.E5.BE.8C.E5.9B.9E.E3.81.97.E3.81.AB.E3.81.97.E3.81.A6.E3.80.81.E3.83.81.E3.82.A7.E3.83.83.E3.82.AF.E3.82.A4.E3.83.B3.E3.82.92.E5.85.88.E3.81.AB.E8.A1.8C.E3.81.86.E3.81.93.E3.81.A8.E3.81.8C.E5.87.BA.E6.9D.A5.E3.81.AA.E3.81.84.E3.81.AE.E3.81.AF.E4.BD.95.E6.95.85.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビューを後回しにして、チェックインを先に行うことが出来ないのは何故ですか？ </h3>
-<p>それには多くの理由があります。ここに、順不同でいくつかを挙げます。
-</p><p>スーパーレビュアーが探し出すのは、チェックインされた後に広範囲の影響を及ぼすような問題だからです。スーパーレビューで発見できるような問題でトランク上の全員が苦労するのでは意味がありません。ミスター・スポックなら「多数の善は、少数の善に勝る」と言うでしょう。
-</p><p>コードをチェックインすると、「パッチの作業はこれで終わりだ。次の作業に進もう」という心理学的な効果をもたらすようです。そうすると、パッチ変更の要求は、新たな別の作業と思われがちです。実際にはまだ完了していないのに、完了したような気分にさせるのは、馬鹿げたことです。
-</p><p>コードのチェックインの後にスーパーレビュアーがコメントを追加すると、そのコメントが実装されたかされていないかを追跡するのが困難になります。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.8B.E3.82.89.E3.80.81.E3.81.A9.E3.81.AE.E3.82.88.E3.81.86.E3.81.AA.E5.9B.9E.E7.AD.94.E3.82.92.E8.B2.B0.E3.81.88.E3.82.8B.E3.81.AE.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビュアーから、どのような回答を貰えるのですか？ </h3>
-<p>典型的な返答としては、以下の様なものがあります：
-</p>
-<ul><li> "sr={{ mediawiki.external('name') }}." という承認。
-</li><li> "r/sr={{ mediawiki.external('name') }}." という承認。これはスーパーレビュアーが、パッチの関係する領域でレビュアーでもある場合に有り得ます。この返答の意味は、承認がレビューとスーパーレビューとのどちらとしても適用できる (両方ではない) ことを意味します。従って、パッチの作者にとって、第二のレビューを受けることが可能な人の幅が広がります。
-</li><li> 変更の要求と変更されたパッチの再提出の要求。
-</li><li> 変更の要求と、"once changes made, sr={{ mediawiki.external('name') }}." (変更後は{{ mediawiki.external('name') }}にスーパーレビューを受けること) の様な但し書き。
-</li><li> "rs={{ mediawiki.external('name') }}." という承認。これは、パッチが小さいか自明のものであって、スーパーレビューは不要である、とスーパーレビュアーが判断したことを意味します。
-</li><li> モジュール所有者に対して、まずレビューを完了するよう依頼。
-</li><li> まずパッチを適用して、テストしてくれるよう誰かに依頼。(往々にして良い学習材料です)
-</li><li> 他のスーパーレビュアーにパッチを取り扱ってくれるように依頼。
-</li><li> 説明またはリスク分析の依頼。
-</li></ul>
-<p>スーパーレビュアーは、上記のリストに記載されていない回答をすることもあります。上記は全ての回答を網羅したものではありませんので、スーパーレビュアーがこのリストに縛られるのは私たちの望むところではありません。
-</p>
-<h3 id=".E3.81.AA.E3.81.9C.E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.8B.E3.82.89_.22rs.3D.22_.E3.82.92.E8.B2.B0.E3.81.86.E3.81.BE.E3.81.A7.E5.BE.85.E3.81.9F.E3.81.AA.E3.81.91.E3.82.8C.E3.81.B0.E3.81.AA.E3.82.89.E3.81.AA.E3.81.84.E3.81.AE.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F_.E3.81.AA.E3.81.9C.E5.B0.8F.E3.81.95.E3.81.AA.E5.A4.89.E6.9B.B4.E3.81.A7.E3.81.82.E3.81.A3.E3.81.A6.E3.82.82.E3.80.81.E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.81.AE.E5.BF.85.E8.A6.81.E3.81.8C.E7.84.A1.E3.81.84.E3.81.A8.E5.8B.9D.E6.89.8B.E3.81.AB.E5.88.A4.E6.96.AD.E3.81.97.E3.81.A6.E3.81.AF.E3.81.AA.E3.82.89.E3.81.AA.E3.81.84.E3.81.AE.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> なぜスーパーレビュアーから "rs=" を貰うまで待たなければならないのですか？ なぜ小さな変更であっても、スーパーレビューの必要が無いと勝手に判断してはならないのですか？ </h3>
-<p>一貫性を保つには、チェックインアクセスが可能な全員よりも、25 人のグループのほうが簡単だからです。あなたのパッチが "rs" の範疇に属すると考えるのなら、リクエストにその旨を注記してください。これによって、レビューに割ける時間が少ないスーパーレビュアーに対して、そのパッチを見てみようという気にさせることができるかもしれません。もちろん、スーパーレビュアーは、リクエストを受け入れず、パッチにスーパーレビューが必要であると決めることが出来ます。もしあなたが全てのパッチに "rs wanted" 通知をつけたとするならば、「オオカミが来たとほらを吹く少年」だと見なされるという逆効果になり、"rs wanted" を付けても重視されなくなるでしょう。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.8C.E3.83.A2.E3.82.B8.E3.83.A5.E3.83.BC.E3.83.AB.E6.89.80.E6.9C.89.E8.80.85.E3.81.AE.E5.A0.B4.E5.90.88.E3.80.81.E3.81.A9.E3.81.86.E3.81.97.E3.81.A6_R_.E3.81.A8_SR_.E3.81.AE.E4.B8.A1.E6.96.B9.E3.82.92.E4.B8.8E.E3.81.88.E3.82.8B.E3.81.93.E3.81.A8.E3.81.8C.E5.87.BA.E6.9D.A5.E3.81.AA.E3.81.84.E3.81.AE.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビュアーがモジュール所有者の場合、どうして R と SR の両方を与えることが出来ないのですか？ </h3>
-<p>ソースコードをツリーに入れるにあたって、第三者の確認が必要と考えるからです。
-</p>
-<h3 id=".E7.A7.81.E3.81.AE.E3.83.91.E3.83.83.E3.83.81.E3.81.AE.E3.83.97.E3.83.A9.E3.82.A4.E3.82.AA.E3.83.AA.E3.83.86.E3.82.A3.E3.81.8C.E4.BD.8E.E3.81.8F.E3.81.A6.E3.80.81.E5.BD.93.E5.88.86.E3.81.AE.E9.96.93.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.82.92.E5.8F.97.E3.81.91.E3.82.89.E3.82.8C.E3.81.AA.E3.81.84.E3.80.81.E3.81.A8.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.AB.E8.A8.80.E3.82.8F.E3.82.8C.E3.81.9F.E5.A0.B4.E5.90.88.E3.80.81.E3.81.A9.E3.81.86.E3.81.97.E3.81.9F.E3.82.89.E8.89.AF.E3.81.84.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> 私のパッチのプライオリティが低くて、当分の間レビューを受けられない、とレビュアーに言われた場合、どうしたら良いですか？ </h3>
-<p>間違ってはいないのかもしれませんが、そのような返答を貰うのはいやですよね、別のスーパーレビュアーをあたってください。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.AF.E3.80.81.E8.A9.B2.E5.BD.93.E3.83.90.E3.82.B0.E3.81.A7.E6.98.8E.E7.A2.BA.E3.81.AB.E7.89.B9.E5.AE.9A.E3.81.95.E3.82.8C.E3.81.A6.E3.81.84.E3.81.AA.E3.81.84.E3.82.88.E3.81.86.E3.81.AA.E4.BD.9C.E6.A5.AD.E3.82.92.E3.83.91.E3.83.83.E3.83.81.E4.BD.9C.E6.88.90.E8.80.85.E3.81.AB.E4.BE.9D.E9.A0.BC.E3.81.99.E3.82.8B.E3.81.93.E3.81.A8.E3.81.8C.E5.87.BA.E6.9D.A5.E3.81.BE.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビュアーは、該当バグで明確に特定されていないような作業をパッチ作成者に依頼することが出来ますか？ </h3>
-<p>はい、これに関して、スーパーレビュアーには自由裁量権があります。コードの品質の継続的な向上が私たちの望みであり、そのパッチに関連する追加的な変更を作成するのは正当なことでしょう。しかしながら、スーパーレビュアーは白紙委任状を持っているわけではありません。例えば、ミスタイプを修正するために、そのモジュール全体の文字列の実装を更新するような要求は、やり過ぎでしょう。特定のバグが関与する範囲と、スーパーレビュアーによって要求される変更の範囲とには、合理的な関係があるべきです。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.8B.E3.82.89.E3.80.81.E4.B8.8A.E8.A8.98.E3.81.AE.E6.96.87.E5.AD.97.E5.88.97.E3.81.AE.E4.BE.8B.E3.81.AE.E3.82.88.E3.81.86.E3.81.AA.E6.8B.85.E5.BD.93.E7.AF.84.E5.9B.B2.E5.A4.96.E3.81.AE.E5.A4.89.E6.9B.B4.E3.82.92.E4.BE.9D.E9.A0.BC.E3.81.95.E3.82.8C.E3.81.9F.E3.82.89.E3.80.81.E3.81.A9.E3.81.86.E3.81.99.E3.82.8C.E3.81.B0.E8.89.AF.E3.81.84.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビュアーから、上記の文字列の例のような担当範囲外の変更を依頼されたら、どうすれば良いですか？ </h3>
-<p>スーパーレビュアーに、その要求を新たなバグとして登録し、別のバグとして評価し優先順位付けし、修正することが可能であるか、尋ねてください。そして、この新しいバグが修正される前に、あなたが行った修正をチェックできないか、ということも確認してください。もしスーパーレビュアーと合意が出来なかった場合、他のスーパーレビュアー、または <a class=" link-mailto" href="mailto:drivers@mozilla.org">drivers@mozilla.org</a>、あるいはこの両方に、仲裁を頼んでください。見解の相違があるということを明記するのを忘れないようにしてください。他のレビュアーに第二のスーパーレビューを求め、より口当たりの良い結果を期待することは、更なる問題に繋がるでしょう。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.AF.E3.83.A6.E3.83.BC.E3.82.B6.E3.83.BC.E3.82.A4.E3.83.B3.E3.82.BF.E3.83.BC.E3.83.95.E3.82.A7.E3.83.BC.E3.82.B9.E3.81.A8.E3.83.A6.E3.83.BC.E3.82.B6.E3.83.BC.E3.82.A8.E3.82.AF.E3.82.B9.E3.83.9A.E3.83.AA.E3.82.A8.E3.83.B3.E3.82.B9.E3.81.AE.E5.95.8F.E9.A1.8C.E3.82.82.E6.8B.85.E5.BD.93.E3.81.97.E3.81.BE.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビュアーはユーザーインターフェースとユーザーエクスペリエンスの問題も担当しますか？ </h3>
-<p>はい。現在私たちは、コードのチェックインに先立って、独立した「UI/UE レビュー」を行っていません。過去に何度か提案されたことはありますが、私たちは別のレベルや別のレビューを設けるつもりはありません。その代わりに、スーパーレビュアーに UI の問題も考慮するように頼んでいます。彼らは、(a) インターフェースの破壊、(b) 他の UI 要素や仕様との不一致、(c) 仕様にはない大幅な UI の変更、 (d) その他奇妙なインターフェース、に注目するでしょう。
-</p><p>(a) の場合、スーパーレビュアーは、スーパーレビューの一環として修正できるか尋ねるでしょう。 (b), (c), (d) に関しては、スーパーレビュアーが UI 開発者に声をかけるでしょう。スーパーレビュアーが個人的な好みで UI に関する決定を行うようなことはあってはならないと考えています。
-</p>
-<h3 id=".E7.90.86.E8.A7.A3.E3.81.A7.E3.81.8D.E3.81.AA.E3.81.84.E5.A4.89.E6.9B.B4.E3.82.84.E3.80.81.E3.81.A9.E3.81.AE.E3.82.88.E3.81.86.E3.81.AB.E5.AE.9F.E8.A3.85.E3.81.97.E3.81.9F.E3.82.89.E3.82.88.E3.81.84.E3.81.8B.E3.82.8F.E3.81.8B.E3.82.89.E3.81.AA.E3.81.84.E5.A4.89.E6.9B.B4.E3.82.92.E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.8B.E3.82.89.E4.BE.9D.E9.A0.BC.E3.81.95.E3.82.8C.E3.81.9F.E5.A0.B4.E5.90.88.E3.80.81.E3.81.A9.E3.81.86.E3.81.97.E3.81.9F.E3.82.89.E8.89.AF.E3.81.84.E3.81.A7.E3.81.99.E3.81.8B.EF.BC.9F"> 理解できない変更や、どのように実装したらよいかわからない変更をスーパーレビュアーから依頼された場合、どうしたら良いですか？ </h3>
-<p>スーパーレビュアーには要求仕様を明確にする責任がありますが、あなたのコードの修正方法を教える責任はありません。スーパーレビュアーの要求を実装するために何らかの勉強が必要な場合、コミュニティの知り合いや会社の同僚に聞く、IRC やニュースグループに質問する、などの方法があります。もし Mozilla の作業を行うために雇われているのなら、あなたの会社に学習システムや指導教育システムがあるかもしれません。
-</p>
-<h3 id=".E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.83.BC.E3.81.AB.E3.81.AF.E3.83.88.E3.83.AC.E3.83.BC.E3.83.8B.E3.83.B3.E3.82.B0.E6.A9.9F.E6.A7.8B.E3.81.A8.E3.81.97.E3.81.A6.E3.81.AE.E6.84.8F.E5.9B.B3.E3.81.AF.E3.81.82.E3.82.8A.E3.81.BE.E3.81.99.E3.81.8B.EF.BC.9F"> スーパーレビューにはトレーニング機構としての意図はありますか？ </h3>
-<p>Yes でもあり、No でもあります。スーパーレビューは中上級者には優れた訓練機構です。一方で、経験が不十分な人にとって、スーパーレビューは恐ろしい訓練機構でもあります。コミュニティーの全体にわたって、基礎的な訓練を徹底的に広める必要がありますが、スーパーレビュアーの数はあまりにも少なく、また忙しすぎるので、マンツーマンで訓練を行う時間はほんの短い時間であっても捻出できません。そんな要求をすれば、燃え尽き症候群へのもうひとつの確実な道となるでしょう。私たちは、スーパーレビューが訓練の最終ステップとなるような、別の訓練方法を探しています。
-</p>
-<h3 id=".E3.81.A9.E3.81.86.E3.81.97.E3.81.9F.E3.82.89.E3.82.B9.E3.83.BC.E3.83.91.E3.83.BC.E3.83.AC.E3.83.93.E3.83.A5.E3.82.A2.E3.83.BC.E3.81.AB.E3.81.AA.E3.82.8C.E3.81.BE.E3.81.99.E3.81.8B.EF.BC.9F"> どうしたらスーパーレビュアーになれますか？ </h3>
-<p>まず、自分の胸に手を当てて考えてください。本当に、インフラのレビュアーになりたいですか？「スーパー」が意味する、製品のコア・シェルよりも魅惑的な何かに惑わされていませんか？それでもやはりスーパーレビュアーになりたいのなら、スーパーレビューの分野におけるあなたの才能を実証する方法を探してください。あなたが既にコードレビューに関っているのなら、範囲を拡大してスーパーレビューの対象も含めるようにしてください。また、スーパーレビュアーの中にはアシスタントがいればいいと思っている人がいるかもしれません。
-</p><p>スーパーレビュアーに次のようなことをアピールしてみましょう。
-</p>
-<ul><li> 製品の基盤と統合の問題について理解していることを示すコードを書く。
-</li><li> より良いレビュー、慎重なレビューを行う。
-</li><li> コードレビューにおいて製品基盤と統合の問題を識別する。
-</li><li> 明確なコメントでフィードバックを送り、製品基盤と統合の問題に関する教育技術を持っていることを示す。
-</li><li> 良好なコミュニケーションが取れることを示す。
-</li><li> Mozilla コミュニティへの尊敬の念を持っていることを示す。
-</li></ul>
-<p>自分の準備が整ったと思ったら、スーパーレビュアーグループにあなたの参加を提案してくれるスーパーレビュアーを探してください。スーパーレビュアーは、あなたの準備が整った、あるいは検討に値する程度に準備が整っていると考えれば、参加を提案してくれるでしょう。 明らかに力不足の人をスーパーレビュアーが推薦することは、まず無いでしょう。
-</p><p>スーパーレビュアーたちの間で、あなたには参加する資格があるという合意が出来たなら、あなたはグループの一員になれます。「合意」についての公式な定義はまだありませんし、明文化のためのプロセスもありません。当面はケースバイケースで対応したいと思います。必要となる前に、ではなく、必要に応じてプロセスを加えましょう。 </p>
-<div class="originaldocinfo">
-<h2 id=".E5.8E.9F.E6.96.87.E6.9B.B8.E3.81.AE.E6.83.85.E5.A0.B1"> 原文書の情報 </h2>
-<ul><li> 著者: Marcia Knous
-</li><li> 貢献者: dbaron, asa
-</li><li> 最終更新日: 2005-03-30
-</li></ul>
-</div>
-<div class="noinclude">
-</div>
-{{ languages( { "en": "en/Code_Review_FAQ" } ) }}
diff --git a/files/ja/mozilla/developer_guide/how_to_submit_a_patch/index.html b/files/ja/mozilla/developer_guide/how_to_submit_a_patch/index.html
deleted file mode 100644
index 03ed7214bd..0000000000
--- a/files/ja/mozilla/developer_guide/how_to_submit_a_patch/index.html
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: How to Submit a Patch
-slug: Mozilla/Developer_Guide/How_to_Submit_a_Patch
-tags:
-  - Developing Mozilla
-  - MDC Project
-  - NeedsContent
-  - 要更新
----
-<div class="summary">
-<p><span class="seoSummary">パッチを提出し、レビューを受け、Mozilla ソースツリーにコミットして貢献するための幾つかのステップです。この記事ではそのやり方を説明します。</span></p>
-</div>
-
-<p>パッチの提出プロセスは以下の図に書いてある通りです。そして、各ステップの詳細は次のセクションで説明します。</p>
-
-<p style="text-align: center;"><img alt="Workflow of submitting a patch: Preparation | Module Ownership | Creating a patch
-| Testing | Getting Reviews | Addressing Review Comments | Committing the Patch" class="default internal" src="/@api/deki/files/3599/=submitting-patch-workflow.png" style="height: 348px; width: 267px;"></p>
-
-<h2 id="準備">準備</h2>
-
-<p>全てのコードの変更は <a class="link-https" href="https://bugzilla.mozilla.org/" title="https://bugzilla.mozilla.org/">bugzilla.mozilla.org</a> のバグによってトラッキングされています。バグがないものについてはコードレビューされず、レビューされないコードは受け付けません。重複を避けるために変更しようとしている内容が既に存在していないか、<a href="https://bugzilla.mozilla.org/query.cgi?format=specific">バグの検索</a>をし存在しなければファイル(登録)してください。変更についてのほとんどの議論はバグ上で行います。そのため、バグには問題を正しく記載することが解決の鍵です。</p>
-
-<p>バグが正しいプロダクト・コンポーネントとして登録されているか確認してください。もっと情報が欲しい時は、IRC チャンネルの #developers か、ニュースグループに問い合わせてください。</p>
-
-<p>バグを作業している人は bugzilla 内のバグの "assignee" として登録されます。もし誰かがバグにアサインされていれば、その人に変更を調整するためにメールしてください。もしいなければ、バグの状態をあなたが作業していることがわかるようにステータスを変更し、バグの編集権限がある人に自分がアサインでいるよう依頼してください。</p>
-
-<p>パッチが長いこと作られず他のコントリビュータが手をつけないことを避けるため、幾つかのチームでは、アサインされる前にパッチを添付する新しいコントリビュータを待っています。バグのコメントに興味を持つようなことを書くと、チームの誰かが普段使っているプロセスを教えてくれるかもしれません。</p>
-
-<h2 id="モジュールオーナーシップ">モジュールオーナーシップ</h2>
-
-<p>全てのコードは<a href="/ja/docs/">モジュールオーナー</a>によって管理されています。モジュールオーナーはレビューをして変更を許可する役割を持っています。コードを書く前に、モジュールオーナーを確認し、変更提案を許可するか書くにしてください。彼らは新しいユーザーインターフェイス(UI review)、関数(API review)、または変更のテストケースを作成する人を探しています。</p>
-
-<p>もしモジュールオーナーがわからない場合、IRC または ニューズグループに確認した方が良いです。変更するファイル履歴も活用できます。例えば、{{ Source("browser/base/content/browser.js") }} の変更ログを <a href="http://mxr.mozilla.org/mozilla/source/">MXR</a> の "Hg Log" リンクをクリックまたは、<code> hg log browser/base/content/browser.js </code>を実行することで確認します。"r=nickname" のようなログがチェックインメッセージに含まれていてそこからレビューアが誰かを質問することができます。</p>
-
-<h2 id="パッチを作成する">パッチを作成する</h2>
-
-<p>Mozilla ソースコードの変更はパッチで表現されます。パッチはバージョンコントロールにコミットするための基本です。</p>
-
-<p>各パッチは１つの完全な変更を表現し、分割された変更だったらパッチも複数に分割します。もし変更が大きい場合、パッチは複雑になります。その時は、<a href="https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/#many-small-commits">パッチを分割し、小さく簡単に読みやすいパッチに変更するためのステップ</a>を参考にしてください。これは変更のレビューを<a href="http://groups.google.com/group/mozilla.dev.planning/msg/2f99460f57f776ef?hl=en">簡単にし、早いレビューを導き</a>、公式なレビューの良い方法です。</p>
-
-<div class="note">
-<p><strong>Note</strong>: 適切なフォーマットでレビューを簡素化させるためのパッチを作るための情報については、<a href="/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F">patch の精製方法</a>を参照してください。我々の<a href="/docs/Developer_Guide/Reviewer_Checklist">レビューアチェックリスト</a>も参照して良いパッチの作成情報を見てください。</p>
-</div>
-
-<h2 id="テスト">テスト</h2>
-
-<p>すべての変更をテストします。多くの場合、他の変更時にテストできるように<a href="/en-US/docs/Mozilla_automated_testing">自動テスト</a>が要求されます。自動テストができない場合、<a href="/docs/Litmus_tests">Limus tests</a> と呼ばれる手動テストを使ってください。</p>
-
-<p>変更がレグレッションを起こさないようにローカルで自動テストをするか、<a href="https://wiki.mozilla.org/Build:TryServer">Mozilla の try server</a> を使ってください。try server の権限がない場合でも、モジュールオーナーまたは開発者が IRC でジョブを動かすための手助けをしてくれます。</p>
-
-<h2 id="パッチを提出する">パッチを提出する</h2>
-
-<p>もしコントリビュータなら、パッチ提出に MozReview を使うべきです。使い方は <a href="https://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview-user.html">MozReview User Guide</a> を見てください。</p>
-
-<p>もし Mercurial を使う場合、Bugzilla にパッチを添付する仕組みである <a href="https://mozilla-version-control-tools.readthedocs.org/en/latest/hgext.html#bzexport">bzexport extension</a> をインストールします。bzexport の簡単なインストール方法は <code>mach mercurial-setup </code>を実行することです。その後、ターミナルから画面を切り替えることなく、Bugzilla にパッチをアップロードするために <code>hg bzexport -e</code> を実行します。</p>
-
-<p>もし、MozReview や bzexport を使わない場合、bugzilla の <em>Add an attachment </em>リンクを使ってバグにパッチを添付します。レビューアや bugzilla ユーザーがパッチを読めるように <em>patch</em> チェックボックスにチェックを入れてください。</p>
-
-<p>一部のパッチのアプローチ手段を確認したり、フィードバックを問い合わせすることを恐れないでください。コードと一緒に質問をされた時にコメントしたり提案することはとても簡単なことです。</p>
-
-<h2 id="Getting_the_patch_reviewed" name="Getting_the_patch_reviewed">レビューを受ける</h2>
-
-<p>コードレビューを通すことは Mozilla の品質管理の一つです。すべてのパッチはモジュールオーナーまたは、支持したピアによってレビューされます。モジュールを跨いだり、API を変更したり、セキュリティ関係の変更をする場合、レビューに加え、<a class="external" href="http://www.mozilla.org/hacking/reviewers.html">super-review</a> も必須です。</p>
-
-<p>レビュープロセスについての詳しい情報は、<a class="internal" href="/en-US/docs/Code_Review_FAQ" title="/en-US/docs/Code Review FAQ">code review FAQ</a> をご覧ください。もし変更がユーザーインターフェイスに影響を与える場合、<a href="/docs/Developer_Guide/Requesting_feedback_and_ui-review_for_desktop_Firefox_front-end_changes">フィードバッグやデスクトップ版 Firefox のフロントエンド変更のためによる ui-review を要求してください</a>。<br>
- <br>
- <br>
- <img alt="request-review.png" class="internal rwrap" src="/@api/deki/files/3598/=request-review.png" style="border: 1px solid black; float: right; height: 149px; width: 519px;">レビューやスーパーレビューを要求するには、bugzilla の添付ファイルリンクの詳細(Details)をクリックします。左側にラベルと共にドロップダウンが存在します。"review" を見つけ、フラグを"?"に変更し、モジュールオーナーかパッチをレビューしてくれるピアのメールアドレスを入力します。最後に送信することを忘れないでください！</p>
-
-<p><em>注意:</em> もしレビューアが１週間ほど応答しない場合は以下の方法をとってください:</p>
-
-<ul>
- <li>Moizlla の IRC サーバーの <a class="link-irc" href="irc://irc.mozilla.org/developers">#developers</a> に参加し、誰かレビューが遅れている理由を知っているか聞いてください。(その時に一緒にバグのリンクを添えてください）</li>
- <li>もしレビューがされていなければ、直接レビューアにメールをして、いつレビューができるか、または誰か他にレビューができないか聞いてください。</li>
- <li>最後の手段としてnews.mozilla.org のニュースグループに問い合わせてみてください。</li>
-</ul>
-
-<h2 id="レビューコメントを修正する">レビューコメントを修正する</h2>
-
-<p>最初っからパッチがパーフェクトな事はありません。レビューアは "review-" をつけ、そしてパッチを許可する前に修正すべき問題点を教えてくれます。要求しているリビジョンは参加を阻害する意図ではなく、変更の完成度を可能な限り良いものにするために奨励しているということを忘れないでください。レビューアの助言を注意深く修正し、新しいパッチを添付して再度レビューを出してください。</p>
-
-<p>時々レビューアは"review+" と共に、スペルミスやインデントミスなどの修正すべき小さな変更を指摘する場合があります。全ての指摘を修正するべきですが、再レビューは不要です。変更を作成し、リビジョンを改訂したのちに、添付ファイルページに表示されている元のパッチの obsolete チェックボックスにチェックを入れてください。もしそのリビジョンに不安がある場合は、レビューを要求してください。</p>
-
-<p>時々レビューした後で、コミット前の場合、誰かが衝突する変更を加えることがあります。もしマージがシンプルで影響を与えないような場合、アップデートしたバージョンのパッチを投稿します。それ以外はレビューが必要です。</p>
-
-<p>もしレビュープロセスが２週間以上止まっている場合は、上述している "注意" を参考にしてください。</p>
-
-<p>多くのオープンソースプロジェクトで、開発者は完全な状態でもパッチを許可し、それを完了し適用ます。Mozilla の文化では、<strong>レビューアはレビューだけして、パッチにコメント</strong>します。もし パッチ提出者が作成したリビジョンを諦めた場合、誰かがバグを引き取るまではパッチは存在し続けます。</p>
-
-<h2 id="Getting_the_patch_checked_into_the_tree" name="Getting_the_patch_checked_into_the_tree">パッチをコミットする</h2>
-
-<p>レビューが完了したらパッチはコミットできます。</p>
-
-<div class="note">
-<p>パッチが適用されたアプリケーションをビルドしてください。それが動作させて自動テスト(そして完了したバグの動作)を確認し、 <a class="link-https" href="https://wiki.mozilla.org/Build:TryServerAsBranch" title="https://wiki.mozilla.org/Build:TryServerAsBranch">try server</a> にプッシュしてください。(この時もコメントにバグを明記します)<br>
- テストしないパッチを提出するとコミッターの時間を浪費し、ツリーを炎上させます。全ての必要な確認を完了することで、全員の時間と努力を節約してください。</p>
-
-<p>コミッターがパッチをチェックしやすいように、パッチを<a href="/docs/Creating_a_patch_that_can_be_checked_in">適切なフォーマット</a>で作成してください。</p>
-</div>
-
-<p>バグに <a class="link-https" href="https://bugzilla.mozilla.org/describekeywords.cgi#checkin-needed"><code>checkin-needed</code></a> キーワードをつけます。(またはバグの変更権限がない場合は、誰かに追加してもらえるよう訪ねてください) コミット権限を持ったコミュニティーメンバーは通常１日程度で checkin-needed キーワードを持ったバグを見つけ、コミットします。もしパッチが時間帯によってチェックインされていない場合は、<a class="external" href="http://irc.mozilla.org/">irc.mozilla.org</a> の <a class="external" href="http://irc.mozilla.org/developers">#developers</a> に参加し、あなたの代わりにチェックインできる人を聞いてください。ほとんどの場合、ランド後に新しい問題をパッチが引き起こさないことを確認するために Try の実行結果のリンクが必要です。</p>
-
-<p>もし自身でコミットできる場合は、<a href="/en-US/docs/Developer_Guide/Committing_Rules_and_Responsibilities" title="/en-US/docs/Developer Guide/Committing Rules and Responsibilities">Committing Rules and Responsibilities</a> に従うことを忘れないでください。</p>
-
-<h2 id="Getting_the_patch_checked_into_the_tree" name="Getting_the_patch_checked_into_the_tree">レグレッション</h2>
-
-<p>自身の変更により、機能またはパフォーマンスのレグレッションが発生した状態です。特にパフォーマンスレグレッションの厳しい<a href="http://www.mozilla.org/hacking/regression-policy.html">ポリシー</a>があります。これは変更したコードがよくバックアウトされてしまうことがあり、修正して再提出する必要があるということです。レグレッションはテスト(自身がチェックイン前に行ったもの、また実施していないもの)が包括的に不十分ということを意味し、パッチを再提出するか、適切なテストを伴うレグレッションの修正をする必要があります。</p>
-
-<p>いくつかパッチを作成したら、<a href="http://www.mozilla.org/hacking/committer/">Mozilla source code のコミット権を取得する</a>ことも考えてみてください。</p>
diff --git a/files/ja/mozilla/developer_guide/index.html b/files/ja/mozilla/developer_guide/index.html
deleted file mode 100644
index e3a8b873d0..0000000000
--- a/files/ja/mozilla/developer_guide/index.html
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: 開発者ガイド
-slug: Mozilla/Developer_Guide
-tags:
-  - Developing Mozilla
-translation_of: Mozilla/Developer_guide
----
-<p><span class="seoSummary">Mozilla プロジェクトへ貢献する方法は、コーディング・テスト・ビルドプロセス/ツールの改善・ドキュメントへの貢献など多くの方法があります。このドキュメントは Mozilla 貢献者向けの情報だけでなく、経験豊富な貢献者にも役に立つ情報を提供します。</span></p>
-
-<div class="row topicpage-table">
-<div class="section">
-<h2 class="Documentation" id="Documentation_topics">Documentation topics</h2>
-
-<dl>
- <dt><a href="/docs/Introduction" title="Introduction">Getting Started</a></dt>
- <dd>A step-by-step beginner's guide to getting involved with Mozilla.</dd>
- <dt><a href="/docs/Mozilla/Developer_guide/Articles_for_new_developers">For new Mozilla developers</a></dt>
- <dd>A directory of articles which are particularly helpful for new Mozilla developers.</dd>
-</dl>
-
-<dl>
- <dt><a class="internal" href="/docs/Developer_Guide/Source_Code" title="en-US/docs/Developer_Guide/Source_Code">Working with Mozilla Source Code</a></dt>
- <dd>A code overview, how to get the code, and the coding style guide.</dd>
- <dt><a class="internal" href="/docs/Developer_Guide/Build_Instructions" title="en-US/docs/Developer_Guide/Build_Instructions">Build Instructions</a></dt>
- <dd>How to build Firefox, Thunderbird, SeaMonkey, or other Mozilla applications.</dd>
- <dt><a href="/docs/Developer_Guide/Development_process_overview" title="en-US/docs/Developer Guide/Development process overview">Development process overview</a></dt>
- <dd>An overview of the entire Mozilla development process.</dd>
- <dt><a href="/docs/Mozilla/Multiple_Firefox_Profiles" title="en-US/docs/Mozilla/Multiple_Firefox_Profiles">Managing multiple profiles</a></dt>
- <dd>When working with prerelease versions of Firefox, it's often helpful to have multiple Firefox profiles, such as one for each channel, or for different kinds of testing.</dd>
- <dt><a class="internal" href="/docs/Mozilla_automated_testing" title="en-US/docs/Mozilla automated testing">Automated Testing</a></dt>
- <dd>How to run Mozilla's automated tests, and how to write new tests.</dd>
- <dt><a class="internal" href="/docs/Developer_Guide/How_to_Submit_a_Patch" title="en-US/docs/Getting your patch in the tree">How to submit a patch</a></dt>
- <dd>After getting your patch written, you need to get it checked into the tree. This article explains the review process and how to get your patch approved.</dd>
- <dt><a href="/docs/Developer_Guide/Getting_documentation_updated" title="en-US/docs/Developer_Guide/Getting documentation updated">Getting documentation updated</a></dt>
- <dd>How to ensure that documentation is kept up to date as you develop.</dd>
- <dt><a class="internal" href="/docs/Mozilla_Modules_and_Module_Ownership" title="en-US/docs/Mozilla Modules and Module Ownership">Mozilla modules and module ownership</a></dt>
- <dd>This article provides information about Mozilla's modules, what the role of a module owner is, and how module owners are selected.</dd>
- <dt><a class="internal" href="/docs/Code_snippets" title="en-US/docs/Code_snippets">Code snippets</a></dt>
- <dd>Useful code samples for a wide variety of things you might need to figure out how to do.</dd>
- <dt><a class="internal" href="/docs/Mozilla_Development_Strategies" title="en-US/docs/Mozilla Development Strategies">Mozilla development strategies</a></dt>
- <dd>Tips for how to make the most of your time working on the Mozilla project.</dd>
- <dt><a class="internal" href="/docs/Debugging" title="en-US/docs/Debugging">Debugging</a></dt>
- <dd>Find helpful tips and guides for debugging Mozilla code.</dd>
- <dt><a href="/docs/Performance" title="en-US/docs/Performance">Performance</a></dt>
- <dd>Performance guides and utilities to help you make your code perform well (and to play nicely with others).</dd>
- <dt><a class="internal" href="/docs/The_Mozilla_platform" title="en-US/docs/The Mozilla platform">The Mozilla platform</a></dt>
- <dd>Information about the workings of the Mozilla platform.</dd>
- <dt><a href="/docs/Developer_Guide/Adding_APIs_to_the_navigator_object" title="en-US/docs/Developer_Guide/Adding_APIs_to_the_navigator_object">Adding APIs to the navigator object</a> {{ gecko_minversion_inline("9.0") }}</dt>
- <dd>How to augment the {{ domxref("window.navigator") }} object with additional APIs.</dd>
- <dt><a href="/docs/Developer_Guide/Interface_Compatibility" title="en-US/docs/Developer Guide/Interface Compatibility">Interface Compatibility</a></dt>
- <dd>Guidelines for modifying scriptable and binary APIs in Mozilla.</dd>
- <dt><a href="/docs/Developer_Guide/Customizing_Firefox" title="en-US/docs/Developer Guide/Customizing Firefox">Customizing Firefox</a></dt>
- <dd>Information about creating customized versions of Firefox.</dd>
- <dt><a href="/docs/Developer_Guide/Virtual_ARM_Linux_environment" title="Virtual ARM Linux environment">Virtual ARM Linux environment</a></dt>
- <dd>How to set up an ARM emulator running Linux for testing ARM-specific, but not necessarily platform-specific, code. Useful for mobile developers.</dd>
- <dt><a href="/docs/Introduction/Obsolete_Build_Caveats_and_Tips" title="Obsolete Build Caveats and Tips">Obsolete Build Caveats and Tips</a></dt>
- <dd>A place to put build tips which are no longer relevant to building the latest version of the code from main but are relevant when building old codebases.</dd>
-</dl>
-</div>
-
-<div class="section">
-<h2 class="Tools" id="ツール">ツール</h2>
-
-<dl>
- <dt><a class="link-https" href="https://bugzilla.mozilla.org/" title="https://bugzilla.mozilla.org/">Bugzilla</a></dt>
- <dd>The <a class="internal" href="/docs/Bugzilla" title="en-US/docs/Bugzilla">Bugzilla</a> database used to track issues for Mozilla projects.</dd>
- <dt><a class="external" href="https://mxr.mozilla.org/">MXR</a></dt>
- <dd>Browse and search the Mozilla source code repository on the Web.</dd>
- <dt><a href="https://dxr.mozilla.org/">DXR</a></dt>
- <dd>Next generation of searching Mozilla's source code. In active development.</dd>
- <dt><a class="external" href="https://bonsai.mozilla.org/cvsqueryform.cgi">Bonsai</a></dt>
- <dd>The <a class="internal" href="/docs/Bonsai" title="en-US/docs/Bonsai">Bonsai</a> tool lets you find out who changed what file in the repository, and when they did it.</dd>
- <dt><a class="internal" href="/docs/Mercurial" title="en-US/docs/Mercurial">Mercurial</a></dt>
- <dd>The distributed version-control system used to manage Mozilla's source code.</dd>
- <dt><a href="https://developer.mozilla.org/docs/Mozilla/Developer_guide/Using_the_VM">Mozilla build VM</a></dt>
- <dd>A VirtualBox compatible virtual machine configured with all the software needed to build and work on Firefox.</dd>
- <dt><a class="external" href="https://treeherder.mozilla.org/">Treeherder</a></dt>
- <dd>Treeherder shows the status of the tree (whether or not it currently builds successfully). Check this before checking in and out, to be sure you're working with a working tree.</dd>
- <dt><a class="internal" href="/docs/Crash_reporting" title="en-US/docs/Crash reporting">Crash tracking</a></dt>
- <dd>Information about the <a class="link-https" href="https://crash-reports.mozilla.com/reports">Socorro</a> crash reporting system.</dd>
- <dt>Performance tracking: <a href="https://datazilla.mozilla.org/">Datazilla</a> and <a href="https://graphs.mozilla.org/">Graphs</a></dt>
- <dd>See performance information for Mozilla projects.</dd>
- <dt><a href="/docs/Developer_Guide/Callgraph" title="en-US/docs/Developing Mozilla/Callgraph">Callgraph</a></dt>
- <dd>A tool to help perform static analysis of the Mozilla code by generating callgraphs automatically.</dd>
- <dt><a class="external" href="https://www.mozilla.org/community/developer-forums.html">Developer forums</a></dt>
- <dd>A topic-specific list of discussion forums where you can talk about Mozilla development issues.</dd>
- <dt><a class="external" href="http://www.codefirefox.com/cheatsheet/">Mozilla Platform Development Cheat Sheet</a></dt>
- <dd>Brian Bondy's list of frequently referenced information for platform developers.</dd>
- <dt><a class="external" href="http://www.codefirefox.com/videos/">Firefox development video tutorials</a></dt>
- <dd>Brian Bondy's video tutorials on Firefox development.</dd>
-</dl>
-</div>
-</div>
-
-<p> </p>
diff --git a/files/ja/mozilla/developer_guide/mozilla-central/index.html b/files/ja/mozilla/developer_guide/mozilla-central/index.html
deleted file mode 100644
index 42ac0e362d..0000000000
--- a/files/ja/mozilla/developer_guide/mozilla-central/index.html
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: mozilla-central
-slug: Mozilla/Developer_guide/mozilla-central
-tags:
-  - Developing Mozilla
-  - Mercurial
-translation_of: Mozilla/Developer_guide/mozilla-central
-original_slug: mozilla-central
----
-<p><b><code>mozilla-central</code></b> は Mozilla ソースコードの <a href="ja/Mercurial">Mercurial</a> リポジトリです: <a class=" external" href="http://hg.mozilla.org/mozilla-central" rel="freelink">http://hg.mozilla.org/mozilla-central</a> 。これは、Mozilla 2 コードベースに編入される変更のための、安定した統合ポイントです。
-</p><p>mozilla-central の <a href="ja/Tinderbox">Tinderbox</a> ページは <a class=" external" href="http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla2" rel="freelink">http://tinderbox.mozilla.org/showbui...?tree=Mozilla2</a> に位置しています。
-{{ Note("Mozilla CVS リポジトリとは異なり、mozilla-central には Firefox と XULRunner のソースのみが含まれています。他のアプリケーションやプロジェクト固有のコードについては別のリポジトリが使用されます。") }}
-{{ 英語版章題("mozilla-central tree rules") }}
-</p>
-<h3 id="mozilla-central_.E3.83.84.E3.83.AA.E3.83.BC.E8.A6.8F.E5.89.87" name="mozilla-central_.E3.83.84.E3.83.AA.E3.83.BC.E8.A6.8F.E5.89.87"> mozilla-central ツリー規則 </h3>
-<p>mozilla-central コードベースは、<a href="ja/Supported_build_configurations">tier-1 プラットフォーム</a>上では常に stable でなくてはなりません:
-</p>
-<ul><li> 自動化されたユニットテストをパスすること。
-</li><li> 自動化されたパフォーマンステストおよびリークテストは退行しないこと。
-</li><li> どの退行バグも、やっかいなパッチを即座にバックアウトする原因になります。
-</li></ul>
-<p>{{ 英語版章題("API Changes") }}
-</p>
-<h4 id="API_.E3.81.AE.E5.A4.89.E6.9B.B4" name="API_.E3.81.AE.E5.A4.89.E6.9B.B4"> API の変更 </h4>
-<p>1.9.1 への準備のため、API の変更については以下の規則が適用されます:
-</p>
-<ul><li> <strong>{{ 原語併記("凍結", "frozen") }}</strong> された API の変更は現在許可されていません。
-</li><li> <strong>{{ 原語併記("未凍結", "nonfrozen") }}</strong> の API の変更はよく考えて慎重に行うべきです。
-<ul><li> JS 拡張仕様にインパクトのある変更は避けるか最小限に止め、注意しながら <a href="ja/Firefox_3.1_for_developers">文書化</a> すべきです。
-</li><li> レビュアは必要な場合、API の変更を明確に承認すべきです。
-</li><li> 疑問があれば mozilla.dev.platform や mozilla.dev.apps.firefox ニュースグループで尋ねてください。
-</li></ul>
-</li></ul>
-<p>この規則は 1.9.1 branch の後で変更されます。
-</p><p>{{ 英語版章題("Pushing changes to mozilla-central") }}
-</p>
-<h3 id="mozilla-central_.E3.81.AB.E5.A4.89.E6.9B.B4.E3.82.92.E3.83.97.E3.83.83.E3.82.B7.E3.83.A5.E3.81.99.E3.82.8B" name="mozilla-central_.E3.81.AB.E5.A4.89.E6.9B.B4.E3.82.92.E3.83.97.E3.83.83.E3.82.B7.E3.83.A5.E3.81.99.E3.82.8B"> mozilla-central に変更をプッシュする </h3>
-<p>CVS チェックインアクセス権をもつすべての開発者は、<a class="link-https" href="https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&amp;component=Server+Operations:+Account+Requests">バグを投稿</a>して、hg.mozilla.org にプッシュするための LDAP ログインの詳細が書かれた Email を受信してください。変更セットをサーバにプッシュするには &lt;tt&gt;hg push&lt;/tt&gt; コマンドを使用します。
-</p>
-<ul><li> 変更は、複数の head を mozilla-central に導入しないこと。
-</li><li> 履歴をきれいに保つこと。履歴をちらかす多くの "作業中" の変更セットよりも、一つのコミットまたはいくつかの個別の変更セットが好ましい。チェックインする前にパッチを管理する <a href="ja/Mercurial_queues">Mercurial queues</a> の使用を検討してください。
-</li><li> 少なくともプッシュされた最後の変更セットには、変更に関するバグ番号とレビュアを記載すること。
-</li><li> 変更は <code><a class=" external" href="ssh://hg.mozilla.org/mozilla-central/" rel="freelink">ssh://hg.mozilla.org/mozilla-central/</a></code> にプッシュすること。詳しい設定の仕方は <a href="ja/Mercurial_FAQ#How_do_I_check_stuff_in.3F">Mercurial FAQ#How do I check stuff in?</a> を確認してください。
-</li></ul>
-<p>{{ 英語版章題("See also") }}
-</p>
-<h3 id=".E5.8F.82.E7.85.A7" name=".E5.8F.82.E7.85.A7"> 参照 </h3>
-<ul><li> <a class="external" href="http://developer.mozilla.org/devnews/index.php/2008/06/02/mozilla-central-open-for-business/">mozilla-central: open for business</a> devnews の投稿。
-</li><li> <a class="link-https" href="https://bugzilla.mozilla.org/showdependencytree.cgi?id=433384&amp;hide_resolved=1">Tracking: issues making development difficult on mozilla-central</a>
-</li></ul>
-<div class="noinclude">
-</div>
-{{ languages( { "en": "en/Mozilla-central", "es": "es/Mozilla-central" } ) }}
diff --git a/files/ja/mozilla/developer_guide/mozilla_build_faq/index.html b/files/ja/mozilla/developer_guide/mozilla_build_faq/index.html
deleted file mode 100644
index f14b507b5b..0000000000
--- a/files/ja/mozilla/developer_guide/mozilla_build_faq/index.html
+++ /dev/null
@@ -1,363 +0,0 @@
----
-title: Mozilla Build FAQ
-slug: Mozilla/Developer_Guide/Mozilla_Build_FAQ
-tags:
-  - Build documentation
-  - Developing Mozilla
-translation_of: Mozilla/Developer_guide/Mozilla_build_FAQ
----
-<p>こちらもご参照ください：</p>
-
-<ul>
- <li><a href="/ja/Debugging_Mozilla_on_Windows_FAQ" title="ja/Debugging_Mozilla_on_Windows_FAQ">Debugging Mozilla on Windows FAQ</a>: Windows 上での Mozilla のデバッグ方法の Tips</li>
-</ul>
-
-<p> </p>
-
-<h3 id=".E5.85.A8.E4.BD.93.E7.9A.84.E3.81.AA.E8.B3.AA.E5.95.8F" name=".E5.85.A8.E4.BD.93.E7.9A.84.E3.81.AA.E8.B3.AA.E5.95.8F">全体的な質問</h3>
-
-<dl>
- <dt id="platform">Mozilla ビルドプラットフォームはどのシステムでサポートされていますか？</dt>
- <dd>Mozilla ビルド "サポート" には複数のレベルまたは段階があります。
- <p>第 1 段階のプラットフォームは開発のプライマリーフォーカスであるプラットフォームが該当します。これらのプラットフォーム上での主要な問題はショーストッパーによって重んじられます。これらはまた <a class="external" href="http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey">SeaMonkey tinderbox ページ</a>に現れるプラットフォームです。</p>
-
- <ul>
-  <li>linux/x86 (gcc)</li>
-  <li>win32/x86 (msvc)</li>
-  <li>OS X (gcc)</li>
- </ul>
-
- <p>第 2 段階のプラットフォームは積極的にメンテナンスしようとしている開発者と貢献者の小さく変化しているサブセットのプラットフォームです。しかし全体の開発はこれらのプラットフォーム上での問題のために停止しません。これらのプラットフォームは大抵、<a class="external" href="http://tinderbox.mozilla.org/SeaMonkey-Ports/">SeaMonkey-Ports tinderbox ページ</a>に Ports として参照されます。 第 2 段階のプラットフォームは：</p>
-
- <ul>
-  <li>aix 4.3 (aCC)</li>
-  <li>beos 5.0.3 (gcc)</li>
-  <li>bsdi 4.x (gcc)</li>
-  <li>hpux 10.x,11.x (HP cc)</li>
-  <li>irix 6.x/gcc (gcc/MIPSpro)</li>
-  <li>linux/ppc (gcc)</li>
-  <li>os/2 (gcc)</li>
-  <li>osf1 5.x (Compaq cc)</li>
-  <li>solaris (sparc &amp; x86) 2.6+ (gcc/Forte)</li>
- </ul>
-
- <p>第 3 段階のプラットフォームは全体的にプロジェクトの主要な開発者が活動的でないプラットフォームですが修正がサードパーティによってもたらされています。 第 3 段階のプラットフォームは：</p>
-
- <ul>
-  <li>freebsd (gcc)</li>
-  <li>linux/alpha (gcc)</li>
-  <li>netbsd (gcc)</li>
-  <li>openvms (?)</li>
-  <li>ps2linux (gcc)</li>
-  <li>qnx 6 (gcc)</li>
-  <li>win32/x86 (gcc)</li>
- </ul>
-
- <p>その他の全てのプラットフォームは主要な mozilla 開発者によって "サポート外" です。"サポート外" は本当に "重要でなく活動的でないもの" を意味します。</p>
-
- <p>ほとんどの Mozilla 開発者は第 1 段階以外のプラットフォームにアクセスしません。なので第 1 段階以外のプラットフォームに対するどんなバグも問題の原因と適切な解決策を定めバグのオーナーを助ける情報で満ちているべきです。あなたがパッチもしくは開発者のパッチがあなたのプラットフォームで動作することを立証するものを準備しているなら、それはあなたのバグを修正しツリーにチェックするのを大変、助けるでしょう。</p>
-
- <p> </p>
- </dd>
- <dt>Mozilla はどんなタイプのビルドシステムを使いますか？</dt>
- <dd>Mozilla は全てのプラットフォーム上で動作が弱弱しい GNU 設定レイヤーに加えて再帰的なレガシー Netscape makefile ビルドシステムを使います。ほとんどの設定ベースのプロジェクトのように、設定スクリプトを生成するために GNU autoconf を使います。GNU make はビルド過程を進めるのに使われます。
- <p> </p>
- </dd>
- <dt>なぜ GNU make を使うのですか？</dt>
- <dd>GNU make は多くのシステムへ移植されています。これは Mozilla をこれらのシステムに少し簡単に移植します。10 の異なったプラットフォームで特有の make プログラムによってサポートされている make 機能の唯一のサブセットを使うことはビルドシステムに不必要なコンパイルを引き起こすでしょう。
- <p> </p>
- </dd>
- <dt>make のその他のバージョンで動作しますか？</dt>
- <dd>いいえ。Mozilla makefile は GNU make でのみ動作する特有の機能を使っています。
- <p> </p>
- </dd>
- <dt>なぜあなた方は automake を使わないのですか？</dt>
- <dd>Netscape レガシーシステムの一部は GNU make の使用を必要としています -それらを使うのを必要としている Makefile の少数のファイルから共通のルールセットを含む機能を含んでいます。この中心のルールシステムで、主要な automake のセリングポイントの 1 つは重要度が低いものでした。また当時、Mozilla のビルドライブラリの方式はライブツールと調和していませんでした。
- <p> </p>
- </dd>
- <dt>nmake と CodeWarrior ビルドシステムで何が起こりますか？</dt>
- <dd>それらは現在のツリーで長く存在しません。nmake ビルドサポートは Mozilla 1.2a リリースサイクルの間に中止されました。mac cfm ビルドシステムは Mozilla 1.3 リリース後、すぐの OS9 サポートと共に中止されました。
- <p> </p>
- </dd>
- <dt>なぜ ant、tmake、scons または <em>あなたの好みのビルドシステムをここに挿入してください</em>？</dt>
- <dd>主に、Mozilla をこれらのシステムで実行する人がいなかったからです。Mozilla が最初にオープンソースにされた時、それはただレガシー Netscape システムを含むだけでした。autoconf レイヤーはunix ビルドで標準ビルドシステムになる前、 6 ヶ月間でブランチへの追加とメンテナンスが並行して行われました。
- <p> </p>
- </dd>
- <dt>私の気に入ったビルドシステムで Mozilla を実行する場合、 Mozilla はそれを使って起動しますか？私はそれを使うかどうかで私の時間を無駄にしたくない。</dt>
- <dd>Mozilla に書かれたどんなコードもデフォルトツリーに受け入れられるという保証はありません。実行されたどんなビルドシステムもそれが現在のビルドシステムよりも全体的に良いことを示さなければなりません。速さ、適応性、ポータビリティそして現在のビルドシステムで 3 年以上の経験がある開発者の大きなグループに簡単に新しいシステムに移ってもらう能力が切り替えを決める中で主要な要因になります。あなたが本気でかつ、多くの仕事をするのをいとわないのであれば、あなたの提案の詳細を話し合うために <a href="/User:Benjamin_Smedberg">en:User:Benjamin Smedberg</a> にコンタクトを取ってください。
- <p> </p>
- </dd>
- <dt>なぜ Mozilla は autoconf 2.5x をサポートしないのですか？</dt>
- <dd>単に、autoconf 2.5x は、アップグレードを努力してみる価値があるようにする何も提供しません。 Autoconf 2.5x は autoconf 2.13 との共存へ戻れず、更に制限は autoconf の新しいバージョンが不確かな増加のために Mozilla ビルドシステムの重大な書き直しを要求することによって引き起こされます。
- <p>サブ設定のための引数を通すための能力のように 2.13 機能のいくつかは 2.5x で利用できません。人々は好意的な返答無しに autoconf メーリングリストでこれらの機能について繰り返し尋ねてきました。Mozilla (NSPR &amp; LDAP) のサブプロジェクトの設定の書き直しは受け入れることのできない取引です。サブプロジェクトはまた独立したプロジェクトでビルドシステムの相反が馬鹿げているせいで全体のコードベースが分岐しています。</p>
-
- <p> </p>
- </dd>
- <dt>なぜ NSS は autoconf を使わないのですか？</dt>
- <dd>NSS プロジェクトはまた Mozilla プロジェクトの外で使われており、NSS プロジェクトのメンバーは autoconf へ移行することはコスト価値があることとは感じませんでした。詳細は{{ Bug(52990) }}を見てください。
- <p> </p>
- </dd>
- <dt>1 つのソースツリーから多様な Mozilla ベースのプロジェクトをビルドしても良いですか？</dt>
- <dd>はい！それぞれのプロジェクトでそれ自身のオブジェクトディレクトリでビルドされなければなりません。
- <p> </p>
- </dd>
- <dt>オブジェクトディレクトリとは何ですか？</dt>
- <dd>オブジェクトディレクトリビルドはソースのある場所と異なった場所に出力されたファイルを作るプロセスを適用します。これは、ほとんどの設定ベースのプロジェクトの標準的な機能です。それはネットワークファイルシステムを使うなら多様なプラットフォームを含む多様な設定のために 1 つのソースツリーからビルドするのを許します。あなたのツリー中のファイルがビルドプロセスによって変更されなかったことを知るには、ソースツリーを汚すのを避けます。
- <p>もし手動で設定を実行したなら、ディスク上の適当な場所に空のディレクトリを作りそのディレクトリに移ってそこから /path/to/mozilla/configure を実行するという標準的な方法を使うことができます。</p>
-
- <pre class="eval">mkdir obj-debug
-cd obj-debug
-../mozilla/configure
-</pre>
-
- <p>ビルドするのに client.mk を使ったなら、mozconfig ファイルを以下のように追加できます：</p>
-
- <pre class="eval">mk_add_options MOZ_OBJDIR=/path/to/objdir
-</pre>
-
- <p> </p>
- </dd>
- <dt>Mozilla をクロスコンパイルして良いですか？</dt>
- <dd>はい、詳細については <a class="external" href="http://www.mozilla.org/build/cross-compiling.html">Mozilla クロスコンパイル</a>ドキュメントを見てください。いいえ、<a class="external" href="http://www.vmlinux.org/joachim/mirror/www.objsw.com/CrossGCC/FAQ-4.html#ss4.9">カナダ英語クロスコンパイル</a>はサポートされていません。
- <p> </p>
- </dd>
- <dt>How can I test out a build of just certain files, instead of the whole tree, while I'm changing code? 私がコードを変更している間に全体のツリーの代わりに特定のファイルだけをテストするにはどうすれば良いですか？</dt>
- <dd>あなたのオブジェクトディレクトリを変更してください、ビルドしたい特定のディレクトリ（オブジェクトディレクトリのディレクトリ構造はソースディレクトリの構造と合致します）に入れ替えてください、そして "make" （必要ならばまたは "gmake"）とタイプしてください。これはただ "Makefile" （ソースツリーの同等のディレクトリは "Makefile.in" に含まれるでしょう）が含まれているディレクトリを見つけた時にのみ動作します。それよりもよりはっきりと得たいならば、"make &lt;ファイル名&gt;.obj" をしてみることが出来ます。<a href="/ja/Incremental_Build" title="ja/Incremental_Build">Incremental Build</a> をご覧ください。
- <p> </p>
- </dd>
- <dt>Mozilla への並列 (make -j) ビルドは動作しますか？</dt>
- <dd>はい。最適な処理についての入り口は <a class="external" href="http://www.gnu.org/software/make/manual/html_node/Parallel.html">GNU Make 並列実行</a>マニュアルを見てください。
- <p>並列ビルド（特に可能な限り並列で多くのタスクを実行するために -jN の代わりに -j を使っている時）を使っている時に不明瞭なビルドエラーが出る場合、N の減少による並列タスク数を減らしてみてください（または無制限の並列処理を使った場合、小さい数字 N を -j に追加してください）。</p>
-
- <p>-j4 と -j8 を並列ビルドで用いるとよく動作するようです。</p>
-
- <p> </p>
- </dd>
- <dt>ビルドシステムに私の mozconfig ファイルへの変更を集めるよう強いるにはどうすれば良いですか？</dt>
- <dd>ツリー中の設定スクリプトに接してください。mozconfig ファイルは MOZCONFIG 環境変数によってどこにでも存在でき、ファイル上に明白な依存物はありません
- <p> </p>
- </dd>
- <dt>error: file '../../toolkit/locales/en-US/chrome/necko/contents.rdf' doesn't exist at ../../config/make-jars.pl line 418, &lt;STDIN&gt; line 9.</dt>
- <dd>あなたは <a href="/ja/Configuring_Build_Options" title="ja/Configuring_Build_Options">Configuring Build Options</a> 上の説明に従わずに Firefox をビルドしようとしています。特に、あなたの mozcconfig ファイルは Firefox をデフォルトの mozconfig ファイルで調達しなければなりません：
- <pre class="eval">. $topsrcdir/browser/config/mozconfig
-# ここに好みの追加オプションを追加してください
-</pre>
-
- <p> </p>
- </dd>
- <dt>Initial cvs checkout fails with the message: <code>cvs {{ mediawiki.external('checkout aborted') }}: *PANIC* administration files missing</code></dt>
- <dd>"CVS" という名前のディレクトリの元に cvs ツリーを作ることはできません。これは cvs の機能/バグです。cvs は特定の管理ファイルを CVS ディレクトリで見つけ、それらが行方不明である場合には不満を言うでしょう。
- <p> </p>
- </dd>
- <dt>Error: ../coreconf/rules.mk:406: target `c' doesn't match the target pattern</dt>
- <dd>make 3.80 が必要で 3.81 のようなその他のバージョンは必要ありません。
- <ul>
-  <li>make 3.80 は長く Cygwin セットアップインストーラで利用されていません。なのであなた自身でそれを見つけなければなりません。make-3.80-1.tar.bz2 と google でき、それはまた<a class="external" href="http://cygwin.paracoda.com/release/make/make-3.80-1.tar.bz2">ここ</a>から入手できます。</li>
- </ul>
-
- <p> </p>
- </dd>
-</dl>
-
-<h3 id="Mac_.E7.89.B9.E6.9C.89.E3.81.AE.E8.B3.AA.E5.95.8F" name="Mac_.E7.89.B9.E6.9C.89.E3.81.AE.E8.B3.AA.E5.95.8F">Mac 特有の質問</h3>
-
-<p> </p>
-
-<dl>
- <dt>Mozilla アプリケーションを Universal Binary としてビルドしても良いですか？</dt>
- <dd>はい。説明については <a href="/ja/Mac_OS_X_Universal_Binaries" title="ja/Mac_OS_X_Universal_Binaries">Mac OS X Universal Binaries</a> を見てください。
- <p> </p>
- </dd>
- <dt>編集を助けるためにどのように distcc 上で起動すれば良いですか？</dt>
- <dd>未定
- <p> </p>
- </dd>
- <dt>UFS 上で Mozilla はビルドされていますか？</dt>
- <dd>はい、{{ Bug(157036) }} から修正されています。
- <p> </p>
- </dd>
- <dt>Mozilla を UFS で実行されていますか？</dt>
- <dd>はい。
- <p> </p>
- </dd>
- <dt>Mach-0 ビルドをコンパイルするために CodeWarrior を使っても良いですか？</dt>
- <dd>いいえ、CodeWarrior は死んでいます。詳細については {{ Bug(119589) }} を見てください。
- <p> </p>
- </dd>
- <dt>例えばレイアウトがリビルドされた後、どのように FirefoxDebug.app にその変更をさせれば良いでしょうか？</dt>
- <dd>make -C browser/app</dd>
-</dl>
-
-<p>よく起こる Mac ビルドエラーと追加のトラブルシューティング tips については <a href="/ja/Developer_Guide/Build_Instructions/Mac_OS_X_Build_Prerequisites" title="ja/Developer_Guide/Build_Instructions/Mac_OS_X_Build_Prerequisites">Mac OS X Build Prerequisites</a>　の <a href="/ja/Developer_Guide/Build_Instructions/Mac_OS_X_Build_Prerequisites#Troubleshooting" title="ja/Developer_Guide/Build_Instructions/Mac_OS_X_Build_Prerequisites#Troubleshooting">トラブルシューティング</a>を見てください。</p>
-
-<h3 id="Win32_.E7.89.B9.E6.9C.89.E3.81.AE.E8.B3.AA.E5.95.8F" name="Win32_.E7.89.B9.E6.9C.89.E3.81.AE.E8.B3.AA.E5.95.8F">Win32 特有の質問</h3>
-
-<p> </p>
-
-<p> </p>
-
-<dl>
- <dt>Mozilla をビルドするための Microsoft Visual Studio プロジェクトファイルはありますか？</dt>
- <dd>いいえ。cygwin と GNU make を使わなければなりません。
- <p> </p>
- </dd>
- <dt>cmd.exe からビルドコマンドを実行しても良いでしょうか？</dt>
- <dd>はい。Make はコマンドを実行するために cygwin /bin/sh サブシェルを呼びます。なので何のシェルが make を呼ぶのに使われるかは重要ではありません。
- <p> </p>
- </dd>
- <dt>cygwin の autoconf パッケージのどのバージョンが使うのに必要でしょうか？</dt>
- <dd>autoconf 2.1x と 2.5x が相反するせいで、cygwin 維持管理者たちは autoconf 設定スクリプトが必要としているバージョンを決定しその autoconf のバージョンを呼ぶラッパースクリプトを書きました。autoconf(-wrapper) &amp; autoconf-stable パッケージが必要です。詳細については <a class="external" href="http://cygwin.com/ml/cygwin-announce/2001/msg00177.html" rel="freelink">http://cygwin.com/ml/cygwin-announce.../msg00177.html</a> を見てください。
- <p> </p>
- </dd>
- <dt>Microsoft ツール（CL, LINK, RC）が <em>file not found</em> エラーを示す</dt>
- <dd>INCLUDE と LIB 環境変数は Microsoft Visual C++ ツールによって使われます。それらは大抵 vcvars32.bat でセットアップされます。あなたのビルドしたモジュールに依存しているなら、MFC と ATL が必要かもしれませんし必要ないかもしれません。下のは Visual C++ が "C:\msvs": にインストールされている場合に動作するパスです。
- <pre class="eval">set INCLUDE=C:\msvs\VC\Include;C:\msvs\VC\ATLMFC\Include
-set LIB=C:\msvs\VC\Lib;C:\msvs\VC98\ATLMFC\Lib
-</pre>
-
- <p> </p>
- </dd>
- <dt>cvs update: authorization failed: server XXXX rejected access -- used empty password; try "cvs login" with a real password</dt>
- <dd>wincvs と cygwin cvs が混じっています。どちらか一方だけを使ってください。
- <p> </p>
- </dd>
- <dt>cvs {{ mediawiki.external('checkout aborted') }}: cannot rename file CVS/Entries.Backup to CVS/Entries: Permission denied</dt>
- <dd>cygwin 1.3.13 で、ntsec はデフォルトで有効です。ntsec はもっと Windows NT のセキュリティ機能をベースにしたパーミッションのような UNIX を得るための cygwin の試みです。そのエラーメッセージは cygwin の /etc/passwd ファイルにリストされた unix パーミッションと Windows NT によって使われるそれらとの間にマッピング不一致があることを指し示しています。回避方法として、あなたの CYGWIN 環境変数に "nontsec" を追加することができます。適切な修正はマッピング問題を修正することです。
- <p> </p>
- </dd>
- <dt>Make が a command not found error, or about not being able to find a .dtd file と吐く</dt>
- <dd>多分、ソースアーカイブを解凍するのに WinZIP を使っています。それを使わないでください。デフォルトで WinZIP は tar.gz アーカイブから 0 長のファイルを解凍しません。他のユーティリティを使うか、または WinZIP が展開しなかったファイルをチェックアウトするのに pull スクリプトを使ってください。
- <p> </p>
- </dd>
- <dt>nsinstall または他のネイティブ Win32 プログラムが a file not being found とエラーを出す</dt>
- <dd>Running the mount command should return something similar to: あなたの cygwin マウントテーブルをチェックしてください。マウントコマンドを実行することは以下によく似たことを返すはずです：
- <pre class="eval">c: on /cygdrive/c type user (binmode,noumount)
-e: on /cygdrive/e type user (binmode,noumount)
-c:\cygwin on / type system (binmode)
-c:\cygwin\bin on /usr/bin type system (binmode)
-c:\cygwin\lib on /usr/lib type system (binmode)
-</pre>
-
- <p>ビルドシステムは動かしているパーティションが prefix を動かすと /cygdrive を使ってマウントされることを期待しています。c: または e: が prefix を動かす時なければ、その後、これらのドライブを使って Mozilla を使うことはできません。コマンドを使うことによって期待されたスポットで手動でマウントする必要があります：</p>
-
- <pre class="eval">mount -s "e:\" /cygdrive/e
-</pre>
-
- <p>あなたのソースツリーが $HOME 以下ならば、マウントモードは binmode (UNIX スタイルラインエンジン）であるべきです。そうでなければビルドは多くのファイルを腐敗させるのに十分な失敗をするでしょう。ソースツリーが $HOME の外にあるなら、マウントモードはあなたのソースエディタが Unix スタイルラインエンジンを認める以上問題ではありません。</p>
-
- <p> </p>
- </dd>
- <dt>アクセス違反で xpidl.exe がクラッシュする</dt>
- <dd>これはコンパイラと glib と libIDL ライブラリまたは glib か libIDL ライブラリの間で食い違っているせいでいつも発生します。
- <p>あなたが Visual Studio .NET でビルドしているのであれば、その時に glib と libIDL DLL の VC7 ビルトバージョンに対してリンクを張らなければなりません。Visual Studio .NET 2003 のために VC 7.1 バージョンを使ってください。Visual Studio 2005 に対しては VC8 バージョンを使ってください。</p>
-
- <p>あなたのコンパイラのため特有のこれらのライブラリのバージョンを含んでいるディレクトリはどんなこれらのライブラリのバージョンの前に PATH になければなりません。.dll と .lib ファイルは実行できるようでなければ（chmod 755）cygwin はそれらをロードしないでしょう。</p>
-
- <p>VC7 とそれ以降のビルドについてのより多くの Tips については <a href="/ja/Windows_Build_Prerequisites/Free_Microsoft_Compilers" title="ja/Windows_Build_Prerequisites/Free_Microsoft_Compilers">Windows ビルド要件</a>を見てください。</p>
-
- <p>またたくさんの代わりの静的ライブラリが {{ Bug(242870) }} でコンパイラの特定のライブラリの代わりに使えるかもしれません。</p>
-
- <p>VC6 を使っているのであれば、その時に VC7 ライブラリをビルドタイムまたはランタイムで使って <em>いない</em> ことを確かめなければなりません。</p>
-
- <p> </p>
- </dd>
- <dt>configure: error: the midl major version, , does not match the compiler suite version, &lt;Visual C++ バージョン番号&gt; -- same for linker</dt>
- <dd>シンボリックリンクのための cygwin ツール "link.exe" がオブジェクトリンカーを Microsoft コンパイラスイーツと間違えているか、midl がそれぞれ見つけられていない。Microsoft ツールが PATH で cygwin よりも前にあるか確かめるか（<a href="/ja/Developer_Guide/Build_Instructions/Windows_Build_Prerequisites#Configure_the_Environment" title="ja/Developer_Guide/Build_Instructions/Windows_Build_Prerequisites#Configure_the_Environment">説明</a>を見てください）、/bin/link.exe をリネームするか削除してください。シェルが起動した時に cygwin が PATH を修正するかもしれないことに注意してください、そして cygwin シェルの<code>export</code> も見てください。
- <p> </p>
- </dd>
- <dt>configure: error: installation or configuration problem: C compiler cannot create executables.</dt>
- <dd>あなたの PATH 変数が全ての必要なディレクトリを含んでいるか確かめてみてください。MS Visual Studio を使っているならば、vcvar32.bat を実行してください（PATH, LIB, そして INCLUDE 変数を設定します）。ビルド環境が変化しているならば、config.cache ファイル（mozilla またはオブジェクトディレクトリで）を削除しビルドし直す必要があります。
- <p> </p>
- </dd>
- <dt>build error: ../coreconf/rules.mk:365: target `c' doesn't match the target pattern</dt>
- <dd>cygwin インストーラから make 3.81 が使用されています。make 3.80 を使わなければなりません。<a href="/ja/Developer_Guide/Build_Instructions/Windows_Build_Prerequisites#make" title="ja/Developer_Guide/Build_Instructions/Windows_Build_Prerequisites#make">説明</a>を読んでください。
- <p> </p>
- </dd>
- <dt>fatal error LNK1112: module machine type 'IA64' conflicts with target machine type 'X86'</dt>
- <dd>PATH, LIB, そして INCLUDE 変数でディレクトリ命令を変えてみてください。他の "win64" またはより終端に近い "IA64" （または "AMD64"）を含むディレクトリに移動してください。
- <p> </p>
- </dd>
- <dt>LINK : fatal error LNK1104: cannot open file 'atlthunk.lib'</dt>
- <dd><a class="external" href="http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=64509">この Microsoft フォーラムスレッド</a>によると、フリープラットフォームソフトウェア開発キット (PSDK) 内の Active Template Library (ATL) は Visual Studio 内のと異なるバージョンです。Visual Studio ATL は 32 ビットも 64 ビットも両方サポートして atlthunk.lib を要求しないのに PSDK 内の ATL は 32 ビットコードをサポートしておらず 64 ビットのみをサポートしています。見たところ、Visual C++ ツールキットと Visual Studio Express に含まれている atlthunk.lib ファイルは利用できず <a href="/ja/Windows_Build_Prerequisites/Free_Microsoft_Compilers" title="ja/Windows_Build_Prerequisites/Free_Microsoft_Compilers">自由に利用できるツール</a> からビルドできません。ATL のそれらのバージョンを使うには Visual Studio を完全なバージョンにアップグレードするか、次の方法で atlbase.h （PSDK ディレクトリ下の \include\atl）のいくつかのコードを変更することによってこの問題を回避するかどちらか一方をすることが出来ます。
- <pre class="eval">--- atlbase.h.old       2006-06-08 08:20:26.671875000 -0400
-+++ atlbase.h   2006-06-08 08:13:26.578125000 -0400
-@@ -283,7 +283,7 @@
-         }
- };
- #pragma pack(pop)
--
-+/*
- PVOID __stdcall __AllocStdCallThunk(VOID);
- VOID  __stdcall __FreeStdCallThunk(PVOID);
-
-@@ -291,6 +291,11 @@
- #define FreeStdCallThunk(p) __FreeStdCallThunk(p)
-
- #pragma comment(lib, "atlthunk.lib")
-+*/
-+
-+// workaround for not having atlthunk.lib in PSDK or VC++ 2005 Express Edition
-+#define AllocStdCallThunk() HeapAlloc(GetProcessHeap(),0,sizeof(_stdcallthunk))
-+#define FreeStdCallThunk(p) HeapFree(GetProcessHeap(), 0, p)
-
- #elif defined (_M_AMD64)
- #pragma pack(push,2)
-</pre>
-
- <p>私はまたコンパイラにこの変更を反映するためにオブジェクトディレクトリを削除して一からコンパイルする必要がありました。</p>
-
- <p> </p>
- </dd>
- <dt>cygwin と VS 6.0 で実行ファイルをコンパイルまたはビルドするときの結果 FIND: Parameter format not correct と出る</dt>
- <dd>System32 "find" と cygwin の /usr/bin/find との間で混乱が生じています。望ましい find は cygwin の方のです。これは Path の整理によって生じます。2,3 の解決法が利用できます：
- <ul>
-  <li>一時的に system32/find.exe をリネームする。</li>
-  <li>system32 path が記入される前に cygwin が記入されていることを確認してください。</li>
- </ul>
-
- <p> </p>
- </dd>
- <dt>私はインストーラによって問題なく Firefox をパッケージ化した： <code>make -C ${OBJ_DIR}/browser/installer installer</code> インストーラは欠けている mozz.dll を要求してインストールが失敗する。</dt>
- <dd>Thunderbird と Firefox は両方とも --enable-static--disable-shared 設定フラグでコンパイルされるべきです。
- <p> </p>
- </dd>
- <dt>shlibsign.exe - Entry Point Not Found; The procedure entry point CERT_GetFirstEmailAddress could not be located in the dynamic link library nss3.dll.</dt>
- <dd>あなたの Path でマシン上の nss3.dll の複数からなるインスタンスをしているのかもしれません。このファイルの全てのインスタンスのためにマシン上で検索を実行してください。 ビルド中は別にしてどんなインスタンスも Firefox ビルドツリーの外に移動してください。そしてビルドされる時にそれらを元の名前にリネームしてください。 &lt;/dd&gt;</dd>
-</dl>
-
-<h3 id="Mingw32_.E7.89.B9.E6.9C.89.E3.81.AE.E8.B3.AA.E5.95.8F" name="Mingw32_.E7.89.B9.E6.9C.89.E3.81.AE.E8.B3.AA.E5.95.8F">Mingw32 特有の質問</h3>
-
-<ul>
- <li>w32api のために設定またはビルドが失敗するなら、あなたの INCLUDE 環境変数の終わりに mingw32 の /include ディレクトリを追加してください。Mingw32 ライブリーまたはバイナリは必要でなくヘッダーのみが必要です。</li>
-</ul>
-
-<h3 id="Unix_.E7.89.B9.E6.9C.89.E3.81.AE.E8.B3.AA.E5.95.8F" name="Unix_.E7.89.B9.E6.9C.89.E3.81.AE.E8.B3.AA.E5.95.8F">Unix 特有の質問</h3>
-
-<p> </p>
-
-<dl>
- <dt>Galeon は libgtksuperwin.so が必要としますが私の Mozilla gtk2 ビルドにそのファイルはありません。それはどこにありますか？</dt>
- <dd>Mozilla gtk1 ビルドのみが libgtksuperwin.so をビルドします。あなたが gtk2 ビルドで galeon を使いたいなら、galeon2 を使う必要があるでしょう。
- <p> </p>
- </dd>
- <dt>なぜ私が libIDL 0.8.x をインストールした時に configure は libIDL &gt;= 0.6.3 が必要だと言うのでしょうか？</dt>
- <dd>libIDL 0.8.x は gtk2 に対してコンパイルしたときのみに使うことが出来ます。 Mozilla はデフォルトで gtk1 に対してコンパイルします。libIDL 0.8.x と gtk2 を使うには、configure コマンドラインまたは mozconfig ファイル中に --enable-default-toolkit=gtk2 を指定しなければなりません。 注意：これは mozilla 1.8 で修正されている古い問題です。</dd>
- <dt>Solaris 10 x86 (SeaMonkey) でどのようにビルドすれば良いでしょうか？</dt>
- <dd>私は動作環境を得るために以下のことをしなければなりませんでした。</dd>
- <dd>1. forte をインストールしてください（Sun からのフリー）</dd>
- <dd>2. gmake をインストールしてください (blastwave から）</dd>
- <dd>3. mv /usr/ucb/cc /usr/ucb/cc.hold</dd>
- <dd>4. CFLAGS="-xlibmil"; export CFLAGS</dd>
- <dd>5. CXXFLAGS="-xlibmil -xlibmopt -features=tmplife -norunpath"; export CXXFLAGS</dd>
- <dd>6. LDFLAGS='-R$ORIGIN -R/usr/sfw/lib -R/opt/sfw/lib -R/usr/local/lib -R/opt/csw/lib'; export LDFLAGS</dd>
- <dd>7. PATH=$PATH:/opt/SUNWspro/bin:/opt/csw/bin:/opt/csw/sbin:/usr/ucb/bin:/usr/ccs/bin; export PATH</dd>
- <dd>8. LD_LIBRARY_PATH=/opt/SUNWspro/lib:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH</dd>
- <dd>9. mozconfig ファイルを創って通常のようにビルドしてください</dd>
- <dd>10. パッケージ（tar と gzip）のビルドが失敗したので、手動で{{ 原語併記("ディスト", "dist") }}ディレクトリにある結果ファイルを tar しました。
- <p> </p>
- </dd>
- <dt>libxpcom_core.so: cannot restore segment prot after reloc: Permission denied&lt;/dt&gt;</dt>
- <dd>あなたは多分、FedoraCore 5 を使っているか、または SELinux が作動している他の Linux ディストリビューションを使っているでしょう。それを直すには dist/bin ディレクトリで 'chcon -t chcon -t texrel_shlib_t lib*' コマンドを使ってください。 &lt;/dd&gt;</dd>
-</dl>
-
-<p>{{ languages( { "en": "en/Mozilla_Build_FAQ", "es": "es/Preguntas_frecuentes_sobre_la_compilaci\u00f3n_de_Mozilla", "fr": "fr/FAQ_sur_la_compilation_de_Mozilla" } ) }}</p>
diff --git a/files/ja/mozilla/developer_guide/source_code/cvs/index.html b/files/ja/mozilla/developer_guide/source_code/cvs/index.html
deleted file mode 100644
index 8ab1fdc8af..0000000000
--- a/files/ja/mozilla/developer_guide/source_code/cvs/index.html
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: Getting Mozilla Source Code Using CVS
-slug: Mozilla/Developer_Guide/Source_Code/CVS
-tags:
-  - Build documentation
-  - Developing Mozilla
----
-<div class="note">注記: このドキュメントは Gecko 1.9.0 や Firefox 3 より古いバージョンと、NSS および NSPR のすべてのバージョンのソースコードを取得する方法について書かれています。Gecko 1.9.1/Firefox 3.5 以降の開発は <a class="internal" href="/ja/Developer_Guide/Source_Code/Mercurial" title="ja/Developer Guide/Source Code/Mercurial">Mercurial</a> ソースコードコントロールシステムを使用します。</div>
-<p>精力的に開発に関わっている人は、CVS を使って最新のソースをチェックアウトできます。この方法は、パッチやバグ修正を提供したい場合におすすめの方法です。というのも、文字通り最新の変更を入手でき、それらとあなた独自の変更をマージできるからです。</p>
-<p>リリースのために製品をコンパイルしたい場合は、tarball で <a href="/ja/Developer_Guide/Source_Code/Downloading_Source_Archives" title="ja/Developer_Guide/Source_Code/Downloading_Source_Archives">Mozilla ソースコードをダウンロードする</a> 方が良いでしょう。</p>
-<h3 id="Getting Started" name="Getting Started">はじめに</h3>
-<p>CVS とは「Concurrent Versioning System」を意味します。CVS 全般について知りたい場合は、 <a class="external" href="http://ximbiot.com/cvs/manual/">ximbiot.com</a> あるいは <a class="external" href="http://ximbiot.com/cvs/cvshome/docs/blandy.html">チュートリアル</a> を参照してください。</p>
-<p>誰でも CVS を経由してソースをチェックアウト （「pull （引っ張る）」 とか 「download （ダウンロードする）」 とも言われます） できますが、チェックイン （変更すること、「commit （コミット）」 とも言われます） は許可のある人しかできません。チェックインができる人は、<a class="external" href="http://www.mozilla.org/owners.html">モジュールオーナー</a> やその代理人に限られます。「<a class="external" href="http://www.mozilla.org/hacking/">Mozilla をハックする<span class="comment">hacking mozilla</span></a>」 を読んで、チェックインの権限を得るにはどうしたらよいのか学んでください。<a href="/ja/Using_SSH_to_connect_to_CVS" title="ja/Using_SSH_to_connect_to_CVS">SSH をつかって CVS に接続する</a>も参考になるかもしれません。</p>
-<h4 id="Requirements" name="Requirements">必要条件</h4>
-<p>ソースをチェックアウトするには、<a class="external" href="http://www.nongnu.org/cvs/">CVS</a> 1.11 以降を実行していなければなりません。1.12.13 は CVS サーバと相性が悪く、ハングアップします。1.12.9 は動作することがわかっています。さらに、Mozilla をチェックアウトしてビルドするには <a class="external" href="http://www.gnu.org/software/make/">GNU make</a> を使用しなければなりません。それ以外の「make」プログラムでは動きません。Windows、Mac および通常の GNU システム（GNU/Linux など）では、「make」と入力して GNU make を実行してください。非 GNU UNIX の多く（例えば Solaris など）では「gmake」を使用してください。</p>
-<h3 id="CVS Client Settings" name="CVS Client Settings">CVS クライアントの設定</h3>
-<p>Mozilla の CVS に匿名でアクセスするための 「cvsroot」（リポジトリを識別する文字列）は次のとおりです：</p>
-<pre class="eval">:pserver:<a class=" link-mailto" href="mailto:anonymous@cvs-mirror.mozilla.org" rel="freelink">anonymous@cvs-mirror.mozilla.org</a>:/cvsroot
-</pre>
-<p>グラフィカル CVS インタフェースを使用する場合は次のサーバデータを使用してください：</p>
-<ul> <li><strong>ホスト</strong>: "cvs-mirror.mozilla.org"</li> <li><strong>リポジトリパス</strong>: "/cvsroot"</li> <li><strong>ユーザ</strong>: "anonymous"</li> <li><strong>パスワード</strong>: "anonymous"</li> <li><strong>接続方法</strong>: pserver</li> <li><strong>ポート</strong>: デフォルト (2401)</li>
-</ul>
-<h3 id="Selecting_a_Project_to_Pull" name="Selecting_a_Project_to_Pull">引っ張ってくるプロジェクトを選択する</h3>
-<p>同じ基礎のソースコードから複数の異なるアプリケーションがビルドされているため、<code>MOZ_CO_PROJECT</code> 変数を使ったコマンドライン上で、どのアプリケーションをチェックアウトするかを選択しなければなりません。この情報は実際のソースコードがチェックアウトされる際に使用されます（チェックアウトしたいブランチに従って、下にある適当な <a href="#.E3.83.81.E3.82.A7.E3.83.83.E3.82.AF.E3.82.A2.E3.82.A6.E3.83.88">チェックアウト</a> <a href="#.E3.83.81.E3.82.A7.E3.83.83.E3.82.AF.E3.82.A2.E3.82.A6.E3.83.88_2">セクション</a> をご覧ください）。利用可能なオプションには次のようなものがあります：</p>
-<dl> <dt> browser </dt> <dd> スタンドアローンな「Firefox」ブラウザです。</dd> <dt> mail </dt> <dd> スタンドアローンな「Thunderbird」メール・ニュースクライアントです。</dd> <dt> suite </dt> <dd> 古くからある、ブラウザ、メール・ニュース、コンポーザ、その他のアプリケーションからなる「Mozilla」 SeaMonkey スイートです。</dd> <dt> minimo </dt> <dd> 小型デバイス向けのスタンドアローンなブラウザです。</dd> <dt> composer </dt> <dd> スタンドアローンな HTML コンポーザです。</dd> <dt> calendar </dt> <dd> スタンドアローンな「Sunbird」カレンダーアプリケーションです。</dd> <dt> xulrunner </dt> <dd> 次世代の XUL アプリケーションランチャーです。</dd> <dt> camino </dt> <dd> Macintosh 用の「Camino」ネイティブブラウザです。</dd> <dt> all </dt> <dd> 上記のプロジェクトすべてに対応したソースに加えてユーティリティコードをチェックアウトします。</dd>
-</dl>
-<p>カンマで繋ぐことで複数のプロジェクトを指定できます：<code>MOZ_CO_PROJECT=suite,browser,xulrunner</code></p>
-<p><strong>注意</strong>：独自の <code><a href="/ja/Configuring_Build_Options#.mozconfig_.E8.A8.AD.E5.AE.9A.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E4.BD.BF.E3.81.86" title="ja/Configuring_Build_Options#.mozconfig_.E8.A8.AD.E5.AE.9A.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E4.BD.BF.E3.81.86">.mozconfig</a></code> ファイルを使用する場合は <code>MOZ_CO_PROJECT</code> をコマンドラインではなくそのファイルで指定することもできます。</p>
-<p>{{ 英語版章題("Checking Out a New Source Tree") }}</p>
-<h3 id=".E6.96.B0.E3.81.97.E3.81.84.E3.82.BD.E3.83.BC.E3.82.B9.E3.83.84.E3.83.AA.E3.83.BC.E3.82.92.E3.83.81.E3.82.A7.E3.83.83.E3.82.AF.E3.82.A2.E3.82.A6.E3.83.88.E3.81.99.E3.82.8B" name=".E6.96.B0.E3.81.97.E3.81.84.E3.82.BD.E3.83.BC.E3.82.B9.E3.83.84.E3.83.AA.E3.83.BC.E3.82.92.E3.83.81.E3.82.A7.E3.83.83.E3.82.AF.E3.82.A2.E3.82.A6.E3.83.88.E3.81.99.E3.82.8B">新しいソースツリーをチェックアウトする</h3>
-<p>{{ 英語版章題("Check Tinderbox") }}</p>
-<h4 id="Tinderbox_.E3.82.92.E7.A2.BA.E8.AA.8D.E3.81.99.E3.82.8B" name="Tinderbox_.E3.82.92.E7.A2.BA.E8.AA.8D.E3.81.99.E3.82.8B">Tinderbox を確認する</h4>
-<p>ツリーを引っ張ってくる前には適当な <a href="/ja/Tinderbox" title="ja/Tinderbox">Tinderbox</a> を毎回確認してコードベースが壊れていないかどうかを確かめるようにします。赤くなっている Tinderbox があれば、それが緑になるまでツリーを引っ張るのを待つことをお勧めします。</p>
-<p>{{ 英語版章題("Branch HEAD") }}</p>
-<h4 id=".E3.83.96.E3.83.A9.E3.83.B3.E3.83.81_HEAD" name=".E3.83.96.E3.83.A9.E3.83.B3.E3.83.81_HEAD">ブランチ HEAD</h4>
-<p>一から新しいソースツリーをチェックアウトするには、まず <code>client.mk</code> ファイルを取得してください。このファイルには残りのツリーを引っ張ってくるのに使用するメイクファイルの命令が含まれています。</p>
-<pre class="eval">$ cvs -d :pserver:<a class=" link-mailto" href="mailto:anonymous@cvs-mirror.mozilla.org" rel="freelink">anonymous@cvs-mirror.mozilla.org</a>:/cvsroot co mozilla/client.mk
-</pre>
-<p>注意：<code><a href="/ja/Configuring_Build_Options#.mozconfig_.E8.A8.AD.E5.AE.9A.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E4.BD.BF.E3.81.86" title="ja/Configuring_Build_Options#.mozconfig_.E8.A8.AD.E5.AE.9A.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E4.BD.BF.E3.81.86">.mozconfig</a></code> ファイルをすでに用意してある場合は次のファイルもチェックアウトしなければなりません。</p>
-<dl> <dt> Firefox </dt> <dd> <pre>cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/browser/config/mozconfig</pre> </dd> <dt> Thunderbird </dt> <dd> <pre>cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/mail/config/mozconfig</pre> </dd>
-</dl>
-<p>{{ Note("HEAD 上の Thunderbird の最新版は 3.0a2 後のナイトリービルドでした。HEAD 上の SeaMonkey の最新版は 2.0a1pre ナイトリービルドでした。Thunderbird や SeaMonkey の開発はこれ以上 CVS の HEAD 上では行われません。") }}</p>
-<p>{{ 英語版章題("Specific Branch") }}</p>
-<h4 id=".E7.89.B9.E5.AE.9A.E3.81.AE.E3.83.96.E3.83.A9.E3.83.B3.E3.83.81" name=".E7.89.B9.E5.AE.9A.E3.81.AE.E3.83.96.E3.83.A9.E3.83.B3.E3.83.81">特定のブランチ</h4>
-<p>特定の <a class="external" href="http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Branching_and_merging">CVS ブランチ</a> のソースコードをチェックアウトしたい場合は代わりに次のようにしてください：</p>
-<pre class="eval">$ cvs -d :pserver:<a class=" link-mailto" href="mailto:anonymous@cvs-mirror.mozilla.org" rel="freelink">anonymous@cvs-mirror.mozilla.org</a>:/cvsroot co -r BRANCH mozilla/client.mk
-</pre>
-<p>例えば、Firefox 2.0/Thunderbird 2.0/SeaMonkey 1.1 開発ブランチを引っ張ってくるには、上記の BRANCH を MOZILLA_1_8_BRANCH に置き換えてください。利用可能な Mozilla のブランチタグについては <a href="/ja/CVS_Tags" title="ja/CVS_Tags">CVS タグ</a> を参照してください。</p>
-<p><a href="#.E3.83.96.E3.83.A9.E3.83.B3.E3.83.81_HEAD">前のセクション</a> で示したプロジェクト固有の <code>.mozconfig</code> ファイルを引っ張ってくる方法はもちろん HEAD 以外のブランチでも使用できます。</p>
-<p>{{ 英語版章題("Checkout") }}</p>
-<h4 id=".E3.83.81.E3.82.A7.E3.83.83.E3.82.AF.E3.82.A2.E3.82.A6.E3.83.88" name=".E3.83.81.E3.82.A7.E3.83.83.E3.82.AF.E3.82.A2.E3.82.A6.E3.83.88">チェックアウト</h4>
-<p>正しいブランチを選んだら、次を実行してください：</p>
-<pre class="eval">$ cd mozilla
-$ make -f client.mk checkout MOZ_CO_PROJECT=<em>option,option</em>
-</pre>
-<p>上で触れたように、<code>MOZ_CO_PROJECT</code> 変数を指定済みの独自の <code>.mozconfig</code> ファイルを使用する場合は、コマンドラインでこの作業を繰り返す必要はありません。</p>
-<div class="note">Mozilla のソースをチェックアウトするときには常に <code>client.mk</code> を使用してください。直接 <code>mozilla/</code> モジュールをチェックアウトしてはいけません。通常の Mozilla の開発がトランク上で行われているときでさえ、NSS、NSPR、LDAP C SDK といったさまざまなサブプロジェクトは安定版リリースタグから引っ張り出されます。</div>
-<p>{{ 英語版章題("Specific Time") }}</p>
-<h4 id=".E7.89.B9.E5.AE.9A.E3.81.AE.E6.99.82.E5.88.BB" name=".E7.89.B9.E5.AE.9A.E3.81.AE.E6.99.82.E5.88.BB">特定の時刻</h4>
-<p>ある特定の時刻においてのソースコードをチェックアウトしたい場合は MOZ_CO_DATE 変数を使用できます。例：<code>MOZ_CO_DATE="20 Oct 2006 17:00 PDT"</code></p>
-<p>これは <code><a href="/ja/Configuring_Build_Options#.mozconfig_.E8.A8.AD.E5.AE.9A.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E4.BD.BF.E3.81.86" title="ja/Configuring_Build_Options#.mozconfig_.E8.A8.AD.E5.AE.9A.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E4.BD.BF.E3.81.86">.mozconfig</a></code> に加えることも、次のようにしてコマンドラインで指定することもできます。</p>
-<pre class="eval">$ cd mozilla
-$ make -f client.mk checkout MOZ_CO_DATE="20 Oct 2006 17:00 PDT" MOZ_CO_PROJECT=<em>option,option</em>
-</pre>
-<p>{{ 英語版章題("Changing the Source Tree to a Different Branch") }}</p>
-<h3 id=".E3.82.BD.E3.83.BC.E3.82.B9.E3.83.84.E3.83.AA.E3.83.BC.E3.82.92.E7.95.B0.E3.81.AA.E3.82.8B.E3.83.96.E3.83.A9.E3.83.B3.E3.83.81.E3.81.AB.E5.A4.89.E6.9B.B4.E3.81.99.E3.82.8B" name=".E3.82.BD.E3.83.BC.E3.82.B9.E3.83.84.E3.83.AA.E3.83.BC.E3.82.92.E7.95.B0.E3.81.AA.E3.82.8B.E3.83.96.E3.83.A9.E3.83.B3.E3.83.81.E3.81.AB.E5.A4.89.E6.9B.B4.E3.81.99.E3.82.8B">ソースツリーを異なるブランチに変更する</h3>
-<p>{{ 英語版章題("Branch HEAD") }}</p>
-<h4 id=".E3.83.96.E3.83.A9.E3.83.B3.E3.83.81_HEAD_2" name=".E3.83.96.E3.83.A9.E3.83.B3.E3.83.81_HEAD_2">ブランチ HEAD</h4>
-<p>ソースツリー（ブランチ HEAD あるいは特定のブランチ）を最新のブランチ HEAD に更新するには、まずこれを実行してください：</p>
-<pre class="eval">$ cd mozilla
-$ cvs up -A client.mk
-</pre>
-<p>-A オプションは「貼り付いたブランチ」の情報を取り払い、ツリーを HEAD に更新できるようになります。</p>
-<p>{{ 英語版章題("Specific Branch") }}</p>
-<h4 id=".E7.89.B9.E5.AE.9A.E3.81.AE.E3.83.96.E3.83.A9.E3.83.B3.E3.83.81_2" name=".E7.89.B9.E5.AE.9A.E3.81.AE.E3.83.96.E3.83.A9.E3.83.B3.E3.83.81_2">特定のブランチ</h4>
-<p>特定のブランチから引っ張ってきたソースツリーを更新するには代わりにこうしてください：</p>
-<pre class="eval">$ cd mozilla
-$ cvs up -r BRANCH client.mk
-</pre>
-<p>BRANCH は更新したいブランチのタグで置き換えてください。</p>
-<p>{{ 英語版章題("Updating a Source Tree") }}</p>
-<h3 id=".E3.82.BD.E3.83.BC.E3.82.B9.E3.83.84.E3.83.AA.E3.83.BC.E3.82.92.E6.9B.B4.E6.96.B0.E3.81.99.E3.82.8B" name=".E3.82.BD.E3.83.BC.E3.82.B9.E3.83.84.E3.83.AA.E3.83.BC.E3.82.92.E6.9B.B4.E6.96.B0.E3.81.99.E3.82.8B">ソースツリーを更新する</h3>
-<p>ソースツリーを更新するには、単に次のようにします:</p>
-<pre class="eval">$ make -f client.mk checkout MOZ_CO_PROJECT=<em>option,option</em>
-</pre>
-<p>やはり <code>MOZ_CO_PROJECT</code> を定義してある独自の <code>.mozconfig</code> ファイルを使用するのであれば、コマンドラインで作業を繰り返す必要はありません。</p>
-<p>{{ 英語版章題("Creating a Diff File") }}</p>
-<h3 id=".E5.B7.AE.E5.88.86.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E4.BD.9C.E6.88.90.E3.81.99.E3.82.8B" name=".E5.B7.AE.E5.88.86.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E4.BD.9C.E6.88.90.E3.81.99.E3.82.8B">差分ファイルを作成する</h3>
-<p>リポジトリ内の現時点でのファイルと単一のローカルファイルとの差分を作成するには次のようにしてください：</p>
-<pre class="eval">$ cvs diff -u8p FILENAME
-</pre>
-<p>詳しくは <a href="/ja/Creating_a_patch" title="ja/Creating_a_patch">パッチの作成</a> を参照してください。</p>
-<p>{{ 英語版章題("Converting a Downloaded Source Tree") }}</p>
-<h3 id=".E3.83.80.E3.82.A6.E3.83.B3.E3.83.AD.E3.83.BC.E3.83.89.E3.81.97.E3.81.9F.E3.82.BD.E3.83.BC.E3.82.B9.E3.83.84.E3.83.AA.E3.83.BC.E3.82.92.E5.A4.89.E6.8F.9B.E3.81.99.E3.82.8B" name=".E3.83.80.E3.82.A6.E3.83.B3.E3.83.AD.E3.83.BC.E3.83.89.E3.81.97.E3.81.9F.E3.82.BD.E3.83.BC.E3.82.B9.E3.83.84.E3.83.AA.E3.83.BC.E3.82.92.E5.A4.89.E6.8F.9B.E3.81.99.E3.82.8B">ダウンロードしたソースツリーを変換する</h3>
-<p>mozilla.org からダウンロードしたソースツリー（<a href="/ja/Developer_Guide/Source_Code/Downloading_Source_Archives" title="ja/Developer_Guide/Source_Code/Downloading_Source_Archives">ソースの tarball</a>）は、通常のチェックアウト時のようにすでに CVS の情報が付け加えられた状態になっています。通常のツリーと同様、このツリーは特別なことをしなくても最新のコードに更新することができます。ソースツリーの更新方法は前のセクションをご覧ください。</p>
-
-<div class="noinclude">
-<p>{{ languages( { "en": "en/Mozilla_Source_Code_(CVS)", "es": "es/C\u00f3digo_fuente_de_Mozilla_(CVS)", "fr": "fr/Obtenir_le_code_source_de_Mozilla_via_CVS", "zh-cn": "cn/\u901a\u8fc7CVS\u83b7\u53d6\u6e90\u7801" } ) }}</p>
-</div>
diff --git a/files/ja/mozilla/developer_guide/source_code/getting_comm-central/index.html b/files/ja/mozilla/developer_guide/source_code/getting_comm-central/index.html
deleted file mode 100644
index 11875d9e3c..0000000000
--- a/files/ja/mozilla/developer_guide/source_code/getting_comm-central/index.html
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Getting comm-central Source Code Using Mercurial
-slug: Mozilla/Developer_guide/Source_Code/Getting_comm-central
-translation_of: Mozilla/Developer_guide/Source_Code/Getting_comm-central
-original_slug: >-
-  Mozilla/Developer_Guide/Source_Code/Getting_comm-central_Source_Code_Using_Mercurial
----
-<p><a href="/ja/Mercurial" title="ja/Mercurial">Mercurial</a> は、ソースコードの変更をローカルで追跡し、それらの変更を他のユーザと共有するためのソースコード管理ツールです。Mozilla プロジェクトはソースコードの管理を、Mozilla 1.9 開発用の <a href="/ja/Developer_Guide/Source_Code/CVS" title="Getting Older Mozilla Source Code Using CVS">CVS</a> から Mozilla 1.9.1 とその先の製品開発用の Mercurial へ移行しています。</p>
-<div class="note">Thunderbird 2.0 や SeaMonkey 1.1, Firefox 3.0 の開発のためのパッチを提出したいときは、<a href="/ja/Developer_Guide/Source_Code/CVS" title="Getting Older Mozilla Source Code Using CVS">CVS</a> を使用してください。</div>
-<h3 id="Client_Settings" name="Client_Settings">クライアントの設定</h3>
-<p>設定は Firefox 3.5/xulrunner 1.9.1 の開発と同じです。次の記事を参照してください。</p>
-<p><a href="/ja/Developer_Guide/Source_Code/Mercurial#Client_settings" title="ja/Mozilla_Source_Code_(Mercurial)#Client_settings">Mozilla_Source_Code_(Mercurial)#Client_settings</a>.</p>
-<h3 id="Checking_out_a_source_tree" name="Checking_out_a_source_tree">ソースツリーのチェックアウト</h3>
-<p>Thunderbird と Seamonkey のソースコードはそれぞれ異なるリポジトリに含まれています。<a class="internal" href="/ja/comm-central" title="ja/comm-central">comm-central</a> は、それらのアプリケーション開発用のメインの統合リポジトリです。Thunderbird および Sunbird, SeaMonkey に必要とされるソースコードが含まれています。また、他のソースコードを入手するための <code>client.py</code> スクリプトも含まれています。</p>
-<p>comm-central のソースコードを入手するには (Mercurial の用語で、リポジトリを "clone" します):</p>
-<pre class="eval"># Mozilla ソースコードを src/ フォルダに pull します。
-# 数百メガバイトの履歴が .hg フォルダにダウンロードされるため、しばらく時間がかかります。
-hg clone <span class="nowiki">http://hg.mozilla.org/comm-central/</span> src
-
-cd src
-</pre>
-<div class="note">すでに mozilla-central ツリーを clone している場合は、mozilla-central 全体を再び pull してしまうことを避けるため、ここでは src/mozilla に clone してください。</div>
-<p>client.py を使用して、必要な他のすべてのソースコードを更新または pull してください:</p>
-<pre class="eval">python client.py checkout
-</pre>
-<div class="note">
-<ul> <li>"No module named subprocess" というエラーメッセージが表示された場合は、Python 2.4 以降をインストールする必要があります。</li> <li>このステップでは数百メガバイトのデータがダウンロードされます。ネットワークの接続速度によっては、しばらく時間がかかります。</li>
-</ul>
-</div>
-<p>client.py は以下のタスクを行います:</p>
-<ul> <li><a href="/ja/mozilla-central" title="ja/mozilla-central">mozilla-central</a> コードベースを mozilla/ ディレクトリに pull する</li> <li>次のリポジトリを mozilla/extensions ディレクトリに pull する: <ul> <li>inspector (DOM Inspector)</li> <li>venkman (JavaScript Debugger)</li> </ul> </li> <li>次のディレクトリを CVS リポジトリから pull する:<br> <ul> <li>extensions/irc (Chatzilla) (mozilla/extensions/irc ディレクトリへ)</li> <li>directory/c-sdk</li> </ul> </li> <li>'hg pull' を実行して変更を pull する。これは必須ではありません (あなた自身が pull することになるでしょう)。--skip-comm オプションを client.py に渡し、このタスクをスキップします。</li>
-</ul>
-<h4 id="Updating_the_Repository" name="Updating_the_Repository">リポジトリの更新</h4>
-<p>リポジトリを更新するには、client.py を再び実行します:</p>
-<pre>python client.py checkout
-</pre>
-<p><a href="/ja/comm-central#Branches" title="ja/comm-central#Branches">comm-central の異なるブランチ</a> を pull するには、 <code><a class=" external" href="http://hg.mozilla.org/comm-central" rel="freelink">http://hg.mozilla.org/comm-central</a></code> をブランチの場所に置きかえて、上に書かれた最初のステップを行ってください。ブランチの場所は <a href="/ja/comm-central#Branches" title="ja/comm-central#Branches">comm-central ページのブランチ章</a>で指定されています。</p>
-<div class="note">関連するリポジトリを pull すると、同じソースディレクトリを使用して上述のソフトウェアを開発してビルドすることができますが、リポジトリをまたがる変更 (chengeset) を作成できるわけではありません。リポジトリをまたがるパッチを作成するときは、各リポジトリごとの変更 (chengeset) が必要です。</div>
-<h3 id="Building" name="Building">ビルド</h3>
-<p>comm-central のアプリケーションについては、次のリンク先をご覧ください:</p>
-<ul> <li><a class="internal" href="/ja/Simple_Thunderbird_build" title="ja/Simple Thunderbird build">Simple Thunderbird Build</a></li> <li><a class="internal" href="/ja/Simple_SeaMonkey_build" title="ja/Simple SeaMonkey build">Simple SeaMonkey Build</a></li> <li><a class="internal" href="/ja/Simple_Sunbird_build" title="ja/Simple Sunbird build">Simple Sunbird Build</a></li>
-</ul>
-<h4 id="Firefox_and_xulrunner" name="Firefox_and_xulrunner">Firefox と xulrunner</h4>
-<p>必要であれば、このツリーから Firefox や xulrunner をビルドすることができます。client.py によって mozilla-central リポジトリが pull されるため、Firefox や xulrunner のビルドと開発は comm-central からのリポジトリ内で行うことができます。ただ一つの違いは、ビルドコマンドを実行する前に mozilla/ ディレクトリに移動する必要があることです:</p>
-<pre class="eval">cd src/mozilla
-make -f client.mk build
-</pre>
-<h3 id="See_Also" name="See_Also">参照</h3>
-<ul> <li><a href="/ja/comm-central" title="ja/comm-central">comm-central</a></li> <li><a href="/ja/Mercurial" title="ja/Mercurial">Mercurial</a></li> <li><a href="/ja/Mercurial_FAQ" title="ja/Mercurial_FAQ">Mercurial FAQ</a></li> <li><a href="/ja/Developer_Guide/Source_Code/Mercurial" title="ja/Mozilla_Source_Code_(Mercurial)">Mozilla_Source_Code_(Mercurial)</a></li>
-</ul>
-<p>{{ languages( { "en": "En/Developer_Guide/Source_Code/Getting_comm-central", "fr": "fr/Code_source_de_comm-central_(Mercurial)" } ) }}</p>
diff --git a/files/ja/mozilla/developer_guide/source_code/index.html b/files/ja/mozilla/developer_guide/source_code/index.html
deleted file mode 100644
index 66a5520a66..0000000000
--- a/files/ja/mozilla/developer_guide/source_code/index.html
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Mozilla のソースコードに貢献する
-slug: Mozilla/Developer_Guide/Source_Code
-tags:
-  - Developing Mozilla
-  - Firefox
-  - Intermediate
-  - Mozilla
-  - thunderbird
-translation_of: Mozilla/Developer_guide/Source_Code
----
-<p>The articles below will help you get your hands on the Mozilla source code, learn to navigate the code, and how to get the changes you propose checked into the tree.</p>
-
-<div class="row topicpage-table">
-<div class="section">
-<dl>
- <dt><a class="internal" href="/En/Developer_Guide/Source_Code/Mercurial" title="En/Mozilla Source Code (Mercurial)">Mercurial のリポジトリからソースコードをダウンロードする</a></dt>
- <dd>Mozilla プロジェクトへ貢献するためソースコードを手元に持ってきたい場合、バージョン管理がされているリポジトリをチェックアウトすると最も良いでしょう。この記事ではダウンロードの方法を紹介します。</dd>
- <dt><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Using_the_VM">仮想マシンとして構築済みの Mozilla ビルドシステムを使う</a></dt>
- <dd>ここでは VirtualBox の仮想マシンを用いますが、すでにビルド環境は構築されているため、仮想マシンを起動するだけでビルドを実行できます。Mozilla のソースコードを初めてビルドするには最も簡単な方法です。</dd>
- <dt><a class="internal" href="/En/Developer_Guide/Source_Code/Downloading_Source_Archives" title="En/Mozilla Source Code (HTTP//FTP)">HTTP や FTP でソースコードをダウンロードする</a></dt>
- <dd>ある Mozilla プロジェクトのソースコードをダウンロードする際にリリースバージョンを指定したい場合、ソースコードのアーカイブを利用したほうが便利です。</dd>
- <dt><a class="internal" href="/en/Viewing_and_searching_Mozilla_source_code_online" title="En/Viewing and searching Mozilla source code online">Mozilla のソースコードをオンラインで閲覧・検索する</a></dt>
- <dd>Mozilla のソースコードをオンラインで閲覧・検索できる MXR の利用方法について解説します。ダウンロードには不向きですが、ソースコードの検索にはとても便利です。</dd>
- <dt><a class="internal" href="/en/Mozilla_Source_Code_Directory_Structure" title="en/Mozilla Source Code Directory Structure">Mozillaソースコードのガイド</a></dt>
- <dd>Mozilla のソースツリーに含まれている様々なフォルダの内容や、閲覧したいソースコード検索方法について解説します。</dd>
- <dt><a class="external" href="/en/Introduction#Find_a_bug_we%27ve_identified_as_a_good_fit_for_new_contributors." title="/en/Introduction#Find_a_bug_we%27ve_identified_as_a_good_fit__for_new_contributors.">初心者向けのバグ</a></dt>
- <dd>参加したいプロジェクトはあっても貢献したことがまだない場合、まずはこちらをご覧ください。</dd>
-</dl>
-</div>
-
-<div class="section">
-<dl>
- <dt><a class="internal" href="/En/Developer_Guide/Coding_Style" title="En/Mozilla Coding Style Guide">Mozilla コーディングスタイルのガイド</a></dt>
- <dd>自分が書いたソースコードを整形する方法や、レビュー結果で落ち込まないための方法をお教えします。</dd>
- <dt><a href="/En/Developer_Guide/Interface_development_guide" title="En/Developer Guide/Interface development guide">インターフェイス開発のガイド</a></dt>
- <dd>XPCOM インターフェイスの作成や改善する際のガイドラインを確認できます。</dd>
- <dt><a href="/en-US/docs/Mozilla/Developer_guide/SVG_Guidelines">SVG クリーンアップガイド</a></dt>
- <dd>新しい SVG を開発する際のベストプラクティスをまとめています。</dd>
- <dt><a class="link-https" href="https://wiki.mozilla.org/Build:TryServer" title="https://wiki.mozilla.org/Build:TryServer">Try Servers</a></dt>
- <dd>Mozilla のプロダクトは 3 つ以上のプラットフォームでビルドされています。すべてでビルドを試すことができない場合、自分の書いたパッチをテストサーバに送ってテストすることができます。</dd>
- <dt><a class="internal" href="/en/Creating_a_patch" title="En/Creating a patch">パッチを作成する</a></dt>
- <dd>Mozilla のソースコードに変更を加え、正しく動くことを確認できた次は、パッチを作成してレビューしてもらいましょう。<em>この記事は Mercurial 向けに全面的な更新が必要です。</em></dd>
- <dt><a class="external" href="http://www.mozilla.org/hacking/committer/" title="http://www.mozilla.org/hacking/committer/">ソースコードへのコミット権を得る</a></dt>
- <dd>Feel ready to join the few, the proud, the committers? Find out how to get check-in access to the Mozilla code.</dd>
- <dt><a class="internal" href="/En/Developer_Guide/Source_Code/CVS" title="En/Mozilla Source Code (CVS)">古い Mozilla ソースコードを CVS からダウンロードする</a></dt>
- <dd>古い Mozilla ソースコードや現在の NSS、NSPR におけるソースコードは CVS リポジトリで管理されています。CVS リポジトリからのダウンロード方法について解説します。</dd>
-</dl>
-</div>
-</div>
diff --git a/files/ja/mozilla/developer_guide/svg_guidelines/index.html b/files/ja/mozilla/developer_guide/svg_guidelines/index.html
deleted file mode 100644
index 1eea32fe92..0000000000
--- a/files/ja/mozilla/developer_guide/svg_guidelines/index.html
+++ /dev/null
@@ -1,197 +0,0 @@
----
-title: SVG ガイドライン
-slug: Mozilla/Developer_Guide/SVG_Guidelines
-translation_of: Mozilla/Developer_guide/SVG_Guidelines
----
-<p>The <a href="/en-US/docs/Web/SVG">SVG</a> format has the advantage of being able to describe complex images while being lightweight and to scaling them very well at all resolutions. Unfortunately, a lot of SVG files (often generated by SVG editors) ship without being cleaned up, so the benefit of them being lightweight is gone. Here are some best pratices to keep SVGs lightweight. These rules are based on some real examples seen in Mozilla's code.</p>
-
-<h2 id="Basics"><span class="author-g-1scq3ywqbljc5puc b">Basics</span></h2>
-
-<ul>
- <li><span class="author-g-1scq3ywqbljc5puc">2 spaces indenting</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">No useless whitespaces or linebreaks (see below for more details)</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">Adding a license header</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">Use double quotes</span></li>
-</ul>
-
-<h2 id="Whitespace_and_line_breaks">Whitespace and line breaks</h2>
-
-<div id="magicdomid5">
-<h3 id="Whitespace">Whitespace</h3>
-
-<p>In addition to trailing whitespace at the end of lines, there are a few more cases more specific to SVGs:</p>
-
-<ul>
- <li>Trailing whitespaces in attribute values (usually seen in path definitions)</li>
- <li>Excessive whitespace in path or polygon points definition</li>
-</ul>
-
-<h4 id="Examples">Examples</h4>
-
-<p>This path:<span class="author-g-g4g23bmoaru8by8u"> </span></p>
-
-<pre><span class="author-g-g4g23bmoaru8by8u">&lt;path d=" M5,5    L1,1z "&gt;</span></pre>
-
-<p><span class="author-g-g4g23bmoaru8by8u">can be cut down to this:</span></p>
-
-<pre><span class="author-g-g4g23bmoaru8by8u">&lt;path d="M5,5 L1,1z"&gt;</span></pre>
-
-<p>Similarly, this polygon:</p>
-
-<pre><span class="author-g-g4g23bmoaru8by8u">&lt;polygon points="  0,0   4,4  4,0  "/&gt;</span></pre>
-
-<p><span class="author-g-g4g23bmoaru8by8u">can be cut down to this:</span></p>
-
-<pre><span class="author-g-g4g23bmoaru8by8u">&lt;polygon points="0,0 4,4 4,0"/&gt;</span></pre>
-
-<h3 id="Line_breaks">Line breaks</h3>
-
-<p>You should only use line breaks for logical separation or if they help make the file readable. You should avoid line breaks between every single element or within attribute values. It's recommended to put the attributes on the same line as their tagnames if possible. You should also put the shortest attributes first so they are easier to spot.</p>
-
-<h2 id="Unused_tags_and_attributes"><span class="author-g-1scq3ywqbljc5puc b">Unused tags and attributes</span></h2>
-</div>
-
-<h3 id="Editor_metadata"><span class="author-g-1scq3ywqbljc5puc b">Editor metadata</span></h3>
-
-<p><span class="author-g-1scq3ywqbljc5puc b">Vector editors (Inkscape, Adobe Illustrator, Sketch, </span>…<span class="author-g-1scq3ywqbljc5puc b">) usually add a bunch of metadata in SVG files when saving them.</span> Metadata can mean many things, including:</p>
-
-<ul>
- <li>The common "Created with <em>editor</em>" comments</li>
- <li>Non-standard editor specific tags and attributes (<code>sketch:foo</code>, <code>illustrator:foo</code>, <code>sopodi:foo</code>, …)</li>
- <li>The <a href="/en-US/docs/Namespaces">XML namespace</a> definition that comes with the latter (<code>xmlns:sketch</code>, <code>xmlns:sopodi</code>, …)</li>
-</ul>
-
-<h3 id="Other_metadata">Other metadata</h3>
-
-<p>In addition to non-standard editor metadata, standard compliant metadata also exists. Common examples of this are <code>&lt;title&gt;</code> and <code>&lt;desc&gt;</code> tags. Although this kind of data is supported by the browser, it can only be displayed when the SVG is opened in a new tab. Plus, the filename is descriptive enough most of the time. So it's recommended to remove that kind of metadata, since it doesn't bring much value.</p>
-
-<p>You shouldn't include DOCTYPEs in your SVGs either, they are source of many issues and the SVG WG recommends not to include them. See <a href="https://jwatt.org/svg/authoring/#doctype-declaration">SVG Authoring guidelines</a>.</p>
-
-<h3 id="Avoid_the_use_of_CDATA_sections"><span class="author-g-1scq3ywqbljc5puc">Avoid the use of <span id="cke_bm_253E" class="hidden"> </span>CDATA sections</span></h3>
-
-<p><span class="author-g-1scq3ywqbljc5puc"><a href="/en-US/docs/Web/API/CDATASection">CDATA sections</a> are used to avoid parsing some text as HTML. Most of time, CDATA isn't needed, for example, the content in <code>&lt;style&gt;</code> tags doesn't need to be wrapped in a CDATA section as the content inside the tag is already properly parsed as CSS.</span></p>
-
-<h3 id="Invisible_shapes">Invisible shapes</h3>
-
-<p>There are 2 kinds of invisible shapes: the offscreen ones and the uncolored ones.</p>
-
-<p>The offscreen shapes are hard to spot, even with an automated tool, and are usually context aware. Those kind of shapes are visible, but off the <a href="/en-US/docs/Web/SVG/Attribute/viewBox">SVG view box</a>. Here's <a href="https://hg.mozilla.org/mozilla-central/diff/9fb143f3b36a/browser/themes/shared/heartbeat-star-lit.svg">an example</a> of a file with offscreen shapes.</p>
-
-<p>On the other hand, the uncolored ones are easier to spot, since they usually come with styles making them invisible. They must meet 2 conditions: they must have no fill (or a transparent one) and no stroke.</p>
-
-<h3 id="Unused_attributes_on_root_&lt;svg>_element">Unused attributes on root <code>&lt;svg</code>&gt; element</h3>
-
-<p>The root <code>&lt;svg&gt;</code> element can also host many useless attributes. Here's an <a href="https://hg.mozilla.org/mozilla-central/diff/2d38fecce226/browser/components/loop/content/shared/img/icons-10x10.svg">example</a> taking into account the list below:</p>
-
-<ul>
- <li><code><span class="author-g-1scq3ywqbljc5puc">version</span></code></li>
- <li><span class="author-g-1scq3ywqbljc5puc"><code>x="0"</code> and <code>y="0"</code></span></li>
- <li><span class="author-g-1scq3ywqbljc5puc"><code>enable-background</code> (unsupported by Gecko and now deprecated by the Filter Effects specification</span><span class="author-g-1scq3ywqbljc5puc">)</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc"><code>id</code> (id on root element has no effect)</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc"><code>xmlns:xlink</code> attribute when there are no <code>xlink:href</code> attributes used throughout the file</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">Other unused <a href="/en-US/docs/Namespaces">XML Namespace</a> definitions</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc"><code>xml:space</code> when there is no text used in the file</span></li>
-</ul>
-
-<h3 id="Other">Other</h3>
-
-<ul style="list-style-type: disc;">
- <li>Empty tags, this may be obvious, but those are sometimes found in SVGs</li>
- <li><span class="author-g-1scq3ywqbljc5puc">Unreferenced ids (usually on gradient stops, but also on shapes or paths)</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc"><code><a href="/en-US/docs/Web/SVG/Attribute/clip-rule">clip-rule</a></code> attribute when the element </span><u><strong><span class="author-g-1scq3ywqbljc5puc u">is not</span></strong></u><span class="author-g-1scq3ywqbljc5puc"> a descendant of a <code><a href="/en-US/docs/Web/SVG/Element/clipPath">&lt;clipPath&gt;</a></code></span></li>
- <li><span class="author-g-1scq3ywqbljc5puc"><code><a href="/en-US/docs/Web/SVG/Attribute/fill-rule">fill-rule</a></code> attribute when the element </span><u><strong><span class="author-g-1scq3ywqbljc5puc u">is</span></strong></u><span class="author-g-1scq3ywqbljc5puc"> a descendant of a <code><a href="/en-US/docs/Web/SVG/Element/clipPath">&lt;clipPath&gt;</a></code></span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">Unreferenced/Unused clip paths, masks or defs (<a href="https://hg.mozilla.org/mozilla-central/diff/2d38fecce226/toolkit/themes/shared/reader/RM-Plus-24x24.svg">example</a>)</span></li>
-</ul>
-
-<h2 id="Styling"><span class="author-g-1scq3ywqbljc5puc b">Styling</span></h2>
-
-<h3 id="Basics_2">Basics</h3>
-
-<ul>
- <li><span class="author-g-1scq3ywqbljc5puc">Privilege short lowercase hex for colors</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">Don't use excessive precision for numeric values (usually comes from illustrator)</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">Use descriptive IDs </span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">Avoid inline styles and use class names or SVG attributes</span></li>
-</ul>
-
-<h4 id="Examples_2"><span class="author-g-1scq3ywqbljc5puc">Examples</span></h4>
-
-<p>Here are some examples for excessive number precision:</p>
-
-<ul>
- <li><span class="author-g-1scq3ywqbljc5puc">5.000000e-02 </span>→<span class="author-g-1scq3ywqbljc5puc"> 0.05 (as seen <a href="https://hg.mozilla.org/mozilla-central/diff/2d38fecce226/browser/themes/shared/devtools/images/tool-network.svg#l1.31">here</a>)</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">-3.728928e-10 </span>→<span class="author-g-1scq3ywqbljc5puc"> 0 (as seen <a href="https://hg.mozilla.org/mozilla-central/diff/2d38fecce226/browser/themes/shared/aboutNetError_alert.svg#l1.12">here</a>)</span></li>
- <li>t<span class="author-g-1scq3ywqbljc5puc">ranslate(0.000000, -1.000000) </span>→<span class="author-g-1scq3ywqbljc5puc"> translate(0, -1) (as seen <a href="https://hg.mozilla.org/mozilla-central/diff/2d38fecce226/browser/themes/shared/heartbeat-icon.svg#l1.13">here</a>)</span></li>
-</ul>
-
-<p>As for descriptive IDs:</p>
-
-<ul>
- <li><span class="author-g-1scq3ywqbljc5puc">For gradients: SVG_ID1 </span>→<span class="author-g-1scq3ywqbljc5puc"> gradient1 (as seen <a href="https://hg.mozilla.org/mozilla-central/diff/2d38fecce226/browser/themes/shared/aboutNetError_alert.svg#l1.12">here</a>)</span></li>
-</ul>
-
-<h3 id="Use_of_class_names"><span class="author-g-1scq3ywqbljc5puc b">Use of class names</span></h3>
-
-<ul>
- <li><span class="author-g-g4g23bmoaru8by8u">Avoid using a class if that class is only used once in the file</span></li>
- <li><span class="author-g-g4g23bmoaru8by8u">If that class only sets a fill or a stroke, it's better to set the fill/stroke directly on the actual shape, instead of introducing a class just for that shape, you can also use SVG grouping to avoid duplicating those attributes</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc">Avoid introducing variants of the same file (color/style variants), and use sprites instead (with class names)</span></li>
-</ul>
-
-<h3 id="Default_style_values"><span class="author-g-1scq3ywqbljc5puc b">Default style values</span></h3>
-
-<p><span class="author-g-1scq3ywqbljc5puc b">There's usually no need to set the default style value unless you're overriding a style. Here are some commonly seen examples:</span></p>
-
-<ul>
- <li><span class="author-g-1scq3ywqbljc5puc"><code>type="text/css"</code> on <code>&lt;style&gt;</code> elements</span></li>
- <li><span class="author-g-1scq3ywqbljc5puc"><code>stroke: none</code> or <code>stroke-width: 0</code></span></li>
-</ul>
-
-<h2 id="SVG_grouping">SVG grouping</h2>
-
-<h3 id="Style_grouping">Style grouping</h3>
-
-<p>Group similarly styled shapes under one <code>&lt;g&gt;</code> tag, this avoids having to set the same class/styles on many shapes.</p>
-
-<h3 id="Avoid_excessive_grouping">Avoid excessive grouping</h3>
-
-<p>Editors can sometimes do excessive grouping when exporting SVGs. This is due to the way editors work.</p>
-
-<h4 id="Nested_groups">Nested groups</h4>
-
-<p>Avoid multiple-level nesting of groups, these make the SVG less readable.</p>
-
-<h4 id="Nested_transforms">Nested transforms</h4>
-
-<p>Some editors use <code>&lt;g&gt;</code> tags to do nested transforms, which is usually not needed. You can avoid this by doing basic algebra, for example:</p>
-
-<pre><span class="author-g-1scq3ywqbljc5puc">&lt;g transform="translate(-62, -310)"&gt;&lt;shape transform="translate(60, 308)"/&gt;&lt;/g&gt;</span></pre>
-
-<p><span class="author-g-1scq3ywqbljc5puc">can be cut down to:</span></p>
-
-<pre><span class="author-g-1scq3ywqbljc5puc">&lt;shape transform="translate(-2,-2)"/&gt;</span></pre>
-
-<p><span class="author-g-1scq3ywqbljc5puc">because: -62+60 = -310+308 = -2</span></p>
-
-<h2 id="Performance_tips"><span class="author-g-1scq3ywqbljc5puc b">Performance tips</span></h2>
-
-<p>These rules are optional, but they help speeding up the SVG.</p>
-
-<ul>
- <li><span class="author-g-1scq3ywqbljc5puc">Avoid using a <code>&lt;use&gt;</code> tag when that <code>&lt;use&gt;</code> tag is being referenced only once in the whole file</span></li>
- <li>Instead of using CSS/SVG <a href="/en-US/docs/Web/SVG/Attribute/transform">transforms</a>, apply directly the transform on the path/shape definition</li>
-</ul>
-
-<h2 id="Tools">Tools</h2>
-
-<p>Tools can help clean SVG files. Note however that some of the rules stated above can be hard to detect with automated tools since they require too much context-awereness.<br>
- To this date, there doesn't seem to be a tool that handles all of the above. However, there are some existing utilities that cover some parts of this document:</p>
-
-<ul>
- <li>Mostly complete command line tool: <a href="https://github.com/svg/svgo">https://github.com/svg/svgo</a></li>
- <li>GUI for command line tool (use with "Prettify code" and "Remove <code>&lt;title&gt;</code>" options on): <a href="https://jakearchibald.github.io/svgomg/">https://jakearchibald.github.io/svgomg/</a></li>
- <li>Good alternative to SVGO/SVGOMG: <a href="http://petercollingridge.appspot.com/svg-editor">http://petercollingridge.appspot.com/svg-editor</a></li>
- <li><span class="author-g-1scq3ywqbljc5puc">Fixes the excessive number precision: </span><span class="author-g-1scq3ywqbljc5puc url"><a href="https://simon.html5.org/tools/js/svg-optimizer/">https://simon.html5.org/tools/js/svg-optimizer/</a></span></li>
- <li><span class="author-g-1scq3ywqbljc5puc url">Converts inline styles to SVG attributes:</span><span class="author-g-1scq3ywqbljc5puc url"> </span><a href="http://www.w3.org/wiki/SvgTidy">http://www.w3.org/wiki/SvgTidy</a></li>
- <li><span class="author-g-1scq3ywqbljc5puc">RaphaelJS has a couple of utilities that may be useful: </span><span class="author-g-1scq3ywqbljc5puc url"><a href="http://raphaeljs.com/reference.html">http://raphaeljs.com/reference.html</a></span></li>
-</ul>