Mailing List Archive

Decorification of features
I've started a Request for comment on MW for the decorification of MW
features into extensions. I am not talking about removing features that we
distribute to our users. Simply how we include them in the mediawiki
software (core vs extensions) especially now that our new installer allows
us to package extensions in the distribution.

http://www.mediawiki.org/wiki/Requests_for_comment/decorify_into_extensions

I would appreciate hearing the community's thoughts on this. Even if you
feel we're not at that point yet, ask yourself when you will be, and if it's
better to start on a different path now.

- Olivier Finlay Beaton
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On Mon, Sep 26, 2011 at 8:13 AM, Olivier Beaton <olivier.beaton@gmail.com>wrote:

> I've started a Request for comment on MW for the decorification of MW
> features into extensions. I am not talking about removing features that we
> distribute to our users. Simply how we include them in the mediawiki
> software (core vs extensions) especially now that our new installer allows
> us to package extensions in the distribution.
>
> http://www.mediawiki.org/wiki/Requests_for_comment/decorify_into_extensions
>
> I would appreciate hearing the community's thoughts on this. Even if you
> feel we're not at that point yet, ask yourself when you will be, and if
> it's
> better to start on a different path now.
>

Having sat in on some of today's IRC chat along these lines, my basic
comments come down to:

* Broadly speaking, putting modular self-contained features in extensions is
good practice
* Bundling some extensions with the default installer is something I
advocate

I tend to reject parts of your premise though: most
Wikimedia/Wikipedia-specific work today is in fact already being done in
extensions -- and they don't magically migrate to core, they actually mostly
stay as extensions.

Allow me to list the extensions referenced in the config for all our
Wikimedia sites, all of which are extensions and not in core:

