We probably used "edit" as strictly speaking it could be "edit"
or "create", and it's hard to tell which will happen before
inspecting the content.
However "manage" is a poor alternative and not a verb we use
anywhere else. "Edit" argualby covers "create" as well, and will
be much more familiar to users.
Bug: T317468
Change-Id: Ia0b5da50fc87bd250e85faf29613a6f97ca36459
Following examples such as "VisuaEditor" -> "the visual editor"
and "Flow" -> "structured discussions", exposing the "brand" name
of the extension to users is no longer consider best practice.
Instead refer to it simply as "template data".
Bug: T317468
Change-Id: I969ddb013f9b51de8c222bff4e4c5104c5a0ee0f
The Metrics.js script needs this, but the dependency is not specified
anywhere. This "accidentially" works because it's rather common that
the module is required by some other code on the page. I just found a
combination where this is not the case (a blank MediaWiki installation
with nothing but TemplateData, not even the WikiEditor).
Change-Id: I97a7c1d227316a222d7ca54adb400aa8dd769047
This was always comparing with the English description. The effect of
this was that the comparison was always false and the value always
set, even if it didn't change, resulting in unnecessary events being
fired. So this is only about performance but not really user facing.
Change-Id: Id7a46dbac81e2595478848bbf325eece21815bec
This patch includes two bugfixes:
1. The previous rule with a `p + p` didn't do what it was supposed to
do. It was adding a margin after the 2nd, 3rd and all following <p>
elements, but not between the 1st and the 2nd. It should have been
margin-top instead. The approach in this patch is different and
avoids the need to repead the 0.5em.
2. The red background color was not applied to the input fields any
more because OOUI doesn't use <input> elements any more.
Change-Id: Ia57b742e8b3cd29c1f55cd7e918f26f70eebab18
Some time ago there was a little bit of custom CSS applied to the HTML
table rendering. This is broken since patch I74214ea from 2016. This
patch renamed all CSS classes but forgot to update the PHP code
accordingly.
I decided to not change the HTML rendering because these class names
might already be used in custom per-wiki or per-user CSS. Instead I
partly revert I74214ea.
Unfortunately, some of the styles are quite dramatic, don't look good
or just don't work. I decided to remove some. The argument is that
the HTML rendering looks the same for 6 years now. I don't see a good
reason to change it now.
In detail:
* Suggested values are not aliases and should not be rendered in
gray.
* The message "no description" is rendered in gray and italics. But
this was applied to the wrong DOM element and made everything else
gray and italic as well.
* The color #777 is not readable, violating WCAG rules. While it's ok
to dim aliases and such, it must be at least #555 or darker.
* The "nowrap" destroys the table the moment one of the parameters
does have a longer name or alias. Let the browser handle this, as
it did for 6 years now.
* Same for rendering aliases as individual, indented blocks. This
makes the table unnecessarily big when there are many aliases, and
just doesn't look right. Again, let's stick to what we had for
6 years.
Change-Id: Idfa76eed6e2d68474c79d4674efce091cb031b66
It's required via the spec. We should act as if it's always there,
even when the actual "original data object" doesn't contain it.
Bug: T307331
Change-Id: I129b0c77e701df6ebbdc39432360cea8f10575e8
