[openstack-dev] _() consensus??

Monty Taylor mordred at inaugust.com
Mon Jan 7 08:19:45 UTC 2013



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...

Monty



More information about the OpenStack-dev mailing list