From f608c67eb1a7a53b341b5af52892e99079ce9344 Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Tue, 3 Apr 2018 17:42:47 +0100 Subject: [PATCH] Fix capitalisation of names --- .../customisation/extending_hallo.rst | 6 +++--- docs/reference/contrib/modeladmin/indexview.rst | 2 +- docs/reference/contrib/modeladmin/primer.rst | 12 ++++++------ docs/reference/contrib/table_block.rst | 6 +++--- docs/releases/0.4.rst | 2 +- docs/topics/search/backends.rst | 2 +- docs/topics/writing_templates.rst | 2 +- 7 files changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/advanced_topics/customisation/extending_hallo.rst b/docs/advanced_topics/customisation/extending_hallo.rst index aa573955d..3e0d9a111 100644 --- a/docs/advanced_topics/customisation/extending_hallo.rst +++ b/docs/advanced_topics/customisation/extending_hallo.rst @@ -37,9 +37,9 @@ A plugin ``halloblockquote``, implemented in ``myapp/js/hallo-blockquote.js``, t The constructor for ``HalloPlugin`` accepts the following keyword arguments: - * ``name`` - the plugin name as defined in the Javascript code. ``hallo.js`` plugin names are prefixed with the ``"IKS."`` namespace, but the name passed here should be without the prefix. - * ``options`` - a dictionary (or other JSON-serialisable object) of options to be passed to the Javascript plugin code on initialisation - * ``js`` - a list of Javascript files to be imported for this plugin, defined in the same way as a `Django form media `_ definition + * ``name`` - the plugin name as defined in the JavaScript code. ``hallo.js`` plugin names are prefixed with the ``"IKS."`` namespace, but the name passed here should be without the prefix. + * ``options`` - a dictionary (or other JSON-serialisable object) of options to be passed to the JavaScript plugin code on initialisation + * ``js`` - a list of JavaScript files to be imported for this plugin, defined in the same way as a `Django form media `_ definition * ``css`` - a dictionary of CSS files to be imported for this plugin, defined in the same way as a `Django form media `_ definition * ``order`` - an index number (default 100) specifying the order in which plugins should be listed, which in turn determines the order buttons will appear in the toolbar diff --git a/docs/reference/contrib/modeladmin/indexview.rst b/docs/reference/contrib/modeladmin/indexview.rst index 43fd3114d..1b54bd1c1 100644 --- a/docs/reference/contrib/modeladmin/indexview.rst +++ b/docs/reference/contrib/modeladmin/indexview.rst @@ -501,7 +501,7 @@ help give the value more context: Or you might like to add one or more data attributes to help implement some -kind of interactivity using javascript: +kind of interactivity using JavaScript: .. code-block:: python diff --git a/docs/reference/contrib/modeladmin/primer.rst b/docs/reference/contrib/modeladmin/primer.rst index 170919bc0..123c118da 100644 --- a/docs/reference/contrib/modeladmin/primer.rst +++ b/docs/reference/contrib/modeladmin/primer.rst @@ -60,7 +60,7 @@ possible. You should bare this in mind if you ever find yourself wanting to change what happens when pages of a certain type are added, deleted, published, or have some other action applied to them. Customising the ``CreateView`` or ``EditView`` for your a page type ``Model`` (even it just -to add an additional stylesheet or javascript), simply won't have any +to add an additional stylesheet or JavaScript), simply won't have any effect, as those views are not used. If you do find yourself needing to customise the add, edit or other @@ -98,11 +98,11 @@ going: :doc:`indexview` .. _modeladmin_adding_css_and_js: ----------------------------------------------- -Adding additional stylesheets and/or javascript +Adding additional stylesheets and/or JavaScript ----------------------------------------------- The ``ModelAdmin`` class provides several attributes to enable you to easily -add additional stylesheets and javascript to the admin interface for your +add additional stylesheets and JavaScript to the admin interface for your model. Each atttribute simply needs to be a list of paths to the files you want to include. If the path is for a file in your project's static directory, Wagtail will automatically prepended paths for each path with ``STATIC_URL``, @@ -114,7 +114,7 @@ following attributes: - ``index_view_extra_css`` - Where each item is the path name of a pre-compiled stylesheet that you'd like to include. -- ``index_view_extra_js`` - Where each item is the path name of a javascript +- ``index_view_extra_js`` - Where each item is the path name of a JavaScript file that you'd like to include. If you'd like to do the same for ``CreateView`` and ``EditView``, you should @@ -123,7 +123,7 @@ set the following attributes: - ``form_view_extra_css`` - Where each item is the path name of a pre-compiled stylesheet that you'd like to include. -- ``form_view_extra_js`` - Where each item is the path name of a javascript +- ``form_view_extra_js`` - Where each item is the path name of a JavaScript file that you'd like to include. And if you're using the ``InspectView`` for your model, and want to do the same @@ -132,7 +132,7 @@ for that view, your should set the following attributes: - ``inspect_view_extra_css`` - Where each item is the path name of a pre-compiled stylesheet that you'd like to include. -- ``inspect_view_extra_js`` - Where each item is the path name of a javascript +- ``inspect_view_extra_js`` - Where each item is the path name of a JavaScript file that you'd like to include. .. _modeladmin_overriding_templates: diff --git a/docs/reference/contrib/table_block.rst b/docs/reference/contrib/table_block.rst index c3b86a9fc..5b4650f82 100644 --- a/docs/reference/contrib/table_block.rst +++ b/docs/reference/contrib/table_block.rst @@ -71,15 +71,15 @@ Every key in the ``table_options`` dictionary maps to a `handsontable `_ - The default number of columns for new tables. * `colHeaders `_ - Can be set to ``True`` or ``False``. This setting designates if new tables should be created with column rows. **Note:** this only sets the behaviour for newly created tables. Page editors can override this by checking the the “Column header” checkbox in the table editor in the Wagtail admin. * `rowHeaders `_ - Operates the same as ``colHeaders`` to designate if new tables should be created with the first row as a header. Just like ``colHeaders`` this option can be overridden by the page editor in the Wagtail admin. -* `contextMenu `_ - Enables or disables the handsontable right-click menu. By default this is set to ``True``. +* `contextMenu `_ - Enables or disables the Handsontable right-click menu. By default this is set to ``True``. * `editor `_ - Defines the editor used for table cells. The default setting is text. * `stretchH `_ - Sets the default horizontal resizing of tables. Options include, 'none', 'last', and 'all'. By default TableBlock uses 'all' for the even resizing of columns. * `height `_ - The default height of the grid. By default TableBlock sets the height to ``108`` for the optimal appearance of new tables in the editor. This is optimized for tables with ``startRows`` set to ``3``. If you change the number of ``startRows`` in the configuration you might need to change the ``height`` setting to improve the default appearance in the editor. * `language `_ - The default language setting. By default TableBlock tries to get the language from ``django.utils.translation.get_language``. If needed, this setting can be overridden here. -* `renderer `_ - The default setting handsontable uses to render the content of table cells. +* `renderer `_ - The default setting Handsontable uses to render the content of table cells. * `autoColumnSize `_ - Enables or disables the ``autoColumnSize`` plugin. The TableBlock default setting is ``False``. -A `complete list of handsontable options `_ can be found on the handsontable website. +A `complete list of handsontable options `_ can be found on the Handsontable website. Changing the default table_options diff --git a/docs/releases/0.4.rst b/docs/releases/0.4.rst index 1145829e0..4d998b244 100644 --- a/docs/releases/0.4.rst +++ b/docs/releases/0.4.rst @@ -140,7 +140,7 @@ Backwards-incompatible changes ElasticUtils replaced with elasticsearch-py ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If you are using the elasticsearch backend, you must install the ``elasticsearch`` module into your environment. +If you are using the Elasticsearch backend, you must install the ``elasticsearch`` module into your environment. .. note:: diff --git a/docs/topics/search/backends.rst b/docs/topics/search/backends.rst index eb65ad55a..e98865cc4 100644 --- a/docs/topics/search/backends.rst +++ b/docs/topics/search/backends.rst @@ -132,7 +132,7 @@ The backend is configured in settings: Other than ``BACKEND``, the keys are optional and default to the values shown. Any defined key in ``OPTIONS`` is passed directly to the Elasticsearch constructor as case-sensitive keyword argument (e.g. ``'max_retries': 1``). -``INDEX_SETTINGS`` is a dictionary used to override the default settings to create the index. The default settings are defined inside the ``ElasticsearchSearchBackend`` class in the module ``wagtail/wagtail/wagtailsearch/backends/elasticsearch.py``. Any new key is added, any existing key, if not a dictionary, is replaced with the new value. Here's a sample on how to configure the number of shards and setting the italian LanguageAnalyzer as the default analyzer: +``INDEX_SETTINGS`` is a dictionary used to override the default settings to create the index. The default settings are defined inside the ``ElasticsearchSearchBackend`` class in the module ``wagtail/wagtail/wagtailsearch/backends/elasticsearch.py``. Any new key is added, any existing key, if not a dictionary, is replaced with the new value. Here's a sample on how to configure the number of shards and setting the Italian LanguageAnalyzer as the default analyzer: .. code-block:: python diff --git a/docs/topics/writing_templates.rst b/docs/topics/writing_templates.rst index c36b63837..140c608bf 100644 --- a/docs/topics/writing_templates.rst +++ b/docs/topics/writing_templates.rst @@ -221,7 +221,7 @@ By default the User Bar appears in the bottom right of the browser window, inset {% wagtailuserbar 'bottom-right' %} ... -The userbar can be positioned where it works best with your design. Alternatively, you can position it with a css rule in your own CSS files, for example: +The userbar can be positioned where it works best with your design. Alternatively, you can position it with a CSS rule in your own CSS files, for example: .. code-block:: css