https://bugzilla.wikimedia.org/show_bug.cgi?id=27963
MZMcBride <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from MZMcBride <[email protected]> 2011-03-10 03:47:03 UTC --- (In reply to comment #0) > When I visit a nonexistent subpage, for example > https://secure.wikimedia.org/wikipedia/en/wiki/Talk:Washington,_D.C./archive_1 > it reports that the page does not exist and that "Titles on Wikipedia are case > sensitive except for the first character." There are two issues that are being conflated here. The first issue is that there aren't better suggestions for very close, but inexact page titles. This crops up in all sorts of places (capitalization changes, accent mark changes, etc.), but is outside the scope of this bug. The second issue is that the documentation is a bit misleading (at least inasmuch as it misled you). Titles _are_ case sensitive except for the first letter. The fact that the content is at "/A" but not at "/a" fairly clearly demonstrates this. The message could be rephrased, but that's an issue for the English Wikipedia, not an issue for MediaWiki development. The default "no page exists" text does not include this passage. If you would like to change the English Wikipedia's text, you can do so at <http://en.wikipedia.org/wiki/MediaWiki:Noarticletext>. > However, the page > https://secure.wikimedia.org/wikipedia/en/wiki/Talk:Washington,_D.C./Archive_1 > does exist, and the only difference is the capital A in Archive. Right. Page titles are case sensitive except for the first letter on the English Wikipedia, as established. This isn't the case for every MediaWiki installation (Wiktionaries, for example, are case insensitive for most namespaces). > The expected behavior is that the first character after a slash in a subpage > name should not be case sensitive. I'm not sure this is the expected behavior. I can see arguments for it being this way, but current (widespread) practice on the English Wikipedia uses conventions such as "/doc" for template documentation subpages and "/sandbox" for many user sandboxen. > Before changing this, have a look at how many pages exist where there ARE two > different pages differing only by the case of the first letter after a slash > (or multiple case-changes-after-slashes, for nested subpages). Usually one > will be a redirect to the other one. Please be sure to keep access to the one > that is not a redirect. Sure, some redirect. This is another case where page title suggestions (or even very cautious auto-redirection) need better implementation. But this is still outside the scope of this bug. > If you think my intuitive expectation about the behavior is not at all > grounded > in reasonableness, we should at least update the "page not found" > documentation > to note that ALL characters, even the first, in subpage names are case > sensitive. I'd rather just have the intuitive behavior, though. Updating the documentation to say that _all_ characters are case sensitive isn't exactly right. The context for this message is largely people clicking red links. When a user does so, they want to be able to figure out why there isn't any content there. In this context, the full page title is not case sensitive, it's entirely case sensitive except for the first letter. For example, [[iPhone]] is always going to lead to [[IPhone]] just as [[IPhone]] would. The case of the first letter in links is irrelevant (except for display purposes), which is what the message at the English Wikipedia tries to convey. Given all of this, I'm inclined to mark the bug as invalid, but I'll hold off for now. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
