mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-07-04 17:59:13 +00:00
Code Issues 32 Releases Wiki Activity

i18n: clarified some points about app-specific translations

Browse Source 
git-svn-id: http://code.djangoproject.com/svn/django/branches/i18n@833 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Georg Bauer 2005-10-11 12:12:13 +00:00
parent 22a8771572
commit f882f3eea9
1 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/translation.txt
View File

@ -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 use the same compile-messages.py to produce the binary django.mo files that
are used by gettext. 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 Specialities of Django Translation
================================== ==================================