Open Stack

On Thu, Mar 30, 2017 at 3:24 PM, Doug Hellmann <doug at doughellmann.com>
wrote:

> Excerpts from Jim Rollenhagen's message of 2017-03-30 15:08:13 -0400:
> > On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann <doug at doughellmann.com>
> > wrote:
> >
> > > Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
> > > > On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > > > > On Tue, 2017-03-21 at 22:10 +0000, Taryma, Joanna wrote:
> > > > > > However, pep8 does not accept passing variable to translation
> > > > > > functions,  so this results in ‘H701 Empty localization string’
> > > error.
> > > > > >
> > > > > > Possible options to handle that:
> > > > > >
> > > > > > 1)      Duplicate messages:
> > > > > >
> > > > > > LOG.error(“<error message>”, {<key>: <val>})
> > > > > >
> > > > > > raise Exception(_(“<error message>”) % {<key>: <val>})
> > > > > >
> > > > > > 2)      Ignore this error
> > > > > >
> > > > > > 3)      Talk to hacking people about possible upgrade of this
> check
> > > > > >
> > > > > > 4)      Pass translated text to LOG in such cases
> > > > > >
> > > > > >
> > > > > >
> > > > > > I’d personally vote for 2. What are your thoughts?
> > > > >
> > > > > When the translators go to translate, they generally only get to
> see
> > > > > what's inside _(), so #2 is a no-go for translations, and #3 also
> is a
> > > > > no-go.
> > > > > --
> > > >
> > > > I think the appropriate thing here is to do something like:
> > > >
> > > > msg = _('<error message>') % {<key>: <val>}
> > > > LOG.error(msg)
> > > > raise Exception(msg)
> > > >
> > > > This results in a translated string going to the log, but I think
> that's
> > > > OK.
> > > >
> > >
> > > Why is the error being logged and then thrown? If it's a true
> exception,
> > > won't the outer-most part of the application loop log the error? And if
> > > it's something that the application is catching and handling, that
> makes
> > > it seem like it's not an operator-facing error.
> > >
> >
> > That's a good point. Without looking for examples, I suspect there's a
> few
> > reasons here:
> >
> > 1) in ironic, the operator and API user are often the same person
> > 2) ironic deals with hardware. Often, errors that are returned to the
> user
> > are
> >    something only the operator can fix.
> > 3) Nova is a heavy user of the ironic API - errors returned to nova may
> not
> > be
> >    seen by the user, but the operator needs to see it somewhere (though
> it
> >    is easy to argue those shouldn't be translated).
> >
> > // jim
>
> I guess my point was that unhandled exceptions should all be handled
> by the Ironic API service code before the response is delivered,
> rather than having them handled in the code that is throwing the
> exception. If the exception is handled, that makes the message a warning
> or info log message, not an error, under our guidelines [1].
>
> [1] http://specs.openstack.org/openstack/openstack-specs/
> specs/log-guidelines.html


Fair enough. Maybe the folks removing translations can work on this while
they are in the code already. :)

// jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170403/90c4346f/attachment.html>