On 2014-05-20, 10:28 PM, Isarra Yos wrote:
> On 20/05/14 23:05, Daniel Friesen wrote:
>> * The skinname you require is the same one assigned to $wgValidSkins
>> and set on $wgDefaultSkin and set on $skinname, and $stylepath.
>> * For all skins using the old autoload pattern the assets directory
>> remains them same, so nothing has to be re-cached.
>
> But that sounds more like an oversight with the autoloader
> implementation and class setup than an actual reason why it would be
> good practice to use lowercase. Was there a particular design reason
> to set those up to be that way?
I'm not sure which item, you think you're replying to but you might be
misunderstanding what I'm saying.
The key used for $wgValidSkins/$wgDefaultSkin/$skinname has always been
lowercase, and I haven't seen anyone suggesting that we start using
&useskin=MonoBook, which would be a bad idea since this key is used in
i18n message keys and the skin- css class – places you don't want to use
upper case letters. Plus of course using upper case letters there is
just asking for a pile of brand new bugs as someone accidentally uses
the wrong case and hard to debug errors start popping up.
And for the bit on re-caching that is simple.
Assets for core skins like Vector and old skins that are implemented
using the autoloader are currently at:
{mediawiki}/skins/vector/*
If you change the directory structure so we load
$IP/skins/Vector/Vector.php (instead of $IP/skin/vector/vector.php) then
the path to assets becomes:
{mediawiki}/skins/Vector/*
Even though not a single one of the assets have changed the URL has, so,
re-cache.
ResourceLoader moves most CSS, JS, and some images to load.php but there
are still resources that are referred to with an actual URL, like
Vector's .htc file, all css images in IE without data: URI support, css
images that aren't marked with @embed (because they're too big, use
multi-backgrounds, etc...), anything in an <img> using
$skin->getSkinStylePath(...), and any stylesheet still loaded with
addStyle (IE stylesheets, etc...).
> Two of those also apply to extensions in general - FooBar and Foo Bar.
> Has this sort of inconsistency between name presentations ever posed a
> problem there? And with skins in particular, why would the internal
> handling of the skin name be coupled to the filename at all? And why
> the case-sensitivity, especially when not all platforms that mw
> supports even use case-sensitive filesystems? Is this just a holdover
> from the autoloader implementation?
Two is fine, the problem is having three, or rather in essence inventing
a third just for skins.
Extensions have two names visible outside of the internal API of the
extension:
* FooBar is a canonical key, it's used in the dirname (plus the entry
file name) and "usually" (there is some inconsistency) the 'name'
key to extension credits (.
* Foo Bar is the human name, and well, sometimes it doesn't even exist
even when an extension name has multiple words.
There is some inconsistency in what we use in extension credits, we have
a 'name' key and sometimes a human name gets filled in there ('PDF
Handler', 'Central Auth', 'Abuse Filter', ...) and in others the
canonical key gets used (ParserFunctions, SyntaxHighlight, AntiBot,
TorBlock, MobileFrontend, ...), the most common behavior seems to be to
just use the canonical key, giving most extensions only one name. If we
were serious about human names for extensions we would make it possible
to i18n them.
Skins are different, they have two names visible outside of the internal
API of the skin:
* foobar is a canonical key it's used on the key that registers the
skin ($wgValidSkins['foobar'] = ...;), in &useskin=foobar,
$wgDefaultSkin = 'foobar', the .skin-foobar css class, the skin's
MediaWiki:Foobar.css (it's ucfirst-ed but it's still foobar not
FooBar.css) and User:X/foobar.css, other i18n messages like
skinname-foobar that defines the skin's other name and messages like
foobar-action-addsection that allow the text used in tabs like "Add
section" to be controlled on a per-skin basis, and currently used by
every core skins and most 3rd party skins for the assets directory
in $IP/skins/.
* Foo Bar is a human name, this name is visible to all users on the
preference page and – unlike extensions' human name – this one has
full i18n support and is defined by practically every skin. This
name is defined by the skinname-foobar i18n message for the foobar skin.
So:
* Extensions often end up with one name not two.
* FooBar has never been exposed outside of the internal APIs for a
skin (SkinFooBar class names aren't visible anywhere and if
$IP/skins/FooBar.php is used it's autoloaded and not visible to anyone).
* If you did expose FooBar somewhere visible one skin now has three
different names for it.
* And to top that off by using FooBar as the dirname a skin now
basically has two different canonical names for it.
Let me detail the what I mean by multiple canonical names.
Pretend in the future we implemented a loader for extensions and skins
into core, so instead of a raw require_once in your LocalSettings.php
you'd drop a call to load an extension by name (maybe in this future
we've moved some stuff into a .json file or something).
Something like:
MWExtension::load('FooBar'); # Install $IP/extensions/FooBar
This works fine for extensions, you've got one canonical key, nothing
else to deal with.
Skins using lowercase dirnames are fine too:
MWSkin::load('foobar'); # Install $IP/skins/foobar/
$wgDefaultSkin = 'foobar';
The canonical keys are the same for both loading/installing skins and
setting it as default.
With the introduction of FooBar "extension style" skin names that's a
little different:
MWSkin::load('FooBar'); # Install $IP/skins/FooBar/
$wgDefaultSkin = 'foobar';
This time two different supposedly canonical keys identifying the same
skin are used for different areas of config, you'll probably end up
looking them up, and anyone who tries mistakenly using `$wgDefaultSkin =
'FooBar';` is a poor soul.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
