I've co-authored two extensions that need an additional hook and additional parameters to two existing hooks. I am requesting commit access so that I may upload the extensions and amend the hooks.
The first is a spellchecker that I posted here a few months ago: http://code.google.com/p/wikimediaspellchecker/ along with some contributed improvements that I've received.
I understand (based on reading the archives) that this won't be included on wikipedia but it is useful for people who have their own mediawiki installations, at least until ff 2.0 or ie7 become standard everywhere. Some users of our wiki prefer this spellcheck extension over the browser spell checkers and google spell check because of its UI and ability to have separate custom dictionaries per wiki.
Ideally I'd like to commit this to the extensions directory so that it can be more easily improved by interested persons. If that isn't possible I'd like to at least commit a hook addition so that users of this extension don't have to change the mediawiki source every time they download a new version of mediawiki.
The second is a "track changes" / "svn blame" view that shows who is responsible for what portions of an encyclopedia entry.
Here are some screenshots: http://people.virginia.edu/~kjl3d/newlinks.png http://people.virginia.edu/~kjl3d/trackchangesview.png
This is not ready for wikipedia yet but is, again, useful for smaller local instances of mediawiki. Ideally I'd like to get this checked in to the extensions directory so that parties interested in improving it can do so. I'll be updating and improving it for a while but it is usable (and being used locally) as is. I'd also like to commit some additional parameters to a few hooks that this extension uses for the reasons outlined above (users don't have to change the mediawiki source every time they update their mediawiki version).
Therein lies my request for commit access.
On Wed, Dec 13, 2006 at 11:50:30AM -0500, David Grogan wrote:
The second is a "track changes" / "svn blame" view that shows who is responsible for what portions of an encyclopedia entry.
Technical derail: I'm curious: what is your list of colors for identifying contributors? Specifically: *how deep is it*? :-)
I regularly see things identified by color codes which are insufficiently distinguishable from one another. Past 9 or 10, it can get rough...
Cheers, -- jra
Jay R. Ashworth wrote:
On Wed, Dec 13, 2006 at 11:50:30AM -0500, David Grogan wrote:
The second is a "track changes" / "svn blame" view that shows who is responsible for what portions of an encyclopedia entry.
Technical derail: I'm curious: what is your list of colors for identifying contributors? Specifically: *how deep is it*? :-)
I believe it is 64 deep.
I regularly see things identified by color codes which are insufficiently distinguishable from one another. Past 9 or 10, it can get rough...
Yeah, there are only about 8 good ones that are really distinctive, and then after about 20 you can get into some hairy situations. It's not that bad though because usually an off-green is next to an off-red or something. It's only bad when a color and two of its off-colors are all close. I might have it wrap after 10 but add a hover feature that will pop up the contributor's name.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dave Grogan wrote:
Jay R. Ashworth wrote:
I regularly see things identified by color codes which are insufficiently distinguishable from one another. Past 9 or 10, it can get rough...
Yeah, there are only about 8 good ones that are really distinctive, and then after about 20 you can get into some hairy situations. It's not that bad though because usually an off-green is next to an off-red or something. It's only bad when a color and two of its off-colors are all close.
Let's not forget the color-blind and the monochrome screen-users.
I might have it wrap after 10 but add a hover feature that will pop up the contributor's name.
I would strongly suggest using such a hover feature. Pop-ups with links to details might be rather more useful, actually, enabling popping over to the specific diff that made the change.
I do fear how this stuff is going to work on pages with tens of thousands of edits, but... ;)
- -- brion vibber (brion @ pobox.com)
On Wed, Dec 13, 2006 at 11:43:28AM -0800, Brion Vibber wrote:
Dave Grogan wrote:
Jay R. Ashworth wrote:
I regularly see things identified by color codes which are insufficiently distinguishable from one another. Past 9 or 10, it can get rough...
Yeah, there are only about 8 good ones that are really distinctive, and then after about 20 you can get into some hairy situations. It's not that bad though because usually an off-green is next to an off-red or something. It's only bad when a color and two of its off-colors are all close.
Let's not forget the color-blind and the monochrome screen-users.
It's an enhancement; accessibility is *slightly* less important than it is to mainline functionality.
For a while.
IMHO.
(That's not dissing the handicapped; it's a scheduling/priority opinion.)
I might have it wrap after 10 but add a hover feature that will pop up the contributor's name.
I would strongly suggest using such a hover feature. Pop-ups with links to details might be rather more useful, actually, enabling popping over to the specific diff that made the change.
I do fear how this stuff is going to work on pages with tens of thousands of edits, but... ;)
Set fences on the earliest and latest versions it displays? Showing older material in just black on white?
Cheers, -- jra
On Wed, Dec 13, 2006 at 02:12:46PM -0500, Dave Grogan wrote:
Jay R. Ashworth wrote:
On Wed, Dec 13, 2006 at 11:50:30AM -0500, David Grogan wrote:
The second is a "track changes" / "svn blame" view that shows who is responsible for what portions of an encyclopedia entry.
Technical derail: I'm curious: what is your list of colors for identifying contributors? Specifically: *how deep is it*? :-)
I believe it is 64 deep.
That won't be enough. :-)
I regularly see things identified by color codes which are insufficiently distinguishable from one another. Past 9 or 10, it can get rough...
Yeah, there are only about 8 good ones that are really distinctive, and then after about 20 you can get into some hairy situations. It's not that bad though because usually an off-green is next to an off-red or something. It's only bad when a color and two of its off-colors are all close. I might have it wrap after 10 but add a hover feature that will pop up the contributor's name.
You've seen the IBM work on this sort of thing, right?
Should we ever expect it to show the rendered text with these markers, instead of the raw? Cause that'd be outta sight...
Cheers, -- jra
Yeah, there are only about 8 good ones that are really distinctive, and then after about 20 you can get into some hairy situations. It's not that bad though because usually an off-green is next to an off-red or something. It's only bad when a color and two of its off-colors are all close. I might have it wrap after 10 but add a hover feature that will pop up the contributor's name.
You've seen the IBM work on this sort of thing, right?
No. Please inform.
Should we ever expect it to show the rendered text with these markers, instead of the raw? Cause that'd be outta sight...
My comrades and I have discussed this and it is definitely on the table. It seems that the parser would have to (and maybe it already does some of this) report when it was processing a token and also when it was about to display some text. When it was about to throw the text on the page the extension could wrap it in the appropriate color span. I have never looked at the parser so I don't know if that would be feasible.
On Wed, Dec 13, 2006 at 05:10:06PM -0500, Dave Grogan wrote:
Yeah, there are only about 8 good ones that are really distinctive, and then after about 20 you can get into some hairy situations. It's not that bad though because usually an off-green is next to an off-red or something. It's only bad when a color and two of its off-colors are all close. I might have it wrap after 10 but add a hover feature that will pop up the contributor's name.
You've seen the IBM work on this sort of thing, right?
No. Please inform.
In light of your posting today, I guess I'd better get to answering this. I can't find the link I blogged (I'm too witty for my own good, clearly), but I spotted it at Metafilter about 8 months to a year ago, and it was a graphical waterfall style representation of how a Wikipedia page changes over time. ISTR they weren't releasing the code at that time, but the details are lost to me.
I don't know that it's directly relevant to what you want to do, but it might bear investigation. I'll look a little further.
Cheers, -- jra
On 12/15/06, Jay R. Ashworth jra@baylink.com wrote:
On Wed, Dec 13, 2006 at 05:10:06PM -0500, Dave Grogan wrote:
Yeah, there are only about 8 good ones that are really distinctive, and then after about 20 you can get into some hairy situations. It's not that bad though because usually an off-green is next to an off-red or something. It's only bad when a color and two of its off-colors are all close. I might have it wrap after 10 but add a hover feature that will pop up the contributor's name.
You've seen the IBM work on this sort of thing, right?
No. Please inform.
In light of your posting today, I guess I'd better get to answering this. I can't find the link I blogged (I'm too witty for my own good, clearly), but I spotted it at Metafilter about 8 months to a year ago, and it was a graphical waterfall style representation of how a Wikipedia page changes over time. ISTR they weren't releasing the code at that time, but the details are lost to me.
I don't know that it's directly relevant to what you want to do, but it might bear investigation. I'll look a little further.
I think you're referring to this one: http://en.wikipedia.org/wiki/IBM_History_Flow_tool
On Fri, Dec 15, 2006 at 10:54:53AM -0800, Evan Martin wrote:
I don't know that it's directly relevant to what you want to do, but it might bear investigation. I'll look a little further.
I think you're referring to this one: http://en.wikipedia.org/wiki/IBM_History_Flow_tool
I meant that one, yes, Evan; thank you kindly.
Cheers, -- jra
Jay R. Ashworth wrote:
On Wed, Dec 13, 2006 at 02:12:46PM -0500, Dave Grogan wrote:
Jay R. Ashworth wrote:
Technical derail: I'm curious: what is your list of colors for identifying contributors? Specifically: *how deep is it*? :-)
I believe it is 64 deep.
That won't be enough. :-)
I think one could use the binary [[van der Corput sequence]] to construct an unlimited sequence of maximally distinct hues.
"David Grogan" dgrogan@gmail.com wrote in message news:cb6d7dc50612130850s74267de2s2f943af0c1c75224@mail.gmail.com...
I've co-authored two extensions that need an additional hook and additional parameters to two existing hooks. I am requesting commit access so that I may upload the extensions and amend the hooks.
What hook and what parameters?
- Mark Clements (HappyDog)
Mark Clements wrote:
"David Grogan" dgrogan@gmail.com wrote in message news:cb6d7dc50612130850s74267de2s2f943af0c1c75224@mail.gmail.com...
I've co-authored two extensions that need an additional hook and additional parameters to two existing hooks. I am requesting commit access so that I may upload the extensions and amend the hooks.
What hook and what parameters?
- Mark Clements (HappyDog)
To be addded:
The spellchecker needs a hook near the end of getEditToolbar that is passed the toolbar variable. The extension adds a spellcheck button to the toolbar.
To be amended:
Track Changes needs ArticleSaveComplete to also pass $revisionId (id of the newly-saved revision) and a flag that determines whether the content of the article changed.
Track changes needs SkinTemplateTabs to pass in revid and oldid so that it can display oldid if specified in the query string or revid if it was:
$oldid = $wgRequest->getVal( 'oldid' ); global $wgArticle; $revid = $wgArticle ? $wgArticle->getLatest() : 0;
dgrogan@gmail.com
On 13/12/06, Dave Grogan dgrogan@gmail.com wrote:
The spellchecker needs a hook near the end of getEditToolbar that is passed the toolbar variable. The extension adds a spellcheck button to the toolbar.
You couldn't just use the existing JavaScript-based support functions for adding custom edit buttons?
Track Changes needs ArticleSaveComplete to also pass $revisionId (id of the newly-saved revision) and a flag that determines whether the content of the article changed.
That sounds sane enough to me.
Rob Church
"Rob Church" robchur@gmail.com wrote in message news:e92136380612131311x24e8cf0cpe0ad70aeaf678b87@mail.gmail.com...
On 13/12/06, Dave Grogan dgrogan@gmail.com
wrote:
The spellchecker needs a hook near the end of getEditToolbar that is passed the toolbar variable. The extension adds a spellcheck button to the toolbar.
You couldn't just use the existing JavaScript-based support functions for adding custom edit buttons?
Or look at how http://www.mediawiki.org/wiki/Extension:Add_Button does it.
Track Changes needs ArticleSaveComplete to also pass $revisionId (id of the newly-saved revision) and a flag that determines whether the content of the article changed.
That sounds sane enough to me.
I was under the impression that the article was never saved if the content hasn't changed, and therefore the hook wouldn't trigger in that situation anyway.
Also, $revisionID should be available through the article object that is already passed to the hook. If not, then that is where it should be added, not as an extra hook parameter.
Track changes needs SkinTemplateTabs to pass in revid and oldid so that it can display oldid if specified in the query string or revid if it
was:
$oldid = $wgRequest->getVal( 'oldid' ); global $wgArticle; $revid = $wgArticle ? $wgArticle->getLatest() : 0;
Not very clear about this point. Can you elaborate?
- Mark Clements (HappyDog)
Mark Clements wrote:
"Rob Church" robchur@gmail.com wrote in message news:e92136380612131311x24e8cf0cpe0ad70aeaf678b87@mail.gmail.com...
On 13/12/06, Dave Grogan dgrogan@gmail.com
wrote:
The spellchecker needs a hook near the end of getEditToolbar that is passed the toolbar variable. The extension adds a spellcheck button to the toolbar.
You couldn't just use the existing JavaScript-based support functions for adding custom edit buttons?
Or look at how http://www.mediawiki.org/wiki/Extension:Add_Button does it.
Thank you for this link.
Track Changes needs ArticleSaveComplete to also pass $revisionId (id of the newly-saved revision) and a flag that determines whether the content of the article changed.
That sounds sane enough to me.
I was under the impression that the article was never saved if the content hasn't changed, and therefore the hook wouldn't trigger in that situation anyway.
No new revision is saved but the hook is run. See Article.php, lines 1285-90 and 1359-63 in v1.8.2.
Also, $revisionID should be available through the article object that is already passed to the hook. If not, then that is where it should be added, not as an extra hook parameter.
A revisionID is available through the article object, but it is the id of the previously retrieved page, not the newly inserted one. The id of the newly-inserted page is not passed to the hook in any of the current parameters, as far as I can tell (var_dumps and some ctrl-f-ing).
Track changes needs SkinTemplateTabs to pass in revid and oldid so that it can display oldid if specified in the query string or revid if it
was:
$oldid = $wgRequest->getVal( 'oldid' ); global $wgArticle; $revid = $wgArticle ? $wgArticle->getLatest() : 0;
Not very clear about this point. Can you elaborate?
The SkinTemplateTags hook calls an extension function that adds the track changes tab shown in the screenshot. The "track changes" tab needs to pass a parameter to the TrackChanges page telling it what revision to display. The SkinTemplate class has access to wgArticle, so it can pass the id of the article's latest revision. However, if the user is viewing an older revision of the document, as specified by the oldid query parameter, eg http://www.mediawiki.org/w/index.php?title=Extension:Add_Button&oldid=52... then the TrackChanges extension should display that older revision. It is not necessary that both of those be passed in (the logic for figuring out which one to display could be moved from the tab-adding extension to SkinTemplate) but SkinTemplate needs to communicate the requested revision to the extension that adds the "track changes" tab somehow.
"Dave Grogan" dgrogan@gmail.com wrote in message news:elpvs2$umj$1@sea.gmane.org...
Mark Clements wrote: JsoAwUIsXouq+1Nelnf3ueG/Ez6ZCGd0@public.gmane.org
On 13/12/06, Dave Grogan
wrote:
Track Changes needs ArticleSaveComplete to also pass $revisionId (id
of
the newly-saved revision) and a flag that determines whether the
content
of the article changed.
I was under the impression that the article was never saved if the
content
hasn't changed, and therefore the hook wouldn't trigger in that
situation
anyway.
No new revision is saved but the hook is run. See Article.php, lines 1285-90 and 1359-63 in v1.8.2.
Is 'ArticleSave' also run? If not, you could set a variable in ArticleSave and check for it in ArticleSaveComplete. If it _is_ run then that sounds like an error.
Also, $revisionID should be available through the article object that is already passed to the hook. If not, then that is where it should be
added,
not as an extra hook parameter.
A revisionID is available through the article object, but it is the id of the previously retrieved page, not the newly inserted one. The id of the newly-inserted page is not passed to the hook in any of the current parameters, as far as I can tell (var_dumps and some ctrl-f-ing).
So does that mean that the $article passed to the function contains an invalid state - i.e. current content but old revision ID? Or is the whole object the pre-save version of the page? To be honest, both of those sound like a mistake.
Either way, my point still stands - this should be fixed (in whatever way is appropriate) by patching the Article class, not by adding an extra hook parameter.
- Mark Clements (HappyDog)
I was under the impression that the article was never saved if the
content
hasn't changed, and therefore the hook wouldn't trigger in that
situation
anyway.
No new revision is saved but the hook is run. See Article.php, lines 1285-90 and 1359-63 in v1.8.2.
Is 'ArticleSave' also run? If not, you could set a variable in ArticleSave and check for it in ArticleSaveComplete. If it _is_ run then that sounds like an error.
ArticleSave is also run.
In reference to ArticleSaveComplete hook run in Article.php:
So does that mean that the $article passed to the function contains an invalid state - i.e. current content but old revision ID? Or is the whole object the pre-save version of the page? To be honest, both of those sound like a mistake.
The $article is the pre-save version of the page: - mContent contains the pre-saved text - mLatest is one revision behind - mRevision corresponds to the outdated mLatest - mCurrent is set to true (outdatedly) - mLastRevision is similar to mRevision but its mText is null
Either way, my point still stands - this should be fixed (in whatever way is appropriate) by patching the Article class, not by adding an extra hook parameter.
If Article's mLatest and mRevision were updated to reflect the new state of the article and mLastRevision represented the revision that the user loaded in order to change the page, that would work great for me. We're talking about changing parameters - existing extensions relying on the current behavior will break.
The spellchecker needs a hook near the end of getEditToolbar that is passed the toolbar variable. The extension adds a spellcheck button to the toolbar.
You couldn't just use the existing JavaScript-based support functions for adding custom edit buttons?
Or look at how http://www.mediawiki.org/wiki/Extension:Add_Button does it.
It might be possible to use a similar method as this extension. Add_Button stuffs its custom js into the page by way of the ParserBeforeTidy hook. Do you know of a more appropriate hook offhand?
Track changes needs SkinTemplateTabs to pass in revid and oldid so that it can display oldid if specified in the query string or revid if it
was:
$oldid = $wgRequest->getVal( 'oldid' ); global $wgArticle; $revid = $wgArticle ? $wgArticle->getLatest() : 0;
Not very clear about this point. Can you elaborate?
I'd like to retract the paragraph in my previous e-mail. This code was moved entirely into the extension:
global $wgArticle, $wgRequest; $oldid = $wgRequest->getVal( 'oldid' ); $revid = $wgArticle ? $wgArticle->getLatest();
The extra parameters to the SkinTemplateTabs hook are no longer needed.
Thanks.
wikitech-l@lists.wikimedia.org