After some review I'm thinking of eliminating Alias as the recommended way
of configuring short urls in MediaWiki and instead exclusively suggesting
the use of RewriteRules.
I reviewed how Alias seems to work and I can't see any real advantage at
all to using it. Certainly not enough to outweigh the disadvantages to
making it a recommendation.
- Internally Apache relies on a PATH_INFO based hack to handle Alias. With
Alias a /wiki/Article gets converted to DOCROOT/w/index.php/Article and
Apache goes through the PATH_INFO pattern of hunting down the location of
the php script. (This is basically a hack)
- Alias only works for 1 of the 4 possible Apache contexts. So it ends up
requiring us to make our documentation extra complex just to support it.
- Alias requires absolute paths while rewrites can take advantage of
%{DOCUMENT_ROOT}
The only advantage Alias has I can see is that from the outside it looks
like a simple one-line config.
It's been suggested in the past that Alias is faster but I have doubts
about that. Even if Apache shortcuts past the rewrite engine and any
regxps (which I have a feeling it doesn't) Alias involves Apache's
PATH_INFO handling which likely involves a number of stat calls and
filesystem IO just to find the location of the php script.
And in any case the php script will take much longer than anything apache
is doing so that kind of performance is really a moot point anyways.
To top off the issues with Alias, it can't be used to setup a 404 image
thumbnail handler and it can't be used in the future plans of MediaWiki
handling 404s internally.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
A somewhat cheeky subject line, I know, but I wanted to get people's
attention. Let me explain:
My team's job is to run experiments that tell us why Wikipedia editors
stay or leave.[1] One of the conclusions we've come to is that we have
zero data on how site performance impacts editor retention (IP editors
included).
We could throw all our energy into building cool new features, but if
people still have a frustrating experience because contributing is
appreciably slower than reading (for purely technical reasons), we
have no idea what the net loss is. We really need to know what the
numbers here are, not just assume that slower is bad in an
unquantifiable way.
We could get a measure of this by artificially slowing down the site
for a subset of users, but we'd rather not do that for obvious
reasons. So my proposal is this: if you're going to deploy anything
that you think might effect English Wikipedia site performance,
positive or negative, tell us beforehand and we'll measure its impact
on users for you.
--
Steven Walling
https://wikimediafoundation.org/
> Hi all,
>
> I'm Julien Dorra, I build creative communities using events. ex:
> http://museomix.com, http://artgameweekend.com, http://dorkbotparis.org,
> http://codinggouter.org.
>
> After a short discussion with Adrienne Alix from Wikimedia France, I took
> my chances and applied for the new role of Engineering Outreach Coordinator
> a few days ago!! Wish me luck!! (It's basically what I'm doing here in
> France with maybe the difference that we mix devs and non-devs, like
> designers and others professionals. We found that mixing is good for the
> cohesiveness of the communities built out of the events, because they are
> issue-oriented communities, mostly. Doing it for Wikimedia would be a dream
> job :)
>
> I also got a very nice answer from Sumana, encouraging me to "email this
> list with proposals/ideas of what the Wikimedia community ought to be
> doing" in term of engineering outreach.
>
> This application is a great occasion (excuse??) for me to divert some time
> and better understand the tech-side of the wikimedia community. I have
> collaborated with the non-tech side of the french community on issues like
> museum innovation and photography, but never directly with the tech-side of
> the community.
>
> I read with great interest the draft "Wikimedia Engineering/2012-13 Goals" (
> http://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals). It's
> super-rich and very exciting in term of focus.
>
>
> - - So, I wanted to start with a couple of questions I was curious about:
>
> 1. In term of outreach to engineers, devs or other technical talents, in
> your experience is there a specific community that is harder to reach to
> than others for Wikimedia?
>
> 2. Also, would like to see even more effort toward the students? (as in
> "the future professionals"!). What about the web startuppers? (AFAISee in
> Paris, they don't really consider Wikimedia as a software project.)
>
> 3. Do you sometimes think there is not enough ux designers on this list?
> And during hackatons? What about other skills?
>
>
> - - Then, to engage the conversation further, I wanted to test on you some
> specific ideas around hackatons and technical events ;-)
>
> The wider issue of testing, of setting up a more robust test culture is one
> of the key goals for 2012-2013, if I understand well.
>
> I personally know at least 3 developers that are passionate about testing,
> love to evangelize Test Driven Dev, and that might attend a test-oriented,
> or TDD-oriented event – but they would probably *not* attend a Wikimedia or
> MediaWiki generalist event. They have so many event to attend! They even
> organize events themselves…
>
> These 3 devs I know personnaly are the kind of test-oriented mentors we
> want to be part of the wikimedia community, if for a weekend or a week,
> because they are good at mentoring and showing the path to others.
>
> So, how can we bring them in?
>
> That made me (re)think about the limits of generic events, and the
> importance of issue-oriented event.
>
> The idea I would like to put up to discussion would be to organize more
> fine grained events around specific issues:
>
> «Testing Wikipedia» could be a nice catchy name for a series for events in
> various cities around TDD, with experienced dev mentoring less experienced
> community members, etc. Even if the experts come and go, everybody learn,
> some test and process get done, and the community grow and learn.
>
> Another issue is engaging other orgs, so why not engage startups:
>
> «Wikimedia for fun and profit!» Ok, this title is a joke -- but we should
> do a series of events focused on encouraging startups to build products on
> top of MediaWiki, APIs and Wikipedia sites. The rationale here is that the
> more startups invest on the wikimedia tech, the more they contribute in
> return.
>
> The documentation of MediaWiki is also an issue. Let's not wait to have a
> big team to launch more sprints, let's the sprints build the team:
>
> «DocDocDooooc Sprints» Realspace events are a powerful way to focus people
> on a goal. So to build a stronger documentation team, we could start
> designing an engaging and inclusive event format, setting up dates and
> places for a series of events. That could boost interest, and gather people
> that wouldn't have think of helping on MediaWiki. Of course the challenge
> is to keep the momentum going in between realspace sprints. So that means
> building an strong doc community online too.
>
>
> Obviously, setting up events, even small ones, takes a lot of effort!
> Scaling them can seems too much to do, too, when resources are limited.
>
> The good news is that we have successful examples of worldwide scaled event
> formats, like Startup weekend, Dorkbot. It's doable. And the rewards can be
> huge.
>
> So the strategy here would be to kickstart local chapters with recipes for
> events and by connecting them with I call 'serial-collaborators', (people
> that love to attend hackatons and creative weekends - they know a lot about
> these events, and are precious resource for advice and support).
> Identifying and contacting partners and places usually helps a lot, too,
> for helping first-time event organizers.
> Having a regular schedule for the local, issue-driven events help the
> community stay focused on the goals in between events.
>
> - - -
>
> Of course if I post here it's because I need feedback, and I might be
> overly naive, overlooking many things. Does it makes sense to you? What's
> your own ideas about events as community catalyzers?
>
> Let's discuss here –– you can also reach me on twitter :
> http://twitter.com/juliendorra
>
> Julien
Hi,
Best of luck with your application. Its always nice to see people who
are excited about what they do/want to do, and you seem to have
excitement in abundance.
> The idea I would like to put up to discussion would be to organize more
> fine grained events around specific issues:
I gather from what you said above that your specialty is in-person
events, but perhaps it would be interesting to have virtual events of
some sort via IRC focusing on a very fine grained topic. I'm not sure
how exactly that would work, but I think it might be interesting.
> 2. Also, would like to see even more effort toward the students? (as in
> "the future professionals"!). What about the web startuppers? (AFAISee in
> Paris, they don't really consider Wikimedia as a software project.)
I personally think (and I imagine many people think differently), that
perhaps retention rather than recruitment is what should be focused
on. After all, we power wikipedia. Wikipedia has a huge user base,
some of which know how to program, and many of those will at the very
least look our way, even if they don't explicitly drop in and say hi.
Those are the people we should attract. Even though probably 90% of
our contributor base come from a wiki project, I still think this is a
vastly untapped pool. People generally join open source projects to
scratch an itch (so the saying goes). The Wikipedians (not to mention
the oft neglected sister projects) are the one's who would be itchy.
In many ways I've noticed a trend where it seems people on some
projects, especially en Wikipedia, treat the foundation as more of a
"host" than an entity meant to serve their interests. As a result they
start to feel that MediaWiki is a product that is being developed
"for" them (in a similar way how something like facebook or google is
developed "for" its users) rather than "by" them (or by "their"
community). Maybe there was always such setiment, and I just never
noticed it in earlier times, but I find such sentiment disturbing. I
think in order to best reach out to new contributors, we need to start
at home so to speak.
Cheers, and once again best of luck,
--Bawolff
Hey,
I'm not sure whether anybody was aware of this, but the Doxygen
documentation at http://svn.wikimedia.org/doc has suddenly broken down.
It's still online, but all the actual class and function definitions have
disappeared.
*--*
*Tyler Romeo
*(Parent5446)
hello,
I'm reading Linker.php source.
I want to take a wikitext like this [{{fullurl:{{PAGENAME}}|
action=edit}} Edit this page]
edit it to get:
index.php?title=AddArticle&action=edit&preload=Template:one
And then I'd like to get only the href content in a php variable.
In Linker.php I have found a lot of private functions.
Can you help me?
I'm going to user $wgOut->redirect($url); for an internal link.
regards,
ADM
I'm getting 502 bad gateways / nginx error from all attempts to hit
WMF sites including en.wikipedia and wikimedia.org and others, right
now...
--
-george william herbert
george.herbert(a)gmail.com
Hi all,
how are you? I'd like to know about the possibility of solving an old
issue with CAPTCHA for Wikipedias in languages other than English.
This bug
https://bugzilla.wikimedia.org/show_bug.cgi?id=5309
was created in 2006. There is a discussion here about having CAPTCHA
in other languages from February 2012
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/51951/
but it seems there was no conclusion. After working on campus with new
editors in Brazil, I've checked this is a real obstacle, since most
people here cannot ready English at all.
I'd like to know if there are plans to solve this issue - I hope I
don't sound rude, maybe this can be a minor issue when we don't see
the difficulties people from a different place can face. I think this
is important for Wikipedias other than the English one (just read
people comments in the bug) and we can be loosing new contributors
because of their first impressions. Thanks,
Tom
--
Everton Zanella Alvarenga (also Tom)
Wikimedia Brasil
Wikimedia Foundation
Hi all,
here is our update on last weeks blocker email. Most of them are very
small, besides the well known gorrilas in the gerrit...
== Ongoing from last week ==
* Changeset <https://gerrit.wikimedia.org/r/#/c/14084/>, bug
<https://bugzilla.wikimedia.org/show_bug.cgi?id=38705> about adding
ll_local to the languagelinks table: as per discussion, there's a -2
from Tim Starling and further comments which were answered by Jeroen.
Awaiting either further reply by Tim, or a merge. Development of core
parts of our Phase I functionality is blocked by this, and not having
this merged is causing hassle for people that want to setup their own
working Wikidata repo-client install.
* Changeset <https://gerrit.wikimedia.org/r/#/c/14295/>, bug
<https://bugzilla.wikimedia.org/show_bug.cgi?id=38705> about handling
sites: Wikidata could benefit from some refactoring of the
interlanguage and interwiki link handling in core. The idea is to
migrate from the "interwiki" table to the new "Sites" facility. RobLa
mentioned that Chad seems to be working in a similar direction, but
haven't seen comments there. Besides that there were a few comments
going back and forth. A Postgres-compatibility is being requested by
saper, which will soon be added, but the question is are there any
further issues that prevent us from merging?
* Merging the Wikidata branch (ContentHandler) is still in discussion,
see <https://bugzilla.wikimedia.org/show_bug.cgi?id=38622>. Daniel
Kinzler hopes to have the discussion here on wikitech-l about this.
Right now there seems a bit of a confusion due to Gerrit (if you look
at the bug comments), but otherwise ongoing.
== New in the list ==
* Changeset <https://gerrit.wikimedia.org/r/#/c/8924/>,
'usecheckboxes' option implemented for HTMLMultiSelectField. Helps us
with displaying some preferences nicely with a scrollable
multiselect-list. Hanging around for a while and needs review and
merge. Some discussion last week.
* New hook 'AfterFinalPageOutput' which is called at the end of
OutputPage::output() <https://gerrit.wikimedia.org/r/#/c/14303/>: Got
a little stuck and is required by the STTLanguage extension. (in
parallel, this is in the Wikidata branch of core already, but would be
removed from there if accepted here).
* Linker::link() handles strings in $query parameter properly now,
changeset: <https://gerrit.wikimedia.org/r/#/c/14301/>. Some concerns
were raised whether this should be fixed in other places instead.
Fixing this in all other places and especially testing it there could
be rather expensive. This is required by the STTLanguage extension. If
this isn't fixed, the function might fail in some places, e.g. on the
latest changes page. (in parallel, this is in the Wikidata branch of
core already, but would be removed from there if accepted here)
* A change to the skin that will allow us to add the description of an
item: changeset <https://gerrit.wikimedia.org/r/#/c/17073/>. There
discussion and development is ongoing.
I hope this helps,
Cheers,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Announcing the Wiki Loves Monuments Android App, V1.1 beta 1!
This app enables mobile monument discovery and photo uploads for the first
time, both in terms of mobile functionality overall and for the Wiki Loves
Monuments contest.
Please turn on "Unknown sources" in Settings => Applications, click on the
link below and install. Then go out and take lots of photos! Uploads will
go to test wiki so feel free to upload whatever you like (and want to share
with the world).
http*://* <http://bit.ly/OFS82I>bit.ly/wlmappv1 <http://bit.ly/OFS82I>
This is the first public release and is not quite feature-complete.
Comments and bugs can go on this page:
http://www.mediawiki.org/wiki/Wiki_Loves_Monuments_mobile_application/Feedb…
Please try the following:
* Browse by campaign (this will become browse by country/region/city)
* Sort the list by name and address
* Search with a search term
* Open a monument, click on "Get directions"
* Click on add a photo
* Login or create a Commons account
* Choose from gallery or take a photo
* Start uploading
* Go back to the opening screen
* Click on "Use my current location"
* Move around the map, open a cluster (a group of monuments close together)
* Click on a pin, open the monument
* Add a photo (login should be retained)
* Start uploading
Let us know what you think!
Known issues:
* Browse by country/region/city not fully implemented
* Full-text search is slow
* Map attribution is missing
* Sort by distance appears when browsing by country
* List view should have a "more" link when lists exceed 100 monuments
* Map view will have two types of pins to distinguish monuments with and
without photos
* Upload later is not yet implemented
Please forward this email as appropriate.
Initial distribution: mobile-l, wmfall, internal-l, wikitech-l
--
Phil Inje Chang
Product Manager, Mobile
Wikimedia Foundation
415-812-0854 m
415-882-7982 x 6810
hello,
I'd like to do thinks in the better way...then:
I have to made an extension similar to BoilerTemplate.
Right now I made a special page and I'd like to put in a form to let
user choose a teplate.
Some questions:
1) Must I use some apis to render the form?
2) How to set the form target? Hidden input tags are a good solution
but: how can I have a clean urls ready form?
I'm ready to read any tutorial you can suggest me,
thanks for your attenction,
ADM