Wikitech-l May 2013

wikitech-l@lists.wikimedia.org

158 participants
196 discussions

[GSoC 2013] Wikidata Entity Suggester prototype
by Nilesh Chakraborty 03 Jun '13

03 Jun '13

Hi everyone, I'm working on a prototype for the Wikidata Entity Suggester (Bug #46555<https://bugzilla.wikimedia.org/show_bug.cgi?id=46555>). As of now, it is a command-line client, completely written in Java, that fetches recommendations from a Myrrix server layer. Please take a look at the GitHub repository here: https://github.com/nilesh-c/wikidata-entity-suggester/ I would really appreciate it if you can take the time to go through the README and provide me with some much-needed feedback. Any questions or suggestions are welcome. If you're curious, you can set up the whole thing on your own machine. Check out a few examples too: https://github.com/nilesh-c/wikidata-entity-suggester/wiki/Examples It can suggest properties and values for new/not-yet-created items (and also currently present items), if it's given a few properties/values as input data. I intend to write a REST API and/or a simple PHP frontend for it before I set it up on a remote VPS, so that everyone can test it out. Some experimentation and quality optimization is also due. Cheers, Nilesh (User Page - https://www.mediawiki.org/wiki/User:Nilesh.c) -- A quest eternal, a life so small! So don't just play the guitar, build one. You can also email me at contact(a)nileshc.com or visit my website<http://www.nileshc.com/>

4 12

Re: [Wikitech-l] showing videos and images in modal viewers within articles
by Fabrice Florin 01 Jun '13

01 Jun '13

