Before Ia72c960b2c7914342eb4d5e3e63f2d6af14719ad the parser test
framework wasn't setting the user language correctly when a variant
was requested, which meant that the UX text was being selected from
the base language, not the user's preferred variant.
Depends-On: I0c9c9fec920f7cb028d935e552a8f11475a23ba7
Change-Id: I7ab40a1d9adc6478c2fe99f44c8f51cbe4ac23a0
The fix for this issue is in Ia72c960b2c7914342eb4d5e3e63f2d6af14719ad
but we have to temporarily disable the test in order to break a cyclic
dependency.
Change-Id: I318c2fb8694c90efef07f1e2951c6d9aa6b3e82f
sr-ec and sr-el are not conform to BCP 47.
BCP 47 explicit mentions sr-Latn and sr-Cyrl as examples.
MediaWiki already supports both the old language codes 'sr-ec' and
'sr-el' and the new language codes 'sr-Cyrl' and 'sr-Latn' as language
codes for variants.
Bug: T117845
Change-Id: I59fd307664769efb8a6e4c47a866c3b1dd17ed5d
Remove the JavaScript module and its logic to toggle the disabled
state on the submit button. Instead, let the browser handle this
natively by setting the `required` attribute, which naturally prevents
early submissions.
Retain the current styling for 99% of cases by using the
:required:invalid selector to target the submit button to make it
appear disabled. This slight duplication of styles is needed because,
despite the form effectively being disabled natively, the core
mediawiki-ui styles only account for :disabled on the button directly
and not e.g. inherited via form:invalid. It is also unclear whether
we would want that, since there is some value to be had from having
the form give a consistent look with a progressive button that can
be submitted even at the wrong time to yield an assistive message to
the required field, so hence handling this locally for now instead of
with a generalised approach.
In order to use the required true/false idiom, I have switched the
generating of the HTML string from the old Xml::element method
to Html::element. This means there is no need to store it in an array
first and conditionally set it since true/false will result in absence
or required="" as needed.
As side-effect from this, redundant attributes like value="" and
type="text" are ommitted from the output, just as MediaWiki core does
more generally.
Bug: T283303
Change-Id: I2c75e09dd3f89fa11fca311b4e1f8133946b01b1
Provide an option to supply the aria-label attribute to the inputbox to
allow generated markup be accessible to screen readers
<inputbox>
type=search
width=120
buttonlabel=Search
arialabel=Search this wiki
</inputbox>
Bug: T242354
Change-Id: I40c62bc9889a4912b43244ec65e628ec8bc8533f
This approximates the behaviour prior to core change for
T119158. It will language convert the options: default,
buttonlabel, searchbuttonlabel, and placeholder if they
contain a "-{".
The old behaviour was to handle the insides
of -{ glossary rules here }- and convert text if there was a
glossary rule both prior to the beginning of the attribute and
prior to the end of the attribute (So default=foo-{}-bar-{}-baz
only bar would be converted). I believe that just looking for
-{ is probably close enough. It also opens the question of if these
options should always be language converted, but I'll leave that
for someone else to decide.
Bug: T180485
Change-Id: I3aa10890950afce445075e895baf6b10327bc222
Add an optional tour parameter with adds `&tour=[x]` to the local Special:Search URL
Remove whitespace error
Add test
Modify test HTML (x3)
Bug: T174077
Change-Id: Iaaf1d04e1939bd555cacd4ea3ac4390d7e43b19d
