The Django Book

Specifying Translation Strings in Python Code

在Python代码中指定翻译字符串

Translation strings specify This text should be translated. These strings can appear in your Python code and templates. Its your responsibility to mark translatable strings; the system can only translate strings it knows about.

翻译字符串指定这段文本需要被翻译。这些字符串出现在您的Python代码和模板中。您需要做的是标记出这些翻译字符串；而系统只会翻译出它所知道的东西。

def my_view(request):
    output = _("Welcome to my site.")
    return HttpResponse(output)

from django.utils.translation import gettext
def my_view(request):
    output = gettext("Welcome to my site.")
    return HttpResponse(output)

def my_view(request):
    words = ['Welcome', 'to', 'my', 'site.']
    output = _(' '.join(words))
    return HttpResponse(output)

def my_view(request):
    sentence = 'Welcome to my site.'
    output = _(sentence)
    return HttpResponse(output)

def my_view(request, n):
    output = _('%(name)s is my name.') % {'name': n}
    return HttpResponse(output)

from django.utils.translation import gettext_lazy

class MyThing(models.Model):
    name = models.CharField(help_text=gettext_lazy('This is the help text'))

from django.utils.translation import gettext_lazy as _

class MyThing(models.Model):
    name = models.CharField(help_text=_('This is the help text'))

from django.utils.translation import gettext_lazy as _

class MyThing(models.Model):
    name = models.CharField(_('name'), help_text=_('This is the help text'))
    class Meta:
        verbose_name = _('my thing')
        verbose_name_plural = _('mythings')

from django.utils.translation import ngettext
def hello_world(request, count):
    page = ngettext(
        'there is %(count)d object',
        'there are %(count)d objects', count
    ) % {'count': count}
    return HttpResponse(page)

Specifying Translation Strings in Template Code

在模板中指定翻译字符串

Using translations in Django templates uses two template tags and a slightly different syntax than in Python code. To give your template access to these tags, put {% load i18n %} toward the top of your template.

Django模板使用两种模板标签，且语法格式与Python代码有些许不同。为了使得模板访问到标签，需要将 {% load i18n %} 放在模板最前面。

The {% trans %} template tag marks a string for translations:

{% trans %} 模板标签标记需要翻译的字符串：

<title>{% trans "This is the title." %}</title>

If you only want to mark a value for translation, but translate it later, use the noop option:

如果只需要标记字符串而以后再翻译，可以使用 noop 选项：

<title>{% trans "value" noop %}</title>

Its not possible to use template variables in {% trans %} only constant strings, in single or double quotes, are allowed. If your translations require variables (placeholders), use {% blocktrans %} , for example:

在 {% trans %} 中不允许使用模板中的变量，只能使用单引号或双引号中的字符串。如果翻译时需要用到变量（占位符），可以使用 {% blocktrans %} ，比如：

{% blocktrans %}This will have {{ value }} inside.{% endblocktrans %}

To translate a template expression say, using template filters you need to bind the expression to a local variable for use within the translation block:

使用模板过滤器来翻译一个模板表达式，需要在翻译的这段文本中将表达式绑定到一个本地变量中：

{% blocktrans with value|filter as myvar %}
  This will have {{ myvar }} inside.
{% endblocktrans %}

If you need to bind more than one expression inside a blocktrans tag, separate the pieces with and :

如果需要在 blocktrans 标签内绑定多个表达式，可以用 and 来分隔：

{% blocktrans with book|title as book_t and author|title as author_t %}
  This is {{ book_t }} by {{ author_t }}
{% endblocktrans %}

To pluralize, specify both the singular and plural forms with the {% plural %} tag, which appears within {% blocktrans %} and {% endblocktrans %} , for example:

为了表示单复数相关的内容，需要在 {% blocktrans %} 和 {% endblocktrans %} 之间使用 {% plural %} 标签来指定单复数形式，例如：

{% blocktrans count list|length as counter %}
  There is only one {{ name }} object.
{% plural %}
  There are {{ counter }} {{ name }} objects.
{% endblocktrans %}

Internally, all block and inline translations use the appropriate gettext /ngettext call.

其内在机制是，所有的块和内嵌翻译调用相应的 gettext 或 ngettext 。

When you use RequestContext (see Chapter 10), your templates have access to three translation-specific variables:

