Author: TobyBartelsFormat: HtmlIt would be very convenient in this way:<p>Right now (for example) [[constructivism]] redirects to [[constructive mathematics]], because we only talk about the philosophy of constructivism in the context of motivating the kind of mathematics that constructivists do. (And the redirect exists at all only because [[constructivism]] was created first, but we —or at least I— found that the other name fit our usage better.) But someday (since this wiki <em>is</em> supposed to be about philosophy as well, after all) we may want to have a page that actually discusses the philosophy of constructivism. When that happens, we'll (or I'll, since I'm the one who does this sort of thing) will have to check all of the links to [[constructive mathematics]] and change those few (and there are a few) that are really about philosophy and so should now link to [[constructivism]]. Whereas, if we had MediaWiki-style redirects, we could link those to [[constructivism]] now and not need to change anything later.<p>It would be nice not to have to fix links when they're first made so that they point to the correct, non-redirect page. But that's not such a big deal. Checking a whole bunch of links all at once, on the other hand, can be a problem; it certainly will not scale.

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
It would be very convenient in this way:<p>Right now (for example) <a href="http://ncatlab.org/nlab/show/constructivism">constructivism</a> redirects to <a href="http://ncatlab.org/nlab/show/constructive+mathematics">constructive mathematics</a>, because we only talk about the philosophy of constructivism in the context of motivating the kind of mathematics that constructivists do. (And the redirect exists at all only because <a href="http://ncatlab.org/nlab/show/constructivism">constructivism</a> was created first, but we —or at least I— found that the other name fit our usage better.) But someday (since this wiki <em>is</em> supposed to be about philosophy as well, after all) we may want to have a page that actually discusses the philosophy of constructivism. When that happens, we'll (or I'll, since I'm the one who does this sort of thing) will have to check all of the links to <a href="http://ncatlab.org/nlab/show/constructive+mathematics">constructive mathematics</a> and change those few (and there are a few) that are really about philosophy and so should now link to <a href="http://ncatlab.org/nlab/show/constructivism">constructivism</a>. Whereas, if we had MediaWiki-style redirects, we could link those to <a href="http://ncatlab.org/nlab/show/constructivism">constructivism</a> now and not need to change anything later.<p>It would be nice not to have to fix links when they're first made so that they point to the correct, non-redirect page. But that's not such a big deal. Checking a whole bunch of links all at once, on the other hand, can be a problem; it certainly will not scale.</p></p>
</div>

Author: Mathforge AdminFormat: TextUsing my superuser powers, I'm reopening this discussion. Jacques would be willing to implement redirects, but it's not so simple as just saying "let's have redirects". There's different ways of doing it, some better than others, and it depends a little on what, exactly, we mean by "redirect". I'm not sure I'm clear as to what all the issues are so that may need a little investigating as well.
Anyway, as admin all I'm doing is reopening this discussion (rather than having a completely new one on the same topic).

Using my superuser powers, I'm reopening this discussion. Jacques would be willing to implement redirects, but it's not so simple as just saying "let's have redirects". There's different ways of doing it, some better than others, and it depends a little on what, exactly, we mean by "redirect". I'm not sure I'm clear as to what all the issues are so that may need a little investigating as well.

Anyway, as admin all I'm doing is reopening this discussion (rather than having a completely new one on the same topic).

