Changeset 6294

Timestamp:

09/15/07 12:32:53 (1 year ago)

Author:

adrian

Message:

Fixed #5495 -- Made some organization / spelling / grammar changes to docs/i18n.txt. Thanks, Axis_of_Entropy

Files:

• django/trunk/docs/i18n.txt (modified) (14 diffs)

django/trunk/docs/i18n.txt

@@ -28 +28 @@
-      to their language preferences.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
-
-Django's internationalization hooks are on by default, and that means there's a
@@ -56 +43 @@
-.. _documentation for USE_I18N: ../settings/#use-i18n
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-Translation strings specify "This text should be translated." These strings can
@@ -296 +296 @@
-
-Working with lazy translation objects
-
+
-
-Using ``ugettext_lazy()`` and ``ungettext_lazy()`` to mark strings in models
@@ -306 +306 @@
-
-Joining strings: string_concat()
-
+
-
-Standard Python string joins (``''.join([...])``) will not work on lists
@@ -325 +325 @@
-
-The allow_lazy() decorator
-
+
-
-Django offers many utility functions (particularly in ``django.utils``) that
@@ -360 +360 @@
-end.
-
-
-
+2. 
+===
-
-Once you've tagged your strings for later translation, you need to write (or
@@ -394 +394 @@
-...where ``de`` is the language code for the message file you want to create.
-The language code, in this case, is in locale format. For example, it's
-
+u
-
-The script should be run from one of three places:
@@ -491 +491 @@
-    .. _Submitting and maintaining translations: ../contributing/
-
-
-
+3. 
+===
-
-Once you've prepared your translations -- or, if you just want to use the
@@ -547 +547 @@
-
-    * In each of these places, the language preference is expected to be in the
-
+u
-      is ``pt-br``.
-    * If a base language is available but the sublanguage specified is not,
@@ -630 +630 @@
-.. _request object: ../request_response/#httprequest-objects
-
+Using translations in your own projects
+=======================================
+
+Django looks for translations by following this algorithm:
+
+    * First, it looks for a ``locale`` directory in the application directory
+      of the view that's being called. If it finds a translation for the
+      selected language, the translation will be installed.
+    * Next, it looks for a ``locale`` directory in the project directory. If it
+      finds a translation, the translation will be installed.
+    * Finally, it checks the base translation in ``django/conf/locale``.
+
+This way, you can write applications that include their own translations, and
+you can override base translations in your project path. Or, you can just build
+a big project out of several apps and put all translations into one big project
+message file. The choice is yours.
+
+.. note::
+
+    If you're using manually configured settings, as described in the
+    `settings documentation`_, 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.)
+
+.. _settings documentation: ../settings/#using-settings-without-the-django-settings-module-environment-variable
+
+All message file repositories are structured the same way. They are:
+
+    * ``$APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
+    * ``$PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
+    * All paths listed in ``LOCALE_PATHS`` in your settings file are
+      searched in that order for ``<language>/LC_MESSAGES/django.(po|mo)``
+    * ``$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)``
+
+To create message files, you use the same ``make-messages.py`` 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 ``compile-messages.py`` to produce the binary ``django.mo`` files that
+are used by ``gettext``.
+
+Application message files are a bit complicated to discover -- they need the
+``LocaleMiddleware``. If you don't use the middleware, only the Django message
+files and project message files will be processed.
+
+Finally, you should give some thought to the structure of your translation
+files. If your applications need to be delivered to other users and will
+be used in other projects, you might want to use app-specific translations.
+But using app-specific translations and project translations could produce
+weird problems with ``make-messages``: ``make-messages`` will traverse all
+directories below the current path and so might put message IDs into the
+project message file that are already in application message files.
+
+The easiest way out is to store applications that are not part of the project
+(and so carry their own translations) outside the project tree. That way,
+``make-messages`` on the project level will only translate strings that are
+connected to your explicit project and not strings that are distributed
+independently.
+
-The ``set_language`` redirect view
-==================================
@@ -652 +713 @@
-    * Django looks for a ``next`` parameter in ``POST`` request.
-    * If that doesn't exist, or is empty, Django tries the URL in the
-
+r
-    * If that's empty -- say, if a user's browser suppresses that header --
-      then the user will be redirected to ``/`` (the site root) as a fallback.
@@ -668 +729 @@
-    </form>
-
-Using translations in your own projects
-=======================================
-
-Django looks for translations by following this algorithm:
-
-    * First, it looks for a ``locale`` directory in the application directory
-      of the view that's being called. If it finds a translation for the
-      selected language, the translation will be installed.
-    * Next, it looks for a ``locale`` directory in the project directory. If it
-      finds a translation, the translation will be installed.
-    * Finally, it checks the base translation in ``django/conf/locale``.
-
-This way, you can write applications that include their own translations, and
-you can override base translations in your project path. Or, you can just build
-a big project out of several apps and put all translations into one big project
-message file. The choice is yours.
-
-.. note::
-
-    If you're using manually configured settings, as described in the
-    `settings documentation`_, 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.)
-
-.. _settings documentation: ../settings/#using-settings-without-the-django-settings-module-environment-variable
-
-All message file repositories are structured the same way. They are:
-
-    * ``$APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
-    * ``$PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
-    * All paths listed in ``LOCALE_PATHS`` in your settings file are
-      searched in that order for ``<language>/LC_MESSAGES/django.(po|mo)``
-    * ``$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)``
-
-To create message files, you use the same ``make-messages.py`` 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 ``compile-messages.py`` to produce the binary ``django.mo`` files that
-are used by ``gettext``.
-
-Application message files are a bit complicated to discover -- they need the
-``LocaleMiddleware``. If you don't use the middleware, only the Django message
-files and project message files will be processed.
-
-Finally, you should give some thought to the structure of your translation
-files. If your applications need to be delivered to other users and will
-be used in other projects, you might want to use app-specific translations.
-But using app-specific translations and project translations could produce
-weird problems with ``make-messages``: ``make-messages`` will traverse all
-directories below the current path and so might put message IDs into the
-project message file that are already in application message files.
-
-The easiest way out is to store applications that are not part of the project
-(and so carry their own translations) outside the project tree. That way,
-``make-messages`` on the project level will only translate strings that are
-connected to your explicit project and not strings that are distributed
-independently.
-
-Translations and JavaScript
-===========================
@@ -828 +828 @@
-way as you do with normal Django translation catalogs.
-
-i
+
-==================================
-
-i
+
-does translation:
-
-e
+is
-      used to differentiate between different programs that store their data
-      in a common message-file library (usually ``/usr/share/locale/``). The
@@ -842 +842 @@
-      that those are as small as possible.
-    * Django doesn't use ``xgettext`` alone. It uses Python wrappers around
-at'
-
+is i
+