[Zope3-dev] Re: Zope 2.9 and Zope 3 i18n, more questions...

[Philipp von Weitershausen]

Chris Withers wrote:
> I need to write a language extractor thats returns the language
> specified in an attribute of the currently logged in user or defaults to
> the normal browser extraction. Has anyone done this before? If not, any
> pointers?

You would inherit from the default implementation in
zope.publisher.browser.BrowserLanguages and override
getPreferredLanguages. Inside I presume you would get the current user
in the Zope 2 manner, getSecurityManager().getUser(), and do your
checks. If that won't lead to anything, you can simply return
super(...).getPreferredLanguages() to default to browser languages.

> I used the following to translate some code inside python scripts:
> 
> from Products.PageTemplates.GlobalTranslationService import \
>       getGlobalTranslationService
> ts = getGlobalTranslationService()
> ts.translate(domain,
>              msgid,
>              context=self,
>              target_language=target_language,
>              default=default)
> 
> What's the equivalent in Z3 land or should I be looking to turn all
> calls to the above into MessageID's? If I do, when and how do they get
> translated?

1) We usually don't do manual translation in Python

2) Instead we mark all user strings ("messages") as i18n messages (using
zope.i18nmessageid.MessageFactory). That also helps the automatic
extraction utility to find them.

3) Since most messages end up being inserted into PageTemplates anyway,
they will be translated there. The idea is that ZPT already detected
when something is an i18n message and translates it automatically (all
the i18n info such as domain, mapping, etc. is intrinsic to the message
object). I think that should even work in Zope 2.9.

4) In case you *do* need manual translation in Python (sometimes it
happens), you can call zope.i18n.translate(msgid, context=REQUEST)
(notice the context is the request here). That will of course only work
with i18n messages from domains that are in Zope 3 style translation
domain objects. If you want to translate messages from PTS or Localizer
in your Python code, you should indeed use your above way of
translating. In that case I recommend you would still mark the messages
as i18n messages, just to be future proof.

> I've made calls to the following too:
> 
> name = ts.getLanguageName('en',self) #'en' is just an example
> 
> current = ts.negotiate_language(self,domain) or default
> 
> languages = [{'code':code,
>              'name':ts.getLanguageName(code, self),
>              'selected':current==code} for code in
>              ts.getLanguages(self,domain)]
> 
> What are the new-world equivalents of these?

Why would you need this? The translation machinery negotiates for you.
All you have to worry about is the *extraction* of preferred languages
from the request. You provide that IUserPReferredLanguages adapter and
the machinery will do the Right Thing. (PTS's nomenclature is a bit
confusing because it calls language negotation what actually is just an
extract from the request).

> Finally, Philipp's article suggests that people may want to write
> message catalog implementations that do the automatic compilation to .mo
> and/or capture and report untranslated message ids. Has anyone done
> this? If not, I might well be up for it :-)

Hanno Schlichting will be working in similar areas, I've heard. Perhaps
you want to make friends with him :).

Philipp