# Django 5.2.8 ドキュメント

# ドキュメントを書く

私たちはドキュメントの一貫性と読みやすさを重要視しています。結局のところ、Django はジャーナリズムの環境で作られました！ですから、私たちはコードを扱うようにドキュメントを扱います。できるだけ頻繁に改善することを目指しています。

ドキュメンテーションの変更には、一般的に2つの形式があります:

- 全般的な改善: 誤字脱字の修正、エラーの修正、より分かりやすい文章とより多くの例による説明の改善。

- 新機能: 前回のリリース以降にフレームワークに追加された機能のドキュメントです。

このセクションでは、ライターが最も有用でミスの少ない方法で文書の変更を行う方法について説明します。

## Django のドキュメント作成プロセス

Django のドキュメントは、 https://docs.djangoproject.com/ で HTML として読まれることを想定していますが、柔軟性を最大にするために、 reStructuredText マークアップ言語で書かれたプレーンテキストファイルの集合として編集しています。

私たちは開発版のリポジトリで作業します。なぜなら、最新かつ最高のドキュメントがあり、最新かつ最高のコードがあるからです。

また、マージャーの判断で、ドキュメントの修正や改良を最後のリリースブランチにバックポートします。これは、最終リリースのドキュメントが最新で正しい方が有利だからです (バージョンごとの違い を参照してください)。

Django のドキュメンテーションは Sphinx ドキュメンテーションシステムを使っ ており、docutils をベースにしています。基本的な考え方は、軽く整形されたプレーンテキストのドキュメントを HTML や PDF などの出力形式に変換するというものです。

Sphinxには `sphinx-build` コマンドがあり、 reStructuredText を他のフォーマット、例えば HTML や PDF に変換できます。このコマンドは設定可能ですが、Djangoのドキュメンテーションには `Makefile` があり、より短い `make html` コマンドを提供しています。

## ドキュメントの構成

ドキュメントはいくつかのカテゴリーに分類されています:

- チュートリアル は、何かを作るための一連のステップを読者に手取り足取り教えてくれます。

  チュートリアルで重要なことは、読者に自信を持たせるために、できればできるだけ早い段階で、何か役に立つことを達成させることです。

  解決しようとしている問題の性質を説明することで、読者がこれから達成しようとしていることを理解できるようにしてください。物事がどう機能するかについての説明から始める必要はありません。重要なのは読者が何をするかであり、あなたが説明する内容ではありません。行ったことを振り返り、その後で説明することは時に有用です。

- トピックガイド は、概念や主題をかなり高いレベルで説明することを目的としています。

  参考資料を繰り返すのではなく、リンクさせましょう。自分にとっては基本的なことでも、他の人には必要な説明かもしれません。

  背景となる文脈を提供することで、初心者がトピックをすでに知っている事柄と結びつけることができます。

- リファレンスガイド には API の技術的なリファレンスが含まれています。Django の内部的な仕組みや使い方を説明しています。

  参考資料は主題にしっかりと焦点を絞ってください。読者はすでに基本的な概念を理解しているが、 Django がどのようにそれを行うかを知るか、思い出す必要があると仮定してください。

  リファレンスガイドは、一般的な説明をする場所ではありません。基本的な概念を説明する場合は、その資料をトピックガイドに移すとよいでしょう。

- How-to ガイド は鍵となる主題に関して、いくつかのステップを踏んで説明しているレシピ集です。

  ハウツーガイドで最も重要なのは、ユーザが何を達成したいかです。ハウツーは常に、 Django が何をどのように実装しているかという内部的な詳細に焦点を当てるよりも、結果指向であるべきです。

  これらのガイドはチュートリアルよりも高度で、Django がどのように動作するかについて、ある程度の知識があることを前提としています。読者はチュートリアルに従ったことがあると仮定し、同じ内容を繰り返すのではなく、適切なチュートリアルに戻ることを躊躇しないでください。

## ドキュメントの寄稿を始めるには

### Django リポジトリをローカルマシンにクローンします。

ドキュメントへの貢献を始めたい場合は、ソースコードリポジトリから Django の開発版を入手してください (開発バージョンをインストールする を参照してください):

