On 30/08/05, Tels nospam-abuse@bloodgate.com wrote:

is an interesting one. Changing the system so that you keep the list of redirects inside (at end) article A would have the benefit that you see them at once and can maintain them better. Currently someone reading A doesn't (easily) see all the redirects to it.

I agree that this could be a useful feature, but I think it would need to be a little more subtle, and I can foresee some major issues with implementing it. Perhaps a separate box on the edit page listing "pages that redirect here" - generated dynamically, not stored with the page's content, as that could easily lead to inconsistencies.

Another related question is how to deal with double redirects, particularly those caused when moving a page: Should the software fix them automatically [or implicitly do so, as it would if they were stored with the content]? Probably not, since a page move is sometimes to make way for a more suitable article at the old title, so the redirects may belong to one or the other. But in that case, how do you display such double redirects in the "backwards" list? Perhaps you'd not list them at all, and people could copy-and-paste them from the new redirect's edit page if appropriate.

If two articles have the same article name in their synonym list, an disambigition (sp?) page could be automatically created (with a warning issued to the editor that the current saved article asks for a redirect which an already existing article also has).

This is an important problem with editting the list backwards like this - an edit is usually considered "complete" when you click save, whereas this would be more of an interactive process, where you need to look at the feedback to see whether the software has actually allowed your changes.

And what happens if I *remove* a redirect from the list - does the page get deleted, even though I don't have deletion rights? Or perhaps just changed to a blank page? Remember it might have history from before it was a redirect...

Perhaps in the end what is needed is a move-page like function that lets you say "if any of these articles don't exist, make them redirect to X", which would then tell you which ones it had been unable to create so you could do them manually.

Of course, even that would be open to abuse, since it potentially allows a user to create tons of junk redirects in very little time...

In the future one could even do away with each redirect to be it's own article (which always seemed a bit awkward to me, you end up having to not count these in a lot of places (redirects arent articles in the sense of a real article, so they are no short articles, no real articles etc). However, this would be a quite a change.

The thing with this is that it just creates special cases elsewhere instead - if redirects weren't articles, then every time the software "follows" a link, it would have to first check if there was an article with that name, and then check if there was a redirect with that name. And any places where you *do* want to count redirects - Special:Wantedpages, for instance - would then have to explicitly include them. So I think this would be rather a case of swapping "six of one for half a dozen of the other".

Also, what would happen to an article which was turned into a redirect? Would it have to be deleted, so that the text didn't mask the redirect - or perhaps it could still exist, but be hidden by the fact that the redirect existed; in which case, how would you revert it back to being an article? Although it seems weird editting the text of an article to turn it into a redirect, it does make sense to store that action in the edit history along with everything else, even if it has a *side-effect* of creating better metadata than we have now.

Perhaps a new feature of "aliases" which belong to an article, as a separate feature to redirects but built on top of the redirect feature in a well-thought-out way. Perhaps at a later stage aliases could completely replace redirects.

So you suggest to handle a alias-redirect page as a list with "every term inside point to main article"? We could then insert synonyms and equivalent expression too. Sounds a good idea: a redirect seems to be an alias anyway. What about typing errors handling? A fuzzy system would be easier then guessing all the possible mispellings and inserting them.

Valentina Faussone

___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.beta.messenger.yahoo.com

On 01/09/05, Andrew Dunbar hippytrail@gmail.com wrote:

Perhaps a new feature of "aliases" which belong to an article, as a separate feature to redirects but built on top of the redirect feature in a well-thought-out way.

Well, isn't that what we're discussing - how to make it "well-thought-out"? Like I say, I agree with the usefulness of the idea, but I'm not yet sure how to deal with the subtleties of it.

Perhaps at a later stage aliases could completely replace redirects. Are there uses of redirects which are distinct from aliases?

Well, some would say there *shouldn't be*, but in practice redirects also get used for things like redirecting a sub-topic which doesn't deserve its own article to a wider topic which contains it. Personally, I think this is rather useful in cases where there will probably *never* be an article just about the sub-topic ("List of minor characters in X" are one example of this set-up) as it saves the user an extra click. Such uses aren't really "aliases", but then there's no real reason to separate them technically.

I'm assuming the concept of aliases owned by the article is easily understood.

Yes, I get the idea of having them conceptually attached to the article, but in terms of implementation this raises some complex issues: * How do you deal with the fact that a given title can be both an article in its own right, and an alias defined by another article? * How do you keep the code efficient if it has to check two places (the list of redirects and the list of actual pages) every time it wants to look up a title? * If you abandon the current "redirect created by magic page content", how do you convert a page to an alias, or vice versa? * What happens when somebody tries to create an alias which is already a page, or which is already an alias for something else? * What happens when you remove something from the list of aliases?

The last three boil down to "where is the central point of control for aliases" - given the title "Bar" which may or may not redirect to "Foo", the current system requires all changes in that state to happen on the "Bar" edit page. Being able to edit a separately-stored alias called "Bar" via "Foo" would necessitate some way of the two edits suppressing each other (you can't create an alias, because there's a page there / you can't create a page, because there's an alias there) and then some mechanism for overriding that (delete the page? blank it? tick a 'notify watching users and create alias anyway' box? / edit "Foo" to remove the alias? tick a special 'notify and confirm' box?).

