Commit Graph

10 Commits

Author SHA1 Message Date
Stephen Niedzielski de76ab59c1 [Special:Preferences] [PHP] Add skin version user preference and configs
Add a Vector-specific user preference to Special:Preferences for
toggling skin version, either Legacy Vector or the latest Vector.

The presentation of the new preference section and the default values
for anonymous, new, and existing accounts are configurable via
$wgVectorShowSkinPreferences, $wgVectorDefaultSkinVersion (to be used by
the feature manager in T244481),
$wgVectorDefaultSkinVersionForExistingAccounts, and
$wgVectorDefaultSkinVersionForNewAccounts. These configurations default
to the fullest experience so that third-party configuration is minimal.
See skin.json for details. The configurations are each tested in
VectorHooksTest.php.

When presentation is enabled, the new preference appears as a checkbox;
enabled is Legacy mode and disable is latest. There are a number of
unfortunate details:

- Showing and hiding a checkbox is supported by OOUI. Showing and hiding
  a whole section (Vector skin preferences, in this case) is not so this
  additional client JavaScript functionality is added in Core (see
  Iaf68b238a8ac7a4fb22b9ef5d6c5a3394ee2e377).
- Stylization as a checkbox is wanted. However, the implied storage type
  for OOUI checkboxes is a boolean. This is not wanted in the event that
  another skin version is added (e.g., '3' or 'alpha'). As a workaround,
  the preference is converted from a boolean to a version string ('1' or
  '2') on save in Hooks::onPreferencesFormPreSave() and from a version
  string to a checkbox enable / disable string ('1' or '0') in
  onGetPreferences(). There a number of test cases to help cover these
  concerning details.

Documentation for overriding the skin version as a URL query parameter
is provided in anticipation of T244481.

Bug: T242381
Bug: T245793
Depends-On: Iaf68b238a8ac7a4fb22b9ef5d6c5a3394ee2e377
Depends-On: Ifc2863fca9cd9efd11ac30c780420e8d89e8cb22
Change-Id: I177dad88fc982170641059b6a4f53fbb38eefad6
2020-02-26 12:56:10 -07:00
Translation updater bot 8234491577 Localisation updates from https://translatewiki.net.
Change-Id: I73cf495e717fd3f4d9a175bad03d6999a76dc689
2019-01-24 22:37:48 +01:00
Translation updater bot a55d9b3e21 Localisation updates from https://translatewiki.net.
Change-Id: I32d1b7a5db51054ded19a14db4ea48fe7795e4d9
2018-05-24 21:56:08 +02:00
Timo Tijhof b843094a2d Re-implement and improve mw-jump links with pure CSS
* Improve their accessibility by giving both links
  a full label "Jump to x" and "Jump to y" instead
  of "Jump to: ", "x", "y".

  This also makes things much better for localisation, for which
  we generally discourage use of concatenation.

* Use pure CSS for the toggling of the visibility on focus,
  instead of relying on JavaScript. Especially given the
  JS comes form core's 'jquery.mw-jump' module, which is
  considered technical debt per T195256. Alternatively,
  that could be copied to vector.js, but pure CSS
  is possible, so why not.

* Use plain <a> links in the HTML instead of wrapped in a <div>.
  This solves the long-standing problem whereby the margin
  between #contentSub and #mw-content-text had to be awkwardly
  negated and overridden in core and on various to make sure that
  the wrapper itself would become visible as needed, in a way that
  has margin around this. This whole problem doesn't apply when
  simply using inline links that aren't part of the regular flow
  with .mixin-screen-reader-text. On focus, the individually
  focussed link appears in regular flow, without the need for
  any custom styles.

* This uses :not(:focus) to naturally make it render in the default
  way on focus, and visibibly hidden/clipped otherwise.
  This is supported in IE9+ and Android 2+.
  There is a way to make it work with CSS2 for IE7-8, by applying
  the mixin to '.mw-jump-link' only and then undoing all of
  'position', 'width', 'height', 'clip', and 'margin' on :focus.
  But I'm not sure that's worth it here. The fallback in IE7-8
  for not supporting ":not(:focus)" is that the accessibility
  link is simply visible always, which seems like a good fallback
  for accessibility, and doesn't hurt anything.

Bug: T195256
Change-Id: Icaadb290f692b3617688d32cbb66dfb007f1c82c
2018-05-24 00:08:02 +00:00
Translation updater bot 1ed289f520 Localisation updates from https://translatewiki.net.
Change-Id: Ib6655db681bfa6aa34d66bc2715d5dde74be1f9f
2017-10-31 21:59:35 +01:00
Translation updater bot 3f3386ddd6 Localisation updates from https://translatewiki.net.
Change-Id: I85f77f298def585ec78ebe5e71c7a834c48a0248
2015-09-28 22:26:45 +02:00
Siebrand a5496bcd75 Revert "Update namemsg to convention"
My bad... skinname-<skinname> is used in core to get the skin name.

This reverts commit ac0d123ba8.

Change-Id: I3c7780f9f08081238744fde094804ea8f5dd191a
2015-09-28 09:42:39 +00:00
Paladox ac0d123ba8 Update namemsg to convention
Bug: T113632
Change-Id: I86323ac69d420927c852eb9197fba3d589e73f1b
2015-09-25 18:26:57 +01:00
Translation updater bot 0f4cdc4dcd Localisation updates from https://translatewiki.net.
Change-Id: Ibaa098139c0440ff60e04ca3606869031abb2a32
2014-12-19 22:08:33 +01:00
Bartosz Dziewoński d28f09df31 Move Vector skin from core
This is the final step of the process described at
<https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki>.

Corresponding core change: Idfc38503.

Change-Id: I84fcf7ce6385b8323544cafe6912a00f1886d20d
2014-08-07 13:38:34 +02:00