Moritz Schubotz | 23 Jul 23:42 2014

Re: Moving Mathoid to production cluster


the discussion stopped with the question:
How to test the new rendering on betalabs?
So, does who knows the answer?


On Tue, Jul 15, 2014 at 12:19 PM, Moritz Schubotz <schubotz <at>> wrote:
> Hi Chris,
> By default the Math extension users the dedicated host
> this  host is accessible from the beta cluster.
> A bug related to the beta cluster is available here
> But I have no clue how to change the config for betalabs.
> Best
> Moritz
> Am 15.07.2014 17:06 schrieb "Chris McMahon" <cmcmahon <at>>:
>> On Tue, Jul 15, 2014 at 1:10 AM, Moritz Schubotz <physik <at>>
>> wrote:
>> > Hi Chris,
>> >
(Continue reading)

Shawn Jones | 23 Jul 14:38 2014

Quick PHP question about checking for web API

HI folks,

I’m working on a another MediaWiki extension and I wanted to know if there is another way to check that the
web API is enabled other than just performing:

if ( $wgEnableAPI === true )

I was hoping there was some function that just returned the value of $wgEnableAPI.

If there is another way to see if the user has turned off the web API, that would be cool, too.  I just need to
check that it’s enabled.

Thanks in advance,

Shawn M. Jones
Graduate Research Assistant
Department of Computer Science
Old Dominion University

Email:          sjone <at>
Research group:
Twitter:         <at> shawnmjones

Wikitech-l mailing list
Wikitech-l <at>
Quim Gil | 23 Jul 13:56 2014

Reviewing a couple of TorBlock patches

According to our algorithm (*), TorBlock currently has the worse track
reviewing code contributions -- even after Tim gave a -1 to one of the
three open patches last week (thanks!). There are two patches from Tyler
that haven't received any feedback at all since August 2013.,n,z

Your help reviewing these patches is welcome.

It is not surprising that this extension has no maintaner listed at (someone suggested
Tim in that table, he disagrees and edited accordingly).

Also, maybe someone is interested in maintaining this extension? Only
eleven patches submitted in the last 15 months.

(*) -- the
algorithm happens to be buggy these days, but apparently equally buggy for
all repos, which still results in some kind of justice.


Quim Gil
Engineering Community Manager  <at>  Wikimedia Foundation
Wikitech-l mailing list
Wikitech-l <at>
MZMcBride | 23 Jul 02:36 2014

Exposing and managing private account info


There are three types of private account info I've been considering:

* unexposed in the user interface/hidden/API-only user preferences;
* user session information; and
* per-action CheckUser-related information that's temporarily stored.

What I'd like to see is a single portal (e.g., Special:AccountInfo) that
combines and enhances the functionalities of these two extensions:


This portal would be a straightforward dashboard that allows users to see
and manage the private information associated with their account. Advanced
user preferences would be toggle-able (similar to chrome://config or
whatever), active sessions could be inspected or terminated, etc.

Perhaps this special page would require successfully entering the user's
current account password to avoid a bad actor jumping on a victim's
computer or other similar types of nefariousness.


Wikitech-l mailing list
Wikitech-l <at>
Pep Adrian | 22 Jul 13:34 2014

RE:Call for Wikimedia Hackathon(s) 2014-2015

Thanks everyone for their time yesterday. It was a really useful sesion to
solve some of our main doubts regarding the organization.

I missed some parts due to bad network connection but did someone ask for a
detailed budget of previous hackathons? (Zurich & Amsterdam) This will be
very useful to prepare our proposal. Are they available online?

Thanks again!
Wikitech-l mailing list
Wikitech-l <at>
Pine W | 22 Jul 09:37 2014

Filtering junk email sent to multiple Wikimedia mailing lists

Can we block spammish posts like this from going to multiple mailing lists
if multiple lists are indicated in the "to" field? Here a number of lists
were saved from this irrelevant email only because the lists were included
in the cc field.

Wikitech-l mailing list
Wikitech-l <at>
Robert Vogel | 22 Jul 08:23 2014

Gadget I18N: Recommendation?

Hello everybody,

I'm trying to figure out the best method for internationalization/localization of MediaWiki Gadgets.
There are several approaches implemented in the different available gadgets, but none of them seem to use
MediaWikis client side message system. I want to use something like


