Re: [Qemu-devel] [PATCH 6/9] QError: Add qdev not found error

[Jamie Lokier <jamie@shareable.org>]

Anthony Liguori wrote:
> hollisb@linux.vnet.ibm.com wrote:
> >It's hard enough to keep localized strings updated for every release
> >within a single code tree. Beyond that, you expect that every *client*
> >will update its localized strings for every *server* release?
> 
> What I meant by highly structured is that you wouldn't pass a string at 
> all.  There would just be an error code and whatever information went 
> along with that error code.  It would be up to the client to decide how 
> to present a message to the user.

The main problem with that is when you add a new error, several things
need to be added in different places, including in clients, so it
discourages adding new errors and existing ones are abused.

Down that road lies "Error, something failed", as well as "File not
found" for things which aren't files.

The practice of providing a string at the call site encourages
messages to be informative and accurate first, with localisation and
error-specific actions added later as needed.

The manual for GNU gettext explains quite well why gettext takes a
message string as argument, instead of a "message code".  Imho, a
similar case can be made for error messages at call sites.

> From a usability perspective, this is better both for localization but 
> also to ensure a consistent user experience with respect to how errors 
> are described to a user.

It's not great for localisation if N clients all maintain separate,
different sets of localisation for the same messages, especially if
the set of messages is changing regularly too from one qemu version to
the next.

It's also not a consistent user experience, if each client has a
different message for the same obscure errors.

Only the most widely used clients are likely to get localised, and
even those will get out of date quickly, e.g. when using a distro's
client with a newer-than-distry qemu.

> Basically, I think the conventional wisdom in UI design is that you 
> never want to pass error messages from a  server directly to a user.

You can probably guess I don't agree with that.  I'm not sure if it is
actually conventional wisdom, either.  It happens a lot in popular
things with highly refined UIs like web browsers, FTP clients and the
like.  They tend to _add_ their own explanation to the server-provided
error messages, but show the server's message too, especially for
uncommon error types that the client doesn't know about (because it
can't know them all).

-- Jamie