Django 国际化

Middleware','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: 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 将只会翻译与项目精确相关的，而不包括那些独立发布的应用程序中的字符串。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头部信息中