Hey Kaldari, Thanks so much for yesterday's code fix to display videos in a modal viewer when you click on article thumbnails! This was long overdue and makes a huge difference already, as shown in this example: https://en.wikipedia.org/wiki/Congenital_insensitivity_to_pain I agree with Erik that the ideal behavior would be to play the video immediately after you click on the thumbnail, without requiring a second click to play in modal view. Now, is there any chance we could do something similar for still photos? As a longtime photographer, it drives me nuts that clicking on a thumbnail article takes you to this overwhelming page on Commons, with scary walls of text all around the image. (That's one of the reasons I haven't yet migrated any of my 20k Flickr photos to Commons, BTW.) Most modern web sites nowadays just show you the photo in full screen, with only a few icons around it, so you can experience the image as it was intended to be seen (typically in a black modal panel, to make it pop up more). You still have the option to reveal all the text details if you want them, but they are not forced on you as we do today on Wikipedia and Commons. Hopefully, our new multimedia team will be able to join forces with the design team to tackle some of these commonsense UI improvements, once we get up to speed this summer. Thanks again for this welcome prelude :) Fabrice _______________________________ Fabrice Florin Product Manager, Editor Engagement Wikimedia Foundation http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF) On May 30, 2013, at 1:35 AM, wikitech-l-request(a)lists.wikimedia.org wrote: > > From: Erik Moeller <erik(a)wikimedia.org> > Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles > Date: May 29, 2013 9:21:48 PM PDT > To: Ryan Kaldari <rkaldari(a)wikimedia.org> > Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > Yes, better support for display of images through a modal viewer would > be great. I'm not sure a "modal" parameter that has to be explicitly > set for files is the best approach - I would recommend optimizing the > default experience when a user clicks an image or video. It's not > clear that the current behavior based on a pixel threshold is actually > desirable as the default behavior. (On a side note, the TMH behavior > should be improved to actually play the video immediately, not require > a second click to play in modal view.) > > Magnus Manske explored an alternative approach pretty extensively in > response to the October 2011 Coding Challenge, which is worth taking a > look at: > https://www.mediawiki.org/wiki/User:Magnus_Manske/wikipic > > Cheers, > Erik > > > From: Brion Vibber <bvibber(a)wikimedia.org> > Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles > Date: May 30, 2013 12:42:00 AM PDT > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Cc: Erik Moeller <emoeller(a)wikimedia.org> > Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > I tend to agree that a light box or other modalish zoom should become the > default behavior. > > -- brion > On May 30, 2013 5:50 AM, "Ryan Kaldari" <rkaldari(a)wikimedia.org> wrote: > >> For years, I have weeped and wailed about people adding complicated maps >> and diagrams as 220px thumbnail images to Wikipedia articles. These sort of >> images are virtually useless within an article unless they are displayed at >> relatively large sizes. Unfortunately, including them at large sizes >> creates a whole new set of problems. Namely, large images mess up the >> formatting of the page and cause headers, edit links, and other images to >> get jumbled around into strange places (or even overlapping each other on >> occasion), especially for people on tablets or other small screens. The >> problem is even worse for videos. Who wants to watch a hi-res video in a >> tiny 220px inline viewer? If there are subtitles, you can't even read them. >> But should we instead include them as giant 1280px players within the >> article? That seems like it would be obnoxious. >> >> What if instead we could mark such complicated images and high-res videos >> to be shown in modal viewers when the user clicks on them? For example: >> [[File:Highres-video1.webm|**thumb|right|modal|A high res video]]. When >> you clicked on the thumbnail, instead of going to Commons, a modal viewer >> would overlay across the screen and let you view the video/image at high >> resolution (complete with a link to Commons and the attribution >> information). Believe it or not, this capability already exists for videos >> on Wikipedia, but it's basically a hidden feature of TimedMediaHandler. If >> you include a video in a page and set the size as 200px or less, it >> activates the modal behavior. Unfortunately, the default size for videos is >> 220px (as of 2010) so you will almost never see this behavior on a real >> article. If you want to see it, go to https://en.wikipedia.org/wiki/** >> American_Sign_Language#**Variation<https://en.wikipedia.org/wiki/American_Sign_Language#Variation>and click on one of the videos. Compare that with the video viewing >> experience at https://en.wikipedia.org/wiki/**Congenital_insensitivity_to_ >> **pain <https://en.wikipedia.org/wiki/Congenital_insensitivity_to_pain>. >> It's a world of difference. Now imagine that same modal behavior at >> https://en.wikipedia.org/wiki/**Cathedral_Peak_Granodiorite#** >> Geological_overview<https://en.wikipedia.org/wiki/Cathedral_Peak_Granodiorite#Geological_overvi…>and >> https://en.wikipedia.org/wiki/**Battle_of_Jutland<https://en.wikipedia.org/wiki/Battle_of_Jutland> >> . >> >> Such an idea would be relatively trivial to implement. The steps would be: >> 1. Add support for a 'modal' param to the [[File:]] handler ( >> https://gerrit.wikimedia.org/**r/#/c/66062/<https://gerrit.wikimedia.org/r/#/c/66062/> >> ) >> 2. Add support for the 'modal' param to TimedMediaHandler ( >> https://gerrit.wikimedia.org/**r/#/c/66063/<https://gerrit.wikimedia.org/r/#/c/66063/> >> ) >> 3. Add support for the 'modal' param to images via some core JS module >> (not done yet) >> >> As you can see, I've already gotten started on adding this feature for >> videos via TimedMediaHandler, but I haven't done anything for images yet. I >> would like to hear people's thoughts on this potential feature and how it >> could be best implemented for images before doing anything else with it. >> What are your thoughts, concerns, ideas? >> >> Ryan Kaldari >> >> >> ______________________________**_________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l> > > > From: Ryan Kaldari <rkaldari(a)wikimedia.org> > Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles > Date: May 30, 2013 12:46:13 AM PDT > To: Erik Moeller <erik(a)wikimedia.org> > Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > On 5/29/13 9:21 PM, Erik Moeller wrote: >> Yes, better support for display of images through a modal viewer would >> be great. I'm not sure a "modal" parameter that has to be explicitly >> set for files is the best approach - I would recommend optimizing the >> default experience when a user clicks an image or video. It's not >> clear that the current behavior based on a pixel threshold is actually >> desirable as the default behavior. (On a side note, the TMH behavior >> should be improved to actually play the video immediately, not require >> a second click to play in modal view.) > > Does anyone think it would be a bad idea to just make modal viewing the default for thumbnailed videos? > > Ryan Kaldari > > > > From: Antoine Musso <hashar+wmf(a)free.fr> > Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles > Date: May 30, 2013 12:52:25 AM PDT > To: wikitech-l(a)lists.wikimedia.org > Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > Le 30/05/13 05:49, Ryan Kaldari a écrit : >> When you clicked on the thumbnail, instead of going to Commons, a modal >> viewer would overlay across the screen and let you view the video/image >> at high resolution > <snip> > > I discovered yesterday that Commons as such a tool to browse pictures in > a category. Whenever you browse a category page such as: > https://commons.wikimedia.org/wiki/Category:Hackathons > > There is a Green icon which when hovered will expand to 'show slideshow' > and when clicked replace the view with a slideshow view like Picassa / > Flickr ... > > It would be nice to have that build in MediaWiki. Maybe there is a well > supported JQuery plugin that does just that and we could ship in core? > > > -- > Antoine "hashar" Musso > > > > From: Antoine Musso <hashar+wmf(a)free.fr> > Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles > Date: May 30, 2013 1:34:35 AM PDT > To: wikitech-l(a)lists.wikimedia.org > Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > Le 30/05/13 09:46, Ryan Kaldari a écrit : >> Does anyone think it would be a bad idea to just make modal viewing the >> default for thumbnailed videos? > > Be bold! To play it safe, you can make the feature protected with a > global feature that we will slowly enable on all wiki and eventually > phase out later on :-] This way the code will land everywhere and we > can play test it on beta then on commons ... > > -- > Antoine "hashar" Musso > "did I say: 'be bold' ?" > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2 1

