[MediaWiki-CodeReview] [MediaWiki r108719]: New comment added
Santhosh.thottingal posted a comment on MediaWiki.r108719. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108719#c29445 Commit summary for MediaWiki.r108719: I18n #410: some hacky code for adding help links Santhosh.thottingal's comment: Forgot to add help.png? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108719]: New comment added
Nikerabbit posted a comment on MediaWiki.r108719. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108719#c29446 Commit summary for MediaWiki.r108719: I18n #410: some hacky code for adding help links Nikerabbit's comment: Yes. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108793]: New comment added
Santhosh.thottingal posted a comment on MediaWiki.r108793. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108793#c29448 Commit summary for MediaWiki.r108793: Add image ping r108719 Santhosh.thottingal's comment: That makes two image directories - one under the extension root and another under resources folder. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88633]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r88633 to fixme and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88633#c29449 Old Status: resolved New Status: fixme Commit summary for MediaWiki.r88633: * In core: ** Added hooks for custom RC/newpages filters ** Added tables,fields,and join_conds to SpecialNewPagesConditions hook ** Removed superflous $nameSpace logic in watchlist code ** Removed some copy-paste code for RC/watchlist filters ** Updates hooks.txt * In FlaggedRevs: * Added hide reviewed edits filter to RC/newpages * Combined two handlers into modifyChangesListQuery. Removed is_array() check - always true now. * Fixed onBeforePageDisplay() so that CSS worked on sp:Watchlist * @TODO: remove $wgUseRCPatrol stuff...this gets us closer. Nikerabbit's comment: Reproduce-able notices with urls like: http://translatewiki.net/w/i.php?target=1%29%20declare%20%40q%20varchar%288000%29%20select%20%40q%20%3D%200x57414954464F522044454C4159202730303A30303A313527%20exec%28%40q%29%20--title=Special:RecentChangesLinked/Main_Pagefeed=atom Notices like: [13-Jan-2012 08:47:52] PHP Warning: Invalid argument supplied for foreach() in /www/w/includes/specials/SpecialRecentchanges.php on line 816 The way the customFilters is used elsewhere but depends on call to setup() to have it initialized looks very fragile. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108794]: Revision status changed
Aaron Schulz changed the status of MediaWiki.r108794 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108794 Old status: new New status: ok Commit summary for MediaWiki.r108794: Fix broken indentation ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108793]: New comment added
Nikerabbit posted a comment on MediaWiki.r108793. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108793#c29450 Commit summary for MediaWiki.r108793: Add image ping r108719 Nikerabbit's comment: Yup. The other images could be moved here. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Breaking backwards compatibility (Re: MediaWiki 1.18 learnings from a wiki admin extension writer)
I think we should reconsider how we deal with backward compatibility,
I am one of people who believe that software should be kept backward
compatible as long as it's technically not causing troubles. It isn't
hard for dev to flag a variable or function as deprecated for some
reason and completely drop a support for it, but it should not
automatically become a standard for every function for which it is
possible to make a better alternative, rather than that we should
consider rewriting the body of old code to somehow use the new code
and keep the deprecated code working. I don't think it's best idea to
just drop support for all sw which has been using some functions /
variables whatever we just flagged as deprecated. Especially not
when it comes to parseable output like api, xml, json etc. I noticed
that latest release of semantic wiki changed behavior of json output
which probably broke lot of tools.
It is generally bad programmer behavior to drop support for old
software frequently, although it makes a dev life easier (I know
myself that keeping support for old sw is annoying, while we can
concentrate on new cool sw and is best just to forget we ever had some
old version), however it probably became a standard for most of open
source sw I know, apart of linux (which still has a very good support
for old versions of sw / drivers etc.)
Maybe we should consider keeping old extensions / tools / browsers and
such work even with newest version of sw we work on (like mediawiki)
and think more about the design of some output, so that we don't need
to change it in future (and in case we would need to, probably keep it
possible to retrieve also deprecated output style)
On Thu, Jan 12, 2012 at 11:05 PM, Rob Lanphier ro...@wikimedia.org wrote:
Hi DanB,
Comments inline:
On Thu, Jan 12, 2012 at 8:31 AM, Daniel Barrett d...@vistaprint.com wrote:
As MediaWiki 1.19 is getting ready, I'd like to offer information on how
MediaWiki 1.18.0 was the most difficult MW upgrade I've ever been through.
Some background: my team administers an internal wiki at a major company
with ~2000 users, over 100 extensions (many of them custom/unreleased), and
100K articles. I've been upgrading MW regularly since 1.11 - every release
and patch - and have never had this much trouble before, mainly because of
extensions that broke in 1.18. The typical MW upgrade takes me a day or
two including regression-testing our extensions. But 1.18 has taken me
weeks and I'm still not done.
Ugh...sorry to hear that.
This message is meant to be constructive helpful, not blameful: it's
quite possible that every issue was our fault for not keeping up on
exactly which functions globals were being deprecated, etc. I'd just like
to describe what kinds of things broke for a reasonably active wiki run by
well-meaning people, and to document how we fixed them.
This is very helpful, thank you.
I understand your frustration on a lot of these points, and I hope we can
do better in future releases. A lot of the problems you point out here are
issues where we broke backwards compatibility without really good reason to
do so. It's a tough balance, because we also want to reduce our technical
debt, but I think we're probably too haphazard in our approach to nuking
and modifying interfaces.
There's a few things that folks like yourself can do to avoid these
surprises
1. Look through your logs for deprecation warnings now and when you get
1.18 fully running
2. Start testing 1.19 (trunk) *now* rather than waiting for the release.
You may be able to catch a gratuitous interface change while there's still
time to revert it, saving yourself the trouble of updating your code and
saving others from going through the breakage you're experiencing now.
3. Release the source code to your extension, either directly on our site,
or on github/gitorious/wherever in anticipation of being able to mirror
your work in our shiny new Git repo. Our devs are generally pretty good
about updating extensions that are checked into our repository
4. If you can't release the source for whatever reason, help write unit
tests for the APIs that matter to you, so that you can track when they
break or are changed.
5. If you don't have time to help write unit tests, help identify those
APIs you'd like to see have unit tests. I don't know if we have a central
place to collect most wanted unit tests, but I'm sure something like that
could be started if you're interested in participating at that level.
I vaguely remember some of the changes you outline below, and I think some
of them even stung us during the 1.18 deploy. I'm interested in
understanding better why these changes were made.
More inline:
1. The global variable $action disappeared, breaking a bunch of our
extensions. I switched to $wgRequest-getVal('action').
I'll assume Chad is correct that this was never intended to be a stable
global.
2. The
[MediaWiki-CodeReview] [MediaWiki r108798]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108798 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108798 Old status: new New status: ok Commit summary for MediaWiki.r108798: a little bit of space between the arrow and the text ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108800]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r108800 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108800#c29451 Old Status: new New Status: ok Commit summary for MediaWiki.r108800: r88633: lazy-load 'customFilters' field in SpecialRecentChanges. Almost every function is public here so there no control of the order stuff happens. Nikerabbit's comment: Confirmed fixed. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88633]: Revision status changed
Nikerabbit changed the status of MediaWiki.r88633 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88633 Old status: fixme New status: resolved Commit summary for MediaWiki.r88633: * In core: ** Added hooks for custom RC/newpages filters ** Added tables,fields,and join_conds to SpecialNewPagesConditions hook ** Removed superflous $nameSpace logic in watchlist code ** Removed some copy-paste code for RC/watchlist filters ** Updates hooks.txt * In FlaggedRevs: * Added hide reviewed edits filter to RC/newpages * Combined two handlers into modifyChangesListQuery. Removed is_array() check - always true now. * Fixed onBeforePageDisplay() so that CSS worked on sp:Watchlist * @TODO: remove $wgUseRCPatrol stuff...this gets us closer. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108403]: New comment added
Nikerabbit posted a comment on MediaWiki.r108403. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108403#c29452 Commit summary for MediaWiki.r108403: Cleanup the convertPLural method for Lithuanian(lt) Add phpunit test cases. Nikerabbit's comment: Commit says cleanup, but to me it looks like this change behavior when only two forms are provied. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108343]: New comment added
Hashar posted a comment on MediaWiki.r108343. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108343#c29453 Commit summary for MediaWiki.r108343: [mw.config] wgAction shouldn't use direct URL values * Fixes bug 25800 * Depends on r108342 Hashar's comment: Where / how to reproduce etc? :-) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108343]: New comment added
Nikerabbit posted a comment on MediaWiki.r108343. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108343#c29454 Commit summary for MediaWiki.r108343: [mw.config] wgAction shouldn't use direct URL values * Fixes bug 25800 * Depends on r108342 Nikerabbit's comment: Some API calls. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108343]: New comment added
Nikerabbit posted a comment on MediaWiki.r108343. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108343#c29455 Commit summary for MediaWiki.r108343: [mw.config] wgAction shouldn't use direct URL values * Fixes bug 25800 * Depends on r108342 Nikerabbit's comment: http://translatewiki.net/ w/api.php?feedformat=atomtype=%27%29%20declare%20%40q%20varchar%288000%29%20select%20%40q%20%3D%200x57414954464F522044454C4159202730303A30303A313527%20exec%28%40q%29%20--talkpage=Supportaction=feedthreads ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108805]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108805 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108805 Old status: new New status: ok Commit summary for MediaWiki.r108805: Add help link to the main page of Special:Translate too. Followup r108804. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108804]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r108804 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108804#c29456 Old Status: new New Status: ok Commit summary for MediaWiki.r108804: Add help links for special pages of Translate. CSS cleanup. Nikerabbit's comment: Discussed on Skype about few minor things: * The target of the link in Special:Translate * The link comes after introduction text in some pages ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108403]: New comment added
Santhosh.thottingal posted a comment on MediaWiki.r108403. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108403#c29457 Commit summary for MediaWiki.r108403: Cleanup the convertPLural method for Lithuanian(lt) Add phpunit test cases. Santhosh.thottingal's comment: Suppose one and few are the only given forms. if count =1 we get one. if ( $count % 10 == 1 $count % 100 != 11 ) return $forms[0]; gives the same If count = anything else, either we will get either forms[1] or forms[2].but they are same since preConvertPlural copies forms[1] to forms[2] Did I miss to notice any change in behavior? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108403]: New comment added
Nikerabbit posted a comment on MediaWiki.r108403.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108403#c29458
Commit summary for MediaWiki.r108403:
Cleanup the convertPLural method for Lithuanian(lt)
Add phpunit test cases.
Nikerabbit's comment:
How about nowiki{{PLURAL:21|first|second}}/nowiki? It looks like to me that
it previous returned second, but now first.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108803]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108803 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108803 Old status: new New status: ok Commit summary for MediaWiki.r108803: Fix name and URL in extension credits. Could someone with more knowledge about the resource loader please check if $wgResourceModules['SpecialInterwiki'] could be changed to $wgResourceModules['Interwiki']? Thanks. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108802]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108802 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108802 Old status: new New status: ok Commit summary for MediaWiki.r108802: Ugh. Removed the wrong message. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108801]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108801 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108801 Old status: new New status: ok Commit summary for MediaWiki.r108801: Handle type:city(population) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108799]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108799 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108799 Old status: new New status: ok Commit summary for MediaWiki.r108799: Actually fix the loop problem this time. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108797]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108797 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108797 Old status: new New status: ok Commit summary for MediaWiki.r108797: Fix a nasty infinite loop. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108795]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108795 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108795 Old status: new New status: resolved Commit summary for MediaWiki.r108795: Remove unneeded extra section. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108791]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108791 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108791 Old status: new New status: ok Commit summary for MediaWiki.r108791: * Distinguish does not exist from failure in FSFileBackend::doGetFileStat(). * Added clearstatcache() to doConcatenate() to make it safe for callers to stat the file. * A few minor comment tweaks. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108790]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108790 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108790 Old status: new New status: ok Commit summary for MediaWiki.r108790: Follow-up to r108577 - fixed name of magic file ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108403]: New comment added
Santhosh.thottingal posted a comment on MediaWiki.r108403. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108403#c29459 Commit summary for MediaWiki.r108403: Cleanup the convertPLural method for Lithuanian(lt) Add phpunit test cases. Santhosh.thottingal's comment: ok, you are correct. But I think, out of [one, few, other ] 21 becoming one or few depending on a translator gave other forms is a tricky logic. CLDR says 1, 21, 31, 41, 51, 61... are one form. And that is what I understood from here: http://en.wikipedia.org/wiki/Lithuanian_grammar#Noun_modification_by_numeral too. I am not sure whether I need to reintorduce it. Javascript code does not have this count(forms) ==2 check. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108403]: New comment added
Nikerabbit posted a comment on MediaWiki.r108403. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108403#c29460 Commit summary for MediaWiki.r108403: Cleanup the convertPLural method for Lithuanian(lt) Add phpunit test cases. Nikerabbit's comment: We should probably get in touch with the lt translators to sort it out. I seem to recall that Russian has the same shortcut. lt JavaScript had the check before you removed it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107776]: New comment added, and revision status changed
IAlex changed the status of MediaWiki.r107776 to new and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107776#c29461 Old Status: fixme New Status: new Commit summary for MediaWiki.r107776: * Display all errors in showForm() instead of only the first one * First do some checks and then delete the target page instead of the opposite so we don't delete a page for no purpose if a problem arises * Changed some empty() checks to count() * Use Title::quickUserCan() to see whether to show the checkbox to delete the page or not instead of User::isAllowed() IAlex's comment: Fixed in r108806. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108376]: Revision status changed
IAlex changed the status of MediaWiki.r108376 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108376 Old status: ok New status: resolved Commit summary for MediaWiki.r108376: Fix double-escaping in 108312 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Mailing lists server migration today
Hi, Today I will be migrating the mailing lists from a very old server (lily) in Amsterdam, to a new server (sodium) in our new Ashburn data center. Mailman will be upgraded to version 2.1.13 along the way. During the migration, mail will be delayed as all data will need to be transferred to the new host. No mail should go lost, but no new mails will be sent out during the process until done, and the web interface will be unavailable. This shouldn't take more than one hour, if all goes well. I will report here when things should be back up and running. Afterwards, please let us know of any new issues, in bugzilla or on IRC (#wikimedia-tech). We don't expect any problems, but as with any software upgrade or migration, this can't be guaranteed... Thanks, -- Mark Bergsma m...@wikimedia.org Lead Operations Architect Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Want student help with your MediaWiki project?
I've arranged for MediaWiki to get some interns this spring. Four bright college students -- they already know web development and have had internships at Facebook, Google, and Microsoft -- need a mentor. https://www.mediawiki.org/wiki/UCOSP_Spring_2012 It's a bit like Google Summer of Code, but a part-time team rather than one full-timer. They'll each be working on MediaWiki 8-10 hours per week between now and the end of April. I figure I need one experienced MediaWiki developer as a mentor -- I'll be your admin, and community dev Amgine will be your backup. Amgine will lead the students in person next weekend during a code sprint in Vancouver. These interns don't yet know what they want to work on so you can choose a project with them. I'd help you run two half-hour IRC meetings per week and we'd run them through two-week iterations between now and the end of April. I figure it'd be about 5 hours a week, possibly more at the start as we ramp the students up. Please let me know as soon as possible, preferably today or Monday. I'd prefer that the students work on something that will be deployed on Wikimedia sites. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r100274]: Revision status changed
Jeroen De Dauw changed the status of MediaWiki.r100274 to new URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100274 Old status: fixme New status: new Commit summary for MediaWiki.r100274: created basic reminder email functionality ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108719]: Revision status changed
Santhosh.thottingal changed the status of MediaWiki.r108719 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108719 Old status: new New status: ok Commit summary for MediaWiki.r108719: I18n #410: some hacky code for adding help links ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108614]: Revision status changed
Santhosh.thottingal changed the status of MediaWiki.r108614 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108614 Old status: new New status: ok Commit summary for MediaWiki.r108614: Fix Uncaught TypeError: Cannot read property 'ttf' of undefined ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108806]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r108806 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108806#c29462 Old Status: new New Status: ok Commit summary for MediaWiki.r108806: Per Aaron, fix for r107776: correct count() check Nikerabbit's comment: === ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108807]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108807 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108807 Old status: new New status: ok Commit summary for MediaWiki.r108807: Fix for r108376: the whole string is already espcaed on output, no need to escape it twice ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108808]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108808 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108808 Old status: new New status: ok Commit summary for MediaWiki.r108808: svn:eol-style native ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108343]: New comment added
Krinkle posted a comment on MediaWiki.r108343. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108343#c29463 Commit summary for MediaWiki.r108343: [mw.config] wgAction shouldn't use direct URL values * Fixes bug 25800 * Depends on r108342 Krinkle's comment: See r108342 CR for discussion/solution. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108342]: New comment added
Krinkle posted a comment on MediaWiki.r108342. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108342#c29464 Commit summary for MediaWiki.r108342: Implement MediaWiki::getPerformedAction() * Fixes: -- Bug 27930 - Ablity to get current action (The Right Way) Krinkle's comment: In r108343 CR it is suggested to store this in the RequestContext instead. However, I don't think it has suffecient information to determine the currently performed action. (OutputPage, WebRequest, User, etc.. all these are part of context but neither has suffient information right now due to some action-stuff still being decided in MediaWiki::performAction, which is terrible). So one could add a public field to the Context class and let MediaWiki::performAction assign a value in it, but that only moves the problem. I think there is an underlaying problem, namely that this @!#$)! action stuff doesn't belong here in the first place. How about we move the remaining pieces (view, edit, submit, ..) into Action as well (either a couple few-line classes like ViewAction, EditAction, ProtectAction, etc. or move the switch statement from here to Action::factory). Either way, so that calling Action::factory with the query-string value of action will be a completely reliable return value that is without a doubt the currently performed action. Then it suddenly becomes very simply to determine the currently performed action from anywhere (could be something like ttpublic static function Action::getPerformedAction( $context )/tt). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90286]: New comment added, and revision status changed
Krinkle changed the status of MediaWiki.r90286 to resolved and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90286#c29465 Old Status: ok New Status: resolved Commit summary for MediaWiki.r90286: Swap else if for elseif Trimming trailing whitespace also Krinkle's comment: This broke part of JavaScript in tt/trunk/extensions/FCKeditor/FCKeditor.body.php /tt as it was replacing codeelse if/code in strings as well, instaed of just the PHP operators. The string in question was JavaScript, which doesn't have ttelseif/tt. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] CANCELED: Mailing lists server migration today
On Jan 13, 2012, at 2:54 PM, Mark Bergsma wrote: Hi, Today I will be migrating the mailing lists from a very old server (lily) in Amsterdam, to a new server (sodium) in our new Ashburn data center. Mailman will be upgraded to version 2.1.13 along the way. ...and right after I sent this mail, I rebooted the new server once more before starting the maintenance. But suddenly it refused to come back up, or even reinstall. Likely the server has hardware issues. Therefore the maintenance is canceled for today, until we've figured out what the problem is. The migration will probably happen next week, possibly using different hardware. -- Mark Bergsma m...@wikimedia.org Lead Operations Architect Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.18 learnings from a wiki admin extension writer
On Thu, Jan 12, 2012 at 5:57 PM, Chad innocentkil...@gmail.com wrote: On Thu, Jan 12, 2012 at 11:51 AM, Daniel Barrett d...@vistaprint.com wrote: Me: 8. Our MediaWiki:common.js stopped running on the login page. I realize this was a security fix; it just took me by surprise. Fixed by writing a custom extension using the hook UserLoginForm to inject the few lines of JS we needed, and I'm evaluating other non-JS solutions for more security. Chad writes: This hasn't changed any time recently as far as I can tell...we've had this in place for quite awhile. Thanks Chad. FYI, MediaWiki:common.js definitely runs on Special:UserLogin in 1.17.1, the immediately previous release. DanB Hrm...I distinctly remember user's personal JS was disabled on that page. I wonder if ResourceLoader by grouping the JS also ends up disabling it. In either case, it is a security issue and there's not much we can do about it right now. -Chad You're both right. It's basically for ever that those special pages call OutputPage::disallowUserJs(). In 1.18 Happy-melon implemented something I think we should've had a long time ago, proper origin recognizition on a module/script level. So it is known about each module where it comes from and to what extend it should be trusted or not. When rewriting security implementation from the basic OutputPage::disallowUserJs to this more elaborate way (using ORIGIN constants defined in the ResourceLoader class) it was probably (unconsciously?) switched from just JS by users, to modules (js/css) by origin = site (which also matches user JS). I'm not sure if that's how it happened, but that what I remember and it was kept. Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r107975]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107975 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107975 Old status: new New status: resolved Commit summary for MediaWiki.r107975: MFT r105341, t105853, r106780 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108274]: New comment added
IAlex posted a comment on MediaWiki.r108274. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108274#c29466 Commit summary for MediaWiki.r108274: * Added WikiPage to RequestContext and related so that it can be shared to avoid creating a new object each time and thus avoiding database queries to load the state of the object * Added Article::getPage() as accessor to the WikiPage object so that it can be set in the context from MediaWiki::initializeArticle() * Use it WikiPage::main() to call doViewUpdates() I'm doing to this now so that I can revert r105790 and use the WikiPage object before the 1.19 release IAlex's comment: The only other solution I see is to silently return null, but this will certainly throw a fatal error at some point because someone forgot to check that the page is not in a special namespace. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108274]: New comment added
IAlex posted a comment on MediaWiki.r108274. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108274#c29467 Commit summary for MediaWiki.r108274: * Added WikiPage to RequestContext and related so that it can be shared to avoid creating a new object each time and thus avoiding database queries to load the state of the object * Added Article::getPage() as accessor to the WikiPage object so that it can be set in the context from MediaWiki::initializeArticle() * Use it WikiPage::main() to call doViewUpdates() I'm doing to this now so that I can revert r105790 and use the WikiPage object before the 1.19 release IAlex's comment: What's the difference with the previous code? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108778]: New comment added
Rsterbin posted a comment on MediaWiki.r108778. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108778#c29468 Commit summary for MediaWiki.r108778: Added spam and abuse filtering: * NB: AbuseFilter setup tested with a simple filter using action=feedback. * AbuseFilter consequences are not used. * Existing AbuseFilter edit filters are not triggered on new feedback. - ArticleFeedbackv5.i18n.php: - Added messages 'articlefeedbackv5-error-abuse', 'articlefeedbackv5-error-abuse-linktext', and 'articlefeedbackv5-error-abuse-link' - ArticleFeedbackv5.hooks.php: - Updated module messages to include the new ones - modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.js: - Updated the error handler on submitForm() to create the abuse feedback link - ApiArticleFeedbackv5: - Removed call to abuse stub from validateParam() and replaced it with just the length check - Removed method validateText() - New method findAbuse() - Added a call to findAbuse() immediately after param validation Rsterbin's comment: Good point, thanks. Fixed in r108812. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] MediaWiki 1.18 learnings from a wiki admin extension writer
On Thu, Jan 12, 2012 at 5:39 PM, Chad innocentkil...@gmail.com wrote:
2. The removal of Xml::hidden() caused one of our extensions to break.
I switched to Xml::input(..., array('type', 'hidden'))
Xml::hidden() was removed entirely? There *is* Html::hidden() which should be
functionally similar.
Someone moved random methods from Xml to Html class without leaving
proper redirects for b/c behind. Whoever did this, he is surely loved
by the extension writers all around the world.
--vvv
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108295]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108295 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108295 Old status: new New status: ok Commit summary for MediaWiki.r108295: Comments: allow removing anonymous users from your ignore list. User::idFromName() returns null for anons, so we have to handle that here. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Breaking backwards compatibility (Re: MediaWiki 1.18 learnings from a wiki admin extension writer)
Rob, thanks for your comprehensive and thoughtful reply. ... bug 31676 (the 32-stylesheet limit of IE, https://bugzilla.wikimedia.org/show_bug.cgi?id=31676) which IMHO is a very serious time-bomb waiting to explode. I hope it makes it into 1.19wmf deployment as planned. Is this all versions of IE? Yes indeed. 9. The addHandler() function in JavaScript does not seem to work in IE8 anymore. We worked around this by using jQuery's bind function. Is there a bug for this problem? I haven't had time to produce a minimal test case to show that it happens, just a huge blob of code, so I haven't filed a bug report. I did mention it in this list and got the advice to use ready() (sorry, I wrote bind above): http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/057166.html DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] proposed tech conference anti-harassment policy
Hi! So, I am pro this policy. It's clean, neat, and easy to understand. However, in some ways, I feel that while a policy like this is a(n) (unfortunately) necessary tool to prevent discrimination and harassment at tech events, I do not think that it is sufficient. Let me explain. In my mind, policies such as this are useful when you either a) want to kick someone who's actions are unacceptable out of your event or b) something bad happened and the organizer wants to be able to point to the policy and say that was against our policy. These are both good things. Having conditions for ejection from an event is useful. However, in my mind, it does not address underlying issues, the variety of -isms, that contributed to harassment and discrimination. It has also been my experience in being around various folk at tech conferences (such as um... myself) that geeks like me often do not have 100% developed social skills and may already deal with feelings of isolation. Thus, what I would love to see would be, in addition to a policy such as this, activities specifically designed to foster closer community, connection, and to bring home that everyone at such an event is valuable, as well as establishing basic social expectations which can be very useful in social situations where participants come from a wide range of cultures and countries. I am, at this moment, not sure what form this thing that I am advocating would take, but I would definitely be interested in working with others to come up with such activities/models/etc. It would probably happen at the beginning of an event, and it would need to be enjoyable, so that people would actually want to come. This is as far as I've managed to get in my brainstorming. Thoughts? Ideas? Comments? -peter On Thu, Jan 12, 2012 at 4:47 PM, Sumana Harihareswara suma...@wikimedia.org wrote: Thanks, Danese. Right now this policy is limited to technical-only events for the reason you describe; I'm talking with other Wikimedia conference organizers to adjust wording for Wikimania and other not-just-technical events. -Sumana On 01/12/2012 04:40 PM, Danese Cooper wrote: Well done, Sumana. I especially like the start of the exception list. Presumably situations such as academic discourse on body function (at a WMF conference on improving content), or depictions of artifacts (in the GLAM context) would be exceptions. Danese On Jan 12, 2012, at 8:00 AM, Sumana Harihareswara suma...@wikimedia.org wrote: The Wikimedia Foundation is dedicated to a harassment-free conference experience for everyone. I'm proposing a fairly short and standard anti-harassment policy of the type that's becoming best practice for tech conferences and hackathons. Draft: https://www.mediawiki.org/wiki/User:Sumanah/AHP I don't imagine I'll get much response on this, but just wanted to put it out there before implementing. I intend on putting this into place by the middle of next week, in time for the San Francisco hackathon (starting January 20th). Comments on the talk page, please. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108811]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108811 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108811 Old status: new New status: ok Commit summary for MediaWiki.r108811: Add 'api-error-emptypage'. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108777]: New comment added
Reedy posted a comment on MediaWiki.r108777. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108777#c29469 Commit summary for MediaWiki.r108777: Maintenance class-ify eval.php Reedy's comment: Hmm. Whenever I used it, I just always did global $wgUser; etc first... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108812]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r108812 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108812#c29470 Old Status: new New Status: ok Commit summary for MediaWiki.r108812: Do the , SpamBlacklist, and AbuseFilter checks only when those are set up (followup to r108778) Nikerabbit's comment: svn ci -m? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108813]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108813 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108813 Old status: new New status: ok Commit summary for MediaWiki.r108813: Localise a likely error. Ping r108811. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108819]: New comment added
Nikerabbit posted a comment on MediaWiki.r108819. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108819#c29471 Commit summary for MediaWiki.r108819: Fixed dim handling, made it fall back to scale and type Nikerabbit's comment: Are these dimensions translatable? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108819]: New comment added
MaxSem posted a comment on MediaWiki.r108819. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108819#c29472 Commit summary for MediaWiki.r108819: Fixed dim handling, made it fall back to scale and type MaxSem's comment: This parser function reuses stuff intended for geohack, and geohack doesn't localise anything - thus, parameters will not be localised unless we write an in-MediaWiki replacement for geohack. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108657]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108657 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108657 Old status: new New status: ok Commit summary for MediaWiki.r108657: 1.18wmf1: Update ArticleFeedback to trunk state ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108666]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108666 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108666 Old status: new New status: ok Commit summary for MediaWiki.r108666: 1.18wmf1: Updating to trunk state to pick up r108665 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108671]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108671 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108671 Old status: new New status: ok Commit summary for MediaWiki.r108671: Revert r108603, which was itself a revert of r107376, r107994. Before considering something unneeded, please ask first ;) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108694]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108694 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108694 Old status: new New status: resolved Commit summary for MediaWiki.r108694: Load the Recaptcha class in a way that has some chance of even working ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101140]: Revision status changed
Siebrand changed the status of MediaWiki.r101140 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101140 Old status: new New status: resolved Commit summary for MediaWiki.r101140: Instead of displaying ugly API errors to unprivileged users, tell them to ask permission from $wgTranslatePermissionUrl ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108606]: Revision status changed
Siebrand changed the status of MediaWiki.r108606 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108606 Old status: new New status: ok Commit summary for MediaWiki.r108606: Revert r108562 - going to introduce new message in next commit ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107305]: Revision status changed
Siebrand changed the status of MediaWiki.r107305 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107305 Old status: new New status: ok Commit summary for MediaWiki.r107305: Rework ext.translate.quickedit.js from global functions into mw.translate Numerous JS fixes, like getting rid of legacy globals ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107380]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107380 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107380 Old status: new New status: ok Commit summary for MediaWiki.r107380: Revert r106546 based on IAlex's CR comments. I've already updated Bug #30047 to let the submitter know this need to be fixed. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108600]: Revision status changed
Siebrand changed the status of MediaWiki.r108600 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108600 Old status: new New status: ok Commit summary for MediaWiki.r108600: Add some top padding to avoid text with large font size not touching the toolbar. Also make sure enough line height is given for large font sizes. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107402]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107402 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107402 Old status: new New status: ok Commit summary for MediaWiki.r107402: [mediawiki.js] code quality and clean up * using local mw variable in file instead of reaching to global scope * exposing to global object after initialization * moving var statements to the top of the function, this uncovered a few risky re-use of variables. Fixed by using different names (in nested for-loops and unconnected if/else statements). This also made several awkward indentions go away (where the first definition would be indented for 'var', and later ones not). * remove unused messageQueue variable * enable strict mode in modern browsers (loose string ignored in other browsers) * where looking to check for array, use $.isArray() (directly pointed to native code) instead of a typeof operation with string comparison for object (slightly faster and also semantically more correct) * other best practices as popularized by JSLint/JSHint * removed 'delete' operator for startUp, didn't' do anything in most modern browsers, only for object members. @note: mw.loader.work really is big, now it's more obvious: code +varreqBase, splits, maxQueryLength, q, b, bSource, bGroup, bSourceGroup, + source, group, g, i, modules, maxVersion, sourceLoadScript, + currReqBase, currReqBaseLength, moduleMap, l, + lastDotIndex, prefix, suffix, bytesAdded; /code ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108029]: Revision status changed
Siebrand changed the status of MediaWiki.r108029 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108029 Old status: deferred New status: ok Commit summary for MediaWiki.r108029: Updated to new version ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107405]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107405 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107405 Old status: new New status: ok Commit summary for MediaWiki.r107405: [mediawiki.js] use simple IIFE closure with object literal * Remove weird new () syntax. Simply use a IIFE and return an object literal * Some blocks had to be moved -- $(document).ready in mw.loader to between vars and functions (couldn't be after the return) -- mw.legacy to near other place holders * Follows-up r107402 (view diff with whitespace ignored: $ svn diff -x -wu) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88118]: New comment added
Fomafix posted a comment on MediaWiki.r88118. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88118#c29473 Commit summary for MediaWiki.r88118: Fix Bug 28979 — “remove some CSS for abbr and acronym tags” The abbr and acronym tags were whitelisted with bug 671, but there are some CSS rules for them since long, long times. They can be found in the first versions of chick, monobook and are carried on to vector skin. Often these tags are used in links, e.g. [[Normalnull|abbr title=meter above see levelNN/abbr]]. But in here the color:black; makes the text unrecognizable as a hyperlink (together with the senseful cursor:help; rule). When these rules where meant to override some crazy browserdependent default settings, they should be be changed to inherit. from Bergi Fomafix's comment: Reported as Bug 33703. Further examples: div style=padding:.5em; background-color:black; color:redred on black: span style=border-bottom: 1px dotted blackborder-bottom: 1px dotted black/span, span style=border-bottom: 1px dottedborder-bottom: 1px dotted/span./div div style=padding:.5em; background-color:white; color:redred on white: span style=border-bottom: 1px dotted blackborder-bottom: 1px dotted black/span, span style=border-bottom: 1px dottedborder-bottom: 1px dotted/span./div div style=padding:.5em; background-color:black; color:whitewhite on black: span style=border-bottom: 1px dotted blackborder-bottom: 1px dotted black/span, span style=border-bottom: 1px dottedborder-bottom: 1px dotted/span./div ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107422]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r107422 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107422#c29474 Old Status: new New Status: ok Commit summary for MediaWiki.r107422: Use implode rather than a poor foreach equivalent. Follow up to r107415. Nikerabbit's comment: Which didn't even work. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108738]: Revision status changed
Siebrand changed the status of MediaWiki.r108738 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108738 Old status: new New status: ok Commit summary for MediaWiki.r108738: * fixed some i18n errors. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108660]: Revision status changed
Siebrand changed the status of MediaWiki.r108660 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108660 Old status: new New status: ok Commit summary for MediaWiki.r108660: Get rid of pipe symbol in translatable page group ids. They cause too many problems, like bug 33666 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108215]: Revision status changed
Siebrand changed the status of MediaWiki.r108215 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108215 Old status: new New status: ok Commit summary for MediaWiki.r108215: Prevent #firstHeading overriding the language specific h1 height. Ref Bug 30809 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r102669]: Revision status changed
Siebrand changed the status of MediaWiki.r102669 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102669 Old status: deferred New status: ok Commit summary for MediaWiki.r102669: Adding Dutch messages and removing translations for local user groups ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108809]: New comment added, and revision status changed
Siebrand changed the status of MediaWiki.r108809 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108809#c29475 Old Status: new New Status: ok Commit summary for MediaWiki.r108809: follow up to r100274 - plural use in js messages Siebrand's comment: Yay! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108810]: New comment added, and revision status changed
Siebrand changed the status of MediaWiki.r108810 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108810#c29476 Old Status: new New Status: ok Commit summary for MediaWiki.r108810: plural in js messages Siebrand's comment: More yay! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r78453]: New comment added
Siebrand posted a comment on MediaWiki.r78453. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/78453#c29477 Commit summary for MediaWiki.r78453: Using $ replacement in message - fixes hacky thing done in r78405. Siebrand's comment: This is now available. See r108809 for example. Adding keyword jsplural, although IMO it should be fixme... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107775]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r107775 to fixme and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107775#c29478 Old Status: new New Status: fixme Commit summary for MediaWiki.r107775: improving testability under windows os Nikerabbit's comment: Typo? openPropertieFile The comments are indented weirdly: + System.getProperty(user.dir) +TEST_DATA_FOLDER + testFilename //in test-data ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107007]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107007 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107007 Old status: new New status: ok Commit summary for MediaWiki.r107007: Don't check badlogin attempts in memcached if we are not configured to show captchas on bad login. Solves problem reported in http://www.mediawiki.org/w/index.php?title=Extension_talk:ConfirmEditoffset=20111218172150#Banned_user_got_banned_until_he_logs_in_9982 where $wgCaptchaTriggers['badlogin'] = false was set to disable that captcha, but as the user had already passed the threshold, it still was shown. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107097]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107097 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107097 Old status: new New status: ok Commit summary for MediaWiki.r107097: Fix issue with deleting security groups. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r95787]: Revision status changed
Nikerabbit changed the status of MediaWiki.r95787 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/95787 Old status: new New status: resolved Commit summary for MediaWiki.r95787: RL2: Add hooks that ensure the database is updated when Gadget definition: pages are deleted and undeleted ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r96010]: Revision status changed
Nikerabbit changed the status of MediaWiki.r96010 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/96010 Old status: new New status: ok Commit summary for MediaWiki.r96010: RL2: Refactor GadgetPageList resulting in less code duplication in GadgetHooks * Factor getRowForTitle() out of add(), will be useful for the maintenance script I'm about to commit * Factor the duplicated if-redirect-else logic out into updatePageStatus() ** also use it in the undelete hook, it appears that previously suffered of a bug where undeleting a newer revision on top of an older one making the page a redirect didn't cause it to be unlisted in gadgetpagelist * Add a function isGadgetPage() that checks if a page qualifies for being in the table. Not used anywhere right now but will be used by the maintenance script ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97052]: Revision status changed
Nikerabbit changed the status of MediaWiki.r97052 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97052 Old status: new New status: ok Commit summary for MediaWiki.r97052: RL2: Followup to r96954 and r97005: add i18n messages for the validation stuff. The messages aren't very good at this point and may need tweaking, but at least they exist now. Merged the notanobject message into the invalidjson message because the distinction between 3A (invalid JSON) and 3 (valid JSON, but of type integer) is not really important. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97055]: Revision status changed
Nikerabbit changed the status of MediaWiki.r97055 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97055 Old status: new New status: ok Commit summary for MediaWiki.r97055: RL2: Per CR on r96863, moved getCategoryTitle() to LocalGadgetRepo. Also turned it from a static method into an object method. Even though it could be static right now (it doesn't use $this), it seems more future-proof to do it this way. All current callers have a $repo object at hand, so making it non-static now doesn't break anything, and it's easier to make a non-static method static (from the callers' perspective) than to make a static method non-static. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98878]: Revision status changed
Nikerabbit changed the status of MediaWiki.r98878 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98878 Old status: new New status: ok Commit summary for MediaWiki.r98878: [RL2] Followup r96837, prevent requests for nonexistent modules from polluting the gadget names cache by caching nonexistence separately. For more details about the bug this was causing, see CR comments on r96837. * Introduce LocalGadgetRepo::$missCache that caches nonexistence of gadgets * Use $data for caching existing gadgets only * In memcached, continue to cache nonexistence by storing an empty array. This requires some logic to ensure the right object member is updated * Document the in-object caching vars * Fix clearInObjectCache() to really clear everything * When deleting a gadget, set its cache entry to an empty array rather than removing it * Update $missCache for modifications and deletions too * Add an optimization where all gadgets that aren't in $data are (rightly) assumed no to exist if $idsLoaded is true ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108184]: New comment added
Nikerabbit posted a comment on MediaWiki.r108184. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108184#c29479 Commit summary for MediaWiki.r108184: ResourceLoader: Add an experimental option to move the main module loading queue (the bottom queue) from the bottom of the body up into the head , while still being loaded asynchronously. This makes them load earlier, which should make the page load faster. This is the product of a long discussion on bug 27488 * Added a blocking state to mw.loader . When loading scripts while the document is not ready, the loader will use document.write() if blocking is true, and append to the body or the head if blocking is false. If the document is ready, the loader will always append to the body * Enable blocking mode while loading the top queue, and disable it after. This ensures that modules in the top queue are still loaded in a blocking way as they were before * If $wgResourceLoaderExperimentalAsyncLoading is true, the bottom queue is also loaded in the head, but with blocking mode disabled. Otherwise, it's loaded at the bottom of the body as before * scripts-only and messages-only requests need special treatment: ** in the top queue, they can continue to use script src=... tags because they are blocking ** if the bottom queue is at the bottom of the body (experimental async loading disabled), they can continue to use script src=... tags as before ** if the bottom queue is in the head (experimental async loading enabled), they cannot use script src=... tags, because those would block. Instead, call mw.loader.load() on the load.php URL Nikerabbit's comment: There are some JS errors in twn log: 2012-01-11T03:17:22UTC mw.loader.setBlocking is not a function http://translatewiki.net/wiki/Translating:Kiwix:31 X.Y.Z.K Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0 URL: http://translatewiki.net/wiki/Translating:Kiwix STACK: (mw.loader.setBlocking is not a function,http://translatewiki.net/wiki/Translating:Kiwix,31)@http://translatewiki.net/w/load.php?debug=falselang=enmodules=jquery%2Cmediawiki%7Ctwn.jserrorlogonly=scriptsskin=vectorversion=20111230T233043Z:156 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108812]: New comment added
Rsterbin posted a comment on MediaWiki.r108812. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108812#c29480 Commit summary for MediaWiki.r108812: Do the , SpamBlacklist, and AbuseFilter checks only when those are set up (followup to r108778) Rsterbin's comment: Yeah, that was supposed to be $wgSpamRegex ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108184]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108184 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108184 Old status: new New status: resolved Commit summary for MediaWiki.r108184: ResourceLoader: Add an experimental option to move the main module loading queue (the bottom queue) from the bottom of the body up into the head , while still being loaded asynchronously. This makes them load earlier, which should make the page load faster. This is the product of a long discussion on bug 27488 * Added a blocking state to mw.loader . When loading scripts while the document is not ready, the loader will use document.write() if blocking is true, and append to the body or the head if blocking is false. If the document is ready, the loader will always append to the body * Enable blocking mode while loading the top queue, and disable it after. This ensures that modules in the top queue are still loaded in a blocking way as they were before * If $wgResourceLoaderExperimentalAsyncLoading is true, the bottom queue is also loaded in the head, but with blocking mode disabled. Otherwise, it's loaded at the bottom of the body as before * scripts-only and messages-only requests need special treatment: ** in the top queue, they can continue to use script src=... tags because they are blocking ** if the bottom queue is at the bottom of the body (experimental async loading disabled), they can continue to use script src=... tags as before ** if the bottom queue is in the head (experimental async loading enabled), they cannot use script src=... tags, because those would block. Instead, call mw.loader.load() on the load.php URL ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] postgreSQL testing
On Thu, 12 Jan 2012 16:17:00 +0100, Antoine Musso wrote: Hello, I have added a new continuous integration job to check our postgres support. This is exactly the same job as MediaWiki-phpunit, only the database backend change. The link is: https://integration.mediawiki.org/ci/job/MediaWiki-postgres-phpunit/ As of now, there are two tests failing. I ran the JS tests for the following configuration and got 8 failures. How should I report the problems (e.g., dump the html into a file and attach it to a bug report?) Configuration: OS: CentOS 5.7 MW revision: 108821 PHP: 5.3.3 PHPUnit: 3.6.7 DB: Postgres 8.3.9 -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r107776]: Revision status changed
Aaron Schulz changed the status of MediaWiki.r107776 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107776 Old status: new New status: resolved Commit summary for MediaWiki.r107776: * Display all errors in showForm() instead of only the first one * First do some checks and then delete the target page instead of the opposite so we don't delete a page for no purpose if a problem arises * Changed some empty() checks to count() * Use Title::quickUserCan() to see whether to show the checkbox to delete the page or not instead of User::isAllowed() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108274]: New comment added
Aaron Schulz posted a comment on MediaWiki.r108274. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108274#c29481 Commit summary for MediaWiki.r108274: * Added WikiPage to RequestContext and related so that it can be shared to avoid creating a new object each time and thus avoiding database queries to load the state of the object * Added Article::getPage() as accessor to the WikiPage object so that it can be set in the context from MediaWiki::initializeArticle() * Use it WikiPage::main() to call doViewUpdates() I'm doing to this now so that I can revert r105790 and use the WikiPage object before the 1.19 release Aaron Schulz's comment: pre$page = WikiPage::factory( $this-getTitle() );/pre It always created a page from the title. Now it has to worry about the wikipage being set. I'd recommend letting getWikiPage() return null and then having the doViewUpdates() code check if a wiki page is set before calling that function. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107792]: Revision status changed
Aaron Schulz changed the status of MediaWiki.r107792 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107792 Old status: new New status: ok Commit summary for MediaWiki.r107792: MFT r107359: fix Adobe Illustrator SVGs presumably broken by a PHP upgrade ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108827]: Revision status changed
GWicke changed the status of MediaWiki.r108827 to deferred URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108827 Old status: new New status: deferred Commit summary for MediaWiki.r108827: Template expansion now enabled and somewhat working, but template fetching still fails all the time. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108828]: Revision status changed
MaxSem changed the status of MediaWiki.r108828 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108828 Old status: new New status: ok Commit summary for MediaWiki.r108828: Remove punctuation from description message. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r102575]: Revision status changed
MarkAHershberger changed the status of MediaWiki.r102575 to new URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102575 Old status: fixme New status: new Commit summary for MediaWiki.r102575: Commit to fix bug 30513. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108822]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r108822 to fixme and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108822#c29482 Old Status: new New Status: fixme Commit summary for MediaWiki.r108822: Return message instead of key. Nikerabbit's comment: Was this supposed to fix API errors? This breaks non-API errors: http://translatewiki.net/sandwiki/i.php?title=Translations:Kfeaction=edit Possibly related bug 29261. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108789]: Revision status changed
Pgehres (WMF) changed the status of MediaWiki.r108789 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108789 Old status: new New status: ok Commit summary for MediaWiki.r108789: adding embargoed countries back ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108783]: Revision status changed
Khorn (WMF) changed the status of MediaWiki.r108783 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108783 Old status: new New status: ok Commit summary for MediaWiki.r108783: tweak enets forms to be closer to others ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108825]: New comment added
Nikerabbit posted a comment on MediaWiki.r108825. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108825#c29483 Commit summary for MediaWiki.r108825: in preparation of concurrencyCheck extension, add concurrency check call to feedback dashboard response items, added method to load tooltip for notification. Nikerabbit's comment: Try to keep consistent whitespace. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
