docs: Added the ContractionFilter option in the docs conf.py file. Re…

…vert my previous changes to the contractions in various files.
django-cms · luisnavarrodelangel · Sep 16, 2022 · Sep 17, 2022 · Sep 17, 2022 · Sep 17, 2022
commit b7b514b6645aa148b47fa3d929d8f5889da2dcac
diff --git a/docs/conf.py b/docs/conf.py
@@ -235,3 +235,8 @@
 spelling_word_list_filename = 'spelling_wordlist'
 
 spelling_ignore_pypi_package_names = True
+
+#Split common contractions from words so they are not flagged as errors by the spellchecker.
+#https://github.com/sphinx-contrib/spelling/blob/master/sphinxcontrib/spelling/filters.py
+#See https://sphinxcontrib-spelling.readthedocs.io/en/latest/customize.html#word-filters
+spelling_filters=["sphinxcontrib.spelling.filters.ContractionFilter"]
diff --git a/docs/contributing/code.rst b/docs/contributing/code.rst
@@ -175,7 +175,7 @@ into the web font. All classes will be automatically added to
 
 Additionally we created an SVG template within
 ``cms/static/cms/font/src/_template.svgz`` that you should use when converting
-or creating additional icons. It is named *svgz* so it does not get compiled
+or creating additional icons. It is named *svgz* so it doesn't get compiled
 into the font. When using *Adobe Illustrator* please mind the
 `following settings <images/svg_settings.png>`_.
 

diff --git a/docs/contributing/management.rst b/docs/contributing/management.rst
@@ -52,7 +52,7 @@ Getting your issue accepted
 Other django CMS developers will see your issue, and will be able to comment. A core developer may
 add further comments, or a :ref:`label <label-reference>`.
 
-The important thing at this stage is to have your issue *accepted*. This means that we have agreed
+The important thing at this stage is to have your issue *accepted*. This means that we've agreed
 it's a genuine issue, and represents something we can or are willing to do in the CMS.
 
 You may be asked for more information before it's accepted, and there may be some discussion before
@@ -84,7 +84,7 @@ A ticket's *status* and *needs* are the most important of these. They tell us tw
 Needless to say, these labels need to be applied carefully, according to the rules of this system.
 
 GitHub's interface means that we have no alternative but to use colours to help identify our
-tickets. We're sorry about this. We have tried to use colours that will cause the fewest issues for
+tickets. We're sorry about this. We've tried to use colours that will cause the fewest issues for
 colour-blind people, so we don't use green (since we use red) or yellow (since we use blue) labels,
 but we are aware it's not ideal.
 
@@ -191,7 +191,7 @@ only for one or the other:
 
     accepted
         (issues only) The issue has been accepted as a genuine issue that needs to be addressed.
-        Note that it does not necessarily mean we will do what the issue suggests, if it makes a
+        Note that it doesn't necessarily mean we will do what the issue suggests, if it makes a
         suggestion - simply that we agree that there is an issue to be resolved.
 
     non-issue
@@ -207,7 +207,7 @@ only for one or the other:
         When this label is applied, an explanation must be provided in a comment.
 
     marked for rejection
-        We have been unable to reproduce the issue, and it has lain dormant for a long time. Or, it's
+        We've been unable to reproduce the issue, and it has lain dormant for a long time. Or, it's
         a pull request of low significance that requires more work, and looks like it might have
         been abandoned. These tickets will be closed when we make the next release.
 
@@ -290,7 +290,7 @@ Other
 .. glossary::
 
     has patch
-        (issues only) A patch intended to address the issue exists. This does not imply that the
+        (issues only) A patch intended to address the issue exists. This doesn't imply that the
         patch will be accepted, or even that it contains a viable solution.
 
         When this label is applied, a comment should cross-reference the pull request(s) containing

diff --git a/docs/contributing/testing.rst b/docs/contributing/testing.rst
@@ -7,7 +7,7 @@ Running and writing tests
 Good code needs tests.
 
 A project like django CMS simply can't afford to incorporate new code that
-does not come with its own tests.
+doesn't come with its own tests.
 
 Tests provide some necessary minimum confidence: they can show the code will
 behave as it expected, and help identify what's going wrong if something breaks
