Changes to the use statements done automatically via script
Addition of missing use statements done manually
Change-Id: I8e049e495a0d0f3a0e1ee02a8252354b12604bf9
* deprecated means "please do not use this".
* required means "you must use this".
* suggested means "it's a good idea to use this".
* optional means "you typically don't need this".
There is no combination that makes any sense. They are really
exclusive to each other.
Still we have to keep the three checkboxes for backwards
compatibility reasons. It was always possible (and will probably
continue to be possible) to have more than one of the three fields
enabled. While users like VisualEditor will make a good guess (e.g.
ignore the rest when "deprecated" is checked) I really think we
should not attempt to hide (and auto-fix) it in this dialog. That's
why the proposed code continues to show the old checkboxes when
more than one is checked.
Bug: T202851
Change-Id: I994268d658602761b180f489bedb50b91fe0c419
Most of the code is already using a "prop" variable for the same
purpose. I hope that following the same pattern everywhere makes the
code easier to read.
Change-Id: I00e344b9041e1cb7e2dee129b17549959f32e4d9
New in OOUI v0.48.2.
Unlike the old version, this also prevents inserting line breaks by
copy-paste and other methods.
Change-Id: I2fe1b7cfe70ebb6b66a9dfdf012522b574f6e774
empty() should only be used to suppress errors
When the type of the variable is array,
a falsy check is the same (checks for null, false and empty array)
Found by a new phan plugin (T234237)
Change-Id: I17e48498c9be9c542b48a9d77c5574fba9f38d4d
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
