These messages are still used in ParamImportWidget, originally added
via I985ea03 in 2014. The comments have been added much later, see
Ib53aa55. This was really only a copy-paste mistake because of the
very similar message keys.
Change-Id: I78e1a8aec200299e72ce8354ea722ad9c1fd27c0
* 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
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
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
OO.ui.ActionFieldLayout requires 3 parameters: 2 widgets and optional
configuration. But this code was passing only 1 widget. The config
object was actually used as a widget and never as config. It's a
miracle this was not throwing an error. ;-)
Replace with a more trivial FieldLayout which requires only 1 widget.
Also clean up some closely related code.
Change-Id: Idca9a39e9f442f3a5412027906de9f868fc12b76
This fixes a whole sequence of issues:
* It was actually possible to add a parameter with no name.
* It was also possible to add parameters where the name is nothing
but whitespace.
* Pressing enter was not possible.
* The button was initially enabled with the input field being empty.
* Validation code was duplicated, but incomplete, which made it
possible to add duplicate parameters with enter.
Bug: T324381
Change-Id: I598997efc63256fd59a2b4f71fb7c3d99306bd85
This placeholder was added in Ic8f9bf7. It makes sure the page
content below the button doesn't shift down the moment the button
appears. See T279869 for a screencast that demonstrates the issue.
Unfortunately something changed (possibly related to T323773) and
the size of the placeholder is not correct any more. At the moment
the page shifts up a few pixels.
Bug: T279869
Change-Id: Ie6e585d2061342c11aabb4414bb9b0bedecf3a12
Note the code style in this file is already a mixture of some early
declarations and others that happen in place. We mostly prefer the
later nowadays because it makes the code much more readable. Some of
the code touched in this patch was really a little confusing, I would
argue.
Change-Id: Ib2777c6f6c86876c016e50d7bd2fe3d82c611914
A change in OOUI made .addItems() silently ignore non-array input.
The most robust fix is to make all callers follow the documentation
instead of relying on undocumented behavior.
The change to onMapItemRemove is not strictly needed but done to make
this piece of code much more robust.
Change-Id: I95f9a058766720d3809c3e56309326c2a91f2bcd
Main change is that we don't map between strings and object
references any more but use the object references directly.
Change-Id: Iecc011f62089d902bb5cbd9ff3b4189d3258a2b4
The data structure at the top of Model.js uses types like "string",
"array" and so on. Fields that share a type behave identical. I find
it odd to repeat parts of this data structure in the code. That's
what the types are for.
Change-Id: Iae55c18ececb809a56e40d3179d2cde357309d0a
… by turning the nested `if` around and simplifying the remaining
parts a little. This patch is intentionally minimized. More
meaningful changes will be done in the next patch.
Change-Id: I56cfa5c8ac8ca29acd42bd71786f5433e884e1b2
Previously, our eslint configuration required all variables
to be declared together at the top of the scope, but that
was changed, and declaring the variables where they are needed
is clearer.
Change-Id: I87e74ceadd5374a6ba6b7a4f8f49dca03a5c4bca
The data structure in Model.js, starting at line #125, does have a
"type" property that's supposed to do this. What kind of input element
we need depends on the type. Repeating individual element names here
means we are duplicating parts of the data structure.
The mapping is unambiguous, i.e. the new code is guaranteed to do the
same as before.
This is a tiny cleanup patch in preparation for later changes.
Change-Id: I162dcd6f9a31f5ab2c6eb7027befd4736de40ca5
"children" is an array. See line #148 in Model.js. What's called "type"
here is just the numeric index in this array.
Change-Id: I73c190f754d113ac90f5df76fb8cc8b7a75fc927
