When looking for resources to answer Tim's question at
<https://www.mediawiki.org/wiki/Architecture_guidelines#Clear_separation_of_…>,
I found a very nice and concise overview of principles to follow for writing
testable (and extendable, and maintainable) code:
"Writing Testable Code" by Miško Hevery
<http://googletesting.blogspot.de/2008/08/by-miko-hevery-so-you-decided-to.h…>.
It's just 10 short and easy points, not some rambling discussion of code philosophy.
As far as I am concerned, these points can be our architecture guidelines.
Beyond that, all we need is some best practices for dealing with legacy code.
MediaWiki violates at least half of these principles in pretty much every class.
I'm not saying we should rewrite MediaWiki to conform. But I'd wish that it was
recommended for all new code to follow these principles, and that (local) "just
in time" refactoring of old code in accordance with these guidelines was encouraged.
-- daniel
*Marc-Andre Pelletier discovered a vulnerability in the MediaWiki OpenID
extension for the case that MediaWiki is used as a “provider” and the wiki
allows renaming of users.
All previous versions of the OpenID extension used user-page URLs as
identity URLs. On wikis that use the OpenID extension as “provider” and
allows user renames, an attacker with rename privileges could rename a user
and could then create an account with the same name as the victim. This
would have allowed the attacker to steal the victim’s OpenID identity.
Version 3.00 fixes the vulnerability by using Special:OpenIDIdentifier/<id>
as the user’s identity URL, <id> being the immutable MediaWiki-internal
userid of the user. The user’s old identity URL, based on the user’s
user-page URL, will no longer be valid.
The user’s user page can still be used as OpenID identity URL, but will
delegate to the special page.
This is a breaking change, as it changes all user identity URLs. Providers
are urged to upgrade and notify users, or to disable user renaming.
Respectfully,
Ryan Lane
https://gerrit.wikimedia.org/r/#/c/52722
Commit: f4abe8649c6c37074b5091748d9e2d6e9ed452f2*
How to load up high-resolution imagery on high-density displays has been an
open question for a while; we've wanted this for the mobile web site since
the Nexus One and Droid brought 1.5x, and the iPhone 4 brought 2.0x density
displays to the mobile world a couple years back.
More recently, tablets and a few laptops are bringing 1.5x and 2.0x density
displays too, such as the new Retina iPad and MacBook Pro.
A properly responsive site should be able to detect when it's running on
such a display and load higher-density image assets automatically...
Here's my first stab:
https://bugzilla.wikimedia.org/show_bug.cgi?id=36198#c6https://gerrit.wikimedia.org/r/#/c/24115/
* adds $wgResponsiveImages setting, defaulting to true, to enable the
feature
* adds jquery.hidpi plugin to check window.devicePixelRatio and replace
images with data-src-1-5 or data-src-2-0 depending on the ratio
* adds mediawiki.hidpi RL script to trigger hidpi loads after main images
load
* renders images from wiki image & thumb links at 1.5x and 2.0x and
includes data-src-1-5 and data-src-2-0 attributes with the targets
Note that this is a work in progress. There will be places where this
doesn't yet work which output their imgs differently. If moving from a low
to high-DPI screen on a MacBook Pro Retina display, you won't see images
load until you reload.
Confirmed basic images and thumbs in wikitext appear to work in Safari 6 on
MacBook Pro Retina display. (Should work in Chrome as well).
Same code loaded on MobileFrontend display should also work, but have not
yet attempted that.
Note this does *not* attempt to use native SVGs, which is another potential
tactic for improving display on high-density displays and zoomed windows.
This loads higher-resolution raster images, including rasterized SVGs.
There may be loads of bugs; this is midnight hacking code and I make no
guarantees of suitability for any purpose. ;)
-- brion
Hi all,
After a talk with Brad Jorsch during the Hackathon (thanks again Brad for
your patience), it became clear to me that Lua modules can be localized
either by using system messages or by getting the project language code
(mw.getContentLanguage().getCode()) and then switching the message. This
second option is less integrated with the translation system, but can serve
as intermediate step to get things running.
For Wikisource it would be nice to have a central repository (sitting on
wikisource.org) of localized Lua modules and associated templates. The
documentation could be translated using Extension:Translate. These modules,
templates and associated documentation would be then synchronized with all
the language wikisources that subscribe to an opt-in list. Users would be
then advised to modify the central module, thus all language versions would
benefit of the improvements. This could be the first experiment of having a
centralized repository of modules.
What do you think of this? Would be anyone available to mentor an Outreach
Program for Women project?
Thanks,
David Cuenca --Micru
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 and click
on one of the videos. Compare that with the video viewing experience at
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_overvi…
and 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/)
2. Add support for the 'modal' param to TimedMediaHandler
(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
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/>
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
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