headers
Sumana Harihareswara | 1 Feb 2012 02:16
Picon
Gravatar

New committers

Two new committers to the Wikimedia Subversion repository:

Christian Williams (christian, User:BladeBronson) now has extensions
access.  He is currently working at Wikia and has been developing
MediaWiki extensions for over 4 years. Christian plans to contribute to
the Visual Editor.

Bináris (binbot) now has commit access to pywikipediabot.  You can see
some of Bináris's past work in
https://www.mediawiki.org/wiki/User:Bin%C3%A1ris/contribs. Bináris is
already known for an essay "Fixes and functions"
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:Bin%C3%A1ris/Fixes_and_functions_HOWTO
, and for TOCbot
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:Bin%C3%A1ris/TOCbot .

Welcome!

--

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Permalink | Reply | 2 comments |
headers
Daniel Friesen | 1 Feb 2012 04:47

Re: ArticleEmblems is back

On Tue, 31 Jan 2012 09:18:22 -0800, Max Semenik <maxsem.wiki <at> gmail.com>  
wrote:

> Hi, as some of you may already noticed, I've resurrected Trevor's
> creation of old - ArticleEmblems that allows to add icons to the right
> of the area below article title. All the architectural problems that
> caused its demise before were resolved, so I'd like to invite more
> people to participate. First of all, the way these templates are
> outputted is flaky - but I think it's not a problem to fix.

Eek, and here I wanted to start completely from scratch incorporating this  
feature into my skinning plans.

--

-- 
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Permalink | Reply | 0 comments |
headers
MZMcBride | 1 Feb 2012 04:50

Re: Some questions about #switch

Steven Walling wrote:
> On Mon, Jan 30, 2012 at 3:23 PM, Tim Starling <tstarling <at> wikimedia.org>wrote:
>> I'm considering introducing a limit on #switch cases of 2000 or so per
>> article, to address this issue. No doubt many templates will break,
>> but it's important to protect our servers, and we've always
>> discouraged this kind of #switch application.
> 
> As a Wikipedian, I would be very happy to see a limitation imposed like
> this. I think the silent majority of editors who want to see pages load and
> save quickly/reliably outweighs the need for unlimited use of a very
> complicated parser functions structure.

This is probably going to read like an attack, but it isn't one.

I continue to view the existence of "expensive parser functions" as a
failure. I don't believe that having users focus on such details is useful
or necessary and I think it largely distracts from any wiki's primary
mission. While these types of functions make a page render/load take longer
(and this unquestionably needs to be addressed), it's more than a vocal and
active minority who favor templates that can do automatic math conversions
and unit labeling, string parsing for automatic page title italics and the
like, and more. In some ways, if these templates weren't so popular, there'd
be no issue. But they're popular for a reason (even if some are only popular
among hardcore template nerds, the result is the same...).

As I recall, it wasn't an overwhelming amount of time that was needed to fix
#ifexist to batch its queries rather than imposing a limit on it (it was
#ifexist that brought the idea of expensive parser functions into existence,
as I remember it... I'm too lazy to hunt down revs). Implementing the latter
was a more interesting coding challenge, I think, and there was a thought
(Continue reading)

Permalink | Reply | 2 comments |
headers
MZMcBride | 1 Feb 2012 04:56

Re: Impediments to forking

Platonides wrote:
> On 29/01/12 22:48, MZMcBride wrote:
>> Hi.
>> 
>> Is there a list of (current) impediments to forking a Wikimedia wiki?
> 
>> replicating parser,
> The parser is publically available. We have no hidden tricks.
> 
>> available dumps,
> Dumps are running quite well currently. That shouldn't be a problem
> 
>> Image access,
> Downloading images is slightly harder. Although the big problem is the
> huge amount of them (so big size, which translates into needed disk
> space + bandwidth to download), not in getting the files.
> If you weren't interested in really forking the images,
> $wgUseInstantCommons could be used.
> 
>> replicating user table, etc.
> All user data deemed private is not available. Basically password
> hashes, watchlists and some preferences.

I appreciate the inline replies, but these were just ideas of the top of my
head. ;-)  I was asking about a more thorough review.

Also, replicating the parser is fairly difficult. Link existence checks,
interwikis, image rendering with foreign repos, extension tags (math
support, hiero support, syntax highlighting), Tidy interaction, etc. make
actual replication very difficult. You can approximate, though.
(Continue reading)

Permalink | Reply | 1 comment |
headers
MZMcBride | 1 Feb 2012 05:01

Re: Announcing Howie Fung as Director of Product Development

Erik Moeller wrote:
> [...] and to use our limited resources for the projects that are
> likely to have the highest impact.

Heh.

