Author: gwilson Date: 2009-12-26 12:03:02 -0600 (Sat, 26 Dec 2009) New Revision: 12002
Modified: django/branches/releases/1.1.X/docs/topics/i18n.txt Log: [1.1.X] i18n documentation fixes: * Fixed typo (fixes #12449, thanks googol). * Wrapped long lines. * Removed unused link target directive. Backport of r12001 from trunk. Modified: django/branches/releases/1.1.X/docs/topics/i18n.txt =================================================================== --- django/branches/releases/1.1.X/docs/topics/i18n.txt 2009-12-26 18:02:09 UTC (rev 12001) +++ django/branches/releases/1.1.X/docs/topics/i18n.txt 2009-12-26 18:03:02 UTC (rev 12002) @@ -225,15 +225,15 @@ Use the function ``django.utils.translation.ungettext()`` to specify pluralized messages. -``ungettext`` takes three arguments: the singular translation string, the plural -translation string and the number of objects. +``ungettext`` takes three arguments: the singular translation string, the +plural translation string and the number of objects. -This function is useful when your need you Django application to be localizable +This function is useful when you need your Django application to be localizable to languages where the number and complexity of `plural forms <http://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms>`_ is greater than the two forms used in English ('object' for the singular and -'objects' for all the cases where ``count`` is different from zero, irrespective -of its value.) +'objects' for all the cases where ``count`` is different from zero, +irrespective of its value). For example:: @@ -276,8 +276,8 @@ .. note:: When using this technique, make sure you use a single name for every - extrapolated variable included in the literal. In the example above note how - we used the ``name`` Python variable in both translation strings. This + extrapolated variable included in the literal. In the example above note + how we used the ``name`` Python variable in both translation strings. This example would fail:: from django.utils.translation import ungettext @@ -355,8 +355,8 @@ {% endblocktrans %} When you use the pluralization feature and bind additional values to local -variables apart from the counter value that selects the translated literal to be -used, have in mind that the ``blocktrans`` construct is internally converted +variables apart from the counter value that selects the translated literal to +be used, have in mind that the ``blocktrans`` construct is internally converted to an ``ungettext`` call. This means the same :ref:`notes regarding ungettext variables <pluralization-var-notes>` apply. @@ -375,8 +375,8 @@ left-to-right language, e.g.: English, French, German etc. -If you don't use the ``RequestContext`` extension, you can get those values with -three tags:: +If you don't use the ``RequestContext`` extension, you can get those values +with three tags:: {% get_current_language as LANGUAGE_CODE %} {% get_available_languages as LANGUAGES %} @@ -542,8 +542,6 @@ When `creating JavaScript translation catalogs`_ you need to use the special 'djangojs' domain, **not** ``-e js``. -.. _create a JavaScript translation catalog: `Creating JavaScript translation catalogs`_ - .. admonition:: No gettext? If you don't have the ``gettext`` utilities installed, ``django-admin.py @@ -584,8 +582,8 @@ out empty, so it's your responsibility to change it. Make sure you keep the quotes around your translation. * As a convenience, each message includes, in the form of a comment line - prefixed with ``#`` and located above the ``msgid`` line, the filename and - line number from which the translation string was gleaned. + prefixed with ``#`` and located above the ``msgid`` line, the filename + and line number from which the translation string was gleaned. Long messages are a special case. There, the first string directly after the ``msgstr`` (or ``msgid``) is an empty string. Then the content itself will be @@ -615,9 +613,9 @@ you'll need to compile it into a more efficient form, for use by ``gettext``. Do this with the ``django-admin.py compilemessages`` utility. -This tool runs over all available ``.po`` files and creates ``.mo`` files, which -are binary files optimized for use by ``gettext``. In the same directory from -which you ran ``django-admin.py makemessages``, run ``django-admin.py +This tool runs over all available ``.po`` files and creates ``.mo`` files, +which are binary files optimized for use by ``gettext``. In the same directory +from which you ran ``django-admin.py makemessages``, run ``django-admin.py compilemessages`` like this:: django-admin.py compilemessages @@ -818,9 +816,9 @@ If you're using manually configured settings, as described :ref:`settings-without-django-settings-module`, the ``locale`` directory in the project directory will not be examined, since Django loses the ability - to work out the location of the project directory. (Django normally uses the - location of the settings file to determine this, and a settings file doesn't - exist if you're manually configuring your settings.) + to work out the location of the project directory. (Django normally uses + the location of the settings file to determine this, and a settings file + doesn't exist if you're manually configuring your settings.) All message file repositories are structured the same way. They are: @@ -834,12 +832,13 @@ tool as with the Django message files. You only need to be in the right place -- in the directory where either the ``conf/locale`` (in case of the source tree) or the ``locale/`` (in case of app messages or project messages) -directory are located. And you use the same ``django-admin.py compilemessages`` -to produce the binary ``django.mo`` files that are used by ``gettext``. +directory are located. And you use the same ``django-admin.py +compilemessages`` to produce the binary ``django.mo`` files that are used by +``gettext``. -You can also run ``django-admin.py compilemessages --settings=path.to.settings`` -to make the compiler process all the directories in your ``LOCALE_PATHS`` -setting. +You can also run ``django-admin.py compilemessages +--settings=path.to.settings`` to make the compiler process all the directories +in your ``LOCALE_PATHS`` setting. Application message files are a bit complicated to discover -- they need the ``LocaleMiddleware``. If you don't use the middleware, only the Django message @@ -1014,14 +1013,16 @@ You create and update the translation catalogs the same way as the other -Django translation catalogs -- with the django-admin.py makemessages tool. The -only difference is you need to provide a ``-d djangojs`` parameter, like this:: +Django translation catalogs -- with the ``django-admin.py makemessages`` tool. +The only difference is you need to provide a ``-d djangojs`` parameter, like +this:: django-admin.py makemessages -d djangojs -l de This would create or update the translation catalog for JavaScript for German. -After updating translation catalogs, just run ``django-admin.py compilemessages`` -the same way as you do with normal Django translation catalogs. +After updating translation catalogs, just run ``django-admin.py +compilemessages`` the same way as you do with normal Django translation +catalogs. Specialties of Django translation ================================== @@ -1042,10 +1043,11 @@ ``gettext`` on Windows ====================== -This is only needed for people who either want to extract message IDs or compile -message files (``.po``). Translation work itself just involves editing existing -files of this type, but if you want to create your own message files, or want to -test or compile a changed message file, you will need the ``gettext`` utilities: +This is only needed for people who either want to extract message IDs or +compile message files (``.po``). Translation work itself just involves editing +existing files of this type, but if you want to create your own message files, +or want to test or compile a changed message file, you will need the +``gettext`` utilities: * Download the following zip files from the GNOME servers http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/ or from one -- You received this message because you are subscribed to the Google Groups "Django updates" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-updates?hl=en.
