[openstack-dev] Blueprint: Separate translation domain for log messages

Mark McLoughlin markmc at redhat.com
Thu Jul 11 08:39:13 UTC 2013

Hi Daisy,

On Wed, 2013-07-10 at 21:48 +0800, Ying Chun Guo wrote:
> Hi, Mark
> I think there is a blueprint we discussed in the Havana summit to
> separate translation domains. 
> https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain
> I don't see any progress there.
> Do you have any plan to implement it?
> The translation team set the command line message as high priority,
> but log messages as low priority.
> So we want the domains can be separated.

Given that there's been no progress on this, I suggest we take a
pragmatic approach to allow us to move forward

  - The fact that the "high priority" and "low priority" messages are 
    mixed together means we can't get to high levels of translations 
    for the high priority messages.

  - It's time we deal with this issue around high priority messages with
    some urgency, even if that means hurting the ability to have low
    priority messages translated.

  - In other words, we should submit patches to have the low priority 
    messages no longer marked for translation.

  - Once someone comes up with a solution for a separate translation 
    domain for low priority messages, we can go back and mark the low 
    priority messages for translation again.

  - This sounds like a lot of churn, but every low priority message 
    will need to be touched even if we come up with a solution for a 
    separate translation domain e.g. changing _() to l_()

The key thing here is to have some very concrete rules about which
messages are high priority and low priority. The question is more subtle
than it seems.

For example, if a Nova instance fails to boot, we include the "instance
fault" in the detailed "nova show" output. Should those fault messages
be translated? If so, tracking down all the possible error messages that
might wind up there is actually quite difficult.

That said, I'd be happy if we erred on the side of "if we're not sure
whether it's user-visible, let's assume it's not" approach.


More information about the OpenStack-dev mailing list