Django在代碼和模板中對文本國際化有完整的支持，這里解釋了它怎樣工作

概覽
國際化的目標是允許單獨的Web程序以多種語言提供內容和功能
你，Django開發人員，可以通過添加少量的鉤子到你的Python代碼和模板中來達到此目的，這些鉤子稱為翻譯字符串，它們
告訴Django:"如果此文本可以用那種語言翻譯得到，這些文本應該被翻譯成最終用戶的語言"
Django根據用戶的語言選擇采用這些鉤子來翻譯Web apps
本質上，Django做兩件事情:
1，它讓開發者和模板作者指定他們apps的哪部分應該被翻譯
2，它使用這些鉤子來根據用戶的語言選擇為特別的用戶翻譯Web apps

怎樣國際化你的app:分三步
1，在你Python代碼和模板中嵌入翻譯字符串
2，用你想支持的語言得到那些字符串的翻譯
3，在你的Django設置中激活位置中間件
在幕后，Django的翻譯機器使用標準的Python自帶的gettext模塊

如果你不需要國際化
Django的國際化鉤子默認打開，這意味著在框架的某些地方有一些i18n相關的過度，如果你不使用國際化，你應該花兩秒鐘
來在你的settings文件鐘設置USE_I18N = False，如果USE_I18N設置為False，則Django將做一些優化而不是載入國際化機器
你可能將也想從你的TEMPLATE_CONTEXT_PROCESSORS設置中刪除'django.core.context_processors.i18n'

怎樣指定翻譯字符串
翻譯字符串指定了"該文本應該被翻譯"，這些字符串可以在你的Python代碼和模板中出現，標記翻譯字符串是你的責任，系
統只能翻譯它知道的字符串

用Python代碼

標準翻譯
通過使用方法_()指定翻譯字符串(是的，方法名是下劃線字符)，該方法可以在任何Python模塊全局得到，你不需要import它
在這個例子中，文本"Welcome to my site."標記為翻譯字符串:

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

方法django.utils.translation.gettext()等同于_()，這個例子和前面的一樣:

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)

(上面兩個例子中使用變量或計算值的警告是Django的翻譯-字符串-檢測工具make-messages.py不能找到這些字符串，等會介
紹make-messages更多的內容)
你傳遞給_()或gettext()的字符串可以通過Python標準命名字符串插補語法指定來采用placeholders，例如:

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

該技術讓語言專有的翻譯對placeholder文本重新排序，例如，一個英語翻譯可能為"Adrian is my name."，而西班牙翻譯可
能為"Me llamo Adrian."--在翻譯文本后面放置placeholder(名字)而不是在它之前
出于這個原因，你應該使用命名字符串插補(例如%(name)s) 而不是位置插補(例如%s或者%d)，如果你使用位置插補，翻譯將
不能重排placeholder文本

標記字符串為不操作
使用django.utils.translation.gettext_noop()方法來標記字符串為翻譯字符串而不翻譯它，字符串在后面從一個變量翻譯
如果你有常量字符串并且應該將其用源語言存儲因為他們在系統或用戶上交換的話則使用它--例如數據庫中的字符串--但是
應該在最后的可能點被及時翻譯，例如當字符串顯示給用戶時

遲翻譯
使用django.utils.translation.gettext_lazy()方法來遲翻譯字符串--當值被訪問而不是當gettext_lazy()方法被調用時
例如，為了翻譯模型的help_text，做下面的事情:

from django.utils.translation import gettext_lazy

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

這個例子中，gettext_lazy()存儲了該字符串的遲引用--而不是真實的翻譯，翻譯本身將當字符串用于字符串context時完成
例如模板在Django的admin站點渲染時
如果你不喜歡冗長的名字gettext_lazy，你可以像這樣給它別名為_(下劃線):

from django.utils.translation import gettext_lazy as _

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

在Django模型中一直使用遲翻譯，為域名和表名添加翻譯也是個好主意，這意味著在Meta類中顯式的寫verbose_name和verbo
se_name_plural選項，通過:

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')

復數形式
使用django.utils.translation.ngettext()方法來指定復數的消息，例如:

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)

ngettext使用三個參數:單一的翻譯字符串，復數形式的翻譯字符串和對象的數量(它作為count變量被傳遞給翻譯語言)