include( $IP . '/extensions/PagedTiffHandler/PagedTiffHandler.php' );
include( $IP . '/extensions/timeline/Timeline.php' );
include( $IP . '/extensions/wikihiero/wikihiero.php' );
include( $IP . '/extensions/SiteMatrix/SiteMatrix.php' );
include( $IP . '/extensions/CharInsert/CharInsert.php' );
include( $IP . '/extensions/CheckUser/CheckUser.php' );
include( $IP . '/extensions/ParserFunctions/ParserFunctions.php' );
require( $IP . '/extensions/Cite/Cite.php' );
include( $IP . '/extensions/InputBox/InputBox.php' );
include( $IP . '/extensions/ExpandTemplates/ExpandTemplates.php' );
include( $IP . '/extensions/ImageMap/ImageMap.php' );
include( $IP . '/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php'
);
include( $IP . '/extensions/DoubleWiki/DoubleWiki.php' );
include( $IP . '/extensions/Poem/Poem.php' );
include( $IP . '/extensions/UnicodeConverter/UnicodeConverter.php' );
require( $IP . '/extensions/CategoryTree/CategoryTree.php' );
include( $IP . '/extensions/ProofreadPage/ProofreadPage.php' );
include( $IP . '/extensions/LabeledSectionTransclusion/lst.php' );
include( $IP . '/extensions/SpamBlacklist/SpamBlacklist.php' );
include( $IP . '/extensions/UploadBlacklist/UploadBlacklist.php' );
include( $IP . '/extensions/TitleBlacklist/TitleBlacklist.php' );
include( "$IP/extensions/Quiz/Quiz.php" );
include( "$IP/extensions/Gadgets/Gadgets.php" );
include( $IP . '/extensions/OggHandler/OggHandler.php' );
include( $IP . '/extensions/AssertEdit/AssertEdit.php' );
include( "$IP/extensions/ContactPageFundraiser/ContactPage.php" );
include( "$IP/extensions/FormPreloadPostCache/FormPreloadPostCache.php"
);
include( "$IP/extensions/SkinPerPage/SkinPerPage.php" );
include( "$IP/extensions/skins/Schulenburg/Schulenburg.php" );
include( "$IP/extensions/skins/Tomas/Tomas.php" );
include( "$IP/extensions/skins/Donate/Donate.php" );
include(
"$IP/extensions/ContributionReporting/ContributionReporting.php" );
include( "$IP/extensions/ExtensionDistributor/ExtensionDistributor.php"
);
include( $IP . '/extensions/GlobalBlocking/GlobalBlocking.php' );
include( $IP . '/extensions/TrustedXFF/TrustedXFF.php' );
include( $IP . '/extensions/ContactPage/ContactPage.php' );
include( $IP . '/extensions/SecurePoll/SecurePoll.php' );
include( "$IP/extensions/EmailCapture/EmailCapture.php" );
include "$IP/extensions/TitleKey/TitleKey.php";
include( $IP . '/extensions/OAI/OAIRepo.php' );
include( $IP . '/extensions/intersection/DynamicPageList.php' );
include( $IP . '/extensions/Renameuser/SpecialRenameuser.php' );
include( $IP . '/extensions/Nuke/SpecialNuke.php' );
include( "$IP/extensions/AntiBot/AntiBot.php" );
include( "$IP/extensions/TorBlock/TorBlock.php" );
include( "$IP/extensions/RSS/RSS.php" );
require( $IP . '/extensions/ScanSet/ScanSet.php' );
require( $IP . '/extensions/Cite/SpecialCite.php' );
require( "$IP/extensions/UserThrottle/UserThrottle.php" );
require( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
require( "$IP/extensions/ConfirmEdit/FancyCaptcha.php" );
require( "$IP/extensions/Oversight/HideRevision.php" );
include $IP . '/extensions/AntiSpoof/AntiSpoof.php';
include "$IP/extensions/CentralAuth/CentralAuth.php";
require(
"$IP/extensions/DismissableSiteNotice/DismissableSiteNotice.php" );
include "$IP/extensions/CentralNotice/CentralNotice.php";
include "$IP/extensions/WikimediaMessages/WikimediaMessages.php";
include "$IP/extensions/WikimediaMessages/WikimediaLicenseTexts.php";
include "$IP/extensions/SimpleAntiSpam/SimpleAntiSpam.php";
include "$IP/extensions/Collection/Collection.php";
include "$IP/extensions/NewUserMessage/NewUserMessage.php";
include "$IP/extensions/CodeReview/CodeReview.php";
include "$IP/extensions/AbuseFilter/AbuseFilter.php";
include ( "$IP/extensions/ClientSide/ClientSide.php" );
include ( "$IP/extensions/CommunityVoice/CommunityVoice.php" );
include ( "$IP/extensions/PdfHandler/PdfHandler.php" );
require( "$IP/extensions/Vector/Vector.php" );
require( "$IP/extensions/WikiEditor/WikiEditor.php" );
require_once( "$IP/extensions/PrefStats/PrefStats.php" );
require_once( "$IP/extensions/PrefSwitch/PrefSwitch.php" );
require "$IP/extensions/UserDailyContribs/UserDailyContribs.php";
require "$IP/extensions/ClickTracking/ClickTracking.php";
include "$IP/extensions/CustomUserSignup/CustomUserSignup.php";
require_once( "$IP/extensions/ReaderFeedback/ReaderFeedback.php" );
require_once( "$IP/extensions/LocalisationUpdate/LocalisationUpdate.php"
);
require_once( "$IP/extensions/LandingCheck/LandingCheck.php" );
require "$IP/extensions/FundraiserPortal/FundraiserPortal.php";
require_once(
"$IP/extensions/DonationInterface/donate_interface/donate_interface.php" );
require_once(
"$IP/extensions/DonationInterface/payflowpro_gateway/payflowpro_gateway.php"
);
require_once( "$IP/extensions/GlobalUsage/GlobalUsage.php" );
require_once( "$IP/extensions/ArticleFeedback/ArticleFeedback.php" );
require_once(
"$IP/extensions/StrategyWiki/ActiveStrategy/ActiveStrategy.php" );
require_once( "$IP/extensions/CommunityHiring/CommunityHiring.php" );
require_once(
"$IP/extensions/CommunityApplications/CommunityApplications.php" );
include( "$IP/extensions/VariablePage/VariablePage.php" );
include( "$IP/extensions/ContributionTracking/ContributionTracking.php"
);
require_once( "$IP/extensions/UploadWizard/UploadWizard.php" );
require_once( "$IP/extensions/Narayam/Narayam.php" );
include( "$IP/extensions/GoogleNewsSitemap/GoogleNewsSitemap.php" );
require_once( "$IP/extensions/cldr/cldr.php" );
require_once( "$IP/extensions/DisableAccount/DisableAccount.php" );
require_once( "$IP/extensions/WikimediaIncubator/WikimediaIncubator.php"
);
require_once( "$IP/extensions/WikiLove/WikiLove.php" );
require_once( "$IP/extensions/EditPageTracking/EditPageTracking.php" );
require_once( "$IP/extensions/MoodBar/MoodBar.php" );
require_once( "$IP/extensions/MobileFrontend/MobileFrontend.php" );
include( "$IP/extensions/SubPageList3/SubPageList3.php" );
require_once( "$IP/extensions/Math/Math.php" ); // Math move out from
core in MW 1.18
require_once( "$IP/extensions/Babel/Babel.php" );


Things like LanguageConverter have been in MediaWiki for several years and
date to younger times for the extension interface. Math wasn't broken out
into an extension until 1.18 because it predates the extension interface
entirely! Some also work along both language- and functional lines --
LanguageConverter could perhaps turn into its own module, but then where do
we bundle the language rules?

In general, things that are infrastructural -- that provide bases for other
things to work with -- are probably not unreasonable to leave where they
are.

-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On 26 September 2011 21:50, Brion Vibber <brion@pobox.com> wrote:

> On Mon, Sep 26, 2011 at 8:13 AM, Olivier Beaton <olivier.beaton@gmail.com
> >wrote:
>
> Things like LanguageConverter have been in MediaWiki for several years and
> date to younger times for the extension interface. Math wasn't broken out
> into an extension until 1.18 because it predates the extension interface
> entirely! Some also work along both language- and functional lines --
> LanguageConverter could perhaps turn into its own module, but then where do
> we bundle the language rules?
>
> In general, things that are infrastructural -- that provide bases for other
> things to work with -- are probably not unreasonable to leave where they
> are.
>
> -- brion
>
> LanguageConverter would be a bitch to move out only because there are
precious few people who could tell us how it's *supposed* to work, let alone
whether it still works after we change anything in it. But LC doesn't AFAIK
form any sort of 'infrastructure': it's a bolt-on module that's rightly
disabled most places because it requires compiled binaries. Just like Math,
in fact. As you said on IRC, LC does sport some elements (db tables etc)
that Math doesn't, but nothing that's not commonly found in extensions of
various types.

--HM
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On Mon, Sep 26, 2011 at 2:49 PM, Happy Melon <happy.melon.wiki@gmail.com>wrote:

> > LanguageConverter would be a bitch to move out only because there are
> precious few people who could tell us how it's *supposed* to work, let
> alone
> whether it still works after we change anything in it. But LC doesn't
> AFAIK
> form any sort of 'infrastructure': it's a bolt-on module that's rightly
> disabled most places because it requires compiled binaries.


Per IRC the 'compiled binaries' apparently referred to the Chinese
conversion-table-generation code in includes/zhtable -- which is used only
to freshly rebuild the conversion tables elsewhere in the source.

First, no binaries need be compiled for use of the conversion; it is
completely unlike the Math situation.


Second, it's not as monolithic as you think. :) There are implementations of
LanguageConverter for several different languages, each of which has to
provide mapping tables etc:

gan (Gan Chinese)
iu (Inuktitut)
kk (Kazakh)
ku (Kurdish)
shi (Tachelhit)
sr (Serbian)
tg (Tagalog)
zh (Han Chinese)

These are mostly bundled in the language classes; Chinese puts the tables in
separate files due to size and just has its code in the language class file.

Basically, if you were to run a wiki *at all* in Chinese, Serbian, Kurdish,
Tagalog, Inuktitut, Tachelhit, etc -- you'd probably want to do it with the
conversion support.

So, there's a base class which is a dependency for languages shipped with
core (such as Chinese, a fairly widely-spoken language ;) and the various
languages extend those base classes and bundle their own data.

In a hypothetically more modular layout you might then have something like:

* LanguageConverter is its own module
* - provides LanguageConverter class

* LanguageZh is its own module
* - depends on LanguageConverter class
* - provides ZhLanguageConverter class
* - provides data sources for ZhLanguageConverter
* - provides LanguageZh class
* - provies zh messages

and any install that includes Chinese, Serbian, Kurdish, Tagalog, Inuktitut,
Tachelhit, etc would then in some way trigger the LanguageConverter
dependency and install both modules.

This is same kind of dependency structure might be nice for the Narayam
input method editor -- for languages that frequently don't have native OS
support it can be very nice to bundle the IME along with the language
support.

-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On 11-09-26 03:09 PM, Brion Vibber wrote:
> On Mon, Sep 26, 2011 at 2:49 PM, Happy Melon <happy.melon.wiki@gmail.com>wrote:
>
>>> LanguageConverter would be a bitch to move out only because there are
>> precious few people who could tell us how it's *supposed* to work, let
>> alone
>> whether it still works after we change anything in it. But LC doesn't
>> AFAIK
>> form any sort of 'infrastructure': it's a bolt-on module that's rightly
>> disabled most places because it requires compiled binaries.
>
> Per IRC the 'compiled binaries' apparently referred to the Chinese
> conversion-table-generation code in includes/zhtable -- which is used only
> to freshly rebuild the conversion tables elsewhere in the source.
>
> First, no binaries need be compiled for use of the conversion; it is
> completely unlike the Math situation.
>
>
> Second, it's not as monolithic as you think. :) There are implementations of
> LanguageConverter for several different languages, each of which has to
> provide mapping tables etc:
>
> gan (Gan Chinese)
> iu (Inuktitut)
> kk (Kazakh)
> ku (Kurdish)
> shi (Tachelhit)
> sr (Serbian)
> tg (Tagalog)
> zh (Han Chinese)
>
> These are mostly bundled in the language classes; Chinese puts the tables in
> separate files due to size and just has its code in the language class file.
>
> Basically, if you were to run a wiki *at all* in Chinese, Serbian, Kurdish,
> Tagalog, Inuktitut, Tachelhit, etc -- you'd probably want to do it with the
> conversion support.
>
> So, there's a base class which is a dependency for languages shipped with
> core (such as Chinese, a fairly widely-spoken language ;) and the various
> languages extend those base classes and bundle their own data.
>
> In a hypothetically more modular layout you might then have something like:
>
> * LanguageConverter is its own module
> * - provides LanguageConverter class
>
> * LanguageZh is its own module
> * - depends on LanguageConverter class
> * - provides ZhLanguageConverter class
> * - provides data sources for ZhLanguageConverter
> * - provides LanguageZh class
> * - provies zh messages
>
> and any install that includes Chinese, Serbian, Kurdish, Tagalog, Inuktitut,
> Tachelhit, etc would then in some way trigger the LanguageConverter
> dependency and install both modules.
>
> This is same kind of dependency structure might be nice for the Narayam
> input method editor -- for languages that frequently don't have native OS
> support it can be very nice to bundle the IME along with the language
> support.
>
> -- brion
Just an interesting site note on LanguageConverter.

We actually have a bug open for adding a LanguageConverter that'll
convert between en-US/en-GB... maybe even en-CA/en-AU hopefully.
https://bugzilla.wikimedia.org/show_bug.cgi?id=31015

If that bug gets implemented... well then, "disabled in most places"
becomes "enabled just short of everywhere"...

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
Thing's I'd like to see in extensions and shipped with the default
install (maybe not each item in it's own, a lot of these could be
grouped)

Maintenance reports
* Broken redirects
* Dead-end pages
* Double redirects
* Long pages
* Oldest pages
* Orphaned pages
* Pages with the fewest revisions
* Pages without language links
* Protected pages
* Protected titles
* Short pages
* Uncategorized categories
* Uncategorized files
* Uncategorized pages
* Uncategorized templates
* Unused categories
* Unused files
* Unused templates
* Unwatched pages
* Wanted categories
* Wanted files
* Wanted pages
* Wanted templates
Recent changes and logs
* Gallery of new files
* My watchlist
* New pages
* Recent changes
* Related changes
Media reports and uploads
* File path
* MIME search
* Search for duplicate files
Wiki data and tools
* Popular pages
* Statistics (just the presentation, not the backend system)
* System messages
Redirecting special pages
* External links
* Random page
* Random redirect
High use pages
* Most linked-to categories
* Most linked-to files
* Most linked-to pages
* Most linked-to templates
* Pages with the most categories
* Pages with the most revisions
Page tools
* Compare pages
* Export pages (not the api, which can do this)
* Global file usage
*Global template usage
* Import pages (not the api, which can do this)
Other special pages
* Book sources

* Watchlist system

I'm not saying these aren't useful, in fact I bet a few would be used
everywhere. So ship them in related-groups as extensions that come
default-on. It really should be up to system admins if they want to
keep them. It would also mean that for almost any given special page
you always know which folder to go into. Why maintain two different
places for special pages and their translations? Some of these I'd
also love to see alternatives to, I'm sure a lot can be done GUI wise
and if you want to use an alternative an admin might not want to keep
the old one, and present a cohesive package to her users.

Chad also joked about making the parser an extension, and I'm no
expert on it but given how much trouble WYSIWYG editors are having
with our wiki syntax, I wouldn't mind being able to say "yeah sure
this is a wiki from scratch, I'll accept the CKeditor syntax instead"
and have one that works great (and has show source!) Especially if I
could mark all current pages as using Parser A, and new pages or edits
get converted to Parser B.

In the end I think what decorifing brings to the table is:
* Freedom of choice through modular programming, creating an extremely
strong plugin/extension system
* Atomic entities that are easier to test independent of each other
and translate
* Able to transition from testing an alternative to making it the
default seamless and almost risk-free. Think about it, if the default
is an extension that is hooked in, it's trivial to ship an alternative
"up and comer" alongside it for people to try, and if it becomes more
attractive, you can just flip the switch and make it the new default.
People who prefer the old can go back to it.

You maintain the idea of shipping a "complete" package to your users
by bundling extensions (as Brion mentioned) and you foster and promote
a very healthy contributing community by making the barrier to entry
low and the rewards higher.

I'm very new to this community, and Brion seemed to indicate that this
was already the plan, but that wasn't the story I was getting
elsewhere. Nevertheless I apologise if I'm talking a little too loudly
to the choir. I hope I can get up to speed on what's going on very
quickly, by exploring the lists and documentation (you've got a
decade's worth! please be patient), voicing my thoughts and questions.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
Olivier Beaton wrote:
> Thing's I'd like to see in extensions and shipped with the default
> install (maybe not each item in it's own, a lot of these could be
> grouped)

I think you're being too bold here (eg. Special:Statistics but keeping
the statistics core). Although I agree that most of those maintenance
reports special pages deserve being rewritten using magic categories.
Similarly, for special pages Export and Import, I oppose to remove the
interfaces just for removing. It's almost as silly as having to install
an Android app just to be able to set the proxy in your browser (real
sample!).
And for others, such as Watchlist, it isn't as simple to split as they
are more highly tied, although there may be a benefit there in doing it.


> Why maintain two different places for special pages and their translations?
I don't consider this an issue for translations. Admins aren't expected
to edit the php files.

> Chad also joked about making the parser an extension, and I'm no
> expert on it but given how much trouble WYSIWYG editors are having
> with our wiki syntax, I wouldn't mind being able to say "yeah sure
> this is a wiki from scratch, I'll accept the CKeditor syntax instead"
> and have one that works great (and has show source!) Especially if I
> could mark all current pages as using Parser A, and new pages or edits
> get converted to Parser B.

I don't think it's as difficult as people think. You just need to
provide a parser with the same interface providing the different dialect
and enable it with $wgParserConf



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On 11-09-27 06:37 AM, Olivier Beaton wrote:
> * Recent changes
This is as ridiculous as removing diffs completely. Revisions, the
ability to diff between them, and a list of changes are three key core
features. If you're going to get rid of any of them you might as well
just stop using MediaWiki.

> * File path
Special:Filepath is an important special page for linking. If you have
uploads then Special:Filepath is the only way for bots and other 3rd
party tools to reliably get a link to a media file. If we get rid of
Special:Filepath we get rid of the one thing making a rewrite of the
upload system and paths used a reasonable possibility.

> * System messages
And what happens when you need to track down a message so you can
customize your wiki?

> * Export pages (not the api, which can do this)
> * Import pages (not the api, which can do this)
No, the API is not an acceptable alternative to the Export/Import system.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
Woah woah woah, I definitely didn't (and would never) say you would'nt
have these things in your wiki, or that mediawiki shouldn't ship with
them.

Currently there are two Recent changes in core, and a few extensions
that have alternatives as well. I don't see why some are extensions
and some are core, why not just have them all as extensions and ship
with one/two of the most popular?

Why are bots using a Special page instead of the api? Really bots
should use the api, and anything else at least in my mind is a hack
(of which I admit to write my own share). Sounds like the api needs to
be extended if it doesn't fulfil this role. But again I didn't say
don't have this page, just don't have it as core. Still ship with it,
as an extension.

Same with System Messages and Export/Import. Especially Export/Import,
I can see people writing great alternatives to those that give me
other options the default ones don't.

From the last two messages I really want to stress that there is a
difference between moving something from core into an extension which
is then bundled into the mediawiki distribution, and not shipping with
a feature at all. I'm all for a feature-rich distribution. I just
think the core should be for absolute necessities only (KISS) and
extensions should provide all the other jazz. That way the core is
small, understandable, documentable and testable. Each extension in
turn doesn't directly interact with a hundred other bits of code, just
their own and the core.

I think everything would be easier with these smaller chunks.

Of course there is a danger of going too far, at what point do you
keep splitting things, and it becomes a big spaghetti mess of modules
everywhere.

There is definitely a line to walk, and while you may not agree with
every item (or many) in my example list, I'm trying to present the
benefits of the philosophy and mantra "not essential? put it in an
extension" and then shipping with it if it's great (maybe even ship
with good alternatives!)

