On Thu, Mar 30, 2017 at 3:24 PM, Doug Hellmann <d...@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 <d...@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev