I'm starting a wiki for Information Architects, and I expect there to be a number of two or three letter acronyms which will get used a s prefix in many cases. IA, UX, ID, UCD, etc. I'm not real keen on suggesting link patterns like IaDeliverables?. Unfortunately IAdeliverables isn't a link pattern, and in any case the word splitting expansion now makes no sense (I Adeliverables). Oh bother, said Pooh.
What would be the basic change to the link pattern grep to allow for AAzzzz as a valid link pattern, while still allowing AzA?, AzAz?, but not Az?
Thus combining:
[A-Z][A-Z]+[A-Za-z]* or [A-Z]+[a-z]+[A-Z]+[A-Za-z]* ...
then this should work:
[A-Z]+[a-z]*[A-Z]+[A-Za-z]*
[... off to do testing ...]
it works!
-- EricScheid
Unfortunately that now breaks ISBN 1234567980 (alternate, search) links :-(
Any suggestions?
-- EricScheid
What is the problem? (Trying to help without installing UseMod . . .) -- AlexSchroeder
Update - the problem was that ISBN was being recognised as a LinkPattern, and thus the magical arrangement of ISBN followed-by-ten-digits was being interrupted with the LinkPattern html link. Problem solved by moving some lines about in the module so that ISBN (and RFC) links get grepped before the LinkPatterns. -- EricScheid (who knows just enough perl to get into trouble)
I suggest not changing the code (you will be doomed to trace Cliff's changes). The regexp you suggest allows for zero non-capitalized letters. Therefore try this (which forces a non-capital letter at the end):
[A-Z]+[a-z]*[A-Z]+[A-Za-z]*[a-z]
Or this, which forces at least one non-capital letter before the end of the word:
[A-Z]+[a-z]*[A-Z]+[A-Za-z]*[a-z][A-Za-z]*
-- AlexSchroeder (who has enough Perl experience to not like it)
Hmmm ... forcing a non-caps on the end would prevent ACRONYMS, so it's not on the preferred list.
Hmmm #2 ... actually, my regexp does require at least two caps, that's what the "+" symbols mean, right?
As to the doom .. too late - I've made other little hacks which I'll feed back to Cliff sometime. It's now possible to specify a stylesheet url in the user prefs, and got the ScriptLink? to properly url-encode the ampersands which means the pages validate now. -- EricScheid
Any particular reason for not allowing leading lowercase chars (ala aLinkPattern)? I just made that minor change to a copy of usemod for use here at work (our perl module namespace has leading lowercase chars - otherwise our names are pretty good CamelCase citizens). FYI the resulting pattern is [a-z]*[A-Z]+[a-z]+[A-Z][A-Za-z]*. --ErikDeBill
I'll not hit a performance barrier, given the incredibly low traffic/overpowered box it's running on, but I can see how a WikiFarm might view things differently. In my case at least I think the "Free Links" issue won't trip us up - and shouldn't it be possible to change the free link handling code to check for both? It's not an issue for me, but in theory? Of course, I've always considered free links as a last resort when you can't get something to work w/ normal WikiNames. The notion of using them for otherwise good WikiNames seems rather alien. --ErikDeBill
I didn't like fooLinkPattern because it made talking about programs really aggravating. (Think about variable names.) It also violates the PrincipleOfLeastAstonishment?. -- SunirShah
A common naming convention is like CamelCase, but with the first letter lowercase. For example, imageDecoderPool. Java programs often have this.
I attempted to fix the fooLinkPattern problem with the new version of the script. I haven't tested it enough, though. Is it showing up? -- SunirShah
My personal recommendation for new sites is to turn on the "Free Links" feature which allows links like [[link pattern suggestions]]. Pseudo-automatic linking (requiring users to use the CamelCase convention) seems to be an advantage for those who have invested a lot of time writing with CamelCase, but it appears strange to others who are not used to CamelCase. (Meatball mostly caters to people used to Ward's C2 Wiki, so it is likely to remain CamelCase-only for the near future.) --CliffordAdams
Free links are nice and a tremendous advantage as opposed to CamelCase links. Free links do, however, in their current form encourage (or at least not discourage) very long page titles. On WikiPedia, this is not much of a problem, because Wikipedia is an encyclopedia and often wants proper, long titles; long term linkability is not as problematic as long term readability. However, even this is limited to the encyclopedia articles, on the articles in the Wikipedia: namespace (used for help, policy discussions etc.), the system is breaking down. You have a huge amount of pages with titles like "How does one edit a page" or "Pages needing attention". Now remember that you have to type "Wikipedia:" before a linkname into that namespace, so you get monster-links like "Wikipedia:How does one edit a page". Not very helpful. And then they do this thing where they turn off the namespace prefix because it's ugly and confusing, so they use a pipe to specify an alternate link name. Then you get "Wikipedia:How does one edit a page|How does one edit a page". This is the ugliest form of free links with namespaces -- ugly not so much for the user, but for the editor. A distinction which is, of course, only marginally useful in a true wiki.
A better long term solution, which I have discussed with Sunir (who seems to be fed up with LinkPatterns? for the next 10^39 years or so), is to use smart underscores. With that I mean a pattern that is very simple to type for short links, but annoying for long links.
That way you automatically encourage short links, while keeping correct word rendering possible (the big, big flaw of CamelCase). As for linking to pages using a different link title than the link name, I suggest this syntax:
By using the -> notation, we give the reader of the wikisource a visual clue, as opposed to the pipe, which gives no clue as to the direction (what is the link title, what the name of the linked to page?). We should keep the syntax as simple as reasonably possible, so we should require the leading underscore only if we have no other hint as to what might be meant. So when a "->" is in the middle of two words, we don't need any other indicator.
The underscore has the important advantage of also looking visually similar to underlining, which is of course forever identified with links. --ErikMoeller
This is in addition to CamelCase (rather than replacing it)? I think it's a good idea, but "free links" should be kept in, too; often it's convenient to copy/paste a link name as is into a free link. -- BayleShanks