@@ -219,7 +219,7 @@ can also rewind.
 It might sometimes be useful not to restart the server when creating the tests,
 for that you can run ``python testserver.py`` with necessary arguments in one
 shell and ``gulp tests:integration --no-server`` in another. However you would
-need to clean the state yourself if the test you have been writing fails.
+need to clean the state yourself if the test you've been writing fails.
 
 *************
 Writing tests
@@ -246,5 +246,5 @@ Generally tests should be:
 * Short running. No hard numbers here, but if your one test doubles the time it
   takes for everybody to run them, it's probably an indication that you're doing
   it wrong.
-* Easy to understand. If your test code is not obvious, please add comments on
+* Easy to understand. If your test code isn't obvious, please add comments on
   what it's doing.
diff --git a/docs/how_to/apphooks.rst b/docs/how_to/apphooks.rst
@@ -65,7 +65,7 @@ Apphooks for non-namespaced applications
 
 If you are writing apphooks for third-party applications, you may find one that in fact does
 not have an application namespace for its URLs. Such an application is liable to tun into namespace
-conflicts, and does not represent good practice.
+conflicts, and doesn't represent good practice.
 
 However if you *do* encounter such an application, your own apphook for it will need in turn to forgo the
 ``app_name`` attribute.

diff --git a/docs/how_to/custom_plugins.rst b/docs/how_to/custom_plugins.rst
@@ -83,7 +83,7 @@ Troubleshooting
 
 Since plugin modules are found and loaded by django's importlib, you might
 experience errors because the path environment is different at runtime. If
-your `cms_plugins` is not loaded or accessible, try the following::
+your `cms_plugins` isn't loaded or accessible, try the following::
 
     $ python manage.py shell
     >>> from importlib import import_module
@@ -118,7 +118,7 @@ In our ``models.py`` we add the following::
         guest_name = models.CharField(max_length=50, default='Guest')
 
 
-If you followed the Django tutorial, this should not look too new to you. The
+If you followed the Django tutorial, this shouldn't look too new to you. The
 only difference to normal models is that you sub-class
 :class:`cms.models.pluginmodel.CMSPlugin` rather than
 :class:`django.db.models.Model`.
@@ -201,7 +201,7 @@ Typically, you will want it to copy related objects. To do this you should
 create a method called ``copy_relations`` on your plugin model, that receives
 the **old** instance of the plugin as an argument.
 
-You may however decide that the related objects should not be copied - you may
+You may however decide that the related objects shouldn't be copied - you may
 want to leave them alone, for example. Or, you might even want to choose some
 altogether different relations for it, or to create new ones when it's
 copied... it depends on your plugin and the way you want it to work.
@@ -400,7 +400,7 @@ A **bad** example:
 .. note::
         If the Plugin requires javascript code to be rendered properly,
         the class ``'cms-execute-js-to-render'`` can be added to the script tag.
-        This will download and execute all scripts with this class, which were not present before,
+        This will download and execute all scripts with this class, which weren't present before,
         when the plugin is first added to the page.
         If the javascript code is protected from prematurely executing by
         the EventListener for the event ``'load'`` and/or ``'DOMContentLoaded'``,

diff --git a/docs/how_to/install.rst b/docs/how_to/install.rst
@@ -16,7 +16,7 @@ If you prefer to do things manually, this how-to guide will take you through the
     assumes that you are starting with a blank project, so you will need to adapt the steps below appropriately as
     required.
 
-This document assumes you have some basic familiarity with Python and Django. After you have integrated django CMS into
+This document assumes you have some basic familiarity with Python and Django. After you've integrated django CMS into
 your project, you should be able to follow the :doc:`/introduction/index` for an introduction to developing with django
 CMS.
 
@@ -141,7 +141,7 @@ Database
 
 django CMS requires a relational database backend. Each django CMS installation should have its own database.
 
-You can use SQLite, which is included in Python and does not need to be installed separately or configured further. You
+You can use SQLite, which is included in Python and doesn't need to be installed separately or configured further. You
 are unlikely to be using that for a project in production, but it's ideal for development and exploration, especially
 as it is configured by default in a new Django project's :setting:`django:DATABASES`::
 
