They often have no concept of core wiki things like history, or languages, or models of editing and workflows. Look at all the unsolicited redesigns wikipedia gets - they almost always look pretty, but then fall apart as soon as you try to apply reality to them. In order to make a skin that is widely usable, that has good UX and serves both user needs adequately, that doesn't break, you need to be familiar with what it's skinning - both the frontend components and some abstraction of the underlying platform. The problem, however, is you still need a lot more than just 'pretty' to make something actually worthwhile. I agree that the bar not being high to make something is a good thing. But a great many of them also fail in terms of usability, and sometimes even functionality. Tumblr has a lot of themes, yes, and many of them are quite pretty. T118134: Create an extremely bare-bones RL module, containing basic, simple styles for skins to consume T118332: Investigate what internal classes all generate the final front-end interface T266613: Technical: Separate notifications from personal menu T259955: Skin hooks should not have unexpected side effects to OutputPage T119022: WikiDev 16 working area: Content format Mentioned Here T89981: Split the `legacy` feature on ResourceLoaderSkinModule into non-legacy manageable and reusable parts and deprecate use of the feature T119162: WikiDev 16 working area: User interface presentation T119032: WikiDev 16 working area: Software engineering T119593: Define the list of "must have" sessions for WikiDev '16 T115430: Undeploy the 'Cologne Blue' and 'Modern' skins from Wikimedia production, as no-one is keeping them working T108271: Extension registration does not prefix path in "ResourceLoaderLESSImportPaths" entries T234907: RFC: Where to implement Desktop Improvements project T249673: RFC: A modern and restrictive (but flexible!) skin system using Mustache T254195: Implement a core 'clearfix' mixin in mediawiki.mixin and evaluate deprecation/removal of 'visualClear' class Mentioned In T255100: Consider CSS naming convention/methodology as coding guideline for Wikimedia projects - for making skins with Twitter Bootstrap.- a frontend abstraction for creating a skin without touching the php backend.- how skin changes have happened in the past.Its template that actually outputs page HTML is class Foo Template which usually extends BaseTemplate, which extends QuickTemplate.Your skin Foo is set up in class Skin Foo which extends SkinTemplate.What we have may work, but not well, and not reliably, especially not when the very ways we interact with the wikis themselves are being redefined (VisualEditor, SMW, Echo and Flow, etc). We need to rethink how MediaWiki skinning is handled, from every angle. We need to be able to build on top of this. We need proper interfaces for other extensions to hook into. We need a better basis to build from, we need proper abstraction in the backend that we can expect to remain consistent in the future, too. We need to fix this.Īs extensions, skins have a powerful flexibility built in, able to implement pretty much anything from the ground up, but this should not be necessary for common skin functions. convert P%C3%A1gina_Principal into Página Principal (and the like for other languages) ORģ.Skins are the MediaWiki extensions that output all the content, everything that core and all other extensions produce, and yet they are one of the least well-supported areas of MediaWiki. lookup the translation for 'Main Page' in the language that is currently used ORĢ. The data has no problems with that, but the is saved as /wiki/P%C3%A1gina_Principalġ. In spanish, the page is called Página Principal. (and some more classes of course, but you get the idea)īut this gives me another problem. (the starts with /wiki/, hence the offset of 6) $ismain = $this->data = substr($mainurl,'6') The only solution I´ve thought of so far is take mediawiki´s variable for the main page url and compare it to the current page title: $mainurl = $this->data I want the skin to detect the title automatically. Most solutions I've googled are based on either 'Main Page' or setting your own title. Unfortunately, there's no way to check that. The problem is that in other languages the main page is called differently (and the class changes accordingly), so I either have to add css rules for all possible main page titles (not gonna happen) or do a check inside the skin that adds a class to the body if the current page is the main page. To do this I originally just added some css rules that only applied to the main_page class: body. So far most of it is working, but I want to use a main page that looks different than the rest of the pages. I'm setting up a bunch of different language mediawiki's on one codebase.
0 Comments
Leave a Reply. |