I'm not happy at all with how the skin naming topic "ended".
Throughout the discussion I explained a variety of reasons why switching
to a CamelCased structure and skin name was a bad idea. We discussed
them, some like the caching issue got valid comments back on why they're
not issues, others remained.
But while there was a lot of discussion on the points on why the change
was a bad idea, almost no one seems to have bothered detailing points
why it's a good idea and comparing them to the negative point.
Reading through the discussion, the only person who bothered making a
single point on why it was a good idea was Jack Phoenix:
I'm going to assume that the lowercase
"skinname" in
$IP/skins/skinname/SkinName.php is just a typo and you meant it to be
CamelCased as "SkinName". If and when so, yes, this is what should be our
recommended way of doing it. CamelCase is how we name things consisting of
multiple words (i.e. BlueSky, DuskToDawn, HowTo, ...), so it's only
reasonable to use CamelCase here too. Having written and cleaned up many
skins myself, this is the naming convention I prefer and that seems natural
right from the start.
For why it's a bad idea, I made various other points, some of the
remaining ones summed up:
* Unlike extension names, skin names are used in a variety of
locations which upper case letters are either considered bad or
problematic, such as i18n keys, and keys to $wgValidSkinNames which
is both used in those i18n keys and has to be lower cased if we want
to make &useskin= case insensitive. So the lower cased keys will
never actually go away.
* ((Not a point in favour, but when someone pointed out that
extensions already have 3 names I pointed out I explained that in
most cases they actually only have 1, at most 2))
* Skins only expose 2 names to site admins and users, the canonical
lower case key and a fully translatable key. Because the lower case
key doesn't actually disappear exposing a CamelCase name now gives
skins 3 names to deal with – more than people installing extensions
deal with – and makes 2 of those names "canonical" names that are
supposed to uniquely identify the skin outside of the internals.
((Btw, I'll also point out that if we ever managed to implement real
class-less skins using templates our current only need for CamelCase
names – skin class names – would actually disappear))
As the discussion and attempts to implement this move on:
Krinkle chimes in that skins should only have a lowercase non-ASCII id
and a localized skin name.
I help out reviewing the various patchsets trying to implement this,
giving normal reviews, and also giving tips on how to properly write a
skin that uses an upper case directory (because most people here trying
it don't know how to do so without doing things like completely breaking
the IE compatibility features in a skin).
Bartosz agrees to leave skin directory names as-is while moving stuff
out of core, at least while the discussion hasn't finished.
Then all of a sudden, while the discussion is still open, it's reported
that someone who isn't even a maintainer for skin related stuff +2s
something that changes skinname -> SkinName directories for some core
skins, and documentation starts getting changed to say that skins use
CamelCased directory names.
As unhappy as I am with my job revolving around themes and skins, I'm
probably currently the one with the most knowledge on how the internals
of our skinning system work. And it feels like me and one of the +2
maintainers for this skinning stuff in core are being ignored.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://danielfriesen.name/]