CamelCaseAlternatives

MeatballWiki | RecentChanges | Random Page | Indices | Categories

CamelCase is the traditional way for recognition and automatical linking of wiki pages.

it is not very compatible with regular spelling (some people distaste wiki for this, projects like WikiPedia avoid it partly for that reason)
it is not compatible with foreign languages using different glyphs without the concept of upper and lower case characters. E. g. there won't be CamelCase Chinese wiki pages.
beyond ASCII, with Unicode, CamelCase patterns quickly become a PITA, because there is no simple way to specify uppercase characters with regular expressions using Unicode (utf-8).

Alternatives for automatic linking:

use the "SPACING UNDERSCORE" 0x5E ASCII/Unicode character as a word separator. LizzyWiki (AlainDesilets?) has used it successfully with small children in educational environments. It even simplifies the regular expressions (char+_anychar+).

While I'm a big fan of CamelCase pagenames personally, I doubt that it was a good design decision. -- HelmutLeitner

If a (defined) separator character is used to trigger URL generation, then please make it an environment variable.

Many good arguments have been presented supporting alternative markup syntaxes that can be used to trigger the creation of a URL. Since wiki technologies are relatively simply and small enough to be within the scope of the activity of a single developer, it is certain that many different approaches are inevitable. In order to respect the needs of the users of wiki software, we should at least advocate that the use of any characters defined as the separator of the parts of a CamelCase word, be implement as a variable that can set within the wiki.

It might be even better to go a bit further an allow such a definition to be a small table of equivalents, since this could accomodate a user's desire to have one copy of the raw text that can be posted to several different environments. That would at least lower some of the barriers to participating in multiple wikis.

-- HansWobbe

ProWiki has this configurable, but I hope it isn't used. I'm not aware of so many good alternatives for automatic linking. If there are, please add them to the list. The underscore is already in the "WikiPedia standard", not for automatic linking, but as a replacement character for the "space character" within page names. So it somewhat bridges the gap to WikiPedia (other separator characters would increase the gap). It is also the only (older C-Style) alternative to word separation within identifiers in programming. That's perhaps one of the psychological reasons it wasn't chosen by the programmer Ward. -- HelmutLeitner

Why do you hope it isn't used?

I certainly agree that there aren't a lot of good alternatives. After all, most of the non-alphanumeric characters have been adopted for some use or other, with many 'colliding' uses resulting over the years since I too started programming in C. I have, however, become more aware of the importance of Scope and I now find it relatively easy to distinguish the '_' (Agreed, as a "space" @ wp - I was carelessly unfocused) that I need to use at wikipedia from the '_' characters in C.

However, when I am working within wikis, I strive to keep the markup as common as possible, since there is a growing probability that I will end up posting the same text to multiple sites. Hence. my 'request' was nothing more than an effort to nudge wiki developers a bit towards the goal of 'as common a markup as possible'. I do know this may not be ever be achievable (especially given the current state evident in WikiMarkupStandard) but I am remain optimistic that small nudges in that direction will be better than proliferating a TowerOfBabel?, in spite of the many good reasons support 'diversification'.

-- HansWobbe

I don't quite understand you. At WikiSym there will be a interwiki workshop by BayleShanks and I assume that standardization will be one of the topics. If I were to make a suggestion then I would suggest CamelCase and underscore as standards for automatic links based on link patterns, and search on a standard markup for free links and labeled links. This would improve the situation considerably for contributors to multiple sites. I think you argue for that. On the other side, making the separator character a variable would counter that and make the situation more complex. You also argue for that? How does this fit together? -- HelmutLeitner

Helmut:

You are quite correct in seing some contradiction between advocating a Standard approach and advocating that the metaCharacter be a variable. There are a great many obvious reasons that the Standard approach is a preferred solution. Unfortunately, the relative 'youth' of wikis means that the current situation is one in which Standards are unlikely to gain universal acceptance during the rest of this decade. Hence, given that;

