一旦你準(zhǔn)備好了翻譯，如果希望在Django中使用，那么只需要激活這些翻譯即可。

在這些功能背后，Django擁有一個(gè)靈活的模型來(lái)確定在安裝和使用應(yīng)用程序的過(guò)程中選擇使用的語(yǔ)言。

要設(shè)定一個(gè)安裝階段的語(yǔ)種偏好，請(qǐng)?jiān)O(shè)定LANGUAGE_CODE。如果其他翻譯器沒(méi)有找到一個(gè)譯文，Django將使用這個(gè)語(yǔ)種作為缺省的翻譯最終嘗試。

如果你只是想要用本地語(yǔ)言來(lái)運(yùn)行Django，并且該語(yǔ)言的語(yǔ)言文件存在，只需要簡(jiǎn)單地設(shè)置 LANGUAGE_CODE 即可。

如果要讓每一個(gè)使用者各自指定語(yǔ)言偏好，就需要使用 LocaleMiddleware 。 LocaleMiddleware 使得Django基于請(qǐng)求的數(shù)據(jù)進(jìn)行語(yǔ)言選擇，從而為每一位用戶定制內(nèi)容。 它為每一個(gè)用戶定制內(nèi)容。

使用 LocaleMiddleware 需要在 MIDDLEWARE_CLASSES 設(shè)置中增加 'django.middleware.locale.LocaleMiddleware' 。 中間件的順序是有影響的，最好按照依照以下要求：

    保證它是第一批安裝的中間件類。

    因?yàn)?LocalMiddleware 要用到session數(shù)據(jù)，所以需要放在 SessionMiddleware 之后。

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

例如， MIDDLE_CLASSES 可能會(huì)是如此：

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

LocaleMiddleware 按照如下算法確定用戶的語(yǔ)言:

•     首先，在當(dāng)前用戶的 session 的中查找django_language鍵；
•     如未找到，它會(huì)找尋一個(gè)cookie
•     還找不到的話，它會(huì)在 HTTP 請(qǐng)求頭部里查找Accept-Language， 該頭部是你的瀏覽器發(fā)送的，并且按優(yōu)先順序告訴服務(wù)器你的語(yǔ)言偏好。 Django會(huì)嘗試頭部中的每一個(gè)語(yǔ)種直到它發(fā)現(xiàn)一個(gè)可用的翻譯。
•     以上都失敗了的話, 就使用全局的 LANGUAGE_CODE 設(shè)定值。

備注：

    在上述每一處，語(yǔ)種偏好應(yīng)作為字符串，以標(biāo)準(zhǔn)的語(yǔ)種格式出現(xiàn)。 例如，巴西葡萄牙語(yǔ)是pt-br

    如果一個(gè)基本語(yǔ)種存在而亞語(yǔ)種沒(méi)有指定，Django將使用基本語(yǔ)種。 比如，如果用戶指定了 de-at （澳式德語(yǔ)）但Django只有針對(duì) de 的翻譯，那么 de 會(huì)被選用。

    只有在 LANGUAGES 設(shè)置中列出的語(yǔ)言才能被選用。 若希望將語(yǔ)言限制為所提供語(yǔ)言中的某些（因?yàn)閼?yīng)用程序并不提供所有語(yǔ)言的表示），則將 LANGUAGES 設(shè)置為所希望提供語(yǔ)言的列表，例如： 例如：

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

    上面這個(gè)例子限制了語(yǔ)言偏好只能是德語(yǔ)和英語(yǔ)（包括它們的子語(yǔ)言，如 de-ch 和 en-us ）。

    如果自定義了 LANGUAGES ，將語(yǔ)言標(biāo)記為翻譯字符串是可以的，但是，請(qǐng)不要使用 django.utils.translation 中的 gettext() （決不要在settings文件中導(dǎo)入 django.utils.translation ，因?yàn)檫@個(gè)模塊本身是依賴于settings，這樣做會(huì)導(dǎo)致無(wú)限循環(huán)），而是使用一個(gè)“虛構(gòu)的” gettext() 。

    解決方案就是使用一個(gè)“虛假的” gettext() 。以 下是一個(gè)settings文件的例子：

