## 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.

• CommentRowNumber1.
• CommentAuthorAndrew Stacey
• CommentTimeMay 26th 2009

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).

• CommentRowNumber2.
• CommentAuthorUrs
• CommentTimeMay 26th 2009
Yes, but it woudn't hurt to have both versions for entries of the kind omega-anything infinity-something. One version being a redirect to the other. One for the search engine and for typeability, the other for in-line readability.

And is it inconceivable that one fine day we'll be able to tweak the instike software to tell it to automatically redirect along redirect entries?
• CommentRowNumber3.
• CommentAuthorTobyBartels
• CommentTimeMay 27th 2009
My method involved nothing special, no escaping or anything. An external link should work fine if it goes to the page's actual URI: http://ncatlab.org/nlab/show/Sandbox%2Ftest. If the RSS feed sends you to the wrong URI, then this is a bug in the RSS feed that Jacques will probably fix if we tell him about it.

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.

• CommentRowNumber4.
• CommentAuthorTobyBartels
• CommentTimeMay 27th 2009
Note to all readers: Some previous discussion of this issue took place on the Café starting here.
• CommentRowNumber5.
• CommentAuthorAndrew Stacey
• CommentTimeMay 27th 2009

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.

• CommentRowNumber6.
• CommentAuthorTobyBartels
• CommentTimeMay 27th 2009
There is a difference between / 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.

• CommentRowNumber7.
• CommentAuthorAndrew Stacey
• CommentTimeJun 5th 2009

In my feed reader, I get

'(?,1)-category of (?,1)-categories'

I'd like to keep links simple.

• CommentRowNumber8.
• CommentAuthorTobyBartels
• CommentTimeJun 7th 2009

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.

• CommentRowNumber9.
• CommentAuthorMike Shulman
• CommentTimeJun 7th 2009

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.

• CommentRowNumber10.
• CommentAuthorAndrew Stacey
• CommentTimeJun 8th 2009
• (edited Jun 8th 2009)

Okay, so how about for a general policy:

1. Titles should be drawn from characters that can be typed on a keyboard without tampering (though on my keyboard that includes ø å, and æ).

2. 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).

• CommentRowNumber11.
• CommentAuthorMike Shulman
• CommentTimeJun 8th 2009

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. • CommentRowNumber12. • CommentAuthorTobyBartels • CommentTimeJun 9th 2009 • (edited Jun 9th 2009) This comment is invalid XML; displaying source. 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="http://ncatlab.org/nlab/show/n-category">n-category</a> by the spaces; is that visually distinct enough?</p></p> • CommentRowNumber13. • CommentAuthorAndrew Stacey • CommentTimeJun 9th 2009 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. • CommentRowNumber14. • CommentAuthorMike Shulman • CommentTimeJun 9th 2009 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"?

• CommentRowNumber15.
• CommentAuthorTobyBartels
• CommentTimeJun 9th 2009
That's kind of nice, Mike. And then the content of that page could be simply ‘< Exploding a Category’ (or ‘< category of elements’, as appropriate). Compare the look of MediaWiki subpages (example).
• CommentRowNumber16.
• CommentAuthorTobyBartels
• CommentTimeDec 12th 2009

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.

• CommentRowNumber17.
• CommentAuthorAndrew Stacey
• CommentTimeDec 12th 2009

Remember that your script can work on the database itself which might be more reliable than working over http (maybe you remembered this already).

• CommentRowNumber18.
• CommentAuthorTobyBartels
• CommentTimeDec 17th 2009

Done.