Several of us on the English Wiktionary are trying to resolve an issue and we could use some advice. (This is my frist post to this list, so apologies if I restate the obvious.) What's the best way to rig it up so that when you interlink to [[Foo]] on a caseful Wiki project, where "Foo" does not exist but "foo" does, to give the user a convenient shortcut to [[foo]]? Background: unlike most Mediawiki projects, the English Wiktionary honors case in the first character of article titles . (That is, I assume it has $wgCapitalLinks set to false.) This can cause problems with links to Wiktionary from other Mediawiki projects, and from the outside world (such as Wiktionary mirrors), since those incoming links are often to the capitalized version of a word, on the assumption that Wiktionary works like Wikipedia. (As, in fact, it once did.) Even since it switched over to casefulness, Wiktionary has evidently been trying to "solve" this problem by having an explicit, capitalized redirect in place for every lower-case entry. But that's clearly a huge nuisance and waste of time. Instead, some of us have been thinking it Would Be Nice if we could adjust the behavior on a missing page ("broken link") slightly. Instead of saying "Wiktionary does not have an entry for this word yet", in the case where Wiktionary does have an alternate-case version of the word, perhaps it should display an explicit "Did you mean?" link right up front (along with but ahead of the other search and create options). There are probably several ways of approaching this. I've already implemented one way, but I'm curious as to this list's opinion of the most appropriate approach. 1. I added some code (in a test wiki) to getContent() in Article.php to optionally display "Did you mean ___?" before displaying 'noarticletext', in the case where an alternate-case version does exist. In some ways this is the right approach, but it's awkward, because it has to prepend its text to the 'noarticletext' boilerplate. Someone editing MediaWiki:noarticletext would reasonably expect to see the "Did you mean?" text there, and might want to integrate it with the rest of the boilerplate, but wouldn't be able to. 2. It might also be possible to implement the test and optional text right there in 'noarticletext', using the new in-line conditional expressions. (But I'm not sure they're quite powerful enough.) 3. Arguably, this is a problem that doesn't need solving, and the typical, already-existing "You can search for this article in Wiktionary" link should suffice. 4. Arguably, this is a problem that does need solving, but in an even more general case, whenever there are other kinds of near matches, that aren't appropriate to handle with redirects or with the automatic case mapping that happens when $wgCapitalLinks is on. (Someone might ask, "Why provide an interactive question and a link; why not just quietly redirect?" But that defeats the purpose of being caseful and makes it difficult or impossible to create a second entry with the other case. If you're going to redirect in this case, you might as well turn on $wgCapitalLinks and be done with it.) Another way of thinking of this is that the proposed "Did you mean?" question is a little like a disambiguation page, in a case where user confirmation is required (i.e. in cases where a more implicit Wiki redirect or 302 redirect is not appropriate). For all I know this issue has been discussed already and some consensus reached. But does anyone have any advice or suggestions? Thanks.

I had written: Brion replied: Thanks. I was about to say, "but the new in-line conditional expressions don't do string functions like lowercasifying things", but shows what I know. Minh Nguyen proposed: Oh! Splendid! I didn't know about those. I'll install the parser in my test wiki, and try this out. Thanks very much. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

(Someone might ask, "Why provide an interactive question and a link; why not just quietly redirect?" But that defeats the purpose of being caseful and makes it difficult or impossible to create a second entry with the other case. If you're going to redirect in this case, you might as well turn on $wgCapitalLinks and be done with it.)

I cannot follow this line of reasoning. The purpose of "being caseful", as you call it, is to have (1) correct article titles, and (2) the potential capability of having separate entries differing only in their capitalisation.

Elliott Cable wrote: #if is brand new; see http://meta.wikimedia.org/wiki/ParserFunctions for info. I haven't found {lcfirst} yet, but I expect it'll be pretty obvious once I start looking.

Minh Nguyen proposed: With a bit of tweaking (see below), this seems to work perfectly. If you're curious, see http://en.wiktionary.org/wiki/cypriot http://en.wiktionary.org/wiki/Tamper http://en.wiktionary.org/wiki/nowordatall

At some point, once Tim recovers from (or becomes inured to) his horror at sending us down this slippery slope in this hell-bent handbasket, we can think about introducing a proper built-in {{exists:}} operator, to eliminate the need for the bizarre compare-the-substitution-to-the-redlink hack. (Though I *am* appreciative of whoever devised it...)

<snip/> At some point, once Tim recovers from (or becomes inured to) his horror at sending us down this slippery slope in this hell-bent handbasket, we can think about introducing a proper built-in {{exists:}} operator, to eliminate the need for the bizarre compare-the-substitution-to-the-redlink hack. (Though I *am* appreciative of whoever devised it...)

Phil Boswell wrote: This is all very welcome. Does it or can it extend to words that differ only by the presence, absence or variation of diacritics? A dictionary that aspires to include all words in all languages faces some significant challenges in making these terms accessible to people who have no idea about how to enter words with diacritics in the search box. Some _may_ be able to handle letters that fall within ISO 8859-1, but even they will have significant difficulties when things get a little more exotic. Ec _______________________________________________ Wikitech-l mailing list Wikitech-l(a)wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l