用模板代碼
在Django模板中使用翻譯使用兩個模板標簽和一個與Python代碼中稍微不同的語法，為了讓你的模板訪問這些標簽，把
{% load i18n %}放置在你的模板的頂端
{% trans %}模板標簽翻譯常量字符串或者變量內容:

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

如果你只想為翻譯標記一個值，但是稍后從一個變量翻譯它，可以使用noop選項:

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

在{% trans %}中使用模板變量式不可一的--只有單引號或雙引號的常量字符串是允許的，如果你的翻譯需要變量(placehold
ers)，使用{% blocktrans %}，例如:

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

為了翻譯模板表達式--比如使用模板過濾器--你需要在翻譯塊中綁定表達式到本地變量來使用:

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

如果你需要在一個blocktrans標簽里綁定多于一個表達式，用and分隔:

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

對于復數，用{% plural %}標簽指定單數和復數形式并在{% blocktrans %}和{% endblocktrans %}中顯示，例如:

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

內部所有的塊和內嵌翻譯使用合適的gettext/ngettext調用
每個RequestContext可以訪問兩個翻譯專有的變量:
1，LANGUAGES是元組的列表，其中第一個元素為語言代碼，第二個元素為語言名(用該語言)
2，LANGUAGE_CODE是當前用戶選擇的語言，作為字符串，例如:en-us(參考下面的"怎樣發現語言選擇")
3，LANGUAGE_BIDI是當前語言的方向，如果為True，它為從右到左的語言，例如希伯來和阿拉伯語，如果為False則它是從左
到右的語言，例如英語，法語，德語等等
如果你不使用RequestContex擴展，你可以用三個標簽得到這些值:
{% get_current_language as LANGUAGE_CODE %}
{% get_available_languages as LANGUAGES %}
{% get_current_language_bidi as LANGUAGE_BIDI %}
這些標簽也需要{% load i18n %}
翻譯鉤子也可以在任何接受常量字符串的模板塊標簽中得到，這種情況下，只需使用_()語法來指定翻譯字符串，例如:

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

這種情況下，標簽和過濾器將看到已經翻譯的字符串，所以它們不需要知道翻譯

怎樣創建語言文件
一旦你標記你的字符串來稍后翻譯，你需要寫(或者獲得)語言翻譯本身，這里解釋了它怎樣工作

消息文件
第一步是為一個新語言創建一個消息文件，消息文件是普通文本文件，它表示一個單獨的語言，保護所有可得到的翻譯字符
串以及它們應該怎樣用給定語言呈現，消息文件有一個.po文件擴展名
Django自帶一個工具bin/make-messages.py，它自動創建和維護這些文件
為了創建或更新消息文件，運行這個命令:
bin/make-messages.py -l de
這里的de是對于消息文件你想創建的語言代碼，這里的語言代碼為位置格式，例如，對巴西為pt_BR對奧地利德國則為de_AT
該腳步應該運行于下面三個地方中的一個:
1，django根目錄(不是Subversion檢出，但是通過$PYTHONPATH鏈接的或者位于該路徑其他位置的地方)
2，你的Django項目的根目錄
3，你的Django app的根目錄
該腳步運行于整個Django源代碼樹并抽出所有標記為翻譯的字符串，它在目錄conf/locale創建(或更新)消息文件，在de例子
中，文件則為conf/locale/de/LC_MESSAGES/django.po
它運行于你的項目源代碼樹或你的程序源代碼樹，它將做同樣的事情，但是位置目錄的位置為locale/LANG/LC_MESSAGES(注
意缺少conf前綴)
沒有gettext?
如果你沒有安裝gettext工具，make-messages.py將創建空文件，如果是這種情況，安裝gettext工具或者只是復制英語消息
文件(conf/locale/en/LC_MESSAGES/django.po)并使用它作為開始點，它只是一個空的翻譯文件
.po文件格式是直接的，每個.po文件保護一些元速據，例如翻譯維護者的聯系信息，但是文件的大部分內容是消息列表--簡
單的翻譯字符串和特殊語言的真實的翻譯文本映射
例如，如果你的Django app包含文本"Welcome to my site."的翻譯字符串，像這樣:

_("Welcome to my site.")

然后make-messages.py將創建一個包含下面消息片斷的.po文件:

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

一個快速的解釋:
1，msgid是翻譯字符串，它以源顯示，不要更改它
2，msgstr你放置語言專有的翻譯，它以空開始，所以更改它是你的責任，確認你在你的翻譯中保持引號
3，方便起見，每個消息包含翻譯字符串收集的文件名和行號
長消息是特殊情況，這里msgstr(或msgid)后面的第一個字符串是空字符串，內容本身則在下幾行以每行一個字符串來寫，這
些字符串直接連接，不要忘了字符串中結尾的空格，否則，它們會沒有空格連在一起
注意你的字符集
當用你最喜歡的文本編輯器創建.po文件時，首先編輯字符集行(搜索"CHARSET")并設置它為你將使用來編輯內容的字符集
通常utf-8應該為大部分語言工作，但是gettext應該處理任何你給它的字符集
運行下面的命令來為新的翻譯字符串重新檢查所有源代碼和模板并為所有語言更新所有的消息文件:
make-messages.py -a

編譯消息文件
在你創建你的消息文件之后--并且每次你更改它時--你將需要編譯它成更有效的形式，通過gettext使用，通過bin/compile
-messages.py工具完成這個
該工具對所有可得到的.po文件運行并創建.mo文件，.mo文件是優化的二進制文件來讓gettext使用，在同一目錄你可以運行
make-messages.py，像這樣運行compile-messages.py:
bin/compile-messages.py
就這樣，你的翻譯已經可以使用

Django怎樣發現語言選擇
一旦你準備了你的翻譯--或者，如果你只想使用Django自帶的翻譯--你將只需要為你的app激活翻譯
在幕后，Django有一個非常靈活的模型來決定哪個語言應該使用--安裝寬度，為特殊的用戶，或者兩者
為了設置安裝寬度的語言選擇，在你的settings文件設置LANGUAGE_CODE，Django使用該語言作為默認翻譯--如果沒有其他
翻譯者找到翻譯則作該最終嘗試
如果所有你想做的只是用你的本地語言運行Django，并且一個語言文件對你的語言可得到，所有你需要做的只是設置LANGUA
GE_CODE
如果你想讓每個單獨的用戶指定哪個語言他想選擇，使用LocaleMiddleware，LocaleMiddleware允許基于從請求的數據做語
言選擇，它為每個用戶自定義內容
為了使用LocaleMiddleware，添加'django.middleware.locale.LocaleMddleware'到你的MIDDLEWARE_CLASSES設置，因為中
間件的順序有關系，你應該遵循下列指示:
1，確認它是首先安裝的中間件中的一個
2，它應該在SessionMiddleware后面，因為LocaleMiddleware使用session數據
3，如果你使用CacheMiddleware，把LocaleMiddleware放在它后面
例如，你的MIDDLEWARE_CLASSES可能看起來像這樣:

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

LocaleMiddleware通過該算法嘗試決定用戶的語言選擇:
1，首先，它在當前用戶的session中尋找django_language鍵
2，失敗的話，它尋找叫django_language的cookie
3，失敗的話，它尋找Accept-Language HTTP頭部，該頭部通過你的瀏覽器發送并且告訴服務器你選擇哪個語言，通過優先級
排序，Django嘗試頭部中的每個語言直到它找到一個可以得到翻譯的語言
4，失敗的話，它使用全局的LANGUAGE_CODE設置
注意:
1，在這些地方中的每一個，語言選擇被期望為標準語言格式，作為一個字符擦，例如，巴西為pt-br
2，如果基本語言可以得到但是指定的子語言不能，Django使用基本語言，例如，用戶指定de-at(奧地利德國)但是Django只
有de可得到，則Django使用de
3，只有在LANGUAGES設置中列出的語言可以被選擇，如果你想限制語言選擇為提供的語言的子集(因為你的程序不提供所有這
些語言)，設置LANGUAGS為一個語言列表，例如:

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

