在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 按照如下算法確定用戶的語言:

備注：

在上述每一處，語種偏好應作為字符串，以標準的語種格式出現。 例如，巴西葡萄牙語是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使用以下算法尋找翻譯：

以這種方式，你可以創建包含獨立翻譯的應用程序，可以覆蓋項目中的基本翻譯。 或者，你可以創建一個包含幾個應用程序的大項目，并將所有需要的翻譯放在一個大的項目信息文件中。 決定權在你手中。

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

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

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com