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:
@@ -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.
|
||||
|
||||
|
||||
@@ -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 ...>
|
||||
---------------------------
|
||||
|
||||
|
||||
@@ -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
|
||||
==================================
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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):
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
------------
|
||||
|
||||
Reference in New Issue
Block a user