Re: [Wikitech-l] Must 3rd party skins and extensions be distributed under GPL?

Aryeh Gregor wrote: > This is C-oriented, but the application to MediaWiki is fairly clear. > Extensions will invariably make function calls back and forth to core > code, and share data structures (= objects). This conventional > understanding is reflected in MediaWiki's README file, which has >

Re: [Wikitech-l] Disabling magic linking for plaintext URLs

Aryeh Gregor wrote: > On Fri, Jul 23, 2010 at 12:41 PM, Alex Kozak > wrote: >> Ah, ok my apologies. Maybe you could add a note describing some of the >> things that would break to >> http://www.mediawiki.org/wiki/Manual:$wgUrlProtocols? > > I've corrected some inaccuracies on that page. I'm not

Re: [Wikitech-l] Fwd: [Foundation-l] Discussion Questions for Potentially-Objectionable Content

Aryeh Gregor wrote: > On Fri, Jul 23, 2010 at 8:00 AM, Platonides wrote: >> You would need to reparse on edit (which changes categories) all pages >> including the image. Even if the image comes from commons or another >> ForeignRepo. >> Not as easy, I think, but this is a long wanted proposal, se

Re: [Wikitech-l] Fwd: [Foundation-l] Discussion Questions for Potentially-Objectionable Content

Neil Kandalgaonkar wrote: > On 7/23/10 11:28 AM, Aryeh Gregor wrote: >> On Thu, Jul 22, 2010 at 8:23 PM, Neil Kandalgaonkar >> wrote: >>> I meant cached in the same way that skins are cached. Not cached in the >>> sense of having a completely static page. >> >> What do you mean when you talk abou

[Wikitech-l] Experience Team - Insert Template

Dear all, The improvements to the page editing interface by the experience team are great. I especially like the new insert link. I was wondering, whether it is possible to have something similar for templates, maybe with following functionalities: - suggestions for templates are listed while

Re: [Wikitech-l] Fwd: [Foundation-l] Discussion Questions for Potentially-Objectionable Content

On 7/23/10 11:28 AM, Aryeh Gregor wrote: > On Thu, Jul 22, 2010 at 8:23 PM, Neil Kandalgaonkar > wrote: >> I meant cached in the same way that skins are cached. Not cached in the >> sense of having a completely static page. > > What do you mean when you talk about skins being cached? What I mean

Re: [Wikitech-l] Architectural revisions to improve category sorting

On Fri, Jul 23, 2010 at 1:24 PM, Aryeh Gregor wrote: > Okay, so I think I have enough feedback to write up an initial > implementation.  I'll start on that now.  To begin with I'll probably > just stick in a dummy collation function, like use "convert everything > to uppercase" and test it with $w

Re: [Wikitech-l] Disabling magic linking for plaintext URLs

On Fri, Jul 23, 2010 at 12:41 PM, Alex Kozak wrote: > Ah, ok my apologies. Maybe you could add a note describing some of the > things that would break to > http://www.mediawiki.org/wiki/Manual:$wgUrlProtocols? I've corrected some inaccuracies on that page. I'm not even going to *try* to predict

Re: [Wikitech-l] Fwd: [Foundation-l] Discussion Questions for Potentially-Objectionable Content

On Thu, Jul 22, 2010 at 8:23 PM, Neil Kandalgaonkar wrote: > I meant cached in the same way that skins are cached. Not cached in the > sense of having a completely static page. What do you mean when you talk about skins being cached? On Fri, Jul 23, 2010 at 8:00 AM, Platonides wrote: > You woul

Re: [Wikitech-l] Architectural revisions to improve category sorting

On 23 July 2010 09:24, Tei wrote: > This looks like a very important feature, and a hard one to get right. > You guys are real world heros :-) +1 - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/li

Re: [Wikitech-l] Architectural revisions to improve category sorting

On Thu, Jul 22, 2010 at 3:01 AM, Tim Starling wrote: > An alternative would be to add a column to the categorylinks table, > say cl_type. It could be an ENUM or some short text type. Then the > index could be altered to include this field at the start of it. > > Presumably the rationale for combin

Re: [Wikitech-l] Must 3rd party skins and extensions be distributed under GPL?

On Thu, Jul 22, 2010 at 8:57 PM, Andrew Fitzgerald wrote: > Saw an article mentioned on Slashdot about Wordpress themes and plugins > being required to be disributed under the GPL because they are derivative of > Wordpress.  Is this also true for Mediawiki extensions and skins?  It seems > like th

Re: [Wikitech-l] Disabling magic linking for plaintext URLs

Ah, ok my apologies. Maybe you could add a note describing some of the things that would break to http://www.mediawiki.org/wiki/Manual:$wgUrlProtocols? - Alex On Fri, Jul 23, 2010 at 9:22 AM, Aryeh Gregor > wrote: > On Fri, Jul 23, 2010 at 12:04 AM, Alex Kozak > wrote: > > Maybe you could modi

Re: [Wikitech-l] Disabling magic linking for plaintext URLs

On Fri, Jul 23, 2010 at 12:04 AM, Alex Kozak wrote: > Maybe you could modify this array? > http://www.mediawiki.org/wiki/Manual:$wgUrlProtocols > > AK That won't do what he wants. That array is responsible for all sorts of things, and removin

Re: [Wikitech-l] Fwd: [Foundation-l] Discussion Questions for Potentially-Objectionable Content

Aryeh Gregor wrote: > On Thu, Jul 22, 2010 at 4:02 PM, David Gerard wrote: >> This is a perennial proposal. It's an idea I like, as it puts control >> in the hands of the viewer rather than third parties. All it requires >> is someone to code something that passes muster as being unlikely to >> me

Re: [Wikitech-l] Architectural revisions to improve category sorting

This looks like a very important feature, and a hard one to get right. You guys are real world heros :-) -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural revisions to improve category sorting

Hi! > No doubt Domas will complain anyway, but without developers adding new > features, I figure his volunteer DBA work would get very boring. I don't complain about well designed features, especially if they don't scan millions of rows to return 0 ;-) Domas ___