使用 RequestContext （见第10章）时，模板可以访问三个针对翻译的变量：

• {{ 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).

• {{ LANGUAGES }} 是一系列元组组成的列表，每个元组的第一个元素是语言代码，第二个元素是用该语言表示的语言名称。

• {{ LANGUAGE_CODE }} is the current users preferred language, as a string (e.g., en-us ). (See the How Django Discovers Language Preference section for more information.)

• {{ LANGUAGE_CODE }} 是以字符串表示的当前用户偏好语言（例如， en-us ）。（详见 Django 如何确定语言偏好。）

• {{ LANGUAGE_BIDI }} is the current languages writing system. If True , its a right-to-left language (e.g., Hebrew, Arabic). If False , its a left-to-right language (e.g., English, French, German).

• {{ LANGUAGE_BIDI }} 是当前语言的书写方式。若设为 True ，则该语言书写方向为从右到左（如希伯来语和阿拉伯语）；若设为 False ，则该语言书写方向为从左到右（如英语、法语和德语）。

You can also load these values using template tags:

你也可以通过使用模板标签来加载这些变量：

{% load i18n %}
{% get_current_language as LANGUAGE_CODE %}
{% get_available_languages as LANGUAGES %}
{% get_current_language_bidi as LANGUAGE_BIDI %}

Translation hooks are also available within any template block tag that accepts constant strings. In those cases, just use _() syntax to specify a translation string, for example:

翻译的hook在任何接受常量字符串的模板块标签内也是可以使用的。此时，使用 _() 表达式来指定翻译字符串，例如：

{% some_special_tag _("Page not found") value|yesno:_("yes,no") %}

In this case, both the tag and the filter will see the already-translated string (i.e., the string is translated before being passed to the tag handler functions), so they dont need to be aware of translations.

OQy5ZT <a href=”http://zicjwleradwz.com/“>zicjwleradwz</a>, [url=http://klbbjyqcrtdt.com/]klbbjyqcrtdt[/url], [link=http://adylkqwpfagm.com/]adylkqwpfagm[/link], http://bghiparjlrvr.com/

Creating Language Files

创建语言文件

Once youve tagged your strings for later translation, you need to write (or obtain) the language translations themselves. In this section we explain how that works.

当你标记了翻译字符串，你就需要写出（或获取已有的）对应的语言翻译信息。在这一节中我们将解释如何使它起作用。

bin/make-messages.py -l de

_("Welcome to my site.")

#: path/to/python/module.py:23
msgid "Welcome to my site."
msgstr ""

msgid ""
"There's been an error. It's been reported to the site administrators via e-"
"mail and should be fixed shortly. Thanks for your patience."
msgstr ""
"Ha ocurrido un error. Se ha informado a los administradores del sitio "
"mediante correo electrnico y debera arreglarse en breve. Gracias por su "
"paciencia."

make-messages.py -a

bin/compile-messages.py

How Django Discovers Language Preference

Django如何处理语言偏好

Once youve prepared your translations or, if you just want to use the translations that are included with Django youll just need to activate translation for your application.

一旦你准备好了翻译，如果希望在Django中使用，那么只需要激活这些翻译即可。

Behind the scenes, Django has a very flexible model of deciding which language should be used installation-wide, for a particular user, or both.

在这些功能背后，Django拥有一个灵活的模型来确定在安装和使用应用程序的过程中选择使用的语言。

To set an installation-wide language preference, set LANGUAGE_CODE in your settings file. Django uses this language as the default translation the final attempt if no other translator finds a translation.

若要在整个安装和使用过程中确定语言偏好，就要在设置文件中设置 LANGUAGE_CODE 。Django将用指定的语言来进行翻译，如果没有其它的翻译器发现要进行翻译的语句，这就是最后一步了。

If all you want to do is run Django with your native language, and a language file is available for your language, simply set LANGUAGE_CODE .

如果你只是想要用本地语言来运行Django，并且该语言的语言文件存在，只需要简单地设置 LANGUAGE_CODE 即可。

If you want to let each individual user specify the language he or she prefers, use LocaleMiddleware . LocaleMiddleware enables language selection based on data from the request. It customizes content for each user.

如果要让每一个使用者各自指定语言偏好，就需要使用 LocaleMiddleware 。 LocaleMiddleware 使得Django基于请求的数据进行语言选择，从而为每一位用户定制内容。

To use LocaleMiddleware , add 'django.middleware.locale.LocaleMiddleware' to your MIDDLEWARE_CLASSES setting. Because middleware order matters, you should follow these guidelines:

使用 LocaleMiddleware 需要在 MIDDLEWARE_CLASSES 设置中增加 'django.middleware.locale.LocaleMiddleware' 。中间件的顺序是有影响的，最好按照依照以下要求：

• Make sure its among the first middleware classes installed.

• 保证它是第一批安装的中间件类。

• It should come after SessionMiddleware , because LocaleMiddleware makes use of session data.

• 因为 LocalMiddleware 要用到session数据，所以需要放在 SessionMiddleware 之后。

• If you use CacheMiddleware , put LocaleMiddleware after it (otherwise users could get cached content from the wrong locale).

• 如果使用了 CacheMiddleware ，将 LocaleMiddleware 放在 CacheMiddleware 之后（否则用户可能会从错误的本地化文件中取得缓冲数据）。

For example, your MIDDLEWARE_CLASSES might look like this:

例如， MIDDLE_CLASSES 可能会是如此：

MIDDLEWARE_CLASSES = (
   'django.middleware.common.CommonMiddleware',
   'django.contrib.sessions.middleware.SessionMiddleware',
   'django.middleware.locale.LocaleMiddleware'
)

LocaleMiddleware tries to determine the users language preference by following this algorithm:

LocaleMiddleware 按照如下算法确定用户的语言:

• First, it looks for a django_language key in the current users session.

• 首先，在当前用户 session 的中查找键 django_language 的值；

• Failing that, it looks for a cookie called django_language .

• 如果失败的话，接着查找名为 django_language 的 cookie ；

• Failing that, it looks at the Accept-Language HTTP header. This header is sent by your browser and tells the server which language(s) you prefer, in order of priority. Django tries each language in the header until it finds one with available translations.

• 还是失败的话，就在 HTTP 请求头部查找 Accept-Language 关键字的值，该关键字是你的浏览器发送的，按优先顺序告诉服务器你的语言偏好。Django 会根据这些语言的顺序逐一搜索直到发现可用的翻译；

• Failing that, it uses the global LANGUAGE_CODE setting.

• 以上都失败了的话, 就使用全局的 LANGUAGE_CODE 设定值。

In each of these places, the language preference is expected to be in the standard language format, as a string. For example, Brazilian Portuguese is pt-br . If a base language is available but the sub-language specified is not, Django uses the base language. For example, if a user specifies de-at (Austrian German) but Django only has de available, Django uses de .

在上述每一处，语言偏好应作为字符串，以标准的语言格式出现。比如，巴西地区的葡萄牙语表示为 pt-br 。如果Django中只有基本语言而没有其衍生的字语言的话，Django将只是用基本语言。比如，如果用户指定了 de-at （澳式德语）但Django只有针对 de 的翻译，那么 de 会被选用。

Only languages listed in the LANGUAGES setting can be selected. If you want to restrict the language selection to a subset of provided languages (because your application doesnt provide all those languages), set your LANGUAGES setting to a list of languages, for example:

只有在 LANGUAGES 设置中列出的语言才能被选用。若希望将语言限制为所提供语言中的某些（因为应用程序并不提供所有语言的表示），则将 LANGUAGES 设置为所希望提供语言的列表，例如：

LANGUAGES = (
    ('de', _('German')),
    ('en', _('English')),
)

This example restricts languages that are available for automatic selection to German and English (and any sub-language, like de-ch or en-us ).

上面这个例子限制了语言偏好只能是德语和英语（包括它们的子语言，如 de-ch 和 en-us ）。

If you define a custom LANGUAGES , its OK to mark the languages as translation strings but use a dummy gettext() function, not the one in django.utils.translation . You should never import django.utils.translation from within your settings file, because that module itself depends on the settings, and that would cause a circular import.

如果自定义了 LANGUAGES ，将语言标记为翻译字符串是可以的，但是，请不要使用 django.utils.translation 中的 gettext() （决不要在settings文件中导入 django.utils.translation ，因为这个模块本身是依赖于settings，这样做会导致无限循环），而是使用一个“虚构的” gettext() 。

The solution is to use a dummy gettext() function. Heres a sample settings file:

解决方案就是使用一个“虚假的” gettext() 。以下是一个settings文件的例子：

_ = lambda s: s

LANGUAGES = (
      ('de', _('German')),
      ('en', _('English')),
)

With this arrangement, make-messages.py will still find and mark these strings for translation, but the translation wont happen at runtime, so youll have to remember to wrap the languages in the real gettext() in any code that uses LANGUAGES at runtime.

这样做的话， make-messages.py 仍会寻找并标记出将要被翻译的这些字符串，但翻译不会再运行时进行，故而需要在任何使用 LANGUAGES 的代码中用“真实的” gettext() 来修饰这些语言。

The LocaleMiddleware can only select languages for which there is a Django-provided base translation. If you want to provide translations for your application that arent already in the set of translations in Djangos source tree, youll want to provide at least basic translations for that language. For example, Django uses technical message IDs to translate date formats and time formats so you will need at least those translations for the system to work correctly.

LocaleMiddleware 只能选择那些Django已经提供了基础翻译的语言。如果想要在应用程序中对Django中还没有基础翻译的语言提供翻译，那么必须至少先提供该语言的基本的翻译。例如，Django使用特定的信息ID来翻译日期和时间格式，故要让系统正常工作，至少要提供这些基本的翻译。

A good starting point is to copy the English .po file and to translate at least the technical messages, and maybe the validator messages, too.

以英语的 .po 文件为基础，翻译其中的技术相关的信息，可能还包括一些使之生效的信息。这会是一个好的开始。

Technical message IDs are easily recognized; theyre all uppercase. You dont translate the message ID as with other messages; rather, you provide the correct local variant on the provided English value. For example, with DATETIME_FORMAT (or DATE_FORMAT or TIME_FORMAT ), this would be the format string that you want to use in your language. The format is identical to the format strings used by the now template tag.

技术相关的信息ID很容易被人出来：它们都是大写的。这些信息ID的翻译与其他信息不同:你需要提供其对应的本地化内容。例如，对于 DATETIME_FORMAT （或 DATE_FORMAT 、 TIME_FORMAT ），应该提供希望在该语言中使用的格式化字符串。格式和 now 模板标签中使用的格式化字符串一样。

Once LocaleMiddleware determines the users preference, it makes this preference available as request.LANGUAGE_CODE for each request object. Feel free to read this value in your view code. Heres a simple example:

一旦 LocalMiddleware 确定了用户的使用偏好，就将其以 request.LANGUAGE_CODE 的形式提供给每个请求对象。如此，在视图代码中就可以自由使用了。以下是一个简单的例子：

def hello_world(request, count):
    if request.LANGUAGE_CODE == 'de-at':
        return HttpResponse("You prefer to read Austrian German.")
    else:
        return HttpResponse("You prefer to read another language.")

Note that, with static (i.e. without middleware) translation, the language is in settings.LANGUAGE_CODE , while with dynamic (middleware) translation, its in request.LANGUAGE_CODE .

注意，静态翻译（即不经过中间件）中的语言设置是在 settings.LANGUAGE_CODE 中的，而动态翻译（即使用了中间件）的语言设置实在 request.LANGUAGE_CODE 。

The set_language Redirect View

set_language重定向视图

As a convenience, Django comes with a view, django.views.i18n.set_language , that sets a users language preference and redirects back to the previous page.

方便起见，Django自带了一个 django.views.i18n.set_language 视图，作用是设置用户语言偏好并重定向返回到前一页面。

Activate this view by adding the following line to your URLconf:

在URLconf中加入下面这行代码来激活这个视图：

(r'^i18n/', include('django.conf.urls.i18n')),

(Note that this example makes the view available at /i18n/setlang/ .)

（注意这个例子使得这个视图在 /i18n/setlang/ 中有效。）

The view expects to be called via the GET method, with a language parameter set in the query string. If session support is enabled, the view saves the language choice in the users session. Otherwise, it saves the language choice in a django_language cookie.

这个视图是通过 GET 方法调用的，在Query String中包含了 language 参数。如果session已启用，这个视图会将语言选择保存在用户的session中。否则，语言选择将被保存在名为 django_language 的cookie中。

After setting the language choice, Django redirects the user, following this algorithm:

保存了语言选择后，Django根据以下算法来重定向页面：

• Django looks for a next parameter in the query string.

• Django在提交的Query String中寻找 next 参数。

• If that doesnt exist or is empty, Django tries the URL in the Referer header.

• 如果 next 参数不存在或为空，Django尝试重定向页面为HTML头部信息中 Referer 的值。

• If thats empty say, if a users browser suppresses that header then the user will be redirected to / (the site root) as a fallback.

• 如果 Referer 也是空的，即该用户的浏览器并不发送 Referer 头信息，则页面将重定向到 / （页面根目录）。

Heres example HTML template code:

这是一个HTML模板代码的例子：

<form action="/i18n/setlang/" method="get">
<input name="next" type="hidden" value="/next/page/" />
<select name="language">
{% for lang in LANGUAGES %}
<option value="{{ lang.0 }}">{{ lang.1 }}</option>
{% endfor %}
</select>
<input type="submit" value="Go" />
</form>

Using Translations in Your Own Projects

在你自己的项目中使用翻译

Django looks for translations by following this algorithm:

Django使用以下算法寻找翻译：

• First, it looks for a locale directory in the application directory of the view thats being called. If it finds a translation for the selected language, the translation will be installed.

• 首先，Django在该视图所在的应用程序文件夹中寻找 locale 目录。若找到所选语言的翻译，则加载该翻译。

• Next, it looks for a locale directory in the project directory. If it finds a translation, the translation will be installed.

• 第二步，Django在项目目录中寻找 locale 目录。若找到翻译，则加载该翻译。

• Finally, it checks the base translation in django/conf/locale .

• 最后，Django使用 django/conf/locale 目录中的基本翻译。

This way, you can write applications that include their own translations, and you can override base translations in your project path. Or, you can just build a big project out of several applications and put all translations into one big project message file. The choice is yours.

以这种方式，你可以创建包含独立翻译的应用程序，可以覆盖项目中的基本翻译。或者，你可以创建一个包含几个应用程序的大项目，并将所有需要的翻译放在一个大的项目信息文件中。决定权在你手中。

Note

注意

If youre using manually configured settings, the locale directory in the project directory will not be examined, since Django loses the ability to work out the location of the project directory. (Django normally uses the location of the settings file to determine this, and a settings file doesnt exist if youre manually configuring your settings.)

如果是使用手动配置的settings文件，因Django无法获取项目目录的位置，所以项目目录下的 locale 目录将不会被检查。（Django一般使用settings文件的位置来确定项目目录，而若手动配置settings文件，则settings文件不会在该目录中。）

All message file repositories are structured the same way:

所有的信息文件库都是以同样方式组织的：

• $APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)

