From: jidanni(a)jidanni.org

http://en.wikipedia.org/wiki/Special:Search?search=steven+tyler gets http://en.wikipedia.org/wiki/Steven_tyler wouldn't be better to directly get http://en.wikipedia.org/wiki/Steven_Tyler even though one could say they are the same page?

On Fri, May 13, 2011 at 12:25 AM, Jay Ashworth <jra(a)baylink.com> wrote: except Like you said, the system is case sensitive. These redirects are created because the software doesn't handle case changes correctly otherwise. For example the following link leads to a "no such page" error because the appropriate redirect does not exist: http://en.wikipedia.org/wiki/Sterling_heights,_Michigan . It would be possible to code around this, so that the redirects would be simulated if they don't exist, but it hasn't happened. In practice, people like me like to type a title in all lower case, and so we have redirects to make it work. - Carl _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

From: "Carl (CBM)" <cbm.wikipedia(a)gmail.com>

On Fri, May 13, 2011 at 12:25 AM, Jay Ashworth <jra(a)baylink.com> wrote: Like you said, the system is case sensitive. These redirects are created because the software doesn't handle case changes correctly otherwise. For example the following link leads to a "no such page" error because the appropriate redirect does not exist: http://en.wikipedia.org/wiki/Sterling_heights,_Michigan .

It would be possible to code around this, so that the redirects would be simulated if they don't exist, but it hasn't happened. In practice, people like me like to type a title in all lower case, and so we have redirects to make it work.

From: "Andrew Dunbar" <hippytrail(a)gmail.com>

On 13 May 2011 14:34, Carl (CBM) <cbm.wikipedia(a)gmail.com> wrote: Indeed on the English Wiktionary we do have some JavaScript which runs when on a page which would be a redlink. It checks all casing combinations of: all lowercase, all uppercase, first letter uppercase and the rest lowercase. If one of those exists it automatically redirects after a couple of seconds. With the different nature of Wikipedia titles you would probably want to check sentence case and title case but would still miss quite a few where only proper nouns within the title are capitalized. And some people would probably hate such a feature too (-:

Repeat after me: "Not all Mediawikiae are Wikipedia; Wikipedia is merely *the most important* customer of the project, not the only one".  No, it would *not* be good to make the base package page-title-case-folding.

I still don't think page titles should be case sensitive. Last time I asked how useful this really was, back in 2005 or so, I got a tersely-worded response that we need it to disambiguate certain pages. OK, but how many cases does that actually apply to? I would think that the increased usability from removing case sensitivity would far outweigh the benefit of natural disambiguation that only applies to a tiny minority of pages, and which could easily be replaced with disambiguation pages.

On Fri, May 13, 2011 at 3:31 AM, M. Williamson <node.ue(a)gmail.com> wrote: From a software perspective, the way to do this would be to store a canonicalized version of each page's title, and require that to be unique instead of the title itself. This would be nice because we could allow underscores in page titles, for instance, in addition to being able to do case-folding. Note that Unicode capitalization is locale-dependent, but case-folding is not. Thus we could use the same case-folding on all projects, including international projects like Commons. There's only one exception -- Turkish, with its dotless and dotted i's. But that's minor enough that we should be able to work around it without too much pain. Some projects, like probably all Wiktionaries, would doubtless not want case-folding at all, so we should support different canonicalization algorithms. Even the ones that don't want case-folding could still benefit from allowing underscores in titles. But all this would require a very intrusive rewrite. Assumptions like "replace spaces by underscores to get dbkey" are hardwired into MediaWiki all over the place, unfortunately. It's not clear that it's worth it, since there are downsides to case-folding too. It might make more sense to auto-generate redirects instead, which would be a much easier project that wouldn't have the downsides.

"Daniel Friesen" <lists(a)nadir-seen-fire.com> wrote in message news:4DCDB7AF.7020909@nadir-seen-fire.com... http://toolserver.org/~krinkle/wikimedia-svn-search/do-live.php?path=%2Ftru… Sure, keep telling yourself that... :-P --HM

On 14 May 2011 01:48, Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote: > On Fri, May 13, 2011 at 3:31 AM, M. Williamson <node.ue(a)gmail.com> wrote:

>> I still don't think page titles should be case sensitive. Last time I asked >> how useful this really was, back in 2005 or so, I got a tersely-worded >> response that we need it to disambiguate certain pages. OK, but how many >> cases does that actually apply to? I would think that the increased >> usability from removing case sensitivity would far outweigh the benefit of >> natural disambiguation that only applies to a tiny minority of pages, and >> which could easily be replaced with disambiguation pages.

> From a software perspective, the way to do this would be to store a > canonicalized version of each page's title, and require that to be > unique instead of the title itself.  This would be nice because we > could allow underscores in page titles, for instance, in addition to > being able to do case-folding. > Note that Unicode capitalization is locale-dependent, but case-folding > is not.  Thus we could use the same case-folding on all projects, > including international projects like Commons.  There's only one > exception -- Turkish, with its dotless and dotted i's.  But that's > minor enough that we should be able to work around it without too much > pain.

I'm almost positive Azeri has the same dotless i issue and perhaps some of the other Turkic languages of Central Asia. One solution is to do accent/diacritic normalization too as part of the canonicalization.

I'm almost positive Azeri has the same dotless i issue and perhaps some of the other Turkic languages of Central Asia. One solution is to do accent/diacritic normalization too as part of the canonicalization.

On Sat, May 14, 2011 at 8:33 PM,  <jidanni(a)jidanni.org> wrote: Because then we can't show the "(Redirected from X)" bar that accompanies the redirects

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

From: "David Gerard" <dgerard(a)gmail.com>

On 13 May 2011 09:09, Jay Ashworth <jra(a)baylink.com> wrote: Ah, OK, we agree :-)

I wouldn't make it the *default* unless and until it proved to be massively the actual desired use case. I think it'd be a great feature and I'd really like it for real-world use (intranet wikis in particular - it's amazing how many people who use a computer all day every day get away with claiming to be unable to use them).

Doesn't look that bad... - Some arcane maintenance scripts. - Some .js that can't interact with Title working with urls. - The expected User, Title, Parser, file related, etc... core api stuff that's easy to tweak. - Some hardcoded stuff for namespaces which could be improved, but actually isn't all that applicable to what we're trying to fix. - Some special pages cleaning up inputs where we might want to provide something inside Title for that.

I'm almost positive Azeri has the same dotless i issue and perhaps some of the other Turkic languages of Central Asia. One solution is to do accent/diacritic normalization too as part of the canonicalization.