1
0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00

newforms-admin: Merged from trunk up to [7852].

git-svn-id: http://code.djangoproject.com/svn/django/branches/newforms-admin@7853 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Brian Rosner
2008-07-06 15:23:24 +00:00
parent 058a190a79
commit 8c8513281e
33 changed files with 559 additions and 503 deletions

View File

@@ -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.

View File

@@ -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 ...>
---------------------------

View File

@@ -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
==================================

View File

@@ -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.

View File

@@ -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

View File

@@ -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.

View File

@@ -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):

View File

@@ -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.

View File

@@ -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
------------