diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/databases.txt | 6 | ||||
| -rw-r--r-- | docs/i18n.txt | 9 | ||||
| -rw-r--r-- | docs/newforms.txt | 4 | ||||
| -rw-r--r-- | docs/request_response.txt | 4 | ||||
| -rw-r--r-- | docs/templates_python.txt | 2 | ||||
| -rw-r--r-- | docs/unicode.txt | 30 |
6 files changed, 30 insertions, 25 deletions
diff --git a/docs/databases.txt b/docs/databases.txt index 4d8824aa3d..213c2d666c 100644 --- a/docs/databases.txt +++ b/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 -------------------------- diff --git a/docs/i18n.txt b/docs/i18n.txt index bf73c88008..2c43e7884e 100644 --- a/docs/i18n.txt +++ b/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:: diff --git a/docs/newforms.txt b/docs/newforms.txt index 11e19e847f..2005adeec8 100644 --- a/docs/newforms.txt +++ b/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. diff --git a/docs/request_response.txt b/docs/request_response.txt index 7806886841..8da00cdf09 100644 --- a/docs/request_response.txt +++ b/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)`` diff --git a/docs/templates_python.txt b/docs/templates_python.txt index b6173ad39a..bd105888ce 100644 --- a/docs/templates_python.txt +++ b/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 diff --git a/docs/unicode.txt b/docs/unicode.txt index 1ab255970c..a0e2648f57 100644 --- a/docs/unicode.txt +++ b/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 |