Kami menempatkan sangat penting pada konsistensi dan kesiapan dari dokumentasi. Lagipula, Django dibuat dalam lingkungan jurnalis! Jadi kami memperlakukan dokumentasi kami seperti kami memperlakukan kode kami: kami membidik untuk meningkatkannya sesering mungkin.
Dokumentasi berubah secara umum datang dalam dua bentuk:
Bagian ini menjelaskan bagaimana penulis dapat mengerjakan perubahan dokumentasi mereka dalam cara paling berguna dan setidaknya lawan kesalahan.
Meskipun dokumentasi Django diperuntukkan untuk dibaca sebagai HTML di https://docs.djangoproject.com/, kami menyuntingnya sebagai kumpulan dari berkas-berkas teks untuk fleksibel maksimal. Berkas-berkas ini berada di tingkat-atas pelipat docs/
dari terbitan Django.
Jika anda ingin mulai memperbaiki dokumen kami, dapatkan versi pengembangan dari Django dari gudang kode sumber (lihat Memasang versi pengembangan). Versi pengembangan mempunyai dokumentasi terakhir-dan-terhebat, hanya karena itu memiliki kode terakhir-dan-terhebat. Kami juga backport dokumentasi pembenaran dan perbaikan, pada kebijaksanaan dari pembuat perbaikan, ke cabang terbitan terakhir. Yakni karena itu sangat menguntungkan memiliki dokumen untuk terbitan terakhir menjadi terbaru dan benar (lihat Perbedaan diantara versi).
Dokumentasi Django menggunakan sistem dokumentasi Sphinx, yang pada gilirannya berdasarkan pada docutils. Ide dasar adalah bahwa dokumentasi teks-tawar berbentuk-ringan dirubah kedalam HTML, PDF, dan bentuk keluaran lainnya.
Untuk membangun dokumentasi lokal, pasang Sphinx:
$ pip install Sphinx
...\> pip install Sphinx
Kemudian dari direktori docs
, bangun HTML:
$ make html
...\> make.bat html
Untuk memulai membantu, anda akan ingin membaca reStructuredText reference.
Dokumentasi bangun-lokal anda akan di temakan berbeda dari dokumentasi pada docs.djangoproject.com. Ini adalah OKE! Jika perubahan anda terlihat baik pada mesin lokal anda, mereka akan mencari hal yang baik pada situs jaringan.
Dokumentasi disusun kedalam beberapa kategori:
Tutorials membawa pembaca dengan tangan melalui rangkaian langkah-langkah untuk membuat sesuatu.
Hal terpenting dalam tutorial ini adalah membantu pembaca mendapatkan sesuatu berguna, lebih disukai seawal mungkin, agar memberikan mereka rasa nyaman.
Jelaskan sifat dari masalah kami sedang tangani, sehingga pembaca mengerti apa kami sedang coba capai. Jangan merasa bahwa anda butuh memulai dengan penjelasan bagaimana hal-hal bekerja - apa masalahnya adalah apa yang pembaca lakukan, bukan apa anda jelaskan. Itu dapat membantu menunjukkan kembali ke apa anda telah lakukan dan jelaskan kemudian.
Topic guides bertujuan untuk menjelaskan konsep atau subjek pada tingkatan yang cukup tinggi.
Tautkan ke bahan acuan daripada mengulanginya. Gunakan contoh dan jangan enggan menjelaskan hal-hal yang kelihatan sangan dasar ke anda- itu mungkin penjelasan seseorang lain butuhkan.
Menyediakan konteks latar belakang membantu pendatang baru menghubungkan topik ke hal-hal yang mereka sudah ketahui.
Reference guides mengandung acuan teknis untuk API. Mereka menggambarkan fungsi dari perlengkapan dalam Django dan petunjuk dalam penggunaannya.
Jaga bahan acuan fokus pada subyek. Anggap bahwa pembaca sudah memahami konsep dasar yang dilibatkan tetapi butuh mengetahui atau diingatkan dari bagaimana Django melakukannya.
Panduan acuan bukanlah tempat untuk penjelasan umum. Jika anda menemukan penjelasan konsep dasar, anda mungkin ingin memindahkan bahan itu ke panduan topik.
How-to guides adalah resep yang membawa pembaca melalui langkah-langkah dalam subjek kunci.
Masalah-masalah apa paling di panduan bagaimana adalah apa yang pengguna ingin untuk dicapai. Bagaimana harus selalu berorientasi hasil daripada fokus pada rincian internal dari bagaimana Django menerapkan apapun yang sedang diobrolkan.
Panduan ini lebih maju daripada tutorial dan anggapan beberapa pengetahuan tentang bagaimana Django bekerja. Anggap bahwa pembaca telah mengikuti tutorial dan tidak ragu-ragu untuk menunjuk pembaca kembali ke tutorial sesuai daripada mengulangi bahan yang sama.
Ketika menggunakan kata ganti di acuan pada hipotesis orang, seperti "pengguna dengan sesi kue", kata ganti netral kelamin (they/their/them) harus digunakan. Sebagai gantinya:
Ini adalah beberapa panduan pada istilah paling umum digunakan sepanjang dokumentasi:
Panduan ini mengatur bentuk dari dokumentasi dari reST (reStructuredText) kami:
Di judul bagian, huruf besar hanya kata permulaan dan kata benda yang tepat.
Bungkus dokumentasi pada lebar 80 karakter, meskipun sebuah contoh kode secara signifikan kurang dibaca ketika dipisah terhadap dua baris, atau untukalasan baik lainnya.
Hal utama untuk diingat ketika anda menulis dan menyunting dokumen adalah bahwa lebih markah semantik anda dapat tambah lebih baik. jadi:
Add ``django.contrib.auth`` to your ``INSTALLED_APPS``...
Hampir tidak bermanfaat sebagai
Add :mod:`django.contrib.auth` to your :setting:`INSTALLED_APPS`...
Ini karena Sphinx akan membangkitkan kaitan yang tepat untuk yang terakhir, yang sangat membantu pembaca.
Anda dapat awali sasaran dengan sebuah ~
(itu adalah tilde) untuk mendapatkan "bit terakhir" dari jalur. Jadi :mod:`~django.contrib.auth`
akan hanya menampilkan sebuah tautan dengan judul "auth".
Gunakan intersphinx
untuk mengacu dokumentasi Python and Sphinx'.
Tambah .. code-block:: <lang>
pada blok tepat sehingga mereka mendapatkan disorot. Pilih mengandalkan pada penyorotan otomatis hanya menggunakan ::
(dua titik dua). Ini mempunyai keuntungan bahwa jika kode mengandung beberapa sintaksis tidak sah, itu tidak akan disorot. Menambahkan .. code-block:: python
, sebagai contoh, akan memaksa menyorot meskipun sintaksis tidak sah.
Gunakan gaya kepala ini:
===
One
===
Two
===
Three
-----
Four
~~~~
Five
^^^^
Selain Sphinx's built-in markup, dokumen Django menentukan beberapa satuan penjelasan tambahan:
Pengaturan:
.. setting:: INSTALLED_APPS
Untuk mengkaitkan ke pengaturan, gunakan :setting:`INSTALLED_APPS`
.
Cetakan etiket:
.. templatetag:: regroup
Untuk mengkaitkan, gunakan :ttag:`regroup`
.
Cetakan penyaring:
.. templatefilter:: linebreaksbr
Untuk mengkaitkan, gunakan :tfilter:`linebreaksbr`
.
Pencarian bidang (yaitu Foo.objects.filter(bar__exact=whatever)
):
.. fieldlookup:: exact
Untuk mengkaitkan, gunakan :lookup:`exact`
.
Perintah django-admin
:
.. django-admin:: migrate
Untuk mengkaitkan, gunakan :djadmin:`migrate`
.
Pilihan baris-perintah django-admin
:
.. django-admin-option:: --traceback
Untuk menautkan, gunakan :option:`command_name --traceback`
(atau hilangkan command_name
untuk pilihan yang dibagi oleh semua perintah seperti --verbosity
).
Tautan ke tiket Trac (khususnya disediakan untuk catatan terbitan tambalan):
:ticket:`12345`
Dokumentasi Django menggunakan petunjuk console
penyesuaian untuk mendokumentasikan contoh-contoh baris-perintah melibatkan django-admin.py
, manage.py
, python
, dll.). Dalam dokumentasi HTML, itu membangun dua-tab UI, dengan tab pertama menunjukkan prompt perintah gaya-Unix dan tab kedua menunjukkan prompt Windows.
Sebagai contoh, anda dapat mengganti potongan ini:
use this command:
.. code-block:: console
$ python manage.py shell
dengan satu ini:
use this command:
.. console::
$ python manage.py shell
Perhatikan dua hal:
.. code-block:: console
.'$'
, '/'
sebagai jalur sistem berkas pemisah komponen, dll.)Contoh diatas akan membangun sebuah blok contoh kode dengan dua tab. Pertama akan menunjukkan:
$ python manage.py shell
(Tidak ada perubahan dari apa .. code-block:: console
akan dibangun).
Yang kedua akan menunjukkan:
...\> py manage.py shell
Kebijakan kami untuk fitur baru adalah:
Semua dokumentasi dari fitur baru harus ditulis dalam cara yang menamai jelas fitur hanya tersedia di versi pengembangan Django. Anggap dokumetnasi menggunakan terbitan terakhir, bukan versi pengembangan.
Pilihan cara kami untuk menandai fitur baru adalah dengan mendahulukan fitur dokumentasi dengan ".. versionadded:: X.Y
", diikuti oleh baris kosong wajib dan pilihan gambaran (bertakuk).
Perbaikan umum, atau perubahan lain pada API yang harus digarisbawahi harus menggunakan petunjuk ".. versionchanged:: X.Y
" (dengan bentuk sama sebagai versionadded
disebutkan diatas.
Blok versionadded
dan versionchanged
ini harus "berdikari". Dengan kata lain, sejak kami hanya menjaga keterangan ini sekitar untuk dua terbitan, itu sangat baik dapat memindahkan keterangan dan isinya tanpa harus reflow, memasukkan ulang, atau menyunting teks sekelilingnya. Sebagai contoh, daripada menaruh gambaran keseluruhan dari fitur baru atau berubah dalam blok, lakukan sesuatu seperti ini:
.. 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.
Taruh perubahan catatan penjelasan pada bawah dari bagian, bukan diatas.
Juga, hindari menunjukkan pada versi khusus dari Django diluar blok versionadded
atau versionchanged
. Bahkan didalam sebuah blok, itu sering berulang untuk melakukan seperti pembangun keterangan ini seperti "Baru di Django A.B:" and "Berubah di Django A.B", masing-masing.
Jika sebuah fungsi, atribut, dll. ditambahkan, itu juga tidak masalah menggunakan keterangan versionadded
seperti ini:
.. attribute:: Author.middle_name
.. versionadded:: A.B
An author's middle name.
Kami dapat dengan mudah memindahkan keterangan .. versionadded:: A.B
tanpa perubahan lekukan ketika waktu datang.
Optimalkan pemampatan gambar dimana memungkinkan. Untuk berkas-berkas PNG, gunakan OptiPNG dan advpng
AdvanceCOMP:
$ 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"`
Ini berbasis pada OptiPNG versi 0.7.5. Versi lama mungkin mengeluh tentang pilihan --strip all
menjadi lossy.
Untuk contoh cepat dari bagaimana semua cocok bersama-sama, pertimbangkan contoh hipotesis ini:
Pertama, dokumen ref/settings.txt
dapat mempunyai tata letak keseluruhan seperti ini:
========
Settings
========
...
.. _available-settings:
Available settings
==================
...
.. _deprecated-settings:
Deprecated settings
===================
...
Selanjutnya, dokumen topics/settings.txt
dapat mengandung sesuatu seperti ini:
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>`.
Kami menggunakan Sphinx doc
unsur penunjukan silang ketika kami ingin menautkan dokumen lain sebagai keseluruhan dan unsur ref
ketika kami ingin menautkan tempat berubah-ubah dalam sebuah dokumen.
Selanjutnya, perhatikan bagaimana pengaturan dijelaskan:
.. setting:: ADMINS
ADMINS
======
Default: ``[]`` (Empty list)
A list of all the people who get code error notifications. When
``DEBUG=False`` and a view raises an exception, Django will email these people
with the full exception information. Each member of the list should be a tuple
of (Full name, email address). Example::
[('John', 'john@example.com'), ('Mary', 'mary@example.com')]
Note that Django will email *all* of these people whenever an error happens.
See :doc:`/howto/error-reporting` for more information.
Markah ini mengikuti kepala sebagai sasaran "resmi" untuk mengatur ADMINS
. Ini berarti tiap waktu Saya berkata tentang ADMINS
, Saya dapat menunjukkannya menggunakan :setting:`ADMINS`
.
Itu adalah secara dasar bagaimana semuanya cocok bersama-sama.
Sebelum anda memperbaiki dokumen anda, adalah ide bagus untuk menjalankan pemeriksa ejaan. Anda akan butuh memasang sepasang paket terlebih dahulu:
Kemudian dari pelipat docs
, jalankan make spelling
. Kata-kata salah (jika ada) bersama dengan berkas dan nomor baris dimana mereka muncul akan disimpan ke _build/spelling/output.txt
.
Jika anda menghadapi false-positives (kesalahan keluaran yang sebenarnya benar), lakukan satu dari berikut:
docs/spelling_wordlist
(silahkan simpan daftar dalam urutan alfabet).Lihat Localizing the Django documentation jika anda suka membantu menterjemahkan dokumentasi kedalam bahasa lain.
django-admin
¶Sphinx dapat membangkitkan sebuah halaman panduan untuk perintah django-admin. Ini dikonfigurasikan dalam docs/conf.py
. Tidak seperti keluaran dokumentasi lainnya, halaman bantuan ini harus disertakan dalam gudang Django dan terbitan sebagai docs/man/django-admin.1
. Tidak perlu memperbaharui berkas ini ketika memperbaharui dokumentasi, seperti dia diperbaharui sekali sebagai bagian dari pengolahan terbitan.
Untuk membangkitkan versi terperbaharui dari halaman bantuan, jalankan make man
di pelipat docs
. Halaman bantuan baru akan ditulis dalam docs/_build/man/django-admin.1
.
Mar 30, 2019