Is there a reason to not use a www in that url schema? If this change is made, you effectively have to support both, as there are hundreds of thousands of inbound links across all the projects. Easy enough to rewrite URLs, but not easy to change those links, or the mindset of those who have been using the lang.wikipedia.org <http://lang.wikipedia.org> schema for years. /Alterego On 7/7/05, Angela &lt;beesley(a)gmail.com&gt; wrote:

That won't change. Google's site search work's for directories as well e.g, site:www.wikipedia.org/en/article/ <http://www.wikipedia.org/en/article/><http://wikipedia.org/en/article/Main_Page> On 7/7/05, Andrew Venier &lt;avenier(a)venier.net&gt; wrote:

Phil Boswell wrote in gmane.science.linguistics.wikipedia.technical: old URLs will not stop working. that would be bad, of course, given the number of links to the current URLs, both internally and externally... (however, using the old URLs would likely redirect to the newer style, were it implemented.) kate.

Brion Vibber wrote: And of course I second it. I don't currently support the idea of changing URL styles, but I could be convinced, and anyway I don't feel that it's the sort of decision that should be left up to me. But one thing that absolutely comes from the top here is that "We are *strongly* committed to maintaining the functioning of existing incoming links." It would be a disaster not to do this. --Jimbo

Ashar Voultoiz wrote: We're already doing that based on source IP, and may even start doing that based on network topology (BGP info). Splitting based on subdomain is not likely to be needed. No, things would stay the same. That's just a matter of rewrite rules. -- Mark mark(a)nedworks.org

Carlos wrote: The "edit" button in the UI already is ;-) I don't think URLs need to be localisable, especially not URLs that only geeks will want to go to directly. Timwi

Ævar Arnfjörð Bjarmason wrote: Well that depends on who you ask, I for one think the opposite :) -- Mark mark(a)nedworks.org

On Thu, 2005-07-07 at 22:49 -0700, David Friedland wrote: Because then you sorta limit your extensibility, putting articles in the same namespace as your "api". Imagine: http://en.wikipedia.org/history -> article on "History" http://en.wikipedia.org/history/protect -> history of the article "Protect" http://en.wikipedia.org/protect/history -> protect the article "History" ...or is it the "History" subpage of the "Protect" article? The rewrite rules get much simpler if the syntax is: http://<lang>.wikipedia.org/<action>/<article> ...and you have more room to grow without breaking URL permanence, because you haven't called dibbs on too many top-level path segments. This is a good idea. It'd be really nice to get all of the technology out of the URLs (e.g. ".php" file extensions) so that maintaining URL permanence doesn't mean maintaining strange mappings, even if MediaWiki is rewritten in a completely different language one day. Rob

David Friedland wrote: I sit at the other end of the bug reports, and I can assure you the opposite is true. The current URLs *work* and with little more than aesthetic preference for a change, a change that actually is KNOWN to fail in cases that are currently handled correctly is just not going to happen. Note that Wikipedias can be fully expected to have articles on [[robots.txt]] and [[favicon.ico]] etc... :) We *must* have a clear namespace, unfettered by exceptions or no-title-zones. This is non-negotiable. Handling things "specially" is a recipe for disaster, and generally means "there will be a bunch of big nasty bugs here". It's far, far better to handle these things generically by eliminating the bug breeding ground. Pretty much any and all "rare" cases will be found as people try to put articles at them and run up against a brick wall. This argument fails for a number of reasons, including: * On wikis with capitalized titles we accept incoming links with both lower- and uppercase forms, with automatic redirecting where necessary. Changing this may break existing links, including interwiki links, unnecessarily. Note that interwiki links do not force the capital letter on the outgoing link since it's unknown whether the software on the other end is case-sensitive or not. * At some point we *will* move to a fully case-insensitive, case-preserving title system. There *will* be titles with initial lowercase letters on the English Wikipedia at that time. * Right now on a number of our wikis, link capitalization is not enforced and there *are now* titles with initial lowercase letters. These include a fair number of major Wiktionaries and a couple artificial-language Wikipedias. -- brion vibber (brion @ pobox.com)

