Last modified: 2014-04-16 03:48:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 453 - Make page titles case-insensitive (but preserve case-sensitivity for display)
Make page titles case-insensitive (but preserve case-sensitivity for display)
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 9173 22055 22211 (view as bug list)
Depends on: 20278
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-11 10:51 UTC by Aaron Peterson
Modified: 2014-04-16 03:48 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Aaron Peterson 2004-09-11 10:51:44 UTC
I finally got a good idea of how to reduce the number of redirects, and annoying
piped links...  and start the transitioning to case-preserving case-insensitive

a "unique" boolean column / field, added to the table that lists the wiki pages.

If the list has the tag "unique", that is it, stop the mysql query, and output
that result.

If it does not have the tag unique.. then, keep searching for potential pages to
return.

Basically, have a flag for uniquely spelled pages, and this unique flag can be
turned on initially  in english only named pages..  as not to interfere with
UTF8 named pages.

This would reduce the editing time substantially on pages, and would allow, a,
probably loved, so I hate to bash it, awkward convention of capitalizing the
first letter of a WikiName

I am hoping to join the coding effort, I need to learn a bunch of stuff first,
but I really hope to get this feature... at least on my lesser wiki where
performance isn't a problem.. yet... -AP



Maybe mysql doesn't support this? maybe postgres? does?   the combining of two
queries into one, where if one is met, the other halts...  because this could
result in a performance increase of up to 1/2 for the database end of things
(assuming checking a boolean is cheap, and checking the filename is expensive)


anyway, when sombody writes a new page of a name that is already there, the
database has to be queried to see if anybody has edited that page in the mean
time.. that same querry could return "did you mean to edit this page with the
same spelling but different capitalization? if the person says no, the unique
flag is removed from that page, and then the querry must continue on to check
for all instances of a certain page...

(I was told that the mysql querry is already case-insensitive.. which doesn't
make sence to me..  that selecting of the right page is done in php with the
list of results returned by the querry when loading a page???   I might have
been mistaken, the search.. makes sence to be case insensitive, and the person
was probably thinking that that was what I was talking about)

