Skip to content

Commit 3070deb

Browse files
authored
Fixed simple typos (jazzband#996)
1 parent 6325659 commit 3070deb

10 files changed

+12
-13
lines changed

AUTHORS.rst

+1
Original file line numberDiff line numberDiff line change
@@ -25,6 +25,7 @@ Authors
2525
- Carlos San Emeterio (`Carlos-San-Emeterio <https://github.com/Carlos-San-Emeterio>`_)
2626
- Christopher Broderick (`uhurusurfa <https://github.com/uhurusurfa>`_)
2727
- Christopher Johns (`tyrantwave <https://github.com/tyrantwave>`_)
28+
- Conrad (`creyD <https://github.com/creyD>`_)
2829
- Corey Bertram
2930
- Craig Maloney (`craigmaloney <https://github.com/craigmaloney>`_)
3031
- Damien Nozay

CHANGES.rst

+1
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,7 @@ Changes
44
Unreleased
55
----------
66

7+
- Fixed typos in the docs
78
- Removed n+1 query from ``bulk_create_with_history`` utility (gh-975)
89
- Started using ``exists`` query instead of ``count`` in ``populate_history`` command (gh-982)
910

docs/common_issues.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -253,7 +253,7 @@ Working with BitBucket Pipelines
253253
--------------------------------
254254

255255
When using BitBucket Pipelines to test your Django project with the
256-
django-simple-history middleware, you will run into an error relating to missing migrations relating to the historic User model from the auth app. This is because the migration file is not held within either your project or django-simple-history. In order to pypass the error you need to add a ```python manage.py makemigrations auth``` step into your YML file prior to running the tests.
256+
django-simple-history middleware, you will run into an error relating to missing migrations relating to the historic User model from the auth app. This is because the migration file is not held within either your project or django-simple-history. In order to bypass the error you need to add a ```python manage.py makemigrations auth``` step into your YML file prior to running the tests.
257257

258258

259259
Using custom OneToOneFields

docs/historical_model.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -52,7 +52,7 @@ You're able to set a custom ``history_date`` attribute for the historical
5252
record, by defining the property ``_history_date`` in your model. That's
5353
helpful if you want to add versions to your model, which happened before the
5454
current model version, e.g. when batch importing historical data. The content
55-
of the property ``_history_date`` has to be a datetime-object, but setting the
55+
of the property ``_history_date`` has to be a ``datetime``-object, but setting the
5656
value of the property to a ``DateTimeField``, which is already defined in the
5757
model, will work too.
5858

docs/querying_history.rst

+3-3
Original file line numberDiff line numberDiff line change
@@ -144,7 +144,7 @@ If you use `as_of` to query history, the resulting instance will have an
144144
attribute named `_history` added to it. This property will contain the
145145
historical model record that the instance was derived from. Calling
146146
is_historic is an easy way to check if an instance was derived from a
147-
historic timepoint (even if it is the most recent version).
147+
historic point in time (even if it is the most recent version).
148148

149149
You can use `to_historic` to return the historical model that was used
150150
to furnish the instance at hand, if it is actually historic.
@@ -155,7 +155,7 @@ HistoricForeignKey
155155

156156
If you have two historic tables linked by foreign key, you can change it
157157
to use a HistoricForeignKey so that chasing relations from an `as_of`
158-
acquired instance (at a specific timepoint) will honor that timepoint
158+
acquired instance (at a specific point in time) will honor that point in time
159159
when accessing the related object(s). This works for both forward and
160160
reverse relationships.
161161

@@ -219,7 +219,7 @@ To filter changes to the data, a relationship to the history can be established.
219219
220220
Poll.objects.filter(history__history_user=4)
221221
222-
You can also prefetch the objects with this relationship using somthing like this for example to prefetch order by history_date descending:
222+
You can also prefetch the objects with this relationship using something like this for example to prefetch order by history_date descending:
223223

224224
.. code-block:: python
225225

docs/quick_start.rst

+2-2
Original file line numberDiff line numberDiff line change
@@ -141,14 +141,14 @@ tables in your database:
141141

142142
.. _above: `Track History`_
143143

144-
The two extra tables with ``historical`` prepended to their names are tables created
144+
The two extra tables with ``historical`` prepend to their names are tables created
145145
by ``django-simple-history``. These tables store every change that you make to their
146146
respective base tables. Every time a create, update, or delete occurs on ``Choice`` or
147147
``Poll`` a new row is created in the historical table for that model including all of
148148
the fields in the instance of the base model, as well as other metadata:
149149

150150
- ``history_user``: the user that made the create/update/delete
151-
- ``history_date``: the datetime at which the create/update/delete occurred
151+
- ``history_date``: the ``datetime`` at which the create/update/delete occurred
152152
- ``history_change_reason``: the reason the create/update/delete occurred (null by default)
153153
- ``history_id``: the primary key for the historical table (note the base table's
154154
primary key is not unique on the historical table since there are multiple versions of it

docs/user_tracking.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -58,7 +58,7 @@ Admin integration requires that you use a ``_history_user.setter`` attribute wit
5858
your custom ``_history_user`` property (see :doc:`/admin`).
5959

6060
Another option for identifying the change user is by providing a function via ``get_user``.
61-
If provided it will be called everytime that the ``history_user`` needs to be
61+
If provided it will be called every time that the ``history_user`` needs to be
6262
identified with the following key word arguments:
6363

6464
* ``instance``: The current instance being modified

docs/utils.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -43,7 +43,7 @@ If you find yourself with a lot of old history you can schedule the
4343
4444
$ python manage.py clean_old_history --auto
4545
46-
You can use ``--auto`` to remove old historial entries
46+
You can use ``--auto`` to remove old historical entries
4747
with ``HistoricalRecords`` or enumerate specific models as args.
4848
You may also specify a ``--days`` parameter, which indicates how many
4949
days of records you want to keep. The default it 30 days, meaning that

simple_history/locale/de/LC_MESSAGES/django.po

+1-1
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,7 @@ msgstr "%s wiederherstellen"
3838

3939
#: simple_history/models.py:314
4040
msgid "Created"
41-
msgstr "Angelegt"
41+
msgstr "Erstellt"
4242

4343
#: simple_history/models.py:314
4444
msgid "Changed"

simple_history/utils.py

-3
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,3 @@
1-
import warnings
2-
3-
import django
41
from django.db import transaction
52
from django.db.models import Case, ForeignKey, ManyToManyField, Q, When
63
from django.forms.models import model_to_dict

0 commit comments

Comments
 (0)