So, like I say, maybe the most sensible thing would be to leave the data-structures mostly as they are, but create some user-interface tools which let you manipulate redirects en masse - "fix these double redirects for me", "create redirects at these pages for me", and even "edit the destinations of this list of redirects" are all features which could be fairly straightforwardly automated within the existing scheme. [They'd have to act like a kind of built-in bot, leaving automatic edit summaries behind like moving pages now does.] Like I say, who gets to do it would be an important question, because it could potentially create a vandal's playground, but that's doable too - indeed, more doable with a Special: page than with some voodoo built into ordinary edit pages.

On 05/09/05, Timwi timwi@gmx.net wrote:

I think most of those questions are quite easy to answer once you realise that (a) 99% of people looking for a topic do so via the search box, not the URL; (b) when someone links to an article, they do it via the URL, not the search box. Hence:

Ah - this is indeed a distinction I hadn't considered; I guess I'm just too "stuck" in the traditional wiki concept that internal links are what holds everything together. Personally, I almost never use the search box, because I know the naming conventions and the URL form, and just guess that way; this may be silly of me.

...

• How do you deal with the fact that a given title can be both an

article in its own right, and an alias defined by another article?

The URL should display the article. The search box should give a selection of both possibilities.

So, an internal link to [[Foo]] would always go to the article "Foo", if it existed, but typing "Foo" and clicking "Go" might come up with a list of alternatives instead; I guess that could work. Of course, this isn't nearly as related to redirects as earlier discussion suggested, being more like an enhancement to the search facility (a way of manually stuffing things into the results) than giving alternative titles to pages.

...

• How do you keep the code efficient if it has to check two places

(the list of redirects and the list of actual pages) every time it wants to look up a title?

Caching.

I was referring more to the fact that during the course of a request, many many titles may be looked up in the database; if they had to be looked up in a separate 'alias' table as well (not a necessary part of the implementation, but one some were suggesting), the number of queries would, AFAICS, effectively double. But this is moot if you're only talking about search functions, not links.

...

• If you abandon the current "redirect created by magic page content",

how do you convert a page to an alias, or vice versa?

You don't "convert" a page to an alias; you just create the alias, and independently of that, delete the page (if that is what you want to do). Similarly, removing an alias and creating a page should also be separate actions.

If no interaction with internal links is implied, then yes, that makes sense. If you wanted links to be able to point at aliases, too, I guess you could add an automatic disambiguation message at the top of the page ("$1 is also defined as an alias for $2[, $3[, etc]]") - preferably with appropriate links for managing the aliases.

...

• What happens when somebody tries to create an alias which is already

a page, or which is already an alias for something else?

The alias gets created as always. Now if someone searches for the alias, it should (obviously) list all the pages that have this alias. The same should probably happen to the URL if there is no actual page at that title; although I wouldn't mind having the URL display the "page does not exist" screen so that it is easier to create a page at that title.

If these aliases are only intended for searching, they should definitely not display as though the page existed - they should probably be displayed in a clear box above the "page does not exist screen", both for search results and "URLs" (since linking to a page that doesn't exist is a bit like searching; linking to a page that does exist is less so).

...

• What happens when you remove something from the list of aliases?

The alias gets removed. Duh. :-) We already have this happening with categories.

Again, I was thinking of aliases as being more similar to redirects - a way of defining a particular title as being an alias for exactly one page (many aliases, but each with only one target). In the context of a many-to-many mapping, of course this is a no-brainer. If other people were thinking in terms of many-to-many, my apologies for not cottoning on sooner - as far as I know, you're the first one to make this explicit.

With this in mind, let's revisit the question of whether these could replace at least some redirects. It seems to me that if they did, they would actually end up replacing disambiguation pages as well - if a title was associated with only one alias, it would redirect, if more than one, disambiguate. For example, "BT" could be an alias for various pages which might have that name if they weren't in conflict, with the summaries stored somewhere with the aliases themselves (and perhaps editable from both the disambig page *and* the target one). Some kind of warning or protection *would* then be needed when creating a page in place of one or more aliases, as this would affect the operation of all links referencing that title (turning the redirect into a "See also" message, or the disambig page into a "For other uses..." reference, akin to current en.wp "see [[<foo> (disambiguation)]]")

I think some way of "compiling" redirects from some kind of directive in the main article is a very good and important idea. Especially for Wiktionary where most words have one or many inflected forms.

Some way to handle conflicts would obviously be necessary. Perhaps a way to warn that those need to be handled the old way, perhaps automatically generated disambiguation pages.

Andrew Dunbar (hippietrail)

On 8/30/05, Evan Martin evanm@google.com wrote:

On 8/30/05, Mark Williamson node.ue@gmail.com wrote:

...

"In most languages" is not true.

The majority of the world's languages do not have gender.

[...]

...

So creating redirects for different forms of a word is not a concern for "most" languages.

Quibbles aside, synonymous terms like "car" and "automobile" occur in all languages. (Except maybe conlangs, I suppose.)

I think another way to word the proposal is: "Upon article submit, extract all of the by-hand-specially-marked synonyms and create redirect articles for the synonyms that don't already have articles." _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l