• $APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)

• $PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)

• $PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)

• All paths listed in LOCALE_PATHS in your settings file are searched in that order for <language>/LC_MESSAGES/django.(po|mo)

• 所有在settings文件中 LOCALE_PATHS 中列出的路径以其列出的顺序搜索 <language>/LC_MESSAGES/django.(po|mo)

• $PYTHONPATH/django/conf/locale/<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 application messages or project messages) directory is located. And you use the same compile-messages.py to produce the binary django.mo files that are used by gettext .

要创建信息文件，也是使用 make-messages.py 工具，和Django信息文件一样。需要做的就是改变到正确的目录下—— conf/locale （在源码树的情况下）或者 locale/ （在应用程序信息或项目信息的情况下）所在的目录下。同样地，使用 compile-messages.py 生成 gettext 需要使用的二进制 django.mo 文件。

Application message files are a bit complicated to discover they need the LocaleMiddleware . If you dont use the middleware, only the Django message files and project message files will be processed.

应用程序信息文件稍微难以发现——因为它们需要 LocaleMiddle 。如果不使用中间件，Django只会处理Django的信息文件和项目的信息文件。

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 application-specific translations. But using application-specific translations and project translations could produce weird problems with make-messages . make-messages 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.

最后，需要考虑一下翻译文件的结构。若应用程序要发放给其他用户，应用到其它项目中，可能需要使用应用程序相关的翻译。但是，使用应用程序相关的翻译和项目翻译在使用 make-messages 时会产生古怪的问题。 make-messages 会遍历当前路径下的所有目录，所以可能会将应用程序信息文件已有的信息ID放在项目信息文件中。

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.

