I tested this locally, and indeed: Try to edit for example your
own page http://en.wikipedia.org/wiki/Special:MyPage/common.js
Try to paste and save this:
var notWikitext = '<templatedata>{</templatedata>';
The page fails to save. (You might not see the error message
because of T258790#6751678.)
But this is not even wikitext. The <templatedata> string is
meaningless and does not trigger any TemplateData code when
the page is parsed and saved. Still there is an additional (!)
parser run that processes every page with the wikitext parser,
no matter what the actual content model is.
This does not only cause strange stack traces (see T272231),
it's most probably a massive performance bottleneck. Luckily
the majority of pages on the Wikimedia cluster is wikitext
anyway.
Bug: T272231
Change-Id: I2efcadc9bae6ecb37314f6d45c0c520abfbb85a0
These are a mess and hard to de-localize. Also, the schema is
already documented as not including the namespace in this field.
A proper migration would be very difficult, so we'll have to remember
that our data includes this glitch and manually strip namespace
prefixes before the deployment date, as needed.
Change-Id: If2a4dd865b95458dc63162460f252500fd52436e
Adding a new widget that inherits from MultilineTextInputWidget but
is initialized with only one row and prevents using the return key
to add new lines.
Bug: T263533
Change-Id: I5423f5f04075d21abd7acf09b622fd6444feeeb2
… instead of 0. Conditionally add a dash in front as well to
avoid confusing results like '1' + sequence number = '12'.
Change-Id: I345704b00ba3812c4905f85e35cf21a6dfd05437
I looks like the Model.params data structure is build in a way
that it allows mismatching parameter "keys" and "names". E.g.
{
"a": { "name": "a" },
"a0": { "name": "a" },
}
There are comments in the code that suggest this is
intentional.
I found code that confused these two values and tries to use
the name as a key, for example. This fails, messes up the
paramOrder, and such.
This should not have much, if any effect for users because
users are blocked from doing this anyway, e.g. buttons get
disabled.
Change-Id: I2067024ad8d5b8e985a4f162cf6875f523777a6c
Example:
On
https://en.wikipedia.beta.wmflabs.org/wiki/Template:Anschutz
the two parameters "state" and "capitalization_test" don't have
a label in the <templatedata> JSON structure. Instead the
internal parameter name is shown. But it's capitalized for an
unknown reason. I guess this is done to make the table look
"nice". But it causes confusion – see the ticket.
This capitalization is there since the very first commits from
2013, see I16d3f9e.
Compare with VisualEditor: Edit the template on
https://en.wikipedia.beta.wmflabs.org/wiki/Conflict-title-0.8542952978413387-I%C3%B1t%C3%ABrn%C3%A2ti%C3%B4n%C3%A0liz%C3%A6ti%C3%B8n
or use the old wikitext editor and TemplateWizard to insert
the template. In both cases the parameter names are not
capitalized.
Another argument why this capitalization is misplaced: When
there is no <templatedata> JSON blob, the TemplateData editor
auto-detects the parameters and semi-automatically creates a
minimal JSON blob. This is the moment where labels should be
created and stored so the user can edit them. But this doesn't
happen (for good reasons).
The user can't do anything about the current capitalization.
The only way to change it is to add a label that does nothing
but repeat the parameter name, just to undo the capitalization.
That should not be the way this works, I would like to argue.
Bug: T174771
Change-Id: Ia8133d3f0d6b79fe89c63bb0392a334c0a185a65