> Please join me in congratulating Howie, and WMF. :-)

Congrats, Howie. :-)

MZMcBride
Permalink | Reply | 2 comments |
headers
Freek Dijkstra | 1 Feb 2012 05:51
Picon
Favicon
Gravatar

Recommended way to register resources for skins

Hi all,

I've created a copy of the Vector skin.
What is the recommended way to register resources (for the resource
loader) for a custom skin?

Vector registers the resources in resources/Resources.php

The recommended method for extensions seems to define
$wgResourceModules['ext.myExtension'] in the MyExtension.php file

This does not seem to work for styles. I get a blank page when I do this
in my skin, and load
/load.php?debug=true&lang=en-gb&modules=skins.myskin&only=styles&skin=myskin&*
in my browser.

Here is what I tried so far:
1. Don't define anything
  --> PHP Fatal error:  Call to a member function getGroup() on a
non-object in includes/OutputPage.php on line 2958

2. define $wgResourceModules['skins.myskin'] in the MySkin.php
  --> blank page

3. define $wgResourceModules['skins.myskin'] in SkinMySkin (extends
SkinTemplate) __construct() function
  --> blank page

4. call $resourceLoader->register('skins.myskin', ...) from a hook
function, defined by $wgHooks['ResourceLoaderRegisterModules'][] in
(Continue reading)

Permalink | Reply | 7 comments |
headers
Freek Dijkstra | 1 Feb 2012 06:51
Picon
Favicon
Gravatar

Re: Recommended way to register resources for skins

Freek Dijkstra wrote:
> Hi all,
> 
> I've created a copy of the Vector skin.
> What is the recommended way to register resources (for the resource
> loader) for a custom skin?
> 
> Vector registers the resources in resources/Resources.php
> 
> The recommended method for extensions seems to define
> $wgResourceModules['ext.myExtension'] in the MyExtension.php file
> 
> This does not seem to work for styles. I get a blank page when I do this
> in my skin, and load
> /load.php?debug=true&lang=en-gb&modules=skins.myskin&only=styles&skin=myskin&*
> in my browser.

It occurs to me that the cause may be that Index.php (the HTML) pages
includes MySkin.php, but load.php (the CSS) does not include MySkin.php.

Is this intended behaviour or a bug?

> Here is what I tried so far:
> 1. Don't define anything
>   --> PHP Fatal error:  Call to a member function getGroup() on a
> non-object in includes/OutputPage.php on line 2958
> 
> 2. define $wgResourceModules['skins.myskin'] in the MySkin.php
>   --> blank page
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Howie Fung | 1 Feb 2012 08:51
Picon
Gravatar

Re: Announcing Howie Fung as Director of Product Development

Thanks everyone.  I'm excited about the new role and continuing our work
together!

Howie

On Tue, Jan 31, 2012 at 8:01 PM, MZMcBride <z <at> mzmcbride.com> wrote:

> Erik Moeller wrote:
> > [...] and to use our limited resources for the projects that are
> > likely to have the highest impact.
>
> Heh.
>
> > Please join me in congratulating Howie, and WMF. :-)
>
> Congrats, Howie. :-)
>
> MZMcBride
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l <at> lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Permalink | Reply | 1 comment |
headers
Nasir Khan | 1 Feb 2012 09:59
Picon
Gravatar

Re: Announcing Howie Fung as Director of Product Development

Congratulations :)

On Wed, Feb 1, 2012 at 1:51 PM, Howie Fung <hfung <at> wikimedia.org> wrote:

> Thanks everyone.  I'm excited about the new role and continuing our work
> together!
>
> Howie
>
> On Tue, Jan 31, 2012 at 8:01 PM, MZMcBride <z <at> mzmcbride.com> wrote:
>
> > Erik Moeller wrote:
> > > [...] and to use our limited resources for the projects that are
> > > likely to have the highest impact.
> >
> > Heh.
> >
> > > Please join me in congratulating Howie, and WMF. :-)
> >
> > Congrats, Howie. :-)
> >
> > MZMcBride
> >
> >
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l <at> lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roan Kattouw | 1 Feb 2012 13:04
Picon

Re: Recommended way to register resources for skins

On Wed, Feb 1, 2012 at 5:51 AM, Freek Dijkstra <software <at> macfreek.nl> wrote:
> Hi all,
>
> I've created a copy of the Vector skin.
> What is the recommended way to register resources (for the resource
> loader) for a custom skin?
>
> Vector registers the resources in resources/Resources.php
>
This is not really well thought-out at this point, unfortunately :( .
I'll file a bug about this, and think about it for a bit later today.

Roan
Permalink | Reply | 5 comments |

Gmane