ugettext = lambda s: s

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

    這樣做的話， make-messages.py 仍會(huì)尋找并標(biāo)記出將要被翻譯的這些字符串，但翻譯不會(huì)在運(yùn)行時(shí)進(jìn)行，故而需要在任何使用 LANGUAGES 的代碼中用“真實(shí)的” ugettext()。

    LocaleMiddleware 只能選擇那些Django已經(jīng)提供了基礎(chǔ)翻譯的語(yǔ)言。 如果想要在應(yīng)用程序中對(duì)Django中還沒(méi)有基礎(chǔ)翻譯的語(yǔ)言提供翻譯，那么必須至少先提供該語(yǔ)言的基本的翻譯。 例如，Django使用特定的信息ID來(lái)翻譯日期和時(shí)間格式，故要讓系統(tǒng)正常工作，至少要提供這些基本的翻譯。

    以英語(yǔ)的 .po 文件為基礎(chǔ)，翻譯其中的技術(shù)相關(guān)的信息，可能還包括一些使之生效的信息。

    技術(shù)相關(guān)的信息ID很容易被認(rèn)出來(lái)：它們都是大寫的。 這些信息ID的翻譯與其他信息不同:你需要提供其對(duì)應(yīng)的本地化內(nèi)容。 例如，對(duì)于 DATETIME_FORMAT （或 DATE_FORMAT 、 TIME_FORMAT ），應(yīng)該提供希望在該語(yǔ)言中使用的格式化字符串。 格式被模板標(biāo)簽now用來(lái)識(shí)別格式字符串。

一旦LocaleMiddleware決定用戶的偏好，它會(huì)讓這個(gè)偏好作為request.LANGUAGE_CODE對(duì)每一個(gè)HttpRequest有效。請(qǐng)隨意在你的視圖代碼中讀一讀這個(gè)值。 以下是一個(gè)簡(jiǎn)單的例子：

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.")

注意，對(duì)于靜態(tài)翻譯（無(wú)中間件）而言，此語(yǔ)言在settings.LANGUAGE_CODE中，而對(duì)于動(dòng)態(tài)翻譯（中間件），它在request.LANGUAGE_CODE中。
在你自己的項(xiàng)目中使用翻譯

Django使用以下算法尋找翻譯：

•     首先，Django在該視圖所在的應(yīng)用程序文件夾中尋找 locale 目錄。 若找到所選語(yǔ)言的翻譯，則加載該翻譯。
•     第二步，Django在項(xiàng)目目錄中尋找 locale 目錄。 若找到翻譯，則加載該翻譯。
•     最后，Django使用 django/conf/locale 目錄中的基本翻譯。

以這種方式，你可以創(chuàng)建包含獨(dú)立翻譯的應(yīng)用程序，可以覆蓋項(xiàng)目中的基本翻譯。 或者，你可以創(chuàng)建一個(gè)包含幾個(gè)應(yīng)用程序的大項(xiàng)目，并將所有需要的翻譯放在一個(gè)大的項(xiàng)目信息文件中。 決定權(quán)在你手中。

所有的信息文件庫(kù)都是以同樣方式組織的： 它們是：

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

要?jiǎng)?chuàng)建信息文件，也是使用 django-admin.py makemessages.py 工具，和Django信息文件一樣。 需要做的就是進(jìn)入正確的目錄—— conf/locale （在源碼樹的情況下）或者 locale/ （在應(yīng)用程序信息或項(xiàng)目信息的情況下）所在的目錄下。 同樣地，使用 compile-messages.py 生成 gettext 需要使用的二進(jìn)制 django.mo 文件。

您亦可運(yùn)行django-admin.py compilemessages --settings=path.to.settings 來(lái)使編譯器處理所有存在于您 LOCALE_PATHS 設(shè)置中的目錄。

應(yīng)用程序信息文件稍微難以發(fā)現(xiàn)——因?yàn)樗鼈冃枰?LocaleMiddle 。如果不使用中間件，Django只會(huì)處理Django的信息文件和項(xiàng)目的信息文件。

最后，需要考慮一下翻譯文件的結(jié)構(gòu)。 若應(yīng)用程序要發(fā)放給其他用戶，應(yīng)用到其它項(xiàng)目中，可能需要使用應(yīng)用程序相關(guān)的翻譯。 但是，使用應(yīng)用程序相關(guān)的翻譯和項(xiàng)目翻譯在使用 make-messages 時(shí)會(huì)產(chǎn)生古怪的問(wèn)題。它會(huì)遍歷當(dāng)前路徑下所有的文件夾，這樣可能會(huì)把應(yīng)用消息文件里存在的消息ID重復(fù)放入項(xiàng)目消息文件中。

最容易的解決方法就是將不屬于項(xiàng)目的應(yīng)用程序（因此附帶著本身的翻譯）存儲(chǔ)在項(xiàng)目樹之外。 這樣做的話，項(xiàng)目級(jí)的 make-messages 將只會(huì)翻譯與項(xiàng)目精確相關(guān)的，而不包括那些獨(dú)立發(fā)布的應(yīng)用程序中的字符串。