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

1 files changed, 18 insertions, 0 deletions

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`_.