Turns out this was always pointless. Nothing the method does makes
sense without a language. A default language is only choosen much
later as part of getSetupProcess, and the method called a second
time, this time with a language.
Issue introduced a long, long time ago and finally surfaced via
Ifcbb877.
Bug: T238329
Change-Id: I47c8ce16107ebe7a1d955665dc890bef80ec892a
A small mistake made in I7a82143. This is only relevant for very few
(but critical) language codes. For example, the dialog allows to add
the MediaWiki code "zh-classical". This needs to be translated to
"lzh", but only when we use it directly in HTML.
Bug: T238329
Change-Id: Ifcbb877fb6a348937e85a82459e924548f5ca856
It's always true and doesn't make any difference because of this.
I think the idea was to do some validation in the method. This
never happened and is done outside of the method instead (better
separation of concerns).
This is split from I1655174 to make it easier to review.
Change-Id: I48b7da75659365e5a2f72b680d40ee4b5b2904a2
Reasons:
* It's not the job of this code to validate the incoming types. This
happens server-side.
* The new code reflects better what actually happened: we stopped
using the prefix "string/".
* This was not (probably never) in sync with the server-side
validation. Some types got replaced, some didn't.
Change-Id: I0a35ca334c9e243dee548b271ddb3e1ca4498611
This is split from I1655174 to make it much easier to review. This
patch here doesn't do anything but rename existing variables to
follow existing, less confusing naming schemes.
Change-Id: Ibd9db5ca5a355246eeaed98d48edc835659ec2c5
The "uneditablefield" was added in 2014 via I9b13e2f, apparently
as a temporary workaround. It was apparently not possible to edit
multi-lingual language object back then.
All code related to that was removed about 5 months later via
I985ea03. The patch made it possible to edit such fields. They just
forgot to remove the message.
The "actions" message was added via I863a819. Apparently used for
an "action" table column where parameters could be deleted. This
also got lost in the same big rewrite in I985ea03.
Change-Id: I57329bef8de10ee19e1904d33605d2102fd22741
This is not really anything new. Most code already followed these
sniffs. This patch just fixes the remaining exceptions. Also:
* Remove PHPDoc blocks that don't add anything but just repeat the
strict types.
* Remove @file comments in favor of class-level comments.
* Add strict types where possible, most notably some `void`.
Change-Id: Iff6872dff68170b0fc4e82ac2ba3cad385e8773e
The first patch I5f52fe3 worked only for fields with an existing
value. Turns out it's undefined for new fields.
Bug: T238329
Change-Id: I7a8214335b720c9ab738f6c4e47febbc0abf7dc4
E.g. in German it says "Neue Zuordnung hinzufügen". The long string
peaks into the other UI elements because OOUI enforces some `nowrap`
for no good reason.
Change-Id: Ib5f8584d4ac652479d6f646dcaa8cf06654832fd
So far we show nothing but the index in the "paramOrder" array. This
is especially useless when a parameter is missing. The index just
points to the end of the array then.
Same when an unknown parameter appears. What the user needs is not
the index but the name of the unknown parameter.
I played around with a few formats. As suggested in this patch:
Required property "paramOrder[ "foo" ]" not found.
Invalid value for property "paramOrder[ "foo" ]".
A possible alternative is:
Required property "paramOrder[0] ("foo")" not found.
Invalid value for property "paramOrder[0] ("foo")".
Bug: T340377
Change-Id: I1dbef1b6e585d5b972a0c9a373a040aee6027cf3
The use of "HookHandlers" attribute in extension.json makes it possible
to inject services into hook handler classes in a future patch.
Bug: T271031
Depends-On: Ic2d188d2c332ab8afeb5454fb5a956c8ba5670ae
Change-Id: Idf4cf94a0e4fae31a5c1f6c3dbf319c0d6913cd7
