On Tue, 17 Sep 2013, at 7:51, Tyler Romeo wrote:
On Mon, Sep 16, 2013 at 6:12 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
* use simple action urls
https://en.wikipedia.org/Foo?action=history instead of
https://en.wikipedia.org/w/index.php?title=Fooaction=history
This already
On 09/27/2013 06:03 AM, Gryllida wrote:
I would be concerned about proper work of this feature in wikilinks. [[Main
Page?action=history|Foo]] makes a red broken link.
So does:
[[/w/index.php?title=Main Page|Foo]]
Neither would be expected to work. Anything to the left of the pipe in
your
On 09/17/2013 05:59 AM, Daniel Friesen wrote:
Side topic https://en.wiktionary.org/w/r/t is messed up: To check for
r/t on Wikipedia, see: //en.wikipedia.org/wiki/r/t
https://en.wikipedia.org/wiki/r/t
Good catch, filed: https://bugzilla.wikimedia.org/show_bug.cgi?id=54357
Matt Flaschen
On 20/09/13 03:04, Jon Robson wrote:
Thanks Tim for running those data. That seems to suggest the URL
structure works for the most case.
I think the request rate for actual articles in the root is very, very
low. And if you look at the paste I gave earlier:
Tim Starling wrote:
Personally, I think the refresh is annoying, since it makes it much
more difficult to correct typos in manually-typed URLs. If you
actually meant to type some non-article URL like a CSS resource, and
make a typo which causes it to hit the refresh, the URL you typed is
erased
On 19 Sep 2013 18:23, Tim Starling tstarl...@wikimedia.org wrote:
On 20/09/13 03:04, Jon Robson wrote:
Thanks Tim for running those data. That seems to suggest the URL
structure works for the most case.
I think the request rate for actual articles in the root is very, very
low.
I agree..
Thanks Tim for running those data. That seems to suggest the URL
structure works for the most case.
On Wed, Sep 18, 2013 at 12:07 AM, Tim Starling tstarl...@wikimedia.org wrote:
On 17/09/13 13:59, Jon Robson wrote:
I would suggest taking a look at the number of 404s caused by people trying
to
On 17/09/13 13:59, Jon Robson wrote:
I would suggest taking a look at the number of 404s caused by people trying
to access pages without the wiki prefix This would be interesting data
to go alongside this interesting proposal...
There are lots of different sorts of 404s, so it's necessary
Note also that zhwiki (and others?) profitably uses the first part of the
path to do variant selection.
https://zh.wikipedia.org/wiki/User:Cscott uses the wiki default variant (if
logged in, uses the variant from the user's preferences)
https://zh.wikipedia.org/zh-hans/User:Cscott
On 17/09/13 14:01, Gabriel Wicke wrote:
On 09/16/2013 07:48 PM, Tim Starling wrote:
On 17/09/13 11:08, Gabriel Wicke wrote:
Tim mentions in
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/49833#c3561 that
this only applied to IE3 and earlier, and IE4 respects the Content-type
header.
On Tue, Sep 17, 2013 at 8:34 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
There *might* be, in theory. In practice I doubt that there are any
articles starting with 'w/'. To avoid future conflicts, we should
probably prefix private paths with an underscore as titles cannot start
with it (and
On 17/09/13 10:24, K. Peachey wrote:
On Tue, Sep 17, 2013 at 8:34 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
There *might* be, in theory. In practice I doubt that there are any
articles starting with 'w/'. To avoid future conflicts, we should
probably prefix private paths with an underscore
Am 17.09.2013 00:34, schrieb Gabriel Wicke:
There *might* be, in theory. In practice I doubt that there are any
articles starting with 'w/'.
I count 10 on en.wiktionary.org:
https://en.wiktionary.org/w/index.php?title=Special%3APrefixIndexprefix=w%2Fnamespace=0
To avoid future conflicts, we
On 2013-09-17 2:29 AM, Nikola Smolenski wrote:
On 17/09/13 10:24, K. Peachey wrote:
On Tue, Sep 17, 2013 at 8:34 AM, Gabriel Wicke gwi...@wikimedia.org
wrote:
There *might* be, in theory. In practice I doubt that there are any
articles starting with 'w/'. To avoid future conflicts, we should
On 2013-09-16 8:01 PM, Gabriel Wicke wrote:
On 09/16/2013 07:24 PM, Daniel Friesen wrote:
On 2013-09-16 7:09 PM, Gabriel Wicke wrote:
Any of the entry points? Any new entry point? Anything we ever want to
put into the root?
We should be able to avoid most conflicts by picking prefixed entry
On 17/09/13 11:59, Daniel Friesen wrote:
On 2013-09-17 2:29 AM, Nikola Smolenski wrote:
I have found 2476 pages in English Wikipedia that start with
'[something]/', inlcuding pages starting with '//'. None of them start
with a small letter though, for obvious reasons.
The problem with that
On 2013-09-17 2:48 AM, Daniel Kinzler wrote:
To avoid future conflicts, we should
probably prefix private paths with an underscore as titles cannot start
with it (and REST APIs often use it for special resources).
That would be better.
But still, I think this is a bad idea. Essentially,
On 09/17/2013 02:48 AM, Daniel Kinzler wrote:
Am 17.09.2013 00:34, schrieb Gabriel Wicke:
There *might* be, in theory. In practice I doubt that there are any
articles starting with 'w/'.
I count 10 on en.wiktionary.org:
On Mon, Sep 16, 2013 at 7:41 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
Using sub-resources rather than the random switch to /w/index.php is
more important for caching (promotes deterministic URLs) and does not
seem to involve similar trade-offs.
Note that promotes deterministic URLs
On 09/17/2013 08:40 AM, Brad Jorsch (Anomie) wrote:
On Mon, Sep 16, 2013 at 7:41 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
Using sub-resources rather than the random switch to /w/index.php is
more important for caching (promotes deterministic URLs) and does not
seem to involve similar
On Tue, Sep 17, 2013 at 12:27 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
An end point that wants to be cacheable should only use one query
parameter, which might well be a path. Hypothetical examples:
http://wiki.org/wiki/Foo?r=latest/html
http://wiki.org/wiki/Foo?r=123456/wikitext
So
On 09/17/2013 11:24 AM, Brad Jorsch (Anomie) wrote:
On Tue, Sep 17, 2013 at 12:27 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
An end point that wants to be cacheable should only use one query
parameter, which might well be a path. Hypothetical examples:
Gabriel Wicke wrote:
A heavily-used content API will perform better and use less resources
when it is cacheable. This will become more important over time, so I
believe it is worth spending a small amount of effort on now.
Sure, I think everyone agrees that a heavily used Web resource will
Hi,
while tinkering with a RESTful content API I was reminded of an old pet
peeve of mine: The URLs we use in Wikimedia projects are relatively long
and ugly. I believe that we now have the ability to clean this up if we
want to.
It would be nice to
* drop the /wiki/ prefix
On Mon, Sep 16, 2013 at 6:12 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
* drop the /wiki/ prefix
https://en.wikipedia.org/Foo instead of
https://en.wikipedia.org/wiki/Foo
Where would we put the API entry point? It can't be at
https://en.wikipedia.org/w/api.php because there might be
On Mon, Sep 16, 2013 at 3:12 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
Hi,
while tinkering with a RESTful content API I was reminded of an old pet
peeve of mine: The URLs we use in Wikimedia projects are relatively long
and ugly. I believe that we now have the ability to clean this up if
On Mon, Sep 16, 2013 at 3:12 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
Hi,
while tinkering with a RESTful content API I was reminded of an old pet
peeve of mine: The URLs we use in Wikimedia projects are relatively long
and ugly. I believe that we now have the ability to clean this up if
On 09/16/2013 03:21 PM, Tyler Romeo wrote:
On Mon, Sep 16, 2013 at 6:12 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
* drop the /wiki/ prefix
https://en.wikipedia.org/Foo instead of
https://en.wikipedia.org/wiki/Foo
Where would we put the API entry point? It can't be at
Chad wrote:
On Mon, Sep 16, 2013 at 3:12 PM, Gabriel Wicke gwi...@wikimedia.org
wrote:
It would be nice to
* drop the /wiki/ prefix
https://en.wikipedia.org/Foo instead of
https://en.wikipedia.org/wiki/Foo
* use simple action urls
https://en.wikipedia.org/Foo?action=history instead
On Mon, Sep 16, 2013 at 6:34 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
There *might* be, in theory. In practice I doubt that there are any
articles starting with 'w/'. To avoid future conflicts, we should
probably prefix private paths with an underscore as titles cannot start
with it (and
- Original Message -
From: MZMcBride z...@mzmcbride.com
The RFC currently seems to gloss over what problem is attempting to be
solved here and what benefits a new URL structure might bring. I'd like to
see a clearer statement of a problem and benefits to a switch, taking
into
On Tue, Sep 17, 2013 at 12:34 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
In practice I doubt that there are any articles starting with 'w/'.
Actually, there are. Looking at enwiktionary only, there are 10 pages
starting with w/.
Some of those are redirects (e.g w/r/t), but others are normal
On 2013-09-16 7:12 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
Hi,
while tinkering with a RESTful content API I was reminded of an old pet
peeve of mine: The URLs we use in Wikimedia projects are relatively long
and ugly. I believe that we now have the ability to clean this up if we
want
On 09/16/2013 03:25 PM, Ryan Lane wrote:
https://www.mediawiki.org/wiki/Manual:Short_URL#URL_like_-_example.com.2FPage_title
*Warning:* this method may create an unstable URL structure and leave some
page names unusable on your wiki. See Manual:Wiki in site root
On Mon, Sep 16, 2013 at 4:41 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
On 09/16/2013 03:25 PM, Ryan Lane wrote:
https://www.mediawiki.org/wiki/Manual:Short_URL#URL_like_-_example.com.2FPage_title
*Warning:* this method may create an unstable URL structure and leave
some
page
On 09/16/2013 04:09 PM, Petr Onderka wrote:
On Tue, Sep 17, 2013 at 12:34 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
In practice I doubt that there are any articles starting with 'w/'.
Actually, there are. Looking at enwiktionary only, there are 10 pages
starting with w/.
Some of those
On Mon, Sep 16, 2013 at 7:51 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
Ah, ok. That would make it hard to keep /w/api.php working. /_w/api.php
would not suffer from that problem, but then current API users would break.
So I guess that kills the /wiki/ removal in the shorter term. Maybe we
On Mon, Sep 16, 2013 at 3:36 PM, MZMcBride z...@mzmcbride.com wrote:
The RFC currently seems to gloss over what problem is attempting to be
solved here and what benefits a new URL structure might bring. I'd like to
see a clearer statement of a problem and benefits to a switch, taking into
On Mon, Sep 16, 2013 at 8:20 PM, Steven Walling steven.wall...@gmail.comwrote:
Our current URL structure is extremely obtuse for non-technical users, and
generally defies their expectations. To most people,
en.wikipedia.org/Dogor even
wikipedia.org/Dog should work just fine, not produce a
- Original Message -
From: Steven Walling steven.wall...@gmail.com
How about the following?
Our current URL structure is extremely obtuse for non-technical users,
and generally defies their expectations. To most people,
en.wikipedia.org/Dogor even
wikipedia.org/Dog should work
On 09/16/2013 04:34 PM, Brian Wolff wrote:
Additionally there is some security issues in ie6 when doing foo?action=raw
if I recall.
Yes, IIRC some version of IE disregarded the Content-type header and
guessed the content type based on the URL and the content. If the URL
contained .php (only
On 09/16/2013 04:42 PM, Ryan Lane wrote:
On Mon, Sep 16, 2013 at 4:41 PM, Gabriel Wicke gwi...@wikimedia.org
mailto:gwi...@wikimedia.org wrote:
That is a very vague warning. So far I have lower-case 'favicon.ico',
'robots.txt' and 'w/' as potential conflicts. Do you see any others?
On 17/09/13 09:34, Brian Wolff wrote:
Well I'm not particularly fond of this idea (probably because im stuck in
my ways more than anything else), I do think that making the
en.wikipedia.org/foo be an instant http redirect instead of did you
mean/redirecting in 5 seconds message we currently
On 2013-09-16 7:09 PM, Gabriel Wicke wrote:
Any of the entry points? Any new entry point? Anything we ever want to
put into the root?
We should be able to avoid most conflicts by picking prefixed entry
points. However, as we can't drop the clashing /w/api.php any time soon
I have removed the
On 17/09/13 11:08, Gabriel Wicke wrote:
On 09/16/2013 04:34 PM, Brian Wolff wrote:
Additionally there is some security issues in ie6 when doing foo?action=raw
if I recall.
Yes, IIRC some version of IE disregarded the Content-type header and
guessed the content type based on the URL and the
On 09/16/2013 07:24 PM, Daniel Friesen wrote:
On 2013-09-16 7:09 PM, Gabriel Wicke wrote:
Any of the entry points? Any new entry point? Anything we ever want to
put into the root?
We should be able to avoid most conflicts by picking prefixed entry
points. However, as we can't drop the
On Tue, Sep 17, 2013 at 2:09 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
So now only the conversion from
/w/index.php?title=foo?action=history
to
/foo?action=history
Do you mean:
to
/wiki/foo?action=history
?
is under discussion.
See also https://gerrit.wikimedia.org/r/51595 and RT#
I would suggest taking a look at the number of 404s caused by people trying
to access pages without the wiki prefix This would be interesting data
to go alongside this interesting proposal...
On 16 Sep 2013 20:01, Gabriel Wicke gwi...@wikimedia.org wrote:
On 09/16/2013 07:24 PM, Daniel
On 09/16/2013 07:48 PM, Tim Starling wrote:
On 17/09/13 11:08, Gabriel Wicke wrote:
Tim mentions in
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/49833#c3561 that
this only applied to IE3 and earlier, and IE4 respects the Content-type
header. As the market share of IE = 3 is probably
On 09/16/2013 08:48 PM, Jeremy Baron wrote:
On Tue, Sep 17, 2013 at 2:09 AM, Gabriel Wicke gwi...@wikimedia.org wrote:
/w/index.php?title=foo?action=history
to
/foo?action=history
Do you mean:
to
/wiki/foo?action=history
Yes, sorry. The RFC had it right, in case you read that ;)
50 matches
Mail list logo
