Wikitech-l November 2010

wikitech-l@lists.wikimedia.org

88 participants
70 discussions

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 12 Nov '10

12 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

Killing $wgStyleDirectory
by Trevor Parscal 12 Nov '10

12 Nov '10

In relation to: https://bugzilla.wikimedia.org/show_bug.cgi?id=25124 - I am considering removing $wgStyleDirectory rather than further depending on it. It seems that it's only partially used right now, and making the style directory variable but not other directories is inconsistent as well. There was some point about this being a feature that makes MediaWiki more flexible, but I'm unsure this is actually adding flexibility, it seems more like unnecessary complexity. I'm considering just removing it - any points to the contrary would help me make this decision. - Trevor

5 6

Is that download.wikimedia.org server is down?
by Billy Chan 12 Nov '10

12 Nov '10

Hi all, I am trying to download mediawiki by the following link, but with no luck, the server seems down: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.tar.gz Anybody know where should i report to and how the service could be resume? thanks.

7 9

Resource Loader problem
by Jeroen De Dauw 11 Nov '10

11 Nov '10

Hey, I'm doing some effort to use the Resource Loader in the Maps extension. A problem I've run into is that I apparently cannot use things defined in another module that already loaded. What I'm doing is loading the OpenLayers library, and then another JS file that uses the OpenLayers library to create the actual maps on the page. After looking at this with Firebug, I guess it's a scope issue, as each module's contents is getting put in a function. Are there currently ways to correctly load such libraries? And if not, what would be a good way of creating this? Making a new class that derives from ResourceLoaderModule? Cheers -- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --

8 32

Question about external links CSS
by emmanuel＠engelhart.org 10 Nov '10

10 Nov '10

Hi, FTP external link CSS looks like that: #bodyContent a.external[href ^="ftp://"], .link-ftp { background: url(file_icon.gif) center right no-repeat; padding: 0 18px; } The padding is 18px on the left AND on the right and 0px otherwise. This is though I guess to reserve space for the small icon placed on the right of the link. I have two questions: * Why we have defined a padding also on the left (and not set padding: 0 18px 0 0;)? * Why on the online site we do not see the padding on the left? I ask these questions, because after using the dumpHTML extension, I have this issue: I see the 18px big padding on the left with the static html files. See this old bug report https://bugzilla.wikimedia.org/show_bug.cgi?id=20828 Thanks for your help Emmanuel

5 8

Selenium Smoke Test Framework
by Jinesh De Silva 10 Nov '10

10 Nov '10

Hi All, More Test Cases could be add to the existing Selenium Test framework. The idea should be to test the main Wiki Editor functionalities and Page view/preview functionalities in a smoke test suite. The detailed administrative functionalities as User Preferences (more advanced features as Managing Watch-list, Advanced options in Editing, E-mail options) should be covered in a separate detailed test suite if necessary. Wiki Editor functionalities can be tested by automating "Content Addition" in a new wiki page. All the basic text editing can be performed and should be verified in page preview and saved page view. The same page can be tested for "Content Editing" by performing same editing functionalities in the previously saved page. The content changes can be verified in page preview and saved page view. Set Basic preferences can be tested separately and basic settings as Basic Information, Signature, Date Format, Skin can be tested. The applied preferences can be verified against the saved page. The other utility functionalities as Search for Pages, Move Page, My Watch-list, My Contributions, Delete Pages can be tested at the end of the test suite. Delete Page functionality can be used to delete all the newly created pages. So the smoke test suite can be of 4 main test suites; Add content to new Page (Wiki Editor for new page) Edit content (Edit content in existing page) Basic user preferences (Basic Information, Signature, Date Format, Skin) Extra features (search, move, delete, watch-list, contribution) All the above can be supported by some common functionalities as; User Login Search for Pages Search and copy Text Select applied skin Get Page Name and other attributes (Page Headings/Titles etc.) Get text atttributes (bold, italic, font size etc.) Regards, Jinesh De Silva Calcey Technologies - <http://www.calcey.com/> www.calcey.com Voice: +94 11 2827560 Fax : +94 11 2827561

5 4

Considering mirroring mediawiki-1.16.0.tar.gz
by Tei 10 Nov '10

10 Nov '10

Hi, Just a sugestion. Downloading the last version of MediaWiki seems to take ages ATM. Maybe servers are overloaded. And not mirror is offered. $ wget http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.tar.gz this takes ages I have managed to download with this: $ svn checkout http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_16/phase3 But I suppose is not the prefered method. I may be a good idea to provide mirrors for the mediawiki-1.16.0.tar.gz file. -- -- ℱin del ℳensaje.

2 2

Bugzilla Weekly Report
by reporter 10 Nov '10

10 Nov '10

MediaWiki Bugzilla Report for November 01, 2010 - November 08, 2010 Status changes this week Bugs NEW : 176 Bugs ASSIGNED : 11 Bugs REOPENED : 22 Bugs RESOLVED : 82 Total bugs still open: 5136 Resolutions for the week: Bugs marked FIXED : 53 Bugs marked REMIND : 0 Bugs marked INVALID : 9 Bugs marked DUPLICATE : 14 Bugs marked WONTFIX : 5 Bugs marked WORKSFORME : 6 Bugs marked LATER : 0 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 11 UploadWizard 10 LiquidThreads 5 Page rendering 4 Uploading 3 New Bugs Per Product MediaWiki 22 Wikimedia 16 MediaWiki extensions 32 Wikipedia Mobile 2 Top 5 Bug Resolvers roan.kattouw [AT] gmail.com 16 hartman [AT] videolan.org 15 ialex.wiki [AT] gmail.com 7 innocentkiller [AT] gmail.com 3 rkaldari [AT] wikimedia.org 2

5 5

2025

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