<div dir="ltr">On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:<br>
<span class="">> On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:<br>
> > On Tue, 2017-03-21 at 22:10 +0000, Taryma, Joanna wrote:<br>
> > > However, pep8 does not accept passing variable to translation<br>
> > > functions,  so this results in ‘H701 Empty localization string’ error.<br>
> > ><br>
> > > Possible options to handle that:<br>
> > ><br>
> > > 1)      Duplicate messages:<br>
> > ><br>
> > > LOG.error(“<error message>”, {<key>: <val>})<br>
> > ><br>
> > > raise Exception(_(“<error message>”) % {<key>: <val>})<br>
> > ><br>
> > > 2)      Ignore this error<br>
> > ><br>
> > > 3)      Talk to hacking people about possible upgrade of this check<br>
> > ><br>
> > > 4)      Pass translated text to LOG in such cases<br>
> > ><br>
> > ><br>
> > ><br>
> > > I’d personally vote for 2. What are your thoughts?<br>
> ><br>
> > When the translators go to translate, they generally only get to see<br>
> > what's inside _(), so #2 is a no-go for translations, and #3 also is a<br>
> > no-go.<br>
> > --<br>
><br>
> I think the appropriate thing here is to do something like:<br>
><br>
> msg = _('<error message>') % {<key>: <val>}<br>
> LOG.error(msg)<br>
> raise Exception(msg)<br>
><br>
> This results in a translated string going to the log, but I think that's<br>
> OK.<br>
><br>
<br>
</span>Why is the error being logged and then thrown? If it's a true exception,<br>
won't the outer-most part of the application loop log the error? And if<br>
it's something that the application is catching and handling, that makes<br>
it seem like it's not an operator-facing error.<br></blockquote><div><br></div><div>That's a good point. Without looking for examples, I suspect there's a few reasons here:<br><br></div><div>1) in ironic, the operator and API user are often the same person<br></div><div>2) ironic deals with hardware. Often, errors that are returned to the user are<br></div><div>   something only the operator can fix.<br></div><div>3) Nova is a heavy user of the ironic API - errors returned to nova may not be<br></div><div>   seen by the user, but the operator needs to see it somewhere (though it<br></div><div>   is easy to argue those shouldn't be translated).<br></div></div><br></div><div class="gmail_extra">// jim<br></div></div>