I hacked a small function that automatically shows what might be disambiguation pages below the page subtitle. This works for all pages with a " (" in the title.
This function was requested (on the German mailing list, IIRC). It is running on the test wiki. Try http://test.wikipedia.org/wiki/Allotment_(gardening) for an example (currently standard skin only!).
The feature has to be enabled for each language, so the Chinese won't suffer from bogus links :-)
I won't commit that to the CVS until Lee says the feature freeze is over...
Magnus ____________________________________________________________________________ Jetzt bei WEB.DE FreeMail anmelden = 1qm Regenwald schuetzen! Helfen Sie mit! Nutzen Sie den Serien-Testsieger. http://user.web.de/Regenwald
Magnus Manske wrote:
I hacked a small function that automatically shows what might be disambiguation pages below the page subtitle. This works for all pages with a " (" in the title.
This function was requested (on the German mailing list, IIRC). It is running on the test wiki. Try http://test.wikipedia.org/wiki/Allotment_(gardening) for an example (currently standard skin only!).
The feature has to be enabled for each language, so the Chinese won't suffer from bogus links :-)
I won't commit that to the CVS until Lee says the feature freeze is over...
And I think I have the Specialpage:Maintainance update for qualifiers ready until end of feature frezze, too. It only needs a better output.
Smurf
Magnus Manske wrote:
This function was requested (on the German mailing list, IIRC). It is running on the test wiki. Try http://test.wikipedia.org/wiki/Allotment_(gardening) for an example (currently standard skin only!).
Because it's not in the CVS I can't say if it is a bug, but tring the link I seen that it works even without the last bracket ")".
Smurf
I hacked a small function that automatically shows what might be disambiguation pages below the page subtitle. This works for all pages with a " (" in the title.
This function was requested (on the German mailing list, IIRC). It is running on the test wiki. Try http://test.wikipedia.org/wiki/Allotment_(g ardening) for an example (currently standard skin only!).
The feature has to be enabled for each language, so the Chinese won't suffer from bogus links :-)
Very cool feature, Magnus! This will save us a lot of manual "Alternate meaning" links. Now all we need is some kind of template/transclusion system so the disambiguation text does not need to be edited on 20342 pages if it changes ..
BTW, we can probably all just speak German if the current trend continues :-)
Regards,
Erik
Erik Moeller wrote:
Very cool feature, Magnus! This will save us a lot of manual "Alternate meaning" links. Now all we need is some kind of template/transclusion system so the disambiguation text does not need to be edited on 20342 pages if it changes ..
Oh, therefore we need users, don't do all the work ;)
BTW, we can probably all just speak German if the current trend continues :-)
Well, but I think it's not even as fair as writing french or whatever, if you can try it in english (I try hard and fail;). It reduces the participation of all the others. And that's in no way the target of wikipedia. (Of course if someone only speaks/writes $language he/she/it can write here and hope someone answers/translate).
Smurf
(Erik Moeller erik_moeller@gmx.de):
I hacked a small function that automatically shows what might be disambiguation pages below the page subtitle. This works for all pages with a " (" in the title.
Very cool feature, Magnus! This will save us a lot of manual "Alternate meaning" links. Now all we need is some kind of template/transclusion system so the disambiguation text does not need to be edited on 20342 pages if it changes ..
I'm not convinced. I generally dislike the idea of automatic content of any kind--the content of Wikipedia should be created by human editors, and even disambiguation pages should each be crafted uniquely to suit the needs of the subject, not just stamped out of a template.
Lee Daniel Crocker wrote:
I'm not convinced. I generally dislike the idea of automatic content of any kind--the content of Wikipedia should be created by human editors, and even disambiguation pages should each be crafted uniquely to suit the needs of the subject, not just stamped out of a template.
Yes, I seem to remember :-)
But this is not written into the content - just a display of (possible) related links, like "what links here". Granted, links on "what links here" are human-made, but so are page titles. We're bound to step onto some false positives with this, but IMHO the advantages outweight that. Unless, of course, it badly affects performance, which I doubt, given the rather minor query (it uses "%", though...)
Magnus
Lee Daniel Crocker wrote:
Erik Moeller wrote:
Magnus Manske wrote:
I hacked a small function that automatically shows what might be disambiguation pages below the page subtitle. This works for all pages with a " (" in the title.
Very cool feature, Magnus! This will save us a lot of manual "Alternate meaning" links. Now all we need is some kind of template/transclusion system so the disambiguation text does not need to be edited on 20342 pages if it changes ..
I'm not convinced. I generally dislike the idea of automatic content of any kind--the content of Wikipedia should be created by human editors, and even disambiguation pages should each be crafted uniquely to suit the needs of the subject, not just stamped out of a template.
I agree with Lee, but I think that the idea can still be made to work.
To expand on Lee's point, if faced simply with a list of alternate articles -- [[X]], [[X (Y1)]], [[X (Y2)]], [[X (Y3)]], etc. -- it may not be clear which article you really want, at least if the various Ys are closely related. A disambiguation page, if necessary, can offer explanations. We usually don't need explanation, and a disambiguation page is thus usually just a list -- but sometimes we do need explanation.
My idea is to link people directly to the disambiguation page, which will (if well written) contain exactly what readers need -- human editing of the disambiguation page in the wiki way will see to that. Here's a brief algorithm:
Given a page title [[X]] without parentheses or of the form [[X (Y)]]: * Search for a page [[X (disambiguation)]] ** If it exists, add "See also: [[X (disambiguation)]]" (unless "Y" = "disambiguation", of course). ** If it doesn't exist, add "See also: [[X]]" (unless we're on [[X]] itself, of course). We don't need to link to anything else; the disambiguation page (either [[X]] or [[X (disambiguation)]]) will do so, and furthermore will have human-written text explaining the nuances, if necessary.
As a bonus, we could add the complete list of parenthesised pages as a "See also" on the disambiguation page itself (as identified by the "unless"es in the previous paragraph). That's not really necessary, but it could be convenient; for example, it would highlight an incomplete disambiguation page.
Furthermore, this could solve the problem of formatting disambiguation blocks. Larry, mav, and I have discussed this matter before on [[en:Wikipedia talk:Disambiguation]] (look for "= Jimmy Carter ="). If, as mav suggested on the mailing list just now, we put this "See also" directly underneath the language links, then Larry, mav, and I, at least, should think that it looks good. Human-written disambiguation blocks would be unnecessary; but the human-written material would still be on [[X (disambiguation)]], so Lee (and I) should be happy about that.
-- Toby
PS: I can read German (standard Hochdeutsch) just fine, but I'll write my own comments in English since that's easier.
Toby Bartels wrote:
Lee Daniel Crocker wrote:
I'm not convinced. I generally dislike the idea of automatic content of any kind--the content of Wikipedia should be created by human editors, and even disambiguation pages should each be crafted uniquely to suit the needs of the subject, not just stamped out of a template.
I agree with Lee, but I think that the idea can still be made to work.
To expand on Lee's point, if faced simply with a list of alternate articles -- [[X]], [[X (Y1)]], [[X (Y2)]], [[X (Y3)]], etc. -- it may not be clear which article you really want, at least if the various Ys are closely related. A disambiguation page, if necessary, can offer explanations. We usually don't need explanation, and a disambiguation page is thus usually just a list -- but sometimes we do need explanation.
Well, I agree with Lee, too. And I don't see the problem of Magnus feature. We have disambiguation pages, written manually as Lee it prefers, with explanations and all. Magnus don't intended to change that.
And Magnus feature only supports a shortcut: If I got on a page X (Y1) (randomly), and I see X (Y2) and think, oh, fine, Y2 was what I'm interested in, let's go there, I can do that. No need to do that list of links manually. If I need the explanations or I'm interested in them I will go to X, and read them. The user has the free choice, we only offer him to have that choice.
Let's first decide if we agree to the feature as it is, and discuss further features seperatly. Erik's proposal is a possiblility, but it should be not mixed up with the current feature.
PS: If you remember, Magnus wrote that each Language can turn it on or off. Or possibly each User. I think that will be a minor change the developers can handle in a few minutes. No need that all have to use this feature. And than each wikipedia or even each user can choose.
--- Thomas Corell T.Corell@t-online.de wrote:
PS: If you remember, Magnus wrote that each Language can turn it on or off. Or possibly each User. I think that will be a minor change
the
developers can handle in a few minutes. No need that all have to use this feature. And than each wikipedia or even each user can choose.
If we adopt Magnus' feature (which I would support), then it should not become a user option. The whole point of the feature is to do away with hand-written disambiguation blocks, but that is only possible if everyone uses it.
Axel
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
(Axel Boldt axelboldt@yahoo.com):
If we adopt Magnus' feature (which I would support), then it should not become a user option. The whole point of the feature is to do away with hand-written disambiguation blocks, but that is only possible if everyone uses it.
No, that's not the point at all. Hand-written disambiguations with clarifying comments are invaluable. This new feature, if we can figure out a good way to do it, is to facilitate creating them and keeping them up to date, not to eliminate them.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Axel Boldt wrote: | If we adopt Magnus' feature (which I would support), then it should not | become a user option. The whole point of the feature is to do away with | hand-written disambiguation blocks, but that is only possible if | everyone uses it. | | Axel
If everybody must use it and hand-written disambiguation blocks are to be "done away with," then I oppose it.
Given a mandatory XOR choice between
"See also USS Enterprise (1775), USS Enterprise (1799), USS Enterprise (1831), USS Enterprise (1874), USS Enterprise (CV-6), and USS Enterprise (CVN-65)."
and the 1500-character disambiguation block at USS Enterprise -- which not only mentions the Star Trek ships and the Space Shuttle and the ten HMS Enterprises but also describes a schooner and a motorboat that are not worth separate articles AND gives a couple of points of distinction between the each of the eight ships -- then I choose the hand-written, informative page.
- -- ~ Sean Barrett | Lozhka diogtia portit bochku miodu. ~ sean@epoptic.com |
Axel Boldt wrote:
If we adopt Magnus' feature (which I would support), then it should not become a user option. The whole point of the feature is to do away with hand-written disambiguation blocks, but that is only possible if everyone uses it.
I think that we can do this in such a way as to eliminate human-written disambiguation *blocks* but to retain of human-written disambiguation *pages*. Indeed, we may have to write a few more of the latter, since some disambiguation now is done *only* by blocks -- so we may get more human-written content in the end.
-- Toby
--- Toby Bartels toby+wikipedia@math.ucr.edu wrote:
Axel Boldt wrote:
If we adopt Magnus' feature (which I would support), then it should not become a user option. The whole point of the feature is to do away with hand-written disambiguation blocks, but that is only possible if everyone uses it.
I think that we can do this in such a way as to eliminate human-written disambiguation *blocks* but to retain of human-written disambiguation *pages*.
Absolutely, and I think that answers the objections of Lee and Sean. Just to clarify, [[Paris]] has a human-written disambiguation block at the top which would become unnecessary; [[Paris (disambiguation)]] is a human-written disambiguation page which would stay the same.
Axel
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Axel Boldt wrote:
Toby Bartels wrote:
I think that we can do this in such a way as to eliminate human-written disambiguation *blocks* but to retain of human-written disambiguation *pages*.
Absolutely, and I think that answers the objections of Lee and Sean. Just to clarify, [[Paris]] has a human-written disambiguation block at the top which would become unnecessary; [[Paris (disambiguation)]] is a human-written disambiguation page which would stay the same.
OK, we seem to be in agreement. But just to be clear:
Magnus' present code will miss a lot of links at the top of [[Paris]], since most of those articles are disambiguated by commas, not parentheses. Alternatively, it'll have an rather unwieldy long list of links, if we create redirects from the parentheses to the commas. And it'll still miss the rock band, unless we create another redirect (from [[Paris (band)]] to [[Poison (band)]]). Best all round, then, to simply link to [[Paris (disambiguation)]].
Magnus' code is also problematic in that on [[Paris, Texas]], its disambiguate block will include only [[Paris, Texas (movie)]], whereas the human-written block also links to [[Paris (disambiguation)]].
That's too much complaining now about a basically good idea. I did say in another post that I would look at the code ...
-- Toby
Smurf wrote in part:
Let's first decide if we agree to the feature as it is, and discuss further features seperatly. Erik's proposal is a possiblility, but it should be not mixed up with the current feature.
Yes, let's set Erik's ideas aside for now -- we can trust Erik to bring them up again! ^_^
-- Toby
(Toby Bartels toby+wikipedia@math.ucr.edu):
My idea is to link people directly to the disambiguation page, which will (if well written) contain exactly what readers need -- human editing of the disambiguation page in the wiki way will see to that. Here's a brief algorithm:
Given a page title [[X]] without parentheses or of the form [[X (Y)]]:
- Search for a page [[X (disambiguation)]]
** If it exists, add "See also: [[X (disambiguation)]]" (unless "Y" = "disambiguation", of course). ** If it doesn't exist, add "See also: [[X]]" (unless we're on [[X]] itself, of course). We don't need to link to anything else; the disambiguation page (either [[X]] or [[X (disambiguation)]]) will do so, and furthermore will have human-written text explaining the nuances, if necessary.
As a bonus, we could add the complete list of parenthesised pages as a "See also" on the disambiguation page itself (as identified by the "unless"es in the previous paragraph). That's not really necessary, but it could be convenient; for example, it would highlight an incomplete disambiguation page.
Furthermore, this could solve the problem of formatting disambiguation blocks. Larry, mav, and I have discussed this matter before on [[en:Wikipedia talk:Disambiguation]] (look for "= Jimmy Carter ="). If, as mav suggested on the mailing list just now, we put this "See also" directly underneath the language links, then Larry, mav, and I, at least, should think that it looks good. Human-written disambiguation blocks would be unnecessary; but the human-written material would still be on [[X (disambiguation)]], so Lee (and I) should be happy about that.
That's a bit complex, but maybe it could be made to work. The analogy to language links doesn't quite work for me because some human editor has actually gone to the trouble of noting that the fr:chat article is an appropriate French version of en:cat, whereas these will be fully automatic. But I agree that it's a reasonably safe bet that X (Y) is somehow related to X, X (Z), and X (disambiguation), because our conventions here have created that association, so it's somewhat human- created.
Another issue is performance. Perhaps we could help both of those issues by making a single link to a list page rather than a set of links. But what to call that list is tricky. Is isn't really "related pages" because they're only related lexigographically, not semantically. Perhaps it could be something like "Other 'Foo' pages".
Lee Daniel Crocker wrote in response to me:
That's a bit complex, but maybe it could be made to work. The analogy to language links doesn't quite work for me because some human editor has actually gone to the trouble of noting that the fr:chat article is an appropriate French version of en:cat, whereas these will be fully automatic. But I agree that it's a reasonably safe bet that X (Y) is somehow related to X, X (Z), and X (disambiguation), because our conventions here have created that association, so it's somewhat human- created.
I don't think that one should stress much of an *analogy* to language links. It should go no farther than that the place where language links now lie would be a good place (one a separate line) to place these as well.
Another issue is performance. Perhaps we could help both of those issues by making a single link to a list page rather than a set of links. But what to call that list is tricky. Is isn't really "related pages" because they're only related lexigographically, not semantically. Perhaps it could be something like "Other 'Foo' pages".
Or [[Foo (disambiguation)]]! ^_^
-- Toby
Lee Daniel Crocker wrote:
Another issue is performance. Perhaps we could help both of those issues by making a single link to a list page rather than a set of links. But what to call that list is tricky. Is isn't really "related pages" because they're only related lexigographically, not semantically. Perhaps it could be something like "Other 'Foo' pages".
But this link should only appear if there really are other "foo" pages, right? So, we'd have to run a SQL query anyway.
One special case I could think of is that there are a lot of matching pages (like the mentioned "USS *" pages). The "Other 'foo' pages" link cuold go into effect if there are more than, say, seven other 'foo' pages. I'm not sure if the trouble of setting up Yet Another Special Page (tm) will pay off considering the expected short number of such pages (I think at the test wiki, with all the 'A' articles, "Atlas" and variants hit the top, with five pages or so, one of them a REDIRECT).
The feature was *not* intended to replace the disambiguation pages. It started off when someone mentioned he'd like to see for a page "foo (bar)" if there's a page "foo" (which is often enough not the case, at least on the German wikipedia).
For the disambiguation pages, I would imagine something as simple as a "{{DISAMBIGUATION}}" variable, which would * add all the "foo (bar)" pages on a "foo" or "foo (disambiguation)" page * add the disambiguation disclaimer
But that's another story :-)
Magnus
Magnus Manske wrote:
Lee Daniel Crocker wrote:
Another issue is performance. Perhaps we could help both of those issues by making a single link to a list page rather than a set of links. But what to call that list is tricky. Is isn't really "related pages" because they're only related lexigographically, not semantically. Perhaps it could be something like "Other 'Foo' pages".
One special case I could think of is that there are a lot of matching pages (like the mentioned "USS *" pages). The "Other 'foo' pages" link cuold go into effect if there are more than, say, seven other 'foo' pages. I'm not sure if the trouble of setting up Yet Another Special Page (tm) will pay off considering the expected short number of such pages (I think at the test wiki, with all the 'A' articles, "Atlas" and variants hit the top, with five pages or so, one of them a REDIRECT).
But Yet Another Special Page would be precisely wrong. It would function like a disambiguation page, but one not written by a human and featuring only a list. If we direct people to a special page through "Other 'Foo' pages", then that really should link to [[Foo (disambiguation)]]. As you say:
The feature was *not* intended to replace the disambiguation pages.
-- Toby
Lee-
I'm not convinced. I generally dislike the idea of automatic content of any kind--the content of Wikipedia should be created by human editors, and even disambiguation pages should each be crafted uniquely to suit the needs of the subject, not just stamped out of a template.
I agree regarding the disambiguation pages themselves. In general, we should only use automatically generated/added content where it is at least equivalent to text written by humans. Using this criterion:
1) The "Alternate meanings:" solution by Magnus is a good one, because this is supposed to be a short line on individual articles that complements the longer disambiguation page. There is no point in having humans write and update this information, just as there is no point in having humans write the "What links here" information.
2) Text blocks that do not change are currently written for each inidividual page. On the main disambiguation pages, for en:, the following text block is currently used:
''This is a [[wikipedia:disambiguation|disambiguation]] page; that is, one that just points to other pages that might otherwise have the same name. If you followed a link here, you might want to go back and fix that link to point to the appropriate specific page.''
It may be useful to be able to transclude such text segments ([[>Wikipedia:Disambiguation]] or something like this). However, I am also thinking about having these segments be inserted as part of a general category scheme, such as
[[Category:Disambiguation page]]
Where that page would list all pages in that category, with automatic paging and sorting, and allow editors to define a standard block of text that is added at the bottom of all pages of that category. So we could use the same principle for
[[Category:Stub]]
or
[[Category:Deletion]]
To have texts like
''This aricle is a [[Wikipedia:stub article|stub]]. Please see [[:Category:Stub]] for a list of current stub articles.''
or
''This page has been marked for deletion. In order to debate its deletion, please use the discussion page.''
Regards,
Erik
Erik Moeller wrote:
It may be useful to be able to transclude such text segments ([[>Wikipedia:Disambiguation]] or something like this). However, I am also thinking about having these segments be inserted as part of a general category scheme, such as
[[Category:Disambiguation page]]
Where that page would list all pages in that category, with automatic paging and sorting, and allow editors to define a standard block of text that is added at the bottom of all pages of that category. So we could use the same principle for
[[Category:Stub]]
or
[[Category:Deletion]]
To have texts like
''This aricle is a [[Wikipedia:stub article|stub]]. Please see [[:Category:Stub]] for a list of current stub articles.''
or
''This page has been marked for deletion. In order to debate its deletion, please use the discussion page.''
Much of this seems compatible to a suggestion that I made several months ago: To include a category box or boxes at the bottom of the edit page. At the time I also spoke in terms of a specific category scheme, which some people felt would be just one more thing to learn before it could be used effectively. Although I would still favour that scheme there is no reason why we can't (at least in the early stages of such an initiative) have multiple overlapping schemes. A which-is-better debate about various possible schemes in the early stages could rapidly lead to accomplishing absolutely nothing. If multiple schemes are allowed, usage and practice will over time determine what stays. Disused schemes will die by atrophy.
Whether there are many boxes at the end of an article, or one box with comma delimited categories would make no difference to me. Although I would appreciate an option being available for case sensitive searches.
When I discussed this before I raised the possibility of an "XXX" classification for possibly objectionable material. Some responses at the time felt that this was tantamount to applying censorship. From my perspective any censorship would only be applied at the home computer level, and would give a parent the opportunity to block articles with certain codes from being viewed by their children. Providing this sort of opportunity would at least give the public some confidence that we are aware of the problems.
Erik's suggestion of categories to detect stubs or to mark an article for deletion could fit in very well. A simple search of category boxes for the word stub could instantly creat a list of these.
As the project gets bigger indexing will become more problematical. Brute searches of the data base are not always the most satifactory. A biography of a famous person will most often not include the word "biography" to be used as a search element. Having an [[Index of ...]] or [[List of ...]] article does not guarantee that everything that could go on that list does go on it.
In Wiktionary we have seen a proliferation of index pages for multiple languages. I've had doubts from the beginning about whether this approach would be viable in the long run. It can be a lot of additional work to insure that each article is properly indexed and linked, often from places whose existence is completely unknown to the newcomer. One established contributor has taken to setting up a series of Wiktionary articles withe the title format [[Polish word: foo]]. It would be a whole lot simpler if the [[foo]] article could have a PL in it's index box.
Eclecticology
Ray Saintonge schrieb:
Erik Moeller wrote:
However, I am also thinking about having these segments be inserted as part of a general category scheme, such as
[[Category:Disambiguation page]]
Much of this seems compatible to a suggestion that I made several months ago: To include a category box or boxes at the bottom of the edit page.
Magnus Manske schrieb:
For the disambiguation pages, I would imagine something as simple as a "{{DISAMBIGUATION}}" variable
Okay, this discussion is coming up again and again. I've said that I'm against putting more of this meta-information into the article text, but some people feel a pressing need for it. So how about adding an extra meta:-namespace were this information could be put in? So we could also get rid of the annoying interlanguage links on top of each article.
This namespace could have some extra functionality like drop-down-boxes, and some magic to *suggest* missing interlanguage links. And while I don't like the idea to have article ratings inside Wikipedia, but seem to be quite alone with this opinion, this could also be handled there.
Kurt
Kurt Jansson wrote:
Ray Saintonge schrieb:
Erik Moeller wrote:
However, I am
also thinking about having these segments be inserted as part of a general category scheme, such as
[[Category:Disambiguation page]]
Much of this seems compatible to a suggestion that I made several months ago: To include a category box or boxes at the bottom of the edit page.
Magnus Manske schrieb:
For the disambiguation pages, I would imagine something as simple as a "{{DISAMBIGUATION}}" variable
Okay, this discussion is coming up again and again. I've said that I'm against putting more of this meta-information into the article text, but some people feel a pressing need for it. So how about adding an extra meta:-namespace were this information could be put in? So we could also get rid of the annoying interlanguage links on top of each article.
This namespace could have some extra functionality like drop-down-boxes, and some magic to *suggest* missing interlanguage links. And while I don't like the idea to have article ratings inside Wikipedia, but seem to be quite alone with this opinion, this could also be handled there.
To be perfectly clear, I am not saying that the category material should be in the body of an article but in a completely separate box. If that fits in with your idea of a "meta-namespace" that's just fine. The interlanguage links have never bothered me, and I've always thought of them more as a benefit than a problem. However, in saying that I also have to admit that I rarely use them. Using drop down boxes for interlanguage links would likely be just as effective.
I would also make a distinction between Interlanguage (IL) boxes, and Index (IX) boxes. IL boxes would involve links between pedias, so they would need to be applied consistently in all the projects. IX boxes would address the requirements of a particular pedia, and its contents could be fashioned to suit the needs of that community. Wiktionary has already developed many unique characteristics, so I am sure that it would use IX boxes quite differently from the other projects. It could use the IL boxes to link to substantive articles arising from a word.
I suppose that some people mught interpret my proposal for XXX codings as "ratings", but I also need to be clear that I think that dumbing down an article in order to appeal to the most prudish elements in a society does not have my support. It will still be an individual human's choice to put an XXX coding in an IX box, and I anticipate that there will be edit wars over this kind of thing.
Eclecticology
Kurt Jansson wrote:
Okay, this discussion is coming up again and again. I've said that I'm against putting more of this meta-information into the article text, but some people feel a pressing need for it. So how about adding an extra meta:-namespace were this information could be put in? So we could also get rid of the annoying interlanguage links on top of each article.
I don't think that we want a *namespace* -- it's all for the one page. But an extra little box on the edit page (perhaps turned on as an option?) could be useful, for both language links and category information.
In the past, I've been quite suspicious of category information, but ''meta'' categories (like "stub", "disambiguation", etc) are different. And once we get the code running well for them, if ''content'' categories fit into the scheme perfectly well (that is, without complicating the editing process), then we could always try them out at that time.
-- Toby
On Wed, 28 May 2003, Magnus Manske wrote:
I hacked a small function that automatically shows what might be disambiguation pages below the page subtitle. This works for all pages with a " (" in the title.
This is very cunning! The list might get a bit cluttered, though, for articles whose titles have lots of different meanings. And, although you say that the feature is not meant to replace human-written disambiguation pages, it might have the effect of discouraging people from writing them in practice. On the other hand, it would help them, by telling them what to put in those disambiguation pages...
On the whole, though, I think Toby's idea of linking to just the one human-written disambiguation page is nicer, as it would clutter the page less, and would leave disambiguation in the hands of the humans, who can still do these things better. But maybe that's irrelevant, as this version has been coded and that one hasn't...
Oliver
+-------------------------------------------+ | Oliver Pereira | | Dept. of Electronics and Computer Science | | University of Southampton | | omp199@ecs.soton.ac.uk | +-------------------------------------------+
Oliver Pereira wrote in part:
On the whole, though, I think Toby's idea of linking to just the one human-written disambiguation page is nicer, as it would clutter the page less, and would leave disambiguation in the hands of the humans, who can still do these things better. But maybe that's irrelevant, as this version has been coded and that one hasn't...
Thanks for the opinion. And it shouldn't be a big changed to the code. Maybe I look at the code for myself and be of some use someday ...
-- Toby
wikipedia-l@lists.wikimedia.org