Wikitech-l June 2009

wikitech-l@lists.wikimedia.org

107 participants
80 discussions

Re: [Wikitech-l] flagged revisions
by private musings 20 Jun '09

20 Jun '09

Hi all, It's been 10 days since the last note on flagged revisions, which is sufficiently important to warrant a follow up at this point in my view. I'll try and focus the questions a bit in order not to pester, but with the intention of helping things forward; see https://bugzilla.wikimedia.org/show_bug.cgi?id=18244 for bug details. * Flagged Revisions is approved for use on the English Wikipedia, my understanding is that there really isn't that much technical work still to do on the extension - is this true? * Is there anything a regular editor such as myself can do to help prioritise this in the hearts, minds and fingers of our wonderful developers? * Personally, I believe this function to be one of the most important matters before the foundation currently, I further believe that this view is relatively widely held (and sure, widely reviled too - but this is a wiki, right!) - I've copied foundation-l in on this note with the intention of further general discussion occurring there, and bug-specific chat only on the wiki-tech list, I hope this is an appropriate use of resources :-) I've offered appreciation, a dollop of charm, and a little bit of money to try and keep this moving forward.... I'm not sure I'm above offering sex, so please throw me a bone for the sake of the decorum of these lists, if nothing else :-) best, Peter, PM. On Wed, Jun 10, 2009 at 12:46 PM, Gregory Maxwell <gmaxwell(a)gmail.com>wrote: > Am I confused or didn't enwp approved flagged revisions, but then it > was held up due to "purely technical reasons" ... what is this crap > now? > > ---------- Forwarded message ---------- > From: K. Peachey <p858snake(a)yahoo.com.au> > Date: Tue, Jun 9, 2009 at 10:29 PM > Subject: Re: [Wikitech-l] flagged revisions > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > On Wed, Jun 10, 2009 at 12:08 PM, private musings<thepmaccount(a)gmail.com> > wrote: > > with apologies for re-vitalising a slightly old thread -I have a couple > of > > follow ups, which it'd be great to try and make some progress on.... > > My understanding is that Aaron (whom I haven't 'met' - so hello!) has > > completed work on a test configuration of flagged revisions - I hope it's > > appropraite for me to ask directly on this list whether or not Aaron > > considers this development complete? (my understanding is that the > extension > > is pretty much ready to go?) > > There is understandably considerable interest in the timeframe for > > installing flagged revisions, I would hope it would be a positive step to > > set some timeframes a bit tighter than 'hopefully by wikimedia' ;-) - is > > this list an appropriate context for such discusison, and if so > (hopefullly) > > - could someone appropriately empowered flesh out the next steps a bit > more, > > and maybe try and establish a timetable of sorts? > > My intention in posting about this every so often is to ensure that such > an > > important development doesn't sort of slip through the cracks - I think > > communication on this matter has to date been ok, but not great - it'll > be > > cool to improve it a bit :-) > > cheers, > > Peter, > > PM. > The implementations depend on a per wiki basis depending on consensus, > for example, wikinews and a few others such as the German Wikipedia > already run it. > > The en.wiki is currently also looking at a slightly modified version > nicked named "Flagged Protections" which is basically designed to work > the same way protection does, articles are only covered by it when > protected to a certain level. > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

2 1

Collection / book extension tweaks
by Brion Vibber 19 Jun '09

19 Jun '09

Just a quick note y'all -- we've implemented bug 18902 so we can limit saving of collections to autoconfirmed users and above. Will be peeking at other issues with it over the next weeks. -- brion

1 0

Filtering and manipulating XML dumps
by Rolf Lampa 19 Jun '09

19 Jun '09

Hi all, I need some hints about how to go about to create a dump filter and a plugin for dumpBackup.php. Since I'm a Delphi programmer I'll probably do well the programming of the inner details, if I only knew how the stub for a filter (& a plugin) should look. I need to do quite extensive examination of the text content of articles before knowing what to keep and what to skip. Sometimes I'd like to even modify the text before dumping it. Hints about how to design a plugin would also be apprechiated. Options according to the dumpBackup.php file: --plugin=<class>[:<file>] --filter=<type>[:<options>] If anyone has done a filter or plugin before, or have a link to an example, I'd be very happy to take advice. :) // Rolf Lampa

3 4

removing rc_ip
by Daniel Kinzler 19 Jun '09

19 Jun '09

Hi all I wonder if the column rc_ip can be safely removed from mediawiki. As far as I know, it has been superceeded by the information in cu_changes, right? So I propose to a) either completely remove it b) or set $wgPutIPinRC = false per default c) and set $wgPutIPinRC = false for wikimedia projects. The rationale is that IP addresses should only be recorded if this is explicitly requested. In some jurisdiction (e.g. Germany) it is illegal to record this information without notifying the users, and there is a requirement to only record data at all if necessary. So it should be off per default. Many privacy-concious hosters disable IP records in the server logs, recording the IP in the database per default subverts this. As to disabling on Wikimedia projects: this would make things easier for the toolserver mainly. We don't need this info there, and having it might conceivably make WMDE the target of legal action. We can easily exclude cu_changes from replication, but we can't easily filter rc_ip from recentchanges. So it would be better if it wasn't there in the first place. Thoughts? Daniel

