nForum
Not signed in
Want to take part in these discussions? Sign in if you have an account, or apply for one below
Site Tag Cloud
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
-
- CommentRowNumber1.
- CommentAuthorMike Shulman
- CommentTimeMar 19th 2009
How hard would it be to add to instiki the capability to have actual redirects, like Wikipedia does? -
- CommentRowNumber2.
- CommentAuthorTobyBartels
- CommentTimeMar 19th 2009
<div> It would be very convenient in this way:<p>Right now (for example) <a href="https://ncatlab.org/nlab/show/constructivism">constructivism</a> redirects to <a href="https://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="https://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="https://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="https://ncatlab.org/nlab/show/constructivism">constructivism</a>. Whereas, if we had MediaWiki-style redirects, we could link those to <a href="https://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> -
- CommentRowNumber3.
- CommentAuthorMathforge Admin
- CommentTimeJun 1st 2009
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). -
- CommentRowNumber4.
- CommentAuthorMike Shulman
- CommentTimeJun 2nd 2009
Can we have this discussion somewhere where Jacques can/will contribute directly as well?
-
- CommentRowNumber5.
- CommentAuthorTobyBartels
- CommentTimeJun 2nd 2009
Maybe somewhere starting from here? -
- CommentRowNumber6.
- CommentAuthorMike Shulman
- CommentTimeJun 2nd 2009
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.
-
- CommentRowNumber7.
- CommentAuthorTobyBartels
- CommentTimeJun 2nd 2009
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.
- 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 …
-
- CommentRowNumber8.
- CommentAuthorAndrew Stacey
- CommentTimeJun 2nd 2009
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.
-
- CommentRowNumber9.
- CommentAuthorTobyBartels
- CommentTimeJun 2nd 2009
<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="https://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="https://ncatlab.org/nlab/show/categories">categories</a></code> should be changed to <code><a href="https://ncatlab.org/nlab/show/category">categories</a></code>, still <code><a href="https://ncatlab.org/nlab/show/constructivism">constructivism</a></code> should not be changed to <code><a href="https://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> -
- CommentRowNumber10.
- CommentAuthorMike Shulman
- CommentTimeJun 2nd 2009
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.
-
- CommentRowNumber11.
- CommentAuthorTobyBartels
- CommentTimeJun 2nd 2009
- (edited Jun 2nd 2009)
<div> Another thing that I would like from redirects, and which MediaWiki does <em>not</em> offer, is this: If <code><a href="https://ncatlab.org/nlab/show/foo">foo</a></code> redirects to <code><a href="https://ncatlab.org/nlab/show/bar">bar</a></code> but <code><a href="https://ncatlab.org/nlab/show/bar">bar</a></code> does not exist, then any link to <code><a href="https://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="https://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="https://ncatlab.org/nlab/show/fu">fu</a></code> redirects to a page <code><a href="https://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="https://ncatlab.org/nlab/show/bar">bar</a></code>. Redirecting <code><a href="https://ncatlab.org/nlab/show/fu">fu</a></code> directly to <code><a href="https://ncatlab.org/nlab/show/bar">bar</a></code> makes it a bit more difficult (although still manageable) when <code><a href="https://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> -
- CommentRowNumber12.
- CommentAuthorMike Shulman
- CommentTimeJun 2nd 2009
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.
-
- CommentRowNumber13.
- CommentAuthorTobyBartels
- CommentTimeJun 3rd 2009
<div> OK, so here's how the new redirects on the Lab work.<p>If you want <a href="https://ncatlab.org/nlab/show/foo">foo</a> to redirected to <a href="https://ncatlab.org/nlab/show/bar">bar</a>, then <em>don't</em> create <a href="https://ncatlab.org/nlab/show/foo">foo</a>! Instead, edit <a href="https://ncatlab.org/nlab/show/bar">bar</a> to include (at the top, although there can be a list) <a href="https://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a>. Then any internal link to <a href="https://ncatlab.org/nlab/show/foo">foo</a> will actually become an HTML link to <a href="https://ncatlab.org/nlab/show/bar">bar</a>. If anybody creates <a href="https://ncatlab.org/nlab/show/foo">foo</a>, then this breaks. If another page has <a href="https://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="https://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="https://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>. (Method: if <a href="https://ncatlab.org/nlab/show/foo">foo</a> redirects to <a href="https://ncatlab.org/nlab/show/bar">bar</a> now using the old method, then move <a href="https://ncatlab.org/nlab/show/foo">foo</a> to <a href="https://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>, remove <a href="https://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a> from <a href="https://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>, and add <a href="https://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a> to <a href="https://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> -
- CommentRowNumber14.
- CommentAuthorTobyBartels
- CommentTimeJun 3rd 2009
<div> I wrote:<blockquote>Method: if <a href="https://ncatlab.org/nlab/show/foo">foo</a> redirects to <a href="https://ncatlab.org/nlab/show/bar">bar</a> now using the old method, then move <a href="https://ncatlab.org/nlab/show/foo">foo</a> to <a href="https://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>, remove <a href="https://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a> from <a href="https://ncatlab.org/nlab/show/bar%2Fhistory">bar/history</a>, and add <a href="https://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a> to <a href="https://ncatlab.org/nlab/show/bar">bar</a>.</blockquote>Actually, you'd have to put it at <a href="https://ncatlab.org/nlab/show/foo%2Fhistory">foo/history</a> to allow for the possibility that more than one current page redirects to <a href="https://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="https://ncatlab.org/nlab/show/foo">foo</a> separate from <a href="https://ncatlab.org/nlab/show/bar">bar</a>, to do this by moving <a href="https://ncatlab.org/nlab/show/foo%2Fhistory">foo/history</a> back to <a href="https://ncatlab.org/nlab/show/foo">foo</a> first. This is a little tricky, but it could work. </div> -
- CommentRowNumber15.
- CommentAuthorMike Shulman
- CommentTimeJun 3rd 2009
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.
-
- CommentRowNumber16.
- CommentAuthorEric
- CommentTimeJun 3rd 2009
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 :|
http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024203 -
- CommentRowNumber17.
- CommentAuthorEric
- CommentTimeJun 3rd 2009
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)
My recommendation is here:
http://golem.ph.utexas.edu/~distler/blog/archives/001083.html#c024243 -
- CommentRowNumber18.
- CommentAuthorAndrew Stacey
- CommentTimeJun 3rd 2009
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.
-
- CommentRowNumber19.
- CommentAuthorTobyBartels
- CommentTimeJun 3rd 2009
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.) -
- CommentRowNumber20.
- CommentAuthorMike Shulman
- CommentTimeJun 3rd 2009
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.
-
- CommentRowNumber21.
- CommentAuthorMike Shulman
- CommentTimeJun 3rd 2009
I'm curious, what are people's thoughts about redirecting plural forms? For instance, if the page
categorycontained!redirects categoriesthen we could start writingcategorieseverywhere instead ofcategories. -
- CommentRowNumber22.
- CommentAuthorTobyBartels
- CommentTimeJun 4th 2009
Yes, I would like to do that. -
- CommentRowNumber23.
- CommentAuthorEric
- CommentTimeJun 4th 2009
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.
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? -
- CommentRowNumber24.
- CommentAuthorMike Shulman
- CommentTimeJun 4th 2009
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 calledwadgetwith just a few lines, and since as everyone knows a widget is a special case of a wadget, I throw in a!redirect widgetat the top of mywadgetpage. (I'm lazy or in a hurry, so I don't bother to check whether someone has written the pagewidgetalready.) 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 pagewidgetdidn't change. No one will notice until they click on a linkwidgetand 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:redirectpages topage/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 createsgizmosin violation of the naming conventions, we can now simply move the page togizmorather than copying the text and makinggizmosa 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!redirectlines 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. -
- CommentRowNumber25.
- CommentAuthorAndrew Stacey
- CommentTimeJun 4th 2009
- (edited Jun 4th 2009)
My word, but you lot can sure talk a lot!
So we can redirect non-existant pages simply by putting
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 idiottoAndrew Staceythen 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.
-
- CommentRowNumber26.
- CommentAuthorAndrew Stacey
- CommentTimeJun 4th 2009
PS In the tradition of GNU naming conventions, I think that we should rename Instiki to INM.
-
- CommentRowNumber27.
- CommentAuthorMike Shulman
- CommentTimeJun 4th 2009
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$-categorycommand. 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
categoriesis redirected tocategory! 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:redirectpages tofoo/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?)
-
- CommentRowNumber28.
- CommentAuthorEric
- CommentTimeJun 4th 2009
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. -
- CommentRowNumber29.
- CommentAuthorMike Shulman
- CommentTimeJun 4th 2009
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/deleteand maybe also addcategory: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.
-
- CommentRowNumber30.
- CommentAuthorEric
- CommentTimeJun 4th 2009
> 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! -
- CommentRowNumber31.
- CommentAuthorTobyBartels
- CommentTimeJun 5th 2009
<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> -
- CommentRowNumber32.
- CommentAuthorTobyBartels
- CommentTimeJun 5th 2009
<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> -
- CommentRowNumber33.
- CommentAuthorTobyBartels
- CommentTimeJun 5th 2009
<div> Instructions to move <a href="https://ncatlab.org/nlab/show/A">A</a> to <a href="https://ncatlab.org/nlab/show/B">B</a> when <a href="https://ncatlab.org/nlab/show/B">B</a> does not exist:<ul><li>Open <a href="https://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="https://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="https://ncatlab.org/nlab/show/A">A</a> (in)to <a href="https://ncatlab.org/nlab/show/B">B</a> when <a href="https://ncatlab.org/nlab/show/A">A</a> has most of the content/history:<ol><li>Move <a href="https://ncatlab.org/nlab/show/B">B</a> to <a href="https://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="https://ncatlab.org/nlab/show/A">A</a> to <a href="https://ncatlab.org/nlab/show/B">B</a> in the usual way.</li><li>Edit <a href="https://ncatlab.org/nlab/show/B">B</a> to include any useful content from <a href="https://ncatlab.org/nlab/show/B%2Fhistory">B/history</a>.</li><li>Edit <a href="https://ncatlab.org/nlab/show/B%2Fhistory">B/history</a> to consist of ‘See <a href="https://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="https://ncatlab.org/nlab/show/A">A</a> (in)to <a href="https://ncatlab.org/nlab/show/B">B</a> when <a href="https://ncatlab.org/nlab/show/B">B</a> has most of the content/history:<ol><li>Move <a href="https://ncatlab.org/nlab/show/A">A</a> to <a href="https://ncatlab.org/nlab/show/A%2Fhistory">A/history</a> in the usual way.</li><li>Add ‘<a href="https://ncatlab.org/nlab/show/%21redirects+A">!redirects A</a>’ to the top of <a href="https://ncatlab.org/nlab/show/B">B</a>.</li><li>Edit <a href="https://ncatlab.org/nlab/show/B">B</a> again to include any useful content from <a href="https://ncatlab.org/nlab/show/A%2Fhistory">A/history</a>.</li><li>Edit <a href="https://ncatlab.org/nlab/show/A%2Fhistory">A/history</a> to consist of ‘See <a href="https://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="https://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> -
- CommentRowNumber34.
- CommentAuthorTobyBartels
- CommentTimeJun 5th 2009
PS to Andrew: How come the ordered lists here come out with bullet points instead of numbers? -
- CommentRowNumber35.
- CommentAuthorTobyBartels
- CommentTimeJun 5th 2009
Also: Instructions to unmerge B and make A a separate page once more, when A/history exists:- Move A/history to A.
- 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.)
-
- CommentRowNumber36.
- CommentAuthorTobyBartels
- CommentTimeJun 5th 2009
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. -
- CommentRowNumber37.
- CommentAuthorEric
- CommentTimeJun 5th 2009
I have some thoughts, but have a 6 hour exam on Saturday and my ability to procrastinate studying is getting weaker... -
- CommentRowNumber38.
- CommentAuthorAndrew Stacey
- CommentTimeJun 5th 2009
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.
-
- CommentRowNumber39.
- CommentAuthorEric
- CommentTimeJun 5th 2009
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. -
- CommentRowNumber40.
- CommentAuthorMike Shulman
- CommentTimeJun 5th 2009
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
!titlecommand 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!
-
- CommentRowNumber41.
- CommentAuthorEric
- CommentTimeJun 5th 2009
- (edited Jun 5th 2009)
I 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
-category redirect to infinity-category which contains a !title -category :)PS: Jacques rulez :)
-
- CommentRowNumber42.
- CommentAuthorAndrew Stacey
- CommentTimeJun 5th 2009
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.
-
- CommentRowNumber43.
- CommentAuthorMike Shulman
- CommentTimeJun 6th 2009
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.
-
- CommentRowNumber44.
- CommentAuthorAndrew Stacey
- CommentTimeJun 6th 2009
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.
Nonetheless, this isn't a major issue either way.
-
- CommentRowNumber45.
- CommentAuthorMike Shulman
- CommentTimeJun 6th 2009
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.
And I don't want to be forced to type (n,r)-category.
-
- CommentRowNumber46.
- CommentAuthorAndrew Stacey
- CommentTimeJun 6th 2009
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.
-
- CommentRowNumber47.
- CommentAuthorMike Shulman
- CommentTimeJun 7th 2009
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.
-
- CommentRowNumber48.
- CommentAuthorTobyBartels
- CommentTimeJun 7th 2009
<div> But what if somebody is creating the page? Then either they still have to type ‘<a href="https://ncatlab.org/nlab/show/_n_r_-category">(n,r)-category</a>’ once or somebody has to move <a href="https://ncatlab.org/nlab/show/%28n%2Cr%29-category">(n,r)-category</a> to <a href="https://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="https://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="https://ncatlab.org/nlab/show/%28n%2Cr%29-category">(n,r)-category</a>’ will create a link to <a href="https://ncatlab.org/nlab/show/_n_r_-category">_n_r_-category</a> automatically. (This would not help much with <a href="https://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="https://ncatlab.org/nlab/show/A+-+history">A - history</a> (with an ASCII hyphen-minus with a space on each side).</p></p></p> </div> -
- CommentRowNumber49.
- CommentAuthorTobyBartels
- CommentTimeJun 7th 2009
(Heh, looks like this comment system doesn't like the infinity character!) -
- CommentRowNumber50.
- CommentAuthorTobyBartels
- CommentTimeJun 7th 2009
<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="https://ncatlab.org/nlab/show/biunivocal+relation">biunivocal relation</a> to <a href="https://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="https://ncatlab.org/nlab/show/A">A</a> that discusses the related topic <a href="https://ncatlab.org/nlab/show/B">B</a> and then redirect <a href="https://ncatlab.org/nlab/show/B">B</a> to <a href="https://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="https://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> -
- CommentRowNumber51.
- CommentAuthorTobyBartels
- CommentTimeJun 7th 2009
<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="https://ncatlab.org/nlab/show/categories">categories</a> ? <a href="https://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> -
- CommentRowNumber52.
- CommentAuthorEric
- CommentTimeJun 7th 2009
- (edited Jun 7th 2009)
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.
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 -
- CommentRowNumber53.
- CommentAuthorMike Shulman
- CommentTimeJun 8th 2009
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. -
- CommentRowNumber54.
- CommentAuthorTobyBartels
- CommentTimeJun 9th 2009
- (edited Jun 9th 2009)
<div> Why does <a href="http://ncatlab.org/nlab/show/doctrine"><a href="https://ncatlab.org/nlab/show/doctrine">doctrine</a></a> redirect to <a href="http://ncatlab.org/nlab/show/internalization"><a href="https://ncatlab.org/nlab/show/internalization">internalization</a></a>? I can't find anything in the edit history to justify this in any way! </div> -
- CommentRowNumber55.
- CommentAuthorMike Shulman
- CommentTimeJun 9th 2009
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.
-
- CommentRowNumber56.
- CommentAuthorMike Shulman
- CommentTimeJun 9th 2009
Oh, no, I stand corrected... maybe it's the one that was created first? Regardless, I think it shouldn't be allowed to come up.
-
- CommentRowNumber57.
- CommentAuthorMike Shulman
- CommentTimeJun 9th 2009
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.
-
- CommentRowNumber58.
- CommentAuthorEric
- CommentTimeJun 9th 2009
> 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. -
- CommentRowNumber59.
- CommentAuthorTobyBartels
- CommentTimeJun 9th 2009
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.
-
- CommentRowNumber60.
- CommentAuthorMike Shulman
- CommentTimeJun 10th 2009
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.
-
- CommentRowNumber61.
- CommentAuthorMike Shulman
- CommentTimeJun 10th 2009
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.
-
- CommentRowNumber62.
- CommentAuthorEric
- CommentTimeJun 10th 2009
- (edited Jun 10th 2009)
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. -
- CommentRowNumber63.
- CommentAuthorTobyBartels
- CommentTimeJun 10th 2009
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 doctrine had 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.)
-
- CommentRowNumber64.
- CommentAuthorAndrew Stacey
- CommentTimeJun 10th 2009
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.
-
- CommentRowNumber65.
- CommentAuthorTobyBartels
- CommentTimeJun 10th 2009
I'm ready to, although somebody else has been editing HowTo for 13 minutes, so it may be a few hours before I get back to it. -
- CommentRowNumber66.
- CommentAuthorMike Shulman
- CommentTimeJun 11th 2009
Jacques told me that the cache bug has been fixed, and I haven't experienced it since then.
-
- CommentRowNumber67.
- CommentAuthorMike Shulman
- CommentTimeJun 11th 2009
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.
-
- CommentRowNumber68.
- CommentAuthorMike Shulman
- CommentTimeJun 11th 2009
Hooray for Jacques! He just fixed this latest bug too.
-
- CommentRowNumber69.
- CommentAuthorTobyBartels
- CommentTimeJun 16th 2009
<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="https://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="https://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="https://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="https://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="https://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="https://ncatlab.org/nlab/show/category">category</a>), then it would replace the edit box contents with the contents of <a href="https://ncatlab.org/nlab/show/category">category</a> (can this be done in a way that doesn't break Ctrl-Z?), adding <code><a href="https://ncatlab.org/nlab/show/%21redirects+category">!redirects category</a></code> to the top (or bottom), and lock <a href="https://ncatlab.org/nlab/show/category">category</a>. Then when I submit, it will actually submit this for <a href="https://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="https://ncatlab.org/nlab/show/%21redirects+categories">!redirects categories</a></code> to the top of <a href="https://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> -
- CommentRowNumber70.
- CommentAuthorEric
- CommentTimeJun 16th 2009
Is there a way to undo a "Change page name"?
If redirects took priority, how would you do what you're trying to do? (I'm a little confused) -
- CommentRowNumber71.
- CommentAuthorTobyBartels
- CommentTimeJun 17th 2009
<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> -
- CommentRowNumber72.
- CommentAuthorTobyBartels
- CommentTimeJun 17th 2009
<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="https://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="https://ncatlab.org/nlab/show/%21redirects+foo">!redirects foo</a></code> is added to <a href="https://ncatlab.org/nlab/show/bar">bar</a>.</li><li>I'm now editing <a href="https://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 <b>. I don't <em>want</em> <strong>, that's <em>wrong</em>; I want <em><b></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> -
- CommentRowNumber73.
- CommentAuthorTobyBartels
- CommentTimeJun 17th 2009
I've decided that this discussion would probably work better separate.
1 to 73 of 73