Open Stack

On Mon, 2013-01-07 at 10:09 +0000, Monty Taylor wrote:
> 
> On 01/07/2013 08:34 AM, Mark McLoughlin wrote:
> > 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.
> 
> So... yes. If they are installed in standard locations, we should be
> fairly good. However, there is some additional work we can do to consume
> them even where they are installed via pip install.

Do we have translations for any of our pip-installable projects yet?

> <rant>
> Python doesn't know how to install message catalogs, or man pages, or
> anything else. Grumble.
> </rant>
> 
> The workaround we're using for message catalogs is taken from the Sphinx
> source. That workaround is to keep them inside of the tree and include
> them as data files in the install.

Ah, I see. We install them (well, the uncompiled .po message catalogs)
in the python sitelib but gettext looks in /usr/share/locale for the
compiled message catalog.

Yes, you're right - we have work to do here :)

> That way, there's not much code (can
> be stolen from sphinx in not much time) involved in looking for the
> files from inside of the data files location. Clearly we don't want to
> that BREAK installations (like Debian packaging) that would actually
> grab the files and put them in properly.
> 
> Why bother then? Because we can't test that we are consuming the
> messages without it. If we're ok with that - then cool! I will stop
> caring and close that bug. But, if we _do_ want to put in testing
> verification that we are shipping catalogs that we can consume, then we
> need for them to work from a purely python toolchain.
> 
> Sigh.
> 
> Why can't we all just get along@!?!?!"?!?!

Oh Monty, I thought we already did!

:-P

Cheers,
Mark.