Everyone,
I’m pleased to welcome Munaf Assaf, a new member of the Product Group.
Munaf is starting today as UX Designer and will work mainly on the
Editor Engagement Experiments projects. Almost all of these projects
have a user-facing component, and Munaf will help us design interfaces
to make these experiments and features more user-friendly.
Munaf joins us from the University of Michigan (UM), where he worked
as a Research Associate in the Office of Enabling Technologies. At UM,
he worked on a variety of projects, including mobile informatics
applications and engagement tools for visiting hospital patients. His
most recent project was the design of a high-tech collaboration space
in conjunction with the Taubman School of Architecture. Earlier in his
career, Munaf was an Algorithm Design Engineer at General Motors,
where he worked on control systems for improving vehicle fuel
efficiency.
He has a BS in Electrical Engineering from Kettering University, as
well as an MSI in Human-Computer Interaction from the University of
Michigan at Ann Arbor. For more information on his background, please
see his public profile [1].
Please join me in welcoming Munaf!
Howie
[1] http://www.linkedin.com/in/munafassaf
As we're starting to migrate functionality provided by the MobileFrontend
extension into Mediawiki core, we have to grapple with some existing
limitations in Mediawiki. I'd like to propose a core change that I think
will greatly increase MW's flexibility in rendering content for different
'view types'. By 'view type', I mean things like:
* The standard web browser view
* A print view
* A mobile view
* Other device specific views, views for particularly slow connections,
views with no graphics, etc.
We could use the idea of a 'view type' to allow us to do some cool stuff,
for instance:
*Dynamic view-specific skin loading*
MobileFrontend already displays content from a mobile-specific skin. We
could make it possible for Mediawiki to dynamically determine the skin to
load based off of the current view type, and provide a pattern for skin
authors to follow for building view type-specific skins, for example:
* Standard: <SkinName>.php
* Print: <SkinName>Print.php
* Mobile: <SkinName>Mobile.php
We could also provide a hook for people to be able to define their own view
types, as well as allow for configuration to define default skins for
specific view types. We could then more easily build view types for
specific devices, for instance. This would greatly lower the barrier of
entry for someone who wants to write a mobile-specific skin, print-specific
skin, etc, and would enrich the pool of available MW skins.
*View-specific functionality*
Different view types will likely have different bits of functionality that
they require, separate from the rest of MW, that may not make sense to
exist in a Skin. We could allow different view types the opportunity to
bootstrap view-specific functionality when appropriate. If we segment this
functionality to only load for a specific view-type, we can prevent
unnecessary components from loading if they are not appropriate for a
specific view. I haven't yet really flushed this concept out, and am very
open to suggestions on implementation.
*
*
I started hacking a bit at a few core files to give a code example of how
this might be implemented, at least for dynamically loading view-specific
skins:
http://pastie.org/4010775
I'd love to hear people's thoughts on this and integrate feedback as we
move forward with migrating MobileFrontend into MW core. Fore more info on
the MobileFrontend to core migration, see
http://www.mediawiki.org/wiki/Mobile_support_in_MediaWiki_core
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
Hey all,
Ryan Lane just made me aware of the gerrit commandline. We're going to use
it to approve l10n-bot commits right after submitting them for review.
I want to share with you an example command:
ssh l10n-bot(a)gerrit.wikimedia.org -p 29418 gerrit review 9748,1
--code-review 2 --verified 1 --submit
This has user "l10n-bot" set code-review to +2, verified to +1 for CHANGE
9748, PATCHSET 1, and tries to merge it.
You can get some help text output using the following sample commands:
Help on all gerrit actions:
ssh l10n-bot(a)gerrit.wikimedia.org -p 29418 gerrit --help
Help on gerrit review:
ssh l10n-bot(a)gerrit.wikimedia.org -p 29418 gerrit review --help
In all examples you will probably have to replace "l10n-bot" with your own
gerrit username.
Cheers!
Siebrand
Hello dear developers,
if you can and have time, please would kindly invite you to
code-review a pending cumulative patch for Extension:RSS
https://gerrit.wikimedia.org/r/#/c/3925/
Up-to-date documentation
https://www.mediawiki.org/wiki/Extension:RSS incl. bugtracker links.
This latest version is fully working for me on all my wikis, but waits
for code-review until it can be deployed to Mediawiki.org .
An older, outdated, and buggy (in the sense, that not all kinds of feeds
are supported) version of the extension runs there.
Tom
Hey all,
As per the commentary on bug #32987, it might be desirable to change the
constructor for ThumbnailImage from:
$foo = new ThumbnailImage( $file, $url, $width, $height, $path, $page );
to:
$foo = new ThumbnailImage( $file, $url, $params );
where $params in an associative array containing width, height and any
other parameters we want to have now or in the future. Obviously, at the
same time as any change to the constructor is made, all the references in
core and Gerrit-tracked extensions can be switched over to the new format.
However, I was wondering what people consider best practice with regard to
softening the transition in order to avoid non-Gerrit-tracked extensions
breaking.
I've thrown up one idea at http://pastebin.com/Jw109j4a .
Any pointers appreciated,
Harry
--
Harry Burt (User:Jarry1250)
Greetings,
As someone involved with Wikimania programming - I'm wondering if there are volunteers interested in developing a Wikimania mobile app. It may not be feasible given the short timeline, but I've seen a number of conference apps coming out over the past week and figured it should at least be pondered. :)
Essentially the idea would be to include schedule, local info, maps, etc. Things that can be pulled from the Wikimania 2012 wiki. Perhaps something PhoneGap based?
Any thoughts or interest?
-greg aka varnent
On Sat, Jun 2, 2012 at 6:13 AM, Anthony <wikimail(a)inbox.org> wrote:
> On Sat, Jun 2, 2012 at 8:49 AM, Thomas Dalton <thomas.dalton(a)gmail.com> wrote:
>> On 2 June 2012 13:44, Anthony <wikimail(a)inbox.org> wrote:
>>> On Fri, Jun 1, 2012 at 7:27 PM, John Du Hart <compwhizii(a)gmail.com> wrote:
>>>> What personal information do you think is contained in an IPv6 address?
>>>
>>> Don't they sometimes contain MAC address information?
>>
>> I don't know, but I wouldn't consider my MAC address to be personal
>> information... you might be able to work out what brand of computer
>> I'm using, but I can live with that.
I think that having a problem with the implementation of IPv6 is about
10 years too late now ;) The IPv4 space is being exhausted, and we're
going to soon run into the opposite problem that IPv4 addresses will
be not identifiable enough as ISP's use NAT.
If someone cares about their mac address information, they can use
privacy extensions - http://en.wikipedia.org/wiki/Ipv6#Privacy .
Considering that in the vast, vast majority of the consumer (versus
production) world, you have to purposefully enable IPv6 (usually with
some sort of tunneling), and that these are turned on in most
operating systems by default, mac addressing is starting to only
become applicable in production environments.
Leslie
--
Leslie Carr
Wikimedia Foundation
AS 14907, 43821
http://as14907.peeringdb.com/
Hi guys, i have created a simple map editor which works with the Maps
extension, i'm looking for some feedback on your impression of it.
please take a look @
http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw…
let me know what you think.
and also, please note it's a work in progress. My idea is to implement this
as a special page in the Maps extension so that people can easily create
and edit maps.
Cheers
Kim