[openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

Doug Hellmann doug at doughellmann.com
Mon Mar 6 18:15:16 UTC 2017


Excerpts from Matt Riedemann's message of 2017-03-06 11:37:06 -0600:
> On 3/6/2017 10:28 AM, Ian Y. Choi wrote:
> >
> > +1 and for such discussions including openstack-i18n at lists.openstack.org
> > mailing list would be also nice :)
> >
> > On Barcelona Design Summit, there were I18n contributor meetup and I18n
> > team members discussed a lot.
> > One of things was not to translate log-level strings for server projects.
> >
> > Note that such decision was made not because translator time is limited.
> >
> > Log messages are important to better identify which errors are being
> > posed and most operators (+ developers)
> > diagnose and start to solve error situations from the log messages.
> > I18n team previously translated log messages a lot especially thanks to
> > translation contribution from IBM. (AFAIK)
> 
>  From what I remember working on an openstack-based product at IBM years 
> ago, non-debug messages required translation. That wasn't an openstack 
> requirement, that was an IBM product requirement. And way back when the 
> IBM products had their own plumbing for i18n and did our own 
> translations, and the upstream team of developers pushed and pushed on 
> the translation teams to upstream that work to the community which they 
> eventually did. Now it sounds like the push from IBM for that work has 
> dropped off so no one is really maintaining it.

This matches my memory of the origin of the feature in oslo.i18n to
support log translations.

> > However, after then, there have been some voices - why I18n team
> > translated log messages?
> > After listening to the voices in details, I18n team identified that the
> > background of such voices was related with searching log messages on
> > Internet.
> > Searching English log messages on the Internet will retrieve more number
> > of results than searching translated log messages on the Internet.

This was, perhaps not surprisingly, the primary argument against
implementing log translations originally. As a counter argument,
we actually enabled oslo.log to write to multiple log files, using
a different language for each one. I'm not sure if any of the log
translation work was ever deployed in production, so I have no idea if
anyone took advantage of this aspect of the system.

> > Translating log messages now has two different point of views:
> >  - Will be useful for OpenStack users to better understand log messages
> > in details with translated log messages?
> >  - Or will not be useful for OpenStack users because the original log
> > messages will have better chance to find solutions who occurred the
> > similar cases on the Internet?
> 
> Another IBM-specific product thing is non-debug translated messages get 
> a unique code which isn't translated. So the message is translated, but 
> the code isn't, and the code is what you use to lookup the error on the 
> internet. There was a proposal to do this in openstack many years ago 
> but it never happened.

I've been involved in a bunch of the discussions about log and error
message codes, and so far I haven't seen a proposal that included
a system for allocating unique codes that would scale to a distributed
project like OpenStack. All of them either relied on a central registry
of IDs or on an allocation scheme that didn't take into account the
number of projects we had at the time.

If we do come up with a workable system, I would be reluctant to
go through the effort of implementing it and rolling it out if there
is not wide-spread interest in maintaining the uniqueness of those
log message IDs and ensuring they are useful. Otherwise I expect
we'll end up having a similar conversation to this one.

In Atlanta at the PTG, Eddie Ramirez showed off some work he is
doing to build a reference site based on all of the exception classes
discoverable by scanning OpenStack application code. It's not
complete, but it shows good promise. One especially nice feature
is that it would give us a single well-known URL for each exception
class that we could (a) include in the logs automatically and (b)
extend with helpful information.

> > I18n team discussed with such point of views and on Barcelona Summit the
> > latter point would be more important than the former point.
> > Also, it would be just a point of view from PTL, but it is difficult for
> > me to encourage to contribution translations which have such kind of
> > controversy.
> >
> > Now I would like to listen again to not only developers, but also
> > operators and translators - for log string translation.
> > If someone thinks that the former point would be more important than the
> > latter point, please share through this mailing list to reconsider the
> > current decision.
> >
> >
> > With many thanks,
> >
> > /Ian
> >
> 
> I'm just trying to provide some context. I don't much care about this 
> either way, but it would probably also be good to get input from the 
> product work group, user committee and operators to make sure everyone 
> is aware of the fact that service logs are no longer translated; this 
> was news to me when we were releasing Ocata actually and I was waiting 
> for translations for ocata RC2.

Yes, given that there are people doing work on this outside of the i18n
team, we need to make sure everyone is included in the conversation.

Doug



More information about the OpenStack-dev mailing list