Author: Mike ShulmanFormat: MarkdownBTW, redirects are mentioned on the main [instiki feature request](http://www.instiki.org/show/FeatureRequest) page. I would like to hear about the different ways of doing redirects; to me the most obvious approach is what mediawiki does.

BTW, redirects are mentioned on the main instiki feature request page. I would like to hear about the different ways of doing redirects; to me the most obvious approach is what mediawiki does.

Author: TobyBartelsFormat: HtmlMediaWiki's redirects have at least three features that one could vary:<ul><li>They allow for redirects to an anchor somewhere in the middle of the page (which requires Javascript to work, else you go to the top of the page).</li><li>There can be more in the redirect page after the redirect code itself, such as notes about the redirect or placing the redirect in a category.</li><li>After you're redirected, the title has a backlink to the redirect page with a control in the URL that prevents you from being redirected again.</li></ul>The first two of these are simply features that you might or might not include; the last can be varied in at least three ways:<ul><li>You could leave out the backlink, requiring people to type in an edit URL directly to change a redirect (probably a bad idea).</li><li>The backlink could be only to the edit page of the redirect page (so no need to program a variation in the URL to override redirection).</li><li>… I thought of another way while I was writing this, but now I forget it …</li></ul>Redirects also interact with other features in MediaWiki, including the list of linking pages and internal searches.

MediaWiki's redirects have at least three features that one could vary:

They allow for redirects to an anchor somewhere in the middle of the page (which requires Javascript to work, else you go to the top of the page).

There can be more in the redirect page after the redirect code itself, such as notes about the redirect or placing the redirect in a category.

After you're redirected, the title has a backlink to the redirect page with a control in the URL that prevents you from being redirected again.

The first two of these are simply features that you might or might not include; the last can be varied in at least three ways:

You could leave out the backlink, requiring people to type in an edit URL directly to change a redirect (probably a bad idea).

The backlink could be only to the edit page of the redirect page (so no need to program a variation in the URL to override redirection).

… I thought of another way while I was writing this, but now I forget it …

Redirects also interact with other features in MediaWiki, including the list of linking pages and internal searches.

Author: Andrew StaceyFormat: MarkdownMike, I thought it best for us to have a discussion on what we want from redirects first and then take it to Jacques once we'd decided that. I suspect that the restrictions on how it is implemented are actually orthogonal to what features it can provide, so if we come up with a spec, Jacques can look at it and think about how to implement it. At that point he may come back with "why do you want that particular bit?" whereupon we can say exactly why, rather than just "oh, so-and-so thought it might be nice.".
Basically, the more information that you can give a developer when making a feature request, the more likely it is that it will be implemented. It says two things: firstly, exactly what is wanted (useful for figuring out exactly how to implement it) and secondly, that someone wants this feature enough to have actually thought about it - rather than just firing off an email at the drop of a hat.
So .. things to think about.
External automatic use: when an external program links to a redirected page, should they really be pointing to the main page or to the redirect?
User use of redirects: when a user clicks on a link, should they know that they've been redirected? Toby mentions this as a feature of MediaWiki redirects but do we really want it? Most of the redirects so far seem to be just minor respellings or ASCIIfication.
Creation of redirects: how easy should it be to create redirects? Are redirects good, neutral, or bad?
Editor use of redirects: again, are redirects okay or should they be shunned? That is, if someone edits a page and puts a link to something _already_ redirected, should it automatically be altered to the main page?
Essentially, who are the redirects for? It may be that there are several types of redirect: redirects because we've changed our minds on what some page should be called, and redirects because there are several conventions in use but we only want to have one page with the information.
If you think of a Unix filesystem then you have symlinks and hard links. A hard link is completely indistinguishable from the original file, indeed there is no way with hard links to say which was the original file and which the link. With a symlink, it is very different. Most of the time, the two are used synonymously but there are occasions when it is useful to have both.

Mike, I thought it best for us to have a discussion on what we want from redirects first and then take it to Jacques once we'd decided that. I suspect that the restrictions on how it is implemented are actually orthogonal to what features it can provide, so if we come up with a spec, Jacques can look at it and think about how to implement it. At that point he may come back with "why do you want that particular bit?" whereupon we can say exactly why, rather than just "oh, so-and-so thought it might be nice.".

Basically, the more information that you can give a developer when making a feature request, the more likely it is that it will be implemented. It says two things: firstly, exactly what is wanted (useful for figuring out exactly how to implement it) and secondly, that someone wants this feature enough to have actually thought about it - rather than just firing off an email at the drop of a hat.

So .. things to think about.

External automatic use: when an external program links to a redirected page, should they really be pointing to the main page or to the redirect?

User use of redirects: when a user clicks on a link, should they know that they've been redirected? Toby mentions this as a feature of MediaWiki redirects but do we really want it? Most of the redirects so far seem to be just minor respellings or ASCIIfication.

Creation of redirects: how easy should it be to create redirects? Are redirects good, neutral, or bad?

Editor use of redirects: again, are redirects okay or should they be shunned? That is, if someone edits a page and puts a link to something already redirected, should it automatically be altered to the main page?

Essentially, who are the redirects for? It may be that there are several types of redirect: redirects because we've changed our minds on what some page should be called, and redirects because there are several conventions in use but we only want to have one page with the information.

If you think of a Unix filesystem then you have symlinks and hard links. A hard link is completely indistinguishable from the original file, indeed there is no way with hard links to say which was the original file and which the link. With a symlink, it is very different. Most of the time, the two are used synonymously but there are occasions when it is useful to have both.

Author: TobyBartelsFormat: Html<blockquote>External automatic use</blockquote>I'm not sure what you're asking about here. If you mean should we show them an HTTP 403, then no, since they might have good reason to point to the redirect page. (See under editor use of redirects.)<p><blockquote>User [reader] use of redirects</blockquote>Editors are also readers, so there should be some indication that a redirect was followed. However, it could be quite unobtrusive, at the bottom of the page, I think.<p><blockquote>Creation of redirects</blockquote>I find them quite helpful in Wikipedia; some people there may find me a little too much of a redirect booster. Prophylactic redirects avoid duplication of effort; redirects from alternative spellings and grammatical variations reduce the need for pipe links (like <code>[[category|categories]]</code>), although low usage of such pipe links can also encourage laxity about naming conventions (but easy page moves and redirects make naming conventions less important too).<p><blockquote>Editor use of redirects</blockquote>We certainly should not automatically alter a link to a redirect page to point to the target page. (I say ‘target page’, because ‘main page’ can also mean the home page of a wiki web.) While perhaps <code>[[categories]]</code> should be changed to <code>[[category|categories]]</code>, still <code>[[constructivism]]</code> should not be changed to <code>[[constructive mathematics|constructivism]]</code> if the link is really about philosophy. (See my comment above from March 19.) Allowing comments on a redirect page in addition to the redirect code itself can help editors who aren't sure what to do.

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
<blockquote>External automatic use</blockquote>I'm not sure what you're asking about here. If you mean should we show them an HTTP 403, then no, since they might have good reason to point to the redirect page. (See under editor use of redirects.)<p><blockquote>User [reader] use of redirects</blockquote>Editors are also readers, so there should be some indication that a redirect was followed. However, it could be quite unobtrusive, at the bottom of the page, I think.<p><blockquote>Creation of redirects</blockquote>I find them quite helpful in Wikipedia; some people there may find me a little too much of a redirect booster. Prophylactic redirects avoid duplication of effort; redirects from alternative spellings and grammatical variations reduce the need for pipe links (like <code><a href="http://ncatlab.org/nlab/show/category">categories</a></code>), although low usage of such pipe links can also encourage laxity about naming conventions (but easy page moves and redirects make naming conventions less important too).<p><blockquote>Editor use of redirects</blockquote>We certainly should not automatically alter a link to a redirect page to point to the target page. (I say ‘target page’, because ‘main page’ can also mean the home page of a wiki web.) While perhaps <code><a href="http://ncatlab.org/nlab/show/categories">categories</a></code> should be changed to <code><a href="http://ncatlab.org/nlab/show/category">categories</a></code>, still <code><a href="http://ncatlab.org/nlab/show/constructivism">constructivism</a></code> should not be changed to <code><a href="http://ncatlab.org/nlab/show/constructive+mathematics">constructivism</a></code> if the link is really about philosophy. (See my comment above from March 19.) Allowing comments on a redirect page in addition to the redirect code itself can help editors who aren't sure what to do.</p></p></p>
</div>

Author: Mike ShulmanFormat: MarkdownI agree with all of Toby's responses to Andrew's questions. Except that I wouldn't mind having the mention that a redirect was followed at the top of the page in small print, the way mediawiki does it.
Regarding the three issues Toby mentioned, as you say the first two are just features one could include or not, although it seems as though the second one would be more effort to forbid than to permit (and I don't see any reason to forbid it). Links to anchors would probably be useful, but could also be added later once we have basic redirects working, so I would say they are not top priority. And I don't have a strong feeling either way about whether the backlinks should use a URL variation or go directly to the edit page; whichever is easier to implement would be fine with me.

I agree with all of Toby's responses to Andrew's questions. Except that I wouldn't mind having the mention that a redirect was followed at the top of the page in small print, the way mediawiki does it.

Regarding the three issues Toby mentioned, as you say the first two are just features one could include or not, although it seems as though the second one would be more effort to forbid than to permit (and I don't see any reason to forbid it). Links to anchors would probably be useful, but could also be added later once we have basic redirects working, so I would say they are not top priority. And I don't have a strong feeling either way about whether the backlinks should use a URL variation or go directly to the edit page; whichever is easier to implement would be fine with me.

Author: TobyBartelsFormat: HtmlAnother thing that I would like from redirects, and which MediaWiki does <em>not</em> offer, is this: If <code>[[foo]]</code> redirects to <code>[[bar]]</code> but <code>[[bar]]</code> does not exist, then any link to <code>[[foo]]</code> looks normal (until you follow it) in MediaWiki, which basically means that you can't create prophylactic redirects without writing a stub (or confusing readers about what exists). It would be nice if it would also show up as a link to an unwritten page and invite you to create <code>[[bar]]</code> when you follow it. This probably requires additional work, however, and it's not a big deal.<p>Also, here is an important technical consideration for anybody programming redirects: What happens if a redirect points to a redirect, possibly in a loop? MediaWiki ingores the second redirect, so no loops are possible but double redirects need to be fixed by editing the first redirect page. A more sophisticated solution, but also probably requiring additional work, is to detect loops but otherwise allow multiple redirects; alternatively, you could allow up to <i>n</i> steps before giving up. It would be nice to have at least <em>one</em> additional step, say when an alternative spelling <code>[[fu]]</code> redirects to a page <code>[[foo]]</code> that doesn't (yet) exist independently but whose topic is discussed on yet another page <code>[[bar]]</code>. Redirecting <code>[[fu]]</code> directly to <code>[[bar]]</code> makes it a bit more difficult (although still manageable) when <code>[[foo]]</code> is later separated into its own page.<p>So here you see feature creep: I have just requested two features that even MediaWiki does not provide! So feel free to ignore them if they make life more difficult, but also don't forget to do something to prevent infinite loops.

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
Another thing that I would like from redirects, and which MediaWiki does <em>not</em> offer, is this: If <code><a href="http://ncatlab.org/nlab/show/foo">foo</a></code> redirects to <code><a href="http://ncatlab.org/nlab/show/bar">bar</a></code> but <code><a href="http://ncatlab.org/nlab/show/bar">bar</a></code> does not exist, then any link to <code><a href="http://ncatlab.org/nlab/show/foo">foo</a></code> looks normal (until you follow it) in MediaWiki, which basically means that you can't create prophylactic redirects without writing a stub (or confusing readers about what exists). It would be nice if it would also show up as a link to an unwritten page and invite you to create <code><a href="http://ncatlab.org/nlab/show/bar">bar</a></code> when you follow it. This probably requires additional work, however, and it's not a big deal.<p>Also, here is an important technical consideration for anybody programming redirects: What happens if a redirect points to a redirect, possibly in a loop? MediaWiki ingores the second redirect, so no loops are possible but double redirects need to be fixed by editing the first redirect page. A more sophisticated solution, but also probably requiring additional work, is to detect loops but otherwise allow multiple redirects; alternatively, you could allow up to <i>n</i> steps before giving up. It would be nice to have at least <em>one</em> additional step, say when an alternative spelling <code><a href="http://ncatlab.org/nlab/show/fu">fu</a></code> redirects to a page <code><a href="http://ncatlab.org/nlab/show/foo">foo</a></code> that doesn't (yet) exist independently but whose topic is discussed on yet another page <code><a href="http://ncatlab.org/nlab/show/bar">bar</a></code>. Redirecting <code><a href="http://ncatlab.org/nlab/show/fu">fu</a></code> directly to <code><a href="http://ncatlab.org/nlab/show/bar">bar</a></code> makes it a bit more difficult (although still manageable) when <code><a href="http://ncatlab.org/nlab/show/foo">foo</a></code> is later separated into its own page.<p>So here you see feature creep: I have just requested two features that even MediaWiki does not provide! So feel free to ignore them if they make life more difficult, but also don't forget to do something to prevent infinite loops.</p></p>
</div>

Author: Mike ShulmanFormat: MarkdownAs a reply to Andrew, when I am the developer on some project, I generally prefer to be involved in feature discussions from the beginning. Sometimes people make unwarranted assumptions that can waste everyone's time until they are corrected, and in my experience restrictions and features are rarely orthogonal. A case in point: as soon as this was brought up to Jacques he [brought up](http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024182) two aspects of a redirect implementation that it wouldn't have occurred to me to think of making different from mediawiki.

As a reply to Andrew, when I am the developer on some project, I generally prefer to be involved in feature discussions from the beginning. Sometimes people make unwarranted assumptions that can waste everyone's time until they are corrected, and in my experience restrictions and features are rarely orthogonal. A case in point: as soon as this was brought up to Jacques he brought up two aspects of a redirect implementation that it wouldn't have occurred to me to think of making different from mediawiki.

Author: TobyBartelsFormat: HtmlOK, so here's how the new redirects on the Lab work.<p>If you want [[foo]] to redirected to [[bar]], then <em>don't</em> create [[foo]]! Instead, edit [[bar]] to include (at the top, although there can be a list) [[!redirects foo]]. Then any internal link to [[foo]] will actually become an HTML link to [[bar]]. If anybody creates [[foo]], then this breaks. If another page has [[!redirects foo]] added to it, then (I think, I'm not sure that this all worked right) it wins, until that text is removed from it and the first page gets the redirect back.<p>If you're editing a page, then you can also click a check box to change its title; this will only allow you to move it to a page that doesn't already exist. Automatically, the new page gets a redirection from the old page, although you can get rid of this if you want.<p>What's missing:<ul><li>To find out where [[foo]] redirects, you need to make a link on the Sandbox and follow it (or at least look at where it goes). There does not seem to be a place to just look it up. (That's OK, I think.)</li><li>You can't add any notes about the redirect, except on the target page.</li><li>You can't merge pages; this is rare, but it has happened.</li><li>We can't actually fix any of our current redirects, since those pages already exist!</li></ul><p>The last is the big problem, in my opinion. If there's no edit history, that's OK; delete them. But most of these have some (and some of these have most) of the edit history of their target pages, and this shouldn't be deleted. The best that we can do is to shunt that history into something like [[bar/history]]. (Method: if [[foo]] redirects to [[bar]] now using the old method, then move [[foo]] to [[bar/history]], remove [[!redirects foo]] from [[bar/history]], and add [[!redirects foo]] to [[bar]].)<p>The moving feature itself, as far as I can tell, works perfectly, except that there is no record of page moves.

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
OK, so here's how the new redirects on the Lab work.<p>If you want <a href="http://ncatlab.org/nlab/show/foo">foo</a> to redirected to <a href="http://ncatlab.org/nlab/show/bar">bar</a>, then <em>don't</em> create <a href="http://ncatlab.org/nlab/show/foo">foo</a>! Instead, edit <a href="http://ncatlab.org/nlab/show/bar">bar</a> to include (at the top, although there can be a list) <a href="http://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a>. Then any internal link to <a href="http://ncatlab.org/nlab/show/foo">foo</a> will actually become an HTML link to <a href="http://ncatlab.org/nlab/show/bar">bar</a>. If anybody creates <a href="http://ncatlab.org/nlab/show/foo">foo</a>, then this breaks. If another page has <a href="http://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a> added to it, then (I think, I'm not sure that this all worked right) it wins, until that text is removed from it and the first page gets the redirect back.<p>If you're editing a page, then you can also click a check box to change its title; this will only allow you to move it to a page that doesn't already exist. Automatically, the new page gets a redirection from the old page, although you can get rid of this if you want.<p>What's missing:<ul><li>To find out where <a href="http://ncatlab.org/nlab/show/foo">foo</a> redirects, you need to make a link on the Sandbox and follow it (or at least look at where it goes). There does not seem to be a place to just look it up. (That's OK, I think.)</li><li>You can't add any notes about the redirect, except on the target page.</li><li>You can't merge pages; this is rare, but it has happened.</li><li>We can't actually fix any of our current redirects, since those pages already exist!</li></ul><p>The last is the big problem, in my opinion. If there's no edit history, that's OK; delete them. But most of these have some (and some of these have most) of the edit history of their target pages, and this shouldn't be deleted. The best that we can do is to shunt that history into something like <a href="http://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>. (Method: if <a href="http://ncatlab.org/nlab/show/foo">foo</a> redirects to <a href="http://ncatlab.org/nlab/show/bar">bar</a> now using the old method, then move <a href="http://ncatlab.org/nlab/show/foo">foo</a> to <a href="http://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>, remove <a href="http://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a> from <a href="http://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>, and add <a href="http://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a> to <a href="http://ncatlab.org/nlab/show/bar">bar</a>.)<p>The moving feature itself, as far as I can tell, works perfectly, except that there is no record of page moves.</p></p></p></p></p>
</div>

Author: TobyBartelsFormat: HtmlI wrote:<blockquote>Method: if [[foo]] redirects to [[bar]] now using the old method, then move [[foo]] to [[bar/history]], remove [[!redirects foo]] from [[bar/history]], and add [[!redirects foo]] to [[bar]].</blockquote>Actually, you'd have to put it at [[foo/history]] to allow for the possibility that more than one current page redirects to [[bar]] (as does happen a few times already). You would also want, if you later decide to recreate [[foo]] separate from [[bar]], to do this by moving [[foo/history]] back to [[foo]] first. This is a little tricky, but it could work.

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
I wrote:<blockquote>Method: if <a href="http://ncatlab.org/nlab/show/foo">foo</a> redirects to <a href="http://ncatlab.org/nlab/show/bar">bar</a> now using the old method, then move <a href="http://ncatlab.org/nlab/show/foo">foo</a> to <a href="http://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>, remove <a href="http://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a> from <a href="http://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>, and add <a href="http://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a> to <a href="http://ncatlab.org/nlab/show/bar">bar</a>.</blockquote>Actually, you'd have to put it at <a href="http://ncatlab.org/nlab/show/foo%2Fhistory">foo/history</a> to allow for the possibility that more than one current page redirects to <a href="http://ncatlab.org/nlab/show/bar">bar</a> (as does happen a few times already). You would also want, if you later decide to recreate <a href="http://ncatlab.org/nlab/show/foo">foo</a> separate from <a href="http://ncatlab.org/nlab/show/bar">bar</a>, to do this by moving <a href="http://ncatlab.org/nlab/show/foo%2Fhistory">foo/history</a> back to <a href="http://ncatlab.org/nlab/show/foo">foo</a> first. This is a little tricky, but it could work.
</div>

Author: Mike ShulmanFormat: MarkdownJacques is fervently opposed to the Mediawiki way of doing things, where the instruction to redirect "foo" to "bar" appears on page "foo" rather than on "bar," for reasons which I am still failing to understand. (Can anyone explain it to me?) If we did it that way, it would seem to solve all of the problems you raise. [Here](http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024236) are some other issues with the current implementation.

Jacques is fervently opposed to the Mediawiki way of doing things, where the instruction to redirect "foo" to "bar" appears on page "foo" rather than on "bar," for reasons which I am still failing to understand. (Can anyone explain it to me?) If we did it that way, it would seem to solve all of the problems you raise. Here are some other issues with the current implementation.

Author: EricFormat: HtmlI suggest discussing this at the place where Jacques is already discussing it (since he's the one person that matters). We now have four different dialogues going on :|
http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024203

I suggest discussing this at the place where Jacques is already discussing it (since he's the one person that matters). We now have four different dialogues going on :|

Author: EricFormat: TextWhoa. I would highly recommend NOT creating a bunch of */history pages. There is a slick way to satisfy all our desires regarding redirects. Let's settle it over at Musing (or any place Jacques wishes)
My recommendation is here:
http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024243

Whoa. I would highly recommend NOT creating a bunch of */history pages. There is a slick way to satisfy all our desires regarding redirects. Let's settle it over at Musing (or any place Jacques wishes)

Author: Andrew StaceyFormat: MarkdownNo! We should discuss this __here__. I have just read through the discussion on Jacques' blog and I think it's time to leave Jacques alone for a bit. Let's play with this shiny new toy, see how it works, and test it a bit. We can discuss it a little amongst ourselves and then present our thoughts and bug reports to Jacques in one go.

No! We should discuss this here. I have just read through the discussion on Jacques' blog and I think it's time to leave Jacques alone for a bit. Let's play with this shiny new toy, see how it works, and test it a bit. We can discuss it a little amongst ourselves and then present our thoughts and bug reports to Jacques in one go.

Author: TobyBartelsFormat: HtmlYeah, I rather wish that we'd presented our feature request in one go too. It might have had all of the features that we wanted then!
And Eric, I agree not to create a bunch of */history pages yet. I did create a small bunch to test how well it work to create them en masse (answer: OK), but I won't create any more. (If your proposal is adopted, incidentally, the current */history pages can be moved back and thus will disappear.)

Yeah, I rather wish that we'd presented our feature request in one go too. It might have had all of the features that we wanted then!

And Eric, I agree not to create a bunch of */history pages yet. I did create a small bunch to test how well it work to create them en masse (answer: OK), but I won't create any more. (If your proposal is adopted, incidentally, the current */history pages can be moved back and thus will disappear.)

Author: Mike ShulmanFormat: MarkdownI'm still not convinced that this way is better than the mediawiki way, although I do see that it is cleaner in some respects. For instance, it is impossible to have chains or loops of redirects in this way (unless it is changed so that redirects take priority over existing pages, which I'm now leaning against). And after using it for a while I may come to like it.
I agree that the main thing missing now is what to do with external links. Right now it seems to me like HTTP redirects would be the best solution.

I'm still not convinced that this way is better than the mediawiki way, although I do see that it is cleaner in some respects. For instance, it is impossible to have chains or loops of redirects in this way (unless it is changed so that redirects take priority over existing pages, which I'm now leaning against). And after using it for a while I may come to like it.

I agree that the main thing missing now is what to do with external links. Right now it seems to me like HTTP redirects would be the best solution.

Author: Mike ShulmanFormat: MarkdownI'm curious, what are people's thoughts about redirecting plural forms? For instance, if the page `category` contained `[[!redirects categories]]` then we could start writing `[[categories]]` everywhere instead of `[[category|categories]]`.

I'm curious, what are people's thoughts about redirecting plural forms? For instance, if the page category contained !redirects categories then we could start writing categories everywhere instead of categories.

Author: EricFormat: TextI thought we might have been nearing a consensus regarding this. Here is my recommendation:
http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024262
which is equivalent to switching (1) and (2) of Jacques original outline
http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024255
Then Jacques refers to this thread saying "I think Mike wins". I don't see anything here that is a counter argument to having pages with [[!redirects foo]] take priority over [[foo]].
Mike, what are your thoughts on changing the order of priority?
I think [[!redirects foo]] should take priority. This is the only way to allow existing pages to redirect to other existing pages. We currently have MANY existing pages that could be accommodated, e.g.
http://ncatlab.org/nlab/list/redirect
For example, we would simply add
[[!redirects Philosophy]]
to [[philosophy]] and we're done.
Add
[[!redirects differential graded category]]
to [[dg-category]] and we're done.
What am I missing?

I thought we might have been nearing a consensus regarding this. Here is my recommendation:

http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024262

which is equivalent to switching (1) and (2) of Jacques original outline

http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024255

Then Jacques refers to this thread saying "I think Mike wins". I don't see anything here that is a counter argument to having pages with !redirects foo take priority over foo.

Mike, what are your thoughts on changing the order of priority?

I think !redirects foo should take priority. This is the only way to allow existing pages to redirect to other existing pages. We currently have MANY existing pages that could be accommodated, e.g.

Author: Mike ShulmanFormat: MarkdownThe comment of mine that Jacques linked to mentioned the fact that with existing pages taking priority over redirects, it is impossible to have chained or looped redirects. E.g. you can't have A redirecting to B and B redirecting to A at the same time, since that would require both A and B to exist as pages, so that no redirection would actually happen. If we changed it so that redirects take priority, then we'd have to think about how to avoid loops and whether to allow chains. So at least from the PoV of simplicity for the programmer, it is better as it is.
I am also not fully comfortable with the idea of having pages that exist but are invisible, and which furthermore can get that way by editing a _different_ page. For instance, suppose you write a long expository page called `widget`. Later on, I decide to create a stub called `wadget` with just a few lines, and since as everyone knows a widget is a special case of a wadget, I throw in a `[[!redirect widget]]` at the top of my `wadget` page. (I'm lazy or in a hurry, so I don't bother to check whether someone has written the page `widget` already.) If redirects take priority over existing pages, now all your carefully crafted text about widgets has silently disappeared from the world, and this disappearance won't even show up on the "recently revised" list because the page `widget` didn't change. No one will notice until they click on a link `[[widget]]` and are surprised to end up at my stub rather than your masterpiece.
It will take a bit of work to move all the existing `category:redirect` pages to `page/history`, although that could probably be automated. (Those with no history to speak of should just be deleted.) But I think that after that one-time change, it will be fairly rare that we need to redirect a page that already exists. For instance, if someone mistakenly creates `gizmos` in violation of the naming conventions, we can now simply _move_ the page to `gizmo` rather than copying the text and making `gizmos` a redirect. And if we pre-emptively redirect variants of names it should reduce the incidence of unintentional duplication. (I notice that with the new implementation it is easy to make _lots_ of different variants redirect to the same page just by adding a lot of `[[!redirect ]]` lines at the top, whereas with mediawiki you would have to create lots of separate redirect pages.) Merges will occasionally happen, but I don't think that there will be a lot of those.

The comment of mine that Jacques linked to mentioned the fact that with existing pages taking priority over redirects, it is impossible to have chained or looped redirects. E.g. you can't have A redirecting to B and B redirecting to A at the same time, since that would require both A and B to exist as pages, so that no redirection would actually happen. If we changed it so that redirects take priority, then we'd have to think about how to avoid loops and whether to allow chains. So at least from the PoV of simplicity for the programmer, it is better as it is.

I am also not fully comfortable with the idea of having pages that exist but are invisible, and which furthermore can get that way by editing a different page. For instance, suppose you write a long expository page called widget. Later on, I decide to create a stub called wadget with just a few lines, and since as everyone knows a widget is a special case of a wadget, I throw in a !redirect widget at the top of my wadget page. (I'm lazy or in a hurry, so I don't bother to check whether someone has written the page widget already.) If redirects take priority over existing pages, now all your carefully crafted text about widgets has silently disappeared from the world, and this disappearance won't even show up on the "recently revised" list because the page widget didn't change. No one will notice until they click on a link widget and are surprised to end up at my stub rather than your masterpiece.

It will take a bit of work to move all the existing category:redirect pages to page/history, although that could probably be automated. (Those with no history to speak of should just be deleted.) But I think that after that one-time change, it will be fairly rare that we need to redirect a page that already exists. For instance, if someone mistakenly creates gizmos in violation of the naming conventions, we can now simply move the page to gizmo rather than copying the text and making gizmos a redirect. And if we pre-emptively redirect variants of names it should reduce the incidence of unintentional duplication. (I notice that with the new implementation it is easy to make lots of different variants redirect to the same page just by adding a lot of !redirect lines at the top, whereas with mediawiki you would have to create lots of separate redirect pages.) Merges will occasionally happen, but I don't think that there will be a lot of those.

Author: Andrew StaceyFormat: MarkdownMy word, but you lot can sure talk a lot!
So we can redirect _non-existant_ pages simply by putting
`[[!redirects other name]]`
at the top of the page. So when we create a new page, we should think of the other possibilities (plurals, unicode) etc that we may want to use instead (I think that the __proper__ name should still be drawn from the character set [A-Za-z-_ ]).
There seem to be a few issues remaining, though.
1. Information about the redirect. Surely we can have a section on the resulting page explaining why there is a redirect. After all, if I'm redirected from `blithering idiot` to `Andrew Stacey` then I'd like to have an explanation right there as to why I was redirected, I don't want to have to hunt around on other pages. This information can be squirrelled away at the bottom of the page, of course, so that it doesn't intrude on the main entry.
2. Existing pages that should be redirects. Firstly, there's no difficulty in _moving_ the existing page out of the way of the redirect. Any relevant information can be copied to the new page. Of course, this loses history but _why is this important?_ The history of a Wiki is extremely linear and should not be thought of as a full-blown revision system. What can be done with Wiki history is very limited. It is the bare minimum needed to make a system publicly editable: the ability to undo something. One can't pick and choose edits; if someone does a massive edit but you don't like one small bit then Wiki history is useless. If an earlier version is interesting then it should be promoted to a full Wiki page, not hidden away in history. It might be useful to be able to take _snapshots_ of pages. One way to implement this would be to have the ability to _branch_ a page and to _lock_ a page. Branching should be a bit link hard links: you don't actually duplicate the history (to save space on the server), but if the original page (and its history) is deleted then the history simply becomes part of the branch's history. (There is still a significant difference between this and a full revision system: I'm not asking for merges. Once a branch has been made, it goes it's own way).
An example of where this might be useful is on the Frolicher space page. It's getting quite long and is in sections so I thought of dividing it so that each section is its own page (and the main page just includes the others). However, it would be nice if the sections could carry the history rather than the main page. So if I made each a branch and then deleted the parts not in the desired section, I'd have the history available.
3. Sorting out the mess that is already there. Yes, this will take a little time (and an administrative password), but it's not overly complicated. All one has to do is go through the redirects category, delete the pages, and add the required redirects to the target page. If there is content on those pages that should be saved, then the page shouldn't become a redirect, it should become a side-page of the target page (though maybe the original title should be a redirect to the target). Thus Toby's scheme - at least in essence - seems quite reasonable. Also, this doesn't need an administrative password to do _most_ of it: rename everything in the redirects category to something like 'Target Old Version N' then add the redirects. Any that can be safely deleted can then be marked as such and an administrator can later just delete them all with minimum hassle.

at the top of the page. So when we create a new page, we should think of the other possibilities (plurals, unicode) etc that we may want to use instead (I think that the proper name should still be drawn from the character set [A-Za-z-_ ]).

There seem to be a few issues remaining, though.

Information about the redirect. Surely we can have a section on the resulting page explaining why there is a redirect. After all, if I'm redirected from blithering idiot to Andrew Stacey then I'd like to have an explanation right there as to why I was redirected, I don't want to have to hunt around on other pages. This information can be squirrelled away at the bottom of the page, of course, so that it doesn't intrude on the main entry.

Existing pages that should be redirects. Firstly, there's no difficulty in moving the existing page out of the way of the redirect. Any relevant information can be copied to the new page. Of course, this loses history but why is this important? The history of a Wiki is extremely linear and should not be thought of as a full-blown revision system. What can be done with Wiki history is very limited. It is the bare minimum needed to make a system publicly editable: the ability to undo something. One can't pick and choose edits; if someone does a massive edit but you don't like one small bit then Wiki history is useless. If an earlier version is interesting then it should be promoted to a full Wiki page, not hidden away in history. It might be useful to be able to take snapshots of pages. One way to implement this would be to have the ability to branch a page and to lock a page. Branching should be a bit link hard links: you don't actually duplicate the history (to save space on the server), but if the original page (and its history) is deleted then the history simply becomes part of the branch's history. (There is still a significant difference between this and a full revision system: I'm not asking for merges. Once a branch has been made, it goes it's own way).

An example of where this might be useful is on the Frolicher space page. It's getting quite long and is in sections so I thought of dividing it so that each section is its own page (and the main page just includes the others). However, it would be nice if the sections could carry the history rather than the main page. So if I made each a branch and then deleted the parts not in the desired section, I'd have the history available.

Sorting out the mess that is already there. Yes, this will take a little time (and an administrative password), but it's not overly complicated. All one has to do is go through the redirects category, delete the pages, and add the required redirects to the target page. If there is content on those pages that should be saved, then the page shouldn't become a redirect, it should become a side-page of the target page (though maybe the original title should be a redirect to the target). Thus Toby's scheme - at least in essence - seems quite reasonable. Also, this doesn't need an administrative password to do most of it: rename everything in the redirects category to something like 'Target Old Version N' then add the redirects. Any that can be safely deleted can then be marked as such and an administrator can later just delete them all with minimum hassle.

Author: Mike ShulmanFormat: Markdown> I think that the proper name should still be drawn from the character set [A-Za-z-_ ]
I'm not completely convinced of that. It certainly does look nicer to have the page title display as ?-category rather than infinity-category. But maybe a better solution to that would be to allow a page to specify how to display its title. Say, a `[[!title $\infty$-category]]` command. That could even allow arbitrary itex, rather than just unicode characters.
> Surely we can have a section on the resulting page explaining why there is a redirect.
When I first read this I thought you were saying there should be an automatic "redirected from foo" notice somewhere on the page, like Mediawiki has. I would like that, and it could probably be implemented fairly easily with a URL argument like `&redirected=foo`.
But now upon rereading I think you are saying that we should _write_ on the text of the target page a section about the redirect? I think this depends on the redirect. Of course, we don't need to explain why `categories` is redirected to `category`! I think that many other redirects will also be fairly obvious and not require explanation, but certainly if there are any controversial ones we can have an explanation.
> Firstly, there's no difficulty in moving the existing page out of the way of the redirect. ... Of course, this loses history
_Moving_ the existing page doesn't lose history; _deleting_ it does.
> but why is this important? The history of a Wiki is extremely linear and should not be thought of as a full-blown revision system.
Well, just because the existing facility is fairly limited doesn't mean we should willfully throw away what it _does_ allow us to do. Given that it won't be too hard to move the existing `category:redirect` pages to `foo/history`, why not do that rather than deleting them (which would surely be just as much work)?
Branching would be an interesting feature, but it seems to me not worth the trouble of getting Jacques to implement. When you break Frolicher space into sub-pages, the history will still be _somewhere_, and that's what matters to me. (At first you seemed to be saying that keeping the history around at all doesn't matter... so why do you care about whether the history of Frolicher space is on the main page or the sub-pages?)

I think that the proper name should still be drawn from the character set [A-Za-z-_ ]

I'm not completely convinced of that. It certainly does look nicer to have the page title display as ?-category rather than infinity-category. But maybe a better solution to that would be to allow a page to specify how to display its title. Say, a !title $\infty$-category command. That could even allow arbitrary itex, rather than just unicode characters.

Surely we can have a section on the resulting page explaining why there is a redirect.

When I first read this I thought you were saying there should be an automatic "redirected from foo" notice somewhere on the page, like Mediawiki has. I would like that, and it could probably be implemented fairly easily with a URL argument like &redirected=foo.

But now upon rereading I think you are saying that we should write on the text of the target page a section about the redirect? I think this depends on the redirect. Of course, we don't need to explain why categories is redirected to category! I think that many other redirects will also be fairly obvious and not require explanation, but certainly if there are any controversial ones we can have an explanation.

Firstly, there's no difficulty in moving the existing page out of the way of the redirect. ... Of course, this loses history

Moving the existing page doesn't lose history; deleting it does.

but why is this important? The history of a Wiki is extremely linear and should not be thought of as a full-blown revision system.

Well, just because the existing facility is fairly limited doesn't mean we should willfully throw away what it does allow us to do. Given that it won't be too hard to move the existing category:redirect pages to foo/history, why not do that rather than deleting them (which would surely be just as much work)?

Branching would be an interesting feature, but it seems to me not worth the trouble of getting Jacques to implement. When you break Frolicher space into sub-pages, the history will still be somewhere, and that's what matters to me. (At first you seemed to be saying that keeping the history around at all doesn't matter... so why do you care about whether the history of Frolicher space is on the main page or the sub-pages?)

Author: EricFormat: TextI think you are over estimating the coding required to eliminate trouble redirects.
By placing the priority on the existing page rather than the redirect, the trade off between usability for the user and simplicity for the programmer is unjustifiably skewed toward that of the programmer. In every case I have ever wanted to create a redirect, I would not be able to with the way things are now. You would force the contributor to have the perfect foresight to know every possible redirect beforehand. If there is a clash in pages and a consolidation is warranted (which has happened many times already... not just by me), then our only choice currently is to involve an administrator.
An initial thought on managing trouble redirects...
Only allow [[!redirects foo]] if [[foo]] contains no content other than "category: redirect".
Pseudo code:
-------------------
function [tf] = checkredirect(foo)
clean = checkcontent(foo);
if clean
tf = true; % Allow redirect
else
tf = false; % foo is not clean. Do not allow redirect and show error message. Author must clean foo before redirecting.
end
---------------
This would place the responsibility on the author inserting the redirect to make sure that the originating page itself is clean, i.e. contains no content, including redirects.
For example, if you write [[widget]] and I write [[wadget]] including a [[!redirects! widget]], we can simply not allow the redirect if [[widget]] contains content other than "category: redirect". The author including the redirect (in this case "I") could be made responsible for consolidating content prior to redirecting. In this way, the original page still exists and its history remains accessible (if desired) by temporarily removing the redirect from [[wadget]]. Most importantly, the whole process can be undone by users via rollbacks without the need to involve administrators.
That is another problem with the current implementation. You cannot undo a redirect, as far as I can tell, once it is created. The first test case I tried with the new redirect was to create a page [[nitwits]], add content and then "Rename" it to [[nitwit]]. From that point, if anyone clicked a link to [[nitwits]], it was redirected to [[nitwit]] as desired. BUT, [[nitwits]] became forever unavailable to anyone. There is no way to undo the redirect. Toby created a second [[nitwits]], which I suppose completely overwrote my original [[nitwits]] and broke the redirect in the process.
In most practical cases, the need for a redirect will arise because someone creates a page and THEN thinks, "Oh wait, this should be a redirect." They have no options with the current implementation and need to request an administrator to delete the page they just created in order to add the redirect. Not to mention the large number of existing redirects:
http://ncatlab.org/nlab/list/redirect
We would need an administrator to "fix", i.e. delete, all of these unless we change the priority.
I am thinking from a user's perspective. The redirect, as is, would be fairly useless in practice due to lack of perfect foresight on the part of the contributor. If a new contributor unwisely places an ill-conceived redirect, the simple content check above would stop them. It would also eliminate nested redirects and loops.

I think you are over estimating the coding required to eliminate trouble redirects.

By placing the priority on the existing page rather than the redirect, the trade off between usability for the user and simplicity for the programmer is unjustifiably skewed toward that of the programmer. In every case I have ever wanted to create a redirect, I would not be able to with the way things are now. You would force the contributor to have the perfect foresight to know every possible redirect beforehand. If there is a clash in pages and a consolidation is warranted (which has happened many times already... not just by me), then our only choice currently is to involve an administrator.

An initial thought on managing trouble redirects...

Only allow !redirects foo if foo contains no content other than "category: redirect".

Pseudo code:-------------------function [tf] = checkredirect(foo)

clean = checkcontent(foo);

if clean

tf = true; % Allow redirect

else

tf = false; % foo is not clean. Do not allow redirect and show error message. Author must clean foo before redirecting.

end---------------

This would place the responsibility on the author inserting the redirect to make sure that the originating page itself is clean, i.e. contains no content, including redirects.

For example, if you write widget and I write wadget including a !redirects! widget, we can simply not allow the redirect if widget contains content other than "category: redirect". The author including the redirect (in this case "I") could be made responsible for consolidating content prior to redirecting. In this way, the original page still exists and its history remains accessible (if desired) by temporarily removing the redirect from wadget. Most importantly, the whole process can be undone by users via rollbacks without the need to involve administrators.

That is another problem with the current implementation. You cannot undo a redirect, as far as I can tell, once it is created. The first test case I tried with the new redirect was to create a page nitwits, add content and then "Rename" it to nitwit. From that point, if anyone clicked a link to nitwits, it was redirected to nitwit as desired. BUT, nitwits became forever unavailable to anyone. There is no way to undo the redirect. Toby created a second nitwits, which I suppose completely overwrote my original nitwits and broke the redirect in the process.

In most practical cases, the need for a redirect will arise because someone creates a page and THEN thinks, "Oh wait, this should be a redirect." They have no options with the current implementation and need to request an administrator to delete the page they just created in order to add the redirect. Not to mention the large number of existing redirects:

http://ncatlab.org/nlab/list/redirect

We would need an administrator to "fix", i.e. delete, all of these unless we change the priority.

I am thinking from a user's perspective. The redirect, as is, would be fairly useless in practice due to lack of perfect foresight on the part of the contributor. If a new contributor unwisely places an ill-conceived redirect, the simple content check above would stop them. It would also eliminate nested redirects and loops.

Author: Mike ShulmanFormat: MarkdownThe way to undo a redirect "nitwits" -> "nitwit" is to edit the page "nitwit" and remove the line `[[!redirects nitwits]]`.
> In most practical cases, the need for a redirect will arise because someone creates a page and THEN thinks, "Oh wait, this should be a redirect."
I disagree. Many of the current redirects are because someone created a page with the wrong name; now we can _rename_ pages so that this will not cause problems. Others are indeed because of unintentional duplication, but I think much of this can be avoided with preemptive redirecting. Most times, the other possible names of a concept are known to the person creating a page.
> They have no options with the current implementation and need to request an administrator to delete the page they just created in order to add the redirect.
Their option without an administrator is to _rename_ the page they created and then add the redirect. They could rename it to `page/delete` and maybe also add `category:delete`. If we want, every so often an administrator could go through and delete such pages. Actually, renaming rather than deleting pages is arguably more in the wiki style. If you make a mistake editing a page, you have to edit it again, and a record will be kept of your mistake.
However, I kind of like the idea of allowing redirects to take priority only over "empty" pages. I need to think about it a bit more though.

The way to undo a redirect "nitwits" -> "nitwit" is to edit the page "nitwit" and remove the line !redirects nitwits.

In most practical cases, the need for a redirect will arise because someone creates a page and THEN thinks, "Oh wait, this should be a redirect."

I disagree. Many of the current redirects are because someone created a page with the wrong name; now we can rename pages so that this will not cause problems. Others are indeed because of unintentional duplication, but I think much of this can be avoided with preemptive redirecting. Most times, the other possible names of a concept are known to the person creating a page.

They have no options with the current implementation and need to request an administrator to delete the page they just created in order to add the redirect.

Their option without an administrator is to rename the page they created and then add the redirect. They could rename it to page/delete and maybe also add category:delete. If we want, every so often an administrator could go through and delete such pages. Actually, renaming rather than deleting pages is arguably more in the wiki style. If you make a mistake editing a page, you have to edit it again, and a record will be kept of your mistake.

However, I kind of like the idea of allowing redirects to take priority only over "empty" pages. I need to think about it a bit more though.

Author: EricFormat: Text> Their option without an administrator is to rename the page they created and then add the redirect.
Nice. With your last comment, I think you managed to convince me that I can accomplish anything I wanted to do with the current implementation. That is very helpful. Thanks!

> Their option without an administrator is to rename the page they created and then add the redirect.

Nice. With your last comment, I think you managed to convince me that I can accomplish anything I wanted to do with the current implementation. That is very helpful. Thanks!

Author: TobyBartelsFormat: Html<blockquote>(Those with no history to speak of should just be deleted.)</blockquote>Those with no history to speak of should be at category: delete instead of at category: redirect; that's the difference between those. (Personally I would not delete even things in category: delete; it's very unlikely that we'll want it, but there is no need to do it, so I just would not open that box. But since some people want to delete some things, I have kept the safe ones segregated.)

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
<blockquote>(Those with no history to speak of should just be deleted.)</blockquote>Those with no history to speak of should be at category: delete instead of at category: redirect; that's the difference between those. (Personally I would not delete even things in category: delete; it's very unlikely that we'll want it, but there is no need to do it, so I just would not open that box. But since some people want to delete some things, I have kept the safe ones segregated.)
</div>

Author: TobyBartelsFormat: Html<blockquote>Of course, this loses history but <em>why is this important?</em> The history of a Wiki is extremely linear and should not be thought of as a full-blown revision system. What can be done with Wiki history is very limited. It is the bare minimum needed to make a system publicly editable: the ability to undo something. One can't pick and choose edits; if someone does a massive edit but you don't like one small bit then Wiki history is useless. If an earlier version is interesting then it should be promoted to a full Wiki page, not hidden away in history.</blockquote><p>It's potentially important because it is information. Yes, wiki history is a bare minimum, but it suffices; deleting pages take us below that minimum and does not suffice. If someone does a massive edit but I don't like one small bit, then wiki history is <em>useful</em>; it tells me what there before, and I can pick and choose (using my human judgement, rather than any algorithmic method, to select text for copying and pasting) what to take from the old version and what to keep from the new version. And while nothing will automatically tell me who wrote what when, I can figure it out if I care that much.<p>If old redirect pages took up a significant amount of space in the database, then that would be another matter. But of course, they don't. We will also have to revisit the issue when we attract spam. (My preference: blank the page and tell the wiki software to treat blank pages as nonexistent ones except for looking at the history; if that is put sufficiently deep into the code, then it will also fulfil Eric's desire for redirects to take priority over extant blank pages. But that may not fit well into Instiki's code.)

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
<blockquote>Of course, this loses history but <em>why is this important?</em> The history of a Wiki is extremely linear and should not be thought of as a full-blown revision system. What can be done with Wiki history is very limited. It is the bare minimum needed to make a system publicly editable: the ability to undo something. One can't pick and choose edits; if someone does a massive edit but you don't like one small bit then Wiki history is useless. If an earlier version is interesting then it should be promoted to a full Wiki page, not hidden away in history.</blockquote><p>It's potentially important because it is information. Yes, wiki history is a bare minimum, but it suffices; deleting pages take us below that minimum and does not suffice. If someone does a massive edit but I don't like one small bit, then wiki history is <em>useful</em>; it tells me what there before, and I can pick and choose (using my human judgement, rather than any algorithmic method, to select text for copying and pasting) what to take from the old version and what to keep from the new version. And while nothing will automatically tell me who wrote what when, I can figure it out if I care that much.<p>If old redirect pages took up a significant amount of space in the database, then that would be another matter. But of course, they don't. We will also have to revisit the issue when we attract spam. (My preference: blank the page and tell the wiki software to treat blank pages as nonexistent ones except for looking at the history; if that is put sufficiently deep into the code, then it will also fulfil Eric's desire for redirects to take priority over extant blank pages. But that may not fit well into Instiki's code.)</p></p>
</div>

Author: TobyBartelsFormat: HtmlInstructions to move [[A]] to [[B]] when [[B]] does not exist:<ul><li>Open [[A]] for editing.</li><li>Click the checkbox.</li><li>Type in the new name ‘B’.</li><li>Submit.</li></ul>I know that everyone here know this; I'm just putting it in for completeness. (I'm also assuming that you don't turn off Javascript in the middle to prevent ‘[[!redirects A]]’ from appearing automatically.) In the following, this will be called ‘the usual way’.<p>Instructions to move/merge [[A]] (in)to [[B]] when [[A]] has most of the content/history:<ol><li>Move [[B]] to [[B/history]] in the usual way. (The slash in the title doesn't cause any problems here, although technically it will be ‘%2F’ in the URI.)</li><li>Move [[A]] to [[B]] in the usual way.</li><li>Edit [[B]] to include any useful content from [[B/history]].</li><li>Edit [[B/history]] to consist of ‘See [[B]].’ and maybe also ‘category: redirect’ or something.</li></ol>If you're clever, then you can do step 4 in the middle of step 1, but I won't make these instructions any more complicated than necessary.<p>Instructions to move/merge [[A]] (in)to [[B]] when [[B]] has most of the content/history:<ol><li>Move [[A]] to [[A/history]] in the usual way.</li><li>Add ‘[[!redirects A]]’ to the top of [[B]].</li><li>Edit [[B]] again to include any useful content from [[A/history]].</li><li>Edit [[A/history]] to consist of ‘See [[B]].’ and maybe also ‘category: redirect’ or something.</li></ol>Obviously, you can combine steps 2 and 3 here, but they serve different purposes.<p>Of course, we need human judgement to distinguish these last two sets of instructions; the good thing is that it doesn't make much difference in the end. Also I'm assuming a naming convention involving ‘/history’; we could use another convention, of course, but the main point is that we can pick these page titles out of the back links at the bottom of [[B]]. Note that these should appear in the back links (which is what step 4 ensures) if we want to know about them; we probably don't need any category for these anymore, since their titles will identify them.

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
Instructions to move <a href="http://ncatlab.org/nlab/show/A">A</a> to <a href="http://ncatlab.org/nlab/show/B">B</a> when <a href="http://ncatlab.org/nlab/show/B">B</a> does not exist:<ul><li>Open <a href="http://ncatlab.org/nlab/show/A">A</a> for editing.</li><li>Click the checkbox.</li><li>Type in the new name ‘B’.</li><li>Submit.</li></ul>I know that everyone here know this; I'm just putting it in for completeness. (I'm also assuming that you don't turn off Javascript in the middle to prevent ‘<a href="http://ncatlab.org/nlab/show/%21redirects+A">!redirects A</a>’ from appearing automatically.) In the following, this will be called ‘the usual way’.<p>Instructions to move/merge <a href="http://ncatlab.org/nlab/show/A">A</a> (in)to <a href="http://ncatlab.org/nlab/show/B">B</a> when <a href="http://ncatlab.org/nlab/show/A">A</a> has most of the content/history:<ol><li>Move <a href="http://ncatlab.org/nlab/show/B">B</a> to <a href="http://ncatlab.org/nlab/show/B%2Fhistory">B/history</a> in the usual way. (The slash in the title doesn't cause any problems here, although technically it will be ‘%2F’ in the URI.)</li><li>Move <a href="http://ncatlab.org/nlab/show/A">A</a> to <a href="http://ncatlab.org/nlab/show/B">B</a> in the usual way.</li><li>Edit <a href="http://ncatlab.org/nlab/show/B">B</a> to include any useful content from <a href="http://ncatlab.org/nlab/show/B%2Fhistory">B/history</a>.</li><li>Edit <a href="http://ncatlab.org/nlab/show/B%2Fhistory">B/history</a> to consist of ‘See <a href="http://ncatlab.org/nlab/show/B">B</a>.’ and maybe also ‘category: redirect’ or something.</li></ol>If you're clever, then you can do step 4 in the middle of step 1, but I won't make these instructions any more complicated than necessary.<p>Instructions to move/merge <a href="http://ncatlab.org/nlab/show/A">A</a> (in)to <a href="http://ncatlab.org/nlab/show/B">B</a> when <a href="http://ncatlab.org/nlab/show/B">B</a> has most of the content/history:<ol><li>Move <a href="http://ncatlab.org/nlab/show/A">A</a> to <a href="http://ncatlab.org/nlab/show/A%2Fhistory">A/history</a> in the usual way.</li><li>Add ‘<a href="http://ncatlab.org/nlab/show/%21redirects+A">!redirects A</a>’ to the top of <a href="http://ncatlab.org/nlab/show/B">B</a>.</li><li>Edit <a href="http://ncatlab.org/nlab/show/B">B</a> again to include any useful content from <a href="http://ncatlab.org/nlab/show/A%2Fhistory">A/history</a>.</li><li>Edit <a href="http://ncatlab.org/nlab/show/A%2Fhistory">A/history</a> to consist of ‘See <a href="http://ncatlab.org/nlab/show/B">B</a>.’ and maybe also ‘category: redirect’ or something.</li></ol>Obviously, you can combine steps 2 and 3 here, but they serve different purposes.<p>Of course, we need human judgement to distinguish these last two sets of instructions; the good thing is that it doesn't make much difference in the end. Also I'm assuming a naming convention involving ‘/history’; we could use another convention, of course, but the main point is that we can pick these page titles out of the back links at the bottom of <a href="http://ncatlab.org/nlab/show/B">B</a>. Note that these should appear in the back links (which is what step 4 ensures) if we want to know about them; we probably don't need any category for these anymore, since their titles will identify them.</p></p></p>
</div>

Author: TobyBartelsFormat: HtmlAlso: Instructions to unmerge [[B]] and make [[A]] a separate page once more, when [[A/history]] exists:<ul><li>Move [[A/history]] to [[A]].</li><li>Edit [[A]] and [[B]] as appropriate, including links to one another but no redirection commands between them.</li></ul><p>If you mess up and forget to do this, then we have an extra page; ah well, edit [[A/history]] to say ‘See [[A]].’ instead of ‘See [[B]].’ and resolve to do better next time. (Of course, no special instructions are needed to make [[A]] into a separate page when [[A/history]] does <em>not</em> exist.)

Also: Instructions to unmerge B and make A a separate page once more, when A/history exists:

Edit A and B as appropriate, including links to one another but no redirection commands between them.

If you mess up and forget to do this, then we have an extra page; ah well, edit A/history to say ‘See A.’ instead of ‘See B.’ and resolve to do better next time. (Of course, no special instructions are needed to make A into a separate page when A/history does not exist.)

Author: TobyBartelsFormat: HtmlSo anyway … are we happy with the new system except for incoming links? While I have some other minor quibbles, I would be happy to go ahead with this as long as that bit is solved.

So anyway … are we happy with the new system except for incoming links? While I have some other minor quibbles, I would be happy to go ahead with this as long as that bit is solved.

Author: Andrew StaceyFormat: Markdown>> I think that the proper name should still be drawn from the character set [A-Za-z-_ ]
> I'm not completely convinced of that. It certainly does look nicer to have the page title display as ?-category rather than infinity-category. But maybe a better solution to that would be to allow a page to specify how to display its title.
I'd prefer this solution to that of allowing junk in the page name. The problem stems from one thing trying to fulfil two roles: the page _title_ and its _link_. Links should be kept simple (we discussed this a little on the [forward slashes in names](http://www.math.ntnu.no/~stacey/Vanilla/nForum/comments.php?DiscussionID=25) thread) since once stuff goes off-site we lose all control over it and so should anticipate the Corollary of Murphey's Law: To err is human, to really make a mess of things requires a computer. Since computers are already involved, minimising their ability to mangle things like links can only be a good thing.
But it would be nice to have nice titles, so specifying the title separately might be a nice feature to have.
This feeds into Toby's suggestions. He seems to have forgotten that he agreed _not_ to put forward slashes in names! A dash or underscore would serve as well. After all, all those Windows users out there won't understand what the forward slash is doing anyway, and anyone from the Unix world will see that it's not a forward slash but a %2f and wonder what the point is. Apart from this minor quibble, I see nothing wrong with Toby's proceedures.
> When I first read this I thought you were saying there should be an automatic "redirected from foo" notice somewhere on the page, like Mediawiki has.
I'm thinking of installing a new filter that removes the word "Mediawiki" from all posts!
Seriously, as Mike continues, some redirects don't need explanation ('categories' -> 'category'). But others do ('distributor' -> 'profunctor' for example). But if one thinks that it is important enough to ensure that the reader knows that they've been redirected, then it's probably important enough to have a comment explaining why the redirection happened. In fact, one could easily have a list of "pages redirected to this one" on the page with (if desired) a short explanation of why they are redirected there. Then even if I went straight to the main page, I'd see which other pages redirected there and that could contain significant information. For example, 'biunivocal' redirects to 'injective' but if I don't know that, I might think that they are completely different concepts. If I never look up 'biunivocal' then I may never know that it's the same thing as 'injective' (after all, I can't look up _every_ word I don't know). But if there's a comment on 'injective' that 'biunivocal' redirects there then I learn something useful (which would have saved a fair bit of time when doing my PhD!).
Mike, you're right about just needing the history preserved _somewhere_, though without a branching system one ought to have a manual system to provide a trace. That is, if I copy a vast swathe of material from one page to another then on the _first_ commit I ought to record that this information originally came from the source page. Then later (after that commit has "taken"), that can be removed. This seems better than branching, you're right. Branching's a daft idea (and I'm glad I didn't suggest it first to Jacques).
I'm still not convinced on the value of keeping _all_ history. Keeping _recent_ history (say, last 10 edits) and _important_ history (say, any change of over 10% of the page) but why all? "Just because we can" and "we may want it _some day_" are not good arguments. Too much information becomes useless information because it's impossible to go through it.
However, given that I'm in a minority here then I'm happy to go with the "keep it all" philosophy. After all, it can always be deleted later.

I think that the proper name should still be drawn from the character set [A-Za-z-_ ]

I'm not completely convinced of that. It certainly does look nicer to have the page title display as ?-category rather than infinity-category. But maybe a better solution to that would be to allow a page to specify how to display its title.

I'd prefer this solution to that of allowing junk in the page name. The problem stems from one thing trying to fulfil two roles: the page title and its link. Links should be kept simple (we discussed this a little on the forward slashes in names thread) since once stuff goes off-site we lose all control over it and so should anticipate the Corollary of Murphey's Law: To err is human, to really make a mess of things requires a computer. Since computers are already involved, minimising their ability to mangle things like links can only be a good thing.

But it would be nice to have nice titles, so specifying the title separately might be a nice feature to have.

This feeds into Toby's suggestions. He seems to have forgotten that he agreed not to put forward slashes in names! A dash or underscore would serve as well. After all, all those Windows users out there won't understand what the forward slash is doing anyway, and anyone from the Unix world will see that it's not a forward slash but a %2f and wonder what the point is. Apart from this minor quibble, I see nothing wrong with Toby's proceedures.

When I first read this I thought you were saying there should be an automatic "redirected from foo" notice somewhere on the page, like Mediawiki has.

I'm thinking of installing a new filter that removes the word "Mediawiki" from all posts!

Seriously, as Mike continues, some redirects don't need explanation ('categories' -> 'category'). But others do ('distributor' -> 'profunctor' for example). But if one thinks that it is important enough to ensure that the reader knows that they've been redirected, then it's probably important enough to have a comment explaining why the redirection happened. In fact, one could easily have a list of "pages redirected to this one" on the page with (if desired) a short explanation of why they are redirected there. Then even if I went straight to the main page, I'd see which other pages redirected there and that could contain significant information. For example, 'biunivocal' redirects to 'injective' but if I don't know that, I might think that they are completely different concepts. If I never look up 'biunivocal' then I may never know that it's the same thing as 'injective' (after all, I can't look up every word I don't know). But if there's a comment on 'injective' that 'biunivocal' redirects there then I learn something useful (which would have saved a fair bit of time when doing my PhD!).

Mike, you're right about just needing the history preserved somewhere, though without a branching system one ought to have a manual system to provide a trace. That is, if I copy a vast swathe of material from one page to another then on the first commit I ought to record that this information originally came from the source page. Then later (after that commit has "taken"), that can be removed. This seems better than branching, you're right. Branching's a daft idea (and I'm glad I didn't suggest it first to Jacques).

I'm still not convinced on the value of keeping all history. Keeping recent history (say, last 10 edits) and important history (say, any change of over 10% of the page) but why all? "Just because we can" and "we may want it some day" are not good arguments. Too much information becomes useless information because it's impossible to go through it.

However, given that I'm in a minority here then I'm happy to go with the "keep it all" philosophy. After all, it can always be deleted later.

Author: EricFormat: TextI think that we all understand the current set up. Before we decide/vote/whatever on which way to actually go, it may be worthwhile to walk through the same steps Toby did for the alternative with redirects taking precedence. Maybe even asking Jacques to temporarily make the switch so we can try it out and see the pros and cons in action before deciding once and for all. I could change my mind, but I still think having redirects take precedence would be cleaner from the user/administrator perspective.
I'm mostly out of commission until next week though. If no one volunteers, I'll try to outline the steps myself next week.

I think that we all understand the current set up. Before we decide/vote/whatever on which way to actually go, it may be worthwhile to walk through the same steps Toby did for the alternative with redirects taking precedence. Maybe even asking Jacques to temporarily make the switch so we can try it out and see the pros and cons in action before deciding once and for all. I could change my mind, but I still think having redirects take precedence would be cleaner from the user/administrator perspective.

I'm mostly out of commission until next week though. If no one volunteers, I'll try to outline the steps myself next week.

Author: Mike ShulmanFormat: MarkdownAndrew, I agree it would be nice to specify "all this material came from page X" in an edit. Ideally, though, it seems like that information would go in a "comment" about the edit, rather than on the page itself, like in **DELETED BY CENSOR**.
I also agree that a list of "pages that redirect to this one" with comments would sometimes be useful; people should be encouraged to make such lists when they add non-obvious redirects.
I continue to like the idea of a `[[!title ]]` command that specifies how the title of a page is to be displayed, together with a convention that actual page names be in ascii. (More than [-A-Za-z ] should be allowed, like digits and parentheses in particular.)
And, dude, check it out, while we've been sitting here jawing, Jacques has implemented HTTP redirects!

Andrew, I agree it would be nice to specify "all this material came from page X" in an edit. Ideally, though, it seems like that information would go in a "comment" about the edit, rather than on the page itself, like in DELETED BY CENSOR.

I also agree that a list of "pages that redirect to this one" with comments would sometimes be useful; people should be encouraged to make such lists when they add non-obvious redirects.

I continue to like the idea of a !title command that specifies how the title of a page is to be displayed, together with a convention that actual page names be in ascii. (More than [-A-Za-z ] should be allowed, like digits and parentheses in particular.)

Author: EricFormat: MarkdownI like the [[!title ]] idea. That would also help with capitalization. [[category of sets]] has [[!title Category of Sets]], etc.
In my favorite example, we'd have [[<latex>\infty</latex>-category]] redirect to [[infinity-category]] which contains a [[!title <latex>\infty</latex>-category]] :)
PS: Jacques rulez :)

