mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-09 21:38:18 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

[1.7.x] Various documentation typo/spelling fixes

Browse source 
Errors detected by Topy (https://github.com/intgr/topy), all changes
verified by hand.

Backport of 11d453bcad from master
This commit is contained in:
Marti Raudsepp 2014-04-23 02:05:14 +03:00 • committed by Tim Graham
parent 4499c676ef
commit ba1728dd9b
18 changed files with 18 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/internals/committers.txt
View file

@ -310,7 +310,7 @@ Ramiro Morales
Honza Král
Honza first discovered Django in 2006 and started using it right away,
first for school and personal projects and later in his full time job. He
first for school and personal projects and later in his full-time job. He
contributed various patches and fixes mostly to the newforms library,
newforms admin and, through participation in the Google Summer of Code
project, assisted in creating the :ref:`model validation
@ -510,7 +510,7 @@ Marc Tamlyn
documentation at DjangoCon EU 2012, and also helped to develop `CCBV`_, an
additional class based view reference tool.
Marc is currently a full time parent, part time developer, and lives in
Marc is currently a full-time parent, part-time developer, and lives in
Oxford, UK.
.. _CCBV: http://ccbv.co.uk/

2
docs/internals/contributing/writing-code/coding-style.txt
View file

@ -206,7 +206,7 @@ Miscellaneous
* Remove ``import`` statements that are no longer used when you change code.
`flake8`_ will identify these imports for you. If an unused import needs to
remain for backwards-compatibility, mark the end of of with ``# NOQA`` to
remain for backwards-compatibility, mark the end of with ``# NOQA`` to
silence the flake8 warning.
* Systematically remove all trailing whitespaces from your code as those

2
docs/internals/contributing/writing-documentation.txt
View file

@ -205,7 +205,7 @@ Our policy for new features is:
release, not the development version.
Our preferred way for marking new features is by prefacing the features'
documentation with: "``.. versionadded:: X.Y``", followed by a a mandatory
documentation with: "``.. versionadded:: X.Y``", followed by a mandatory
blank line and an optional content (indented).
General improvements, or other changes to the APIs that should be emphasized