Wikitech-l November 2010

wikitech-l@lists.wikimedia.org

88 participants
67 discussions

Open and transparency or not
by a b 15 Nov '10

15 Nov '10

Interesting..... users/developers comment on the inclusion of reCATCHPA within the fund-raising[1] code since other projects have been they can't utilize its services then ~two weeks later (which isn't all that long in wmf time) its project documentation is moved off wiki (mw wiki) into the office[2] wiki which is private to WMF staff members only.... I will let everybody think about that. [1]. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/70919 [2]. http://www.mediawiki.org/w/index.php?title=Payment_Fraud_Prevention&action=…

4 3

WinCache support review ?
by Ashar Voultoiz 15 Nov '10

15 Nov '10

Hello, Chad added support for the Microsoft Windows Cache (WINCACHE) with r66364 and r66369, thus fixing bug 22844. This is obviously not going to be used for WikiMedia and I am not sure a lot of our developers are able to test it. Should we just mark both revisions as deferred or is there anyone willing to review this feature ? =) Links: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/66364 http://www.mediawiki.org/wiki/Special:Code/MediaWiki/66369 https://bugzilla.wikimedia.org/show_bug.cgi?id=22844 -- Ashar Voultoiz

3 2

Bugzilla Weekly Report
by reporter 14 Nov '10

14 Nov '10

MediaWiki Bugzilla Report for November 08, 2010 - November 15, 2010 Status changes this week Bugs NEW : 131 Bugs ASSIGNED : 5 Bugs REOPENED : 16 Bugs RESOLVED : 113 Total bugs still open: 5140 Resolutions for the week: Bugs marked FIXED : 82 Bugs marked REMIND : 0 Bugs marked INVALID : 7 Bugs marked DUPLICATE : 13 Bugs marked WONTFIX : 7 Bugs marked WORKSFORME : 3 Bugs marked LATER : 1 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 6 SemanticForms 4 AbuseFilter 4 WikiBhasha 4 Special pages 3 New Bugs Per Product MediaWiki 19 Wikimedia 12 MediaWiki extensions 28 mwEmbed 4 XML Snapshots 1 Top 5 Bug Resolvers jeluf [AT] gmx.de 25 ialex.wiki [AT] gmail.com 18 agarrett [AT] wikimedia.org 8 roan.kattouw [AT] gmail.com 6 rhalsell [AT] wikimedia.org 5

1 0

Call to arms - installer translations
by Max Semenik 14 Nov '10

14 Nov '10

As you all know, the installer was rewritten recently. Step-by-step wizard, JS magic, UI for configuration options that previously had to be manually changed in LocalSettings, in-place upgrades, you name it. However, there's one thing about it that needs YOUR help: translations. The new installer (at last!) has localisable interface, and it needs translations to be usable to more people around the world. However, from my experience with installer translations: * Most translators are non-techies, they have problems with long messages full of that weird IT lingo. * Things are bad when translators avoid translating a message because they don't understand it. Things get much, much worse if they think that they know how to translate them, but in reality they're wrong. * While simple users usually can take a look at wiki to have an idea how things work, this is not an option with the installer. Some messages may therefore be translated out of context. So those of you who are proficient in languages other than English - YOU can make a difference. Go to http://translatewiki.net and start translating. If there are already some translations in your language, double-check them - I assure you, there will be things to fix. Once everything is complete, try running the installer a few times, covering as many execution paths as you can - there will be things to fix. This way, we can ensure much better localisation. Oh, and forgive me my propagandist style - I couldn't help myself :) -- Max Semenik ([[User:MaxSem]])

2 1

Refresh of the Mediawiki logo
by Leo Koppelkamm 14 Nov '10

14 Nov '10

Hi, after seeing the new "powered by MediaWiki" button, I got motivated to rework the existing tournesol logo a bit. Mainly because the use of photos in logos is often discouraged and the path version looks a bit "friendlier" as well. What do you think of it? Fullsize: http://commons.wikimedia.org/wiki/File:Mediawiki_logo_reworked.svg 135px ($wgLogo size): http://upload.wikimedia.org/wikipedia/commons/thumb/3/30/Mediawiki_logo_rew… Mediawiki_logo_reworked.svg.png

13 14

