Re: [Wikitech-l] Icon area for articles (Re: Anyone with CSS fu ...)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Jun 5, 2010 at 3:33 AM, Rob Lanphier wrote: > Hi everyone, > > In the "CSS fu" thread, we outlined a few problems with the positioning of > the lock icon. This is particularly pronounced in Monobook, where the lock > covers up the "[dismiss]" link on the notification for many of us (maybe > everyone): > http://flaggedrevs.labs.wikimedia.org/wiki/Backmasking?useskin=monobook > > [...snip...] > > So, here's the plan we'd like to pursue: > 1. Short term: Adam is working out a CSS hack that puts the icon somewhere > marginally sensible. > 2. Longer term: we'd like to have a standard area in the skin for things > like this lock, the "featured article" star, and so on. This is more > complicated than it would seem on the surface, because some of those icons > get placed there via template while others are placed there by something in > the PHP. > FYI, on zhwiki we're using a script to arrange those icons. See the template [1] and the implemention in site js [2] (search for "topicon"). However I still like this function to be implemented in MediaWiki rather than in user space. 1. http://zh.wikipedia.org/wiki/Template:Topicon 2. http://zh.wikipedia.org/wiki/MediaWiki:Common.js - -- Jimmy Xu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwJ0xsACgkQwBaNZ/uabwqX4QCgoBhh7f2nrnYJZyf0X1N5I6vS UIcAn1igonIjWMig28Lg9RzuAxkCGQDy =etxN -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pending Changes deployment strategy (Re: Pending Changes (nee Flagged Protection) launch on June 14 (PDT))
2010/6/5 Rob Lanphier : > A couple of different ways of going about it: > 1. Deploy FlaggedRevs, but then drop back to FlaggedRevs_alpha if there's > obvious breakage on one of the other wikis we can't fix quickly > 2. Deploy FlaggedRevs_alpha from the start > > Right now, we really don't want to delay deployment, since delays beget > delays. Thoughts on a preferred strategy? > I don't think strategy #1 makes any sense at all. What I'd do is: * Update FlaggedRevs_alpha to the desired state and check it on the labs wikis * Switch wikis from FlaggedRevs to FlaggedRevs_alpha * The old FlaggedRevs dir now sits around not being used. Leave it like this for a while so we can easily switch wikis back to it * After some time, update FlaggedRevs to be identical to FlaggedRevs_alpha, and switch the wikis back, so we don't drag this _alpha thing along forever. The rationale behind this is that FlaggedRevs is a known-good state more so than FlaggedRevs_alpha. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Pending Changes deployment strategy (Re: Pending Changes (nee Flagged Protection) launch on June 14 (PDT))
On Fri, Jun 4, 2010 at 3:12 PM, Platonides wrote: > Rob Lanphier wrote: > > A full test pass with all of the different configurations isn't going to > be > > possible, so some help with testing the different configurations would be > > wonderful. We'll have a fast fallback plan in place should we > accidentally > > break the other wikis, but obviously it'd be better to get it right the > > first time. > > A bit off topic but, what makes it impossible? It shouldn't be /that/ > hard. Fixing it may be useful for future deployments. Well, it's possible, but it would delay the deployment. One plan we discussed on #wikimedia-tech was to deploy the FlaggedRevs_alpha branch to en.wikipedia.org, rather than deploying the FlaggedRevs trunk. FlaggedRevs_alpha is what is currently running on flaggedrevs.labs.wikimedia A couple of different ways of going about it: 1. Deploy FlaggedRevs, but then drop back to FlaggedRevs_alpha if there's obvious breakage on one of the other wikis we can't fix quickly 2. Deploy FlaggedRevs_alpha from the start Right now, we really don't want to delay deployment, since delays beget delays. Thoughts on a preferred strategy? Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Icon area for articles (Re: Anyone with CSS fu ...)
Aryeh Gregor wrote:
> On Fri, Jun 4, 2010 at 3:39 PM, Chad wrote:
>> This isn't necessarily hard. If there's a specific area in the HTML
>> we can inject them, we could easily add a {{#icon}} parser function
>> or similar that could affect these sorts of icons (and kill the need
>> for CSS hacks to do these)
>
> That sounds perfectly sensible. Probably easier than trying to get
> the CSS to work right, too.
+1
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pending Changes (nee Flagged Protection) launch on June 14 (PDT)
Rob Lanphier wrote: > A full test pass with all of the different configurations isn't going to be > possible, so some help with testing the different configurations would be > wonderful. We'll have a fast fallback plan in place should we accidentally > break the other wikis, but obviously it'd be better to get it right the > first time. A bit off topic but, what makes it impossible? It shouldn't be /that/ hard. Fixing it may be useful for future deployments. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Icon area for articles (Re: Anyone with CSS fu ...)
On Fri, Jun 4, 2010 at 12:33 PM, Rob Lanphier wrote:
> I filed this in Bugzilla so that we have a place to keep track of the
> feature request:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=23796
>
Erik pointed me to some earlier thinking on this subject that's been
floating around a while. Relevant bits of the thread are below:
Rob
-- Forwarded message --
From: Erik Moeller
Date: 2009/7/28
Subject: Fwd: OOB notices in articles
I saw the design mockups by Parul here:
http://usability.wikimedia.org/w/index.php?title=File:Messages.pdf&page=1
We discussed this issue a bit earlier this year - Brion wrote a blog
post about the various kinds of "out of band" article notices here:
http://leuksman.com/log/2009/01/29/e-mail-scams-and-out-of-band-article-notices/
I responded with the suggestion below. This may well be beyond the
scope of the current project, but if we're going to start thinking
about this problem, it is a direction we may want to explore -
basically, a simple syntax to program an intelligent article
notification system that is reader-friendly.
-- Forwarded message --
From: Erik Moeller
Date: 2009/2/2
Subject: OOB notices in articles
To: Brion Vibber
Thanks for the blog post re: OOB notices. I think it's an issue which
we need to address soon, as it has implications for FlaggedRevs and
many other quality-related initiatives.
I think we need a mechanism which I will call, for the moment, the
Notification Box, or NoBo. The NoBo would accept, via MediaWiki code
or templates, information that's relevant about the currently viewed
page, and display it to the user in a customized fashion. The user
could dismiss all of these notifications, some of them, or none of
them.
So, the NoBo could capture the FlaggedRevs state of a given revision,
some NPOV warning an editor added, and even additional metrics such as
Luca's trust assessment ratings. It could also show editor-relevant
information such as the protection status. And of course it could
capture special warnings like the spam notice you mentioned. Ideally,
the user would just click a simple "[X]" link to collapse a warning or
information box, and the software would learn not to show warnings of
that type in their expanded form again.
So, in simple ASCII-art, an example of a page that's labeled as
"unpatrolled" by FlaggedRevs, and as "NPOV dispute" by an editor:
__
| (!) Unreviewed edits [x] |
| (!) Neutrality disputed[x] |
-
When one of them is collapsed, it could show as:
__
| (!) Unpatrolled changes [x] |
------
That is, there would need to be an indicator that further information
is available.
When both of them are collapsed, it would simply show as:
___
| (!) |
Clicking the icon would show the expanded version.
The icons could have at least three levels: information, yellow
warning sign, and red warning sign, used for different kinds of
messages. We could set defaults for collapsed/expanded state depending
on the seriousness level. When summarized to a single state, the most
serious icon would be shown. The text ("Neutrality disputed") could be
clickable for further information.
There would need to be a mechanism, possibly through the MediaWiki
namespace, to define the various warnings in the different levels.
Ideally, to avoid clutter, there would be limits on the text size for
the displayed version. Cookies/JavaScript could be used to record
reader preferences.
Cleaning ugly templates out of the article body in en.wp would be a
nice side-effect. As an editor, I would add a function like
{{#notify:npov}}, probably through a template, which would "feed" the
NoBo. (This does not address the metadata-in-wikitext issue, though I
think that's a separate and solvable problem.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Icon area for articles (Re: Anyone with CSS fu ...)
On Fri, Jun 4, 2010 at 3:39 PM, Chad wrote:
> This isn't necessarily hard. If there's a specific area in the HTML
> we can inject them, we could easily add a {{#icon}} parser function
> or similar that could affect these sorts of icons (and kill the need
> for CSS hacks to do these)
That sounds perfectly sensible. Probably easier than trying to get
the CSS to work right, too.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Icon area for articles (Re: Anyone with CSS fu ...)
On Fri, Jun 4, 2010 at 3:33 PM, Rob Lanphier wrote:
> 2. Longer term: we'd like to have a standard area in the skin for things
> like this lock, the "featured article" star, and so on. This is more
> complicated than it would seem on the surface, because some of those icons
> get placed there via template while others are placed there by something in
> the PHP.
>
This isn't necessarily hard. If there's a specific area in the HTML
we can inject them, we could easily add a {{#icon}} parser function
or similar that could affect these sorts of icons (and kill the need
for CSS hacks to do these)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Icon area for articles (Re: Anyone with CSS fu ...)
Hi everyone, In the "CSS fu" thread, we outlined a few problems with the positioning of the lock icon. This is particularly pronounced in Monobook, where the lock covers up the "[dismiss]" link on the notification for many of us (maybe everyone): http://flaggedrevs.labs.wikimedia.org/wiki/Backmasking?useskin=monobook Aryeh chimed in: On Sun, May 30, 2010 at 8:45 AM, Aryeh Gregor > wrote: > Try just putting [the pending changes lock icon] div right before the id="firstHeading"> or > equivalent, and float: right it. You can put some margins or padding > on the top and/or right to adjust it a bit if you like. Something > like that should work. This will be much more reliable than trying to > absolutely position it, because different skins will use different > heights, and the heights won't be consistent at all in the face of > things like site notices. Everyone who has looked at it agrees we'd like to do it that way. The tricky part is that the other icons aren't being done that way, and the hooks aren't there (currently) to inject the HTML in the best spot. So, here's the plan we'd like to pursue: 1. Short term: Adam is working out a CSS hack that puts the icon somewhere marginally sensible. 2. Longer term: we'd like to have a standard area in the skin for things like this lock, the "featured article" star, and so on. This is more complicated than it would seem on the surface, because some of those icons get placed there via template while others are placed there by something in the PHP. We're heads down on the launch, but if there's any enterprising developers who would like to take on the challenge of solving this right, we'd love to help you do it. It may turn out that the CSS hack is more work than doing it right, so we're putting this out there in hopes that someone will be the hero and fix it right before we figure out how to do it the ugly way. I filed this in Bugzilla so that we have a place to keep track of the feature request: https://bugzilla.wikimedia.org/show_bug.cgi?id=23796 Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Pending Changes (nee Flagged Protection) launch on June 14 (PDT)
Hi everyone, Below is William's update on the Pending Changes (nee Flagged Protection) trial launch on en.wikipedia.org on June 14. As we'll continue to stress: this is a trial, and as such, still has a few rough edges, but we feel we're ready to press forward and commit to iterative improvement after the launch. There are a number of things that we'd love help making sure are good for launch: * Making sure that the latest version of the FlaggedRevs extension will still work for all other sites. Here's a list of the sites that its enabled on: http://noc.wikimedia.org/conf/flaggedrevs.dblist ...along with a list of current configurations: http://noc.wikimedia.org/conf/highlight.php?file=flaggedrevs.php A full test pass with all of the different configurations isn't going to be possible, so some help with testing the different configurations would be wonderful. We'll have a fast fallback plan in place should we accidentally break the other wikis, but obviously it'd be better to get it right the first time. * Test the English test site: http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page * Test the German test site: http://de.labs.wikimedia.org/ * Help with documentation: http://en.wikipedia.org/wiki/Help:Pending_changes * Lots of other stuff I haven't thought of. Let me know if you'd like to help and just want some pointers on where to jump in. Thanks! Rob -- Forwarded message -- From: William Pietri Date: Thu, Jun 3, 2010 at 10:57 PM Subject: [Foundation-l] Pending Changes (nee Flagged Protection) update for June 3 To: English Wikipedia , Wikimedia Foundation Mailing List As requested, here's the weekly Pending Changes update. The big news is that we have picked a date for releasing the new version of Flagged Revisions and launching the trial of Pending Changes on the English Wikipedia: June 14. I'd like to stress that this will be a trial. The goal is to learn, which means that things will not be perfect at launch. There are many areas where we hope to verify our current work and see what improvements can be made: * the technical underpinnings * the interface and language as experienced by * our readers * casual editors * serious editors * reviewers * admins * which articles should be covered * how best to use Pending Changes We think we have something that is workable as is, and have notions for possible improvements down the road. To know what improvements are the right ones, we'll need real use and community feedback. We intend to respond speedily to community concerns and lessons learned from actual use. To that end we aim to keep to the same weekly release schedule that we've been using on labs these last few months. More mundanely, the work completed this week includes ops documentation, the completion of the terminology work, and some interface improvements. We've also had some vigorous testing done by the folks at Calcey, who discovered a few bugs for us. If you'd like to see the current condition of things, you can try it out here: http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page To see the upcoming work, it's listed in our tracker, under Current and Backlog: http://www.pivotaltracker.com/projects/46157 We expect to release to labs again next week, after which we intend to go live on the English Wikipedia. William ___ foundation-l mailing list foundatio...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reasonably efficient interwiki transclusion
-- From: "Dmitriy Sintsov" Sent: Friday, June 04, 2010 11:35 AM To: "Happy-melon" Subject: Re: [Wikitech-l] Reasonably efficient interwiki transclusion > * Happy-melon [Fri, 4 Jun 2010 11:10:04 +0100]: >> >> MW 2.0? :-D >> > Not really. These are pretty simple things, comparing to Parser and some > another classes. MediaWiki class isn't that complex. > >> You wouldn't need to remove the globals, at least immediately; you'd >> retain >> them as aliases for the relevant variables of the 'main' wiki; > assuming >> that >> it makes sense to define one primary wiki, which it usually does. >> > That might introduce glitches where one variable in "global / member > pair" has it's value modified, while another isn't. Or, maybe the > references (&$) will help. > Dmitriy > s/aliases/references, yes. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reasonably efficient interwiki transclusion
-- From: "Dmitriy Sintsov" Sent: Friday, June 04, 2010 11:01 AM To: "Happy-melon" ; "Wikimedia developers" Subject: Re: [Wikitech-l] Reasonably efficient interwiki transclusion > * Happy-melon [Fri, 4 Jun 2010 10:03:14 +0100]: >> >> "Dmitriy Sintsov" wrote in message >> news:1006208056.1275619880.71836632.61...@mcgi66.rambler.ru... >> > * Happy-melon [Fri, 4 Jun 2010 00:33:30 > +0100]: >> >> >> >> >> >> One way to achieve this would be to develop the MediaWiki class to >> >> actually >> >> be what it originally promised: an object representing a wiki, of >> > which >> >> there can in principle be more than one instantiated at any one > time. >> >> Configuration options could determine how the MediaWiki object >> > accesses >> >> data, and consequently what sub-entities it is able to produce. >> >> >> > Current MediaWiki class has some shortcomings. For example, when > I've >> > tried to setup rendering urls in my very own way and not using >> > mod_rewrite, I've "cloned" and "refactored" index.php. The problem > was >> > with the following call: >> > >> > # warning: although instances of OutputPage and others are passed, >> > # they are sometimes used as "fixed" wg* globals in other classes >> > # so you cannot pass a non-global here, or use the different names >> > # of passed instances >> > $MW->initialize( $wgTitle, $wgArticle, $wgOut, $wgUser, $wgRequest > ); >> > >> > First, I've made an instance of OutputPage with variable name >> different >> > from default $wgOut. And $wgArticle, too. The engine didn't work as >> > expected, it still was looking for the default names here and there. > I >> > was forced to use default wgOut and wgArticle names. But, then, > there >> is >> > no real incapsulation and there is no point to pass these as method >> > parameters.. >> > >> > I'd imagine that "emulated" request or api through the local farm > can >> be >> > done really fast, while real remote interwiki call would be done in >> > usual way (api). >> > Dmitriy >> >> Indeed; it does need a lot of work; doing it properly would probably >> deprecate all the state globals ($wg(Title|Parser|Article|Out|Request) >> etc); >> replacing them with member variables of the MediaWiki class. How > other >> classes would access those variables is an interesting question; I > could >> see >> an Article::getWiki()->getOut() chain, but that won't work for static >> functions. It would be a major overhaul, but would probably kill >> several >> birds with one stone. >> > Hundreds of extensions would break :-( Compatibility is a huge burden. A > crude but simpler approach would be having these globals saved in some > context data structure and introduce Farm->switch() method, which would > save/replace all the globals. Much less of core has to be changed, then. > However, that's a bit more unreliable and risky. However, the code is > fragile, anyway (from my exp, one typo sometimes can cause dreaded > errors). > Dmitriy > MW 2.0? :-D You wouldn't need to remove the globals, at least immediately; you'd retain them as aliases for the relevant variables of the 'main' wiki; assuming that it makes sense to define one primary wiki, which it usually does. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] a wysiwyg editor for wikipedia?
* Trevor Parscal [Tue, 01 Jun 2010 11:31:03 -0700]: > In Berlin I gave a quick demo in the UX working group of a new parser > I've been writing that understands the structure and meaning of > Wikitext, rather than just converting it on the fly into HTML like the > current parser (actually a hybrid parser/renderer) does. To be fair, the > current pre-processor does properly parse things into a node-tree, but > only for a small subset of the language, namely templates. My > alternative approach parses the entire wikitext document into a > node-tree, which can then be rendered into HTML (or any format for that > matter) or back to wikitext. By having a unified data-structure for an > entire article, we can do all sorts of things that were never before > possible. > XML and DOM processing probably, too. Traversing / modifying any part(s) of particular wiki page, not just the whole page at once. Though current parser probably just wants to be fast. > What we need is to be looking at building a first-class wikitext-editor, > rather than adapting a buggy HTML editing system (ContentEditable). > Wikitext deserves an editor that thinks in wikitext. Wikitext is a round > peg, and ContentEditable is a square hole. It doesn't matter how much > you try and force it in, it will never fit properly. Google has come to > this conclusion after years of struggling with buggy browsers and poorly > designed APIs. I would prefer not to go down a long road of hardship and > struggles just to come out with a similar conclusion. > Complex.. I wish that would really be possible. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reasonably efficient interwiki transclusion
* Happy-melon [Fri, 4 Jun 2010 10:03:14 +0100]: > > "Dmitriy Sintsov" wrote in message > news:1006208056.1275619880.71836632.61...@mcgi66.rambler.ru... > > * Happy-melon [Fri, 4 Jun 2010 00:33:30 +0100]: > >> > >> > >> One way to achieve this would be to develop the MediaWiki class to > >> actually > >> be what it originally promised: an object representing a wiki, of > > which > >> there can in principle be more than one instantiated at any one time. > >> Configuration options could determine how the MediaWiki object > > accesses > >> data, and consequently what sub-entities it is able to produce. > >> > > Current MediaWiki class has some shortcomings. For example, when I've > > tried to setup rendering urls in my very own way and not using > > mod_rewrite, I've "cloned" and "refactored" index.php. The problem was > > with the following call: > > > > # warning: although instances of OutputPage and others are passed, > > # they are sometimes used as "fixed" wg* globals in other classes > > # so you cannot pass a non-global here, or use the different names > > # of passed instances > > $MW->initialize( $wgTitle, $wgArticle, $wgOut, $wgUser, $wgRequest ); > > > > First, I've made an instance of OutputPage with variable name > different > > from default $wgOut. And $wgArticle, too. The engine didn't work as > > expected, it still was looking for the default names here and there. I > > was forced to use default wgOut and wgArticle names. But, then, there > is > > no real incapsulation and there is no point to pass these as method > > parameters.. > > > > I'd imagine that "emulated" request or api through the local farm can > be > > done really fast, while real remote interwiki call would be done in > > usual way (api). > > Dmitriy > > Indeed; it does need a lot of work; doing it properly would probably > deprecate all the state globals ($wg(Title|Parser|Article|Out|Request) > etc); > replacing them with member variables of the MediaWiki class. How other > classes would access those variables is an interesting question; I could > see > an Article::getWiki()->getOut() chain, but that won't work for static > functions. It would be a major overhaul, but would probably kill > several > birds with one stone. > Hundreds of extensions would break :-( Compatibility is a huge burden. A crude but simpler approach would be having these globals saved in some context data structure and introduce Farm->switch() method, which would save/replace all the globals. Much less of core has to be changed, then. However, that's a bit more unreliable and risky. However, the code is fragile, anyway (from my exp, one typo sometimes can cause dreaded errors). Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reasonably efficient interwiki transclusion
"Dmitriy Sintsov" wrote in message news:1006208056.1275619880.71836632.61...@mcgi66.rambler.ru... > * Happy-melon [Fri, 4 Jun 2010 00:33:30 +0100]: >> >> >> One way to achieve this would be to develop the MediaWiki class to >> actually >> be what it originally promised: an object representing a wiki, of > which >> there can in principle be more than one instantiated at any one time. >> Configuration options could determine how the MediaWiki object > accesses >> data, and consequently what sub-entities it is able to produce. >> > Current MediaWiki class has some shortcomings. For example, when I've > tried to setup rendering urls in my very own way and not using > mod_rewrite, I've "cloned" and "refactored" index.php. The problem was > with the following call: > > # warning: although instances of OutputPage and others are passed, > # they are sometimes used as "fixed" wg* globals in other classes > # so you cannot pass a non-global here, or use the different names > # of passed instances > $MW->initialize( $wgTitle, $wgArticle, $wgOut, $wgUser, $wgRequest ); > > First, I've made an instance of OutputPage with variable name different > from default $wgOut. And $wgArticle, too. The engine didn't work as > expected, it still was looking for the default names here and there. I > was forced to use default wgOut and wgArticle names. But, then, there is > no real incapsulation and there is no point to pass these as method > parameters.. > > I'd imagine that "emulated" request or api through the local farm can be > done really fast, while real remote interwiki call would be done in > usual way (api). > Dmitriy Indeed; it does need a lot of work; doing it properly would probably deprecate all the state globals ($wg(Title|Parser|Article|Out|Request) etc); replacing them with member variables of the MediaWiki class. How other classes would access those variables is an interesting question; I could see an Article::getWiki()->getOut() chain, but that won't work for static functions. It would be a major overhaul, but would probably kill several birds with one stone. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
