Wikitech-l March 2012

wikitech-l@lists.wikimedia.org

155 participants
204 discussions

22 Mar '12

Hi everyone, MediaWiki core and WMF-deployed extensions are now completely read-only in SVN--please begin submitting your changes through Gerrit now for those projects. Might be a few minor issues to iron out (.gitreview files aren't everywhere just yet), so feel free to ping me on IRC if you have any questions. -Chad

2 1

Video codecs and mobile
by Brion Vibber 22 Mar '12

22 Mar '12

As some may know, we've restricted videos on Wikimedia sites to the freely-licensed Ogg Theora codec for some years, with some intention to support other non-patent-encumbered formats like WebM. One of our partners in pushing for free formats was Mozilla; Fire fox's HTML5 video supports only Theora and WebM. The prime competing format, H.264, has potential patent issues - like other MPEG standards there's a patent pool and certain licensing rules. It's also nearly got an exclusive choke hold on mobile - so much so that Mozilla is considering ways to adopt H.264 support to avoid being left behind: http://blog.lizardwrangler.com/2012/03/18/video-user-experience-and-our-mis… Is it time for us to think about H.264 encoding on our own videos? Right now users of millions of mobile phones and tablets have no access to our audio and video content, and our old desktop fallback of using a Java applet is unavailable. In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users. What do we think about this? What are the pros and cons? -- brion

19 46

WURFL licensing concerns and Git migration
by Kevin Israel 22 Mar '12

22 Mar '12

Our MobileFrontend extension, which is currently deployed on Wikimedia sites, uses WURFL to detect the mobile devices it targets. However, I recently became aware the version of the WURFL data files we use has a rather restrictive license. http://tech.groups.yahoo.com/group/wmlprogramming/message/34311 The license seems to suggest we are not even supposed to redistribute verbatim copies or install the data files on multiple servers rather than only making "[...] one copy [...]", if not merely fail to grant such permission. Currently, the files are in our Subversion repository and are going to end up in Git soon. I am not a lawyer, and I realize this is probably a matter for the Wikimedia Foundation to handle, albeit one of urgent importance to us. If I am not mistaken, proper removal of infringing material from Git repositories is somewhat painful in that it causes all child SHA-1 hashes to change, so I feel resolution of the above licensing concern blocks Git migration of at least the MobileFrontend extension. -- Wikipedia user PleaseStand http://en.wikipedia.org/wiki/User:PleaseStand

7 7

Gadget copy script
by mah＠wikimedia.org 21 Mar '12

21 Mar '12

In the past few months, I've needed to test gadgets that are used on WMF sites, but didn't have an easy way to copy them from, say, Commons to Beta in Labs. I hacked something together and then forgot about it until Chris McMahon (the WMF's new QA guy) wanted something similar for one of his test wikis a couple of weeks ago. I couldn't find it, so last night I rewrote the script from scratch. The script is pretty ugly and, normally, I might commit it to SVN and work on it there, but we're in the process of moving to Git, so I've gone ahead and created a gitorious repository: https://gitorious.org/wiki-gadgets Lots of hard-coding that could be cleaned up, and it could use the API to copy from one wiki to another, but its a start. I'm sharing it here so that other people can begin to use it. It just blats the import-able file out on standard output for now, and it only copies from Commons, so it should be used in the following way: $ php dupe-gadgets.php > import-this-file.xml [ Go to Special:Import on your wiki and import. ] I hope that it helps someone! -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

2 2

Re: [Wikitech-l] [Mediawiki-l] New Plugin for Extension:ConfirmEdit - RFC
by nischay nahata 21 Mar '12

21 Mar '12

Thanks for your replies, I realize this is a faulty plugin right now for following reasons * 25% probability * securing the questions and answers I will see if I can remove them, again this is my first plugin and I am trying to learn so my apologies :) -- With Regards Nischay Nahata B.tech 3rd year Department of Information Technology NITK,Surathkal

5 7

Federated Login to Wikipedia. Re: OAuth
by Andreas Åkre Solberg 21 Mar '12

21 Mar '12

John Erling Blad pointed us to this thread. I was not subscribed to the list, so I'm sorry that this repond probably creates a new thread. We, UNINETT, operates Feide, the norwegian Identity Federation for students from lower and higher education and research institutions in Norway. Feide would allow services, like Wikipedia, to verify end users (with some additional user data, like userid, email and name etc) using the SAML 2.0 protocol. The end users will then login on their instituion login page using their institutional credentials, they will also have single sign-on to other sites. We also maintain the software package SimpleSAMLphp, that implements the various roles in the SAML 2.0 protocol architecture, including support for acting as a Service Provider, which will be the relevant role for a service like Wikipedia. SimpleSAMLphp is implemented in PHP, and while we are not maintaining mediawiki extensions to integrate with others, I believe others have done some efforts: http://www.mediawiki.org/wiki/Extension:MultiAuthPlugin http://www.mediawiki.org/wiki/Extension:SAMLAuth SimpleSAMLphp is one of many open source products implementing SAML. We have a good contact network of other educational Identity Federations across the world, and in particular Europe and US. We have been part of two initiatives for allowing service provider to connect to a wide range of Identity Federations (at once), including GEANT eduGAIN and Kalmar2. http://www.geant.net/service/edugain/pages/home.aspx https://www.kalmar2.org Identity Federations, like Feide, can provide: * verified accounts, something that may help controlling trolling. * user convenience of not having to register or maintain another set of credentials, + the convenience of SSO. If you are interested in doing a pilot with connecting wikipedia to Feide, we may provide you with further details to proceed with that. The user centric Identity Federation paradigm, represented by protocols like OpenID (and others), will (usually) not provide you with verified accounts, but still get you the user convenience of SSO and re-use of existing account. OpenID has went throuh a few versions, 1.0 and 2.0, and currently OpenID Connect is beeing sorted out. OpenID Connect differs signficantly from earlier versions since it is built upon OAuth (a good thing). We're also a bit involved with the OpenID Connect standardization. As part of the GÉANT Identity Federation project in collaboration with Kantara Initative, we will be responsible for implementing an automated interoperability test facility for OpenID Connect, like this: http://www.youtube.com/watch?v=3mGA79T0hPg OAuth "alone" can not provide authentication of users to Wikipedia from external sites. But, it can be used to grant a user authorization to wikpiedia content through a back-channel REST API (without exposing credentials through this api). I believe that was the idea that this thread started with, which seems like a very good idea, but a very different idea than offering federated login. OAuth also exists in multiple versions, and I think it would be reccomended to go for OAuth 2.0 for any new projects that have not supported earlier versions of OAuth. Andreas Åkre Solberg UNINETT AS - http://rnd.feide.no

3 2

Etherpad bug
by Samat 21 Mar '12

21 Mar '12

If I am writing to a wrong address, please let us know. I used etherpad for a long time without any problem. Now, if I open an etherpad window (etherpad.wikimedia.org) I got this message after a few second: "Disconnected. *Lost connection with the EtherPad synchronization server.* This may be due to a loss of network connectivity. If this continues to happen, please let us know<http://etherpad.wikimedia.org/ep/support>(opens in new window)." If I reconnect, this happen again after a few second. My internet connection work properly. If I click "let us know", I got an other error message: "Oops! A server error occured. It's been logged. Please email <support(a)etherpad.com> if this persists." Does this problem come from my computer (which is a new one and I have never used etherpad on it)? Should I write a message to support(a)etherpad.com or how could I use etherpad? Thank you for your help. Best regards, Samat

2 2

integrating who's been awsome to MediaWiki
by Eranga Mapa 21 Mar '12

21 Mar '12

Hi Sumanah Still I did not hear from James Can you look into this matter. When can I get a space to host my extension in Git??

3 3

FW: Topic Maps
by John McClure 21 Mar '12

21 Mar '12

-----Original Message----- From: John McClure [mailto:jmcclure@hypergrove.com] Sent: Wednesday, March 21, 2012 4:48 AM To: 'Yury Katkov'; 'Wikimedia developers' Subject: RE: [Wikitech-l] Topic Maps Yury, Sure SMW certainly could be part of a solution especially using subobjects from v1.7, but this suggests WP isn't intended to have something as basic as a subject-index itself because SMW is apparently not on WP's roadmap. If WP doesn't record topics for its articles, then WP cannot fully leverage its library of data in the semantic web. IMHO I think the semantic web is more fruitfully about merging and contrasting topic maps than resource descriptions. On implementation, I see two parts. First, are hierarchical subject indexes (such as the LCSH)based on SKOS [3] and second are topic maps that are roundtripped XTM v2.0 [2] within the scope of <page> elements. "All the other" plumbing is significant enough though to make this work. For instance, I'd consider requiring "type" designators in XTM stream to be names of (aliased+actual) namespaces. The suggests a more dynamic namespace manager which I know has been kicking around for awhile. Bottom line if SMW were to be incorporated into WP then it's a fine idea to use SMW to hold topic data. If not, I am concerned that platforms without semantics don't seem sustainable over the long haul. [1] http://en.wikipedia.org/wiki/Topic_Maps [2] http://www.isotopicmaps.org/sam/sam-xtm/ [3] http://www.w3.org/TR/skos-referenc Thank - John >-----Original Message----- >From: ganqturgon(a)gmail.com [mailto:ganqturgon@gmail.com]On Behalf Of >Yury Katkov >Sent: Tuesday, March 20, 2012 7:50 PM >To: jmcclure(a)hypergrove.com; Wikimedia developers >Subject: Re: [Wikitech-l] Topic Maps > > >Hi John! Could you provide some links on how the Topic Maps are used >in modern wikis and information systems? >There is a big family of Semantic Extensions [1] that allow to export >wikipages to RDF, isn't this enough? > >[1] http://semantic-mediawiki.org/wiki/Help:SMW_extensions >----- >Yury Katkov > > > > >On Wed, Mar 21, 2012 at 6:53 AM, John McClure ><jmcclure(a)hypergrove.com> wrote: >> Adding Topic Maps to MW base software could be a winner -- >it can generate a >> wiki-site map (some think WP needs one!); it can be used to >corelate the >> contents of documents loaded into a wiki (like conference >proceedings) with >> a wiki's topic map; and would make a cool tool for any page >in a wiki, most >> clearly on a user page. It's perhaps a smart strategic move >- ISO 82250 >> Topic Maps are the fruit of SGML/Hytime n-ary models that >'lost' to RDF >> triples back when. Being a superset of RDF, TMs can type associations >> between articles while capturing all infobox data. >> >> Topic maps may be a compelling FUNCTIONAL upgrade for MW as >it captures >> subjects of an article for the first time. Given topic-map >to RDF transforms >> amid continuing W3 research, this could be enough for the >semantic world. By >> adopting say the Lib of Congress' Subject Headings, a wiki >like Wikipedia >> could play an important role in the semantic web. The >current situation with >> Wikipedia is that it's hard to have a large library of >information without a >> subject catalogue... right now, wikis have an author >catalogue sort of, fine >> for smaller hadcrafted wikis but doesn't scale well for many. >> >> Since other platforms now have maturing topic map extensions >I'm worried the >> impact on wikis not to have that technology. >> >> John McClure >> >> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2 1

Re: [Wikitech-l] [Labs-l] Multiple collation support (was: New project request)
by Liangent 21 Mar '12

21 Mar '12

On Mon, Mar 19, 2012 at 12:23 AM, Bawolff Bawolff <bawolff(a)gmail.com> wrote: >>Message: 1 >>Date: Sun, 18 Mar 2012 13:02:53 +0800 >>From: Liangent <liangent(a)gmail.com> >>To: "A list for announcements and discussion related to the Wikimedia >> Labs project." <labs-l(a)lists.wikimedia.org>, Wikimedia developers >> <wikitech-l(a)lists.wikimedia.org> >>Subject: Re: [Wikitech-l] [Labs-l] New project request >>Message-ID: >> <CAJ23o9ijb2TrfW6Gk+XTaVZQwHfoST0M4EE2UD4A5xcmdXVLdQ(a)mail.gmail.com> >>Content-Type: text/plain; charset=UTF-8 > [..] >>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. > > Hmm interesting. I could definitely see how it could feel "natural" > that this be in core. I could also see fairly good arguments for it > being an extension. Either way I think it should (ideally) > integrate with the categorylinks table. As it stands though, the > unique index on (cl_from,cl_to) would probably prevent that [change to > a unique index on cl_from,cl_to,cl_collation?]. Otherwise I don't see > any major hurdles. If going the extension route, hooks can always be > added if there are not enough. Some maintenance scripts would have to > be changed, and some changes to the Collation class would have to be > made, but I don't think they would be super-complicated changes by any > means. > > On a related note, there's also a bug that wants sort collations to be > specified per category (but still only 1 collation to a category) - > https://bugzilla.wikimedia.org/show_bug.cgi?id=28397 > > -bawolff This is my quick work and I'll push it for review after Git migration. Comments are welcome. -Liangent

1 1

← Newer
1
...
7
8
9
10
11
12
13
...
21
Older →

Jump to page:

2026

2025

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 March 2012