On Tue, Sep 27, 2011 at 4:52 PM, Daniel Friesen
<lists@nadir-seen-fire.com> wrote:
> On 11-09-27 06:37 AM, Olivier Beaton wrote:
>> * Recent changes
> This is as ridiculous as removing diffs completely. Revisions, the
> ability to diff between them, and a list of changes are three key core
> features. If you're going to get rid of any of them you might as well
> just stop using MediaWiki.
>
>> * File path
> Special:Filepath is an important special page for linking. If you have
> uploads then Special:Filepath is the only way for bots and other 3rd
> party tools to reliably get a link to a media file. If we get rid of
> Special:Filepath we get rid of the one thing making a rewrite of the
> upload system and paths used a reasonable possibility.
>
>> * System messages
> And what happens when you need to track down a message so you can
> customize your wiki?
>
>> * Export pages (not the api, which can do this)
>> * Import pages (not the api, which can do this)
> No, the API is not an acceptable alternative to the Export/Import system.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On 11-09-27 02:18 PM, Olivier Beaton wrote:
> Woah woah woah, I definitely didn't (and would never) say you would'nt
> have these things in your wiki, or that mediawiki shouldn't ship with
> them.
>
> Currently there are two Recent changes in core, and a few extensions
> that have alternatives as well. I don't see why some are extensions
> and some are core, why not just have them all as extensions and ship
> with one/two of the most popular?
Care to point out an extension that provides a custom RC page?
The only ones I remember I couldn't track down the source code for or
were complete hacks that rewrote html which naturally would never be
accepted into core or a bundle.