CategoryFeed
by Max Semenik 13 Nov '10

13 Nov '10

This extension received no significant updates for the last 5 years and doesn't work with anything newer than 1.4. It doesn't even have a description page on mw.org. Nevertheless, numerous developers was^H^H^H spent their time on it while doing batch improvements to the whole extensions directory. Is someone interested in reviving it, or we can delete it right away? -- Max Semenik ([[User:MaxSem]])

1 0

Re: [Wikitech-l] Resource Loader bug 20962 ( {{PLURAL}} support )
by Dmitriy Sintsov 13 Nov '10

13 Nov '10

* Michael Dale <mdale(a)wikimedia.org> [Sat, 13 Nov 2010 17:08:50 +0100]: > On 11/10/2010 05:53 PM, Dmitriy Sintsov wrote: > > > > As Roan have pointed out, local messages don't need a complete parser > > anyway. I hope you have the time to merge it, if so can you announce > > that, please? > > Dmitriy > > The bug has been updated with a patch. Some integration notes are in the > bug comment. > Thank you a lot. I'll update from trunk and try to use it client-side in my extension. Dmitriy

1 0

Re: [Wikitech-l] Resource Loader problem
by Dmitriy Sintsov 13 Nov '10

13 Nov '10

* Michael Dale <mdale(a)wikimedia.org> [Wed, 10 Nov 2010 17:20:26 +0100]: > The code is not spread across many files.. its a single mw.Parser.js > file. Its being used in my gadget and Neil's upload wizard. I agree > the parser is not the "ideal parser", its not feature complete, is not > very optimised, and it was hacked together quickly. But it passes all > the tests and matches the output of php for all the messages across all > the languages. I should have time in the next few days to re merge / > clean it up a bit if "no one else" is doing it. > As Roan have pointed out, local messages don't need a complete parser anyway. I hope you have the time to merge it, if so can you announce that, please? Dmitriy

2 1

Request for comments
by Huji Lee 12 Nov '10

12 Nov '10

Hi I would be grateful if one could review the the functions added in the patch<https://bugzilla.wikimedia.org/attachment.cgi?id=7813&action=diff>I attached to bug 24411 <https://bugzilla.wikimedia.org/show_bug.cgi?id=24411> and post comments on the bug on how to improve the code. Best, Hojjat (aka Huji)

1 0

Backward compatibility guidelines
by Aryeh Gregor 11 Nov '10

11 Nov '10

We just had a discussion in #mediawiki about this commit: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/76064 It removed wfLoadExtensionMessages() from dozens of extensions in trunk. With trunk MediaWiki, this causes no problems, since the function does nothing. But in older MediaWiki versions, it will cause the extension to break. Yaron reported that he quickly got a complaint from someone using one of his trunk extensions together with MediaWiki 1.15. This kind of thing has come up before, e.g., the removal of IE5 support from Monobook. My take on this is that the cost-benefit analysis is very simple: * Cost to users of removing wfLoadExtensionMessages() from trunk extensions: If the extension happened to work on some old MW version (some do), the extension breaks. * Benefit to users of removing wfLoadExtensionMessages() from trunk extensions: Nothing. Extension works the same as before, no better or worse. I think it's very clear that in cases like this, we should not remove back-compat. If there's some benefit, then maybe -- for instance, if the code is hard to maintain, that could outweigh back-compat benefits. But this code isn't hard to maintain at all, it's one line in each extension. If there's no cost, then sure -- for instance, if the extension already only works on trunk for some other reason (maybe a new feature was added that uses a trunk function), then no harm is caused by removing the back-compat lines. But going out of your way to remove back-compat when that will hurt some users and not ease development *quantifiably* does not make any sense, and IMO no one should be doing that. ("Quantifiably" means "I'm not going to bother adding new feature X if I have to maintain back-compat while doing it", not "I think the code is uglier".) We can disagree about how much work we need to go into to maintain back-compat, but it's not *negative* -- putting work into removing back-compat without clear gain does not make sense. I've created a page on mediawiki.org to set out some guidelines we can consider: <http://www.mediawiki.org/wiki/Backward_compatibility>. I think we should get something written down that we can agree on, since this issue has come up more than once before and the same people tend to repeat the same disagreements every time.

7 10

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 November 2010