I created bug 11902, but since I haven't had any replies, I'm reposting here. Some feedback, please? http://bugzilla.wikipedia.org/show_bug.cgi?id=11902 -- I think I want to have a go at implementing this, but want to check that it's a good idea, and stands a chance of being implemented at Wikipedia.
Motivation: there are lots of links to disambiguous pages, and they're not at all visible. This is bad for navigating, bad for reusing content, and bad for any kind of analysis that involves links.
- Define a magic word like __AMBIGUOUSPAGE__, which would be included in {{disambig}} on Wikipedia. - Flag pages containing this magic word (schema change, I believe?) - When a link is rendered that goes towards a flagged ambiguous page, it is rendered differently, such as using a new css style, or perhaps a predefined but editable template, which would allow an image to be displayed next to such a link.
Desirable? Feasible? Would be enabled at Wikipedia?
Issues for discussion: - Should it be generalised at all to something like __BADLINKTARGET__? - Should there be a way of controlling which namespaces it applies in? Perhaps it's ok to link to a disambiguation page from a talk namespace... - Should there be a way to suppress it for an individual link? If so, what would that syntax look like? Perhaps some semantics like linking to any page named "... (disambiguation)" (configurable) would be taken to be a deliberate link, and to deliberately link to a page not named that, you should use a redirect? --
Thanks, Steve
- Define a magic word like __AMBIGUOUSPAGE__, which would be included in
{{disambig}} on Wikipedia.
- Flag pages containing this magic word (schema change, I believe?)
I think that would require disambig to be substed. Probably better to use AWB to add the magic word to every page in the appropriate category, and then change the instructions for creating disambig pages. And yes, I expect that would require a schema change - I don't think there's an existing field you could use (perhaps the schema change should be adding a fairly large bit field to the articles/revisions table(s) so people can add properties like this without needing to add a new field each time, they could just change a text file somewhere which describes what all the bits mean).
Thomas Dalton schreef:
I don't think there's an existing field you could use
You thought correctly, there isn't.
(perhaps the schema change should be adding a fairly large bit field to the articles/revisions table(s) so people can add properties like this without needing to add a new field each time, they could just change a text file somewhere which describes what all the bits mean).
Good idea, makes for much fewer schema changes in the future. The table we'll want this one in is the page table [1]. While we're at it, we could also condense page_is_new and page_is_redirect into this new page_flags bitfield.
Roan Kattouw (Catrope)
On 11/9/07, Roan Kattouw roan.kattouw@home.nl wrote:
Thomas Dalton schreef:
I don't think there's an existing field you could use
You thought correctly, there isn't.
(perhaps the schema change should be adding a fairly large bit field to the articles/revisions table(s) so people can add properties like this without needing to add a new field each time, they could just change a text file somewhere which describes what all the bits mean).
Good idea, makes for much fewer schema changes in the future. The table we'll want this one in is the page table [1]. While we're at it, we could also condense page_is_new and page_is_redirect into this new page_flags bitfield.
Sounds problematic. There isn't a binary AND function in mysql, so looking for new/redirected pages (as is done in, for instance, special pages) would have performance issues if you condensed it into a bitfield. Lots of special pages would need to be updated, as well.
As for disambiguation pages, it's done best as an extension. Most wikis running MediaWiki will not want or need this functionality, and it's certainly an editorial tool more than a display tool. It's probably better implemented as some user-side javascript.
Andrew Garrett schreef:
Sounds problematic. There isn't a binary AND function in mysql,
That's kind of stupid. Although I can imagine that if it existed, AND queries would be poorly indexed.
so looking for new/redirected pages (as is done in, for instance, special pages) would have performance issues if you condensed it into a bitfield.
Ouch. Let's just keep that stuff in separate bool fields then.
Roan Kattouw (Catrope)
On 09/11/2007, Andrew Garrett andrew@epstone.net wrote:
On 11/9/07, Roan Kattouw roan.kattouw@home.nl wrote:
Thomas Dalton schreef:
I don't think there's an existing field you could use
You thought correctly, there isn't.
(perhaps the schema change should be adding a fairly large bit field to the articles/revisions table(s) so people can add properties like this without needing to add a new field each time, they could just change a text file somewhere which describes what all the bits mean).
Good idea, makes for much fewer schema changes in the future. The table we'll want this one in is the page table [1]. While we're at it, we could also condense page_is_new and page_is_redirect into this new page_flags bitfield.
Sounds problematic. There isn't a binary AND function in mysql, so looking for new/redirected pages (as is done in, for instance, special pages) would have performance issues if you condensed it into a bitfield. Lots of special pages would need to be updated, as well.
Ah, that's a big problem. Do you think the mysql people would add a binary AND function if we asked nicely?
Sounds problematic. There isn't a binary AND function in mysql, so looking for new/redirected pages (as is done in, for instance, special pages) would have performance issues if you condensed it into a bitfield. Lots of special pages would need to be updated, as well.
Ah, that's a big problem. Do you think the mysql people would add a binary AND function if we asked nicely?
Well, since there already IS a binary AND operator in MySQL (http://dev.mysql.com/doc/refman/5.0/en/bit-functions.html), you don't have to ask. But still, I believe you don't want to filter by that for performance reason, as has already been said in this thread.
-- [[cs:User:Mormegil | Petr Kadlec]]
On 11/9/07, Andrew Garrett andrew@epstone.net wrote:
As for disambiguation pages, it's done best as an extension. Most wikis running MediaWiki will not want or need this functionality, and it's certainly an editorial tool more than a display tool. It's probably better implemented as some user-side javascript.
Such as "Lupin's Popups".
/me hides.
—C.W.
On Sun, Nov 11, 2007 at 10:13:47AM -0600, Charlotte Webb wrote:
On 11/9/07, Andrew Garrett andrew@epstone.net wrote:
As for disambiguation pages, it's done best as an extension. Most wikis running MediaWiki will not want or need this functionality, and it's certainly an editorial tool more than a display tool. It's probably better implemented as some user-side javascript.
Such as "Lupin's Popups".
Yeah, but those are only troublesome every 28 days or so...
Cheers, -- jra
On 11/9/07, Thomas Dalton thomas.dalton@gmail.com wrote:
- Define a magic word like __AMBIGUOUSPAGE__, which would be included in
{{disambig}} on Wikipedia.
- Flag pages containing this magic word (schema change, I believe?)
I think that would require disambig to be substed.
Probably not true as other magic words such as __TOC__ work from within templates.
—C.W.
I think that would require disambig to be substed.
Probably not true as other magic words such as __TOC__ work from within templates.
Placing the table of contents doesn't involve putting a flag in the database, it's just taken into account when parsing the page before displaying it. Marking a page as a disambig would have to be taken into account when saving the page and I don't think transcluded pages are even looked at during the process unless they are substed.
Thomas Dalton wrote:
I think that would require disambig to be substed.
Probably not true as other magic words such as __TOC__ work from within templates.
Placing the table of contents doesn't involve putting a flag in the database, it's just taken into account when parsing the page before displaying it. Marking a page as a disambig would have to be taken into account when saving the page and I don't think transcluded pages are even looked at during the process unless they are substed.
A full parse is done on save; otherwise link tables could not be updated. Note however that that's a separate step from the update of the page table.
-- brion vibber (brion @ wikimedia.org)
"Steve Bennett" stevagewp@gmail.com wrote in message news:b8ceeef70711090139q3689c7bau5db8852eeb759117@mail.gmail.com...
- Define a magic word like __AMBIGUOUSPAGE__, which would be included in
{{disambig}} on Wikipedia.
- Flag pages containing this magic word (schema change, I believe?)
- When a link is rendered that goes towards a flagged ambiguous page, it
is rendered differently, such as using a new css style, or perhaps a predefined but editable template, which would allow an image to be displayed next to such a link.
MW already knows which pages are disambiguation pages. These are any pages that include the page given at [[MediaWiki:Disambiguationspage]].
I'm not sure if this is remembered anywhere on a per-page basis, but if not you probably need to add something to the schema to remember it.
Links to disambiguation pages should be identical to currently, but with a new CSS class, e.g. 'mw-dablink', added to the current ones. Individual wikis can then customise this in [[Mediawiki:Common.css]] if they choose to (including the addition of an image if wanted).
- Mark Clements (HappyDog)
This would be great, see bugs http://bugzilla.wikipedia.org/show_bug.cgi?id=8339 and http://bugzilla.wikipedia.org/show_bug.cgi?id=6754 for more discussion about this. Maybe it will finally happen! :D
Also, whether you want to enable this or not, it might be worth thinking about building the system so that it would give you a warning on save that your text contains links to disambiguation pages, and displays some system message. I'm not sure a different css class is enough to draw most people's attention that are likely to generate these links.
On 11/10/07, cohesion cohesion@sleepyhead.org wrote:
This would be great, see bugs http://bugzilla.wikipedia.org/show_bug.cgi?id=8339 and http://bugzilla.wikipedia.org/show_bug.cgi?id=6754 for more discussion about this. Maybe it will finally happen! :D
Very interesting - those two basically cover everything I had in mind. So, yes, let's make it happen. We should resolve the issue of whether the DB flag will be specifically for *disambiguation* pages only, or a more general sense of "you shouldn't be linking here".
Also, whether you want to enable this or not, it might be worth
thinking about building the system so that it would give you a warning on save that your text contains links to disambiguation pages, and displays some system message. I'm not sure a different css class is enough to draw most people's attention that are likely to generate these links.
Good
idea. At the very least, at preview time, it could call a javascript hook. It would be controversial to interfere at *save* time, though possibly it could save *and* display a warning.
Steve
On Nov 9, 2007 9:00 AM, Steve Bennett stevagewp@gmail.com wrote:
idea. At the very least, at preview time, it could call a javascript hook. It would be controversial to interfere at *save* time, though possibly it could save *and* display a warning.
That sounds good, just something like, "Some of the links you created are ambiguous, and are marked in yellow (or whatever). If you can, please follow the links and see which article is most appropriate and update the links appropriately."
On 11/9/07, Steve Bennett stevagewp@gmail.com wrote:
Motivation: there are lots of links to disambiguous pages, and they're not at all visible. This is bad for navigating, bad for reusing content, and bad for any kind of analysis that involves links.
- Define a magic word like __AMBIGUOUSPAGE__, which would be included in
{{disambig}} on Wikipedia.
Unnecessary. {{disambig}} already has special status, because it's listed on MediaWiki:Disambiguationspage. Otherwise Special:Disambiguations wouldn't work. A magic word might be more sensible from an interface perspective, which of course would allow anyone to declare a template to be a disambig template.
- When a link is rendered that goes towards a flagged ambiguous page, it is
rendered differently, such as using a new css style, or perhaps a predefined but editable template, which would allow an image to be displayed next to such a link.
You know you can set it so that links to short pages display differently? It picks up many disambig pages, in my experience. Although far from all, and it picks up short articles too.
On 11/9/07, Andrew Garrett andrew@epstone.net wrote:
Sounds problematic. There isn't a binary AND function in mysql
Um, what?
mysql> SELECT 9 & 15; +--------+ | 9 & 15 | +--------+ | 9 | +--------+ 1 row in set (0.00 sec)
, so looking for new/redirected pages (as is done in, for instance, special pages) would have performance issues if you condensed it into a bitfield.
That's true, but only because ordinary INT-type columns aren't indexable for that kind of search. Apparently SET columns aren't either: FIND_IN_SET requires an index scan. Of course the cardinality is very low, for a small bit field, so the index scan might be "fast enough".
As for disambiguation pages, it's done best as an extension. Most wikis running MediaWiki will not want or need this functionality, and it's certainly an editorial tool more than a display tool. It's probably better implemented as some user-side javascript.
If it purely affects display, it should use CSS, not JavaScript, if possible.
On 11/9/07, Mark Clements gmane@kennel17.co.uk wrote:
MW already knows which pages are disambiguation pages. These are any pages that include the page given at [[MediaWiki:Disambiguationspage]].
I'm not sure if this is remembered anywhere on a per-page basis, but if not you probably need to add something to the schema to remember it.
We just use the templatelinks table. Contrary to previous remarks by me, it's perfectly efficient for individual articles, just an extra join.
On 11/10/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Unnecessary. {{disambig}} already has special status, because it's listed on MediaWiki:Disambiguationspage. Otherwise Special:Disambiguations wouldn't work. A magic word might be more sensible from an interface perspective, which of course would allow anyone to declare a template to be a disambig template.
I think we're going to need a bit more than the meagre Special:Disambiguations functionality. Looking up another page to see what templates are linked to from there is a bit hackish, isn't it?
You know you can set it so that links to short pages display differently? It picks up many disambig pages, in my experience. Although far from all, and it picks up short articles too.
Nothing wrong with linking to short pages.
Steve
On 11/11/07, Steve Bennett stevagewp@gmail.com wrote:
You know you can set it so that links to short pages display differently? It picks up many disambig pages, in my experience. Although far from all, and it picks up short articles too.
Nothing wrong with linking to short pages.
He's referring to the "Threshold for stub link formatting" on the last tab of Special:Preferences, so "short" in this context means "less than a certain user-defined length", and links to such pages appear in sort of a brown color by default.
It would probably be easy enough to hack the famous "popups" script to make links to disambig pages appear in yet a fourth color.
—C.W.
On 11/12/07, Charlotte Webb charlottethewebb@gmail.com wrote:
It would probably be easy enough to hack the famous "popups" script to make links to disambig pages appear in yet a fourth color.
Yep. But until that javascript is in *everyone*'s skin, it doesn't count as a solution. This is about encouraging everyone to get their links right, not just a few.
For some reason I wasn't really thinking of showing the link in a different colour (note the subject of this thread is "display...differently". A wiggly underline (probably not possible) or a little icon next to the link was more what I had in mind, but it doesn't matter.
Steve
On 11/11/07, Steve Bennett stevagewp@gmail.com wrote:
I think we're going to need a bit more than the meagre Special:Disambiguations functionality. Looking up another page to see what templates are linked to from there is a bit hackish, isn't it?
Yes, but my point is it's already in the DB, and AFAICT in a pretty efficient form.
On 11/11/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Placing the table of contents doesn't involve putting a flag in the database, it's just taken into account when parsing the page before displaying it. Marking a page as a disambig would have to be taken into account when saving the page and I don't think transcluded pages are even looked at during the process unless they are substed.
Of course they are. How do you think it can figure out what categories the page is in? Any wikitext construct can be put in a template, because templates are substituted into the text during parsing before almost anything else (okay, not before parser tags). __DISAMBIG__ or whatever would certainly work, I'm just not sure whether it's superior to the current method.
On 11/11/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Placing the table of contents doesn't involve putting a flag in the database, it's just taken into account when parsing the page before displaying it. Marking a page as a disambig would have to be taken into account when saving the page and I don't think transcluded pages are even looked at during the process unless they are substed.
Of course they are. How do you think it can figure out what categories the page is in? Any wikitext construct can be put in a template, because templates are substituted into the text during parsing before almost anything else (okay, not before parser tags). __DISAMBIG__ or whatever would certainly work, I'm just not sure whether it's superior to the current method.
I stand corrected. In which case, I would say it is superior, simply because it isn't a hack. The hack may work, but the fact that it's a hack means it's likely more difficult to maintain. It's also more difficult for users to understand what's going on. The Mediawiki namespace is there for interface customisation. Using it for anything else is asking for trouble sooner or later.
wikitech-l@lists.wikimedia.org