1
0
mirror of https://github.com/django/django.git synced 2025-07-04 01:39:20 +00:00

i18n: updated translation documentation for new syntax

git-svn-id: http://code.djangoproject.com/svn/django/branches/i18n@1063 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Georg Bauer 2005-11-03 12:01:16 +00:00
parent c9194cdf90
commit ed05d90232

View File

@ -120,45 +120,41 @@ A standard problem with translations is pluralization of strings. Use
Using translations in templates Using translations in templates
=============================== ===============================
Using translations in Django templates works much like translations in Python Using translations in Django templates uses two template tags and a slightly
code. The ``{% i18n %}`` template tag lets you use the same ``_()`` helper different syntax than standard gettext. The ``{% trans %}`` template tag
function as in your Python code:: translates a constant string or a variable content::
<html> <title>{% trans 'This is the title.' %}</title>
<title>{% i18n _('This is the title.') %}</title>
<body>
<p>{% i18n _('Hello %(name)s, welcome at %(site)s!') %}</p>
<p>{% i18n ngettext('There is %(count)d file', 'There are %(count)d files', files|count) %}</p>
</body>
</html>
It's not only possible to translate hard-coded strings, but the strings can If you only want to mark some value for translation, but translate it
contain interpolated parts, e.g. ``%(name)s``. Those parts are automatically later from a variable, use the ``noop`` option::
resolved from the template context, just as they would be if you had used them
in ``{{ ... }}``. But this can only resolve variables, not more complex
expressions.
To translate a variable value, do this:: <input name="field" value="{% trans "value" noop %}"/>
{% i18n _(variable) %} It is not possible to use variables in this constant string. If you
have variables you need to put in your translations, you have to use the
``{% blocktrans %}`` tag::
Filters are allowed, too:: {% blocktrans %}This will have {{ value }} inside{% endblocktrans %}
{% i18n _(variable|lower) %} If your expressions are more complex (like you need to have filters applied),
you need to bind them to local variables for the translation block::
Any template tag that resolves variables accepts i18n-string constants, too. {% blocktrans with value|filter as variable %}
This will have {{ value }} inside
{% endblocktrans %}
Also, note you can use ``_()`` around variable names, like so:: The last variant is the pluralization form: you need to specify both the singular
and plural sentence with intersparsed variables like this::
<html> {% blocktrans count list|counted as counter %}
<title>{{ _('This is the title') }}</title> There is only one {{ name }} object.
<body> {% plural %}
<p>{{ _('Hello, world!') }}</p> There are {{ counter }} {{ name }} objects.
</body> {% endblocktrans %}
</html>
This syntax is much shorter, but it doesn't allow you to use ``gettext_noop`` Internally all block translations and inline translations are translated into
or ``ngettext``. the actual gettext/ngettext call.
Each ``DjangoContext`` has access to two translation-specific variables: Each ``DjangoContext`` has access to two translation-specific variables:
@ -167,6 +163,15 @@ Each ``DjangoContext`` has access to two translation-specific variables:
* ``LANGUAGE_CODE`` is the current user's preferred language, as a string. * ``LANGUAGE_CODE`` is the current user's preferred language, as a string.
Example: ``en-us``. (See "How language preference is discovered", below.) Example: ``en-us``. (See "How language preference is discovered", below.)
If you don't use the ``DjangoContext`` extension, you can get those values with
two tags::
{% get_current_language as LANGUAGE_CODE %}
{% get_available_languages as LANGUAGES %}
All tags live in the ``i18n`` tag library, so you need to specify
``{% load i18n %}`` in the head of your template to make use of them.
The ``setlang`` redirect view The ``setlang`` redirect view
----------------------------- -----------------------------