Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics comma complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration finite foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
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.
    • 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
    Looks like your feed reader needs more fonts! (^_^)

    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="https://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.