Here's an idea. Have a "maintenance mode" preference for editors that highlights errors in Wikipedia articles so they're easy to spot and fix. For example: - Links that go to disambiguation pages - Links that go to redirects (not necessarily errors, but worth checking) - Broken syntax - make it big and red and ugly rather than gracefully degrading. - Spelling errors, possibly? - Stuff that goes against MoS (for example, level 1 headings, links in headings...)
There are already tools to do this, but they rely on a user making the (pretty significant effort) to get AWB and decide that they're going to do maintenance. Integrating highlighting like this into normal Wikipedians' daily routine would be a lot more effective. And certain problems like links going to disambig pages are really hard to pick up unless you're specifically looking for them.
Any takers?
Steve
On 20/01/07, Steve Bennett stevagewp@gmail.com wrote:
- Links that go to disambiguation pages
Depends upon finding a decent solution for http://bugzilla.wikimedia.org/show_bug.cgi?id=6754#c8.
- Spelling errors, possibly?
British, Australian or American English? We get enough editing disputes as it is. What about all the other languages we support? We'd have to maintain dictionaries, and we don't even have full maintenance of our *translations* at the moment.
- Stuff that goes against MoS (for example, level 1 headings, links in
headings...)
"MoS" is extremely variant from wiki to wiki and could change on a whim, which would mean software changes.
Rob Church
On 1/21/07, Rob Church robchur@gmail.com wrote:
On 20/01/07, Steve Bennett stevagewp@gmail.com wrote:
- Links that go to disambiguation pages
Depends upon finding a decent solution for http://bugzilla.wikimedia.org/show_bug.cgi?id=6754#c8.
So I see. Looks like a useful thing for a variety of other reasons, too.
- Spelling errors, possibly?
British, Australian or American English? We get enough editing disputes as it is. What about all the other languages we support? We'd have to maintain dictionaries, and we don't even have full maintenance of our *translations* at the moment.
That problem is easy at least: http://en.wikipedia.org/wiki/WP:AWB/T The rule is easy: if a spelling is correct in *any* variation, don't propose it as a mistake.
- Stuff that goes against MoS (for example, level 1 headings, links in
headings...)
"MoS" is extremely variant from wiki to wiki and could change on a whim, which would mean software changes.
Yes. Perhaps any such "style violations" should be configurable through a config page of some sort. Or simply that rules be codified and set as preferences: "Highlight formatting in section headings [yes/no]"
Incidentally, I think Platonides is right about CSS. I was thinking about this afterwards and realised it could pose a problem for caching if an error-highlighted page had to be stored separately from a non-highlighted page. But you could actually just mark all the highlighting with a CSS class and make it display as plain text for users not in "maintenance mode".
Would this be a lot of work, do you think?
Steve
Steve Bennett wrote:
Here's an idea. Have a "maintenance mode" preference for editors that highlights errors in Wikipedia articles so they're easy to spot and fix. For example:
- Links that go to disambiguation pages
- Links that go to redirects (not necessarily errors, but worth checking)
They should have their own CSS class, so you could show them different.
On 20/01/07, Platonides Platonides@gmail.com wrote:
They should have their own CSS class, so you could show them different.
For redirect pages, at least, this has been proposed before and closed WONTFIX; see http://bugzilla.wikimedia.org/show_bug.cgi?id=4709.
Rob Church
Rob Church escribió:
On 20/01/07, Platonides Platonides@gmail.com wrote:
They should have their own CSS class, so you could show them different.
For redirect pages, at least, this has been proposed before and closed WONTFIX; see http://bugzilla.wikimedia.org/show_bug.cgi?id=4709.
Rob Church
Interesting. What was the reason? On the last proposal (#5) there are no performance issues, adds no difference for the normal user and seems easy to do.
On 20/01/07, Platonides Platonides@gmail.com wrote:
Interesting. What was the reason?
I assume you'll be insulted if I assume you can't read.
Rob Church
Rob Church wrote:
On 20/01/07, Platonides Platonides@gmail.com wrote:
Interesting. What was the reason?
I assume you'll be insulted if I assume you can't read.
Either there is no reason given in the bug, or he and I both can't read.
Timwi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timwi wrote:
Rob Church wrote:
On 20/01/07, Platonides Platonides@gmail.com wrote:
Interesting. What was the reason?
I assume you'll be insulted if I assume you can't read.
Either there is no reason given in the bug, or he and I both can't read.
You can't read. ;)
- -- brion vibber (brion @ pobox.com)
On 1/21/07, Timwi timwi@gmx.net wrote:
Rob Church wrote:
On 20/01/07, Platonides Platonides@gmail.com wrote:
Interesting. What was the reason?
I assume you'll be insulted if I assume you can't read.
Either there is no reason given in the bug, or he and I both can't read.
It's the very first comment, by the person who WONTFIXed it (i.e., Brion, who as you may recall is the lead developer): "Redirects are meant to be a transparent part of the user interface. Behaving just like other links is desired behavior, not a bug."
On 1/22/07, Simetrical Simetrical+wikitech@gmail.com wrote:
It's the very first comment, by the person who WONTFIXed it (i.e., Brion, who as you may recall is the lead developer): "Redirects are meant to be a transparent part of the user interface. Behaving just like other links is desired behavior, not a bug."
"Transparent" is ambiguous here. Normally in these contexts, transparent means "the user can see exactly what is going on". Whereas Brion apparently meant "invisible", in the sense that "transparent" glass is kind of "invisible".
Semantics aside, being able to distinguish redirects from links to real articles strikes me as useful, and not "undesirable" at all. Example: I have a page in my user space that links to all the stubs I've started. Clicking "related changes" shows any changes to any page I started - useful for me. If anyone renames any of those stubs, it becomes a redirect. "Related changes" then quietly[1] breaks, because future changes to the stub no longer show up. It would be very handy for me to see which of my links are actually pointing to redirects.
Remember we're still talking about "maintenance mode" here - you wouldn't want redirects to show up specially for users in normal mode (especially non-logged-in users).
Steve [1] The actual change to a redirect will show up, once.
On 22/01/07, Steve Bennett stevagewp@gmail.com wrote:
Remember we're still talking about "maintenance mode" here - you wouldn't want redirects to show up specially for users in normal mode (especially non-logged-in users).
It's already been agreed that we can probably add a class for users who would like one, as it incurs no additional performance penalty in Linker::makeLinkObj(); I wouldn't introduce a whole new "mode" for this, though...users who *want* their redirect links distinguised can just add the relevant line to their custom CSS.
Rob Church
On 1/23/07, Rob Church robchur@gmail.com wrote:
It's already been agreed that we can probably add a class for users who would like one, as it incurs no additional performance penalty in Linker::makeLinkObj(); I wouldn't introduce a whole new "mode" for this, though...users who *want* their redirect links distinguised can just add the relevant line to their custom CSS.
Ok cool. Should I file a bug?
Then maybe later we can come up with an elegant way for people to get certain pre-defined CSS styles to appear in certain pre-defined ways without having to hack their monobook.css. There are other styles in this category (notably, spoilers).
Steve
On 22/01/07, Steve Bennett stevagewp@gmail.com wrote:
Ok cool. Should I file a bug?
No, the previous one was reopened.
Then maybe later we can come up with an elegant way for people to get certain pre-defined CSS styles to appear in certain pre-defined ways without having to hack their monobook.css. There are other styles in
Not a bad idea, perhaps...
Rob Church
On Tue, Jan 23, 2007 at 12:41:28AM +1100, Steve Bennett wrote:
On 1/22/07, Simetrical Simetrical+wikitech@gmail.com wrote:
It's the very first comment, by the person who WONTFIXed it (i.e., Brion, who as you may recall is the lead developer): "Redirects are meant to be a transparent part of the user interface. Behaving just like other links is desired behavior, not a bug."
"Transparent" is ambiguous here. Normally in these contexts, transparent means "the user can see exactly what is going on". Whereas Brion apparently meant "invisible", in the sense that "transparent" glass is kind of "invisible".
Semantics aside, being able to distinguish redirects from links to real articles strikes me as useful, and not "undesirable" at all.
I had what I think was most of this argument last fall; you might want to check the archives. :-) It was in the context of URLs and the sub-labels, but still similar.
Cheers, -- jra
Example: I have a page in my user space that links to all the stubs I've started. Clicking "related changes" shows any changes to any page I started - useful for me. If anyone renames any of those stubs, it becomes a redirect. "Related changes" then quietly[1] breaks, because future changes to the stub no longer show up. It would be very handy for me to see which of my links are actually pointing to redirects.
I just whipped up a little Javascript for that purpose (PHP developers, start puking now!). Just insert the following lines into your monibook.js (or whichever skin you are using.
// [[User:Dschwen/highlightredirects.js]] - please include this line document.write('<script type="text/javascript" src="' + 'http://en.wikipedia.org/w/index.php?title=User:Dschwen/highlightredirects.js' + '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
Have fun and please report bugs directly to me (less spammy to the list and less embarrasing to me :-) )
Dschwen wrote:
I just whipped up a little Javascript for that purpose (PHP developers, start puking now!). Just insert the following lines into your monibook.js (or whichever skin you are using.
// [[User:Dschwen/highlightredirects.js]] - please include this line document.write('<script type="text/javascript" src="'
- 'http://en.wikipedia.org/w/index.php?title=User:Dschwen/highlightredirects.js'
- '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
Have fun and please report bugs directly to me (less spammy to the list and less embarrasing to me :-) )
Problem with JavaScript solutions is that they need *another* http query. If that was done on the server side there would be no overhead.
Some points about the code: It uses 5 functions: createXMLHTTP, updateStatus, addEvent, install and run
Being it new worl, i'd discourage coding new fucntions for addEvent and createXMLHTTP, as the general Mediawiki javascript includes already includes equivalent functions (theoretically with full browser compat.).
It's interesting your style of making eveything into a big variable.
Dschwen wrote:
I just whipped up a little Javascript for that purpose (PHP developers, start puking now!). Just insert the following lines into your monibook.js (or whichever skin you are using.
// [[User:Dschwen/highlightredirects.js]] - please include this line document.write('<script type="text/javascript" src="'
- 'http://en.wikipedia.org/w/index.php?title=User:Dschwen/highlightredirects.js'
- '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
Have fun and please report bugs directly to me (less spammy to the list and less embarrasing to me :-) )
Problem with JavaScript solutions is that they need *another* http query. If that was done on the server side there would be no overhead.
Some points about the code: It uses 5 functions: createXMLHTTP, updateStatus, addEvent, install and run
Being it new worl, i'd discourage coding new fucntions for addEvent and createXMLHTTP, as the general Mediawiki javascript includes already includes equivalent functions (theoretically with full browser compat.).
It's interesting your style of making eveything into a big variable.
wikitech-l@lists.wikimedia.org