On 2014-05-24, 12:12 PM, Bartosz Dziewoński wrote:
> First of all, something we all agree on: let's murder skin
> autodiscovery. I'll
> submit patches to emit deprecation warnings if a skin using it is
> found (to
> master and 1.23 LTS release), and another patch that will remove it
> entirely
> (intended for MW 1.24 or MW 1.25).
+1
> As for Daniel's concerns about capitalization differences (which are
> valid
> regardless of which directory we want to place the skins in), forcing
> everything to be lowercase is a solution, but one that I don't like
> very much.
> Keeping the status quo is also a solution, but clearly no one at all
> likes
> this one.
>
> I'm going to name the three names we have 'skin file name' (same as skin
> directory name), 'skin name' (the one used in $wgValidSkins, saved in
> user
> preferences etc., used for site and user JS and CSS pages) and 'proper
> skin
> name' (localised one displayed on Special:Preferences).
>
> Let me propose two more ways we could do this. (All of the back-compat
> concerns below don't apply to new skins, only existing ones that we'd
> want to
> retro-fit to the new way. We could also avoid them by not retro-fitting.)
>
> * Instead of switching file name to lowercase, why not switch skin
> name to
> CamelCase? We'd have a maintenance script to update user preferences
> in the
> database, and a little back-compat layer to allow skins to define
> non-canonical names they want to respond to (for site admins who
> can't run
> the maintenance script).
>
> This will, however, break back-compat for JS user scripts (that
> implement
> different behavior per-skin), as well as very poorly written
> PHP-side code
> (which should have no reason to care about skins). This might be
> acceptable.
>
> * Always compare skin names case-insensitively (which is easy if they're
> all-ASCII), in 'useskin', in database user preferences data,
> everywhere –
> and use CamelCased names in "user-visible" areas. We could keep the
> canonical skin names the way they are in existing skins for
> back-compat of
> user preferences, but site admins would be able to set $wgDefaultSkin =
> 'CologneBlue' even if the canonical skin name was 'cologneblue'.
>
> As far as I can tell this will not break back-compat at all, and
> would let
> us move forward leaving very little tech debt behind.
The idea of "migrating" a pile of keys in the first makes me shudder.
In both of these cases please keep some other areas in mind:
* i18n message keys like skinname-{$skinname} and
{$skinname}-action-viewsource (which the i18n system as set a standard
of always using lower case keys)
* Site skin scripts and styles MediaWiki:{ucfirst($skinname)}.css +
MediaWiki:{ucfirst($skinname)}.js and user scripts and styles
User:X/{$skinname}.css + MediaWiki:{ucfirst($skinname)}.js (these would
be ridiculously hard to just "migrate".
So either way even if you try replacing skinname with SkinName, the
lower case skinname still sticks around.
I am fine with the idea of letting &useskin= and $wgDefaultSkin (and
even $wgSkipSkins) work case insensitively (though I wouldn't encourage
the actual use of uppercase there). However $wgValidSkins isn't
something should become case insensitive, attempting that for array keys
is asking for bugs. Same for putting non lowercase keys in the database
and trying to make them case insensitive.
The easiest way to make &useskin=, $wgDefaultSkin, and $wgSkipSkins case
insensitive is to normalize all skin keys from them to lowercase (which
is actually only a few lines in Skin.php) and then as a "breaking
change" say we're forbidding non-lowercase keys to $wgValidSkins (which
should be rather simple since I haven't seen a single skin yet doing
that which would actually be broken by such a change).
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
