Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
1 to 10 of 10
Certainly, the fact that page names here are case sensitive does significantly more harm than good. However, I also understand that there is a preferred capitalization scheme, so is there any way when one creates a page, all of the redirects will be created to the page with the correct capitalization?
If you want Page to automatically redirect to page even when there is no [[!redirects Page]] in the source of page, essentially the way Wikipedia does things, I would be against that. The redirect should be in the body, where we can remove it later if we decide to.
However, if you want a method that, when you create page, automatically places [[!redirects Page]] into the source, that would be a good idea. Presumably this would be no harder than the Javascript that places [[!redirects foo]] into the source when you rename foo to bar. However, Andrew may not be able to do this; we may need Jacques to do it.
So casting our minds back, when somebody first creates set, it would have [[!redirects Set]] put in it. Any links to that really meant to go to Set instead of set, as long as Set does not exist, would do well to redirect to set anyway. But someday, when we decide to create Set as a separate page, we can remove [[!redirects Set]] from set while placing a link there to Set, which we use to create Set. (Actually, this example is ahistorical, since Set existed a few minutes before set did. Sorry about that.)
Yes, I was talking about the solution that you agree with.
I would find this quite useful as well. I think that it sounds like something for javascript and I would have it tied to a button, both so that it didn’t annoy people who didn’t want it and so that it could be applied retrospectively. As well as the singular/plural issue, I would add redirects where accented characters are taken out. I would guess that it couldn’t do the plurals perfectly (any pages with sheep in the title?) so the idea would be to suggest a load which could then be pruned by the user. But it’s easier to simply delete a few than to add in new ones, so I would go for more suggestions rather than fewer.
Adding javascript is straightforward and I don’t think would break our connection with the source. If we found this useful, it could easily be added to the main source as well.
How I think it would work:
I’m no javascript expert so I don’t know actually how one would do this!
By the way, concerning programming the nLab: way high on my wish-list (not demand-list!) for things that hopefully can be done at some point is a fix for the slowdown produced by many hyperlinks.
This is a problem that my style of writing is causing, but it’s a problem. Pages like Lie infinity-groupoid take forever to appear. Same for many of the pages on my personal web, which are written in a similar style. But I think that “style” (hyperlinking everything in sight) is the very point of a wiki, so I am hoping the software can eventually cope with it.
(All this based on the assumption that it’s indeed the number of hyperlinks that makes the appearance of these pages slow. That’s what Andrew suggested last time I mentioned this.)
Urs, that would require Deep Hackery so should be passed on to Jacques. I suppose I could do a little more investigating first to try to gather more evidence that that is the issue with those pages.
try to gather more evidence that that is the issue with those pages.
Probably the existing evidence is pretty good already: first I noticed it only with my personal web and so thought it was an issue with that. Then, when you mentioned that it might be the links, I started expanding the entry Lie-infinity groupoid on the nLab (which would otherwise maybe have expanded this way on my personal web). And sure enough, after it had grown a little bit, it began to display real slow.
It also seems to me, that these pages display with no extraaordinary delay if they have displayed shortly before and weren’t edited since. So I suppose there is caching of information going on. While I suppose that means the harm to other readers is not too big (should there indeed be anyone trying to read these pages, that is…) but for me the editing process becomes a real pain: each time after submitting any edit, I have to wait literally minutes for the entry to re-appear.
I think I’ll follow your sugestion and contact Jacques about it at some point.
The pages are cached so that if there are no changes then you just get the cached copy (this is what led to the so-called “cache bug”). It certainly sounds as though there’s a correlation between the speed and the number of links. It’s certainly worth mentioning to Jacques.
Back on the original subject – could we add the redirects to the bottom of the edit box? It seems to be the nLab standard by now to have redirects at the bottom.
@ Mike +1
It’s easier to read the source that way. Although with sidebars and contents, it doesn’t matter as much now as it used to.
1 to 10 of 10