diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt index 04ab9bae1b..2325e32ac2 100644 --- a/docs/howto/custom-management-commands.txt +++ b/docs/howto/custom-management-commands.txt @@ -193,7 +193,7 @@ Attributes ---------- All attributes can be set in your derived class and can be used in -:class:`BaseCommand`'s :ref:`subclasses`. +:class:`BaseCommand`’s :ref:`subclasses`. .. attribute:: BaseCommand.args @@ -267,7 +267,7 @@ the :meth:`~BaseCommand.handle` method must be implemented. .. admonition:: Implementing a constructor in a subclass If you implement ``__init__`` in your subclass of :class:`BaseCommand`, - you must call :class:`BaseCommand`'s ``__init__``. + you must call :class:`BaseCommand`’s ``__init__``. .. code-block:: python diff --git a/docs/howto/error-reporting.txt b/docs/howto/error-reporting.txt index a9ce798dca..54de19cef7 100644 --- a/docs/howto/error-reporting.txt +++ b/docs/howto/error-reporting.txt @@ -122,8 +122,8 @@ Filtering sensitive information Error reports are really helpful for debugging errors, so it is generally useful to record as much relevant information about those errors as possible. For example, by default Django records the `full traceback`_ for the -exception raised, each `traceback frame`_'s local variables, and the -:class:`~django.http.HttpRequest`'s :ref:`attributes`. +exception raised, each `traceback frame`_’s local variables, and the +:class:`~django.http.HttpRequest`’s :ref:`attributes`. However, sometimes certain types of information may be too sensitive and thus may not be appropriate to be kept track of, for example a user's password or @@ -166,7 +166,7 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``): .. admonition:: When using mutiple decorators If the variable you want to hide is also a function argument (e.g. - '``user``' in the following example), and if the decorated function has + '``user``’ in the following example), and if the decorated function has mutiple decorators, then make sure to place ``@sensitive_variables`` at the top of the decorator chain. This way it will also hide the function argument as it gets passed through the other decorators:: @@ -234,7 +234,7 @@ own filter class and tell Django to use it via the DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter' You may also control in a more granular way which filter to use within any -given view by setting the ``HttpRequest``'s ``exception_reporter_filter`` +given view by setting the ``HttpRequest``’s ``exception_reporter_filter`` attribute:: def my_view(request): diff --git a/docs/intro/tutorial05.txt b/docs/intro/tutorial05.txt index 133b0eea82..f017134517 100644 --- a/docs/intro/tutorial05.txt +++ b/docs/intro/tutorial05.txt @@ -132,7 +132,7 @@ We identify a bug Fortunately, there's a little bug in the ``polls`` application for us to fix right away: the ``Poll.was_published_recently()`` method returns ``True`` if the ``Poll`` was published within the last day (which is correct) but also if -the ``Poll``'s ``pub_date`` field is in the future (which certainly isn't). +the ``Poll``’s ``pub_date`` field is in the future (which certainly isn't). You can see this in the Admin; create a poll whose date lies in the future; you'll see that the ``Poll`` change list claims it was published recently. diff --git a/docs/ref/class-based-views/mixins-date-based.txt b/docs/ref/class-based-views/mixins-date-based.txt index 7003adfa06..f62a3b272d 100644 --- a/docs/ref/class-based-views/mixins-date-based.txt +++ b/docs/ref/class-based-views/mixins-date-based.txt @@ -230,7 +230,7 @@ DateMixin .. attribute:: date_field The name of the ``DateField`` or ``DateTimeField`` in the - ``QuerySet``'s model that the date-based archive should use to + ``QuerySet``’s model that the date-based archive should use to determine the list of objects to display on the page. When :doc:`time zone support ` is enabled and diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt index f2d3824140..b6e7a58807 100644 --- a/docs/ref/contrib/admin/index.txt +++ b/docs/ref/contrib/admin/index.txt @@ -1590,7 +1590,7 @@ in your own admin JavaScript without including a second copy, you can use the The embedded jQuery has been upgraded from 1.4.2 to 1.9.1. The :class:`ModelAdmin` class requires jQuery by default, so there is no need -to add jQuery to your ``ModelAdmin``'s list of media resources unless you have +to add jQuery to your ``ModelAdmin``’s list of media resources unless you have a specifc need. For example, if you require the jQuery library to be in the global namespace (for example when using third-party jQuery plugins) or if you need a newer version of jQuery, you will have to include your own copy. diff --git a/docs/ref/contrib/auth.txt b/docs/ref/contrib/auth.txt index 545263445a..2fd5b0794f 100644 --- a/docs/ref/contrib/auth.txt +++ b/docs/ref/contrib/auth.txt @@ -259,7 +259,7 @@ Manager methods be called. The ``extra_fields`` keyword arguments are passed through to the - :class:`~django.contrib.auth.models.User`'s ``__init__`` method to + :class:`~django.contrib.auth.models.User`’s ``__init__`` method to allow setting arbitrary fields on a :ref:`custom User model `. diff --git a/docs/ref/contrib/comments/moderation.txt b/docs/ref/contrib/comments/moderation.txt index 796e257200..5f0badfadb 100644 --- a/docs/ref/contrib/comments/moderation.txt +++ b/docs/ref/contrib/comments/moderation.txt @@ -54,7 +54,7 @@ following model, which would represent entries in a Weblog:: Now, suppose that we want the following steps to be applied whenever a new comment is posted on an ``Entry``: -1. If the ``Entry``'s ``enable_comments`` field is ``False``, the +1. If the ``Entry``’s ``enable_comments`` field is ``False``, the comment will simply be disallowed (i.e., immediately deleted). 2. If the ``enable_comments`` field is ``True``, the comment will be diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index dc45bbff21..b85f5454b1 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -572,7 +572,7 @@ several lines in language files. .. django-admin-option:: --no-location -Use the ``--no-location`` option to not write '``#: filename:line``' +Use the ``--no-location`` option to not write '``#: filename:line``’ comment lines in language files. Note that using this option makes it harder for technically skilled translators to understand each message's context. diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt index fd78638898..6b9ed4aef2 100644 --- a/docs/ref/models/options.txt +++ b/docs/ref/models/options.txt @@ -97,7 +97,7 @@ Django quotes column and table names behind the scenes. The name of an orderable field in the model, typically a :class:`DateField`, :class:`DateTimeField`, or :class:`IntegerField`. This specifies the default - field to use in your model :class:`Manager`'s + field to use in your model :class:`Manager`’s :meth:`~django.db.models.query.QuerySet.latest` and :meth:`~django.db.models.query.QuerySet.earliest` methods. diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index d327013cac..b4c85967c2 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -1752,7 +1752,7 @@ Default:: A tuple of template loader classes, specified as strings. Each ``Loader`` class knows how to import templates from a particular source. Optionally, a tuple can be -used instead of a string. The first item in the tuple should be the ``Loader``'s +used instead of a string. The first item in the tuple should be the ``Loader``’s module, subsequent items are passed to the ``Loader`` during initialization. See :doc:`/ref/templates/api`. @@ -2528,7 +2528,7 @@ files` for more details about usage. your static files from their permanent locations into one directory for ease of deployment; it is **not** a place to store your static files permanently. You should do that in directories that will be found by - :doc:`staticfiles`'s + :doc:`staticfiles`’s :setting:`finders`, which by default, are ``'static/'`` app sub-directories and any directories you include in :setting:`STATICFILES_DIRS`). diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt index 6a9efc0811..669016ae00 100644 --- a/docs/ref/templates/api.txt +++ b/docs/ref/templates/api.txt @@ -683,7 +683,7 @@ class. Here are the template loaders that come with Django: with your own ``admin/base_site.html`` in ``myproject.polls``. You must then make sure that your ``myproject.polls`` comes *before* ``django.contrib.admin`` in :setting:`INSTALLED_APPS`, otherwise - ``django.contrib.admin``'s will be loaded first and yours will be ignored. + ``django.contrib.admin``’s will be loaded first and yours will be ignored. Note that the loader performs an optimization when it is first imported: it caches a list of which :setting:`INSTALLED_APPS` packages have a diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt index 060f099c52..6bf4c0db60 100644 --- a/docs/releases/1.3.txt +++ b/docs/releases/1.3.txt @@ -365,7 +365,7 @@ In earlier Django versions, when a model instance containing a file from the backend storage. This opened the door to several data-loss scenarios, including rolled-back transactions and fields on different models referencing the same file. In Django 1.3, when a model is deleted the -:class:`~django.db.models.FileField`'s ``delete()`` method won't be called. If +:class:`~django.db.models.FileField`’s ``delete()`` method won't be called. If you need cleanup of orphaned files, you'll need to handle it yourself (for instance, with a custom management command that can be run manually or scheduled to run periodically via e.g. cron). @@ -654,7 +654,7 @@ Password reset view now accepts ``from_email`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The :func:`django.contrib.auth.views.password_reset` view now accepts a -``from_email`` parameter, which is passed to the ``password_reset_form``'s +``from_email`` parameter, which is passed to the ``password_reset_form``’s ``save()`` method as a keyword argument. If you are using this view with a custom password reset form, then you will need to ensure your form's ``save()`` method accepts this keyword argument. diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt index 798228b7d7..8ddf340eda 100644 --- a/docs/releases/1.6.txt +++ b/docs/releases/1.6.txt @@ -201,7 +201,7 @@ Minor features * The :attr:`~django.views.generic.edit.DeletionMixin.success_url` of :class:`~django.views.generic.edit.DeletionMixin` is now interpolated with - its ``object``\'s ``__dict__``. + its ``object``’s ``__dict__``. * :class:`~django.http.HttpResponseRedirect` and :class:`~django.http.HttpResponsePermanentRedirect` now provide an ``url`` @@ -344,7 +344,7 @@ Minor features * :class:`~django.forms.ModelForm` fields can now override error messages defined in model fields by using the - :attr:`~django.forms.Field.error_messages` argument of a ``Field``'s + :attr:`~django.forms.Field.error_messages` argument of a ``Field``’s constructor. To take advantage of this new feature with your custom fields, :ref:`see the updated recommendation ` for raising a ``ValidationError``. diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt index 96b5e9f498..2132b4ffa3 100644 --- a/docs/topics/class-based-views/mixins.txt +++ b/docs/topics/class-based-views/mixins.txt @@ -288,7 +288,7 @@ object. In order to do this, we need to have two different querysets: ``Book`` queryset for use by :class:`~django.views.generic.list.ListView` Since we have access to the ``Publisher`` whose books we want to list, we - simply override ``get_queryset()`` and use the ``Publisher``'s + simply override ``get_queryset()`` and use the ``Publisher``’s :ref:`reverse foreign key manager`. ``Publisher`` queryset for use in :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()` diff --git a/docs/topics/db/managers.txt b/docs/topics/db/managers.txt index b940b09d33..93602d7666 100644 --- a/docs/topics/db/managers.txt +++ b/docs/topics/db/managers.txt @@ -100,7 +100,7 @@ access ``self.model`` to get the model class to which they're attached. Modifying initial Manager QuerySets ----------------------------------- -A ``Manager``'s base ``QuerySet`` returns all objects in the system. For +A ``Manager``’s base ``QuerySet`` returns all objects in the system. For example, using this model:: from django.db import models @@ -111,7 +111,7 @@ example, using this model:: ...the statement ``Book.objects.all()`` will return all books in the database. -You can override a ``Manager``\'s base ``QuerySet`` by overriding the +You can override a ``Manager``’s base ``QuerySet`` by overriding the ``Manager.get_queryset()`` method. ``get_queryset()`` should return a ``QuerySet`` with the properties you require. diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt index f6ae90062b..b4cc8e2955 100644 --- a/docs/topics/db/queries.txt +++ b/docs/topics/db/queries.txt @@ -724,7 +724,7 @@ efficient code. In a newly created :class:`~django.db.models.query.QuerySet`, the cache is empty. The first time a :class:`~django.db.models.query.QuerySet` is evaluated -- and, hence, a database query happens -- Django saves the query results in -the :class:`~django.db.models.query.QuerySet`\'s cache and returns the results +the :class:`~django.db.models.query.QuerySet`’s cache and returns the results that have been explicitly requested (e.g., the next element, if the :class:`~django.db.models.query.QuerySet` is being iterated over). Subsequent evaluations of the :class:`~django.db.models.query.QuerySet` reuse the cached diff --git a/docs/topics/db/tablespaces.txt b/docs/topics/db/tablespaces.txt index 8bf1d07bca..115887f512 100644 --- a/docs/topics/db/tablespaces.txt +++ b/docs/topics/db/tablespaces.txt @@ -30,7 +30,7 @@ Declaring tablespaces for indexes --------------------------------- You can pass the :attr:`~django.db.models.Field.db_tablespace` option to a -``Field`` constructor to specify an alternate tablespace for the ``Field``'s +``Field`` constructor to specify an alternate tablespace for the ``Field``’s column index. If no index would be created for the column, the option is ignored. diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt index 543a5e11ba..8be945d690 100644 --- a/docs/topics/forms/modelforms.txt +++ b/docs/topics/forms/modelforms.txt @@ -392,7 +392,7 @@ these security concerns do not apply to you: model = Author fields = '__all__' -2. Set the ``exclude`` attribute of the ``ModelForm``'s inner ``Meta`` class to +2. Set the ``exclude`` attribute of the ``ModelForm``’s inner ``Meta`` class to a list of fields to be excluded from the form. For example:: @@ -768,7 +768,7 @@ Specifying widgets to use in the form with ``widgets`` .. versionadded:: 1.6 Using the ``widgets`` parameter, you can specify a dictionary of values to -customize the ``ModelForm``'s widget class for a particular field. This +customize the ``ModelForm``’s widget class for a particular field. This works the same way as the ``widgets`` dictionary on the inner ``Meta`` class of a ``ModelForm`` works::