Thanks for the answer (which does make sense indeed) and the new section
in the doc. I took the liberty of fixing a few typos there.

Le 01/05/10 20:56, Chris McDonough a écrit :
> 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.

Repoze-dev mailing list

Reply via email to