Auto Link

Auto Link lets any title be used for a page, not limited to the usual CamelCase or similar. Unlike FreeLinks, one doesn’t need to wrap a reference to the page in link brackets; instead, the wiki remembers what pages it contains, and makes as many links as it can.

Some means to make a page with the right name in the first place must, of course, be found.

Possibilities

• Normal readers see all the automatically generated links.
• Only editors see the automatically generated links (“suggestions”). Normal readers only see links on words the editors manually linkify.
• Instead of making words or phrases into clickable links, let them merely allude to other pages, then add all the links alluded to at the end of the section (just before the next heading) or at the end of the page. (Even if a word is used many times, it only needs to be put in that list once). (Does this help reduce the MeatBall:AvoidClutterLinks potential problem?)

Implementations

GeboGebo has it, using fast database indexes on display time. My experiences are very positive with it. The links are displayed in a different color than normal links. Words are checked case-insensitive. Depending on your wiki page names, it sometimes happens, that AutoLink detects words correctly by syntax but not by semantic. This is annoying then.

As far as I know, as of 2007, all implementations so far only link single words (not phrases). This means that the autolink never links to pages with spaces in their names. So people either must remove spaces in both the text and the page names ( either replace with underscore or use Wiki:CamelCase ) to trick the “link single word” parser into thinking it’s a single word. Or else they must use some different syntax to manually mark-up text to force it to link to pages with spaces in their names.

Activity

MeatBall:UbikWiki tried this out, but that engine is now defunct.

OddMuse: Link All Words extension “implements the GaGaParser for Oddmuse”.

In consideration, by PhpWiki.

Terminology

“link single word”: The parser breaks up the text into individual words. The parser breaks the text on whitespace characters and a few other patterns like “--” that separate words. The parser trims those words (removing whitespace from the beginning and end; removing “.” periods from words that happen to occur at the end of sentences, forcing lowercase, etc.) Those trimmed words are then considered candidate page titles. Unfortunately, page titles with spaces in them are never recognized in a “link single word” parser.

With “link single word”, either

• a. every single word is linked. (This does not require searching the list of page titles, and so is very fast). Or
• b. only words that exist in the list of page titles are linked. (This is less confusing to the user, but requires some other mechanism to create a new page).

“link phrases”: The parser looks for phrases of one or more words as candidate page titles. Only phrases that exist in the list of page titles are linked. This allows page titles with spaces in them to be automatically linked to.

Problems

Problems with both single-word and phrase-oriented parsers:

• Nobody, scanning the source text in an edit page, will be able to identify what will link and what won’t, without knowing the relevant wiki intimately.

Problems with phrase-oriented parsers:

• Typically, links shouldn’t start or end in the middle of a word. “link rot” shouldn’t match in “blink rotundly”.
• Whitespace will be used arbitrarily, and a space in a link should match a carriage return in text (in case the line has hard-wrapped).
• Should two consecutive words always link to the corresponding two-word page, or should some (or any) punctuation between them block the link? (Should “Interesting link. Rot is, I think, unlikely.” link to pages titled “link rot” and “think unlikely”?) If punctuation always blocks the link, what to do when someone wants to create a page with a title that includes punctuation?

Link interference with phrase-oriented parsers:

• Long links, like “problems in matrimony”, should be favored over short ones it contains, like “problems” or “matrimony”
• When two phrases overlap, what should we do? (This problem doesn’t occur in “link single word” parsers). For example, imagine that the text contains the phrase “small group organization”, and we have pages named “small group” and “group organization” (but not “small group organization”). Should we only link “small group” ? Only link “group organization” (because it is longer)?

With “links at the end of the section”, perhaps *all* possible phrases should be mentioned in that list, even if they overlap or if one is contained in the other.

Technical details

Most of these technical details are pure Wiki:PrematureOptimization. Don’t worry about them in the first prototype – it’s possible that they will never be necessary, in the same way that Wiki:StaticHtml turned out to be an unnecessary premature optimization.

• I speculate that large sites really will slow down a lot when using AutoLink: after all, every part of the text needs to be matched against every single page.
• Using this at runtime would be bad resource-wise. However, running it at page creation (and at intervals afterward) would give most of the benefit, while costing much less. I suggest having a button in the “create page” page, that says “linkify” or something. That button will search through and add links as needed. That would give most of the benefit, while not causing the wiki to start acting up.

See Also

FreeLink, MeatBall:GaGaParser, MeatBall:AutoLink, CommunityWiki:AutoLink

Contributors

ChrisPurcell DavidCary

CategoryFeature CategoryLinking