Open Stack

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.

<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. 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@!?!?!"?!?!

Monty

PS. I'm going to file a bug to replace all of our setup.py files with
automake...