[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.
Cheers,
Mark.
More information about the OpenStack-dev
mailing list