mirror of
https://github.com/django/django.git
synced 2025-10-17 13:58:24 +00:00
Fixed #30573 -- Rephrased documentation to avoid words that minimise the involved difficulty.
This patch does not remove all occurrences of the words in question. Rather, I went through all of the occurrences of the words listed below, and judged if they a) suggested the reader had some kind of knowledge/experience, and b) if they added anything of value (including tone of voice, etc). I left most of the words alone. I looked at the following words: - simply/simple - easy/easier/easiest - obvious - just - merely - straightforward - ridiculous Thanks to Carlton Gibson for guidance on how to approach this issue, and to Tim Bell for providing the idea. But the enormous lion's share of thanks go to Adam Johnson for his patient and helpful review.
This commit is contained in:
parent
addabc492b
commit
4a954cfd11
149 changed files with 1101 additions and 1157 deletions
|
@ -78,9 +78,9 @@ modules to the page via the model's class Admin :ref:`js parameter
|
|||
pointing to JavaScript modules that will be included within the admin form via
|
||||
a ``<script>`` tag.
|
||||
|
||||
If you want more flexibility than simply tweaking the auto-generated forms,
|
||||
feel free to write custom views for the admin. The admin is powered by Django
|
||||
itself, and you can write custom views that hook into the authentication
|
||||
If you want more flexibility than is feasible by tweaking the auto-generated
|
||||
forms, feel free to write custom views for the admin. The admin is powered by
|
||||
Django itself, and you can write custom views that hook into the authentication
|
||||
system, check permissions and do whatever else they need to do.
|
||||
|
||||
If you want to customize the look-and-feel of the admin interface, read the
|
||||
|
|
|
@ -84,7 +84,7 @@ of a larger problem. While we can spend time writing, testing and applying
|
|||
lots of little patches, sometimes the right solution is to rebuild. If a
|
||||
rebuild or refactor of a particular component has been proposed or is
|
||||
underway, you may find that bugs affecting that component will not get as much
|
||||
attention. Again, this is just a matter of prioritizing scarce resources. By
|
||||
attention. Again, this is a matter of prioritizing scarce resources. By
|
||||
concentrating on the rebuild, we can close all the little bugs at once, and
|
||||
hopefully prevent other little bugs from appearing in the future.
|
||||
|
||||
|
@ -93,7 +93,7 @@ bug regularly, it doesn't necessarily follow that every single Django user
|
|||
will hit the same bug. Different users use Django in different ways, stressing
|
||||
different parts of the code under different conditions. When we evaluate the
|
||||
relative priorities, we are generally trying to consider the needs of the
|
||||
entire community, not just the severity for one particular user. This doesn't
|
||||
mean that we think your problem is unimportant -- just that in the limited
|
||||
time we have available, we will always err on the side of making 10 people
|
||||
happy rather than making 1 person happy.
|
||||
entire community, instead of prioritizing the impact on one particular user.
|
||||
This doesn't mean that we think your problem is unimportant -- just that in the
|
||||
limited time we have available, we will always err on the side of making 10
|
||||
people happy rather than making a single person happy.
|
||||
|
|
|
@ -8,7 +8,7 @@ How can I see the raw SQL queries Django is running?
|
|||
====================================================
|
||||
|
||||
Make sure your Django :setting:`DEBUG` setting is set to ``True``.
|
||||
Then, just do this::
|
||||
Then do this::
|
||||
|
||||
>>> from django.db import connection
|
||||
>>> connection.queries
|
||||
|
@ -32,7 +32,7 @@ same interface on each member of the ``connections`` dictionary::
|
|||
>>> connections['my_db_alias'].queries
|
||||
|
||||
If you need to clear the query list manually at any point in your functions,
|
||||
just call ``reset_queries()``, like this::
|
||||
call ``reset_queries()``, like this::
|
||||
|
||||
from django.db import reset_queries
|
||||
reset_queries()
|
||||
|
@ -61,8 +61,8 @@ But this isn't an issue in practice, because there's nothing stopping you from
|
|||
adding other constraints (using the ``unique_together`` model option or
|
||||
creating the constraint directly in your database), and enforcing the
|
||||
uniqueness at that level. Single-column primary keys are needed for things such
|
||||
as the admin interface to work; e.g., you need a simple way of being able to
|
||||
specify an object to edit or delete.
|
||||
as the admin interface to work; e.g., you need a single value to specify
|
||||
an object to edit or delete.
|
||||
|
||||
Does Django support NoSQL databases?
|
||||
====================================
|
||||
|
|
|
@ -61,9 +61,9 @@ Using a :class:`~django.db.models.FileField` or an
|
|||
How do I make a variable available to all my templates?
|
||||
=======================================================
|
||||
|
||||
Sometimes your templates just all need the same thing. A common example would
|
||||
be dynamically-generated menus. At first glance, it seems logical to simply
|
||||
add a common dictionary to the template context.
|
||||
Sometimes your templates all need the same thing. A common example would be
|
||||
dynamically generated menus. At first glance, it seems logical to add a common
|
||||
dictionary to the template context.
|
||||
|
||||
The correct solution is to use a ``RequestContext``. Details on how to do this
|
||||
are here: :ref:`subclassing-context-requestcontext`.
|
||||
The best way to do this in Django is to use a ``RequestContext``. Details on
|
||||
how to do this are here: :ref:`subclassing-context-requestcontext`.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue