From 3b98bdc240a743fa6f366beafe358604ec26c154 Mon Sep 17 00:00:00 2001 From: Georg Bauer Date: Wed, 18 Jan 2006 13:01:43 +0000 Subject: [PATCH] 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 --- docs/i18n.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/i18n.txt b/docs/i18n.txt index aac27b2ac5..fb49f73dc1 100644 --- a/docs/i18n.txt +++ b/docs/i18n.txt @@ -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`_.