Please remove "wiki/" string from URLs of all Wikimedia wikis. Locators will be shorter and hence better memorizable. Also, locators will be created easier when one knows article name only. URL of an article on EN Wikipedia will look like this: http://en.wikipedia.org/Automobile.
Version: unspecified
Severity: enhancement
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| Do not suggest images that are already on the page | repos/structured-data/image-suggestions!12 | cparle | T322669 | T311289 |
A MediaWiki man page is NOT an answer for this problem to me. Tim Berners-Lee may say something, but time goes on and the web evolves. So if you want to stick to his principles, you seem to be a bit yesterday to me. I still think simpler URLs would be a plus here.
Indeed, wiki*.*/wiki/ looks a bit schizophrenic. It is a leftoff from times when there was wikipedia.org/images/, wikipedia.org/tarballs/ and so on. Since these are not used anymore, we can shorten URLs a bit without interferring with other bits and pieces. If the wikipedia.org/Article_Name schema is unacceptable from an ops viewpoint (it's still possible though not advised), we still can shorten URLs to something like:
wikipedia.org/index.php?...
wikipedia.org/w/Article_Name
This might involve the following steps:
Although it's a PITA, it (or similar changes) will result in nicer URLs.
bugs wrote:
Or we could use the things like "/view/" and "/history/". This would probably need some wider discussion before it was implemented though, since it would be kind of a global change for all of URLs everywhere.
If anything, we should probably switch to ActionPaths indeed, like the following already do:
(In reply to comment #5)
If anything, we should probably switch to ActionPaths indeed, like the
following already do:
I like this idea.
Yes, this is a Good Thing, it will , of course, break just about every piece of third party software that interacts with the existing version.
(In reply to comment #7)
Yes, this is a Good Thing, it will , of course, break just about every piece of
third party software that interacts with the existing version.
It should be fine if /wiki/Foo remains as a redirect to /view/Foo , right?
(In reply to comment #7)
Yes, this is a Good Thing, it will , of course, break just about every piece of
third party software that interacts with the existing version.
If they use the API like they should, it shouldn't cause that much damage, And if we were to do something like this, we wouldn't just switch it over one night and go for drinks.
Of course, a "suitable transition" means there would be time for drinks AND a pizza. But you are right of course, the API uses /w/ so my alarmism is alarmist - only the relatively few apps that rely on the HTML version of pages should suffer.
This is almost a duplicate of bug 16659.
The best notes about implementing action paths are probably here: http://wikitech.wikimedia.org/view/Action_paths.
This has been discussed on the mailing lists a few times. One of the issues with switching to action paths is that they're not currently localizable.
This might be a dupe of bug 17981 (Action paths), but it seems the original request is to just have a null path... Thus I'm a bit unclear what this bug is currently "about" so I'm unclear if i should mark as dupe.
Kozuch, can you clarify what's being requested here? Are you trying to have "en.wikipedia.org/Foo"? If so, http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory pretty clearly lays out why that's not really a good idea. And if so, this can probably be resolved as "wontfix."
If this bug is simply about removing "wiki/" from the URL (and putting "view/" or whatever in its place), then this bug is a duplicate of bug 17981.
Either way, this bug is likely resolved.
Marking wontfix per comment 13 and comment 14.
See bug 17981 for suggestions about using wgActionPaths on Wikimedia wiks (eg. en.wikipedia.org/edit/Sandbox and en.wikipedia.org/view/Sandbox)