8 20

spam after subscribing to this list
by H. Langos 18 Jun '09

18 Jun '09

After being subscribed to the list for two weeks and posting three mails on one subject I received spam on the address that I used to subscribe/post. Either address harvesters are adapting to read the "name at domain" format that is used in the archive, or they auto-subscribe to mailinglists to get addresses from the traffic, or the news gateways leaks addresses, or whatever... I'll unsubscribe and put this address on my blacklist of burnt addresses. cheers -henrik

6 9

Re: [Wikitech-l] [Commons-l] Some reflections about the governance of Commons
by David Gerard 17 Jun '09

17 Jun '09

2009/6/15 Huib Laurens <Abigor(a)forgotten-beauty.com>: > I'm seeing a discussions or even multible discussions about how Commons > needs to change to be a better service project. But when Commons needs > to change, will we change all other projects also? There are still > images getting deleted because we couldn't get the source information or > other important information because the file was already deleted local, > there is a bug to give Commons adminstrators view permission for deleted > files globally, there has been a vote on Meta and still it isn't > activated (more than a year waiting time). Things like that will make > Commons also a better service project.. Or isn't that important enough? Yes, that's exactly the sort of thing Commons needs. (and this is something of what I meant when asking for constructinve suggestions on what to do to improve things - in both directions.) cc to wikitech-l - do you have a bug number for this? - d.

3 2

image link popup weirdness
by scs＠eskimo.com 16 Jun '09

16 Jun '09

I don't know anything about link preview popups, but does the issue discussed in this thread: http://en.wikipedia.org/wiki/Wikipedia:Help_desk/Archives/2009_June_12#.27A… indicate a buglet that could/should be fixed? Should the preview code know about <nowiki> in a way that it currently doesn't?

3 2

Global deleted image review (was [Commons-l] Some reflections about the governance of Commons)
by David Gerard 16 Jun '09

16 Jun '09

2009/6/15 Huib Laurens <Abigor(a)forgotten-beauty.com>: > Here is the page on meta: > http://meta.wikimedia.org/wiki/Global_deleted_image_review > That one links to the vote that passed with 80% support. > And for the bug: > https://bugzilla.wikimedia.org/show_bug.cgi?id=14801 Looks like there's code to implement it, but it isn't very good ... Is there an interested dev who could implement better code for this bug? We appear to have the consensus, we just need good enough magical incantations to implement it! - d.

4 3

Re: [Wikitech-l] Fixing problem with complete dumps in WikiXRay
by Felipe Ortega 15 Jun '09

15 Jun '09

OK, thank you guys. Now the reasons are clear :-). In any case, this forced the parser improvement, so it's welcome anyway ;). Best, F. --- El lun, 15/6/09, Platonides <Platonides(a)gmail.com> escribió: > De: Platonides <Platonides(a)gmail.com> > Asunto: Re: [Wikitech-l] Fixing problem with complete dumps in WikiXRay > Para: wikitech-l(a)lists.wikimedia.org > Fecha: lunes, 15 junio, 2009 10:44 > Felipe Ortega wrote: > > Hello, all. > > > > For (yet) unknown reasons, last complete dump files > (pages-meta-history.xml) in some languages are flawed. > Certain revision items are missing info about rev_user. Even > though there are only 3 or 4 of that kind, this is enough to > mess up either the parsing process or the later SQL load > into the DB. > > > > So far, the last 3 dumps of DE Wikipedia and 20090603 > from FR Wikipedia have presented this error. > > > > I have updated both WikiXRay parsers: > > http://meta.wikimedia.org/wiki/WikiXRay_parser > > http://meta.wikimedia.org/wiki/WikiXRay_parser_research > > > > They now probe whether the parsed revision item is > complete or not, before creating the SQL. If it's flawed, > its omitted and logged into an error file for later > inspection. > > > > Regards, > > > > Felipe. > > They're an effect of revdelete. > You can see how they have a parameter deleted. > An example is available in the bug for pywikipediabot: > http://sourceforge.net/tracker/index.php?func=detail&aid=2790339&group_id=9… > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

1 0

Fixing problem with complete dumps in WikiXRay
by Felipe Ortega 15 Jun '09

15 Jun '09

Hello, all. For (yet) unknown reasons, last complete dump files (pages-meta-history.xml) in some languages are flawed. Certain revision items are missing info about rev_user. Even though there are only 3 or 4 of that kind, this is enough to mess up either the parsing process or the later SQL load into the DB. So far, the last 3 dumps of DE Wikipedia and 20090603 from FR Wikipedia have presented this error. I have updated both WikiXRay parsers: http://meta.wikimedia.org/wiki/WikiXRay_parser http://meta.wikimedia.org/wiki/WikiXRay_parser_research They now probe whether the parsed revision item is complete or not, before creating the SQL. If it's flawed, its omitted and logged into an error file for later inspection. Regards, Felipe.

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l June 2009