這個例子限制可得到語言為選擇德語和英語(已經任何子語言，如de-ch或en-us)
4，如果你定義一個自定義LANGUAGES設置，和前面解釋的一樣，標記語言為翻譯字符串是可以的--但是使用"假的"gettext()
方法，而不是django.utils.translation中的，你應該從不在你的settings文件中import django.utils.translation，因為
該模塊本身依賴于settings，并且它不會導致循環import
解決方案是使用"假的"gettext()方法，這里是一個settings文件的例子:

gettext = lambda s: s

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

使用該排列，make-messages.py將仍然為翻譯尋找和標記這些字符串，但是翻譯不會在運行時發生--所以你將需要記住在真
實的gettext()中在運行時用使用LANGUAGES的代碼包裝語言
5，LocaleMiddleware只能選擇有Django提供的基本翻譯的語言，如果你想為你的沒有Django的源代碼樹中的翻譯集的程序
提供翻譯，你將想至少提供該語言的基本的翻譯，例如，Django使用技術上的消息IDs來翻譯日期和時間格式--所以你將至少
需要那些讓系統正確工作的翻譯
一個好的開始點是復制英語的.po文件并至少翻譯技術消息--可能也有驗證消息
技術消息IDs很容易識別，它們都是大寫的，你不像其他消息一樣翻譯消息ID，你對提供的英語值提供正確的本地變量，例如
使用DATETIME_FORMAT(或者DATE_FORMAT或者TIME_FORMAT)，它將為你想用你的語言使用的格式字符串，格式等同于now模板
標簽使用的格式字符串
一旦LocaleMiddleware決定了用戶的選擇，它使該選擇可以為每個請求對象作為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.")

注意，對于靜態(無中間件)翻譯，語言位于settings.LANGUAGE_CODE，對于動態(中間件)翻譯它位于request.LANGUAGE_CODE

set_language重定向視圖
方便起見，Django自帶一個視圖django.views.i18n.set_language，它設置用戶的語言選擇并重定向回到前一頁面
通過添加下列行到你的URL配置來激活該視圖:

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

(注意該例子使視圖可以在/i18n/setlang/得到)
該視圖期望通過GET方法得到，并有一個language參數設置在查詢字符串里，如果session支持是允許的，該視圖在用戶的ses
sion中保存語言選擇，否則，它在django_language cookie里保存語言選擇
在設置了語言選擇之后，Django按下面的算法重定向用戶:
1，Django在查詢字符串里查找next參數
2，如果它不存在，或者為空，Django嘗試Referer頭部中的URL
3，如果它為空--比方說如果用戶瀏覽器禁止了該頭部--然后用戶將被重定向到/(站點的根)作為退路
這里是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>

在你自己的項目中使用翻譯
Django按下面的算法查找翻譯:
1，首先，它在被調用的視圖的程序目錄查找locale目錄，如果它找到選擇語言的翻譯，則翻譯將被安裝
2，然后，它在項目目錄查找locale目錄，如它找到一個翻譯，則該翻譯將被安裝
3，最后，它在django/conf/locale檢查基本的翻譯
這種方式下，你可以寫包含自己的翻譯的程序，并且你可以在你的項目路徑中覆蓋基本翻譯，或者你可以構建一個包含一些
apps的大型項目并把所有的翻譯放置于一個巨大的項目消息文件，選擇權在你手中
注意
如果你在使用手動配置的settings，由于Django失去計算項目目錄位置的能力，項目目錄中的locale目錄將不被檢測(Django
通常使用settings文件的位置來決定這點，如果你手動配置你的settings則settings文件不存在)
所有的消息文件倉庫以同樣的方式組織，它們是:
1，$APPPATH/locale/(language)/LC_MESSAGES/django.(po|mo)
2，$PROJECTPATH/locale/(language)/LC_MESSAGES/django.(po|mo)
3，在你的settings文件中所有的在LOCALE_PATHS中列出的路徑以該順序搜索(language)/LC_MESSAGES/django.(po|mo)
4，$PYTHONPATH/django/conf/locale/(language)/LC_MESSAGES/django.(po|mo)
為了創建消息文件，你和Django消息文件使用相同的make-messages.py工具，你只需在正確的地方--在conf/locale(源代碼
樹的情況下)或者locale/(app消息或項目消息情況下)目錄所在的位置，你使用相同的compile-messages.py來生成gettext
使用的二進制django.mo文件
程序消息文件有些難以發現--它們需要LocaleMiddleware，如果你不使用該中間件，則只有Django消息文件和項目消息文件
將被處理
最后，你應該思考一下你的翻譯文件的結構，如果你的程序需要遞送給其他用戶并且將在其他項目里使用，你可能像使用app
專有的翻譯，但是使用app專有的翻譯和項目翻譯可能產生怪異的make-messages問題:make-messages將穿越當前路徑下所有
的目錄這樣可能把消息IDs放置到已經在程序消息文件的項目消息文件中
最簡單的方式是把不是項目的一部分的程序存儲在項目樹外面(這樣則攜帶它們自己的翻譯)，這種方式下，項目級別的make-
messages將只翻譯連接到你的外在項目的字符串而不是單獨發布的字符串

