diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/contributing.txt | 2 | ||||
| -rw-r--r-- | docs/django-admin.txt | 82 | ||||
| -rw-r--r-- | docs/i18n.txt | 91 | ||||
| -rw-r--r-- | docs/man/compile-messages.1 | 40 | ||||
| -rw-r--r-- | docs/man/django-admin.1 | 23 | ||||
| -rw-r--r-- | docs/man/make-messages.1 | 62 | ||||
| -rw-r--r-- | docs/newforms.txt | 18 | ||||
| -rw-r--r-- | docs/sessions.txt | 2 | ||||
| -rw-r--r-- | docs/settings.txt | 8 |
9 files changed, 173 insertions, 155 deletions
diff --git a/docs/contributing.txt b/docs/contributing.txt index 686c440c96..61b24f4705 100644 --- a/docs/contributing.txt +++ b/docs/contributing.txt @@ -392,7 +392,7 @@ translated, here's what to do: * Create translations using the methods described in the `i18n documentation`_. * Create a diff of the ``.po`` file against the current Subversion trunk. - * Make sure that `` bin/compile-messages.py -l <lang>`` runs without + * Make sure that `` django-admin.py compilemessages -l <lang>`` runs without producing any warnings. * Attach the patch to a ticket in Django's ticket system. diff --git a/docs/django-admin.txt b/docs/django-admin.txt index 309166fe94..f5cc02ee52 100644 --- a/docs/django-admin.txt +++ b/docs/django-admin.txt @@ -85,6 +85,32 @@ your admin's index page. See `Tutorial 2`_ for more information. .. _Tutorial 2: ../tutorial02/ +cleanup +------- + +**New in Django development version** + +Can be run as a cronjob or directly to clean out old data from the database +(only expired sessions at the moment). + +compilemessages +--------------- + +**New in Django development version** + +Compiles .po files created with ``makemessages`` to .mo files for use with +the builtin gettext support. See the `i18n documentation`_ for details. + +--locale +~~~~~~~~ + +Use the ``--locale`` or ``-l`` option to specify the locale to process. +If not provided all locales are processed. + +Example usage:: + + django-admin.py compilemessages --locale=br_PT + createcachetable <tablename> ---------------------------- @@ -362,6 +388,62 @@ Example usage:: django-admin.py loaddata --verbosity=2 +makemessages +------------ + +**New in Django development version** + +Runs over the entire source tree of the current directory and pulls out all +strings marked for translation. It creates (or updates) a message file in the +conf/locale (in the django tree) or locale (for project and application) +directory. After making changes to the messages files you need to compile them +with ``compilemessages`` for use with the builtin gettext support. See the +`i18n documentation`_ for details. + +.. _i18n documentation: ../i18n/#how-to-create-language-files + +--all +~~~~~ + +Use the ``--all`` or ``-a`` option to update the message files for all +available languages. + +Example usage:: + + django-admin.py makemessages --all + +--locale +~~~~~~~~ + +Use the ``--locale`` or ``-l`` option to specify the locale to process. + +Example usage:: + + django-admin.py makemessages --locale=br_PT + +--domain +~~~~~~~~ + +Use the ``--domain`` or ``-d`` option to change the domain of the messages files. +Currently supported: + + * ``django`` for all ``*.py`` and ``*.html`` files (default) + * ``djangojs`` for ``*.js`` files + +--verbosity +~~~~~~~~~~~ + +Use ``--verbosity`` or ``-v`` to specify the amount of notification and debug +information that ``django-admin.py`` should print to the console. + + * ``0`` means no output. + * ``1`` means normal output (default). + * ``2`` means verbose output. + +Example usage:: + + django-admin.py makemessages --verbosity=2 + reset <appname appname ...> --------------------------- diff --git a/docs/i18n.txt b/docs/i18n.txt index d6c86e1c9d..c221b43718 100644 --- a/docs/i18n.txt +++ b/docs/i18n.txt @@ -122,8 +122,8 @@ Translation works on variables. Again, here's an identical example:: (The caveat with using variables or computed values, as in the previous two examples, is that Django's translation-string-detecting utility, -``make-messages.py``, won't be able to find these strings. More on -``make-messages`` later.) +``django-admin.py makemessages``, won't be able to find these strings. More on +``makemessages`` later.) The strings you pass to ``_()`` or ``ugettext()`` can take placeholders, specified with Python's standard named-string interpolation syntax. Example:: @@ -266,10 +266,11 @@ Internally, all block and inline translations use the appropriate Each ``RequestContext`` has access to three translation-specific variables: * ``LANGUAGES`` is a list of tuples in which the first element is the - language code and the second is the language name (in that language). + language code and the second is the language name (translated into the + currently active locale). * ``LANGUAGE_CODE`` is the current user's preferred language, as a string. Example: ``en-us``. (See "How language preference is discovered", below.) - * ``LANGUAGE_BIDI`` is the current language's direction. If True, it's a + * ``LANGUAGE_BIDI`` is the current locale's direction. If True, it's a right-to-left language, e.g: Hebrew, Arabic. If False it's a left-to-right language, e.g: English, French, German etc. @@ -392,12 +393,17 @@ file is a plain-text file, representing a single language, that contains all available translation strings and how they should be represented in the given language. Message files have a ``.po`` file extension. -Django comes with a tool, ``bin/make-messages.py``, that automates the creation -and upkeep of these files. +Django comes with a tool, ``django-admin.py makemessages``, that automates the +creation and upkeep of these files. + +.. admonition:: A note to Django veterans + + The old tool ``bin/make-messages.py`` has been moved to the command + ``django-admin.py makemessages`` to provide consistency throughout Django. To create or update a message file, run this command:: - bin/make-messages.py -l de + django-admin.py makemessages -l de ...where ``de`` is the language code for the message file you want to create. The language code, in this case, is in locale format. For example, it's @@ -422,11 +428,11 @@ do the same, but the location of the locale directory is ``locale/LANG/LC_MESSAG .. admonition:: No gettext? - If you don't have the ``gettext`` utilities installed, ``make-messages.py`` - will create empty files. If that's the case, either install the ``gettext`` - utilities or just copy the English message file - (``conf/locale/en/LC_MESSAGES/django.po``) and use it as a starting point; - it's just an empty translation file. + If you don't have the ``gettext`` utilities installed, + ``django-admin.py makemessages`` will create empty files. If that's the + case, either install the ``gettext`` utilities or just copy the English + message file (``conf/locale/en/LC_MESSAGES/django.po``) and use it as a + starting point; it's just an empty translation file. The format of ``.po`` files is straightforward. Each ``.po`` file contains a small bit of metadata, such as the translation maintainer's contact @@ -439,8 +445,8 @@ For example, if your Django app contained a translation string for the text _("Welcome to my site.") -...then ``make-messages.py`` will have created a ``.po`` file containing the -following snippet -- a message:: +...then ``django-admin.py makemessages`` will have created a ``.po`` file +containing the following snippet -- a message:: #: path/to/python/module.py:23 msgid "Welcome to my site." @@ -475,24 +481,30 @@ otherwise, they'll be tacked together without whitespace! To reexamine all source code and templates for new translation strings and update all message files for **all** languages, run this:: - make-messages.py -a + django-admin.py makemessages -a Compiling message files ----------------------- After you create your message file -- and each time you make changes to it -- you'll need to compile it into a more efficient form, for use by ``gettext``. -Do this with the ``bin/compile-messages.py`` utility. +Do this with the ``django-admin.py compilemessages`` utility. This tool runs over all available ``.po`` files and creates ``.mo`` files, which are binary files optimized for use by ``gettext``. In the same directory -from which you ran ``make-messages.py``, run ``compile-messages.py`` like -this:: +from which you ran ``django-admin.py makemessages``, run +``django-admin.py compilemessages`` like this:: - bin/compile-messages.py + django-admin.py compilemessages That's it. Your translations are ready for use. +.. admonition:: A note to Django veterans + + The old tool ``bin/compile-messages.py`` has been moved to the command + ``django-admin.py compilemessages`` to provide consistency throughout + Django. + .. admonition:: A note to translators If you've created a translation in a language Django doesn't yet support, @@ -597,9 +609,9 @@ Notes: ('en', ugettext('English')), ) - With this arrangement, ``make-messages.py`` will still find and mark - these strings for translation, but the translation won't happen at - runtime -- so you'll have to remember to wrap the languages in the *real* + With this arrangement, ``django-admin.py makemessages`` will still find + and mark these strings for translation, but the translation won't happen + at runtime -- so you'll have to remember to wrap the languages in the *real* ``ugettext()`` in any code that uses ``LANGUAGES`` at runtime. * The ``LocaleMiddleware`` can only select languages for which there is a @@ -676,15 +688,16 @@ All message file repositories are structured the same way. They are: searched in that order for ``<language>/LC_MESSAGES/django.(po|mo)`` * ``$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)`` -To create message files, you use the same ``make-messages.py`` tool as with the -Django message files. You only need to be in the right place -- in the directory -where either the ``conf/locale`` (in case of the source tree) or the ``locale/`` -(in case of app messages or project messages) directory are located. And you -use the same ``compile-messages.py`` to produce the binary ``django.mo`` files -that are used by ``gettext``. +To create message files, you use the same ``django-admin.py makemessages`` +tool as with the Django message files. You only need to be in the right place +-- in the directory where either the ``conf/locale`` (in case of the source +tree) or the ``locale/`` (in case of app messages or project messages) +directory are located. And you use the same ``django-admin.py compilemessages`` +to produce the binary ``django.mo`` files that are used by ``gettext``. -You can also run ``compile-message.py --settings=path.to.settings`` to make -the compiler process all the directories in your ``LOCALE_PATHS`` setting. +You can also run ``django-admin.py compilemessages --settings=path.to.settings`` +to make the compiler process all the directories in your ``LOCALE_PATHS`` +setting. Application message files are a bit complicated to discover -- they need the ``LocaleMiddleware``. If you don't use the middleware, only the Django message @@ -694,15 +707,15 @@ Finally, you should give some thought to the structure of your translation files. If your applications need to be delivered to other users and will be used in other projects, you might want to use app-specific translations. But using app-specific translations and project translations could produce -weird problems with ``make-messages``: ``make-messages`` will traverse all +weird problems with ``makemessages``: ``makemessages`` will traverse all directories below the current path and so might put message IDs into the project message file that are already in application message files. The easiest way out is to store applications that are not part of the project (and so carry their own translations) outside the project tree. That way, -``make-messages`` on the project level will only translate strings that are -connected to your explicit project and not strings that are distributed -independently. +``django-admin.py makemessages`` on the project level will only translate +strings that are connected to your explicit project and not strings that are +distributed independently. The ``set_language`` redirect view ================================== @@ -857,14 +870,14 @@ Creating JavaScript translation catalogs ---------------------------------------- You create and update the translation catalogs the same way as the other -Django translation catalogs -- with the make-messages.py tool. The only -difference is you need to provide a ``-d djangojs`` parameter, like this:: +Django translation catalogs -- with the django-admin.py makemessages tool. The +only difference is you need to provide a ``-d djangojs`` parameter, like this:: - make-messages.py -d djangojs -l de + django-admin.py makemessages -d djangojs -l de This would create or update the translation catalog for JavaScript for German. -After updating translation catalogs, just run ``compile-messages.py`` the same -way as you do with normal Django translation catalogs. +After updating translation catalogs, just run ``django-admin.py compilemessages`` +the same way as you do with normal Django translation catalogs. Specialties of Django translation ================================== diff --git a/docs/man/compile-messages.1 b/docs/man/compile-messages.1 deleted file mode 100644 index d26a94aca7..0000000000 --- a/docs/man/compile-messages.1 +++ /dev/null @@ -1,40 +0,0 @@ -.TH "compile-messages.py" "1" "August 2007" "Django Project" "" -.SH "NAME" -compile-messages.py \- Internationalization utility for the Django -web framework -.SH "SYNOPSIS" -.B compile-messages.py \fR[-l <locale>] - -.SH "DESCRIPTION" -A Django-customised wrapper around gettext's \fBmsgfmt\fR command. Generates -binary message catalogs (.mo files) from textual translation descriptions (.po -files). -.sp -The script should be invoked after running -.BI make-messages.py, -in the same directory from which -.BI make-messages.py -was invoked. - -.SH "OPTIONS" -.TP -.I \-l <locale> -Compile the message catalogs for a specific locale. If this option is omitted, -all message catalogs are (re-)compiled. - -.SH "SEE ALSO" -The man page for -.BI msgfmt -from the GNU gettext utilities, and the internationalization documentation -for Django: -.sp -.I http://www.djangoproject.com/documentation/i18n/ - -.SH "AUTHORS/CREDITS" -Originally developed at World Online in Lawrence, Kansas, USA. Refer to the -AUTHORS file in the Django distribution for contributors. - -.SH "LICENSE" -New BSD license. For the full license text refer to the LICENSE file in the -Django distribution. - diff --git a/docs/man/django-admin.1 b/docs/man/django-admin.1 index fec5053ccb..c482a3fc6e 100644 --- a/docs/man/django-admin.1 +++ b/docs/man/django-admin.1 @@ -1,4 +1,4 @@ -.TH "django-admin.py" "1" "June 2007" "Django Project" "" +.TH "django-admin.py" "1" "March 2008" "Django Project" "" .SH "NAME" django\-admin.py \- Utility script for the Django web framework .SH "SYNOPSIS" @@ -21,6 +21,12 @@ script found at the top level of each Django project directory. .BI "adminindex [" "appname ..." "]" Prints the admin\-index template snippet for the given app name(s). .TP +.BI cleanup +Cleans out old data from the database (only expired sessions at the moment). +.TP +.BI "compilemessages [" "\-\-locale=LOCALE" "]" +Compiles .po files to .mo files for use with builtin gettext support. +.TP .BI "createcachetable [" "tablename" "]" Creates the table needed to use the SQL cache backend .TP @@ -43,6 +49,11 @@ Executes .B sqlall for the given app(s) in the current database. .TP +.BI "makemessages [" "\-\-locale=LOCALE" "] [" "\-\-domain=DOMAIN" "] [" "\-\-all" "]" +Runs over the entire source tree of the current directory and pulls out all +strings marked for translation. It creates (or updates) a message file in the +conf/locale (in the django tree) or locale (for project and application) directory. +.TP .BI "reset [" "appname ..." "]" Executes .B sqlreset @@ -136,7 +147,15 @@ Verbosity level: 0=minimal output, 1=normal output, 2=all output. .TP .I \-\-adminmedia=ADMIN_MEDIA_PATH Specifies the directory from which to serve admin media when using the development server. - +.TP +.I \-l, \-\-locale=LOCALE +The locale to process when using makemessages or compilemessages. +.TP +.I \-d, \-\-domain=DOMAIN +The domain of the message files (default: "django") when using makemessages. +.TP +.I \-a, \-\-all +Process all available locales when using makemessages. .SH "ENVIRONMENT" .TP .I DJANGO_SETTINGS_MODULE diff --git a/docs/man/make-messages.1 b/docs/man/make-messages.1 deleted file mode 100644 index b8c83dcff5..0000000000 --- a/docs/man/make-messages.1 +++ /dev/null @@ -1,62 +0,0 @@ -.TH "make-messages.py" "1" "August 2007" "Django Project" "" -.SH "NAME" -make-messages.py \- Internationalization utility for the Django -web framework -.SH "SYNOPSIS" -.B make-messages.py\fR [\-a] [\-v] [\-l <locale>] [\-d <domain>] - -.SH "DESCRIPTION" -This script creates or updates one or more message files for a Django app, -a Django project or the Django framework itself. It should be run from one -of three places: the root directory of a Django app; the root directory -of a Django project; or the root django directory (the one in your PYTHONPATH, -not the root of a Subversion checkout). -.sp -The script will run over the source tree of an application, project or Django -itself (depending on where it is invoked), pulling out all strings marked for -translation and creating or updating a standard PO-format message file for the -specified language. Refer to Django's internationalization documentation for -details of where this file is created. -.sp -The \fI\-a\fR and \fI\-l\fR options are used to control whether message -catalogs are created for all locales, or just a single one. - -.SH "OPTIONS" -.TP -.I \-a -Run make-messages for all locales specified in the Django settings file. Cannot -be used in conjuntion with \fI\-l\fR. -.TP -.I \-d <domain> -Specifies the translation domain to use. Valid domains are \fIdjango\fR or -\fIdjangojs\fR, depending on whether you wish to generate translation strings -for the Python or JavaScript components of your app, your project or the -framework itself. The default domain is \fIdjango\fR. -.TP -.I \-l <locale> -Extract messages for a particular locale. -.TP -.I \-v -Run verbosely. - -.SH "ENVIRONMENT" -.TP -.I DJANGO_SETTINGS_MODULE -This environment variable defines the settings module to be read. -It should be in Python-import form, e.g. "myproject.settings". - -.SH "SEE ALSO" -The Django internationalization documentation: -.sp -.I http://www.djangoproject.com/documentation/i18n/ -.sp -The PO file format is documented in the GNU gettext documentation. - -.SH "AUTHORS/CREDITS" -Originally developed at World Online in Lawrence, Kansas, USA. Refer to the -AUTHORS file in the Django distribution for contributors. - -.SH "LICENSE" -New BSD license. For the full license text refer to the LICENSE file in the -Django distribution. - diff --git a/docs/newforms.txt b/docs/newforms.txt index be3a0b6a2a..824bdb7ea1 100644 --- a/docs/newforms.txt +++ b/docs/newforms.txt @@ -1348,7 +1348,7 @@ An ``UploadedFile`` object has two attributes: The string representation of an ``UploadedFile`` is the same as the filename attribute. -When you use a ``FileField`` on a form, you must also remember to +When you use a ``FileField`` in a form, you must also remember to `bind the file data to the form`_. .. _`bind the file data to the form`: `Binding uploaded files to a form`_ @@ -1415,7 +1415,7 @@ These control the range of values permitted in the field. Using an ImageField requires that the `Python Imaging Library`_ is installed. -When you use a ``FileField`` on a form, you must also remember to +When you use an ``ImageField`` in a form, you must also remember to `bind the file data to the form`_. .. _Python Imaging Library: http://www.pythonware.com/products/pil/ @@ -1820,15 +1820,21 @@ reuse certain sets of widget attributes over and over again. Rather than repeat these attribute definitions every time you need them, Django allows you to capture those definitions as a custom widget. -For example, if you find that you are including a lot of comment fields on forms, -you could capture the idea of a ``TextInput`` with a specific ``size`` attribute -as a custom extension to the ``TextInput`` widget:: +For example, if you find that you are including a lot of comment fields on +forms, you could capture the idea of a ``TextInput`` with a specific +default ``size`` attribute as a custom extension to the ``TextInput`` widget:: class CommentWidget(forms.TextInput): def __init__(self, *args, **kwargs): - kwargs.setdefault('attrs',{}).update({'size': '40'}) + attrs = kwargs.setdefault('attrs',{}) + if 'size' not in attrs: + attrs['size'] = 40 super(CommentWidget, self).__init__(*args, **kwargs) +We allow the ``size`` attribute to be overridden by the user, but, by default, +this widget will behave as if ``attrs={'size': 40}`` was always passed into the +constructor. + Then you can use this widget in your forms:: class CommentForm(forms.Form): diff --git a/docs/sessions.txt b/docs/sessions.txt index 0c47f0deed..648832b85d 100644 --- a/docs/sessions.txt +++ b/docs/sessions.txt @@ -349,7 +349,7 @@ table. Django updates this row each time the session data changes. If the user logs out manually, Django deletes the row. But if the user does *not* log out, the row never gets deleted. -Django provides a sample clean-up script in ``django/bin/daily_cleanup.py``. +Django provides a sample clean-up script in ``django-admin.py cleanup``. That script deletes any session in the session table whose ``expire_date`` is in the past -- but your application may have different requirements. diff --git a/docs/settings.txt b/docs/settings.txt index a68d2ff92f..4566eea1f9 100644 --- a/docs/settings.txt +++ b/docs/settings.txt @@ -682,10 +682,10 @@ settings file:: ('en', gettext('English')), ) -With this arrangement, ``make-messages.py`` will still find and mark these -strings for translation, but the translation won't happen at runtime -- so -you'll have to remember to wrap the languages in the *real* ``gettext()`` in -any code that uses ``LANGUAGES`` at runtime. +With this arrangement, ``django-admin.py makemessages`` will still find and +mark these strings for translation, but the translation won't happen at +runtime -- so you'll have to remember to wrap the languages in the *real* +``gettext()`` in any code that uses ``LANGUAGES`` at runtime. LOCALE_PATHS ------------ |