Extension talk:LinkTitles/Archive

This is a great extension, and is perfect for what I'm using. There is one minor issue I've found, however. When I'm using my template to auto-generate categories, and one of the names of the categories also is a link, it puts a link in the category syntax and breaks the creation of the categories. (I'm not sure if this happens if the category is manually created, I have not actually had the chance to look at it. Here is what I'm talking about, in case what I'm saying isn't clear.

Template: ]

On page: Test=Blue When rendered: Group]]]

I have fixed this for now by just black-listing the pages so they don't auto-link, but I would like to see an exclusion for things in a Category bracket. (I know, it can get tricky to do, but it's a suggestion) ^.^

--Taintedsnowqueen (talk) 20:12, 8 October 2012 (UTC)


 * Well if I understand you correctly, the problem is that the extension parses template parameters. I've quickly added a new option "$wgLinkTitlesSkipTemplates" that lets you control this behavior. Please see the main extension page to read more about it. The downside is that this setting will prevent all template contents from being automatically linked; but there is currently no other way that I can think of how to accomplish what you want. Is it what you want? -- Bovender (talk) 17:51, 9 October 2012 (UTC)

Case of linking
This is really hurting me. I hate to have to create a stub redirect for all of the items. I have lots of articles that have two words with both being capitalized. I would like the option to search exact, then case-insensitive. I know this would double the load, but it would vastly help. - - - ''The extension performs a case-insensitive regexp search. Therefore, brackets may be added to words that have incorrect capitalization, causing 'broken' wiki links to appear. You may want to create redirecting pages for these variants (to also handle different user inputs).'' -- Philipsaj


 * Hi, I've added a new option $wgLinkTitlesIgnoreCase and published version 1.7.0, but I'm afraid there will be no solution that satisfies all needs. The problem is that all articles in a Wiki begin with a capital letter, thus, if you had an article "Snow" and set $wgLinkTitlesIgnoreCase to false (meaning an exact match is required to link a title), none of the occurrences of the word "snow" in an English article about the winter would be linked. That's the reason why I had the extension perform a non-configurable case-insensitive search and replace in the first place. If I understand you correctly, you have lots of articles on "Snow Flakes" and "Snow Men". With case-insensitive linking, all occurrences of "snow flakes" and "snow men" would link to non-existing pages. I guess that's your problem, right? But how about writing "Snow Flakes" and "Snow Men" in your articles' texts in the first place? Would that not be more practical? -- Bovender (talk) 16:03, 22 January 2013 (UTC)


 * Thank you for your quick response and help! I appreciate your help and you understand the situation quite well in regards to the article titles and the challenge I face.  I'm sure my problem sounds easy and simplistic to fix, unfortunately I wish your suggestion for a fix was as easy to implement.  It is not just me doing the editing, but hundreds of people.  Many of which are extremely limited in their understanding of what they are doing, but they hold the knowledge we are trying to get recorded.  I think the only solution is a two part scan of the text.  I guess I need to find an extension that will scan my text and switch the case insensitive matches to the correct case that matches the article...  I really appreciate your extension and how it helps my wiki.  Thanks for your help.  -- Philipsaj 7:44, 23 January 2013 (CST)


 * Well I think I got it now. What is needed is automatic aliasing if the case of a page title and the case of its occurrence on the page do not match, so that link such as Snow ball are generated. I've added this functionality to the version 1.8.1 which I uploaded just now. You are probably right that a two-pass algorithm would be more useful, so that case-sensitive matches are preferred. I'll think about this further. Bovender (talk) 17:48, 26 January 2013 (UTC)