Fixed #18040 -- Removed so-called project-level locale trees from the list of paths the translation loading process takes in account.

Deprecated in Django 1.3. Removed completely for Django 1.5.

Thanks Claude for the review.


git-svn-id: http://code.djangoproject.com/svn/django/trunk@17861 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 2 insertions, 22 deletions

diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index 6bb6a0c5e4..052109b72c 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -1503,18 +1503,9 @@ translations for the same literal:
 2. Then, it looks for and uses if it exists a ``locale`` directory in each
    of the installed apps listed in :setting:`INSTALLED_APPS`.  The ones
    appearing first have higher precedence than the ones appearing later.
-3. Then, it looks for a ``locale`` directory in the project directory, or
-   more accurately, in the directory containing your settings file.
-4. Finally, the Django-provided base translation in ``django/conf/locale``
+3. Finally, the Django-provided base translation in ``django/conf/locale``
    is used as a fallback.
 
-.. deprecated:: 1.3
-    Lookup in the ``locale`` subdirectory of the directory containing your
-    settings file (item 3 above) is deprecated since the 1.3 release and will be
-    removed in Django 1.5. You can use the :setting:`LOCALE_PATHS` setting
-    instead, by listing the absolute filesystem path of such ``locale``
-    directory in the setting value.
-
 .. seealso::
 
     The translations for literals included in JavaScript assets are looked up
@@ -1527,25 +1518,14 @@ be named using :term:`locale name` notation. E.g. ``de``, ``pt_BR``, ``es_AR``,
 etc.
 
 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
+you can override base translations in your project. Or, you can just build
 a big project out of several apps and put all translations into one big common
 message file specific to the project you are composing. The choice is yours.
 
-.. note::
-
-    If you're using manually configured settings, as described in
-    :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.)
-
 All message file repositories are structured the same way. They are:
 
 * All paths listed in :setting:`LOCALE_PATHS` in your settings file are
   searched for ``<language>/LC_MESSAGES/django.(po|mo)``
-* ``$PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)`` --
-  deprecated, see above.
 * ``$APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
 * ``$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)``