Wikitech-l August 2013

wikitech-l@lists.wikimedia.org

133 participants
130 discussions

VE/Migration guide for gadgets developers
by Eran Rosenthal 25 Sep '13

25 Sep '13

Hi, When the ResourceLoader was deployed (or even before it) to production, there were migration development guides for gadget/extension developers: - http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_… - http://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader Such guides allowed easier adoption of ResourceLoader. We need something similar for the visual editor: - Migration - What are the recommended steps to make gadget/extension VE adapted? [with answers to questions such as: how to get the underlying model - instead of $('#wpTextbox1').val() and what is this model [and what modifications to the underlying model are supported/to be avoided by gadgets/user scripts ] ] - Development with the VE: guides with explanation for common editor UI customization, and what is recommended API for it (for example: add custom toolbar buttons). Eran

4 4

The summary of new zero architecture proposal
by Yuri Astrakhan 25 Sep '13

25 Sep '13

Based on many ideas that were put forth, I would like to seek comments on this ZERO design. This HTML will be rendered for both M and ZERO subdomains if varnish detects that request is coming from a zero partner. M and ZERO will be identical except for the images - ZERO substitutes images with links to File:xxx namespace through a redirector. * All non-local links always point to a redirector. On javascript capable devices, it will load carrier configuration and replace the link with local confirmation dialog box or direct link. Without javascript, redirector will either silently 301-redirect or show confirmation HTML. Links to images on ZERO.wiki and all external links are done in similar way. * The banner is an ESI link to */w/api.php?action=zero&banner=250-99* - returns HTML <div> blob of the banner. (Not sure if banner ID should be part of the URL) Expected cache fragmentation for each wiki page: * per subdomain (M|ZERO) * if M - per "isZeroCarrier" (TRUE|FALSE). if ZERO - always TRUE. 3 variants is much better then one per carrier ID * 2 per subdomain. P.S. Redirector is a Special:Zero page, but if speed is an issue, it could be an API calls (which seem to load much faster). The API call would redirect to the target, or could either redirect to the special page for confirmation rendering, or output HTML itself (no skin support, but avoids an extra redirect). Might not be worth it as javascript will be available on most of our target platforms now or soon.

3 4

Meet Bingle and Bugello
by Arthur Richards 19 Sep '13

19 Sep '13

I wrote a tool that will import bugs from Bugzilla into either Mingle and/or Trello (two project management tools used by some teams at the Wikimedia Foundation). The mobile web team was finding it difficult to keep track of two separate tools - one for new feature development, the other for tracking bugs, so Bingle helps bridge the gap and allows us to focus on one tool. This has had the side effect of keeping visibility of reported bugs high and has made it easier for us to quickly prioritize incoming bugs against existing work, and quickly respond to open issues. You can find the code and some rudimentary usage instructions here: https://github.com/awjrichards/bingle I hacked this together rather quickly - expedience was my goal rather than perfection, so it's not well documented, a little quirky, and there's a lot of room for improvement. I've been sitting on it for a while, hoping to make improvements before announcing it, but I have not found the time to make the changes I would like (eg for it to use the Bugzilla API rather than Bugzilla atom feeds). So, I invite anyone interested and willing to fork it, and pitch in and help make it awesome :) -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

4 5

paper cuts
by Lydia Pintscher 11 Sep '13

11 Sep '13

