javascript_catalog(request, domain='djangojs', packages=None)
[source]
Deprecated since version 1.10: javascript_catalog()
is deprecated in favor of JavaScriptCatalog
and will be removed in Django 2.0.
The main solution to these problems is the 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 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 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 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.
Before Django 1.9, the catalogs completely overwrote each other and you could only use one at a time.
The JavaScript translations found in the paths listed in the 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 LOCALE_PATHS
have the highest precedence with the ones appearing first having higher precedence than the ones appearing later.
Please login to continue.