> Why are bots using a Special page instead of the api? Really bots
> should use the api, and anything else at least in my mind is a hack
> (of which I admit to write my own share). Sounds like the api needs to
> be extended if it doesn't fulfil this role. But again I didn't say
> don't have this page, just don't have it as core. Still ship with it,
> as an extension.
It's not just bots, it's also used for interwiki embedding of images. I
think I've even used it in the .css of some wiki.
Special:Filepath is a guarantee that if you have File:Foo.png you can
use Special:Filepath/Foo.png and always have it point to the right image.

Simple redirection from a filename to a image path is outside of the
scope of the api.

> Same with System Messages and Export/Import. Especially Export/Import,
> I can see people writing great alternatives to those that give me
> other options the default ones don't.
Then write them... having something in core doesn't preclude creating
something better. Moving them out of core doesn't make it any more
likely that someone will write alternatives than providing a way to
override them... which should already be possible.

> From the last two messages I really want to stress that there is a
> difference between moving something from core into an extension which
> is then bundled into the mediawiki distribution, and not shipping with
> a feature at all. I'm all for a feature-rich distribution. I just
> think the core should be for absolute necessities only (KISS) and
> extensions should provide all the other jazz. That way the core is
> small, understandable, documentable and testable. Each extension in
> turn doesn't directly interact with a hundred other bits of code, just
> their own and the core.
>
> I think everything would be easier with these smaller chunks.
>
> Of course there is a danger of going too far, at what point do you
> keep splitting things, and it becomes a big spaghetti mess of modules
> everywhere.
>
> There is definitely a line to walk, and while you may not agree with
> every item (or many) in my example list, I'm trying to present the
> benefits of the philosophy and mantra "not essential? put it in an
> extension" and then shipping with it if it's great (maybe even ship
> with good alternatives!)
>
> On Tue, Sep 27, 2011 at 4:52 PM, Daniel Friesen
> <lists@nadir-seen-fire.com> wrote:
>> On 11-09-27 06:37 AM, Olivier Beaton wrote:
>>> * Recent changes
>> This is as ridiculous as removing diffs completely. Revisions, the
>> ability to diff between them, and a list of changes are three key core
>> features. If you're going to get rid of any of them you might as well
>> just stop using MediaWiki.
>>
>>> * File path
>> Special:Filepath is an important special page for linking. If you have
>> uploads then Special:Filepath is the only way for bots and other 3rd
>> party tools to reliably get a link to a media file. If we get rid of
>> Special:Filepath we get rid of the one thing making a rewrite of the
>> upload system and paths used a reasonable possibility.
>>
>>> * System messages
>> And what happens when you need to track down a message so you can
>> customize your wiki?
>>
>>> * Export pages (not the api, which can do this)
>>> * Import pages (not the api, which can do this)
>> No, the API is not an acceptable alternative to the Export/Import system.
>>
>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On 27 September 2011 22:38, Daniel Friesen <lists@nadir-seen-fire.com>wrote:

> On 11-09-27 02:18 PM, Olivier Beaton wrote:
> >>> * File path
> >> Special:Filepath is an important special page for linking. If you have
> >> uploads then Special:Filepath is the only way for bots and other 3rd
> >> party tools to reliably get a link to a media file. If we get rid of
> >> Special:Filepath we get rid of the one thing making a rewrite of the
> >> upload system and paths used a reasonable possibility.
>

We should just make http://my.wiki/wiki/Media:Foo.jpg redirect to the
appropriate url; simple and effective. There's really no need for a special
page for this. Although now that it's in, we can't really get rid of it...
:-(

--HM
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
> On 11-09-27 02:18 PM, Olivier Beaton wrote:
>> Woah woah woah, I definitely didn't (and would never) say you would'nt
>> have these things in your wiki, or that mediawiki shouldn't ship with
>> them.
>>
>> Currently there are two Recent changes in core, and a few extensions
>> that have alternatives as well. I don't see why some are extensions
>> and some are core, why not just have them all as extensions and ship
>> with one/two of the most popular?
> Care to point out an extension that provides a custom RC page?
> The only ones I remember I couldn't track down the source code for or
> were complete hacks that rewrote html which naturally would never be
> accepted into core or a bundle.

http://www.mediawiki.org/wiki/Extension:CleanChanges does that.
Description: Clean changes extension is based on enhanced changes list,
but it tries to by more concise, hiding less important information by
default. It needs JavaScript to be fully functional. It works best in
wikis where changes per user ratio is high.

Siebrand


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On 11-09-27 05:58 PM, Siebrand Mazeland wrote:
>> On 11-09-27 02:18 PM, Olivier Beaton wrote:
>>> Woah woah woah, I definitely didn't (and would never) say you would'nt
>>> have these things in your wiki, or that mediawiki shouldn't ship with
>>> them.
>>>
>>> Currently there are two Recent changes in core, and a few extensions
>>> that have alternatives as well. I don't see why some are extensions
>>> and some are core, why not just have them all as extensions and ship
>>> with one/two of the most popular?
>> Care to point out an extension that provides a custom RC page?
>> The only ones I remember I couldn't track down the source code for or
>> were complete hacks that rewrote html which naturally would never be
>> accepted into core or a bundle.
> http://www.mediawiki.org/wiki/Extension:CleanChanges does that.
> Description: Clean changes extension is based on enhanced changes list,
> but it tries to by more concise, hiding less important information by
> default. It needs JavaScript to be fully functional. It works best in
> wikis where changes per user ratio is high.
>
> Siebrand
Hmmm... we could use a new rc request variable.
Rather than this &oldrc= &newrc= &cleanrc= stuff we should switch to
something like just &rctype={classic,enhanced,clean}.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On Wed, Sep 28, 2011 at 12:49 AM, Happy Melon <happy.melon.wiki@gmail.com>wrote:

> On 27 September 2011 22:38, Daniel Friesen <lists@nadir-seen-fire.com
> >wrote:
>
> > On 11-09-27 02:18 PM, Olivier Beaton wrote:
> > >>> * File path
> > >> Special:Filepath is an important special page for linking. If you have
> > >> uploads then Special:Filepath is the only way for bots and other 3rd
> > >> party tools to reliably get a link to a media file. If we get rid of
> > >> Special:Filepath we get rid of the one thing making a rewrite of the
> > >> upload system and paths used a reasonable possibility.
> >
>
> We should just make http://my.wiki/wiki/Media:Foo.jpg redirect to the
> appropriate url; simple and effective. There's really no need for a
> special
> page for this. Although now that it's in, we can't really get rid of it...
> :-(
>
> --HM
>

That, and that Special:FilePath also supports a width parameter to get the
path to a thumbnail without having to calculate it's dimensions, make
assumptions about the upload path or make one or more API requests. And it
links to the original size if the requested width is larger than the
original width.

--
Krinkle
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Decorification of features [ In reply to ]
On Tue, Sep 27, 2011 at 9:19 PM, Daniel Friesen
<lists@nadir-seen-fire.com> wrote:
> Hmmm... we could use a new rc request variable.
> Rather than this &oldrc= &newrc= &cleanrc= stuff we should switch to
> something like just &rctype={classic,enhanced,clean}.
>

URL parameters are kind of ugly for this.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l