/ 

    $ git clone https://github.com/django/django.git

    ...\> git clone https://github.com/django/django.git

これらの変更を提出するつもりなら、代わりに Django リポジトリをフォークして、このフォークをクローンすると便利かもしれません。

### 仮想環境のセットアップと依存関係のインストール

仮想環境を作成してアクティブにし、依存関係をインストールします:

    $ python -m venv .venv
    $ source .venv/bin/activate
    $ python -m pip install -r docs/requirements.txt

### ドキュメントをローカルでビルドする

`docs` ディレクトリから HTML 出力をビルドできます:

/ 

    $ cd docs
    $ make html

    ...\> cd docs
    ...\> make.bat html

ローカルにビルドされたドキュメントは `_build/html/index.html` にアクセスできるようになり、どのウェブブラウザでも閲覧できるようになりますが、 docs.djangoproject.com にあるドキュメントとは異なるテーマで表示されます。これはOKです！あなたのローカルマシンで変更がうまくいけば、 ウェブサイトでもうまくいくでしょう。

### ドキュメントの編集

ソースファイルは `docs/` ディレクトリにある `.txt` ファイルです。

これらのファイルはreStructuredTextマークアップ言語で書かれています。マークアップを学ぶには reStructuredText reference を参照してください。

このページを編集するには、例えば docs/internals/contributing/writing-documentation.txt というファイルを編集し、 `make html` でHTMLを再構築します。

### Documentation quality checks

Several checks help maintain Django's documentation quality, including spelling, code block formatting, and documentation style.

These checks are run automatically in CI and must pass before documentation changes can be merged. They can also be run locally with a single command:

/ 

    $ make check

    ...\> make.bat check

This command runs all current checks and will include any new checks added in the future.

#### スペルチェック

Before you commit your docs, it's a good idea to run the spelling checker. You'll need to install sphinxcontrib-spelling first. Then from the `docs` directory, run:

/ 

    $ make spelling

    ...\> make.bat spelling

Wrong words (if any) along with the file and line number where they occur will be saved to `_build/spelling/output.txt`.

誤検出（実際には正しいのに検出されたエラー）が発生した場合は、以下のいずれかを行ってください:

- Surround inline code or brand/technology names with double grave accents (``)

- スペルチェッカーが認識する同義語を探します。

- あなたが使っている単語が正しいと確信できる場合のみ、その単語を `docs/spelling_wordlist` に追加してください（リストはアルファベット順にしてください）。

#### Code block format check

All Python code blocks should be formatted using the blacken-docs auto-formatter. This is automatically run by the pre-commit hook if configured.

The check can also be run manually: provided that `blacken-docs` is installed, run the following command from the `docs` directory:

/ 

    $ make black

    ...\> make.bat black

The formatter will report any issues by printing them to the terminal and will reformat code blocks where possible.

#### Documentation lint check

Django's documentation is checked for reStructuredText style and formal issues using sphinx-lint. This helps catch problems like stray tabs, trailing whitespace, excessive line length, and similar formatting problems.

Once `sphinx-lint` is installed, the check can be run with the following command from the `docs` directory:

/ 

    $ make lint

    ...\> make.bat lint

The command prints any violations to the terminal in the form `path:line: message`. If problems are encountered:

- Read the message and fix the indicated issue (for example, remove trailing whitespace, adjust backticks, or replace tabs with spaces).

- For long lines consider wrapping text onto new lines or breaking long inline links into named references. The custom line length check should already skip common false positives such as headings, tables and long links.

### リンクの確認

Links in documentation can become broken or changed such that they are no longer the canonical link. Sphinx provides a builder that can check whether the links in the documentation are working. From the `docs` directory, run:

/ 

    $ make linkcheck

    ...\> make.bat linkcheck

Output is printed to the terminal, but can also be found in `_build/linkcheck/output.txt` and `_build/linkcheck/output.json`.

警告

The execution of the command requires an internet connection and takes several minutes to complete, because the command tests all the links that are found in the documentation.

ステータスが "working "のエントリーは問題ありませんが、"unchecked "または "ignored "のエントリーは、チェックできないか、設定の無視ルールにマッチしているため、スキップされています。

