From f882f3eea9c25faf7c47757e67cdb998e2a09f87 Mon Sep 17 00:00:00 2001 From: Georg Bauer Date: Tue, 11 Oct 2005 12:12:13 +0000 Subject: [PATCH] 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 --- docs/translation.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) 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 ==================================