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.
I see from the Sandbox that Toby has been experimenting with ways to get forward slashes in names. Whatever his method is, it seems to work within the n-Lab.
However, it doesn't (necessarily) work externally. My RSS feed reader showed that someone had created a page called 'Sandbox/test' but when I clicked on it then I got the 'Internal Error' page.
Did Toby's method involve escaping the slash? If so, the problem is that you want it to remain escaped right until the end. However, when stuff goes through scripts and readers and gets passed from one page to another then it tends to get decoded and re-encoded many times. So it's hard to predict how many times you need to escape the escaping - if it's even possible to do that at all.
We shouldn't overlook Murphy's Law when designing schemes like the naming scheme. Sticking to the basic character set makes the system a whole lot more robust (quite apart from Google rankings).
But what you didn't see that I wasn't able to produce Sandbox/test.png:file; you didn't see that, because it utterly refused to let me save that! So there is a problem. And I agree that it's probably simpler just to use the basic character set in the filenames of uploaded pictures; avoiding potential bugs in things like RSS feeds being one reason.
I think the problem with non-standard characters is that we (rather, the 'lab) don't have control over anything once it goes off site. If we care about that, then we ought to make sure that anything that could go off-site should be "clean". To a browser, there is no difference between "/" and "%2F" and some scripts or browsers may encode everything that isn't in the standard character set just to be on the safe side.
But it seems we're in agreement on the practical outcome so there's probably nowt more to discuss.
/ and %2F; compare these URLs: http://ncatlab.org/nlab/show/Sandbox/test and http://ncatlab.org/nlab/show/Sandbox%2Ftest.But it is true that many programs have bugs with this (simply Google “bug 2f” to see some), so we should probably avoid it.
In my feed reader, I get
'(?,1)-category of (?,1)-categories'
I'd like to keep links simple.
But you make a good point: even though we can reasonably expect people to install some fonts to read the math in the Lab itself, it's a bit much to expect people to install them for anything that might receive material about the lab, especially automatically generated material like this that hasn't even had a human decide that it matters.
Can we have a list of exactly what gets broken by forward slashes in names? Are they bugs in Instiki (the comment about Sandbox/test.png:file seems to indicate that) or bugs in people's feed readers, and how many and which feed readers have this problem? I use Google Reader and it has no trouble.
Okay, so how about for a general policy:
Titles should be drawn from characters that can be typed on a keyboard without tampering (though on my keyboard that includes ø å, and æ).
Forward slashes are, however, Not Good. Even if we figure out how to code them properly in every situation then I think that because they are used for directory separators it gives the wrong impression about the structure of the wiki. We can use dashes to give the information that we want (namely, that there is a dependency) without risking a false impression (that there are "directories" and "files" and one file is only in one directory).
There are a few other "loaded" symbols, though. The dollar sign springs to mind. If I see a dollar sign in a page URL then I'm going to think that the person tried to type in some TeX but didn't know how to get it in the URL. I'm not advocating a complete ban, but maybe a "greylist" (or even a gray one).
I would vote for using something other than a dash for dependencies; dashes are not visually distinct enough for me. Also dashes appear elsewhere in page names, like "n-category." What about something like "page#history"?
I think discouraging $s, along with /s and probably \s, is fine.
We should discourage dollar signs in the sense of putting TeX into page names. If one comes naturally, then we could allow it, although this seems very unlikely given our subject matter. (There's a reason that Knuth decided that the dollar sign was safe to use as a math delimiter!)<p >I think that using a hash is just as likely as using a slash to give a ‘false impression’ about the structure of the wiki. I'm not sure that such false impressions matter, really, but they are the sort of thing that one would expect to break scripts.<p >As for the hyphen method described <a href="http://www.math.ntnu.no/~stacey/Vanilla/nForum/comments.php?DiscussionID=16&page=1#Item_48" >here</a>, this is distinguished from <a href="https://ncatlab.org/nlab/show/n-category">n-category</a> by the spaces; is that visually distinct enough?</p></p>
So it seems that the one thing that we should settle on here is how to express hierarchy of pages. Let's take a hypothetical example. Suppose I have a main page, say Froelicher spaces, and another page, say Hausdorff Froelicher spaces, that is indisputably a sub-page of the main page. I want to rename the sub-page something like: "Froelicher spaces ? Hausdorff", except that we've yet to decide what the question mark should be.
Here's another reason to avoid /, which also holds for #. Sometimes, just sometimes, I actually have to type a URL into the location bar on my browser. If I see http://ncatlab.org/nlab/show/Exploding+a+Category/history then that is what I will type, and get an internal error. Similarly with #s. Then, being the superficial guy I am, I'll get bored and go to Wikipedia instead.
If a dash with spaces is not clear enough, how about a double dash? "Froelicher spaces -- Hausdorff" seems fairly clear to me. I don't think that one would encounter a double dash in the "normal" run of things and with the spaces it does mark it out.
I never see http://ncatlab.org/nlab/show/Exploding+a+Category/history; my location bar shows http://ncatlab.org/nlab/show/Exploding+a+Category%2Fhistory. But you have a reasonable point.
With a little bit of experimentation, it seems as though the following non-alphanumeric characters can be typed directly in a URL:
! - _ \ * ~ ` ^ < > { }
@ $ ;
For me, Firefox displays all of these except the last three as themselves, and URL-escapes @ $ and ; by default, but if I type @ $ or ; directly then the URL still works.
Spaces around a single dash don't really make it visually distinct enough for me. A double dash might be okay. But what about something like "Exploding a Category > history"?
I've started implementing this on old ‘history’ pages. (More recent ones have been doing this for a while.)
But I'm going to see about writing a script to help me.
Remember that your script can work on the database itself which might be more reliable than working over http (maybe you remembered this already).
Done.
1 to 18 of 18