ステータスが "broken" のエントリは修正する必要があります。 "redirected" のステータスを持つものは、正規の場所を指すように更新する必要があるかもしれません。例えば、スキームが `http://` → `https://` に変更された場合などです。場合によっては、"redirected" リンクを更新したくないこともあります。例えば、常にドキュメントの最新版や安定版を指すように書き換えたい場合などです。例えば、 `/en/stable/` → `/en/3.2/` のようにです。

## 執筆スタイル

"セッション・クッキーを持つユーザ" のような、仮想的な人物を指して代名詞を使うときは、下記のようなものの代わりに、性別に中立な代名詞(they/their/them)を使うべきです。:

- he や she... they を使います。

- him や her... them を使います。

- his や her... their を使います。

- his や hers... theirs を使います。

- himself や herself... themselves を使います。

「簡単に」、「単に」、「ただ」、「単に」、「単純に」など、作業や操作の難しさを最小化するような言葉はなるべく使わないようにしましょう。人々の経験とあなたの期待とは一致しないかもしれませんし、暗示されているような「簡単な」「単純な」ステップを見つけられなかったときに、不満を抱くかもしれません。

## よく使われる用語

ここでは、ドキュメントの中でよく使われる用語についてのスタイルガイドラインを示します:

- Django -- このフレームワークを指すときは、Django を大文字にします。Python のコードと djangoproject.com のロゴの中だけ小文字です。

- email -- ハイフンなし。

- HTTP -- 予想される発音は "Aitch Tee Tee Pee "なので、"a "ではなく "an "を前に置くべきです。

- MySQL, PostgreSQL, SQLite

- SQL -- SQLを指す場合、"sequel "ではなく、"Ess Queue Ell "と発音します。したがって、"Returns an SQL expression "のようなフレーズでは、"SQL "の前に "an "を付けるべきであり、"a "を付けるべきではありません。

- Python -- 言語を指すときは、Pythonを大文字にします。

- realize, customize, initialize など。接尾辞は "ise" ではなく、アメリカの "ize" を使います。

- subclass -- 動詞（「そのモデルをサブクラス化する」）としても名詞（「サブクラスを作成する」）としても、ハイフンなしの1語です。

- the web, web framework -- 大文字ではありません。

- website -- 大文字にせず、1語にしてください。

## Django 特有の用語

- model -- 大文字ではありません。

- template -- 大文字ではありません。

- URLconf -- "conf "の前にはスペースを入れず、大文字を3文字使います。

- view -- 大文字ではありません。

## reStructuredText ファイルのガイドライン

このガイドラインは、reST（reStructuredText）文書の書式を規定しています:

- セクションのタイトルでは、最初の単語と固有名詞のみ先頭を大文字にします。

- コード例が2行に分割されると著しく読みにくくなる場合や、その他の正当な理由がある場合を除き、ドキュメントは80文字の幅で折り返します。

- ドキュメントを書いたり編集したりするときに心に留めておくべきことは、セマンティックなマークアップは多ければ多いほど良いということです。よって:

      Add ``django.contrib.auth`` to your ``INSTALLED_APPS``...

  このように書くより、次のように書くほうが役立ちます:

      Add :mod:`django.contrib.auth` to your :setting:`INSTALLED_APPS`...

  これは、Sphinxが後者のために適切なリンクを生成してくれるからです。

  ターゲットの前に `~` (チルダ) を付けると、そのパスの「最後の部分」だけを取得できます。つまり、 `:mod:`~django.contrib.auth`` は "auth" というタイトルのリンクを表示します。

- PythonとSphinxのドキュメントを参照するには、 `intersphinx` を使用してください。

- リテラルブロックには `.. code-block:: <lang>` を追加して、ハイライトされるようにします。 `::` （2つのコロン）を使用した自動ハイライトに頼るほうがいいでしょう。これには、コードに無効な構文が含まれていてハイライトされないような場合に利点があります。たとえば `.. code-block:: python` を追加すると、無効な構文があっても強制的にハイライトされます。

- 可読性を向上させるために、 `.. note::` の代わりに `.. admonition:: Descriptive title` を使用してください。これらのボックスは控えめに使用してください。

