On Mon, May 11, 2026 at 17:32:44 -0400, Laine Stump wrote: > (I prefer the way you describe it in the actual commit message - "don't > break up lines in the source" - vs the subject line here - "prohibit > newlines" - since it's more accurate. Fortunately the actual commit message > is used as .... the actual commit message, so everything is cool! :-)) > > > On 5/11/26 12:23 PM, Peter Krempa via Devel wrote: > > Make them the same as we do with error messages since they often end up > > in logs. > > > > Since they are not translated [1] the existing check didn't catch that. > > > > > > [1] IMO in some cases they are in fact used as errors, and maybe would > > be worth to be translated. But this is for another series > > There have been a few times I've wished we were allowed to at least > *optionally* mark VIR_WARN strings to be translated, for cases where the > situation is something like:
Yeah, at least some of the warnings we emit would benefit from a translation. Especially since they are logged by default. > "This is *probably* going to lead to an error, and we've just seen evidence > of it in advance of the place where it's going to actually blow up. Right > now while we have this context we can tell the user how to fix it (and it > would be nice to tell them in a language they understand), but it would be > awkward and wasteful to try and regather that context later at the time we > actually fail. But also it might *not* be an error, so we don't want to just > fail right away in case we wouldn't have failed later." > > or something like that. For example (a recent one), we determine that a > particular default path for a directory for something isn't accessible by > the uid of the process running libvirt, but it turns out that in some > situations that path is never actually used, and so adding an actual error > when we decide on the path for config/logging/status would cause some > working setups to "mysteriously" start failing. (On the other hand, it's > awkward to later regather the context that the reason for the open/create > failure was because "the log path is inaccessible by this process" (the fact > that this was the source of the file path is usually a few layers up the > call stack from where the error is logged). > > So yeah, that issue is completely unrelated to your patch, but I thought I'd > chime in while the topic was brought up. Well, this is a first step :). Maybe Jirka still has his script to add positional substitutions which he used when adding them to virReportError, so we could also do the second step too :) > > > Reviewed-by: Laine Stump <[email protected]> Thanks!
