Format/style of UI message
Daniel P. Berrangé
berrange at redhat.com
Fri Jul 17 15:28:59 UTC 2020
On Fri, Jul 17, 2020 at 05:01:47PM +0200, Pino Toscano wrote:
> I recently took a look at the UI/user visible messages from libvirt,
> which are translated using gettext. They are extracted in a single
> libvirt.pot catalog, which includes messages from libvirt.so itself
> (mostly, if not all, errors), the separate daemons, the helper tools,
> and from virsh.
> I noticed there is plently of room for improvements: what strikes is
> the lack of consistency among the messages. Let me state first: I
> understand that not all the people are native English speakers
> (I am not), so I'm not picking against anyone.
Yes, the lack of consistency is pretty bad and makes more work for
> Some examples:
> a) different capitalization:
> - "cannot open %s"
> - "Cannot open %s"
> b) different quoting for files/identifiers/etc:
> - "Cannot open %s"
> - "Cannot open '%s'"
> c) different verbs for failed actions:
> - "Cannot frobnicate ..."
> - "Could not frobnicate ..."
> - "Did not frobnicate ..."
> - "Failed to frobnicate ..."
> - "Unable to frobnicate ..."
> depending on the message, also "frobbing failed"
> d) sometimes contractions ("couldn't", "don't", etc), sometimes not
> ("could not", "do not", etc)
> e) what QEMU/etc supports:
> - "... by this QEMU binary"
> - "... for this QEMU binary"
> - "... in this QEMU binary"
> - "... with this QEMU binary"
> - "... by this QEMU"
> - "... for this QEMU"
> - "... with this QEMU"
> - "... with this binary" [in a QEMU file]
> - "... [supported] by qemu"
> there is also "qemu does not support ...", which I think it can stay
> for now; also both "available [by/for/etc]" and "supported [by/for/etc]"
> are used
> I can give it a try in fixing the messages to be more consistent all
> around; before I start the mass editing, I need to know which style to
> a) it seems like the virError fields @message, @str1, @str2 and @str3
> are joined together in reporting/log strings like "error: <text>";
> hence, should they be not capitalized? It may look OK in English, but
> less nice and hard to fix in translations.
> Obviously, sentences as shown in tools (e.g. virsh) definitely need to
> be properly capitalized.
I think there is no correct answer here, because even with the error
messages, the <text> is not always used in the "error: <text>" scenario.
eg an application like virt-manager will merely display "<text>" in a
On the one hand I'd suggest lowercase text for error mesages, but if
the message is multiple sentances that would involve a capital. Probably
don't have many of the latter though, so standardizing in lowecase is
> b) should identifiers such as filenames, paths, XML tags, JSON fields,
> etc be always quoted?
Generally user data that may go missing should be quoted because it makes
it more obvious when there is an accidentally empty string provided. I've
gone back to add quotes every time I've debugged a problem where the empty
string was involved. To make it easier as a policy, it is fine to expand
that to all filenames/path, regardless of whether they come from the user
data or not. For XML / JSON field names, if it is just a bare word, then
I'd probably suggest quoting too, as some field names could accidentally
lead to grammatically correct but misleading error messages if unquoted.
> c) which verb to use when something failed? "could not" is a subjective
> thing, not a past action; "failed" seems to imply that something was
> attempted; "did not" seems to imply that it was not done, but nothing
> whether it was attempted; the rest sort of indicate the ability to do
I don't especially care which we use, as long as we're pretty
consistent. Perhaps the thing todo is just see which is the most
popular usage today, so we invalidate the fewest translations
> d) allow contractions or not? They are generally used in spoken/informal
> language, and while libvirt is not that formal it should not be that
> colloquial either IMHO; also, they make the text slightly harder to
> understand by non-native speakers, and they are lost when translating.
> A POV on the matter is:
Yeah, I think I've seen enough recommendations about not using
contractions, that we should apply that rule.
> e) which message to use to indicate that QEMU does not support
I don't have a strong preference. Perhaps again just let a popularity
contest decide it.
I wonder if there's any clever python code we can pull in that reports
on "similar" strings that we could usefully run across the pot file
to identify candidates for sanitizing.
Also if there are many cases where we use roughly the same string
message, then that's a candidate for creating a wrapper function
to standardize on message text.
eg we added a virReportEnumRangeError() so that we got guaranteed
identical error messages for all enum range problems.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the libvir-list