There will undoubtedly be many variations introduced and supported by the large number of wiki developers, and
For each developer, there are likely to be a considerable number of Sites that are hosted by many other Owners, for use by various Communities,

I thought that asking developers to make the selection of such a character a configuration option, would at least allow some Communities to eventually converge on whatever is found to be the most common usage.

There are, of course, other options and forces that will come into play to help improve the current situation, so this is not a very important item at all. I posted my plea simply because I know that it is trivial to implement this at the start of a development, but can be very difficult to 'retro-fit'.

Regards -- HansWobbe

At MoinMoin wiki, we also thought about using _ as link markup and also developped some other ideas that might give some nice effects when being combined:

One annoyance of using _ (as well as CamelCase) as link markup is that it triggers unwanted links sometimes and you have to use additional markup (and additional edits if you didn't care) for getting rid of those links.

When is a link unwanted? It is usually unwanted if there is no such page! E.g. if you talked about that C function my_function and there is no page my_function in the wiki. So a working solution would be to link ONLY if the pagename exists (when using a dict / hash table lookup, this is O(1) for the lookup, no matter how many pages you have). This would also work for the case, that initially the link is unwanted, but later, the wiki is used for documenting functions and then my_function should link to the then existing page my_function.

The usage of _ instead of spaces in links is nice for that, because you just have to split the text at whitespace in that case. A word like "Thomas_Waldmann" would (maybe) get rendered as "Thomas Waldmann", but treated like a single word and the lookup for the corresponding page is easy.

Of course one needs a mechanism to make new pages. In my experimental code I just used an additional rendering mode "linkall" that renders a page with every word as a link. So you can easily click on the words you want to make pages for. Another possibility is of course to have some form field for creating a new page, but in that case you would have to type the pagename again (or c&p it).

A problem of this approach is when you have common words as existing pages in your wiki. E.g. you could have a page about the UNIX "make" tool in your wiki (pagename "make"), but you definitely don't want every "make" you type to link to that page. This can be handled by either having some "don't link to me" attribute per page or just a global blacklist page with common words that should not get linked. If you really want to link to page make, you can use the usual free link (or, if the wiki has no free link markup, the interwiki style Self:make) markup.

I already did experiment with such stuff a while ago, you maybe can find it under the working name of "gaga" and "gaga2" in the MoinMoin wiki (GaGaParser). gaga was a rather basic (and fast!) thing using a dict lookup (and relying on words being separated by whitespace), gaga2 was a more complex thing using a TRIE data structure to even find whitespace separated stuff to link (e.g. you could write a b c somewhere and it would link if there was a page named "a b c"). Of course, this used quite some more CPU time.

-- ThomasWaldmann

CamelCase is, in my opinion, a totally awkward choice, insufficient for many reasons, the most important being that single words cannot be linked nicely (Wikipedia is called Wikipedia, not WikiPedia nor WikIpEdia?), and that neither can abbreviations (HtMl?? CsS?? UniCef?? UsA?? What about C?). Being over thirty years old, I got used to what you could call "encyclopedia syntax" in my early days, which I implemented in a somewhat experimental wiki. It works nicely. Linking to an article about ->Wikipedia is as easy as to one about ->C or just anything other word.

Similarly you might want to link to a page named "CSS" using "Stylesheet" as text:

  Use a stylesheet (->CSS) to format your document.

will produce something like

  Use a <a href="/wiki/CSS">stylesheet</a> to format your document.

This is especially useful with conjugated or inflected words (write stylesheets, link to stylesheet). I suggest allowing link text spanning multiple words (write "style sheets", link to stylesheet), which I've also implementend and which also works nicely.

  Use "style sheets" (->CSS) for document formatting.

will produce something like

  Use <a href="/wiki/CSS">style sheets</a> for document formatting.

This way, even the plain text is easily readable. No ambiguities, no restrictions that had struck me so far. What do you think?

-- TimoBezjak

CamelCaseAlternatives

Discussion