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