On Thursday, 31 January 2013 at 13:33, rupert THURNER wrote:
many thanks jon! personally i do not like that the qrpedia domain is registered cloaked, so nobody knows what comes out there later on. this, and the long time the topic could not be settled is imo enough to consider the name "qrpedia" as poisoned.
maybe it's best to just leave qrpedia to the people who registered it and use another domain. qrcodes pointing to some website which then redirects to some url is no rocket sience, and widely used since quite a long time.
at WMCH we use qrcodes at least in two working groups, international (tunesia e.g.) and GLAM. they are important to us, and i'd consider it high risk to mount qrcode stickers physically which then link to a site which has a cloaked owner. if qrpedia in 2 years time links to pussy galore there is huge cost involved to change all the stickers installed, beside the enormous reputational damage.
If no agreement is forthcoming regarding QRpedia, it would be sensible to build an extension for MediaWiki that did HTTP header-based language content negotiation, and use that MediaWiki extension (or core modification, perhaps) on the various Wikimedia projects, such that the URIs produced are actually on wikipedia.org (and any other WMF projects like Wikisource).
As the source code for qrwp is MIT licensed and available on Google Code, it would be fairly trivial for a MediaWiki hacker to build the functionality into MediaWiki itself.
One would have to be careful legally as MediaWiki is GPL2 licensed, but the Software Freedom Law Center has a guide on how to maintain code that is "permissively licensed" (which includes MIT licensed code) with GPL modifications. See ยง2.2:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.htm...
I know that there is a general strategy in Wikimedia tech circles towards trying to unify codebases and centralise the running of technical services. The plans to close the Toolserver and transition the services running on there from WMDE to WMF is one example of that.
If Wikimedia UK are unable to bring the QRpedia business to a sensible conclusion, porting it to be an internal rather than external function of MediaWiki would be a relatively straight-forward project for a programmer to do.
One of the benefits of providing HTTP header-based language content negotiation (what a mouthful) through MediaWiki itself rather than through an external service is that currently QRpedia stores accesses of QRpedia URLs in a database. Each time a user accesses a QRpedia URL, their IP and the Wikipedia URL they are directed to is stored in a database.*
I am confident that the data is not being used illegitimately by Roger or Terence. But ideally, a Wikimedia-affiliated service would not store this kind of information given the Foundation's privacy policy. Ensuring complete compliance with WMF privacy policy seems like a pretty compelling reason to bring QRpedia in-house or build an internally-supported replacement running on top of MediaWiki.
In addition, having language content negotiation done on the MediaWiki side means that these things can be easily modified by engineers working for the Foundation for compatibility and better integration with new developments in mobile (smartphone apps, Wikipedia Zero etc).
* The function 'writeLog' in config.php https://code.google.com/p/qrwp/source/browse/trunk/config.php which is called on line 107 of index.php https://code.google.com/p/qrwp/source/browse/trunk/index.php before redirect to Wikipedia.
-- Tom Morris http://tommorris.org/