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.
--
Damien
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
