[openstack-dev] _() consensus??

Mark McLoughlin markmc at redhat.com
Mon Jan 7 07:27:04 UTC 2013


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

Cheers,
Mark.




More information about the OpenStack-dev mailing list