Author: Andrew StaceyFormat: MarkdownMike, I agree that the meta-information would be more suited in a page about the page, but I'm not sure that this is enough to go down the route of having pages about pages. Sounds a bit too MediaWiki-ish to me! My reason for having it on the first import and then deleted was that if someone is stepping back through the revisions then they'll hit that first revision with the imported material and then see directly where it came from and so know where to go to follow the history further back. That seems to provide all the functionality that would be needed for tracing the history with no additional programming and hardly any additional work for authors. As the extra information would only be visible for a short time, it also wouldn't be too intrusive.
Okay, so more than [-A-Za-z ] is, of course, fine. My point was to avoid already overloaded symbols (like slashes). We can argue the finer points if you like! I would allow digits, of course, but wouldn't allow parentheses. My rule of thumb would be that if my shell expanded it to something else, I wouldn't allow it.
As for Jacques implementing HTTP redirects, may I be a bit cheeky and say that perhaps since we've left him alone for 24hours then he's actually had the time to do something practical rather than answering all those comments on his blog!
Eric, Yay! Someone's used the maths on this forum! And I completely agree with your last sentence.

Mike, I agree that the meta-information would be more suited in a page about the page, but I'm not sure that this is enough to go down the route of having pages about pages. Sounds a bit too MediaWiki-ish to me! My reason for having it on the first import and then deleted was that if someone is stepping back through the revisions then they'll hit that first revision with the imported material and then see directly where it came from and so know where to go to follow the history further back. That seems to provide all the functionality that would be needed for tracing the history with no additional programming and hardly any additional work for authors. As the extra information would only be visible for a short time, it also wouldn't be too intrusive.

Okay, so more than [-A-Za-z ] is, of course, fine. My point was to avoid already overloaded symbols (like slashes). We can argue the finer points if you like! I would allow digits, of course, but wouldn't allow parentheses. My rule of thumb would be that if my shell expanded it to something else, I wouldn't allow it.

As for Jacques implementing HTTP redirects, may I be a bit cheeky and say that perhaps since we've left him alone for 24hours then he's actually had the time to do something practical rather than answering all those comments on his blog!

Eric, Yay! Someone's used the maths on this forum! And I completely agree with your last sentence.

Author: Mike ShulmanFormat: MarkdownYeah, I agree that having comments about submits is too complicated and not useful enough to be worthwhile.
I think we should allow parentheses, however, partly because there are already oodles of pages that have parentheses in their names that I wouldn't know how else to rename. What would you like to call (n,r)-category? Or (infinity,1)-category? Parentheses don't have the same problem that slashes do (do they?) because they aren't used as a path separator by anyone.

Yeah, I agree that having comments about submits is too complicated and not useful enough to be worthwhile.

I think we should allow parentheses, however, partly because there are already oodles of pages that have parentheses in their names that I wouldn't know how else to rename. What would you like to call (n,r)-category? Or (infinity,1)-category? Parentheses don't have the same problem that slashes do (do they?) because they aren't used as a path separator by anyone.