- これらの見出しスタイルを使用してください:

      ===
      One
      ===

      Two
      ===

      Three
      -----

      Four
      ~~~~

      Five
      ^^^^

- Use `:rfc:` to reference a Request for Comments (RFC) and try to link to the relevant section if possible. For example, use `:rfc:`2324#section-2.3.2`` or `:rfc:`Custom link text <2324#section-2.3.2>``.

- Python Enhancement Proposal (PEP) を参照するには `:pep:` を使い、可能であれば関連するセクションにリンクするようにしてください。例えば、 `:pep:`20#easter-egg`` や `:pep:`Easter Egg <20#easter-egg>`` を使います。

- コードの例で値が引用符で囲まれていない限り、MIMEタイプを参照するには `:mimetype:` を使用します。

- 環境変数を参照するには `:envvar:` を使います。また、 `.. envvar::` を使って、その環境変数のドキュメントへの参照を定義する必要があるかもしれません。

- Use `:cve:` to reference a Common Vulnerabilities and Exposures (CVE) identifier. For example, use `:cve:`2019-14232``.

## Django 固有のマークアップ

Sphinx's built-in markup 以外にも、Djangoドキュメントではいくつかの追加拡張を利用しています：

- 設定:

      .. setting:: INSTALLED_APPS

  設定にリンクするには `:setting:`INSTALLED_APPS`` を使用します。

- テンプレートタグ:

      .. templatetag:: regroup

  リンクするには `:ttag:`regroup`` を使います。

- テンプレートフィルタ:

      .. templatefilter:: linebreaksbr

  リンクするには `:tfilter:`linebreaksbr`` を使います。

- フィールドのルックアップ (例 `Foo.objects.filter(bar__exact=whatever)`):

      .. fieldlookup:: exact

  リンクするには `:lookup:`exact`` を使います。

- `dango-admin` コマンド:

      .. django-admin:: migrate

  リンクするには `:djadmin:`migrate`` を使用します。

- `django-admin` のコマンドラインオプション:

      .. django-admin-option:: --traceback

  リンクするには、 `:option:`command_name --traceback`` を使います（ `--verbosity` のようなすべてのコマンドに共通するオプションの場合は `command_name` を省略することもできます）。

- Trac チケットへのリンク (通常、パッチリリースノート用に予約されています):

      :ticket:`12345`

Django のドキュメントでは、 `djangoo-admin` や `manage.py`, `python` などのコマンドラインの例をドキュメント化するために、カスタム の `console` ディレクティブを使っています。例）HTML ドキュメントでは、2 つのタブの UI を表示し、1 つのタブでは Unix スタイルのコマンドプロンプトを表示し、2 番目のタブでは Windows プロンプトを表示します。

例えば、次のような断片を:

    use this command:

    .. code-block:: console

        $ python manage.py shell

このように置き換えることができます:

    use this command:

    .. console::

        $ python manage.py shell

下記の2点に注意してください:

- 通常、 `.. code-block:: console` ディレクティブの出現箇所を置き換えることになります。

- コード例の実際の内容を変更する必要はありません。Unixライクな環境（つまり、 `'$'` というプロンプト記号、ファイルシステムパスコンポーネントの区切りとしての `'/'` など）を前提にしたまま記述します。

上の例では、2つのタブを持つコード例ブロックがレンダリングされます。最初のタブは:

    $ python manage.py shell

(`.. code-block:: console` がレンダリングするものと変わりません)。

２つめのタブは次のようになります:

    ...\> py manage.py shell

## 新機能のドキュメントを書く

私たちの新機能に関するポリシーは以下のとおりです:

> 新機能のドキュメントはすべて、Django の開発版でしか利用できない機能を明確に指定するように書くべきです。ドキュメントの読者は開発版ではなく、最新のリリースを使っていると仮定してください。

新機能をマークするには、その機能のドキュメントの前に "`.. versionadded:: X.Y`" を付与し、必須の空白行とオプションの説明（インデントされたもの）を続けます。

APIへの一般的な改善や強調すべきその他の変更には、 "`.. versionchanged:: X.Y`" ディレクティブを使用してください（上述の "`versionadded`" と同じフォーマットです）。

