test0908
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

added a note on what to do when app developers want to provide translations for languages where there is no django-provided base translation. 

git-svn-id: http://code.djangoproject.com/svn/django/trunk@2046 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Georg Bauer 2006-01-18 13:01:43 +00:00
parent 8f54a225a5
commit 3b98bdc240
1 changed files with 18 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/i18n.txt
View File

@ -447,6 +447,24 @@ Notes:
en-us).
.. _LANGUAGES setting: http://www.djangoproject.com/documentation/settings/#languages
* the LocaleMiddleware can only select languages for which there is a
django provided base translation. If you want to provide translations
for your application that aren't already in the set of translations
in Djangos source tree, you will want to at least provide basic
translations for that language. For example Django uses technical
message IDs to translate date formats and time formats - so you will
need at least those translations for the system to work correctly.
A good starting point is to just copy over the english ``.po`` file
and to translate at least the technical messages and maybe the validator
messages, too.
Technical message IDs are easily recognized by them being all upper case.
You don't translate the message ID as with other messages, you provide
the correct local variant on the provided english value. For example with
``DATETIME_FORMAT`` (or ``DATE_FORMAT`` or ``TIME_FORMAT``), this would
be the format string that you want to use in your language. The format
is identical to the ``now`` tag date formattings.
Once ``LocaleMiddleware`` determines the user's preference, it makes this
preference available as ``request.LANGUAGE_CODE`` for each `request object`_.