Open Stack

On Mon, 2013-01-07 at 08:19 +0000, Monty Taylor wrote:
> 
> On 01/07/2013 07:57 AM, Mark McLoughlin wrote:
> > On Mon, 2013-01-07 at 07:48 +0000, Monty Taylor wrote:
> >>
> >> On 01/07/2013 07:27 AM, Mark McLoughlin wrote:
> >>> On Sat, 2013-01-05 at 16:43 +0800, Zhongyue Luo wrote:
> >>>> Hi all,
> >>>>
> >>>> I understand that i18n is an important feature to customers and that having
> >>>> gettextutils wrapped on all log messages will benefit
> >>>> in packing custom .pot files to ship with a product.
> >>>
> >>> If we want to i18n log messages, I think they should be in a separate
> >>> translation domain from the messages we return to users of the REST API.
> >>>
> >>> The problem with having them both in the same translation domain is that
> >>> translators have no way of prioritizing the REST API messages nor do
> >>> administrators have any way of disabling the translation of log messages
> >>> without the translation of the REST API messages.
> >>>
> >>> Something like this:
> >>>
> >>>   import gettext
> >>>
> >>>   gettext.install('nova', unicode=True)
> >>>   t = gettext.translation('nova-logmsgs', fallback=True)
> >>>
> >>>   import __builtin__
> >>>   __builtin__.__dict__['L_'] = t.ugettext
> >>>
> >>>   print _('This is a user-visible message')
> >>>   print L_('This is a log message')
> >>>
> >>> The next step is to handle the setuptools integration so that it can
> >>> generate multiple template files and install multiple catalogs. Here's a
> >>> quick experiment I did for extract_messages:
> >>>
> >>> First in setup.py, add the extract_log_messages command:
> >>>
> >>>   cmdclass = common_setup.get_cmdclass()
> >>>
> >>>   from babel.messages import frontend as babel
> >>>
> >>>   cmdclass['extract_log_messages'] = babel.extract_messages
> >>>
> >>> and, secondly, in setup.cfg configure its default parameters:
> >>>
> >>>   [extract_log_messages]
> >>>   no_default_keywords = True
> >>>   keywords = L_
> >>>   mapping_file = babel.cfg
> >>>   output_file = nova/locale/nova-logmsgs.pot
> >>>
> >>> It looks like it might just be possible to do this.
> >>>
> >>> I've filed this oslo blueprint, since we'd probably add some helper code
> >>> to oslo to make this possible:
> >>>
> >>>   https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain
> >>
> >> GREAT!
> >>
> >> However, before we start doing multiple-domain craziness, we should
> >> probably finish the task of consuming the messages we currently have.
> > 
> > I don't follow? What aren't we doing? Bug #?
> 
> https://bugs.launchpad.net/openstack-ci/+bug/995287
> 
> We happily collect the strings, translate them and install them - but to
> the best of my knowledge we are still missing the code to actually
> consume the translations. I'd be thrilled to be wrong here...

The gettext.install('nova') calls hook _() up as a call to ugettext().

The issue Clark alludes to is "what is message catalogs aren't installed
in a standard location?" may be accurate, but AFAICT we're doing what's
needed to consume translations installed in standard locations.

Cheers,
Mark.