Merged revisions 6442-6524 via svnmerge from [repos:django/trunk trunk].

git-svn-id: http://code.djangoproject.com/svn/django/branches/gis@6525 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/databases.txt

@@ -175,9 +175,9 @@ operators.  You will also need the `cx_Oracle`_ driver, version 4.3.1 or newer.
 .. _`cx_Oracle`: http://cx-oracle.sourceforge.net/
 
 To run ``python manage.py syncdb``, you'll need to create an Oracle database
-user with CREATE TABLE, CREATE SEQUENCE, and CREATE PROCEDURE privileges.  To
-run Django's test suite, the user also needs CREATE and DROP DATABASE and
-CREATE and DROP TABLESPACE privileges.
+user with CREATE TABLE, CREATE SEQUENCE, CREATE PROCEDURE, and CREATE TRIGGER
+privileges.  To run Django's test suite, the user also needs 
+CREATE and DROP DATABASE and CREATE and DROP TABLESPACE privileges.
 
 Connecting to the Database
 --------------------------

docs/i18n.txt

@@ -456,10 +456,13 @@ otherwise, they'll be tacked together without whitespace!
 
 .. admonition:: Mind your charset
 
-    When creating a ``.po`` file with your favorite text editor, first edit
+    When creating a PO file with your favorite text editor, first edit
     the charset line (search for ``"CHARSET"``) and set it to the charset
-    you'll be using to edit the content. Generally, utf-8 should work for most
-    languages, but ``gettext`` should handle any charset you throw at it.
+    you'll be using to edit the content. Due to the way the ``gettext`` tools
+    work internally and because we want to allow non-ASCII source strings in
+    Django's core and your applications, you **must** use UTF-8 as the encoding
+    for your PO file (this means that everybody will be using the same
+    encoding, which is important when Django processes the PO files).
 
 To reexamine all source code and templates for new translation strings and
 update all message files for **all** languages, run this::

docs/newforms.txt

@@ -2075,9 +2075,9 @@ More coming soon
 ================
 
 That's all the documentation for now. For more, see the file
-http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py
+http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms
 -- the unit tests for ``django.newforms``. This can give you a good idea of
-what's possible.
+what's possible. (Each submodule there contains separate tests.)
 
 If you're really itching to learn and use this library, please be patient.
 We're working hard on finishing both the code and documentation.

docs/request_response.txt

@@ -381,8 +381,8 @@ Methods
     ``mimetype``. Historically, the parameter was only called ``mimetype``,
     but since this is actually the value included in the HTTP ``Content-Type``
     header, it can also include the character set encoding, which makes it
-    more than just a MIME type specification. If ``mimetype`` is specifiedi
-    (not None), that value is used.  Otherwise, ``content_type`` is used. If
+    more than just a MIME type specification. If ``mimetype`` is specified
+    (not None), that value is used. Otherwise, ``content_type`` is used. If
     neither is given, the ``DEFAULT_CONTENT_TYPE`` setting is used.
 
 ``__setitem__(header, value)``

docs/templates_python.txt

@@ -316,7 +316,7 @@ optional, third positional argument, ``processors``. In this example, the
         }, [ip_address_processor])
         return t.render(c)
 
-Note::
+.. note::
     If you're using Django's ``render_to_response()`` shortcut to populate a
     template with the contents of a dictionary, your template will be passed a
     ``Context`` instance by default (not a ``RequestContext``). To use a

docs/unicode.txt

@@ -110,19 +110,22 @@ Conversion functions
 The ``django.utils.encoding`` module contains a few functions that are handy
 for converting back and forth between Unicode and bytestrings.
 
-    * ``smart_unicode(s, encoding='utf-8', errors='strict')`` converts its
-      input to a Unicode string. The ``encoding`` parameter specifies the input
-      encoding. (For example, Django uses this internally when processing form
-      input data, which might not be UTF-8 encoded.) The ``errors`` parameter
-      takes any of the values that are accepted by Python's ``unicode()``
-      function for its error handling.
+    * ``smart_unicode(s, encoding='utf-8', strings_only=False, errors='strict')``
+      converts its input to a Unicode string. The ``encoding`` parameter
+      specifies the input encoding. (For example, Django uses this internally
+      when processing form input data, which might not be UTF-8 encoded.) The
+      ``strings_only`` parameter, if set to True, will result in Python
+      numbers, booleans and ``None`` not being converted to a string (they keep
+      their original types). The ``errors`` parameter takes any of the values
+      that are accepted by Python's ``unicode()`` function for its error
+      handling.
 
       If you pass ``smart_unicode()`` an object that has a ``__unicode__``
       method, it will use that method to do the conversion.
 
-    * ``force_unicode(s, encoding='utf-8', errors='strict')`` is identical to
-      ``smart_unicode()`` in almost all cases. The difference is when the
-      first argument is a `lazy translation`_ instance. While
+    * ``force_unicode(s, encoding='utf-8', strings_only=False, errors='strict')``
+      is identical to ``smart_unicode()`` in almost all cases. The difference
+      is when the first argument is a `lazy translation`_ instance. While
       ``smart_unicode()`` preserves lazy translations, ``force_unicode()``
       forces those objects to a Unicode string (causing the translation to
       occur). Normally, you'll want to use ``smart_unicode()``. However,
@@ -132,11 +135,10 @@ for converting back and forth between Unicode and bytestrings.
 
     * ``smart_str(s, encoding='utf-8', strings_only=False, errors='strict')``
       is essentially the opposite of ``smart_unicode()``. It forces the first
-      argument to a bytestring. The ``strings_only`` parameter, if set to True,
-      will result in Python integers, booleans and ``None`` not being
-      converted to a string (they keep their original types). This is slightly
-      different semantics from Python's builtin ``str()`` function, but the
-      difference is needed in a few places within Django's internals.
+      argument to a bytestring. The ``strings_only`` parameter has the same
+      behaviour as for ``smart_unicode()`` and ``force_unicode()``. This is
+      slightly different semantics from Python's builtin ``str()`` function,
+      but the difference is needed in a few places within Django's internals.
 
 Normally, you'll only need to use ``smart_unicode()``. Call it as early as
 possible on any input data that might be either Unicode or a bytestring, and