[openstack-dev] Blueprint: Separate translation domain for log messages
joe.gordon0 at gmail.com
Thu Jul 11 08:56:43 UTC 2013
On Thu, Jul 11, 2013 at 9:39 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> 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.
> > 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.
What about starting with log messages are all low priority (except perhaps
for the error level?). A quick grep shows these are *roughly* half of the
> 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.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev