Fixed Sphinx highlight warnings in docs.
This commit is contained in:
parent
65c13f9675
commit
9c43d8252a
|
@ -70,8 +70,6 @@ as a shorter alias, ``_``, to save typing.
|
|||
global ``_()`` function causes interference. Explicitly importing
|
||||
``ugettext()`` as ``_()`` avoids this problem.
|
||||
|
||||
.. highlightlang:: python
|
||||
|
||||
In this example, the text ``"Welcome to my site."`` is marked as a translation
|
||||
string::
|
||||
|
||||
|
@ -1209,6 +1207,8 @@ Additionally, if there are complex rules around pluralization, the catalog view
|
|||
will render a conditional expression. This will evaluate to either a ``true``
|
||||
(should pluralize) or ``false`` (should **not** pluralize) value.
|
||||
|
||||
.. highlight:: python
|
||||
|
||||
The ``json_catalog`` view
|
||||
-------------------------
|
||||
|
||||
|
@ -1243,7 +1243,8 @@ The view is hooked up to your application and configured in the same fashion as
|
|||
|
||||
The response format is as follows:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: text
|
||||
.. JSON doesn't allow comments so highlighting as JSON won't work here.
|
||||
|
||||
{
|
||||
"catalog": {
|
||||
|
@ -1266,9 +1267,7 @@ Server-side caching will reduce CPU load. It's easily implemented with the
|
|||
:func:`~django.views.decorators.cache.cache_page` decorator. To trigger cache
|
||||
invalidation when your translations change, provide a version-dependent key
|
||||
prefix, as shown in the example below, or map the view at a version-dependent
|
||||
URL.
|
||||
|
||||
.. code-block:: python
|
||||
URL::
|
||||
|
||||
from django.views.decorators.cache import cache_page
|
||||
from django.views.i18n import javascript_catalog
|
||||
|
@ -1282,9 +1281,7 @@ Client-side caching will save bandwidth and make your site load faster. If
|
|||
you're using ETags (:setting:`USE_ETAGS = True <USE_ETAGS>`), you're already
|
||||
covered. Otherwise, you can apply :ref:`conditional decorators
|
||||
<conditional-decorators>`. In the following example, the cache is invalidated
|
||||
whenever you restart your application server.
|
||||
|
||||
.. code-block:: python
|
||||
whenever you restart your application server::
|
||||
|
||||
from django.utils import timezone
|
||||
from django.views.decorators.http import last_modified
|
||||
|
@ -1360,8 +1357,8 @@ After defining these URL patterns, Django will automatically add the
|
|||
language prefix to the URL patterns that were added by the ``i18n_patterns``
|
||||
function. Example::
|
||||
|
||||
from django.urls import reverse
|
||||
from django.utils.translation import activate
|
||||
>>> from django.urls import reverse
|
||||
>>> from django.utils.translation import activate
|
||||
|
||||
>>> activate('en')
|
||||
>>> reverse('sitemap-xml')
|
||||
|
@ -1417,8 +1414,8 @@ URL patterns can also be marked translatable using the
|
|||
After you've created the translations, the :func:`~django.urls.reverse`
|
||||
function will return the URL in the active language. Example::
|
||||
|
||||
from django.urls import reverse
|
||||
from django.utils.translation import activate
|
||||
>>> from django.urls import reverse
|
||||
>>> from django.utils.translation import activate
|
||||
|
||||
>>> activate('en')
|
||||
>>> reverse('news:category', kwargs={'slug': 'recent'})
|
||||
|
@ -1716,8 +1713,6 @@ translation utilities with a ``gettext`` package if the command ``xgettext
|
|||
Customizing the ``makemessages`` command
|
||||
----------------------------------------
|
||||
|
||||
.. highlightlang:: python
|
||||
|
||||
If you want to pass additional parameters to ``xgettext``, you need to create a
|
||||
custom :djadmin:`makemessages` command and override its ``xgettext_options``
|
||||
attribute::
|
||||
|
@ -1756,8 +1751,6 @@ Miscellaneous
|
|||
The ``set_language`` redirect view
|
||||
----------------------------------
|
||||
|
||||
.. highlightlang:: python
|
||||
|
||||
.. currentmodule:: django.views.i18n
|
||||
|
||||
.. function:: set_language(request)
|
||||
|
|
|
@ -29,7 +29,8 @@ which are particularly dangerous to HTML. While this protects users from most
|
|||
malicious input, it is not entirely foolproof. For example, it will not
|
||||
protect the following:
|
||||
|
||||
.. code-block:: html+django
|
||||
.. code-block:: text
|
||||
.. highlighting as html+django fails due to intentionally missing quotes.
|
||||
|
||||
<style class={{ var }}>...</style>
|
||||
|
||||
|
|
Loading…
Reference in New Issue