Lucas_Werkmeister_WMDE added a comment.
Ugh, but reporting such a `Status` in the API response becomes a huge mess :( The modern MediaWiki Action API error formats, which Wikibase doesn’t use (see below), all match `Status` well: both in the API and in `Status`, you can have a list of errors, each defined as a message with optional parameters that may be formatted in different ways (plain text, HTML, etc.). (The default format, `errorformat=bc`, only supports one error and throws away the other ones, but that format is no longer recommended.) Wikibase’s own format for API errors, which slightly predates the modern MediaWiki thing mentioned above (see T304945 <https://phabricator.wikimedia.org/T304945>), also kinda supports multiple errors, but still needs a single / top-level error //code// to report. You can see this slight mismatch in `EntitySavingHelper` – it gets a `Status` from the `EditEntity` service, and then has to determine an error code to pass to Wikibase’s `ApiErrorReporter`; `EntitySavingHelper::handleSaveStatus()` does this by either picking an `errorCode` from the `Status` value, or by hard-coding certain error codes based on the `errorFlags` from the `Status` value. Here, the “value” field of the `Status` is effectively carrying additional error information between `EditEntity` and `EntitySavingHelper. The `MergeItems` API (`wbmergeitems`) apparently invented //another// way to return multiple errors (to resolve T180296 <https://phabricator.wikimedia.org/T180296>), which is to return an array of error strings in the `extradata` of the error. It gets those error strings by starting from a single exception and walking up the chain of nested exceptions / causes while collecting their messages. I don’t know whether these messages are typically localized or not. The `CreateRedirect` API (`wbcreateredirect`), on the other hand, doesn’t support multiple errors. When handling a `RedirectCreationException`, it always uses that exception’s code as the error code; if the exception has a cause, it’ll use the cause’s message, otherwise the exception’s own message. Recursive causes are ignored as far as I can tell, and the exception’s message may not even be localized: for instance, you can see the error “Can't create redirect on non empty item $id”, which comes from hard-coded English text in `ItemRedirectCreationInteractor`, and not “Can't create redirect on non empty //entity// $1”, which would be the `wikibase-redirect-origin-not-empty` i18n message. TASK DETAIL https://phabricator.wikimedia.org/T356149 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: Aklapper, Arian_Bozorg, Danny_Benjafield_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, QZanden, KimKelting, LawExplorer, JJMC89, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331, Ltrlg
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org