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

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: sLANGUAGES = (  ('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//LC_MESSAGES/django.(po|mo)  $PROJECTPATH/locale//LC_MESSAGES/django.(po|mo)

所有在settings檔案中 LOCALE_PATHS 中列出的路徑以其列出的順序搜尋 /LC_MESSAGES/django.(po|mo)

  $PYTHONPATH/django/conf/locale//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 將只會翻譯與項目精確相關的，而不包括那些獨立發布的應用程式中的字串。

