Added missing period to "etc.".
This commit is contained in:
parent
99d2469e75
commit
b34ff66e5b
|
@ -227,7 +227,7 @@ class BaseDatabaseOperations(object):
|
|||
def lookup_cast(self, lookup_type, internal_type=None):
|
||||
"""
|
||||
Returns the string to use in a query when performing lookups
|
||||
("contains", "like", etc). The resulting string should contain a '%s'
|
||||
("contains", "like", etc.). The resulting string should contain a '%s'
|
||||
placeholder for the column being searched against.
|
||||
"""
|
||||
return "%s"
|
||||
|
|
|
@ -842,7 +842,7 @@ def yesno(value, arg=None):
|
|||
def filesizeformat(bytes_):
|
||||
"""
|
||||
Formats the value like a 'human-readable' file size (i.e. 13 KB, 4.1 MB,
|
||||
102 bytes, etc).
|
||||
102 bytes, etc.).
|
||||
"""
|
||||
try:
|
||||
bytes_ = float(bytes_)
|
||||
|
|
|
@ -117,7 +117,7 @@ class Literal(TokenBase):
|
|||
"""
|
||||
# IfParser uses Literal in create_var, but TemplateIfParser overrides
|
||||
# create_var so that a proper implementation that actually resolves
|
||||
# variables, filters etc is used.
|
||||
# variables, filters etc. is used.
|
||||
id = "literal"
|
||||
lbp = 0
|
||||
|
||||
|
|
|
@ -40,7 +40,7 @@ something like this::
|
|||
"""A hand of cards (bridge style)"""
|
||||
|
||||
def __init__(self, north, east, south, west):
|
||||
# Input parameters are lists of cards ('Ah', '9s', etc)
|
||||
# Input parameters are lists of cards ('Ah', '9s', etc.)
|
||||
self.north = north
|
||||
self.east = east
|
||||
self.south = south
|
||||
|
|
|
@ -221,7 +221,7 @@ When a mistaken commit is discovered, please follow these guidelines:
|
|||
|
||||
* If the original author can't be reached (within a reasonable amount
|
||||
of time -- a day or so) and the problem is severe -- crashing bug,
|
||||
major test failures, etc -- then ask for objections on the
|
||||
major test failures, etc. -- then ask for objections on the
|
||||
|django-developers| mailing list then revert if there are none.
|
||||
|
||||
* If the problem is small (a feature commit after feature freeze,
|
||||
|
|
|
@ -225,7 +225,7 @@ annotate
|
|||
Annotates each object in the ``QuerySet`` with the provided list of :doc:`query
|
||||
expressions </ref/models/expressions>`. An expression may be a simple value, a
|
||||
reference to a field on the model (or any related models), or an aggregate
|
||||
expression (averages, sums, etc) that has been computed over the objects that
|
||||
expression (averages, sums, etc.) that has been computed over the objects that
|
||||
are related to the objects in the ``QuerySet``.
|
||||
|
||||
Each argument to ``annotate()`` is an annotation that will be added
|
||||
|
@ -1954,7 +1954,7 @@ aggregate
|
|||
|
||||
.. method:: aggregate(*args, **kwargs)
|
||||
|
||||
Returns a dictionary of aggregate values (averages, sums, etc) calculated over
|
||||
Returns a dictionary of aggregate values (averages, sums, etc.) calculated over
|
||||
the ``QuerySet``. Each argument to ``aggregate()`` specifies a value that will
|
||||
be included in the dictionary that is returned.
|
||||
|
||||
|
|
|
@ -1505,7 +1505,7 @@ filesizeformat
|
|||
^^^^^^^^^^^^^^
|
||||
|
||||
Formats the value like a 'human-readable' file size (i.e. ``'13 KB'``,
|
||||
``'4.1 MB'``, ``'102 bytes'``, etc).
|
||||
``'4.1 MB'``, ``'102 bytes'``, etc.).
|
||||
|
||||
For example::
|
||||
|
||||
|
|
|
@ -168,7 +168,7 @@ used template filters:
|
|||
|
||||
:tfilter:`filesizeformat`
|
||||
Formats the value like a "human-readable" file size (i.e. ``'13 KB'``,
|
||||
``'4.1 MB'``, ``'102 bytes'``, etc). For example::
|
||||
``'4.1 MB'``, ``'102 bytes'``, etc.). For example::
|
||||
|
||||
{{ value|filesizeformat }}
|
||||
|
||||
|
|
|
@ -251,7 +251,7 @@ Models
|
|||
======
|
||||
|
||||
Because all strings are returned from the database as Unicode strings, model
|
||||
fields that are character based (CharField, TextField, URLField, etc) will
|
||||
fields that are character based (CharField, TextField, URLField, etc.) will
|
||||
contain Unicode values when Django retrieves data from the database. This
|
||||
is *always* the case, even if the data could fit into an ASCII bytestring.
|
||||
|
||||
|
|
|
@ -302,7 +302,7 @@ Work with file fields using the new API
|
|||
|
||||
The internal implementation of :class:`django.db.models.FileField` have changed.
|
||||
A visible result of this is that the way you access special attributes (URL,
|
||||
filename, image size, etc) of these model fields has changed. You will need to
|
||||
filename, image size, etc.) of these model fields has changed. You will need to
|
||||
make the following changes, assuming your model's
|
||||
:class:`~django.db.models.FileField` is called ``myfile``:
|
||||
|
||||
|
|
|
@ -150,7 +150,7 @@ actual project.
|
|||
|
||||
If settings, URLconfs and apps within the project are imported or referenced
|
||||
using the project name prefix (e.g. ``myproject.settings``, ``ROOT_URLCONF =
|
||||
"myproject.urls"``, etc), the new ``manage.py`` will need to be moved one
|
||||
"myproject.urls"``, etc.), the new ``manage.py`` will need to be moved one
|
||||
directory up, so it is outside the project package rather than adjacent to
|
||||
``settings.py`` and ``urls.py``.
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ objects instead of functions. They do not replace function-based views, but
|
|||
have certain differences and advantages when compared to function-based views:
|
||||
|
||||
* Organization of code related to specific HTTP methods (``GET``, ``POST``,
|
||||
etc) can be addressed by separate methods instead of conditional branching.
|
||||
etc.) can be addressed by separate methods instead of conditional branching.
|
||||
|
||||
* Object oriented techniques such as mixins (multiple inheritance) can be
|
||||
used to factor code into reusable components.
|
||||
|
|
|
@ -6,7 +6,7 @@ HTTP clients can send a number of headers to tell the server about copies of a
|
|||
resource that they have already seen. This is commonly used when retrieving a
|
||||
Web page (using an HTTP ``GET`` request) to avoid sending all the data for
|
||||
something the client has already retrieved. However, the same headers can be
|
||||
used for all HTTP methods (``POST``, ``PUT``, ``DELETE``, etc).
|
||||
used for all HTTP methods (``POST``, ``PUT``, ``DELETE``, etc.).
|
||||
|
||||
For each page (response) that Django sends back from a view, it might provide
|
||||
two HTTP headers: the ``ETag`` header and the ``Last-Modified`` header. These
|
||||
|
|
|
@ -4,7 +4,7 @@ Managing files
|
|||
|
||||
This document describes Django's file access APIs for files such as those
|
||||
uploaded by a user. The lower level APIs are general enough that you could use
|
||||
them for other purposes. If you want to handle "static files" (JS, CSS, etc),
|
||||
them for other purposes. If you want to handle "static files" (JS, CSS, etc.),
|
||||
see :doc:`/howto/static-files/index`.
|
||||
|
||||
By default, Django stores files locally, using the :setting:`MEDIA_ROOT` and
|
||||
|
|
|
@ -397,7 +397,7 @@ class NamespacePackageAppTests(SimpleTestCase):
|
|||
A Py3.3+ namespace package with multiple locations cannot be an app.
|
||||
|
||||
(Because then we wouldn't know where to load its templates, static
|
||||
assets, etc from.)
|
||||
assets, etc. from.)
|
||||
"""
|
||||
# Temporarily add two directories to sys.path that both contain
|
||||
# components of the "nsapp" package.
|
||||
|
|
|
@ -1384,7 +1384,7 @@ class MiscTests(SimpleTestCase):
|
|||
)
|
||||
def test_support_for_deprecated_chinese_language_codes(self):
|
||||
"""
|
||||
Some browsers (Firefox, IE etc) use deprecated language codes. As these
|
||||
Some browsers (Firefox, IE, etc.) use deprecated language codes. As these
|
||||
language codes will be removed in Django 1.9, these will be incorrectly
|
||||
matched. For example zh-tw (traditional) will be interpreted as zh-hans
|
||||
(simplified), which is wrong. So we should also accept these deprecated
|
||||
|
|
Loading…
Reference in New Issue