But this only works with message keys that are available on the client side, based on the 'messages' field of
a server side module definition ($wgResourceModules). The clientside

mw.loader.implement( moduleName, scripts, styles, messages );

has a parameter for a 'messages' config object. But it does not load the translation texts for the keys
automatically. Actually it expects a JavaScript object that contains keys _and_ values [1]. I've tried
whether the values get overridden when a translation on the MediaWiki-namespace is available, but they
don't seem to. Am I missing something important? Can you recommend a method for I18N in a gadget?

Just for the record: I've been experimenting with keeping the messages in subpages
("MediaWiki:Gadget.-/de.js") in JSON format [2] and loading them on runtime via AJAX [3]. I think  this
has some beauty because it's close to what MediaWiki does on the server side. Unfortunately in this case
I'll have to implement a language fallback [4] by myself. Any thoughts or hints?



(Continue reading)

Sumana Harihareswara | 22 Jul 05:26 2014

Architecture guidelines could use your perspective

I have worked on improving the architecture guidelines, but I think they
are still a draft, and I'm sorry about that, because I wanted to have that
done by now. Specifically, I think the "YAGNI" and "separation of concerns"
sections could be clearer, and I'd love more examples of times in the past
we did data-driven change well or badly.

I suggest that we talk onlist, onwiki, and in a future RfC meeting about
those points. I'm this week moving on to working on API documentation but I can participate
in those discussions.

Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
Wikitech-l mailing list
Wikitech-l <at>
Sumana Harihareswara | 22 Jul 04:35 2014

Security guidelines

Hi all! Check out -- I
just removed the {{draft}} tag.

These security guidelines help lead developers, architects, and product
managers make decisions that protect MediaWiki's users when developing new
features or refactoring old code.

All MediaWiki developers can follow these principles and process when
developing new core features or extensions. If a developer or team is
planning to have their code deployed on the Wikimedia cluster, following
these guidelines will ensure the security review process is quick and
requires minimal changes before deployment.

This guide interrelates with the Architecture guidelines
<>, Performance
guidelines <>, and user
experience guidelines
Thanks to everyone who helped write these, especially Chris Steipp -- he
wrote most of it and I helped. Thanks also to the chiptunes at which helped me power through. :-)

Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
Wikitech-l mailing list
Wikitech-l <at>
(Continue reading)

Sumana Harihareswara | 21 Jul 17:40 2014

RFC discussion Wednesday: Composer-managed libraries on WMF cluster

This Wednesday we're discussing Bryan Davis's suggested "process for using
managed PHP libraries to support MediaWiki on the WMF production and
beta clusters."

He says: "I would really appreciate comments from those of you
spend time thinking about keeping the cluster running smoothly and
securely. I would especially be excited to hear ideas about how we can
ensure that upstream security issues are tracked and responded to in a
timely manner."

2100-2200 UTC on Wednesday, 23 July, in #wikimedia-office on Freenode IRC.
All are welcome, as usual.

 10pm London
 5pm New York City
 2pm San Francisco
 Thursday 7am Sydney

Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
Wikitech-l mailing list
Wikitech-l <at>
reporter | 21 Jul 05:00 2014

Bugzilla Weekly Report

MediaWiki Bugzilla Report for July 14, 2014 - July 21, 2014

Status changes this week

Reports changed/set to UNCONFIRMED:  2                             
Reports changed/set to NEW        :  28                            
Reports changed/set to ASSIGNED   :  31                            
Reports changed/set to REOPENED   :  10                            
Reports changed/set to PATCH_TO_RE:  99                            
Reports changed/set to RESOLVED   :  300                           
Reports changed/set to VERIFIED   :  87                            

Total reports still open              : 15225                         
Total bugs still open                 : 9241                          
Total non-lowest prio. bugs still open: 8978                          
Total enhancements still open         : 5984                          

Reports created this week: 342                           

Resolutions for the week:

Reports marked FIXED     :  193                           
Reports marked DUPLICATE :  34                            
Reports marked INVALID   :  14                            
Reports marked WORKSFORME:  39                            
Reports marked WONTFIX   :  18                            

Specific Product/Component Resolutions & User Metrics 

Created reports per component
(Continue reading)