On Fri, 2005-07-08 at 20:56 +0100, Timwi wrote: I'm not sure if there's a specific prohibition of this practice in any spec, but it does fight typical conventions, which is kind of a bad thing. For example, it appears that Apache throws away extra slashes, as can be seen here: http://apache.org///foundation////faq.html http://apache.org/foundation/faq.html IIS seems to do the same thing: http://www.microsoft.com////windowsserversystem///default.mspx Chances are there are going to be weird corner cases where the web server smarts interfere with what you want to do. While it seems like a simple enough problem to solve for the Wikipedia admin team, it's likely that such a convention would be difficult to support in a general MediaWiki install. Though there's no reason that WP can't have a custom, tricked-out config, it'd be nice if WP were running in a "recommended" configuration for MediaWiki. Mixing subpages into the action namespace seems like a bad idea. Arguably its worse when its only the exception, because that means it'll be something that will always need to be accommodated, but rare enough that its often forgotten. In the spirit of putting the action at the end, perhaps this syntax would work: http://en.wikipedia.org/Pagename?action=edit http://en.wikipedia.org/Pagename?action=history It seems a little dicey from a future-proofing perspective to put the article names at the root, but there is an appeal to it as well. In order to avoid mixing functionality extensions into the article namespace, the extensions would either need to live in URL parameters or in the 'Special:' namespace (or other namespace). Rob

On Fri, 2005-07-08 at 22:40 +0100, Timwi wrote: Ok, that's good. What about the ramifications for relative URL handling in RFC 2396? http://www.ietf.org/rfc/rfc2396 I haven't found any immediate problems, but it would take me a while reading through the BNF to figure out if there are places where it breaks. Not that it's a huge deal if relative URLs don't work, since MW can always just stick to absolute references, but its one area where things can go wrong. Ok, that's good. Still, I maintain that assigning unique semantics to "//" versus "/" when used in that part of a URL doesn't have a lot of precedent, which also means that there's probably a lot of places it can break. I admit that's a vague criticism, but I just have a bad gut feeling about going down that road. First, let me quote again the part of your proposal which I was responding to, and try again with a clearer response: Let's say there's an article called "Particles", with a sub-article "Atom". The "Particle" article would be: http://en.wikipedia.org/Particles ...and the Atom subarticle would be: http://en.wikipedia.org/Particles/Atom Now lets say that a future version of MW allows output of the history of any page in Atom form, with "/Atom" designating the output. So, after the upgrade, what used to be a valid reference to the Atom article is now an atom feed. The new URL to the article is: http://en.wikipedia.org/Particles//Atom But wait, we already committed to not break incoming links. Crap...now we have to choose a name for every new action that doesn't overlap with any existing subpage. This is what I mean about keeping namespaces separate ("namespace" in the general sense, not the MediaWiki specific "Foo:Bar" sense). I would much prefer there be a syntactic way of distinguishing between a subpage and an action that always works, even on Tuesdays ;-) ...but it's far less ambiguous, and it's clear that it's an action performed on article "Pagename", rather than a page of its own. Rob

Rob Lanphier wrote: I see you misunderstood. My proposal isn't to double the slash only in cases where it disambiguates an action. That would be stupid precisely for the reasons you mentioned. No, the canonical URL for [[a/b/c/d]] would be at http://en.wikipedia.org/A//b//c//d under my proposal. But anyway. I understand everybody's concerns about the double-slashes, and they aren't a required portion of my proposal anyway, so we can change this. You could always encode them as %2F instead, or you could use ";edit" instead of "/edit" and then encode semicolons as %3B instead (the software already does this now). But think about why that is the case. It's only because you know that the question mark ("?") cannot occur in the page title because it would be encoded as "%3F". Therefore, my proposal is essentially equivalent to yours except that the delimiting character is a single "/" and not a "?" and the proposed encoding is "//" and not "%2F". We can change any of these two parameters any way we like, just as long as we have a clear delimiter. Slashes are more common in page titles only if the wiki makes extensive use of subpages. In actual articles (zero-namespace pages), the question mark is way more common (e.g. [[Is Everybody Listening?]]). I think the semicolon (";") is rarer than both of these, so even if you think it's unusual, it may be a better choice than both "/" and "?". Greetings, Timwi

Brion Vibber wrote: I understand. I didn't think of this. I guess that means we have to have something between the domain name and the article title, and it can't just be a double-slash, so it has to be at least /w/ or something. So how about this: - http://en.wikipedia.org/w/Article_title Use /w/ for pages that can be crawled. - http://en.wikipedia.org/z/Article_title;history Use /z/ for pages that must not be crawled. - http://en.wikipedia.org/w/Article_title;history would redirect to http://en.wikipedia.org/z/Article_title;history - http://en.wikipedia.org/z/Article_title would redirect to http://en.wikipedia.org/w/Article_title What do you think? :-) Timwi