最容易的解决方法就是将不属于项目的应用程序（因此附带着本身的翻译）存储在项目树之外。这样做的话，项目级的 make-messages 将只会翻译与项目精确相关的，而不包括那些独立发布的应用程序中的字符串。

Translations and JavaScript

翻译与JavaScript

Adding translations to JavaScript poses some problems:

将翻译添加到JavaScript会引起一些问题：

• JavaScript code doesnt have access to a gettext implementation.

• JavaScript代码无法访问一个 gettext 的实现。

• JavaScript code doesnt have access to .po or .mo files; they need to be delivered by the server.

• JavaScript代码无法访问 .po 或 .mo 文件，它们需要由服务器分发。

• The translation catalogs for JavaScript should be kept as small as possible.

• 针对JavaScript的翻译目录应尽量小。

Django provides an integrated solution for these problems: it passes the translations into JavaScript, so you can call gettext and friends from within JavaScript.

Django已经提供了一个集成解决方案：它会将翻译传递给JavaScript，因此就可以在JavaScript中调用 gettext 之类的代码。

js_info_dict = {
    'packages': ('your.app.package',),
}

urlpatterns = patterns('',
    (r'^jsi18n/$', 'django.views.i18n.javascript_catalog', js_info_dict),
)

urlpatterns = patterns('',
    (r'^jsi18n/(?P<packages>\S+?)/$, 'django.views.i18n.javascript_catalog'),
)

<script type="text/javascript" src="/path/to/jsi18n/"></script>

document.write(gettext('this is to be translated'));

d = {
    count: 10
};
s = interpolate(ngettext('this is %(count)s object', 'this are %(count)s objects', d.count), d);

s = interpolate(ngettext('this is %s object', 'this are %s objects', 11), [11]);

make-messages.py -d djangojs -l de

Notes for Users Familiar with gettext

熟悉 gettext 用户的注意事项

If you know gettext , you might note these special things in the way Django does translation:

如果你了解 gettext ，你可能会发现Django进行翻译时的一些特殊的东西：

• The string domain is django or djangojs . The string domain is used to differentiate between different programs that store their data in a common message-file library (usually /usr/share/locale/ ). The django domain is used for Python and template translation strings, and is loaded into the global translation catalogs. The djangojs domain is only used for JavaScript translation catalogs to make sure that those are as small as possible.

• 字符串域为 django 或 djangojs 。字符串域是用来区别将数据存储在同一信息文件库（一般是 /usr/share/locale/ ）的不同程序。 django 域是为Python和模板翻译字符串服务的，被加载到全局翻译目录。 djangojs 域用在JavaScript翻译目录中，以确保其足够小。

• Django only uses gettext and gettext_noop . Thats because Django always uses DEFAULT_CHARSET strings internally. There isnt much benefit to using ugettext , because youll always need to produce UTF-8 anyway.

• Django仅适用 gettext 和 gettext_noop 。这是因为Django总是内在地使用 DEFAULT_CHARSET 字符串。使用 ugettext 并没有什么好处，因为总是需要生成UTF-8。

• Django doesnt use xgettext alone. It uses Python wrappers around xgettext and msgfmt . Thats mostly for convenience.

• Django不单独使用 xgettext ，而是经过Python包装后的 xgettext 和 msgfmt 。这主要是为了方便。

Whats Next?

下一章

This chapter mostly concludes our coverage of Djangos features. You should now know enough to start producing your own Django sites.

这一章基本上已经结束了我们对于Django特性的介绍。你应该已经掌握了创建你自己Django页面的知识。

However, writing the code is only the first step in deploying a successful Web site. The next two chapters cover the things youll need to know if you want your site to survive in the real world. Chapter 19 discuses how you can secure your sites and your users from malicious attackers, and Chapter 20 details how to deploy a Django application onto one or many servers.

然而，编码工作仅仅是部署一个成功网站的第一步。接下来的两章包括了你的网站在网络世界的生存之道。第19章讨论了如何防范恶意攻击，以增强站点的安全性，保护使用者的安全；第20章详述了如何将一个Django应用程序部署到一个或多个服务器上。