Author: Andrew StaceyFormat: MarkdownPart of the point of separating titles and urls is so that it's not overly important what the url is. Of course, we want it to be an approximation of the title, but (n,r)-category could easily have the url _n_r_category without causing any excessive confusion.
Theoretically, any character set is acceptable because any well-written script can cope with any sort of input. However, in practice there aren't that many well-written scripts! My underlying reason behind my choice of charset was "something that almost no script will misinterpret". I may well have not translated this correctly to a specific charset, though. Thus a badly written script that fails to escape a url coming from the n-lab should still process it correctly. Thus parentheses are out because they denote grouping.
Of course, it's part of the question of "how far should we go to be nice to everyone else?". Whilst I'd like us to be on friendly terms with anyone else, I also don't want it to be a major hassle. If something like the 'title' command were implemented then it would be easy to have urls that were extremely clean. But without a 'title' command then it's a balance: certain characters should definitely be avoided, but the class of 'acceptable' characters becomes wider.
Nonetheless, this isn't a major issue either way.

Part of the point of separating titles and urls is so that it's not overly important what the url is. Of course, we want it to be an approximation of the title, but (n,r)-category could easily have the url _n_r_category without causing any excessive confusion.

Theoretically, any character set is acceptable because any well-written script can cope with any sort of input. However, in practice there aren't that many well-written scripts! My underlying reason behind my choice of charset was "something that almost no script will misinterpret". I may well have not translated this correctly to a specific charset, though. Thus a badly written script that fails to escape a url coming from the n-lab should still process it correctly. Thus parentheses are out because they denote grouping.

