Done:
* Replace LanguageConverter::newConverter by LanguageConverterFactory::getLanguageConverter
* Remove LanguageConverter::newConverter from all subclasses
* Add LanguageConverterFactory integration tests which covers all languages by their code.
* Caching of LanguageConverters in factory
* Make all tests running (hope that's would be enough)
* Uncomment the deprecated functions.
* Rename FakeConverter to TrivialLanguageConverter
* Create ILanguageConverter to have shared ancestor
* Make the LanguageConverter class abstract.
* Create table with mapping between lang code and converter instead of using name convention
* ILanguageConverter @internal
* Clean up code
Change-Id: I0e4d77de0f44e18c19956a1ffd69d30e63cf51bf
Bug: T226833, T243332
Released just now.
Many old suppressions can now be removed. Enabling the issue for
undeclared variables is left to do later, given that there are
roughly 200 warning.
Change-Id: I99462a1e9232d6e75022912e2df82bc2038476ef
Apparently the section edit links may depend on state that is
available through context in the Skin object, but not necessarily
through the global context, such as the current user and page title.
Allow ParserOutput::getText() to take a 'skin' option for this purpose.
Bug: T234868
Change-Id: Iaa83e5f801c7776bf8218d8ce7484e2485b227d4
The @see points to a totally different class – which is fine. But no
tool knows it is supposed to inherit the @return type from there.
Change-Id: I40cd0f329980553b7b5f03e8539ee80ca5f032b3
The setting of $pageParams in that code path was assuming the page was
specified by title, breaking when it was passed a pageid.
Bug: T241362
Change-Id: Ia5b34ee392c94e5ae7693e95b58806c1dac2b24e
@phan-assert-false-condition $x will make Phan infer that the argument
to parameter $x is falsey if the function returned successfully.
Change-Id: I928474e922980b2759fcc4252b1df21164297e0a
Until I70473280, integer literals were always quoted as strings, because
the databases we support all have no problem with casting
string-literals for comparisons and such.
But it turned out that gave MySQL/MariaDB's planner problems in some
queries, so we changed it to not quote actual PHP integers.
But then we run into the fact that PHP associative arrays don't preserve
the types of keys, it converts integer-like strings into actual
integers. And when those are passed to the DB unquoted for comparison
with a string-typed column, MySQL/MariaDB screws up the comparison while
PostgreSQL simply throws an error. Sigh.
So ensure the user names passed to the database are actually strings.
Bug: T240808
Change-Id: If2bca6ab9faa5b50516e47f06b0b26b3648e4cbf
Given an API response indicating an error, it returns a jQuery object
containing a human-readable error message that you can display
somewhere on the page.
Handling the "real" API responses from the server is easy, since they
already contain the error message and we basically just extract it.
The important part of this patch is handling the issues that happen
on the client, or server-side issues where the error-handling API
code never runs, so we have to figure out what happened and make up
our own error message.
I have not yet seen any mw.Api consumer that handles all the error
cases correctly (I thought VisualEditor did, but in the process of
writing this patch I learned that we missed a few cases there as
well), and most don't even try. This might not be perfect but it
should be the closest thing so far.
The new code is inspired by error handling in VisualEditor (see
I69d9432162f195dcfe9470485b549a1b007617ff) and in mw.Upload.BookletLayout.
New messages:
* 'api-clientside-error-noconnect'
- Adapted from 'apierror-offline' and 'visualeditor-error-noconnect'
* 'api-clientside-error-http'
- Adapted from 'visualeditor-loadwarning' and 'visualeditor-error-http'
* 'api-clientside-error-timeout'
- Copied from 'apierror-timeout'
* 'api-clientside-error-aborted'
- Entirely new
* 'api-clientside-error-invalidresponse'
- Copied from 'visualeditor-error-invalidresponse'
Update some existing code to use it, as an example:
* mediawiki.page.watch.ajax
- Removed messages: 'watcherrortext'
* mediawiki.special.unwatchedPages
- Removed messages: 'watcherrortext'
* mediawiki.action.edit.preview
- (errors were hardcoded in English)
* mediawiki.feedback
- Removed messages: 'feedback-error2', 'feedback-error3'
(error1 and error4 remain, they handle errors not caused by the API)
* mediawiki.Upload.BookletLayout
- Removed messages: 'apierror-timeout', 'apierror-offline', 'apierror-unknownerror'
* mediawiki.page.ready
- Removed messages: 'logout-failed'
* 'mediawiki.page.patrol.ajax
- (the messages are already used by the patrol API)
Example usages in extensions:
* VisualEditor: I69d9432162f195dcfe9470485b549a1b007617ff
* DiscussionTools: Ice92fafb1f546510dab28e3f8aa7d2280668965a
Bug: T240519
Change-Id: Ie18666b41f4aff1ab4bcf93f9df6e3000ac7b500
