21. INTERNATIONALIZATION AND LOCALIZATION
21.4 Obtaining the Locale Name for a Request
You |
can |
obtain |
the |
locale |
name |
related |
to |
a |
request |
by |
using |
the |
pyramid.i18n.get_locale_name() function.
1
2
3
4
from pyramid.i18n import get_locale_name
def aview(request):
locale_name = get_locale_name(request)
This returns the locale name negotiated by the currently active locale negotiator or the default locale name if the locale negotiator returns None. You can change the default locale name by changing the pyramid.default_locale_name setting; see Default Locale Name.
Once get_locale_name() is first run, the locale name is stored on the request object. Subsequent calls to get_locale_name() will return the stored locale name without invoking the locale negotiator. To avoid this caching, you can use the pyramid.i18n.negotiate_locale_name() function:
1
2
3
4
from pyramid.i18n import negotiate_locale_name
def aview(request):
locale_name = negotiate_locale_name(request)
You can also obtain the locale name related to a request using the locale_name attribute of a localizer.
1
2
3
4
5
from pyramid.i18n import get_localizer
def aview(request):
localizer = get_localizer(request) locale_name = localizer.locale_name
Obtaining the locale name as an attribute of a localizer is equivalent to obtaining a locale name by calling the get_locale_name() function.
21.5 Performing Date Formatting and Currency Formatting
Pyramid does not itself perform date and currency formatting for different locales. However, Babel can help you do this via the babel.core.Locale class. The Babel documentation for this class provides
240
21.6. CHAMELEON TEMPLATE SUPPORT FOR TRANSLATION STRINGS
minimal information about how to perform date and currency related locale operations. See Installing Babel and Lingua for information about how to install Babel.
The babel.core.Locale class requires a locale name as an argument to its constructor. You can use Pyramid APIs to obtain the locale name for a request to pass to the babel.core.Locale constructor; see Obtaining the Locale Name for a Request. For example:
1
2
3
4
5
6
from babel.core import Locale
from pyramid.i18n import get_locale_name
def aview(request):
locale_name = get_locale_name(request) locale = Locale(locale_name)
21.6 Chameleon Template Support for Translation Strings
When a translation string is used as the subject of textual rendering by a Chameleon template renderer, it will automatically be translated to the requesting user’s language if a suitable translation exists. This is true of both the ZPT and text variants of the Chameleon template renderers.
For example, in a Chameleon ZPT template, the translation string represented by “some_translation_string” in each example below will go through translation before being rendered:
1<span tal:content="some_translation_string"/>
1<span tal:replace="some_translation_string"/>
1<span>${some_translation_string}</span>
1<a tal:attributes="href some_translation_string">Click here</a>
The features represented by attributes of the i18n namespace of Chameleon will also consult the Pyramid translations. See http://chameleon.repoze.org/docs/latest/i18n.html#the-i18n-namespace.
241
21. INTERNATIONALIZATION AND LOCALIZATION
latex-note.png
Unlike when Chameleon is used outside of Pyramid, when it is used within Pyramid, it does not support use of the zope.i18n translation framework. Applications which use Pyramid should use the features documented in this chapter rather than zope.i18n.
Third party Pyramid template renderers might not provide this support out of the box and may need special code to do an equivalent. For those, you can always use the more manual translation facility described in
Performing a Translation.
21.7 Mako Pyramid I18N Support
There exists a recipe within the Pyramid Cookbook named “Mako Internationalization” which explains how to add idiomatic I18N support to Mako templates.
21.8 Localization-Related Deployment Settings
A Pyramid application will have a pyramid.default_locale_name setting. This value represents the default locale name used when the locale negotiator returns None. Pass it to the Configurator constructor at startup time:
1
2
from pyramid.config import Configurator
config = Configurator(settings={’pyramid.default_locale_name’:’de’})
You may alternately supply a pyramid.default_locale_name via an application’s .ini file:
1 |
[app:main] |
2 |
use = egg:MyProject |
3 |
pyramid.reload_templates = true |
4 |
pyramid.debug_authorization = false |
5 |
pyramid.debug_notfound = false |
6 |
pyramid.default_locale_name = de |
|
|
242
21.9. “DETECTING” AVAILABLE LANGUAGES
If this value is not supplied via the Configurator constructor or via a config file, it will default to en.
If this setting is supplied within the Pyramid application .ini file, it will be available as a settings key:
1
2
3
from pyramid.threadlocal import get_current_registry settings = get_current_registry().settings
default_locale_name = settings[’pyramid.default_locale_name’]
21.9 “Detecting” Available Languages
Other systems provide an API that returns the set of “available languages” as indicated by the union of all languages in all translation directories on disk at the time of the call to the API.
It is by design that Pyramid doesn’t supply such an API. Instead, the application itself is responsible for knowing the “available languages”. The rationale is this: any particular application deployment must always know which languages it should be translatable to anyway, regardless of which translation files are on disk.
Here’s why: it’s not a given that because translations exist in a particular language within the registered set of translation directories that this particular deployment wants to allow translation to that language. For example, some translations may exist but they may be incomplete or incorrect. Or there may be translations to a language but not for all translation domains.
Any nontrivial application deployment will always need to be able to selectively choose to allow only some languages even if that set of languages is smaller than all those detected within registered translation directories. The easiest way to allow for this is to make the application entirely responsible for knowing which languages are allowed to be translated to instead of relying on the framework to divine this information from translation directory file info.
You can set up a system to allow a deployer to select available languages based on convention by using the pyramid.settings mechanism:
Allow a deployer to modify your application’s .ini file:
1
2
3
4
[app:main]
use = egg:MyProject
# ...
available_languages = fr de en ru
Then as a part of the code of a custom locale negotiator:
243