Of course, it's part of the question of "how far should we go to be nice to everyone else?". Whilst I'd like us to be on friendly terms with anyone else, I also don't want it to be a major hassle. If something like the 'title' command were implemented then it would be easy to have urls that were extremely clean. But without a 'title' command then it's a balance: certain characters should definitely be avoided, but the class of 'acceptable' characters becomes wider.

Author: Mike ShulmanFormat: MarkdownI think that any script that can't cope with parentheses in a _string_ it is processing probably has more serious problems than breaking our URLs -- like, security holes. I can more easily imagine a script that isn't too bad otherwise, but fails to make the distinction between / and %2F correctly; that's a more subtle issue.
And I don't want to be forced to type [[_n_r_category|(n,r)-category]].

I think that any script that can't cope with parentheses in a string it is processing probably has more serious problems than breaking our URLs -- like, security holes. I can more easily imagine a script that isn't too bad otherwise, but fails to make the distinction between / and %2F correctly; that's a more subtle issue.

Author: Andrew StaceyFormat: MarkdownAh, but with the magic of redirects you wouldn't have to type that! The point would be that the _canonical_ name is "clean" but you can have as many redirects with weird and wonderful names as you like.

Ah, but with the magic of redirects you wouldn't have to type that! The point would be that the canonical name is "clean" but you can have as many redirects with weird and wonderful names as you like.

Author: Mike ShulmanFormat: MarkdownI think that the actual name of a page should be what it is actually called, not some mangling of it to avoid characters that are unproblematic for non-brain-dead scripts.
Have you actually seen scripts that would not correctly process a URL containing parentheses? I'm really having trouble imagining what such a script would be doing with its URLs.

I think that the actual name of a page should be what it is actually called, not some mangling of it to avoid characters that are unproblematic for non-brain-dead scripts.

Have you actually seen scripts that would not correctly process a URL containing parentheses? I'm really having trouble imagining what such a script would be doing with its URLs.

Author: TobyBartelsFormat: HtmlBut what if somebody is creating the page? Then either they still have to type ‘[[_n_r_-category|(n,r)-category]]’ once or somebody has to move [[(n,r)-category]] to [[_n_r_-category]] after they ignore the naming conventions. In principle, that's true of [[infinity-category|?-category]] too, but at least there I think that it's more natural to understand the naming convention and follow it right away.<p>Another possibility —but this involves Jacques— is to allow a web to specify a whitelist (or blacklist) of (un)acceptable characters in page titles, along with the character to use (in this case, an underscore) when a forbidden character is entered. Then typing ‘[[(n,r)-category]]’ will create a link to [[_n_r_-category]] automatically. (This would not help much with [[?-category]]; there we would have to rely on the naturalness of the ASCII-only conventions.) Even in this case, there ought to be some way to override this restriction, if only to link to legacy pages from discussion.<p>All in all, I'm with Mike on parentheses; any script that breaks there has bigger problems. (This also applies to apostrophes, as well as some other characters that we're less likely to want.) But I'm otherwise sympathetic to Andrew's position that we forbid characters likely to break scripts.<p>In particular:<blockquote>[Toby] seems to have forgotten […] <em>not</em> to put forward slashes in names!</blockquote>You're right, sorry! In that case, my sense of æsthetics leans towards [[A - history]] (with an ASCII hyphen-minus with a space on each side).

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
But what if somebody is creating the page? Then either they still have to type ‘<a href="http://ncatlab.org/nlab/show/_n_r_-category">(n,r)-category</a>’ once or somebody has to move <a href="http://ncatlab.org/nlab/show/%28n%2Cr%29-category">(n,r)-category</a> to <a href="http://ncatlab.org/nlab/show/_n_r_-category">_n_r_-category</a> after they ignore the naming conventions. In principle, that's true of <a href="http://ncatlab.org/nlab/show/infinity-category">?-category</a> too, but at least there I think that it's more natural to understand the naming convention and follow it right away.<p>Another possibility —but this involves Jacques— is to allow a web to specify a whitelist (or blacklist) of (un)acceptable characters in page titles, along with the character to use (in this case, an underscore) when a forbidden character is entered. Then typing ‘<a href="http://ncatlab.org/nlab/show/%28n%2Cr%29-category">(n,r)-category</a>’ will create a link to <a href="http://ncatlab.org/nlab/show/_n_r_-category">_n_r_-category</a> automatically. (This would not help much with <a href="http://ncatlab.org/nlab/show/%3F-category">?-category</a>; there we would have to rely on the naturalness of the ASCII-only conventions.) Even in this case, there ought to be some way to override this restriction, if only to link to legacy pages from discussion.<p>All in all, I'm with Mike on parentheses; any script that breaks there has bigger problems. (This also applies to apostrophes, as well as some other characters that we're less likely to want.) But I'm otherwise sympathetic to Andrew's position that we forbid characters likely to break scripts.<p>In particular:<blockquote>[Toby] seems to have forgotten […] <em>not</em> to put forward slashes in names!</blockquote>You're right, sorry! In that case, my sense of æsthetics leans towards <a href="http://ncatlab.org/nlab/show/A+-+history">A - history</a> (with an ASCII hyphen-minus with a space on each side).</p></p></p>
</div>

