I'll not answer all your points. I'd just like to (again) question the need to keep all the names and identifiers of a skin identical whatever the cost. Maybe I am daft, everybody else seems to take this as some given great goal and nobody else is questioning it. As I see it it introduces all kinds of dependencies for no better reason than to not confuse some hypothetical user or admin. Decoupling has apparently gone out of fashion. And it is biting you already, you have or will have to special case and transform identifiers to somehow make it work introducing loads of bugs along the way. It adds more bad design to an already badly flawed skin system.
I18n message names that are directly derived from some value in $wgValidSkinNames? What?
And what's the value of lower-casing the useskin param? If some skin developer thought it was a great idea to use camel case there or upper case or whatever, why do you care? They will get fire from their users soon enough. I think it is a bad idea to convolute core code with special transformations just to protect the users from some skin designers bad decisions. It makes the core code slow and unmaintainable. And in the end it introduces exactly the kind of imprecision into a skin's specs that we are trying to avoid. Because now with all combinations of uc and lc being valid we really have created a case where nobody knows exactly what is supposed to go into this useskin param and why.
Stephan
On 1 June 2014 09:44, Daniel Friesen daniel@nadir-seen-fire.com wrote:
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/]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l