On Sat, 2010-05-01 at 19:10 +0200, Damien Baty wrote:
> Hello Chris,
>
> Le 25/04/10 15:19, Chris McDonough a écrit :
> > BFG 1.3 will ship with internationalization and localization
> > features. [...]
> > If anyone who needs these features has a chance to provide feedback
> > on or otherwise help out on those docs, I'd be grateful.
>
> I "ported" (sic) a small application (from zope.i18n). The documentation
> is (as usual) very detailed and easy to read.
>
> One thing that struck me is the default locale negotiator: it does not
> look at the "Accept-Language" HTTP header. Fair enough, I'll write my
> own, something like:
>
> def locale_negotiator(request):
> ## Use BFG default negotiator
> locale = default_locale_negotiator(request)
> if locale is not None:
> return locale
>
> available_languages = ['fr', 'de'] ## FIXME
>
> ## No cookie, nothing in the request parameters, let's look
> ## at what the browser accepts and prefers.
> accepts = request.headers.get('Accept-Language', None)
> if not accepts:
> return None
> ## The following is probably not bullet-proof but whatever...
> for part in accepts.split(','):
> lang = part.split(';')[0].strip()
> if lang in available_languages:
> return lang
> lang = lang.split('-')[0]
> if lang in available_languages:
> return lang
> return None
>
> This is all well, but I need a list of available languages, here. As far
> as I can see, translation directories are registered when the
> application starts. Then localizers are registered on-demand when a
> particular language is requested. May I ask what is the intent behind
> this behaviour (rather than registering all localizers at startup)? It
> obviously cut down startup times: is this the only reason?
Not quite, although that is a desired side effect. This was a conscious
decision based on discussions with Hanno.
It was by design that the framework itself doesn't supply the "available
languages"; I decided to make the application itself responsible for
knowing these. The rationale is this: any particular application
deployment should know which languages it should be translatable to.
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 be
incomplete or incorrect. Or there may be translations to a language but
not for all domains. The deployment will need to be able to selectively
choose to allow only some languages even if that set of languages is
smaller than all those detected in the translation directories. The
easiest way to do that is to make the application itself responsible for
knowing which translations are allowed.
You can easily set up such a system using the settings mechanism:
In the paste .ini file:
available_languages = fr de en ru
Then in code:
from repoze.bfg.settings import get_settings
languages = get_settings()['available_languages'].split()
> If all
> localizers were registered at startup, I would be able to get a list of
> available languages with something like:
>
> [l[0] for l in registry.getUtilitiesFor(ILocalizer)]
>
> However, in the current situation, I have to 'listdir()' each
> translation directory, which looks redundant with what is done in
> "i18n.get_localizer()" to register ILocalizer utilities. Of course I
> could do that only once, when the application gets started. But isn't
> there a better way?
If it's the policy of your application that all languages that exist on
disk in registered translation dirs become available to your
application, I think doing this walk of translation directories is
appropriate. We could maybe make it easier to get this information by
adding an API.
- C
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
