Additionally, trailing punctuation characters (except /) are not considered part of the link.
[Now that trailing punctuation is not part of the link, the ""-delimiters are rarely needed. They may still be useful for special circumstances.] In addition, any link (page, URL, image, or InterWiki) followed by two double-quote characters ("") will be terminated before the first quote, and both quote characters will be removed. This allows links to blend seamlessly with other text, without requiring a complex tag-like behavior. See TextFormattingRules for more examples.
...I'll try to edit the stuff below later. (Perhaps it should split into several topics.)
Note: A point after a Wikiname invalidates the link, when the Wikiname is intended without a trailing point. It's the second time that I had to insert a blank before the point to get a reasonable link-target. ;-) -- fp
This is [was] intentional. The InterWiki link pattern allows any characters except whitespace in the target link. I have considered changing the link code to remove trailing punctuation, since the current behavior is often annoying. Any other opinions? --CliffordAdams
The SubPage slash syntax is good because we are familiar with it from filenames. If we use it for InterWiki links too, then we get the sense of one big multi-levelled wiki. Also, because the SubPage notion has a fine granularity, we get a sense of growth by small increments. I think that's how communities should be - growing smoothly rather than splitting in two like ameoba. -- DaveHarris
I think there is some value in clearly separating external links--they aren't the same as local pages. (Different guidelines, link patterns, and copyright policies are some of the bigger differences.) Smooth growth is an important idea for the ViewPoint project, however. --CliffordAdams
Why can't guidelines and copyright policies vary from page to page within a single site? That they don't is just a consequence of the smallness of current Wikis. -- DaveHarris
One of the big problems with InterWiki links is that different Wikis have different LinkPatterns. This made Cliff write UseModWiki to gobble up everything up to the next whitespace, but some Wiki's make links between square brackets ala "[This is a link]" which breaks this. Another possibility is to store with each InterWiki entry its associated LinkPattern and match accordingly. Then we don't have these problems. This is, however, harder to implement.
Using the SubPage slash won't work, then. On the other hand, you could just impose the restriction: "Either you play by the rules, or you don't interlink."
If might be nicer if the foreign Wiki name didn't show up in the text output because it ruins the natural flow of sentences.
Finally, if you don't like the colon or slash, how about a Smalltalk styled ">>" as in "WikiWiki>>LinkPattern"? -- SunirShah <i>[The > character is a pain to work with in HTML-based systems, largely because of the different encoding/escaping systems in common use (%xx escapes vs. > for instance).]
I think it is important to allow spaces in page names. My current preference is for almost anything in square brackets to be a page name, so that I could sign my name [Dave Harris]. An alternative is to turn some other character, such as underlines or + signs, into spaces. (That is roughly what happens with UrlEncoding?.) -- DaveHarris
[Sunir says some Wiki's make links between square brackets ala "[This is a link]"]
I do not like the page name/link differences in those wikis. Swiki-clones usually use numbered pages, and ZWiki uses the proper %20 substitution in the links. Both choices yeild ugly URLs. While I'm being negative (;-), I also don't like the ability to set the link text--I like to know what I'm clicking on, especially for links that leave the local site. --CliffordAdams
Whether they use numbered pages is orthogonal to what the link pattern is. You can use UrlEncoding? in Urls, like Dave+Harris (which is why I mentioned plus-signs in my earlier comment). I don't think this is too ugly.
I agree setting the link text should be discouraged. Although it is tempting to allow external URLs to be displayed as  (with the number assigned by the system, of course), because they can be so long and ugly.
Bold and italic would be <B> and <I>. I suspect this will be more obvious than triple-single-quote-marks, even for people who don't know HTML or XML. -- DaveHarris [One can now use the HTML <B> and <I> tags for bold and italic on this wiki.]
I think WysiwygWikis? are most userfriendly. The underlying link coding structure should be made compliant with the Web standard. For user convenience I suggest a drag and link mechanism, working like this: dragging partially over a text, all touched words form the name of a link. A helper selection box offers a list of external Wikiforums, from which to select. The standard link under the hood is then generated accordingly. -- fp
There was a nice idea in WardsWiki to improve AccidentalLinking. Search for (say) three adjacent words (not necessarily separated by spaces) and suggest all existing permutations in the Wiki Data Base. Of course good style would suggest to use wordsequences, with each word as significant as possible. (Noise words like "the, it, etc. .." could be filtered out by software.)
By the way Wiki:WysiwygWikiWithForteForJava could be a quick front-end solution for a bunch of different Wikis.
In looking at general-purpose web linking vs. intra- and inter-wiki linking, I'd like to catalog the latter two's requirements beyond what is available in HTML/XHTML for the purposes of an [InterWikiMarkupLanguage]. If one looks at the HTML 4 spec's [description] for the <a> element, there's many more attributes available than are typically used; a lot can be ignored. Now, the 'rel' and 'rev' attributes are pretty useful in that they provide potential containers for inbound and outbound link semantics, usually called link roles. Beyond link roles, what other things would be necessary to capture in a general purpose intra-/inter-wiki link that currently can't be supported? (E.g., things like link IDs can't use the 'id' attribute on <a> since that is the ID of the link element, not of the link itself.) -- MurrayAltheim (PS. it occurs to me after posting that this question might be better asked in a different place. If so, please feel free to redirect)