@@ -414,7 +414,7 @@ so far has no plugins installed, which means it has no way of handling content i
 CMS is managed via plugins. So, we now need to install some additional addon applications to provide plugins and other
 functionality.
 
-You don't actually **need** to install any of these. django CMS does not commit you to any particular applications for
+You don't actually **need** to install any of these. django CMS doesn't commit you to any particular applications for
 content handling. The ones listed here however provide key functionality and are strongly recommended.
 
 Django Filer

diff --git a/docs/how_to/namespaced_apphooks.rst b/docs/how_to/namespaced_apphooks.rst
@@ -41,7 +41,7 @@ throw up a ``NoReverseMatch`` error.
 
 You can set the namespace for the instance of the apphook in the *Application instance name* field. However, you'll
 need to set that to something *different* if an instance with that value already exists. In this case, as long as
-``app_name = "myapp"`` it does not matter; even if the system does not find a match with the name of the instance it will
+``app_name = "myapp"`` it doesn't matter; even if the system does not find a match with the name of the instance it will
 fall back to the one hard-wired into the class.
 
 In other words setting ``app_name`` correctly guarantees that URL-reversing will work, because it sets the fallback

diff --git a/docs/how_to/testing.rst b/docs/how_to/testing.rst
@@ -9,7 +9,7 @@ Testing Apps
 Resolving View Names
 ====================
 
-Your apps need testing, but in your live site they are not in ``urls.py`` as
+Your apps need testing, but in your live site they aren't in ``urls.py`` as
 they are attached to a CMS page.  So if you want to be able to use
 :func:`~django.urls.reverse()` in your tests, or test templates that
 use the :ttag:`url` template tag, you need to hook up your app to a special

diff --git a/docs/how_to/toolbar.rst b/docs/how_to/toolbar.rst
@@ -293,7 +293,7 @@ items. For example, to find (using ``get_menu()``) and rename the *Site* menu:
 
 * it can update the item's attributes itself
   (``self.toolbar.get_or_create_menu(ADMIN_MENU_IDENTIFIER, 'Site')``)
-* if the item does not exist, it will create it rather than raising an error.
+* if the item doesn't exist, it will create it rather than raising an error.
 
 
 ``find_items()`` and ``find_first()``
@@ -308,7 +308,7 @@ Search for items by their type:
         self.toolbar.find_items(item_type=LinkItem)
 
 will find all ``LinkItem``\s in the toolbar (but not for example in the menus in the toolbar - it
-does not search *other* items in the toolbar for items of their own).
+doesn't search *other* items in the toolbar for items of their own).
 
 :meth:`~cms.toolbar.items.ToolbarAPIMixin.find_items` returns a list of
 :class:`~cms.toolbar.items.ItemSearchResult` objects;

diff --git a/docs/how_to/wizards.rst b/docs/how_to/wizards.rst
@@ -60,7 +60,7 @@ do this for ``MyApp``, it might look like this::
 
 .. note::
 
-    If your model does not define a ``get_absolute_url`` function then your wizard
+    If your model doesn't define a ``get_absolute_url`` function then your wizard
     will require a :ref:`get_success_url` method.
 
     ..  code-block:: python

diff --git a/docs/index.rst b/docs/index.rst
@@ -134,7 +134,7 @@ There are other capable Django-based CMS platforms but here's why you should
 consider django CMS:
 
 * thorough documentation
-* easy and comprehensive integration into existing projects - django CMS is not a monolithic application
+* easy and comprehensive integration into existing projects - django CMS isn't a monolithic application
 * a healthy, active and supportive developer community
 * a strong culture of good code, including an emphasis on automated testing
 

diff --git a/docs/introduction/01-install.rst b/docs/introduction/01-install.rst
@@ -48,7 +48,7 @@ First, open your system's terminal and go to the folder where you want to instal
 Confirm you can access the login page
 ****************************************
 
-Once the installation process has finished, open your browser and type `http://localhost:8000/admin <http://localhost:8000/admin>`_. You have successfully installed django CMS, If you can see the login page.
+Once the installation process has finished, open your browser and type `http://localhost:8000/admin <http://localhost:8000/admin>`_. If you can see the login page, you have successfully installed django CMS.
 
 Log in using the username and password you set during the installation process.
 

