1、如何指定待翻译字符串

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

from django.utils.translation import ugettext as _

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

from django.utils.translation import ugettext

def my_view(request):
    output = ugettext("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, m, d):
    output = _('Today is %(month)s %(day)s.') % {'month': m, 'day': d}
    return HttpResponse(output)

from django.utils.translation import ugettext_lazy

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

# This is fine: putting a unicode proxy into a unicode string.
u"Hello %s" % ugettext_lazy("people")

# This will not work, since you cannot insert a unicode object
# into a bytestring (nor can you insert our unicode proxy there)
"Hello %s" % ugettext_lazy("people")

from django.utils.translation import ugettext_lazy as _

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

from django.utils.translation import ugettext_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 ungettext

def hello_world(request, count):
    page = ungettext('there is %(count)d object',
        'there are %(count)d objects', count) % {
            'count': count,
        }
    return HttpResponse(page)

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

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

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

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

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

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

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

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

from django.utils.translation import string_concat
# ...
name = ugettext_lazy(u'John Lennon')
instrument = ugettext_lazy(u'guitar')
result = string_concat([name, ': ', instrument])

.. cnid:: 109


  在这种情况下，当

from django.utils.functional import allow_lazy

def fancy_utility_function(s, ...):
    # Do some conversion on string 's'
    # ...
fancy_utility_function = allow_lazy(fancy_utility_function, unicode)

2、如何创建语言文件

当你标记了翻译字符串，你就需要写出（或获取已有的）对应的语言翻译信息。 这里就是它如何工作的。

地域限制

Django不支持把你的应用本地化到一个连它自己都还没被翻译的地域。 在这种情况下，它将忽略你的翻译文件。 如果你想尝试这个并且Django支持它，你会不可避免地见到这样一个混合体––参杂着你的译文和来自Django自己的英文。 如果你的应用需要你支持一个Django中没有的地域，你将至少需要做一个Django core的最小翻译。

django-admin.py makemessages -l de

django-admin.py makemessages -l de -e txt

django-admin.py makemessages -l de -e html,txt -e xml

_("Welcome to my site.")

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

django-admin.py makemessages -a

django-admin.py compilemessages

Django如何处理语言偏好

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

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

要设定一个安装阶段的语种偏好，请设定LANGUAGE_CODE。如果其他翻译器没有找到一个译文，Django将使用这个语种作为缺省的翻译最终尝试。

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

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

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

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

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

• 如果你使用CacheMiddleware,把LocaleMiddleware放在它后面。

例如， MIDDLE_CLASSES 可能会是如此：

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

（更多关于中间件的内容，请参阅第17章）

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

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

• 如未找到，它会找寻一个cookie

• 还找不到的话，它会在 HTTP 请求头部里查找Accept-Language， 该头部是你的浏览器发送的，并且按优先顺序告诉服务器你的语言偏好。 Django会尝试头部中的每一个语种直到它发现一个可用的翻译。

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

备注：

在上述每一处，语种偏好应作为字符串，以标准的语种格式出现。 例如，巴西葡萄牙语是pt-br

如果一个基本语种存在而亚语种没有指定，Django将使用基本语种。 比如，如果用户指定了 de-at （澳式德语）但Django只有针对 de 的翻译，那么 de 会被选用。

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

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

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

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

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

ugettext = lambda s: s

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

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

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

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

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

一旦LocaleMiddleware决定用户的偏好，它会让这个偏好作为request.LANGUAGE_CODE对每一个HttpRequest有效。请随意在你的视图代码中读一读这个值。 以下是一个简单的例子：

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

注意，对于静态翻译（无中间件）而言，此语言在settings.LANGUAGE_CODE中，而对于动态翻译（中间件），它在request.LANGUAGE_CODE中。

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

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

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

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

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

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

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

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

• $PROJECTPATH/locale/<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)

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

您亦可运行django-admin.py compilemessages --settings=path.to.settings 来使编译器处理所有存在于您 LOCALE_PATHS 设置中的目录。

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

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

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

set_language 重定向视图

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

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

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

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

这个视图是通过 GET 方法调用的，在请求中包含了 language 参数。 如果session已启用，这个视图会将语言选择保存在用户的session中。 否则，它会以缺省名django_language在cookie中保存这个语言选择。(这个名字可以通过LANGUAGE_COOKIE_NAME设置来改变)

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

• Django 在 POST 数据中寻找一个 下一个 参数。

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

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

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

<form action="/i18n/setlang/" method="post">
<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>

翻译与JavaScript

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

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

• JavaScript 代码并不访问 .po或 .mo 文件；它们需要由服务器分发。

• 针对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'));

var object_cnt = 1 // or 0, or 2, or 3, ...
s = ngettext('literal for the singular case',
        'literal for the plural case', object_cnt);

function interpolate(fmt, obj, named);

fmts = ngettext('There is %s object. Remaining: %s',
        'There are %s objects. Remaining: %s', 11);
s = interpolate(fmts, [11, 20]);
// s is 'There are 11 objects. Remaining: 20'

d = {
    count: 10
    total: 50
};

fmts = ngettext('Total: %(total)s, there is %(count)s object',
'there are %(count)s of a total of %(total)s objects', d.count);
s = interpolate(fmts, d, true);

django-admin.py makemessages -d djangojs -l de

熟悉 gettext 用户的注意事项

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

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

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

Windows下的gettext

对于那些要提取消息或编译消息文件的人们来说，需要的只有这么多。翻译工作本身仅仅包含编辑这个类型的现存文件，但如果你要创建你自己的消息文件，或想要测试或编译一个更改过的消息文件，你将需要这个gettext公用程序。

• 从http://sourceforge.net/projects/gettext下载以下zip文件

  • gettext-runtime-X.bin.woe32.zip

  • gettext-tools-X.bin.woe32.zip

  • libiconv-X.bin.woe32.zip

• 在同一文件夹下展开这3个文件。（也就是 C:\Program Files\gettext-utils )

• 更新系统路径：

  • 控制面板 > 系统> 高级 > 环境变量

  • 在系统变量列表中，点击Path，点击Edit

  • 把;C:\Program Files\gettext-utils\bin加到变量值字段的末尾。

只要xgettext --version命令正常工作，你亦可使用从别处获得的gettext的二进制代码。 有些版本的0.14.4二进制代码被发现不支持这个命令。 不要试图与Django公用程序一起使用一个gettext。在一个windows命令提示窗口输入命令 `` xgettext —version ``将导致出现一个错误弹出窗口–“xgettext.exe产生错误并且将被windows关闭”。

下一章

未章 将关注于安全，如何帮助你的用户和网站远离恶意软件的攻击。