翻譯和JavaScript
添加翻譯到JavaScript產生一些問題:
1，JavaScript代碼不能訪問gettext實現
2，JavaScript代碼不能訪問.po或者.mo文件，它們需要通過服務器遞送
3，JavaScript的翻譯目錄應該盡可能小
Django提供這些問題的一個集成方案:它傳遞翻譯給JavaScript，所以你可以在JavaScript里調用gettext等等

javascript_catalog視圖
這些問題的主要解決方案是javascript_catalog視圖，它使用模仿gettext接口的方式發送JavaScript代碼庫，加上一個翻譯
字符串數組，這些翻譯字符串來自于程序，項目或者Django代碼，根據你在info_dict或URL里指定的東西
你像這樣來使用它:

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

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

在packages里的每個字符串應該為Python小數點包語法(和在INSTALLED_APPS里的字符串格式一樣)并且應該引用包含locale
目錄的包，如果你指定多個包，所有這些目錄合并為一個目錄，如果你有使用不同程序的字符串的JavaScript的話這很有用
你可以通過把包放在URL模式里來讓該視圖變得動態:

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

通過這個，你在URL里指定了通過'+'號分隔的包名列表，如果你的頁面使用來自于不同apps的代碼并且它經常改變并且你不
想將其放在一個大的目錄文件里的話這非常有用，出于安全考慮，這些值只能為django.conf或者INSTALLED_APPS設置中的
包

使用JavaScript翻譯目錄
為了使用該目錄，只需像這樣抽取動態生成的腳本:

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

這解釋了admin怎樣得到從服務器得到翻譯目錄，當目錄載入時，你的JavaScript代碼可以使用標準的gettext接口來訪問它

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

甚至有一個ngettext接口和一個字符串插補方法:

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

該interpolate方法支持位置插補和命名插補，所以上面的內容可以這樣寫:

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

插補語法借助于Python，你不應該總使用字符串插補:它仍然是JavaScript，所以代碼將不得不做重復的正則表達式替換，這
不像在Python中做字符串插補那么快，所以當你真正需要它時才使用它(例如，與ngettext工作來生成正確的復數形式)

創建JavaScript翻譯目錄
你使用其他Django翻譯目錄同樣的方式來創建和更新翻譯目錄--使用make-messages.py工具，唯一的區別是你需要像這樣提
供一個-d djangojs參數:

make-messages.py -d djangojs -l de

這將為德語的JavaScript創建或更新翻譯目錄，在更新翻譯目錄之后，像普通Django翻譯目錄一樣運行compile-messages.py

熟悉gettext的用戶注意
如果你了解gettext，你可能注意到Django做翻譯的這些特性:
1，字符串領域為django或者djangojs，字符串領域用來區分不同的存儲數據于通用消息文件庫(通常在/usr/share/locale/)
的程序，django領域被python和模板翻譯字符串使用并且載入到全局翻譯目錄，djangojs領域只被JavaScript翻譯目錄用來
確認它們盡可能小
2，Django只使用gettext和gettext_noop，這是因為Django內部一直使用DEFAULT_CHARSET字符串，對ugettext沒有很多使用
因為你一直需要生成utf-8
3，Django不單獨使用xgettext，它使用xgettext和msgfmt的Python包裝器，這主要是為了方便
安徽新華電腦學校專業職業規劃師為你提供更多幫助【在線咨詢】