Welcome, Nik Everett
by Rob Lanphier 01 Jun '13

01 Jun '13

Hi everyone It is my pleasure to introduce Nik Everett as a new Senior Software Engineer specializing in Search, working remotely from his home in Raleigh, North Carolina. Nik joins us from Lulu, a company founded by Bob Young[1] to enable anyone to publish a book (dealing with print, distribution, and order fulfillment issues). Nik was responsible for a number of DevOps-related tasks at Lulu, mainly centered around test automation, build infrastructure, and database performance, but also including maintenance and support of their Solr infrastructure. He also founded and chaired Lulu’s architecture review board, which is similar to a group we’re just now starting up here[2] Prior to Lulu, Nik worked at Bandwidth.com, Radarfind, and Nortel. He has Bachelors Degrees in Computer Science and Mathematics from University of North Carolina at Chapel Hill. Nik knows many programming languages. He prefers writing in Python, but due to the nature of what we’re doing here, he’ll probably end up writing more Java and (of course) PHP. He likes picking up a new languages every so often. He’s currently playing around with Haskell, and on good days may be able to explain what a monad is. :-) Nik’s nick on Freenode is “manybubbles”, and he's cc'd on this mail. Rob [1] One of Bob Young’s other claims to fame is as co-founder and former CEO of Red Hat. [2] Not yet an “architecture review board”, but that may be as good a name as any for this: http://lists.wikimedia.org/pipermail/wikitech-l/2013-May/069569.html

7 6

Deployment Highlights - Week of June 3rd
by Greg Grossmeier 31 May '13

31 May '13

Hello all, Next week (starting June 3rd) will be a very interesting week as far as deployments are concerned. Why? Because on Thursday June 6th we will be starting the one-week deployment cycle! But, we're also in the tail end of the old two-week deploy cycle for 1.22wmf5, thus making next week a bit crowded. For more information on the one-week deploy cycle, see: <https://wikitech.wikimedia.org/wiki/Deployments/One_week>. == Monday == * MediaWiki general deployment window for 1.22wmf5 to English Wikipedia. See: <https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap> == Tuesday == * Universal Language Selector (ULS) will be updating to the latest master after last week's revert in preparation for the following week's deploy which will start the transition to using ULS. See <https://www.mediawiki.org/wiki/UniversalLanguageSelector/Deployment/Planning> for more information. * AFTv5, see: <http://etherpad.wikimedia.org/AFT5-release> and <http://www.mediawiki.org/wiki/Article_feedback/Version_5/Release_Plan_2013> == Wednesday == * MediaWiki general deployment window for 1.22wmf5 to all 'pedias (completion of wmf5 rollout). See: <https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap> * MobileFrontEnd updates (moved from Tuesday due to conflicting meetings). See: <https://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments> == Thursday == * MediaWiki general deployment window (1.22) the beginning of 1.22wmf6 (and of the one-week cycle), rolled out to mediawiki.org, test.wikipedia.org, and test2.wikipedia.org. See: <https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap> and <https://wikitech.wikimedia.org/wiki/Deployments/One_week> * E3: Updates to GettingStarted and potentially some updates to GuidedTour. See: <https://www.mediawiki.org/wiki/Extension:GettingStarted> and <https://www.mediawiki.org/wiki/Extension:GuidedTour> == All week == * Lightning deploys! <https://wikitech.wikimedia.org/wiki/Lightning_deployments> Any questions, just ask! Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Re: [Wikitech-l] Wikitech-l Digest, Vol 118, Issue 102
by anton.bolfing＠access-for-all.ch 31 May '13

31 May '13

Besten Dank für Ihre Nachricht. Ich bin bis am Montag, dem 24. Juni 2013 abwesend und kann Ihre Nachricht erst ab dann wieder bearbeiten. Ihre Email wird nicht weitergeleitet. Beste Grüsse Anton Bolfing ************************************************************************************************************ Thank you for your message. I'm out of office until Monday, June 26. I will not respond to your email until then. Best regards Anton Bolfing

1 0

ZERO architecture
by Yuri Astrakhan 31 May '13

31 May '13