これらの `versionadded` と `versionchanged` ブロックは "自己完結型" であるべきです。言い換えると、これらの注釈は2つのリリースの間だけ残しておくために、周囲のテキストをリフローしたり、インデントを変更したり、編集したりすることなく、注釈とその内容を削除できればいいのです。例えば、新機能や変更された機能の説明全体をブロックに入れる代わりに、次のようにします:

    .. class:: Author(first_name, last_name, middle_name=None)

        A person who writes books.

        ``first_name`` is ...

        ...

        ``middle_name`` is ...

        .. versionchanged:: A.B

            The ``middle_name`` argument was added.

changed 注釈ノートはセクションの上ではなく、一番下に配置します。

また、 `versionadded` や `versionchanged` ブロックの外側で Django の特定のバージョンを参照するのは避けてください。ブロックの中であっても、これらのアノテーションはそれぞれ "New in Django A.B:" や "Changed in Django A.B" としてレンダリングされるので、そうするのは冗長な場合が多いです。

関数や属性などが追加された場合は、このように `versionadded` 注釈を使っても構いません:

    .. attribute:: Author.middle_name

        .. versionadded:: A.B

        An author's middle name.

この `.. versionadded:: A.B` 注釈は、インデントを変更することなく削除できます。

## 画像を縮小する

可能な限り画像圧縮を最適化してください。 PNG ファイルの場合は、 OptiPNG と AdvanceCOMP の `advpng` を使用してください:

/ 

    $ cd docs
    $ optipng -o7 -zm1-9 -i0 -strip all `find . -type f -not -path "./_build/*" -name "*.png"`
    $ advpng -z4 `find . -type f -not -path "./_build/*" -name "*.png"`

    ...\> cd docs
    ...\> optipng -o7 -zm1-9 -i0 -strip all `find . -type f -not -path ".\_build\*" -name "*.png"`
    ...\> advpng -z4 `find . -type f -not -path ".\_build\*" -name "*.png"`

これは OptiPNG バージョン 0.7.5 に基づいています。古いバージョンは、`-strip all` オプションが非可逆であることに文句を言うかもしれません。

## 例

それぞれの例がどのように連携するのか、簡単な例を見てみましょう:

- まず、 `ref/settings.txt` ドキュメント全体のレイアウトはこのようになっています:

      ========
      Settings
      ========

      ...

      .. _available-settings:

      Available settings
      ==================

      ...

      .. _deprecated-settings:

      Deprecated settings
      ===================

      ...

- 次に、 `topics/settings.txt` ドキュメントには以下のような内容が含まれるかもしれません:

      You can access a :ref:`listing of all available settings
      <available-settings>`. For a list of deprecated settings see
      :ref:`deprecated-settings`.

      You can find both in the :doc:`settings reference document
      </ref/settings>`.

  別のドキュメント全体へのリンクを作成したい場合は Sphinx の `doc` クロスリファレンス要素を使用し、ドキュメント内の任意の場所へのリンクを作成したい場合は `ref` 要素を使用します。

- 次に、設定がどのようにアノテーションされているかに注目してください:

      .. setting:: ADMINS

      ADMINS
      ======

      Default: ``[]`` (Empty list)

      A list of all the people who get code error notifications...

  これにより、以降のヘッダが `ADMINS` という設定の "正規の" ターゲットとしてマークアップされます。これは `ADMINS` について話すときはいつでも `:setting:`ADMINS`` を使って参照できることを意味します。

これが基本的な組み立て方です。

## ドキュメントを翻訳する

ドキュメントを他の言語に翻訳したい場合は Django ドキュメントのローカライズ を参照してください。

## `django-admin` の man ページ

Sphinxは django-admin コマンドのマニュアルページを生成できます。これは `docs/conf.py` で設定します。他のドキュメントの出力とは異なり、このマニュアルページは `docs/man/django-admin.1` として Django リポジトリやリリースに含める必要があります。ドキュメントを更新する際に、このファイルを更新する必要はありません。

To generate an updated version of the man page, in the `docs` directory, run:

/ 

    $ make man

    ...\> make.bat man

The new man page will be written in `docs/_build/man/django-admin.1`.