I am wondering if interwikis can be be more powerfully leveraged.
For instance, I'd like much to say ZZZ:my_ns:my_page to indicate a page in a
particular subset of pages within a namespace in my wiki. Ultiimately an ACL
can be associated with each interwiki descriptor.
And although I haven't tested this, does anyone know if a 'local' interwiki
link (one mapped to the local wiki) is *supposed to* resolve to the local
wiki?
Thanks
from foundation-l thread "[Fwd: Re: Do WMF want enwp.org?]"
On Tue, May 17, 2011 at 11:27 PM, Casey Brown <lists(a)caseybrown.org> wrote:
> On Tue, May 17, 2011 at 9:24 AM, Lodewijk <lodewijk(a)effeietsanders.org> wrote:
>> Of course
>> unless someone finds a way to redirect en.wikipedia.org/Example to
>> en.wikipedia.org/wiki/Example .
>
> "Did you mean to type http://en.wikipedia.org/wiki/Example? You will
> be automatically redirected there in five seconds."
>
> :-)
>
> It already redirects there, though we don't want to advertise that we
> have a "link shortener" because the 404 page redirects.
Is there a good reason for us to always include the '/wiki/' in the URL?
Removing the prefix would save five characters, and I'm guessing that
it would also save a measurable amount of traffic serving 5KB 404
pages.
Is there something else on these virtual hosts other than a few
regexes which are extremely unlikely to be used as page names (i.e.
\/w\/.*\.php).
--
John Vandenberg
Luiz Augusto <lugusto(a)gmail.com> writes:
> Firstly, thank you very much for enabling DPL on all Wikisources! [1] It is
> IMO a pity that this request was fulfilled based only in a direct request,
> but at least it is now enabled.
>
> Please help us to develop Wikimedia contents in foreign languages simply
> giving 30 minutes each week to check those requests!
30 minutes a week would be less attention than they are currently
getting.
The Berlin Hackathon, was especially helpful in taking care of some of
these shell requests. Take a look at http://hexm.de/2w for a list of
requests closed during the hackathon. Of special note is Bug #5220
(https://bugzilla.wikimedia.org/5220), the request to “Enable email
notification on changes to user talk pages also on big wikis.” It has
been left for YEARS, much longer than any other request you mention.
There is hope for every bug, no matter how old.
However, I admit I have been giving non-shell requests a bit more
attention in my bugmeistering because the people with shell access are
pretty good about dealing with the requests. For example, of the 20
shell requests opened this month, only 12 have not yet been dealt with,
which means 40% of shell requests opened in the past two weeks are
already completed.
By comparison, only 85 of the 256 shell requests created since the first
of the have not yet been closed, so 67% of the shell requests opened
this year are completed.
That said, many of the open requests are open for a reason. For
example, the LiquidThreads request that you list:
> 25609 <https://bugzilla.wikimedia.org/show_bug.cgi?id=25609> Enable
> liquidthreads for the Wikimedia Brasil wiki (waiting since 2010-10-21)
is open because Andrew's LQT rewrite is ongoing. Last time I checked in
with Andrew on this, he was finishing up the backend rewrite. That was
at Easter, though, and I haven't checked back in on the LQT project to
see when we could start deploying it again.
You've made a good point, though, and I'll be working with CT Woo and
the operations team to make sure these requests get attention in a more
timely manner.
Mark.
Hi,
yes, I fully agree to take over the OpenID things from Sergey Chernyshev.
Someone already assigned me as maintainer (ok), and would like to ask
all of you "to bear with me" and to help me, especially in the code review.
I created these easy-two remember self-explaining shortcuts:
http://hexm.de/openid/codereviewhttp://hexm.de/openid/bugs (*)
Tom
(*) alias for the previously mailed: http://hexm.de/2v
We had a whole bunch of folks who've had their hands in the world of
MediaWiki parsing & rich text editing here at the Berlin Hackathon, and made
some great progress on setting out some ideas for how to start actually
working on it.
Tomorrow I'll distill our session notes into a clearer description of the
core ideas & next steps (dare I say... a manifesto? :)
In the meantime, if you're brave you can peek at the raw session notes:
http://etherpad.wikimedia.org/mwhack11Sat-Parser
We're reviving the wikitext-l mailing list for people interested in the
project; it's gotten some traffic about interesting projects but we'll be
making it an active working group. I'll also be making regular posts here on
wikitech-l, on the Wikimedia tech blog, and on the wikis -- but I don't want
to clutter wikitech-l *too* much with the nitty-gritty details. ;)
Project hub pages will go up tomorrow at
http://www.mediawiki.org/wiki/Future
-- brion vibber (brion @ wikimedia.org / brion @ pobox.com)
Sergey Chernyshev <sergey.chernyshev(a)gmail.com> writes:
> I'd like to step down as maintainer for OpenID extension.
> Please remove me as maintainer from Bugzilla.
I've removed you.
For other developers who may be interested, there are currently 16 open
issues against OpenID in Bugzilla: http://hexm.de/2v
Mark.
Hi everyone,
Just dropping a note to let people know that I've merged and deployed r85128--
reverting hiding logs of all autocreated accounts. As pointed out on bug 19161
(specifically, comment #46), this solution was overkill and failed to actually
address the underlying concern.
Fixes for the original bug are certainly welcome, but lets not use a
sledgehammer where we could've used a screwdriver.
-Chad