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.
Steve Summit wrote: [snip]
- 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.)
I'd say give this a shot, and if it doesn't look like it's going to work we could probably add a special-case on the software as 1)
-- brion vibber (brion @ pobox.com)
I had written:
- 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.)
Brion replied:
I'd say give this a shot, and if it doesn't look like it's going to work we could probably add a special-case on the software as 1)
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:
{{#ifeq: [[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]] | {{:{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}}} | | Did you mean '''[[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]]'''? }}
Oh! Splendid! I didn't know about those. I'll install the parser in my test wiki, and try this out. Thanks very much.
What are these {{#if things and lcfirst and all that? I don't remember these... am I totally missing something?
On May 9, 2006, at 8:29 PM, Steve Summit wrote:
I had written:
- 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.)
Brion replied:
I'd say give this a shot, and if it doesn't look like it's going to work we could probably add a special-case on the software as 1)
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:
{{#ifeq: [[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]] | {{:{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}}} | | Did you mean '''[[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]]'''? }}
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@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Elliott Cable wrote:
What are these {{#if things and lcfirst and all that? I don't remember these... am I totally missing something?
#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.
Steve Summit wrote:
Elliott Cable wrote:
What are these {{#if things and lcfirst and all that? I don't remember these... am I totally missing something?
#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.
http://meta.wikimedia.org/wiki/Help:Magic_words#Formatting.
Minh Nguyen proposed:
{{#ifeq: [[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]] | {{:{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}}} | | Did you mean '''[[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]]'''? }}
I replied:
Oh! Splendid! I didn't know about those. I'll... try this out. Thanks very much.
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 and http://en.wiktionary.org/wiki/nowordatall
for a demonstration.
I had to remove the explicit {{NAMESPACE}}: tag. For whatever reason, in the main namespace, that caused the comparison to always be false, making the page always seem to exist, whether it did nor not. But removing the tag makes it work perfectly for the main namespace. (Removing the tag breaks it in the other direction for the other namespaces, making the link almost always fail, and the comparison always true, and the page therefore never seeming to exist. But that's actually a good thing, in this context, since we probably don't want to display "Did you mean?" for minorly-different capitalizations in the various project namespaces.)
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...)
Steve Summit wrote:
Minh Nguyen proposed:
{{#ifeq: [[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]] | {{:{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}}} | | Did you mean '''[[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]]'''? }}
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
Nice. I've posted a suggestion for a somewhat simplified version at http://en.wiktionary.org/wiki/MediaWiki_talk:noarticletext .
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...)
Agreed. It's not as if it'd even be hard to implement, seeing as MediaWiki already has a simple method call for checking this.
Steve Summit wrote:
<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...)
This has now been done, for anybody interested: http://meta.wikimedia.org/wiki/ParserFunctions#.23ifexist:
HTH HAND
Phil Boswell wrote:
Steve Summit wrote:
<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...)
This has now been done, for anybody interested: http://meta.wikimedia.org/wiki/ParserFunctions#.23ifexist:
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
On 04/06/06, Ray Saintonge saintonge@telus.net wrote:
Phil Boswell wrote:
Steve Summit wrote:
<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...)
This has now been done, for anybody interested: http://meta.wikimedia.org/wiki/ParserFunctions#.23ifexist:
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@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
What would be useful (and perhaps not very difficult to implement) is have [[MediaWiki:Edittools]] available at [[Special:Search]].
You should be able to use the following code, based on [[w:Template:Exists]] (but not compatible with it):
{{#ifeq: [[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]] | {{:{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}}} | | Did you mean '''[[{{NAMESPACE}}:{{lcfirst:{{PAGENAME}}}}]]'''? }}
Steve Summit wrote:
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.
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.
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.)
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.
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.
(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. Neither of two have anything to do with redirects.
I would favour an approach where, if the user visits a title that doesn't exist but the same title with different capitalisation does exist, the software pretends there was a redirect, and displays the "redirected from" message that allows you to click back to the original title in case you actually need to create a separate article. I would actually favour the same approach on Wikipedia too.
Timwi
I have to say I agree with timwi (-:
On May 10, 2006, at 10:09 AM, Timwi wrote:
(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. Neither of two have anything to do with redirects.
I would favour an approach where, if the user visits a title that doesn't exist but the same title with different capitalisation does exist, the software pretends there was a redirect, and displays the "redirected from" message that allows you to click back to the original title in case you actually need to create a separate article. I would actually favour the same approach on Wikipedia too.
Timwi
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Timwi wrote:
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.
Indeed.
My worry -- which I may not have thought through far enough -- was that if there was *too* much mapping from the case variant that didn't exist to the case variant that did, it would be impossible to create that second entry differing only in its capitalization.
which is why I like his idea of treating them as redirects - just same link (appears in the upper-right hand of the content area in Monobook) as normal user-created redirects. On May 10, 2006, at 10:39 AM, Steve Summit wrote:
Timwi wrote:
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.
Indeed.
My worry -- which I may not have thought through far enough -- was that if there was *too* much mapping from the case variant that didn't exist to the case variant that did, it would be impossible to create that second entry differing only in its capitalization. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Hoi, When you want to treat different cased titles for articles as potential redirects, I would want this behaviour to be something that you can configer. This behaviour is not necessarily what makes sense on all projects. It certainly would be extremely controversial in a Wiktionary(Z) environment. Thanks, GerardM
Elliott F. Cable wrote:
which is why I like his idea of treating them as redirects - just same link (appears in the upper-right hand of the content area in Monobook) as normal user-created redirects. On May 10, 2006, at 10:39 AM, Steve Summit wrote:
Timwi wrote:
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.
Indeed.
My worry -- which I may not have thought through far enough -- was that if there was *too* much mapping from the case variant that didn't exist to the case variant that did, it would be impossible to create that second entry differing only in its capitalization
wikitech-l@lists.wikimedia.org