anyway, case-insensitive could have other advantages for the database.. (I'm
theorising, I'm not a database designer... so .. this is why I wanted to post
this idea on the wiki counterpart to this page.. but.. [[m:case sensitivity]]
isn't something I feel like typing into my browser.

Bah, the page names are probably all cached niftilly...

anyway, I am constantly annoyed by miscapitalizations and rarely correct
compromises...  i really hope that my musings have resulted in some usefull
ideas for this system.

-AP (my email address is changing soon)
Comment 1 Brion Vibber 2005-04-22 12:25:05 UTC
Reassigned to enhancements.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-03-06 02:07:39 UTC
*** Bug 9173 has been marked as a duplicate of this bug. ***
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-03-06 03:41:56 UTC
I'm seriously confused by comment #0.  As far as I can see, this would quite
simply (hah) entail adding a field page_display_title that would allow any
capitalization and allow mixing underscores and spaces, uniformly lowercase
page_title, and use the normalized page_title as the DB key as now while using
page_display_title for display instead of the voodoo magic we do now.  The issue
would be in converting everything so existing conflicts are dealt with cleanly
and nothing in the entire codebase breaks.  I don't get the proposed solution,
which is also incidentally 2.5 years old.

Anyway, I'm clarifying the purpose of this bug, since I didn't see any suitable
similar bugs.
Comment 4 André Offringa 2008-01-06 11:46:07 UTC
Hey, I'm just posting to let you know that allowing case insensitive page titles-searches, but case-sensitive pages would in my eyes be a really great feature for the Wikipedia-project, so I really vote for implementing this. It would reduce the number of necessary redirect from things like "John doe" to "John Doe" (not to speak about things like "HHC Hardenberg" or "President of the United States" where it gets harder and harder), reduce the possibility of getting two articles about the same subject (which at least happens regularly on the Dutch wikipedia) and would not bother the user of Wikipedia with a worthless "(Redirected from John doe)"-message when entering "john doe" (as everyone does) in the search field. So... I really hope that this can be implemented.
Comment 5 Ben White 2008-02-08 21:20:08 UTC
This feature is possible. I have implemented it at the Homestar Runner wiki. Not only does my implementation match links in a case-insensitive manner, it will also match plurals (configurable in LocalSettings on a per-wiki basis). The functions handle typed URLs, searches, and links in wikitext. Here are the specifications as listed on http://www.hrwiki.org/index.php/HRWiki:Autopipe/Autoredirect :

----------
When a link is entered on a page that points to a page in the _main, project, user, or help namespace_, the system first tries to match it exactly as it's written. If the page does not exist, the system automatically tries to create a hidden piped link to a _capitalized/lowercase or plural form_ (except it does not attempt to match plural forms for the user namespace). Similarly, if the system cannot find a page based on a URL, it tries to automatically create a redirect. What this means is that it is no longer necessary to create a piped link from "goat" to "Goats", for example, and it is not necessary to have a corresponding redirect page. Pages where the capitalized and lowercase forms mean different things, like "Homsar" and "homsar", are unaffected. 

If it should ever become necessary to create a page that ordinarily would be autoredirected, just type it into the URL, and you'll be presented with a "rediected from" link, such as http://www.hrwiki.org/index.php?title=goat&redirect=no. Then create the page like normal. 
----------

My implementation requires some methods to be added to Title.php; a minor change to Wiki.php, SearchEngine.php, and Linker.php; and some fairly substantial changes to a couple of spots in Parser.php. If this feature were to be seriously considered for MediaWiki proper, I would be more than happy to elaborate on how I did it.
Comment 6 Happy-melon 2009-07-24 12:27:41 UTC
IMO this should be WONTFIXed: we have redirects, which are *not* evil as many people believe, we have the recently-overhauled LuceneSearch and mwsuggest, and we have {{DISPLAYTITLE:...}} to correct page display.  I don't think that any additional functionality is needed, certainly not on the level of a schema change. 
Comment 7 Ben White 2009-07-24 19:08:31 UTC
My implementation in comment #5 doesn't require a schema change. It makes many redirects unnecessary but not obsolete. Having used it for a while now I can't imagine living without it.
Comment 8 Chad H. 2009-07-24 19:12:14 UTC
Go ahead and post the patch (against trunk, please). Can't hurt to have it in front of us to review, and it may very well be worth committing to MW.
Comment 9 Max Semenik 2010-01-08 11:48:24 UTC
*** Bug 22055 has been marked as a duplicate of this bug. ***
Comment 10 Chad H. 2010-01-21 16:43:10 UTC
*** Bug 22211 has been marked as a duplicate of this bug. ***
Comment 11 Anu 2012-11-27 10:50:53 UTC
Using the word CHICKEN, I am trying to resolve this issue.

For example, the link http://en.wikipedia.org/wiki/CHICKEN returns that Wikipedia does not have an article with this exact name. However it does state that "Please search for CHICKEN in Wikipedia to check for alternative titles or spellings. " 

And when we click on the alternatives link, then we get the link connecting to the relevant pages. For now, this issue can be updated to be resolved?
Comment 12 Andre Klapper 2012-11-27 18:11:11 UTC
Anu: The default "Article not found" page with a Search link is not a "resolution" for this request.
FYI, the underlying problem of this bug report is about *page titles* and described in https://meta.wikimedia.org/wiki/Case sensitivity_of_page_names
Comment 13 Quim Gil 2014-04-16 03:48:21 UTC
The correct link is https://meta.wikimedia.org/wiki/Case_sensitivity_of_page_names

Coincidentally, I also found https://meta.wikimedia.org/wiki/Case_insensitivity_of_page_names , where you can find more argumentation pro and against case-sensitiveness.

In any case, nobody is currently planning to work on this. Setting priority accordingly.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links