diff --git a/docs/introduction/03-templates_placeholders.rst b/docs/introduction/03-templates_placeholders.rst
@@ -76,7 +76,7 @@ If you switch to *Structure* mode (*button in the upper-right corner of the page
 Static Placeholders
 *******************
 
-The content of the placeholders we have encountered so far is different for
+The content of the placeholders we've encountered so far is different for
 every page. Sometimes though you'll want to have a section on your website
 which should be the same on every single page, such as a footer block.
 

diff --git a/docs/introduction/04-integrating_applications.rst b/docs/introduction/04-integrating_applications.rst
@@ -10,11 +10,11 @@ All the following sections of this tutorial are concerned with different ways of
 applications into django CMS. The ease with which other applications can be built into django CMS
 sites is an important feature of the system.
 
-Integrating applications does not merely mean installing them alongside django CMS, so that they peacefully co-exist. It
+Integrating applications doesn't merely mean installing them alongside django CMS, so that they peacefully co-exist. It
 means using django CMS's features to build them into a single coherent web project that speeds up the work of managing
 the site, and makes possible richer and more automated publishing.
 
-It's key to the way that django CMS integration works that **it does not require you to modify your other applications**
+It's key to the way that django CMS integration works that **it doesn't require you to modify your other applications**
 unless you want to. This is particularly important when you're using third-party applications and don't want to have to
 maintain your own forked versions of them. (The only exception to this is if you decide to build django CMS features
 directly into the applications themselves, for example when using :ref:`placeholders in other applications
@@ -57,7 +57,7 @@ Add the ``poll`` URL configuration to ``urlpatterns`` in the project's ``urls.py
     )
 
 Note that it must be included **before** the line for the django CMS URLs. django CMS's URL pattern
-needs to be last, because it "swallows up" anything that has not already been matched by a previous
+needs to be last, because it "swallows up" anything that hasn't already been matched by a previous
 pattern.
 
 Now run the application's migrations:

diff --git a/docs/introduction/08-menu.rst b/docs/introduction/08-menu.rst
@@ -80,5 +80,5 @@ You can force the menu to be added automatically to the page by the apphook if y
 
     * If you're going to use sub-pages, you'll need to improve the menu styling to make it work a
       bit better.
-    * Since the Polls page lists all the Polls in it anyway, this is not really the most practical
+    * Since the Polls page lists all the Polls in it anyway, this isn't really the most practical
       addition to the menu.
diff --git a/docs/introduction/10-third_party.rst b/docs/introduction/10-third_party.rst
@@ -6,7 +6,7 @@
 Integrating a third-party application
 #####################################
 
-We have already written our own django CMS plugins and apps, but now we want to
+We've already written our own django CMS plugins and apps, but now we want to
 extend our CMS with a third-party application,
 `Djangocms-Blog <https://github.com/nephila/djangocms-blog>`_.
 
@@ -81,7 +81,7 @@ Add the following url pattern to the main ``urls.py``:
 Migrate the database
 ********************
 
-We have added a new application so we need to update our database::
+We've added a new application so we need to update our database::
 
     python manage.py migrate
 

diff --git a/docs/reference/navigation.rst b/docs/reference/navigation.rst
@@ -202,7 +202,7 @@ Properties of Navigation Nodes in templates
 
     {{ node.is_leaf_node }}
 
-Is it the last in the tree? If true it does not have any children.
+Is it the last in the tree? If true it doesn't have any children.
 
 ::
 

diff --git a/docs/reference/templatetags.rst b/docs/reference/templatetags.rst
@@ -302,7 +302,7 @@ Example::
     <a href="{% page_url "help" %}">Help page</a>
     <a href="{% page_url request.current_page.parent %}">Parent page</a>
 
-If a matching page is not found and :setting:`django:DEBUG` is ``True``, an
+If a matching page isn't found and :setting:`django:DEBUG` is ``True``, an
 exception will be raised. However, if :setting:`django:DEBUG` is ``False``, an
 exception will not be raised.
 

diff --git a/docs/topics/colorscheme.rst b/docs/topics/colorscheme.rst
@@ -1,7 +1,7 @@
 .. _colorscheme:
 
 ###########################################
-Colour schemes (light/dark) with django CMS
+Color schemes (light/dark) with django CMS
 ###########################################
 
 .. important::

diff --git a/docs/topics/frontend-integration.rst b/docs/topics/frontend-integration.rst
@@ -4,7 +4,7 @@
 Frontend integration
 ####################
 
-Generally speaking, django CMS is wholly frontend-agnostic. It does not care what your site's
+Generally speaking, django CMS is wholly frontend-agnostic. It doesn't care what your site's
 frontend is built on or uses.
 
 The exception to this is when editing your site, as the django CMS toolbar and editing controls

diff --git a/docs/topics/menu_system.rst b/docs/topics/menu_system.rst
@@ -75,7 +75,7 @@ menu becomes much more manageable::
 Registration
 ============
 
-The menu system is not monolithic. Rather, it is composed of numerous active parts, many of which can operate independently of each other.
+The menu system isn't monolithic. Rather, it is composed of numerous active parts, many of which can operate independently of each other.
 
 What they operate on is a list of menu nodes, that gets passed around the menu system, until it emerges at the other end.
 

diff --git a/docs/topics/multiple_languages.rst b/docs/topics/multiple_languages.rst
@@ -40,4 +40,4 @@ What django CMS shows in your menus
 ===================================
 
 If :setting:`hide_untranslated` is ``True`` (the default) then pages that
-are not translated into the desired language will not appear in the menu.
+aren't translated into the desired language will not appear in the menu.
diff --git a/docs/topics/permissions.rst b/docs/topics/permissions.rst
@@ -92,7 +92,7 @@ They include:
 
 .. _important:
 
-    Even though a user may have *Can edit* permissions on a page, that does not give them
+    Even though a user may have *Can edit* permissions on a page, that doesn't give them
     permissions to add or change plugins *within* that page. In order to be able to
     add/change/delete plugins on any page, you will need to go through :ref:`the standard Django
     permissions <key-user-permissions>` to provide users with the actions they can perform, for
@@ -118,7 +118,7 @@ only.
 .. _view-restrictions:
 
 *View restrictions* determine which groups and users will be able to see the page when it is
-published. Adding a view restriction will allow you to set this. Note that this does not apply any
+published. Adding a view restriction will allow you to set this. Note that this doesn't apply any
 restrictions to users who are also editors with appropriate permissions.
 
 *Page permissions* determine what editors can do to a page (or hierarchy of pages). They are

diff --git a/docs/topics/plugins.rst b/docs/topics/plugins.rst
@@ -71,12 +71,12 @@ template             rendering                         --
 The plugin **model**, the sub-class of :class:`cms.models.pluginmodel.CMSPlugin`,
 is optional.
 
-You could have a plugin that does not need to be configured, because it only
+You could have a plugin that doesn't need to be configured, because it only
 ever does one thing.
 
 For example, you could have a plugin that only publishes information
-about the top-selling record of the past seven days. Obviously, this would not
-be very flexible - you would not be able to use the same plugin for the
+about the top-selling record of the past seven days. Obviously, this wouldn't
+be very flexible - you wouldn't be able to use the same plugin for the
 best-selling release of the last *month* instead.
 
 Usually, you find that it is useful to be able to configure your plugin, and this

diff --git a/docs/upgrade/2.2.rst b/docs/upgrade/2.2.rst
@@ -81,7 +81,7 @@ the ``cms_tags`` template tag library in your templates. The template tag
 should be placed somewhere within the body of the HTML (within ``<body>...</body>``).
 
 This solves issues people were having with the toolbar showing up in places it
-should not have.
+shouldn't have.
 
 
 Static files moved to /static/
-Original file line number
+Diff line change
@@ Expand Up / @@ -202,7 +202,7 @@ Properties of Navigation Nodes in templates @@
         {{ node.is_leaf_node }}
-    Is it the last in the tree? If true it does not have any children.
+    Is it the last in the tree? If true it doesn't have any children.
     ::
@@ Expand Down @@