Interested in giving back to the community a little? Maybe you've found a bug\nin Django that you'd like to see fixed, or maybe there's a small feature you\nwant added (but remember that proposals for new features should follow the\nprocess for suggesting new features).
\nMembantu kembali ke Django adalah cara terbaik untuk melihat alamat perhatian anda. ini mungkin terlihat menakutkan awalnya, tetapi itu adalah jalur bepergian-dengan-baik dengan dokumentasi, peralatan, dan komunitas untuk mendukung anda. Kami akan berjalan melalui proses keseluruhan, sehingga anda dapat belajar berdasarkan contoh.
\nFor this tutorial, we expect that you have at least a basic understanding of\nhow Django works. This means you should be comfortable going through the\nexisting tutorials on writing your first Django app.\nIn addition, you should have a good understanding of Python itself. But if you\ndon't, Dive Into Python is a fantastic (and free) online book for beginning\nPython programmers.
\nBagi anda yang tidak akrab dengan vesi kendali sistem dan Trac akan menemukan bahwa tutorial ini dan tautannya memasukkan informasi cukup untuk memulai. Bagaimanapun, anda akan mungkin membaca beberapa lebih alat berbeda jika anda berencana sering untuk membantu Django.
\nUntuk sebagian besar, tutorial ini mencoba menjelaskan sebanyak mungkin, sehingga itu dapat digunakan pada pendengar luas.
\n\nWe'll be walking you through contributing to Django for the first time. By the\nend of this tutorial, you should have a basic understanding of both the tools\nand the processes involved. Specifically, we'll be covering the following:
\nMemasang Git
Mengunduh salinan versi pengembangan Django.
Menjalankan rangkaian percobaan Django.
Writing a test for your changes.
Writing the code for your changes.
Testing your changes.
Mengajukan pull request
Dimana mencari untuk informasi lebih.
Sekali anda selesai dengan tutorial, anda dapat mencari sisa dari Django's documentation on contributing. Itu mengandung banyak informasi hebat dan harus dibaca untuk siapapun yang suka menjadi penyumbang rutin ke Django. Jika anda mendapatkan pertanyaan, itu mungkin mendapatkan jawaban.
\n\nSebagai penyumbang, anda dapat membantu kami menjaga komunitas Django terbuka dan inklusif. Silahkan baca dan ikuti ``Code of Conduct <https://www.djangoproject.com/conduct/>`_ kami.
\nFor this tutorial, you'll need Git installed to download the current\ndevelopment version of Django and to generate a branch for the changes you\nmake.
\nUntuk memeriksa apakah atau tidak anda telah terpasang Git, masukkan git ke baris perintah. Jika anda mendapatkan pesan dimana perintah ini tidak ditemukan, anda akan perlu mengunduh dan memasangnya, lihat Halaman unduh Git.
Jika anda tidak akrab dengan Git, anda dapat selalu menemukan lebih tentang perintahnya (pertama dia dipasang) dengan mengetik git help kedalam baris perintah.
Langkah pertama untuk membantu Django adalah mendapatkan sebuah salinan dari kode sumber. Pertama, fork Django on GitHub. Kemudian, dari baris perintah, gunakan perintah cd untuk melayari ke direktori dimana anda akan ingin salinan lokal anda dari Django menjadi langsung.
Unduh gudang kode sumber Django menggunakan perintah berikut:
\nLinux / macOS
$ git clone https://github.com/YourGitHubName/django.git\nWindows
...\\> git clone https://github.com/YourGitHubName/django.git\nSekarang dimana anda memiliki salinan lokal Django, anda dapat memasang itu seperti anda memasang paket apapun menggunakan pip. Cara paling nyaman melakukannya adalah dengan menggunakan virtual environment, yaitu fitur dibangun kedalam Python yang mengizinkan anda menjaga direktori terpisah dari paket-paket terpasang untuk setiap dari proyek-proyek anda sehingga mereka tidak mengganggu satu sama lain.
Itu adalah ide bagus menjaga semua lingkungan maya anda dalam satu tempat, sebagai contoh dalam .virtualenvs/ di direktori rumah anda.
Buat lingkungan maya baru dengan menjalankan:
\nLinux / macOS
$ python3 -m venv ~/.virtualenvs/djangodev\nWindows
...\\> py -m venv %HOMEPATH%\\.virtualenvs\\djangodev\nJalur dimana lingkungan baru akan disimpan ke komputer anda.
\nlangkah akhir dalam mengatur lingkungan maya adalah mengaktifkan itu:
\n$ source ~/.virtualenvs/djangodev/bin/activate\nJika perintah source tidak tersedua, anda dapat mencoba menggunakan titik:
$ . ~/.virtualenvs/djangodev/bin/activate\nAnda harus mengaktifkan lingkungan virtual setiap kali Anda membuka jendela terminal baru.
\n\nNama dari lingkungan maya diaktivasi sekarang ditampilkan pada baris perintah untuk membantu anda melacak dimana yang anda sedang gunakan. Apapun anda pasang melalui pip selagi nama ini ditampilkan akan dipasang dalam lingkungan maya, terpencil dari lingkungan dan paket-paket sistem-lebar.
Lanjutkan dan pasang klon salinan sebelumnya dari Django:
\nLinux / macOS
$ python -m pip install -e /path/to/your/local/clone/django/\nWindows
...\\> py -m pip install -e \\path\\to\\your\\local\\clone\\django\\\nThe installed version of Django is now pointing at your local copy by\ninstalling in editable mode. You will immediately see any changes you make to\nit, which is of great help when testing your first contribution.
\nKetika membantu Django adalah sangat penting bahwa perubahan kode anda tidak memperkenalkan kesalahan kedalam kawasan Django lain. Satu cara untuk memeriksa bahwa Django masih bekerja setelah anda membuat perubahan anda adalah dengan menjalankan deretan percobaan Django. Jika semua percobaan masih terlewati, lalu anda cukup yakin bahwa perubahan anda bekerja dan tidak merusak bagian lain dari Django. Jika anda tidak pernah menjalankan deretan percobaan Django sebelumnya, adalah ide bagus untuk menjalankannya sekali sebelumnya untuk lebih akrab dengan keluarannya.
\nSebelum menjalankan deretan pengujian, masukkan direktori tests/ Django menggunakan perintah cd tests dan pasang ketergantungan pengujian dengan menjalankan:
Linux / macOS
$ python -m pip install -r requirements/py3.txt\nWindows
...\\> py -m pip install -r requirements\\py3.txt\nJika anda mengalami sebuah kesalahan selama pemasangan, sisem anda mungkin kehilangan ketergantungan untuk satu atau lebih paket Python. Obrolkan dokumentasi paket yang gagal atau cari di jaringan dengan pesan kesalahan yang anda alami.
\nNow we are ready to run the test suite:
\nLinux / macOS
$ ./runtests.py\nWindows
...\\> runtests.py \nSekarang duduk dan rileks. Keseluruhan rangkaian pengujian Django mempunyai ribuan pengujian, dan itu membutuhkan paling sedikit beberapa menit untuk dijalankan, tergantung pada kecepatan komputer anda.
\nWhile Django's test suite is running, you'll see a stream of characters\nrepresenting the status of each test as it completes. E indicates that an\nerror was raised during a test, and F indicates that a test's assertions\nfailed. Both of these are considered to be test failures. Meanwhile, x and\ns indicate expected failures and skipped tests, respectively. Dots indicate\npassing tests.
Lewati percobaan biasanya karena kehilangan pustaka luar yang diwajibkan untuk menjalankan percobaan; lihat Menjalankan semua percobaan untuk daftar dari ketergantungan dan pastikan memasang tiap untuk percobaan terhubung ke perubahan anda sedang buat (kami tidak akan butuh untuk tutorial ini). Beberapa percobaan sangat khusus pada backend basisdata tertentu dan akan dilewati jika tidak dicobakan dengan backend itu. SQLite adalah backend basisdata untuk pengaturan awal. Untuk menjalankan percobaan menggunakan backend berbeda, lihat Gunakan modul pengaturan lain.
\nKetika percobaan lengkap, anda akan disapa dengan pesan menginformasikan bahwa deretan percobaan lulus atau gagal. Sejak anda tidak mempunyai perubahan apapun ke kode Django, deretan percobaan seluruhnya harus lulus. Jika anda mendapatkan kegagalan atau kesalahan pastikan anda telah mengikuti langkah sebelumnya dengan benar. Lihat Menjalankan satuan percobaan untuk informasi lebih.
\nCatat bahwacabang "main" Django mungkin tidak selalu stabil. Ketika mengembangkan terhadap "main", anda dapat memeriksa Django's continuous integration builds untuk menentukan jika kegagalan spesifik pada mesin anda atau jika mereka juga hadir dalam bangunan resmi Django. Jika anda mengklik untuk melihat bangunan tertentu, anda dapat melihat "Configuration Matrix" yang menunjukkan kegagalan dipecah oleh versi Python dan backend basisdata.
\n\nFor this tutorial, we'll work on a "fake accepted ticket" as a case study. Here\nare the imaginary details:
\n\nKami akan menerapkan fitur ini dan percobaan terkait.
\nSebelum membuat perubahan apapun, buat sebuah cabang baru untuk tiket:
\nLinux / macOS
$ git checkout -b ticket_99999\nWindows
...\\> git checkout -b ticket_99999\nAnda dapat memilih nama apapun yang anda ingin untuk cabang, "ticket_99999" adalah sebuah contoh. Semua perubahan dibuat dalam cabang ini akan khusus pada tiket dan tidak akan mempengaruhi salinan uta,a dari kode yang kami kloning diawal.
\nIn most cases, for a contribution to be accepted into Django it has to include\ntests. For bug fix contributions, this means writing a regression test to\nensure that the bug is never reintroduced into Django later on. A regression\ntest should be written in such a way that it will fail while the bug still\nexists and pass once the bug has been fixed. For contributions containing new\nfeatures, you'll need to include tests which ensure that the new features are\nworking correctly. They too should fail when the new feature is not present,\nand then pass once it has been implemented.
\nA good way to do this is to write your new tests first, before making any\nchanges to the code. This style of development is called\ntest-driven development and can be applied to both entire projects and\nsingle changes. After writing your tests, you then run them to make sure that\nthey do indeed fail (since you haven't fixed that bug or added that feature\nyet). If your new tests don't fail, you'll need to fix them so that they do.\nAfter all, a regression test that passes regardless of whether a bug is present\nis not very helpful at preventing that bug from reoccurring down the road.
\nSekarang untuk contoh meneruskan kami.
\nUntuk menyelesaikan tiket ini, kami akan menambahkan sebuah fungsi make_toast() ke dalam modul django.shortcuts. Pertama kami akan menulis sebuah pengujian yang mencoba menggunakan fungsi dan memeriksa bahwa keluarannya terlihat benar.
Kemudikan ke folder tests/shortcuts/ Django dan buat sebuah berkas baru test_make_toast.py. Tambah kode berikut:
from django.shortcuts import make_toast\nfrom django.test import SimpleTestCase\n\n\nclass MakeToastTests(SimpleTestCase):\n def test_make_toast(self):\n self.assertEqual(make_toast(), "toast")\nPercobaan ini memeriksa bahwa make_toast() mengembalikan 'toast'.
Sejak kami belum membuat perubahan apapun pada django.shortcuts, percobaan kami harus gagal. Mari kita jalankan semua percobaan dalam folder shortcuts untuk memastikan bahwa itu memang terjadi. cd ke direktori tests/ Django dan jalankan:
Linux / macOS
$ ./runtests.py shortcuts\nWindows
...\\> runtests.py shortcuts\nIf the tests ran correctly, you should see one failure corresponding to the\ntest method we added, with this error:
\nImportError: cannot import name 'make_toast' from 'django.shortcuts'\nJika semua percobaan dilewati, kemudian anda akan ingin memastikan bahwa anda menambahkan percobaan terbaru ditampilkan diatas pada folder dan nama berkas sesuai.
\nSelanjutnya kami akan menambahkan fungsi make_toast().
Kemudikan ke folder django/ dan buka berkas shortcuts.py. Pada bagian bawah, tambah:
def make_toast():\n return "toast"\nSekarang kami butuh memastikan bahwa percobaan kami tulis sebelumnya lolos, jadi kami dapat melihat apakah kode kami tambahkan bekerja dengan benar. Kembali, kemudikan ke direktori tests/ Django dan jalankan:
Linux / macOS
$ ./runtests.py shortcuts\nWindows
...\\> runtests.py shortcuts\nSemuanya harus dilewatkan. Jika itu tidak, pastikan anda dengan benar menambahkan fungsi ke berkas benar.
\nOnce you've verified that your changes and test are working correctly, it's\na good idea to run the entire Django test suite to verify that your change\nhasn't introduced any bugs into other areas of Django. While successfully\npassing the entire test suite doesn't guarantee your code is bug free, it does\nhelp identify many bugs and regressions that might otherwise go unnoticed.
\nUntuk menjalankan seluruh rangkaian percobaan Django, cd kedalam direktori test/ Django dan jalankan:
Linux / macOS
$ ./runtests.py\nWindows
...\\> runtests.py \nThis is a new feature, so it should be documented. Open the file\ndocs/topics/http/shortcuts.txt and add the following at the end of the\nfile:
``make_toast()``\n================\n\n.. function:: make_toast()\n\n.. versionadded:: 2.2\n\nReturns ``'toast'``.\nSince this new feature will be in an upcoming release it is also added to the\nrelease notes for the next version of Django. Open the release notes for the\nlatest version in docs/releases/, which at time of writing is 2.2.txt.\nAdd a note under the "Minor Features" header:
:mod:`django.shortcuts`\n~~~~~~~~~~~~~~~~~~~~~~~\n\n* The new :func:`django.shortcuts.make_toast` function returns ``'toast'``.\nUntuk informasi lebih dalam menulis dokumen, termasuk penjelasan dari apa semua tentang bit versionadded, lihat Menulis dokumentasi. Halaman itu juga menyertakan sebuah penjelasan dari bagaimana membangun salinan dari dokumentasi secara lokal, sehingga anda dapat meninjau HTML yang akan dibangkitkan.
Now it's time to review the changes made in the branch. To stage all the\nchanges ready for commit, run:
\nLinux / macOS
$ git add --all\nWindows
...\\> git add --all\nKemudian tampilkan perbedaan diantara salinan saat ini dari Django (dengan perubahan anda) dan perbaikan yang anda awali periksa di paling awal dengan petunjuk penggunaan:
\nLinux / macOS
$ git diff --cached\nWindows
...\\> git diff --cached\nGunakan kunci panah untuk pindah ke atas dan ke bawah.
\ndiff --git a/django/shortcuts.py b/django/shortcuts.py\nindex 7ab1df0e9d..8dde9e28d9 100644\n--- a/django/shortcuts.py\n+++ b/django/shortcuts.py\n@@ -156,3 +156,7 @@ def resolve_url(to, *args, **kwargs):\n\n # Finally, fall back and assume it's a URL\n return to\n+\n+\n+def make_toast():\n+ return 'toast'\ndiff --git a/docs/releases/2.2.txt b/docs/releases/2.2.txt\nindex 7d85d30c4a..81518187b3 100644\n--- a/docs/releases/2.2.txt\n+++ b/docs/releases/2.2.txt\n@@ -40,6 +40,11 @@ database constraints. Constraints are added to models using the\n Minor features\n --------------\n\n+:mod:`django.shortcuts`\n+~~~~~~~~~~~~~~~~~~~~~~~\n+\n+* The new :func:`django.shortcuts.make_toast` function returns ``'toast'``.\n+\n :mod:`django.contrib.admin`\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\ndiff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt\nindex 7b3a3a2c00..711bf6bb6d 100644\n--- a/docs/topics/http/shortcuts.txt\n+++ b/docs/topics/http/shortcuts.txt\n@@ -271,3 +271,12 @@ This example is equivalent to::\n my_objects = list(MyModel.objects.filter(published=True))\n if not my_objects:\n raise Http404("No MyModel matches the given query.")\n+\n+``make_toast()``\n+================\n+\n+.. function:: make_toast()\n+\n+.. versionadded:: 2.2\n+\n+Returns ``'toast'``.\ndiff --git a/tests/shortcuts/test_make_toast.py b/tests/shortcuts/test_make_toast.py\nnew file mode 100644\nindex 0000000000..6f4c627b6e\n--- /dev/null\n+++ b/tests/shortcuts/test_make_toast.py\n@@ -0,0 +1,7 @@\n+from django.shortcuts import make_toast\n+from django.test import SimpleTestCase\n+\n+\n+class MakeToastTests(SimpleTestCase):\n+ def test_make_toast(self):\n+ self.assertEqual(make_toast(), 'toast')\nWhen you're done previewing the changes, hit the q key to return to the\ncommand line. If the diff looked okay, it's time to commit the changes.
Memperbaiki perubahan:
\nLinux / macOS
$ git commit\nWindows
...\\> git commit\nIni membuka penyunting teks untuk mengetik pesanperbaikan. Ikuti commit message guidelines dan tulis sebuah pesan seperti:
\nFixed #99999 -- Added a shortcut function to make toast.\nAfter committing the changes, send it to your fork on GitHub (substitute\n"ticket_99999" with the name of your branch if it's different):
\nLinux / macOS
$ git push origin ticket_99999\nWindows
...\\> git push origin ticket_99999\nAnda dapat membuat sebuah pull request dengan mengunjungi Django GitHub page. Anda akan melihat cabang anda dibawah "Your recently pushed branches". Klik "Compare & pull request" dekatnya.
\nPlease don't do it for this tutorial, but on the next page that displays a\npreview of the changes, you would click "Create pull request".
\nSelamat, anda telah belajar bagaimana membuat sebuah pull request pada Django! Rincian dari teknik-teknik lebih lanjut anda mungkin butuh adalah di Bekerja dengan Git dan GitHub.
\nSekarang anda dapat menaruh keahlian-keahlian tersebut untuk penggunaan bagus dengan membantu memperbaiki kode dasar Django.
\nBefore you get too into contributing to Django, there's a little more\ninformation on contributing that you should probably take a look at:
\nYou should make sure to read Django's documentation on\nclaiming tickets and submitting pull requests.\nIt covers Trac etiquette, how to claim tickets for yourself, expected\ncoding style (both for code and docs), and many other important details.
Pertama kali penyumbang harus juga membaca documentation for first time contributors. Django. Itu mempunyai banyak saran baik untuk siapa dari kita yang baru untuk dibantu dengan Django.
Setelah itu, jika anda masih terburu-buru untuk informasi lebih tentang bantuan, anda dapat selalu menjelajah melalui sisa Django's documentation on contributing. Itu mengandung ton dari informasi berguna dan harus menjadi sumber pertama anda untuk menjawab pertanyaan papun anda mungkin punya.
Once you've looked through some of that information, you'll be ready to go out\nand find a ticket of your own to contribute to. Pay special attention to\ntickets with the "easy pickings" criterion. These tickets are often much\nsimpler in nature and are great for first time contributors. Once you're\nfamiliar with contributing to Django, you can start working on more difficult\nand complicated tickets.
\nIf you just want to get started already (and nobody would blame you!), try\ntaking a look at the list of easy tickets without a branch and the\neasy tickets that have branches which need improvement. If you're familiar\nwith writing tests, you can also look at the list of\neasy tickets that need tests. Remember to follow the guidelines about\nclaiming tickets that were mentioned in the link to Django's documentation on\nclaiming tickets and submitting branches.
\nAfter a ticket has a branch, it needs to be reviewed by a second set of eyes.\nAfter submitting a pull request, update the ticket metadata by setting the\nflags on the ticket to say "has patch", "doesn't need tests", etc, so others\ncan find it for review. Contributing doesn't necessarily always mean writing\ncode from scratch. Reviewing open pull requests is also a very helpful\ncontribution. See Mendahulukan tiket for details.
\n