i18n: clarified some points about app-specific translations

git-svn-id: http://code.djangoproject.com/svn/django/branches/i18n@833 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 16 insertions, 0 deletions

diff --git a/docs/translation.txt b/docs/translation.txt
index e0a6531ba8..e63009883b 100644
--- a/docs/translation.txt
+++ b/docs/translation.txt
@@ -291,6 +291,22 @@ where either the conf/locale (in case of the source tree) or the locale/
 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
+i18n middleware to be found. If you don't use the middleware, only the
+django message files and project message files will be processed.
+
+Additionally you should think about how to structure your translation
+files. If your applications should be delivered to other users and should
+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. 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 stuff that is connected to your
+explicit project and not stuff that is distributed independently.
+
 Specialities of Django Translation
 ==================================