Localization in v2 - all errors AND warnings are localized in default
language unless lang= is given, in which case you can get parameter array
or a non-default language. All standard translation magic
(plural/gender/etc) will be supported. Warnings will always include a
I was thinking of getting it done fairly early in APIv2 (next few weeks),
so please post/email your browser-based api use cases and preferences. API
internals already contain methods to report errors (dieUsage) and setting
warnings, and the later will be expanded to support warning codes.
Open implementation questions: how better to provide translation maps so
that an extension could easily raise common and extension specific errors,
and so that the translation could be done on both the server and the client
On Fri, Jan 25, 2013 at 10:03 AM, Brad Jorsch <bjorsch(a)wikimedia.org> wrote:
I'm going to copy this to the mediawiki-api list,
On Fri, Jan 25, 2013 at 8:01 AM, Daniel Kinzler <daniel(a)brightbyte.de>
Wikidata (technically, Wikibase) uses a lot of JS/API based editing, and
several times hit upon the question of how to
best report errors from
I'll try to break the issue down into several
concrete questions. But
the status quo as I understand it:
* errors are reported using an error code (a string) and a free form
message. The message is usually not
internationalized, though sometimes
* warnings are reported as free form text.
* Additional information can be added to both errors and warnings, but
no standard way to do this.
* Errors exposed by the API are often not generated but just passed
the API; Typically, a generic error code is used
with the original error
(e.g. from an exception).
Sounds generally correct. Anything coming out of the API
internationalized is probably either being passed through from
something else or being generated in an extension.
So, here are my questions:
* Should error messages returned by the API be translated? Or should the
** In both cases, it would be nice to have a consistent relationship
error codes and the corresponding system
** If translation is done on the client, we need to pass any message
** The message key would have to somehow be derived or mapped from the
It would be nice to have internationalized and parameterized error
messages from the API. The problem is that if we want to do anything
without waiting for "API version 2", we want to avoid as much as
possible breaking backwards compatibility with existing clients. Which
probably means that we'll want to add a parameter for the client to
specify the new style errors and warnings; this can double as
selecting the language the errors should be returned in.
I'd have to look at what existing code does as far as errors/warnings
before making a more concrete proposal.
* When using system messages to translate the
error codes from the API,
messages will often contain wikitext. How can we
best avoid this?
likely to be quite useless to the client - it
would be better to return
pass all the message keys and parameters, and let
the client generate
I'd suggest that messages actually returned by the API should be in
plain text, and should ''not'' use the MediaWiki namespace. In terms
of the Message class, $msg->useDatabase( false )->text(). This makes
things sensible for bots and such; they will often be writing errors
to a log file or showing them in some user interface where HTML
parsing is probably not available.
The message key and parameters should (optionally?) be returned for
the client to format as HTML or whatever. And the client is welcome to
interface and such.
Unfortunately, it seems that the message key prefix "api-error-" is
already in use.
* Status objects are often used to collect errors
and warnings the occur
trying to perform some task. It would be nice if
the API would provide a
standard way to put the contents of a Status object into the result
least the errors and warnings).
It seems it does, at least sort of: ApiResult has a
Any thoughts on that?
Mediawiki-api mailing list