Resolving this issue as Won't Implement is shameful. Perhaps the "little demand" is the silence of customers you will never have. Or perhaps it's because any Atlassian personnel that commented suggested all sorts of things, but never seemed to even ENTERTAIN the notion of fixing it. This is an annoying, productivity killing "attribute" of this product, and has ALWAYS needed fixing. Resolved, not.

After being open for many years and with little demand, I'm closing this issue as something we can't see ourselves implementing in the foreseeable future.

We had tried to workaround the issue by removing the false links from the rendered HTML Dom using jQuery. Below is a code one can embed in the page. Probably we can have this js code supported through a macro named nocamel

{html}
<script type="text/javascript" src="/download/attachments/59835554/jquery-1.2.6.js"></script>
<script type="text/javascript"> 
//The $ notation is used by DWR. So we rely on jQuery namespace only
jQuery.noConflict();          
jQuery(document).ready(function() {
   //The camel case links have class createlink. So fetch all such links and remove the html part and retain the text part
   jQuery("a.createlink").each(function(index){
    var text = jQuery(this).text();
    if(isValidCamelCase(text)){//Only filter where we have a camelcase text and not valid yet to be created link
       jQuery(this).after(text).remove();
    }
    return true;
   });
});

function isValidCamelCase(s){
	if(s == null || s.length == 1){
		return false;
	}
	
	if(s.indexOf(' ') != -1){
		return false;
	}

	//Check for case where valid link is being created like [Test123]
	var indexOfNonUpperCaseChar = -1;
	for(var i = 0; i < s.length; i++){
		var c = s.charAt(i);
		if(!isUpperCase(c)){
			indexOfNonUpperCaseChar = i;
			break;
		}
	}
	
	if(indexOfNonUpperCaseChar == -1){
	   return false;
	}
	
	var lowerCase = s.toLowerCase().substring(indexOfNonUpperCaseChar);
    var originalCase = s.substring(indexOfNonUpperCaseChar);
    if(originalCase == lowerCase){
	    return false;
    }
	return true;
}

function isUpperCase(char){
	return char >= 'A' && char <= 'Z'
}
</script>
{html}

Going on 3 years for this issue.

Hi. Our company does software engineering and uses Confluence extensively for engineering-related documents. In this environment, automatic CamelCase linking is inappropriate. We need more flexibility in controlling this feature per-page or ideally per-space.

Just received from one of my users....

Hi Garnet,
Would it be possible to turn off CamelCase linking in our Wiki space?
We're using this space for our engineers to add technical articles, and when writing out methods and class names, they won't want these to be turned into links.
Thanks!
Bonnie

We write a lot of content in our wiki that references code and so often uses camel case in situations where we don't want links to new pages created. Creating a link without using camel case is really easy, so I'd like to be able to turn autolinking from camel case off. In contrast, the syntax to turn the link off on a particular camel case word is a pain. A single symbol I could type at the beginning of the word to suppress the link would be a lot better, if you have a good character that hasn't been used yet. (Like the character on English keyboards above the Tab and to the left of the 1 key. I don't know what it's called.) But better would be a way to suppress camel case links for a whole page, or for all the children of a particular home page.

At work, our game designers like to use CamelCase to very quickly create links to information. Programmers writing documentation often use programming terms that happen to be in CamelCase. The resulting documents end up littered with spurious links that are not intended to be pages. It would be outstanding if programmers could turn this off for an entire page.

While we're asking for features, here are a couple of others to consider:

(a) Better TWiki alignment of CamelCase algorithm:
Confluence implements CamelCase mainly to help with people who are used to TWiki and other CamelCase wiki sites.
But the algorithms are different, and, frankly, I think in almost all cases TWiki got it right (e.g., dealing with words inside
punctuation, etc.)
If there were better compatibility (e.g., if the CamelCase option could allow for different regular expression patterns for recognizing camelcase), that would help.

(b) Setting (per-space) some 'no CamelCase words' – words that are used commonly but for which camel case autolinking isn't wanted.
That way, you don't have to

every occurrence of BigProduct, even though other CamelCase words might be.

(c) Making CamelCase a space or page option rather than a site option.

Changes to the twiki converter are not possible because the twiki conversion to Confluence has already been finished. Confluence and Twiki have slightly different rules as to what they CamelCase. It's easy to get it wrong, and we didn't want to risk adding quirks of a converter into the mix, so we left the CamelCase issue alone, and instead focused on fixing up issues where Confluence made a different choice about how much or how little to CamelCase......

Regardless of that, many of the users we've brought over are used to the noautolink available with twiki. Many users are used to doing things like:
<noautolink>
... lots of wiki content here....

• Use this calling point to initialize the debugger DebugInit(DebugStruct *S)
  • NOTE: Be sure the DebugMgrHelper dll is loaded first!
• Use this call to end the debugging session DebugDispose(DebugStruct *S)
  .... more wiki content here .....
  </noautolink>

Sprinkling at least five uses of

into that text is more difficult than things need to be. We need a

that can span many lines, even an entire page.