Replaced "django" with "Django" in spelling_wordlist.
This commit is contained in:
akki
Tim Graham
parent
7c6efb3233
commit
74ed20b49a
|
|
@ -16,8 +16,8 @@ active community of helpful individuals who may be able to solve your problem.
|
|||
|
||||
.. _message-does-not-appear-on-django-users:
|
||||
|
||||
Why hasn't my message appeared on django-users?
|
||||
===============================================
|
||||
Why hasn't my message appeared on `django-users`?
|
||||
=================================================
|
||||
|
||||
|django-users| has a lot of subscribers. This is good for the community, as
|
||||
it means many people are available to contribute answers to questions.
|
||||
|
|
@ -30,8 +30,8 @@ that spammers get caught, but it also means that your first question to the
|
|||
list might take a little longer to get answered. We apologize for any
|
||||
inconvenience that this policy may cause.
|
||||
|
||||
Nobody on django-users answered my question! What should I do?
|
||||
==============================================================
|
||||
Nobody on `django-users` answered my question! What should I do?
|
||||
================================================================
|
||||
|
||||
Try making your question more specific, or provide a better example of your
|
||||
problem.
|
||||
|
|
|
|||
|
|
@ -7,10 +7,10 @@ during the development of Django applications.
|
|||
|
||||
.. _troubleshooting-django-admin:
|
||||
|
||||
Problems running django-admin
|
||||
=============================
|
||||
Problems running ``django-admin``
|
||||
=================================
|
||||
|
||||
"command not found: django-admin"
|
||||
"command not found: `django-admin`"
|
||||
------------------------------------
|
||||
|
||||
:doc:`django-admin </ref/django-admin>` should be on your system path if you
|
||||
|
|
|
|||
|
|
@ -248,10 +248,10 @@ All attributes can be set in your derived class and can be used in
|
|||
Make sure you know what you are doing if you decide to change the value of
|
||||
this option in your custom command if it creates database content that
|
||||
is locale-sensitive and such content shouldn't contain any translations
|
||||
(like it happens e.g. with django.contrib.auth permissions) as making the
|
||||
locale differ from the de facto default 'en-us' might cause unintended
|
||||
effects. Seethe `Management commands and locales`_ section above for
|
||||
further details.
|
||||
(like it happens e.g. with :mod:`django.contrib.auth` permissions) as
|
||||
making the locale differ from the de facto default 'en-us' might cause
|
||||
unintended effects. See the `Management commands and locales`_ section
|
||||
above for further details.
|
||||
|
||||
.. attribute:: BaseCommand.style
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ uWSGI model
|
|||
-----------
|
||||
|
||||
uWSGI operates on a client-server model. Your Web server (e.g., nginx, Apache)
|
||||
communicates with a django-uwsgi "worker" process to serve dynamic content.
|
||||
communicates with a `django-uwsgi` "worker" process to serve dynamic content.
|
||||
See uWSGI's `background documentation`_ for more detail.
|
||||
|
||||
.. _background documentation: https://projects.unbit.it/uwsgi/wiki/Background
|
||||
|
|
|
|||
|
|
@ -109,9 +109,9 @@ Committing guidelines
|
|||
In addition, please follow the following guidelines when committing code to
|
||||
Django's Git repository:
|
||||
|
||||
* Never change the published history of django/django branches! **Never
|
||||
force-push your changes to django/django.** If you absolutely must (for
|
||||
security reasons for example) first discuss the situation with the core team.
|
||||
* Never change the published history of ``django/django`` branches by force
|
||||
pushing. If you absolutely must (for security reasons for example), first
|
||||
discuss the situation with the team.
|
||||
|
||||
* For any medium-to-big changes, where "medium-to-big" is according to
|
||||
your judgment, please bring things up on the |django-developers|
|
||||
|
|
@ -242,7 +242,7 @@ When a mistaken commit is discovered, please follow these guidelines:
|
|||
* The release branch maintainer may back out commits to the release
|
||||
branch without permission if the commit breaks the release branch.
|
||||
|
||||
* If you mistakenly push a topic branch to django/django, just delete it.
|
||||
* If you mistakenly push a topic branch to ``django/django``, just delete it.
|
||||
For instance, if you did: ``git push upstream feature_antigravity``,
|
||||
just do a reverse push: ``git push upstream :feature_antigravity``.
|
||||
|
||||
|
|
|
|||
|
|
@ -145,8 +145,8 @@ FAQ
|
|||
First off, it's not personal. Django is entirely developed by volunteers
|
||||
(even the core team), and sometimes folks just don't have time. The best
|
||||
thing to do is to send a gentle reminder to the |django-developers| mailing
|
||||
list asking for review on the ticket, or to bring it up in the #django-dev
|
||||
IRC channel.
|
||||
list asking for review on the ticket, or to bring it up in the
|
||||
`#django-dev` IRC channel.
|
||||
|
||||
2. **I'm sure my ticket is absolutely 100% perfect, can I mark it as RFC
|
||||
myself?**
|
||||
|
|
|
|||
|
|
@ -55,8 +55,8 @@ cloned directory, so switch to it now::
|
|||
|
||||
Your GitHub repository will be called "origin" in Git.
|
||||
|
||||
You should also setup django/django as an "upstream" remote (that is, tell git
|
||||
that the reference Django repository was the source of your fork of it)::
|
||||
You should also setup ``django/django`` as an "upstream" remote (that is, tell
|
||||
git that the reference Django repository was the source of your fork of it)::
|
||||
|
||||
git remote add upstream git@github.com:django/django.git
|
||||
git fetch upstream
|
||||
|
|
@ -116,7 +116,7 @@ their clone would become corrupt when you edit commits.
|
|||
There are also "public branches". These are branches other people are supposed
|
||||
to fork, so the history of these branches should never change. Good examples
|
||||
of public branches are the ``master`` and ``stable/A.B.x`` branches in the
|
||||
django/django repository.
|
||||
``django/django`` repository.
|
||||
|
||||
When you think your work is ready to be pulled into Django, you should create
|
||||
a pull request at GitHub. A good pull request means:
|
||||
|
|
@ -193,14 +193,14 @@ a topic branch, and nobody should be basing their work on it.
|
|||
After upstream has changed
|
||||
--------------------------
|
||||
|
||||
When upstream (django/django) has changed, you should rebase your work. To
|
||||
When upstream (``django/django``) has changed, you should rebase your work. To
|
||||
do this, use::
|
||||
|
||||
git fetch upstream
|
||||
git rebase
|
||||
|
||||
The work is automatically rebased using the branch you forked on, in the
|
||||
example case using upstream/master.
|
||||
example case using ``upstream/master``.
|
||||
|
||||
The rebase command removes all your local commits temporarily, applies the
|
||||
upstream commits, and then applies your local commits again on the work.
|
||||
|
|
|
|||
|
|
@ -307,7 +307,7 @@ details on these changes.
|
|||
* ``django.db.models.field.subclassing.SubfieldBase`` will be removed.
|
||||
|
||||
* ``django.utils.checksums`` will be removed; its functionality is included
|
||||
in django-localflavor 1.1+.
|
||||
in ``django-localflavor`` 1.1+.
|
||||
|
||||
* The ``original_content_type_id`` attribute on
|
||||
``django.contrib.admin.helpers.InlineAdminForm`` will be removed.
|
||||
|
|
|
|||
|
|
@ -343,7 +343,7 @@ Now you're ready to actually put the release out there. To do this:
|
|||
announcement blog post. If this is a security release, also include
|
||||
oss-security@lists.openwall.com.
|
||||
|
||||
#. Add a link to the blog post in the topic of the #django IRC channel:
|
||||
#. Add a link to the blog post in the topic of the `#django` IRC channel:
|
||||
``/msg chanserv TOPIC #django new topic goes here``.
|
||||
|
||||
Post-release
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ The technical board holds two prerogatives:
|
|||
- Making major technical decisions when no consensus is found otherwise. This
|
||||
happens on the |django-developers| mailing-list.
|
||||
- Veto a grant of commit access or remove commit access. This happens on the
|
||||
django-core mailing-list.
|
||||
``django-core`` mailing-list.
|
||||
|
||||
In both cases, the technical board is a last resort. In these matters, it
|
||||
fulfills a similar function to the former Benevolent Dictators For Life.
|
||||
|
|
|
|||
|
|
@ -191,7 +191,7 @@ Ramiro Morales
|
|||
`Chris Beaven`_
|
||||
Chris has been submitting patches and suggesting crazy ideas for Django
|
||||
since early 2006. An advocate for community involvement and a long-term
|
||||
triager, he is still often found answering questions in the #django IRC
|
||||
triager, he is still often found answering questions in the `#django` IRC
|
||||
channel.
|
||||
|
||||
Chris lives in Napier, New Zealand (adding to the pool of Oceanic core
|
||||
|
|
@ -423,9 +423,9 @@ Daniele Procida
|
|||
`Michael Manfre`_
|
||||
Michael started running Django on Windows against a Microsoft SQL Server
|
||||
(MSSQL) database in 2008. He quickly became the maintainer of the
|
||||
django-mssql 3rd party database backend. Much of his involvement with
|
||||
Django relates to the ORM, the private 3rd party database API, and using
|
||||
Django on Windows.
|
||||
``django-mssql`` database backend. Much of his involvement with Django
|
||||
relates to the ORM, the private 3rd party database API, and using Django on
|
||||
Windows.
|
||||
|
||||
Michael lives in Cary, NC, USA.
|
||||
|
||||
|
|
@ -461,11 +461,11 @@ Daniele Procida
|
|||
specialization. Upon finding Django when it was first open sourced, he
|
||||
realized it was possible to enjoy web development.
|
||||
|
||||
He spends a lot of time helping people on the #django IRC channel, and has
|
||||
authored and released a number of `smaller django apps`_.
|
||||
He spends a lot of time helping people on the `#django` IRC channel, and
|
||||
has authored and released a number of `smaller Django apps`_.
|
||||
|
||||
.. _Curtis Maloney: http://musings.tinbrain.net/blog/
|
||||
.. _smaller django apps: https://github.com/funkybob/
|
||||
.. _smaller Django apps: https://github.com/funkybob/
|
||||
|
||||
`Markus Holtermann`_
|
||||
Markus is a senior backend developer at `LaterPay`_ in Munich. He studied
|
||||
|
|
|
|||
|
|
@ -977,7 +977,7 @@ subclass::
|
|||
class FilterWithCustomTemplate(admin.SimpleListFilter):
|
||||
template = "custom_template.html"
|
||||
|
||||
See the default template provided by django (``admin/filter.html``) for
|
||||
See the default template provided by Django (``admin/filter.html``) for
|
||||
a concrete example.
|
||||
|
||||
.. attribute:: ModelAdmin.list_max_show_all
|
||||
|
|
|
|||
|
|
@ -67,8 +67,8 @@ The ``ContentType`` model
|
|||
The name of the application the model is part of. This is taken from
|
||||
the :attr:`app_label` attribute of the model, and includes only the
|
||||
*last* part of the application's Python import path;
|
||||
"django.contrib.contenttypes", for example, becomes an
|
||||
:attr:`app_label` of "contenttypes".
|
||||
``django.contrib.contenttypes``, for example, becomes an
|
||||
:attr:`app_label` of ``contenttypes``.
|
||||
|
||||
.. attribute:: model
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ created with the following values:
|
|||
|
||||
* :attr:`~django.contrib.contenttypes.models.ContentType.app_label`
|
||||
will be set to ``'sites'`` (the last part of the Python
|
||||
path "django.contrib.sites").
|
||||
path ``django.contrib.sites``).
|
||||
|
||||
* :attr:`~django.contrib.contenttypes.models.ContentType.model`
|
||||
will be set to ``'site'``.
|
||||
|
|
|
|||
|
|
@ -325,7 +325,7 @@ Fink
|
|||
|
||||
`Kurt Schwehr`__ has been gracious enough to create GeoDjango packages for users
|
||||
of the `Fink`__ package system. `Different packages are available`__ (starting
|
||||
with "django-gis"), depending on which version of Python you want to use.
|
||||
with ``django-gis``), depending on which version of Python you want to use.
|
||||
|
||||
__ https://schwehr.blogspot.com/
|
||||
__ http://www.finkproject.org/
|
||||
|
|
|
|||
|
|
@ -49,10 +49,10 @@ The new features and changes introduced in 0.95 include:
|
|||
|
||||
* User-defined models, functions and constants now appear in the module
|
||||
namespace they were defined in. (Previously everything was magically
|
||||
transferred to the django.models.* namespace.)
|
||||
transferred to the ``django.models.*`` namespace.)
|
||||
|
||||
* Some optional applications, such as the FlatPage, Sites and Redirects
|
||||
apps, have been decoupled and moved into django.contrib. If you don't
|
||||
apps, have been decoupled and moved into ``django.contrib``. If you don't
|
||||
want to use these applications, you no longer have to install their
|
||||
database tables.
|
||||
|
||||
|
|
@ -109,9 +109,9 @@ many common questions appear with some regularity, and any particular problem
|
|||
may already have been answered.
|
||||
|
||||
Finally, for those who prefer the more immediate feedback offered by IRC,
|
||||
there's a #django channel on irc.freenode.net that is regularly populated by
|
||||
Django users and developers from around the world. Friendly people are usually
|
||||
available at any hour of the day -- to help, or just to chat.
|
||||
there's a `#django` channel on irc.freenode.net that is regularly populated
|
||||
by Django users and developers from around the world. Friendly people are
|
||||
usually available at any hour of the day -- to help, or just to chat.
|
||||
|
||||
.. _Django website: https://www.djangoproject.com/
|
||||
.. _django-users: https://groups.google.com/group/django-users
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Backwards incompatible changes
|
|||
Restricted filters in admin interface
|
||||
-------------------------------------
|
||||
|
||||
The Django administrative interface, django.contrib.admin, supports
|
||||
The Django administrative interface, ``django.contrib.admin``, supports
|
||||
filtering of displayed lists of objects by fields on the corresponding
|
||||
models, including across database-level relationships. This is
|
||||
implemented by passing lookup arguments in the querystring portion of
|
||||
|
|
@ -42,7 +42,7 @@ with repeated use of regular-expression lookups supported by the
|
|||
Django database API -- expose sensitive information such as users'
|
||||
password hashes.
|
||||
|
||||
To remedy this, django.contrib.admin will now validate that
|
||||
To remedy this, ``django.contrib.admin`` will now validate that
|
||||
querystring lookup arguments either specify only fields on the model
|
||||
being viewed, or cross relations which have been explicitly
|
||||
whitelisted by the application developer using the pre-existing
|
||||
|
|
|
|||
|
|
@ -440,13 +440,9 @@ What's next?
|
|||
|
||||
We'll take a short break, and then work on Django 1.2 will begin -- no rest for
|
||||
the weary! If you'd like to help, discussion of Django development, including
|
||||
progress toward the 1.2 release, takes place daily on the django-developers
|
||||
mailing list:
|
||||
|
||||
* https://groups.google.com/group/django-developers
|
||||
|
||||
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. Feel free to
|
||||
join the discussions!
|
||||
progress toward the 1.2 release, takes place daily on the |django-developers|
|
||||
mailing list and in the ``#django-dev`` IRC channel on ``irc.freenode.net``.
|
||||
Feel free to join the discussions!
|
||||
|
||||
Django's online documentation also includes pointers on how to contribute to
|
||||
Django:
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Backwards incompatible changes
|
|||
Restricted filters in admin interface
|
||||
-------------------------------------
|
||||
|
||||
The Django administrative interface, django.contrib.admin, supports
|
||||
The Django administrative interface, ``django.contrib.admin``, supports
|
||||
filtering of displayed lists of objects by fields on the corresponding
|
||||
models, including across database-level relationships. This is
|
||||
implemented by passing lookup arguments in the querystring portion of
|
||||
|
|
@ -42,7 +42,7 @@ with repeated use of regular-expression lookups supported by the
|
|||
Django database API -- expose sensitive information such as users'
|
||||
password hashes.
|
||||
|
||||
To remedy this, django.contrib.admin will now validate that
|
||||
To remedy this, ``django.contrib.admin`` will now validate that
|
||||
querystring lookup arguments either specify only fields on the model
|
||||
being viewed, or cross relations which have been explicitly
|
||||
whitelisted by the application developer using the pre-existing
|
||||
|
|
|
|||
|
|
@ -679,8 +679,8 @@ refuse to start. This is slightly accelerated from the usual deprecation path
|
|||
due to the severity of the consequences of running Django with no
|
||||
:setting:`SECRET_KEY`.
|
||||
|
||||
django.contrib.admin
|
||||
--------------------
|
||||
``django.contrib.admin``
|
||||
------------------------
|
||||
|
||||
The included administration app ``django.contrib.admin`` has for a long time
|
||||
shipped with a default set of static files such as JavaScript, images and
|
||||
|
|
@ -830,8 +830,8 @@ instance:
|
|||
well with Django 1.4 and you won't have to roll back to 1.3, enable the new
|
||||
password hashes.
|
||||
|
||||
django.contrib.flatpages
|
||||
------------------------
|
||||
``django.contrib.flatpages``
|
||||
----------------------------
|
||||
|
||||
Starting in 1.4, the
|
||||
:class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware` only
|
||||
|
|
|
|||
|
|
@ -94,8 +94,8 @@ functionality of the ``django.contrib.auth.decorators`` for class-based views.
|
|||
These mixins have been taken from, or are at least inspired by, the
|
||||
`django-braces`_ project.
|
||||
|
||||
There are a few differences between Django's and django-braces' implementation,
|
||||
though:
|
||||
There are a few differences between Django's and ``django-braces``\'
|
||||
implementation, though:
|
||||
|
||||
* The :attr:`~django.contrib.auth.mixins.AccessMixin.raise_exception` attribute
|
||||
can only be ``True`` or ``False``. Custom exceptions or callables are not
|
||||
|
|
@ -843,12 +843,12 @@ Changes to the default logging configuration
|
|||
--------------------------------------------
|
||||
|
||||
To make it easier to write custom logging configurations, Django's default
|
||||
logging configuration no longer defines 'django.request' and 'django.security'
|
||||
loggers. Instead, it defines a single 'django' logger, filtered at the ``INFO``
|
||||
level, with two handlers:
|
||||
logging configuration no longer defines ``django.request`` and
|
||||
``django.security`` loggers. Instead, it defines a single ``django`` logger,
|
||||
filtered at the ``INFO`` level, with two handlers:
|
||||
|
||||
* 'console': filtered at the ``INFO`` level and only active if ``DEBUG=True``.
|
||||
* 'mail_admins': filtered at the ``ERROR`` level and only active if
|
||||
* ``console``: filtered at the ``INFO`` level and only active if ``DEBUG=True``.
|
||||
* ``mail_admins``: filtered at the ``ERROR`` level and only active if
|
||||
``DEBUG=False``.
|
||||
|
||||
If you aren't overriding Django's default logging, you should see minimal
|
||||
|
|
|
|||
|
|
@ -206,7 +206,7 @@ discoverable
|
|||
Disqus
|
||||
distro
|
||||
divisibleby
|
||||
django
|
||||
Django
|
||||
djangojs
|
||||
djangonaut
|
||||
djangoproject
|
||||
|
|
|
|||
Loading…
Reference in New Issue