Hello everyone,
in the past weeks, I put together "xmldumps-test"---a test suite for
Ariel's xmldumps-backup software. xmldumps-test tries to assure that
the MySQL database, MediaWiki, and xmldumps-backup play nicely
together.
xmldumps-test injects data into the database (so do not use it on a
live database), starts xmldumps-backup, and compares the generated XML
dumps against pre-verified data.
Using xmldumps-test I hope to catch problems caused by modifications
to MediaWiki or xmldumps-backup /before/ they hit Wikimedia's
production servers dumping enwiki, ...
The code is up for review at
https://gerrit.wikimedia.org/r/p/operations/dumps/test.git
.
README serves as general point of entry to the documentation.
README.installation shows you how to set up xmldumps-test.
After setup is completed,
./run_tests.sh
runs all available tests.
xmldumps-test comes with tests for REL1_1{7,8,9} and trunk.
I'd love to get some feedback, or comments on the scripts.
Best regards,
Christian
--
---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65a Email: christian(a)quelltextlich.at
4040 Linz, Austria Phone: +43 732 / 26 95 63
Fax: +43 732 / 26 95 63
Homepage: http://quelltextlich.at/
---------------------------------------------------------------
(cross posting to wikitech-l)
On Sun, Mar 18, 2012 at 2:26 AM, Ryan Lane <rlane32(a)gmail.com> wrote:
> I've created a project called category-sorting for you.
>
> On Sat, Mar 17, 2012 at 10:41 AM, Liangent <liangent(a)gmail.com> wrote:
>> Hi,
>>
>> The zhwiki community started a discussion about category sorting
>> again[1], which was what Extension:CategoryMultisort[2] designed for.
>> However in MW 1.17+ it should be re-written to make use of the new
>> Collation component. I plan to do it later (maybe after Git migration,
>> as a new extension because it need to be written completely in another
>> way) and I want to use Labs so the community can see the current
>> developing progress. Can someone create a project for me?
>>
>> [1] https://zh.wikipedia.org/wiki/Wikipedia:%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%8…
>> [2] https://www.mediawiki.org/wiki/Extension:CategoryMultisort
What do you think is a better approach to implement this? In 1.16
version I had to create another DB table but in modern MediaWiki,
categories have better sorting support so another choice (which seems
more natural) is to patch MediaWiki and change $wgCategoryCollation to
an array to support multiple collation at the same time. Maybe another
choice is to reuse the existing categorylinks table in an extension
but this requires MediaWiki to have enough hooks.
>>
>> -Liangent
>>
>> _______________________________________________
>> Labs-l mailing list
>> Labs-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
> _______________________________________________
> Labs-l mailing list
> Labs-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
-Liangent
> Message: 4
> Date: Fri, 16 Mar 2012 10:31:56 -0700
> From: Rob Lanphier <robla(a)wikimedia.org>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Subject: [Wikitech-l] Mark Hershberger departing Wikimedia Foundation
> in May
> Message-ID:
> <CAPzpXh6xKcwnJ04JqMO7YcanHYUYSvtH-f3kaJv5xUO-YV5nkQ(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi everyone,
>
> I regret to inform you all that Mark Hershberger will be leaving the
> Wikimedia Foundation at the end of May.
>
> Mark started as a contractor at the beginning of 2010, helping the
> Wikimedia Foundation with code review and the release process. He
> developed an interest in our testing infrastructure, and was
> responsible for some of the early work in phpUnit and Selenium
> integration in our codebase. In early 2011, we reconceived his role
> here at the Foundation, asking him to step into the role of
> Bugmeister. During the past year and a half, Mark has undertaken the
> daunting task of going through the mountainous backlog of bug reports
> and patches, as well as the incoming stream of new bugs.
> Additionally, he has pushed us to review our backlog of code review
> through three deployments now.
>
> Mark has been a passionate advocate for community developers, and
> hasn't shied away from asking for what they need. He has been a
> friendly and approachable representative for WMF; enthusiastic and
> cheerful with everyone he deals with. Thank you, Mark, for setting
> this example!
>
> We plan to start recruiting for a new Bugmeister soon. I'll post more
> details when I have them.
>
> In the meantime, please join me in thanking Mark for his service to
> the Wikimedia movement.
>
> Rob
:'(
You will be very deeply missed. I wish you the best of luck in
whatever you decide to do next.
-bawolff
I set up Bugzilla today so that, by default, bugs would be in the
"UNCONFIRMED" state.
Next week, I plan to begin recruiting volunteers for the "Bug Squad",
who will help me to verify bugs by testing them against the Beta
cluster. The plan is that the Bug Squad will be able to verify these
bugs and change them to the "NEW" state.
The Bug Squad idea comes from KDE's Bug Squad
(http://techbase.kde.org/Contribute/Bugsquad) and I've begun talking
with them.
If you have an interest in helping out with or participating in the Bug
Squad, please contact me.
--
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
mah(a)wikimedia.org
Reminder to get your Wikimania program submissions in soon!
The deadline for submissions is Sunday, March 18 at 11:59 (San Francisco)
Pacific Daylight Time (or 06:59 UTC on 19 March 2012).
We seek submissions for presentations, workshops, panels, and other types
of sessions.
We want the technical track to be the best possible and we need your help!
We want submission on various aspects of MediaWiki technology, mobile
apps, operations, and more.
How do we make Wikipedia scale? visual editor? Wikipedia and wiktionary
mobile apps, wikidata, semantic mediawiki, GLAM tech, toolserver projects
and tools, MediaWiki extensions, OpenStreetMap and other maps/geo,
Wikimedia labs, and everything else that I'm forgetting to mention. :)
Among all these topics, we're also interested in highlight accessibility as
a topic for presentations and during the hackathon.
You can view the call for participation and make submissions here:
http://wikimania2012.wikimedia.org/wiki/Submissions
Don't forget there will also be a hackathon during the preconference:
http://wikimania2012.wikimedia.org/wiki/Hackathon
Cheers,
Katie
--
President, Wikimedia District of Columbia
http://wikimediadc.org
@wikimediadc / @wikimania2012
Hi.
I occasionally get asked about what a reasonable rate for querying the API
of a Wikimedia wiki is for a particular script or tool. I don't really know
the answer other than "be reasonable" and "specify an informative
User-Agent." That's essentially what I said when asked here:
https://meta.wikimedia.org/w/index.php?title=Tech&diff=3569658&oldid=3569474
If there's an authoritative answer (on Meta-Wiki or mediawiki.org or even
wikitech), that'd obviously be ideal. I'd also settle for a mailing list
post. I looked at <https://www.mediawiki.org/wiki/API:Main_page> to see if
it mentioned "limit" or "rate", but nothing came up. It's a fairly common
question; it should probably be a bit easier to find.
MZMcBride
Over the last couple of weeks, I've taken a few steps to remove some of the
WMF-specific bits of the MobileFrontend code base:
https://bugzilla.wikimedia.org/show_bug.cgi?id=34144https://bugzilla.wikimedia.org/show_bug.cgi?id=34145
Also, now if you view an article with "useformat=mobile" in the URL's query
string, MobileFrontend will keep the mobile view enabled as you browse page
to page until you explicitly exit the mobile view.
While MobileFrontend has now been generalized enough to be used beyond the
WMF cluster, there are still quit a few things that could be done to
improve the ease of out-of-the-box usage. For instance, adding configurable
WURFL support (which I believe should be fairly straightforward - this is
out of date but the same idea should still work:
http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057478.html)
or making it possible to use path-based modifiers to signify mobile view
(eg http://mywiki.com/wiki/Article -> http://mywiki.com/wiki/m/Article -
https://bugzilla.wikimedia.org/show_bug.cgi?id=35178).
It would be great if anyone can help test/provide feedback for the changes
that have been made, and especially if anyone wants to help add the
features mentioned above!
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
Hi,
>From the very beginning, there is a problem in the PDF Download tool and
that is it can not properly render the Bengali and some of the other Indic
languages (might be all Indic languages). A few bug was reported earlier
and the developers tried to solve the issues but unfortunate it was not
completely fixed.
Here i have a question that at this moment is there any developer of
developer group is working on this issue? if yes then i want to join with
him. But is no one is engaged with it then is is possible to apply GSoC for
this issue.
I am involved with the Wikimedia Bangladesh and within a short time we are
going to arrange outreach programs outside of the city area. For that
purpose the offline version will help us a lot. That is why i am
interested.
regards
nasir khan
--
*Nasir Khan Saikat <http://profiles.google.com/nasir8891>*
What is our policy/best practices on code needed by several
extensions? Does it make sense to integrate such code into core?
For example, my current situation: there is a class in MobileFrontend
that performs reformatting of HTML: remove some tags depending on
their ID/class and so on. MF uses it to make page content more
suitable for mobile devices. At the same time, it can be used for
other transformations such as getting plain-text extracts of articles.
Consequentially, producing such extracts is currently part of
MobileFrontend although such functionality should belong to a separate
extension (and why not core?). So if I want to use this functionality
in several extensions, they should either depend on one of them or some
meta-extension, both of these would be inconvenient.
The question is: does it make sense to integrate this class into MW
core? Its code can be seen at
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/MobileFrontend/H…
while its mobile-specific descendant class can be used as an example
of its practical application:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/MobileFrontend/M…
--
Best regards,
Max Semenik ([[User:MaxSem]])