boulder-oracle-sprint: Merged rest of package to trunk [4719]

git-svn-id: http://code.djangoproject.com/svn/django/branches/boulder-oracle-sprint@4722 bcc190cf-cafb-0310-a4f2-bffc1f526a37

3 files changed, 43 insertions, 0 deletions

diff --git a/docs/fastcgi.txt b/docs/fastcgi.txt
index 1efeaf09cf..5ecaac8666 100644
--- a/docs/fastcgi.txt
+++ b/docs/fastcgi.txt
@@ -304,3 +304,14 @@ If you have access to a command shell on a Unix system, you can accomplish this
 easily by using the ``touch`` command::
 
     touch mysite.fcgi
+
+Serving admin media files
+=========================
+
+Regardless of the server and configuration you eventually decide to use, you will
+also need to give some thought to how to serve the admin media files. The
+advice given in the modpython_ documentation is also applicable in the setups
+detailed above.
+
+.. _modpython: ../modpython/#serving-the-admin-files
+
diff --git a/docs/forms.txt b/docs/forms.txt
index 8c40eeb997..f76f6d27ef 100644
--- a/docs/forms.txt
+++ b/docs/forms.txt
@@ -417,6 +417,27 @@ Here's a simple function that might drive the above form::
         form = forms.FormWrapper(manipulator, new_data, errors)
         return render_to_response('contact_form.html', {'form': form})
 
+Implementing ``flatten_data`` for custom manipulators
+------------------------------------------------------
+
+It is possible (although rarely needed) to replace the default automatically
+created manipulators on a model with your own custom manipulators. If you do
+this and you are intending to use those models in generic views, you should
+also define a ``flatten_data`` method in any ``ChangeManipulator`` replacement.
+This should act like the default ``flatten_data`` and return a dictionary
+mapping field names to their values, like so::
+
+    def flatten_data(self):
+        obj = self.original_object
+        return dict(
+            from = obj.from,
+            subject = obj.subject,
+            ...
+        )
+
+In this way, your new change manipulator will act exactly like the default
+version.
+
 ``FileField`` and ``ImageField`` special cases
 ==============================================
 
diff --git a/docs/i18n.txt b/docs/i18n.txt
index d7f5db6861..d430a56160 100644
--- a/docs/i18n.txt
+++ b/docs/i18n.txt
@@ -282,6 +282,17 @@ How to create language files
 Once you've tagged your strings for later translation, you need to write (or
 obtain) the language translations themselves. Here's how that works.
 
+.. admonition:: Locale restrictions
+
+    Django does not support localising your application into a locale for
+    which Django itself has not been translated -- it will ignore your
+    translation files. If you were to try this and Django supported it, you
+    would inevitably see a mixture of translated strings (from your
+    application) and English strings (from Django itself). If you are wanting
+    to support a locale for your application that is not already part of
+    Django, you will need to make at least a minimal translation of the Django
+    core.
+
 Message files
 -------------