Skip to content

Commit

Permalink
[1.1.X] Fixed #11714 - Document a few of the i18n function that can b…
Browse files Browse the repository at this point in the history
…e used outside views and templates. Thanks, Jarek Zgoda and Ramiro Morales.

Backport or r12473.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.1.X@12483 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information
jezdez committed Feb 22, 2010
1 parent 5059de2 commit 9ee2d5c
Show file tree
Hide file tree
Showing 2 changed files with 35 additions and 2 deletions.
33 changes: 33 additions & 0 deletions docs/howto/i18n.txt
Expand Up @@ -70,3 +70,36 @@ The easiest way out is to store applications that are not part of the project
``django-admin.py makemessages`` on the project level will only translate
strings that are connected to your explicit project and not strings that are
distributed independently.

Using translations outside views and templates
==============================================

While Django provides a rich set of i18n tools for use in views and templates,
it does not restrict the usage to Django-specific code. The Django translation
mechanisms can be used to translate arbitrary texts to any language that is
supported by Django (as long as an appropriate translation catalog exists, of
course). You can load a translation catalog, activate it and translate text to
language of your choice, but remember to switch back to original language, as
activating a translation catalog is done on per-thread basis and such change
will affect code running in the same thread.

For example::

from django.utils import translation
def welcome_translated(language):
cur_language = translation.get_language()
try:
translation.activate(language)
text = translation.ugettext('welcome')
finally:
translation.activate(cur_language)
return text

Calling this function with the value 'de' will give you ``"Willkommen"``,
regardless of :setting:`LANGUAGE_CODE` and language set by middleware.

Functions of particular interest are ``django.utils.translation.get_language()``
which returns the language used in the current thread,
``django.utils.translation.activate()`` which activates a translation catalog
for the current thread, and ``django.utils.translation.check_for_language()``
which checks if the given language is supported by Django.
4 changes: 2 additions & 2 deletions docs/topics/i18n/index.txt
Expand Up @@ -18,11 +18,11 @@ Essentially, Django does two things:
to their language preferences.

The complete process can be seen as divided in three stages. It is also possible
to identify an identical number of roles with very well defined responsabilities
to identify an identical number of roles with very well defined responsibilities
associated with each of these tasks (although it's perfectly normal if you
find yourself performing more than one of these roles):

* For applicacion authors wishing to make sure their Django apps can be
* For application authors wishing to make sure their Django apps can be
used in different locales: :ref:`topics-i18n-internationalization`.
* For translators wanting to translate Django apps: :ref:`topics-i18n-localization`.
* For system administrators/final users setting up internationalized apps or
Expand Down

0 comments on commit 9ee2d5c

Please sign in to comment.