Zero is rapidly growing, but its architecture is falling behind, and needs to be revised. *== Zero Partner Requirements ==* * Support both smart phones (full JavaScript support) and feature phones (limited HTML/no js support) * Show carrier-specific, language-specific banner * Allow carriers to select what features are zero-rated: images and list of languages * Ask for user confirmation when navigating away from zero (images, non-zero languages, external sites) *== Technical Requirements ==* * increase Varnish cache hits / minimize cache fragmentation * Set up and configure new partners without code changes * Use partner-supplied IP ranges as a preferred alternative to the geo-ip database for fundraising & analytic teams *== Current state ==* Zero domain requests set X-Subdomain="ZERO", and treat the request as mobile. The backend uses X-Subdomain and X-CS headers to customize result. The cache is heavily fragmented due to its variance on both of these headers in addition to the variance set by MobileFrontend extension and MediaWiki core. *== Proposals ==* In order to reduce Zero-caused fragmentation, we propose to shrink from one bucket per carrier (X-CS) to three general buckets: * smart phones bucket -- banner and site modifications are done on the client in javascript * feature phones -- HTML only, the banner is inserted by the ESI ** for carriers with free images ** for carriers without free images *=== Varnish logic ===* * Parse User-Agent to distinguish between desktop / mobile / feature phone: X-Device-Type=desktop|mobile|legacy * Use IP -> X-CS lookup (under development by OPs) to convert client's IP into X-CS header * If X-CS && X-Device-Type == 'legacy': Use IP -> X-Images lookup (same lookup plugin, different database file) to determine if carrier allows images Since each carrier has its own list of free languages, language links on feature phones will point to origin, which will either silently redirect or ask for confirmation. *=== ZERO vs M ===* Even though I think zero. and m. subdomains should both go the way of the dodo to make each article have just one canonical location (no more linking & Google issues) , this won't happen until we are fully migrated to Varnish and make some mobile code changes (and possibly other changes that I am not aware of). At the same time, we should try to get rid of ZERO wherever possible. There are two technical differences between m & zero: zero shows a link to image instead of the actual image, and a big red zero warning is shown if the carrier is not detected. There is also an organizational difference -- some carriers only whitelist zero, some - only m, and some -- both zero & m subdomains. This spreadsheet<https://docs.google.com/spreadsheet/ccc?key=0As-T7jJ1slQGdDd3WjhkVmk5SWc5OE…> shows all configurations we allow, and how we handle them at the moment. Each case requires a different handling, so proposals are listed there. In general, we should manipulate image links in M for carriers who don't allow them, and always redirect ZERO to M unless M is not whitelisted, in which case convince carrier to change their whitelist.

3 3

Can we kill $wgPasswordSalt
by Daniel Friesen 31 May '13

31 May '13

It would be nice to kill off $wgPasswordSalt if we could (the ability to set it to false that is). This setting controls whether we use a salted password algorithm or an unsalted one. Basically making something somewhat secure almost completely insecure. This setting appears to exist to make it possible for auth plugins on other pieces of 3rd party software to login using MediaWiki accounts by directly accessing MediaWiki's database but not bothering to understand any of MediaWiki's password algorithms. A fairly dubious rationale to exist IMHO. The current documentation on the setting is also complete and totally false. It says "For compatibility with old installations set to false.", but at this point this has absolutely nothing to do with compatibility. Frankly even if we do have any sort of remaining incompatibility I'd bet it would be fairly trivial to actually solve (eg: For ancient password hashes just try both ancient algorithms instead of just one). -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

5 4

Using Skin system as a beta development environment
by Jon Robson 31 May '13

31 May '13

In my short time at the Foundation I've seen various problems which have risen due to communication problems between seasoned wikipedia editors, WMF teams and volunteer developers. Echo comes to mind as does the mobile photo upload feature my team designed. It strikes me that the skin system would lend itself beautifully to bridging this communication gap between developers and editors. class SkinVectorBeta extends SkinVector { public function initPage( OutputPage $out ) { parent::initPage( $out ); $out->addModules( array( 'echo', 'visualeditor' ) ); } } Any interested editors could enable this skin through user preferences and be able to see exactly what new features are in the pipeline. Is there any reason we don't currently do this in favour of various experiments and then a sudden push to production which tends a lot of the time to result in a heated Village Pump discussion?

4 4

Re: [Wikitech-l] Wikitech-l Digest, Vol 118, Issue 101
by anton.bolfing＠access-for-all.ch 31 May '13

31 May '13

1 0

Re: [Wikitech-l] ZERO architecture
by Adam Baso 31 May '13

31 May '13

Yuri, carrying the IRC chat over to mail... "Since each carrier has its own list of free languages, language links on feature phones will point to origin, which will either silently redirect or ask for confirmation." This will require some engineering finesse for article content, Read in Another Language, and language dropdown list links. Anything's achievable, just gotta be careful. "In general, we should manipulate image links in M for carriers who don't allow them, and always redirect ZERO to M unless M is not whitelisted, in which case convince carrier to change their whitelist." Dan should probably weigh in on that piece, in case there are contractual obligations or bandwidth considerations.

1 0

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