mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-04 19:08:28 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Refs #19567 -- Removed deprecated javascript_catalog() and json_catalog() views.

Browse source
This commit is contained in:
Tim Graham 2016-12-31 12:10:37 -05:00
parent 933dc62742
commit 2b20e4148f
6 changed files with 5 additions and 516 deletions
Download patch file Download diff file Expand all files Collapse all files

133
docs/topics/i18n/translation.txt
View file

@ -1049,88 +1049,6 @@ If you use more than one ``JavaScriptCatalog`` view on a site and some of them
define the same strings, the strings in the catalog that was loaded last take
precedence.
The ``javascript_catalog`` view
-------------------------------
.. function:: javascript_catalog(request, domain='djangojs', packages=None)
.. deprecated:: 1.10
``javascript_catalog()`` is deprecated in favor of
:class:`JavaScriptCatalog` and will be removed in Django 2.0.
The main solution to these problems is the
:meth:`django.views.i18n.javascript_catalog` view, which sends out a JavaScript
code library with functions that mimic the ``gettext`` interface, plus an array
of translation strings. Those translation strings are taken from applications or
Django core, according to what you specify in either the ``info_dict`` or the
URL. Paths listed in :setting:`LOCALE_PATHS` are also included.
You hook it up like this::
from django.views.i18n import javascript_catalog
js_info_dict = {
'packages': ('your.app.package',),
}
urlpatterns = [
url(r'^jsi18n/$', javascript_catalog, js_info_dict, name='javascript-catalog'),
]
Each string in ``packages`` should be in Python dotted-package syntax (the
same format as the strings in :setting:`INSTALLED_APPS`) and should refer to a
package that contains a ``locale`` directory. If you specify multiple packages,
all those catalogs are merged into one catalog. This is useful if you have
JavaScript that uses strings from different applications.
The precedence of translations is such that the packages appearing later in the
``packages`` argument have higher precedence than the ones appearing at the
beginning, this is important in the case of clashing translations for the same
literal.
By default, the view uses the ``djangojs`` gettext domain. This can be
changed by altering the ``domain`` argument.
You can make the view dynamic by putting the packages into the URL pattern::
urlpatterns = [
url(r'^jsi18n/(?P<packages>\S+?)/$', javascript_catalog, name='javascript-catalog'),
]
With this, you specify the packages as a list of package names delimited by '+'
signs in the URL. This is especially useful if your pages use code from
different apps and this changes often and you don't want to pull in one big
catalog file. As a security measure, these values can only be either
``django.conf`` or any package from the :setting:`INSTALLED_APPS` setting.
You can also split the catalogs in multiple URLs and load them as you need in
your sites::
js_info_dict_app = {
'packages': ('your.app.package',),
}
js_info_dict_other_app = {
'packages': ('your.other.app.package',),
}
urlpatterns = [
url(r'^jsi18n/app/$', javascript_catalog, js_info_dict_app),
url(r'^jsi18n/other_app/$', javascript_catalog, js_info_dict_other_app),
]
If you use more than one ``javascript_catalog`` on a site and some of them
define the same strings, the strings in the catalog that was loaded last take
precedence.
The JavaScript translations found in the paths listed in the
:setting:`LOCALE_PATHS` setting are also always included. To keep consistency
with the translations lookup order algorithm used for Python and templates, the
directories listed in :setting:`LOCALE_PATHS` have the highest precedence with
the ones appearing first having higher precedence than the ones appearing
later.
Using the JavaScript translation catalog
----------------------------------------
@ -1326,57 +1244,6 @@ The ``JSONCatalog`` view
.. JSON doesn't allow comments so highlighting as JSON won't work here.
The ``json_catalog`` view
-------------------------
.. function:: json_catalog(request, domain='djangojs', packages=None)
.. deprecated:: 1.10
``json_catalog()`` is deprecated in favor of :class:`JSONCatalog` and will
be removed in Django 2.0.
In order to use another client-side library to handle translations, you may
want to take advantage of the ``json_catalog()`` view. It's similar to
:meth:`~django.views.i18n.javascript_catalog` but returns a JSON response.
The JSON object contains i18n formatting settings (those available for
`get_format`_), a plural rule (as a ``plural`` part of a GNU gettext
``Plural-Forms`` expression), and translation strings. The translation strings
are taken from applications or Django's own translations, according to what is
specified either via ``urlpatterns`` arguments or as request parameters. Paths
listed in :setting:`LOCALE_PATHS` are also included.
The view is hooked up to your application and configured in the same fashion as
:meth:`~django.views.i18n.javascript_catalog` (namely, the ``domain`` and
``packages`` arguments behave identically)::
from django.views.i18n import json_catalog
js_info_dict = {
'packages': ('your.app.package',),
}
urlpatterns = [
url(r'^jsoni18n/$', json_catalog, js_info_dict),
]
The response format is as follows:
.. code-block:: text
{
"catalog": {
# Translations catalog
},
"formats": {
# Language formats for date, time, etc.
},
"plural": "..." # Expression for plural forms, or null.
}
.. JSON doesn't allow comments so highlighting as JSON won't work here.
Note on performance
-------------------