Author: TobyBartelsFormat: Html<blockqoute>In fact, one could easily have a list of "pages redirected to this one" on the page with (if desired) a short explanation of why they are redirected there.</blockquote>I think that this information ought to be available, but I would put it in the main text without bringing in the mechanics of the redirection system.<p>So when you redirect [[biunivocal relation]] to [[injection]], be sure to add a note to the page itself stating that (along with ‘one-to-one’ and ‘monomorphism’) this term is also used. (In extreme cases, one can and probably should have a brief section on the page discussing all of the terminology that's been invented over the years for the same concept.)<p>On Wikipedia (but not so much on the Lab) people also sometimes create a page [[A]] that discusses the related topic [[B]] and then redirect [[B]] to [[A]] (sometimes temporarily, also sometimes permanently if the topic of B is tagged with the oxymoron ‘unencyclopedic’). Here we tend to create [[B]] rather than redirect it, but if we ever do otherwise, then we just have to make sure that people can actually <em>find</em> the text ‘B’ on the page! (Sometimes they forget that at Wikipedia ….)

This comment is invalid XML; displaying source.<blockquote><blockqoute >In fact, one could easily have a list of "pages redirected to this one" on the page with (if desired) a short explanation of why they are redirected there.</blockquote>I think that this information ought to be available, but I would put it in the main text without bringing in the mechanics of the redirection system.<p >So when you redirect <a href="http://ncatlab.org/nlab/show/biunivocal+relation">biunivocal relation</a> to <a href="http://ncatlab.org/nlab/show/injection">injection</a>, be sure to add a note to the page itself stating that (along with ‘one-to-one’ and ‘monomorphism’) this term is also used. (In extreme cases, one can and probably should have a brief section on the page discussing all of the terminology that's been invented over the years for the same concept.)<p >On Wikipedia (but not so much on the Lab) people also sometimes create a page <a href="http://ncatlab.org/nlab/show/A">A</a> that discusses the related topic <a href="http://ncatlab.org/nlab/show/B">B</a> and then redirect <a href="http://ncatlab.org/nlab/show/B">B</a> to <a href="http://ncatlab.org/nlab/show/A">A</a> (sometimes temporarily, also sometimes permanently if the topic of B is tagged with the oxymoron ‘unencyclopedic’). Here we tend to create <a href="http://ncatlab.org/nlab/show/B">B</a> rather than redirect it, but if we ever do otherwise, then we just have to make sure that people can actually <em >find</em> the text ‘B’ on the page! (Sometimes they forget that at Wikipedia ….)</p></p></blockqoute>

Author: TobyBartelsFormat: HtmlI forgot to add:<p>In any case, there should be text that suggests the reason for any redirect more complicated than [[categories]] ? [[category]], just as part of the natural exposition, wherever the redirection term (first) appears.<p>(OK, the right arrow there appears in the preview; let's see if it lasts to the final post ….)

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
I forgot to add:<p>In any case, there should be text that suggests the reason for any redirect more complicated than <a href="http://ncatlab.org/nlab/show/categories">categories</a> ? <a href="http://ncatlab.org/nlab/show/category">category</a>, just as part of the natural exposition, wherever the redirection term (first) appears.<p>(OK, the right arrow there appears in the preview; let's see if it lasts to the final post ….)</p></p>
</div>

Author: EricFormat: TextOk!
My exam is over. A six hour exam spread over eight hours with a two hour commute thrown in just for fun. I slept for about 11.5 hours. Now, I'm back in business :)
One point...
I'm with Mike about parentheses. I actually think the topic is moot because no one on the nLab wil stop using parentheses for page titles. Nor should they.
Another point...
If we make redirects take priority over existing pages, then we can use the built-in functionality to create automated lists of pages redirected toward other pages.
For example, on [[groupoids]] we could have a
category: redirect(groupoid)
Any link pointing to [[groupoids]] will be redirected to [[groupoid]]. Now to see a list of all pages that are redirected to [[groupoid]], just go to
http://ncatlab.org/nlab/list/redirect(groupoid)
I am not a big fan of the current implementation of redirects because if we want to maintain some meta information on the source page, we need to create a separate "source/history". That does not seem very clean to me.
Note: Whenever I talk about redirects taking priority, I mean redirects taking priority AND any new redirects check the source page to make sure it is "clean", i.e. only containing meta information, before allowing the redirect to go through as outlined in Comment 240 (is there a way to link to a comment here?)
Edit: With some trial and error, here is a more direct link to my outline
http://www.math.ntnu.no/~stacey/Vanilla/nForum/comments.php?DiscussionID=16&page=1#Item_28

Ok!

My exam is over. A six hour exam spread over eight hours with a two hour commute thrown in just for fun. I slept for about 11.5 hours. Now, I'm back in business :)

One point...

I'm with Mike about parentheses. I actually think the topic is moot because no one on the nLab wil stop using parentheses for page titles. Nor should they.

Another point...

If we make redirects take priority over existing pages, then we can use the built-in functionality to create automated lists of pages redirected toward other pages.

Any link pointing to groupoids will be redirected to groupoid. Now to see a list of all pages that are redirected to groupoid, just go to

http://ncatlab.org/nlab/list/redirect(groupoid)

I am not a big fan of the current implementation of redirects because if we want to maintain some meta information on the source page, we need to create a separate "source/history". That does not seem very clean to me.

Note: Whenever I talk about redirects taking priority, I mean redirects taking priority AND any new redirects check the source page to make sure it is "clean", i.e. only containing meta information, before allowing the redirect to go through as outlined in Comment 240 (is there a way to link to a comment here?)

Edit: With some trial and error, here is a more direct link to my outline

Author: Mike ShulmanFormat: MarkdownAn easier way to see a list of all page names that are redirected to "groupoid," not just those which happen to exist as separate pages that have been overridden by redirects, is to edit the source of "groupoid" and look at all the `[[!redirects ...]` commands.

An easier way to see a list of all page names that are redirected to "groupoid," not just those which happen to exist as separate pages that have been overridden by redirects, is to edit the source of "groupoid" and look at all the [[!redirects ...] commands.

Author: TobyBartelsFormat: HtmlWhy does <a href="http://ncatlab.org/nlab/show/doctrine">[[doctrine]]</a> redirect to <a href="http://ncatlab.org/nlab/show/internalization">[[internalization]]</a>? I can't find anything in the edit history to justify this in any way!

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
Why does <a href="http://ncatlab.org/nlab/show/doctrine"><a href="http://ncatlab.org/nlab/show/doctrine">doctrine</a></a> redirect to <a href="http://ncatlab.org/nlab/show/internalization"><a href="http://ncatlab.org/nlab/show/internalization">internalization</a></a>? I can't find anything in the edit history to justify this in any way!
</div>

Author: Mike ShulmanFormat: MarkdownI guess someone must have been thinking of the sentence "The structure required on C is often referred to as a doctrine." I added a redirect for "doctrine" to "2-monad" but it looks like this one took precedence.
I suggest that we suggest to Jacques that it be an error to create a second page that claims to redirect a given page name, just like it's an error to try to save a page without changing its content. Currently if two or more pages claim to redirect the same page name, it seems as if the one that's lexicographically earlier wins silently.

I guess someone must have been thinking of the sentence "The structure required on C is often referred to as a doctrine." I added a redirect for "doctrine" to "2-monad" but it looks like this one took precedence.

I suggest that we suggest to Jacques that it be an error to create a second page that claims to redirect a given page name, just like it's an error to try to save a page without changing its content. Currently if two or more pages claim to redirect the same page name, it seems as if the one that's lexicographically earlier wins silently.

Author: Mike ShulmanFormat: MarkdownBy the way when I first read your post, "doctrine" was still redirecting to "internalization," despite the latter no longer having a [[!redirects doctrine]] on it. So it looks like the cache bug is not completely solved, although I'm failing to reproduce a problem with toy pages at the moment.

By the way when I first read your post, "doctrine" was still redirecting to "internalization," despite the latter no longer having a !redirects doctrine on it. So it looks like the cache bug is not completely solved, although I'm failing to reproduce a problem with toy pages at the moment.

Author: EricFormat: Text> An easier way to see a list of all page names that are redirected to "groupoid," not just those which happen to exist as separate pages that have been overridden by
> redirects, is to edit the source of "groupoid" and look at all the [[!redirects ...] commands.
True, but the only way to really ensure the accuracy of this would be to have redirects take priority. If [[foo]] already exists and [[bar]] has a [[!redirects foo]], then you would mistakenly think that [[foo]] redirects to [[bar]].

> An easier way to see a list of all page names that are redirected to "groupoid," not just those which happen to exist as separate pages that have been overridden by > redirects, is to edit the source of "groupoid" and look at all the !redirects ...] commands.

Author: TobyBartelsFormat: HtmlThe cache bug is what I was asking about, except that I can't find any past version of [[internalization]] to justify that redirect either! (By ‘justify’, I mean to justify the behaviour of the software.)<p>And I don't think that either of those redirects should exist, actually. The page [[doctrine]] is where we should discuss whether it should be defined as a 2-monad at all.

The cache bug is what I was asking about, except that I can't find any past version of internalization to justify that redirect either! (By ‘justify’, I mean to justify the behaviour of the software.)

And I don't think that either of those redirects should exist, actually. The page doctrine is where we should discuss whether it should be defined as a 2-monad at all.

Author: Mike ShulmanFormat: MarkdownToby: That's weird. You're right about the redirects, I added the one to 2-monad before I understood what people were driving at with "doctrine."
Eric: Maybe it should also be an error to try to create a page that is currently redirected, or else it should automatically remove the redirect instruction. And likewise it would be an error to try to create a redirect for a page name that already exists.

Toby: That's weird. You're right about the redirects, I added the one to 2-monad before I understood what people were driving at with "doctrine."

Eric: Maybe it should also be an error to try to create a page that is currently redirected, or else it should automatically remove the redirect instruction. And likewise it would be an error to try to create a redirect for a page name that already exists.

Author: Mike ShulmanFormat: MarkdownOh, hey, here's something that might have caused the redirection to [[internalization]]. For a while, there was a cache bug whereby when you *deleted* a [[!redirects ]] instruction, pages linking to the redirected page name weren't expired from the cache and continued to point to the page that used to claim a redirect. (Jacques said that fixing this bug took him twice as long as coding the redirects in the first place!) Now suppose that while this bug existed, someone edited [[internalization]] to add a [[!redirects doctrine]], but then immediately changed their mind and deleted it. Since immediate re-edits don't create new versions, there wouldn't be anything to see in the page history, but because of the cache bug, [[doctrine]] would have been left pointing to [[internalization]].

Oh, hey, here's something that might have caused the redirection to internalization. For a while, there was a cache bug whereby when you deleted a !redirects instruction, pages linking to the redirected page name weren't expired from the cache and continued to point to the page that used to claim a redirect. (Jacques said that fixing this bug took him twice as long as coding the redirects in the first place!) Now suppose that while this bug existed, someone edited internalization to add a !redirects doctrine, but then immediately changed their mind and deleted it. Since immediate re-edits don't create new versions, there wouldn't be anything to see in the page history, but because of the cache bug, doctrine would have been left pointing to internalization.

Author: EricFormat: TextProblems with cache bugs etc would seem to me to disappear if redirects took priority. Sorry if I sound like a broken record :)
Edit: The current implementation requires a level of finesse that I think is too high to be practical. Making redirects take priority is kind of crude, but it will work and gives enough flexibility to do anything we'd like to do.

Problems with cache bugs etc would seem to me to disappear if redirects took priority. Sorry if I sound like a broken record :)

Edit: The current implementation requires a level of finesse that I think is too high to be practical. Making redirects take priority is kind of crude, but it will work and gives enough flexibility to do anything we'd like to do.

Author: TobyBartelsFormat: HtmlEric, I don't think that making redirects take priority would get rid of cache bugs. It wouldn't have had any effect on whatever cache bug was affecting [[doctrine]], for example, since that page had never existed. And it could even cause new cache bugs; suppose that [[doctrine]] <em>had</em> existed when a redirect to [[internalization]] or [[2-monad]] was created and then removed; the cache bug would have thought that this redirect <em>still</em> had priority.<p>Mike, I think that your explanation is the only thing that makes sense. (If I recall correctly, this means that John must have done it; we could ask him if we care that much, but I don't.)

Eric, I don't think that making redirects take priority would get rid of cache bugs. It wouldn't have had any effect on whatever cache bug was affecting doctrine, for example, since that page had never existed. And it could even cause new cache bugs; suppose that doctrinehad existed when a redirect to internalization or 2-monad was created and then removed; the cache bug would have thought that this redirect still had priority.

Mike, I think that your explanation is the only thing that makes sense. (If I recall correctly, this means that John must have done it; we could ask him if we care that much, but I don't.)

Author: Andrew StaceyFormat: MarkdownMike can presumably confirm or deny this, but I understand that the cache bug has been dealt with. There may still be lingering effects from when it was in force (that's the problem with caches, after all) but there shouldn't be any _new_ ones.
Eric, I don't think that Jacques is going to change the system for a bit (beyond bug fixes). I think he would like us to try it out for a while, long enough to get used to what it _is_ and forget what it _isn't_. If we do that then we can say, "Okay, we really would like X or Y." and have some reason from experience behind what we say. No system is perfect and at some point you start just having to use it and stop trying to fine tune it.
I think it's time that someone who really understands the system (i.e. not me) to write something on the HowTo or FAQ (or both) explaining how it works. Maybe also note that it's a new feature and any comments on it can be put here on the Forum.

Mike can presumably confirm or deny this, but I understand that the cache bug has been dealt with. There may still be lingering effects from when it was in force (that's the problem with caches, after all) but there shouldn't be any new ones.

Eric, I don't think that Jacques is going to change the system for a bit (beyond bug fixes). I think he would like us to try it out for a while, long enough to get used to what it is and forget what it isn't. If we do that then we can say, "Okay, we really would like X or Y." and have some reason from experience behind what we say. No system is perfect and at some point you start just having to use it and stop trying to fine tune it.

I think it's time that someone who really understands the system (i.e. not me) to write something on the HowTo or FAQ (or both) explaining how it works. Maybe also note that it's a new feature and any comments on it can be put here on the Forum.

Author: Mike ShulmanFormat: MarkdownOk, the situation with "doctrine" is _very weird_ at the moment! None of the three pages "internalization," "internal logic," and "2-monad" currently claim to redirect doctrine, but the links to [[doctrine]] on each of those pages always point to one of the three. Which one they point to seems to change whenever one of them is saved, but I can't figure out what controls it. I'm going to ask Jacques. For now, I suggest that no one actually create the page "doctrine" while we try to figure this out.

Ok, the situation with "doctrine" is very weird at the moment! None of the three pages "internalization," "internal logic," and "2-monad" currently claim to redirect doctrine, but the links to doctrine on each of those pages always point to one of the three. Which one they point to seems to change whenever one of them is saved, but I can't figure out what controls it. I'm going to ask Jacques. For now, I suggest that no one actually create the page "doctrine" while we try to figure this out.

Author: TobyBartelsFormat: HtmlOK, here is a feature that would be very nice.<p>On Wikipedia, if I edit a page and create a link (say [[categories]]) to a page that I think should already exist, then (usually while still in preview on the first page) I'll create that page as a redirect (sometimes testing the proper target while in that page's preview). Here, however, I must somehow get to [[category]] (which I never linked), requiring that I edit the URI by hand. Certainly I can do nothing (other than mess things up) by actually clicking on my new link [[categories]].<p>So I would like, in addition to the ‘Change page name.’ checkbox when editing an existant page, a ‘Redirect page.’ checkbox when creating a new page. So I'd click on [[categories]], check to redirect the page, and it would ask me for the title to redirect it to. If I type the name of a page that doesn't exist, then it could return with an error; or else, it might happily continue, adding <code>[[!redirects categories]]</code> to the top of edit box, and let me create the new page at the new title. (This case is not so important, since I can always move the page afterwards.) But if I type the name of a page that does exist (say, [[category]]), then it would replace the edit box contents with the contents of [[category]] (can this be done in a way that doesn't break Ctrl-Z?), adding <code>[[!redirects category]]</code> to the top (or bottom), and lock [[category]]. Then when I submit, it will actually submit this for [[category]].<p>Or if that's too complicated, then when I type in the name of a page that already exists, then it could just ignore whatever I have in the edit box (hopefully with some sort of warning), then add <code>[[!redirects categories]]</code> to the top of [[category]] when I hit save. That's all that I really want it to do, although it may look a little counterintuitive.

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
OK, here is a feature that would be very nice.<p>On Wikipedia, if I edit a page and create a link (say <a href="http://ncatlab.org/nlab/show/categories">categories</a>) to a page that I think should already exist, then (usually while still in preview on the first page) I'll create that page as a redirect (sometimes testing the proper target while in that page's preview). Here, however, I must somehow get to <a href="http://ncatlab.org/nlab/show/category">category</a> (which I never linked), requiring that I edit the URI by hand. Certainly I can do nothing (other than mess things up) by actually clicking on my new link <a href="http://ncatlab.org/nlab/show/categories">categories</a>.<p>So I would like, in addition to the ‘Change page name.’ checkbox when editing an existant page, a ‘Redirect page.’ checkbox when creating a new page. So I'd click on <a href="http://ncatlab.org/nlab/show/categories">categories</a>, check to redirect the page, and it would ask me for the title to redirect it to. If I type the name of a page that doesn't exist, then it could return with an error; or else, it might happily continue, adding <code><a href="http://ncatlab.org/nlab/show/%21redirects+categories">!redirects categories</a></code> to the top of edit box, and let me create the new page at the new title. (This case is not so important, since I can always move the page afterwards.) But if I type the name of a page that does exist (say, <a href="http://ncatlab.org/nlab/show/category">category</a>), then it would replace the edit box contents with the contents of <a href="http://ncatlab.org/nlab/show/category">category</a> (can this be done in a way that doesn't break Ctrl-Z?), adding <code><a href="http://ncatlab.org/nlab/show/%21redirects+category">!redirects category</a></code> to the top (or bottom), and lock <a href="http://ncatlab.org/nlab/show/category">category</a>. Then when I submit, it will actually submit this for <a href="http://ncatlab.org/nlab/show/category">category</a>.<p>Or if that's too complicated, then when I type in the name of a page that already exists, then it could just ignore whatever I have in the edit box (hopefully with some sort of warning), then add <code><a href="http://ncatlab.org/nlab/show/%21redirects+categories">!redirects categories</a></code> to the top of <a href="http://ncatlab.org/nlab/show/category">category</a> when I hit save. That's all that I really want it to do, although it may look a little counterintuitive.</p></p></p>
</div>

Author: TobyBartelsFormat: HtmlYes, you can undo ‘Change page name.’; just change it back. (You'll also want to remove the spurious <code>!redirects</code> command, although it's harmless as long as existing pages take priority over redirects.)<p>To undo my proposed ‘Redirect page.’ command (at least in the important case when you redirect to a page that already exists), you only have to remove the <code>!redirects</code> command (and possibly undo any other edits that you made at that time). You can't (without deleting pages) undo a ‘Redirect page.’ command when you redirect to a page that doesn't exist; maybe that's a reason not to allow that. (That's not the case that I care about, after all.)<p>I don't see how anything would be different if redirects took priority (other than the parenthetical comment in my first paragraph), since this is all supposed to turn a clean system (no duplicate redirects, no redirects from existing pages) into another clean system.

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
Yes, you can undo ‘Change page name.’; just change it back. (You'll also want to remove the spurious <code>!redirects</code> command, although it's harmless as long as existing pages take priority over redirects.)<p>To undo my proposed ‘Redirect page.’ command (at least in the important case when you redirect to a page that already exists), you only have to remove the <code>!redirects</code> command (and possibly undo any other edits that you made at that time). You can't (without deleting pages) undo a ‘Redirect page.’ command when you redirect to a page that doesn't exist; maybe that's a reason not to allow that. (That's not the case that I care about, after all.)<p>I don't see how anything would be different if redirects took priority (other than the parenthetical comment in my first paragraph), since this is all supposed to turn a clean system (no duplicate redirects, no redirects from existing pages) into another clean system.</p></p>
</div>

Author: TobyBartelsFormat: HtmlMaybe things will be clearer if I spell out my new suggestion in pseudocode, although I warn that there are some gaps!<p><ol><li>I click on the link that starts a new page [[foo]], or otherwise get to a URI of the form <code>http://ncatlab.org/*/new/foo</code>.</li><li>There's an unchecked box there labelled ‘Redirect page.’ (or something like that).</li><li><b>if</b> I check the box <b>then</b> <b>begin</b><ol><li>I get a blank form to fill out.</li><li>I put a title ‘bar’ in the form.</li><li><b>if</b> the title matches an existing page <b>then</b> <b>begin</b><ol><li><code>[[!redirects foo]]</code> is added to [[bar]].</li><li>I'm now editing [[bar]] (or possibly I'm forced to save now, if that's easier).</li></ol><b>end</b> <b>else</b> I get an error (or maybe something more clever, but this isn't the case that I'm interested in).</li></ol><b>end</b> <b>else</b> I create a new page as normal.</li></ol><p>Is that clear enough?<p>(Stupid forum software doesn't believe in &lt;b&gt;. I don't <em>want</em> &lt;strong&gt;, that's <em>wrong</em>; I want <em>&lt;b&gt;</em>! Ah well, it's not really necessary to put keywords in bold. Maybe I should just use Markdown and stop pretending that there's an HTML option, since I know about a dozen reasons by now that it really isn't HTML at all.)

This comment is invalid XHTML+MathML+SVG; displaying source.<div>
Maybe things will be clearer if I spell out my new suggestion in pseudocode, although I warn that there are some gaps!<p><ol><li>I click on the link that starts a new page <a href="http://ncatlab.org/nlab/show/foo">foo</a>, or otherwise get to a URI of the form <code>http://ncatlab.org/*/new/foo</code>.</li><li>There's an unchecked box there labelled ‘Redirect page.’ (or something like that).</li><li><b>if</b> I check the box <b>then</b> <b>begin</b><ol><li>I get a blank form to fill out.</li><li>I put a title ‘bar’ in the form.</li><li><b>if</b> the title matches an existing page <b>then</b> <b>begin</b><ol><li><code><a href="http://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a></code> is added to <a href="http://ncatlab.org/nlab/show/bar">bar</a>.</li><li>I'm now editing <a href="http://ncatlab.org/nlab/show/bar">bar</a> (or possibly I'm forced to save now, if that's easier).</li></ol><b>end</b> <b>else</b> I get an error (or maybe something more clever, but this isn't the case that I'm interested in).</li></ol><b>end</b> <b>else</b> I create a new page as normal.</li></ol><p>Is that clear enough?<p>(Stupid forum software doesn't believe in &lt;b&gt;. I don't <em>want</em> &lt;strong&gt;, that's <em>wrong</em>; I want <em>&lt;b&gt;</em>! Ah well, it's not really necessary to put keywords in bold. Maybe I should just use Markdown and stop pretending that there's an HTML option, since I know about a dozen reasons by now that it really isn't HTML at all.)</p></p></p>
</div>