Heya folks :) Quite a while ago Ubuntu did a paper cuts initiative (https://wiki.ubuntu.com/OneHundredPaperCuts). Basically it was about collecting and fixing small bugs/annoyances that were easy to fix but had a large impact on how pleasant it is to use the product. We're going to do something similar for Wikidata now. I'd like to get a bugzilla keyword for this so we can easily tag those bugs. For that I need at least one other team however who'd like to join such an initiative. Is there anyone who's interested in this? Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Technical Projects Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

2 3

A metadata API module for commons
by Brian Wolff 10 Sep '13

10 Sep '13

Hi all, I've been working on an api module/extension to extract metadata from commons image description pages, and display it in the API. I know this is an area that various people have thought about from time to time, so I thought it would be of interest to this list. The specific goals I have: *Should be usable for a light box type feature ("MediaViewer") that needs to display information like Author and license. [1] (This is primary use case) *Should be generic where possible, so that better metadata access can be had by all wikis, even if they don't follow commons conventions. For example, should generically support exif data from files where possible/appropriate, overriding the exif data when more reliable sources of information are available. *Should be compatible with a future wikidata on commons thing. [2] **In particular, I want to read existing description page formatting, not try and force people to use new parser functions or formatting conventions, since they may become outdated in near future when wikidata comes **Hopefully Wikidata would be able to hook into my system (Well at the same time providing its own native interface) *Since descriptions on commons are formatted data (Wikilinks are especially common) it needs to be able to output formatted data. I think html is the most easy to use format. Much more easy to use than say wikitext (However this is perhaps debatable) What I've come up with is a new api metadata property (Currently pending review in gerrit) called extmetadata that has a hook extensions can hook into. [3] [4] [5] Additionally I developed an extension for reading information from commons description pages. [6] It combines information from both the file's metadata, and from any extensions. For example, if the Exif data has an author specified ("Artist" in exif speak), and the commons description page also has one specified, the description page takes precedence, under the assumption its more reliable. The module outputs html, since that's the type of data stored in the image description page (Except that it uses full urls instead of local ones). The downside to this is in order to effectively get metadata out of commons given the current practises, one essentially has to screen scrape and do slightly ugly things (Look ahead for a brighter tomorrow with wikidata!) As an example, given a query like api.php?action=query&prop=imageinfo&iiprop=extmetadata&titles=File:Schwedenfeuer_Detail_04.JPG&format=xmlfm&iiextmetadatalanguage=en it would produce something like [7] So thoughts? /me eagerly awaits mail tearing my plans apart :) [1] https://www.mediawiki.org/wiki/Multimedia/Media_Viewer [2] https://commons.wikimedia.org/wiki/Commons:Wikidata_for_media_info [3] https://gerrit.wikimedia.org/r/#/c/81598/ [4] https://gerrit.wikimedia.org/r/#/c/78162/ [5] https://gerrit.wikimedia.org/r/#/c/78926/ [6] https://gerrit.wikimedia.org/r/#/c/80403/ [7] http://pastebin.com/yh5286iR -- Bawolff

11 16

Etherpad Lite labs instance going down in two weeks - backup time
by Mark Holmquist 06 Sep '13

06 Sep '13

The day we have all equally hoped for and dreaded is come to pass: Etherpad Lite has now replaced Etherpad "Classic" in production, and the labs instance is on its way out. This is my as-wide-as-possible email warning to say that everything on the labs instance, as really should have been expected, is going to be gone soon. Not immediately - we intend to give you two weeks to get your important data off the instance and onto the new one at https://etherpad.wikimedia.org/ - but you should _absolutely_ be moving things as soon as possible. We will also keep a data dump around, in case anything else needs to get pulled out of the pads, but I would suggest not relying on that if you don't have to. And in the future: If a URL has "wmflabs.org" in it...don't put anything, ANYTHING, important there. The purpose of labs is to let us experiment with new technology without having to worry about reliability. Thanks so much for your help and understanding in the course of this migration. tl;dr: http://etherpad.wmflabs.org is going down in 2 weeks, get yer stuff off it. -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtraceur(a)member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist

6 9

"Developers" link in the footer of all Wikimedia wikis
by Quim Gil 05 Sep '13

05 Sep '13

Just a heads up about a little big step. As per Add "Developers" link to footer of Wikimedia wikis using WikimediaMessages extension https://bugzilla.wikimedia.org/show_bug.cgi?id=33464 A Developers link pointing to https://www.mediawiki.org/wiki/Special:MyLanguage/How_to_contribute is visible in the footer of ALL WIKIMEDIA PROJECTS. Thank you very much MZMcBride, Matmarex, MaxSem, Nemo, Ori and anyone else involved! Thank you also to all the translators of that string and that page. Next... revisiting https://www.mediawiki.org/wiki/Developer_hub ? -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

6 8

Making inter-language links shorter
by Pau Giner 04 Sep '13

04 Sep '13

As multilingual content grows, interlanguage links become longer on Wikipedia articles. Articles such as "Barak Obama" or "Sun" have more than 200 links, and that becomes a problem for users that often switch among several languages. As part of the future plans for the Universal Language Selector, we were considering to: - Show only a short list of the relevant languages for the user based on geo-IP, previous choices and browser settings of the current user. The language the users are looking for will be there most of the times. - Include a "more" option to access the rest of the languages for which the content exists with an indicator of the number of languages. - Provide a list of the rest of the languages that users can easily scan (grouped by script and region ao that alphabetical ordering is possible), and search (allowing users to search a language name in another language, using ISO codes or even making typos). I have created a prototype <http://pauginer.github.io/prototype-uls/#lisa> to illustrate the idea. Since this is not connected to the MediaWiki backend, it lacks the advanced capabilities commented above but you can get the idea. If you are interested in the missing parts, you can check the flexible search and the list of likely languages ("common languages" section) on the language selector used at http://translatewiki.net/ which is connected to MediaWiki backend. As part of the testing process for the ULS language settings, I included a task to test also the compact interlanguage designs. Users seem to understand their use (view recording<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>), but I wanted to get some feedback for changes affecting such an important element. Please let me know if you see any possible concern with this approach. Thanks -- Pau Giner Interaction Designer Wikimedia Foundation

9 16

gwtoolset : architecture design help
by dan entous 03 Sep '13

03 Sep '13

context ------- i’m working on a mediawiki extension, http://www.mediawiki.org/wiki/Extension:GWToolset, which has as one of its goals, the ability to upload media files to a wiki. the extension, among other tasks, will process an XML file that has a list of urls to media files and upload those media files to the wiki along with metadata contained within the XML file. our ideal goal is to have this extension run on http://commons.wikimedia.org/ <onhttp://commons.wikimedia.org/>. background ---------- h ttp://commons.wikimedia.org/wiki/Commons:GLAMToolset_project/Request_for_Co…<http://commons.wikimedia.org/wiki/Commons:GLAMToolset_project/Request_for_C…> Metadata Set Repo ----------------- one of the goals of the project is to store Metadata Sets, such as XML under some type of version control. those Metadata Sets need to be accessible so that the extension can grab the content from it and process it. processing involves iterating over the entire Metadata Set and creating Jobs for the Job Queue which will upload each individual media file and metadata into a media file page using a Mediawiki template format, such as Artwork. some initial requirements • File sizes • can range from a few kilobytes to several megabytes. • max file-size is 100mb. • XML Schema - not required. • XML DTD - not required. • When metadata is in XML format, each record must consist of a single parent with many child • XML attribute lang= is the only one currently used and without user interaction • There is no need to display the Metadata sets in the wiki. • There is no need to edit the Metadata sets in the wiki. we initially developed the extension to store the files in the File: namespace, but we were told by the Foundation that we should use ContentHandler instead. unfortunately there is an issue with storing content > 1mb in the db so we need to find another solution. 1. any suggestions? Mapping ------- a mapping is a json that maps a metadata set to a mediawiki template. we’re currently storing those as Content in the namespace GWToolset. an entry might be in GWToolset:Metadata_Mappings/Dan-nl/Rijkmuseum. 1. does that namespace make sense? a. if not, what namespace would you recommend? 2. does this concept make sense? a. if not, what would you recommend? Maintaining Original Metadata Snippet & Mapping ----------------------------------------------- another goal is to link or somehow connect the original metadata used to create the mediafile: • metadata set • metadata snippet • metadata mapping the current thought is to insert these items as comments within the wiki text of the media file page 1. does that make sense? a. if not, what would you recommend doing? 2. is there a better way to do this? mediawiki template parameters ----------------------------- the application needs to know what mediawiki template parameters exist and are available to use for mapping media file metadata to the mediawiki templates. for the moment we are hard-coding these parameters in a db table and sometimes in the code. this is not ideal. i have briefly seen TemplateData, but haven’t had enough time to see if it would address our needs. 1. is there a way to programatically discover the available parameters for a mediawiki template? thanks in advance for your help! dan

5 9

01 Sep '13

I have a bot editing script that started having trouble logging in to the English Wikipedia a few days ago. I think what's happening is that the login process started using Javascript in a way it didn't before, and is detecting that my script doesn't do Javascript (which it doesn't), and throwing a second, fallback, non-Javascript-using login page at the point where the script is expecting to have already logged in. So the question is, if this is the case, is there a way to force the use of the non-Javascript login page from the beginning? Or if this is not the case, is there some other recent change that might have affected the flow? (And, in case you're wondering, no, the script does not use the API, but yes, I know about it, and this may be the circumstance that goads me into actually using it.)

6 7

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 August 2013