[MediaWiki-CodeReview] [pywikipedia r9783]: New comment added
"Xqt" posted a comment on pywikipedia.r9783. URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/9783#c27008 Commit summary for pywikipedia.r9783: Localisation updates from http://translatewiki.net. Xqt's comment: table2wiki.py should be re-imported from svn to enable PLURAL support ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [pywikipedia r9783]: Revision status changed
"Xqt" changed the status of pywikipedia.r9783 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/9783 Old status: new > New status: ok Commit summary for pywikipedia.r9783: Localisation updates from http://translatewiki.net. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94461]: New comment added
"MaxSem" posted a comment on MediaWiki.r94461. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94461#c27007 Commit summary for MediaWiki.r94461: Fix r94429 : Left and right side are still nearly the same color for 7% of the population. When I wrote to the list a while ago, no one argued for keeping the yellow scheme just because we're used to it. This makes it red/blue, also increases the highlight area ands adds a subtle border per Brandon Harris MaxSem's comment: Since the ILIKEIT arguing isn't going to ever end, I propose to use the only improved coloring scheme widely tested on live humans: [//fr.wikipedia.org/w/index.php?diff=48039253 the French version]. At least in one parameter it's definitely better than DieBuche's: it has lighter .diffchange background making it easier to read. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104375]: New comment added, and revision status changed
"Raymond" changed the status of MediaWiki.r104375 to "deferred" and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104375#c27006 Old Status: fixme > New Status: deferred Commit summary for MediaWiki.r104375: == SWB - 2011-11-27 == * Incoming links work now * beautifications * language * ... Raymond's comment: Thanks for the reminder. Done. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105188]: Revision status changed
"Santhosh.thottingal" changed the status of MediaWiki.r105188 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105188 Old status: new > New status: ok Commit summary for MediaWiki.r105188: Bug fix: wrong config name ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r103925]: New comment added
"Santhosh.thottingal" posted a comment on MediaWiki.r103925. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/103925#c27005 Commit summary for MediaWiki.r103925: Narayam: Remove cc-by-sa from my contributions. Santhosh.thottingal's comment: Is there any reason for this license change? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r102667]: New comment added
"Santhosh.thottingal" posted a comment on MediaWiki.r102667. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102667#c27004 Commit summary for MediaWiki.r102667: Narayam: Update Assamese transliteration rules. For bug 32120 Santhosh.thottingal's comment: 'lookbackLength': 8, Why we need 8? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104056]: Revision status changed
"Santhosh.thottingal" changed the status of MediaWiki.r104056 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104056 Old status: new > New status: ok Commit summary for MediaWiki.r104056: Narayam: Assamese transliteration update For bug 32120 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r103748]: New comment added
"Santhosh.thottingal" posted a comment on MediaWiki.r103748. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/103748#c27003 Commit summary for MediaWiki.r103748: Narayam: Lekhani, a new scheme for Odiya with help from Subashish. Santhosh.thottingal's comment: Odia is the correct spelling, not Odiya. See http://en.wikipedia.org/wiki/Odiya and http://en.wikipedia.org/wiki/Oriya_language Do we have documentation or specification for this scheme? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r103736]: Revision status changed
"Santhosh.thottingal" changed the status of MediaWiki.r103736 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/103736 Old status: new > New status: ok Commit summary for MediaWiki.r103736: Narayam: InScript keyboard implementation for Bodo. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r103750]: Revision status changed
"Santhosh.thottingal" changed the status of MediaWiki.r103750 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/103750 Old status: new > New status: ok Commit summary for MediaWiki.r103750: Narayam: Gujarati InScript implementation. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r103730]: Revision status changed
"Santhosh.thottingal" changed the status of MediaWiki.r103730 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/103730 Old status: new > New status: ok Commit summary for MediaWiki.r103730: Narayam: Marathi InScript implementation. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r103732]: Revision status changed
"Santhosh.thottingal" changed the status of MediaWiki.r103732 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/103732 Old status: new > New status: ok Commit summary for MediaWiki.r103732: Narayam: IE fear last comma. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105260]: Revision status changed
"Santhosh.thottingal" changed the status of MediaWiki.r105260 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105260 Old status: new > New status: ok Commit summary for MediaWiki.r105260: Internationalization tweaks and fixes, as per Roan ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105262]: Revision status changed
"Santhosh.thottingal" changed the status of MediaWiki.r105262 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105262 Old status: new > New status: ok Commit summary for MediaWiki.r105262: Fixed comment to match code in ArticleFeedbackv5.php; dropped debug lines in ArticleFeedbackv5.hooks.php ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104264]: New comment added, and revision status changed
"Santhosh.thottingal" changed the status of MediaWiki.r104264 to "resolved" and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104264#c27002 Old Status: fixme > New Status: resolved Commit summary for MediaWiki.r104264: Added gom-deva; sorted brx. Santhosh.thottingal's comment: r104963 corrected this ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104375]: New comment added
"Jeroen De Dauw" posted a comment on MediaWiki.r104375. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104375#c27001 Commit summary for MediaWiki.r104375: == SWB - 2011-11-27 == * Incoming links work now * beautifications * language * ... Jeroen De Dauw's comment: So the fixme should be removed now? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104373]: New comment added
"Jeroen De Dauw" posted a comment on MediaWiki.r104373. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104373#c27000 Commit summary for MediaWiki.r104373: == SWB - 2011-11-27 == * Incoming links work now * beautifications * language * ... Jeroen De Dauw's comment: It's not needed, but I've seen people do this before. It makes a lot of IDEs not go mad at using "undefined" variables :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97636]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r97636 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97636 Old status: new > New status: ok Commit summary for MediaWiki.r97636: Re-do several things of r96798 in preparation of re-doing the rest (there's a bug somewhere that needs fixing). * Do additional validation and is_array() check in LanguageConverter * Make redirects be in content language again (remove from Title->getPageLanguage()) * Pass title object from ParserCache to ParserOptions->optionsHash ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Html dump for Wikipedia
On 04/12/11 12:32, MZMcBride wrote: > This may be a stupid question as I don't understand the mechanics > particularly well, but... as far as I understand it, there's a Squid cache > layer that contains the HTML output of parsed and rendered wikitext pages. > This stored HTML is what most anonymous viewers receive when they access the > site. Why can't that be dumped into a output file rather than running > expensive and timely HTML dump generation scripts? > > In other words, it's not as though the HTML doesn't exist already. It's > served millions and millions of times each day. Why is it so painful to make > it available as a dump? Most of the code would be the same, it's just a bit more flexible to do the parsing in the extension, it makes it easier to change some details of the generated HTML, and lets you avoid polluting the caches with rarely-viewed pages. It's not especially painful either way. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Updated revision report for 1.19
Hi everyone, In trying to figure out where the bottlenecks are, it seemed it would be helpful to have a breakdown of the revisions. So, here's the first of many revision reports for 1.19: https://www.mediawiki.org/wiki/MediaWiki_roadmap/1.19/Revision_report This updated report now contains three sections: * New revisions by tag * New revisions by author * Fixmes There are several helpful things that jump out now: * Many, many untagged revisions. I think would be very helpful for those doing review to have revisions tagged by product area (e.g. "parser", "frontend", etc). We * The new revisions by author is a new view, and it's pretty helpful to see the big picture. For example, it looks like Aaron, Patrick, Roan, and Sam have a ton of stuff to review. It may be helpful for those people to pair up with (other) reviewers for some real-time reviews of their code. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r104982]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104982 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104982 Old status: new > New status: ok Commit summary for MediaWiki.r104982: removing code no longer needed ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104933]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104933 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104933 Old status: new > New status: ok Commit summary for MediaWiki.r104933: Splits the limbo queue into Credit Card, and Everything Else. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104648]: New comment added, and revision status changed
"Awjrichards" changed the status of MediaWiki.r104648 to "ok" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104648#c26999
Old Status: new
> New Status: ok
Commit summary for MediaWiki.r104648:
followup r104503, r104539, r104588
Limbo queue consumer IN the orphan rectifier: Initial commit for all the
command-line stuff. This has yet to be thoroughly tested and as such, should
not be used by anyone.
Awjrichards's comment:
+ $data = array(
+ 'wh' => 'yes'
+ );
+ $this->adapter = new
GlobalCollectOrphanAdapter(array('external_data' => $data));
Please comment around this whatever is going on here :p
+ function getStompOrphans(){
+ $time_buffer = 60*20; //20 minutes? Sure. Why not?
+ $selector = "payment_method = 'cc'";
+ $messages = stompFetchMessages( 'limbo', $selector, 300 );
It would be great if the batch size for stompFetchMessages was configurable, as
well as the $time_buffer.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104791]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104791 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104791 Old status: new > New status: ok Commit summary for MediaWiki.r104791: Another round of preparatory limbo stomp changes. - Allows for the whole limbo stomp process to get short-circuited if the limbo queue name is undefined, or false. - A couple bug fixes in which various overloaded versions of the do_transaction function weren't always returning... anything at all. - Moved the re-definition of early pending transactions to failed transactions, into a bit of code that will only fire if we are rectifying orphans. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97685]: Revision status changed
"Trevor Parscal" changed the status of MediaWiki.r97685 to "new" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97685 Old status: fixme > New status: new Commit summary for MediaWiki.r97685: Added initial html and css that UI will be built from. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105267]: Revision status changed
"Kaldari" changed the status of MediaWiki.r105267 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105267 Old status: new > New status: ok Commit summary for MediaWiki.r105267: [HarvardResearch] Swap ternary operator in registration fallback to zero * Follows-up :D r105239, r99005, r91244, r84932 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83791]: New comment added, and revision status changed
"Tim Starling" changed the status of MediaWiki.r83791 to "fixme" and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83791#c26998 Old Status: ok > New Status: fixme Commit summary for MediaWiki.r83791: (bug 2581, bug 6834) Added links to thumbnail in several resolutions to the file description page. The sizes are set by $wgImageLimits. Not really happy about how it looks, perhaps only the numbers should be linked? See http://www.mediawiki.org/wiki/User:Bryan/Bug_2581 for options. Removed message show-big-image-thumb, added show-big-image-preview, show-big-image-other, show-big-image-size. Tim Starling's comment: You said on bug 2581 that doing this for wikis without a 404 handler was an unacceptable performance burden and that you weren't going to enable this feature on such wikis. But the relevant code seems to be missing, and small default installations do indeed have a large performance burden from this feature. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Proposal for new table image_metadata
On Thu, Dec 1, 2011 at 6:34 PM, William Lee wrote: > We propose expanding the metadata field into a new table. We propose the > name image_metadata. It will have three columns: img_name, attribute > (varchar) and value (varchar). It can be joined with Image on img_name. > > Per convention this should probably read "file" instead of image, (like is already done with namespaces and the "filearchive" table). Anyway, that's just naming. A major problem as mentioned before in this thread is a key. Right now files (both the files as an abstract thing or the versions) have a no unique key. All they have is a page title and a timestamp. This is related to the License-integration project[1] (that name is a bit outdated, it started for license information, but it basically aiming at storing all kinds of file properties). The first blocker bug would be https://bugzilla.wikimedia.org/show_bug.cgi?id=26741 (image/oldimage to filerevision). And another one would be to make the file system even more like page/revisions. By giving implementing file ids and filerevision ids. - Krinkle [1] http://www.mediawiki.org/wiki/License_integration ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MathJax integration to stock MediaWiki Math extension? (was RFC: math options)
On Tue, Nov 29, 2011 at 12:44 AM, Roan Kattouw wrote: > On Tue, Nov 29, 2011 at 1:42 AM, Brion Vibber wrote: > > Most compatible thing is probably to let it include the images/text form > > as-is, then make sure MathJax goes over and replaces them in-place. It > > might need tweaks to understand the images (source in alt text). > > > You may want to do a quick check for MathJax support in a script in > the (which executes before the browser renders the page) which > then adds some CSS that ensures the images aren't loaded but the space > is still reserved (something like visibility: hidden; on the image). > I've started on integrating some of User:Nageh's customizations for the loader & configuration, which includes special support to find the latex source bits as we label them with 'tex' class and replace them in-place. It should be possible to tweak that a bit further so that the image forms can also get detected and transformed (since the source is on the alt text, we can use that). This last update also bundles the MathJax source (Apache license) with the extension, minus the 112 megabytes of PNG "font" fallbacks. We'll have to check whether we actually need to be able to use those images for some browsers or something... -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r103471]: Revision status changed
"Tim Starling" changed the status of MediaWiki.r103471 to "resolved" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/103471 Old status: new > New status: resolved Commit summary for MediaWiki.r103471: Apply cryptocoryne's patch from Bug 32454 - ArticlePurge hook is broken after r86041 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104588]: New comment added
"Khorn (WMF)" posted a comment on MediaWiki.r104588. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104588#c26997 Commit summary for MediaWiki.r104588: r104503, r104539 More changes for the limbo queue: Finding and acking the old message in real time takes _way_ too long, so we're not going to do that in realtime. Additional: Some stopwatch / commstats cleanup. Mostly only relevent for batch processes. Khorn (WMF)'s comment: I took 'em out in r105263. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105239]: New comment added
"Krinkle" posted a comment on MediaWiki.r105239. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105239#c26996 Commit summary for MediaWiki.r105239: [HarvardResearch][CentralNotice] Temporary wgNoticeBanner_Harvard2011 data. -- Banner display is handled through JavaScript because it's CentralNotice that is also for anonymous users and page output must be unaffected. -- Banner submission to Harvard/Science PO needs a hash of which the salt must not be in cleartext in the front-end code (also generating hashes in JS is ugly). So we need at least one temporary server component. -- Instead of requesting things from 2 or three different APIs on all pages + outputting a hash from PHP, might as well do it all in PHP and output an object in mw.config with all the needed data -- Cached in the session. Not sure whether it should be in memcached or session. Choose session for now since this is going to happen for all logged-in users on en.wiki, not sure wether it's good to have a gazillion memcached entries only used by 1 user only needed for about a week. -- Also notices that session is somewhat tied into memcached Krinkle's comment: Agreed. Taken from [http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UserDailyContribs/api/ApiUserDailyContribs.php?revision=104622&view=markup#l34 ApiUserDailyContribs.php] (originally like [//svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UserDailyContribs/api/ApiUserDailyContribs.php?revision=84932&view=markup#l21 this], [//svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UserDailyContribs/api/ApiUserDailyContribs.php?revision=91244&view=markup#l21 broken] and [//svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UserDailyContribs/api/ApiUserDailyContribs.php?revision=99005&view=markup#l22 fixed]). Fixed in r105267. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105263]: Revision status changed
"Krinkle" changed the status of MediaWiki.r105263 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105263 Old status: new > New status: ok Commit summary for MediaWiki.r105263: followup r104588 Some cleanup I missed at the end of the Limbo Stomp transaction. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105241]: Revision status changed
"Kaldari" changed the status of MediaWiki.r105241 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105241 Old status: new > New status: ok Commit summary for MediaWiki.r105241: [HarvardResearch][CentralNotice] Fix wgNoticeBanner_Harvard2011 * Since we're using memcached directly now instead of session, adapt to this (proper global and no-cache is false instead of null) * Follows-up r105239 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104588]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104588 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104588 Old status: new > New status: ok Commit summary for MediaWiki.r104588: r104503, r104539 More changes for the limbo queue: Finding and acking the old message in real time takes _way_ too long, so we're not going to do that in realtime. Additional: Some stopwatch / commstats cleanup. Mostly only relevent for batch processes. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104588]: New comment added
"Awjrichards" posted a comment on MediaWiki.r104588.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104588#c26995
Commit summary for MediaWiki.r104588:
r104503, r104539
More changes for the limbo queue: Finding and acking the old message in real
time takes _way_ too long, so we're not going to do that in realtime.
Additional: Some stopwatch / commstats cleanup. Mostly only relevent for batch
processes.
Awjrichards's comment:
+ if ($antimessage){
+ $antimessage = "Anti-message = true";
+ } else {
+ $antimessage = '';
+ }
These lines seem... extraneous, yet harmless.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105239]: New comment added
"Kaldari" posted a comment on MediaWiki.r105239. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105239#c26994 Commit summary for MediaWiki.r105239: [HarvardResearch][CentralNotice] Temporary wgNoticeBanner_Harvard2011 data. -- Banner display is handled through JavaScript because it's CentralNotice that is also for anonymous users and page output must be unaffected. -- Banner submission to Harvard/Science PO needs a hash of which the salt must not be in cleartext in the front-end code (also generating hashes in JS is ugly). So we need at least one temporary server component. -- Instead of requesting things from 2 or three different APIs on all pages + outputting a hash from PHP, might as well do it all in PHP and output an object in mw.config with all the needed data -- Cached in the session. Not sure whether it should be in memcached or session. Choose session for now since this is going to happen for all logged-in users on en.wiki, not sure wether it's good to have a gazillion memcached entries only used by 1 user only needed for about a week. -- Also notices that session is somewhat tied into memcached Kaldari's comment: $registrationDate = !$wgUser->getRegistration() ? 0 : $wgUser->getRegistration(); Wouldn't this be more readable as: $registrationDate = $wgUser->getRegistration() ? $wgUser->getRegistration() : 0; ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105239]: New comment added
"Kaldari" posted a comment on MediaWiki.r105239. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105239#c26993 Commit summary for MediaWiki.r105239: [HarvardResearch][CentralNotice] Temporary wgNoticeBanner_Harvard2011 data. -- Banner display is handled through JavaScript because it's CentralNotice that is also for anonymous users and page output must be unaffected. -- Banner submission to Harvard/Science PO needs a hash of which the salt must not be in cleartext in the front-end code (also generating hashes in JS is ugly). So we need at least one temporary server component. -- Instead of requesting things from 2 or three different APIs on all pages + outputting a hash from PHP, might as well do it all in PHP and output an object in mw.config with all the needed data -- Cached in the session. Not sure whether it should be in memcached or session. Choose session for now since this is going to happen for all logged-in users on en.wiki, not sure wether it's good to have a gazillion memcached entries only used by 1 user only needed for about a week. -- Also notices that session is somewhat tied into memcached Kaldari's comment: Looks good. My only suggestion is that you probably don't need to refetch the username since it's already available in wgUserName. Marking inspected. I'll let someone else sanity check for DB load before marking OK. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97636]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r97636 to "resolved" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97636 Old status: ok > New status: resolved Commit summary for MediaWiki.r97636: Re-do several things of r96798 in preparation of re-doing the rest (there's a bug somewhere that needs fixing). * Do additional validation and is_array() check in LanguageConverter * Make redirects be in content language again (remove from Title->getPageLanguage()) * Pass title object from ParserCache to ParserOptions->optionsHash ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97849]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r97849 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97849
Old status: new
> New status: ok
Commit summary for MediaWiki.r97849:
Re-do r96798 ("LanguageConverter now depends on the page content language"),
without the change in WikiPage which caused an infinite loop (see bug 31098)
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97849]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r97849 to "resolved"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97849
Old status: ok
> New status: resolved
Commit summary for MediaWiki.r97849:
Re-do r96798 ("LanguageConverter now depends on the page content language"),
without the change in WikiPage which caused an infinite loop (see bug 31098)
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104540]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104540 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104540 Old status: new > New status: ok Commit summary for MediaWiki.r104540: r104539 Cleaning up my lame array merging. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104539]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104539 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104539 Old status: new > New status: ok Commit summary for MediaWiki.r104539: More changes for the 'limbo' queue functionality. Now, they should delete themselves neatly from the queue on a not-abnormal end to the credit card process. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104503]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104503 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104503 Old status: new > New status: ok Commit summary for MediaWiki.r104503: Establishes a 'limbo' queue for data that GlobalCollect is either extremely likely, or completely guaranteed to bifurcate and/or otherwise mangle before handing it back to us (if they bother to do that bit at all). This by itself should not be allowed anywhere near production! So don't do it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82645]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r82645 to "resolved" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82645 Old status: new > New status: resolved Commit summary for MediaWiki.r82645: * Rewrote StripState to not use ReplacementArray. The memory usage of FSS was excessive when there were many (>10k) strip items. I used preg_replace_callback(), which is slower than strtr() in the simplest case, but much faster than it when the markers have different lengths, which they usually do. * It was not necessary to preserve the $stripState->general->setPair() interface since it wasn't used by any extensions. * Moved StripState to its own file. * Refactored serialiseHalfParsedText() and unserialiseHalfParsedText() so that the bulk of the functionality is in the relevant modules, instead of using scary direct access to object member variables. Made it support the new StripState. It seemed like a lot of work to go to to support an "emergency optimisation" feature in Cite. Cite updates will be in a subsequent commit. * Fixed spelling of serialiseHalfParsedText() and unserialiseHalfParsedText(), there is unavoidable interface breakage anyway, due to cache object versioning. * Moved transparent tags to their own function, as requested in a fixme comment. * Added documentation for markerSkipCallback(). * Removed OnlyIncludeReplacer, unused since MW 1.12. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104223]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104223 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104223 Old status: new > New status: ok Commit summary for MediaWiki.r104223: fixing rare divide by zero bug, fixing table formatting, commenting out console commands ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104999]: Revision status changed
"Kaldari" changed the status of MediaWiki.r104999 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104999 Old status: new > New status: ok Commit summary for MediaWiki.r104999: [CentralNotice] Add function comments. * This mess should eventually be upgraded to todays standards (no global functions but in a hooks class with static methods), but for now keeping that as is. Atleast make note of what is implementing what hook (since the function names don't help in that). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r932]: New comment added
"Pgehres (WMF)" posted a comment on Wikimedia.r932. URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/932#c26992 Commit summary for Wikimedia.r932: Adding quick script to import contacts into a group. Added a simple arg parser to scrips.common.inc Pgehres (WMF)'s comment: Ugh, I totally searched for just such a function. Google fail. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r932]: New comment added, and revision status changed
"Awjrichards" changed the status of Wikimedia.r932 to "ok" and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/932#c26991 Old Status: new > New Status: ok Commit summary for Wikimedia.r932: Adding quick script to import contacts into a group. Added a simple arg parser to scrips.common.inc Awjrichards's comment: In the future, considering using php's getopt() for handling command line args in a one-off script like this. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r103028]: Revision status changed
"Raindrift" changed the status of MediaWiki.r103028 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/103028 Old status: new > New status: ok Commit summary for MediaWiki.r103028: Renamed jquery plugin and css class prefixes Updated the css file accordingly Added info about CTAs to the jquery plugin file doc block Fixed a bug where the ratings labels and tooltips were missing (due to not being in the module messages list) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105249]: Revision status changed
"Krinkle" changed the status of MediaWiki.r105249 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105249 Old status: new > New status: ok Commit summary for MediaWiki.r105249: Language tweaks for mobile beta (simplify; reduce jargon) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100697]: Revision status changed
"Krinkle" changed the status of MediaWiki.r100697 to "resolved" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100697 Old status: fixme > New status: resolved Commit summary for MediaWiki.r100697: tweak CodeReview email notifications I have spent way too much time trying to quickly read the notification emails we receive from mw.org. Those new messages are a bit more readeable to me. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Math: getting baseline from texvc
I've made an initial stab at trying to get the baseline offset for rasterized math images; patch attached on: https://bugzilla.wikimedia.org/show_bug.cgi?id=32694 this is a feature from Blahtex that was much requested here for helping image renderings to match up with the surrounding text, and is done by getting the --depth option offset from dvipng (which itself needs the 'preview' latex package to be present to get reliable results). Unfortunately in my offhand tests this isn't giving good results; I'm getting 0 or 1px baseline depth offsets despite having descender letters (like "q") or using "tall" constructs like a square root or fraction. The result is images that are higher up than they ought to be, whereas in the default centering positioning they are often slightly lower than they ought to be. I'm not sure whether I'm doing something wrong, or whether the baseline depth that is retrieved is actually bogus to begin with. Need to compare in more detail against blahtex maybe... ... if we can't get this working, it's less of a big deal assuming MathJax can be set up to load fairly transparently, as that'll fix things up nice. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r100697]: New comment added
"Krinkle" posted a comment on MediaWiki.r100697. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100697#c26990 Commit summary for MediaWiki.r100697: tweak CodeReview email notifications I have spent way too much time trying to quickly read the notification emails we receive from mw.org. Those new messages are a bit more readeable to me. Krinkle's comment: Sounds like a work-around to me, is this necessary ? If we want nice visual emails we can use HTML. If just plain text, I'd prefer just keeping it plain. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100697]: New comment added
"Hashar" posted a comment on MediaWiki.r100697. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100697#c26989 Commit summary for MediaWiki.r100697: tweak CodeReview email notifications I have spent way too much time trying to quickly read the notification emails we receive from mw.org. Those new messages are a bit more readeable to me. Hashar's comment: This was intentional. The idea is that lot of clients use a different colors for quoted lines use a different color. Thus it highlight the change. Gmail collapsing defeat the purpose. I am wondering if quote collapsing can be disabled under a given threshold. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105241]: New comment added
"Krinkle" posted a comment on MediaWiki.r105241. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105241#c26988 Commit summary for MediaWiki.r105241: [HarvardResearch][CentralNotice] Fix wgNoticeBanner_Harvard2011 * Since we're using memcached directly now instead of session, adapt to this (proper global and no-cache is false instead of null) * Follows-up r105239 Krinkle's comment: '''Requires r104622, r104622''' ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105239]: New comment added
"Krinkle" posted a comment on MediaWiki.r105239. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105239#c26987 Commit summary for MediaWiki.r105239: [HarvardResearch][CentralNotice] Temporary wgNoticeBanner_Harvard2011 data. -- Banner display is handled through JavaScript because it's CentralNotice that is also for anonymous users and page output must be unaffected. -- Banner submission to Harvard/Science PO needs a hash of which the salt must not be in cleartext in the front-end code (also generating hashes in JS is ugly). So we need at least one temporary server component. -- Instead of requesting things from 2 or three different APIs on all pages + outputting a hash from PHP, might as well do it all in PHP and output an object in mw.config with all the needed data -- Cached in the session. Not sure whether it should be in memcached or session. Choose session for now since this is going to happen for all logged-in users on en.wiki, not sure wether it's good to have a gazillion memcached entries only used by 1 user only needed for about a week. -- Also notices that session is somewhat tied into memcached Krinkle's comment: '''Requires r104622''' ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104886]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104886 to "resolved" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104886 Old status: new > New status: resolved Commit summary for MediaWiki.r104886: dont need this since Special pages arent server-cached anyway ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105237]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r105237 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105237 Old status: new > New status: ok Commit summary for MediaWiki.r105237: follow-up to r104886, dont need headers since were redirecting anyway ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104984]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104984 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104984 Old status: new > New status: ok Commit summary for MediaWiki.r104984: follow-up to r104829 - better way to build URL ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104886]: New comment added, and revision status changed
"Kaldari" changed the status of MediaWiki.r104886 to "new" and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104886#c26986 Old Status: fixme > New Status: new Commit summary for MediaWiki.r104886: dont need this since Special pages arent server-cached anyway Kaldari's comment: Ah, good point. Removed in r105237. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104942]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104942 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104942 Old status: new > New status: ok Commit summary for MediaWiki.r104942: new defaults and better template construction ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94461]: New comment added
"Krinkle" posted a comment on MediaWiki.r94461. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94461#c26985 Commit summary for MediaWiki.r94461: Fix r94429 : Left and right side are still nearly the same color for 7% of the population. When I wrote to the list a while ago, no one argued for keeping the yellow scheme just because we're used to it. This makes it red/blue, also increases the highlight area ands adds a subtle border per Brandon Harris Krinkle's comment: See reply below with the 3 list items. I did this on prototype for now, showing each in a live diff demo. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104988]: Revision status changed
"Raindrift" changed the status of MediaWiki.r104988 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104988 Old status: new > New status: ok Commit summary for MediaWiki.r104988: Updated Option 3 and tooltip text, and added documentation lines for new messages (fix for r103348, r104602, r104629, and r104715) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104886]: New comment added, and revision status changed
"Awjrichards" changed the status of MediaWiki.r104886 to "fixme" and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104886#c26984 Old Status: new > New Status: fixme Commit summary for MediaWiki.r104886: dont need this since Special pages arent server-cached anyway Awjrichards's comment: I don't think you need $this->setHeaders(); either. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104829]: Revision status changed
"Awjrichards" changed the status of MediaWiki.r104829 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104829 Old status: new > New status: ok Commit summary for MediaWiki.r104829: adding a redirector and fixing old code to use globals ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100697]: Revision status changed
"Krinkle" changed the status of MediaWiki.r100697 to "fixme" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100697 Old status: new > New status: fixme Commit summary for MediaWiki.r100697: tweak CodeReview email notifications I have spent way too much time trying to quickly read the notification emails we receive from mw.org. Those new messages are a bit more readeable to me. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100697]: New comment added
"Krinkle" posted a comment on MediaWiki.r100697. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100697#c26983 Commit summary for MediaWiki.r100697: tweak CodeReview email notifications I have spent way too much time trying to quickly read the notification emails we receive from mw.org. Those new messages are a bit more readeable to me. Krinkle's comment: -Old Status: $3 -New Status: $4 +Old status: $3 +> New status: $4 This > character is causing e-mail clients to render this as a "quote". Sometimes (GMail) it's actually collapsed, requiring me to expand the (supposedly) repeated section in order to read it. If this was not intentional, please undo it. Example: http://i.imgur.com/luQCU.png ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105114]: Revision status changed
"^demon" changed the status of MediaWiki.r105114 to "resolved" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105114 Old status: new > New status: resolved Commit summary for MediaWiki.r105114: Remove tocindent and tocinline from print stylesheet. These seem to have been unused since r7073 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105115]: Revision status changed
"^demon" changed the status of MediaWiki.r105115 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105115 Old status: new > New status: ok Commit summary for MediaWiki.r105115: Follow up to r105114 one more tocindent ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105116]: Revision status changed
"^demon" changed the status of MediaWiki.r105116 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105116 Old status: new > New status: ok Commit summary for MediaWiki.r105116: Remove totally pointless and somewhat annoying !important from commonPrint. This fixes bug 32795 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105224]: Revision status changed
"^demon" changed the status of MediaWiki.r105224 to "deferred" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105224 Old status: new > New status: deferred Commit summary for MediaWiki.r105224: Localisation updates for core and extension messages from translatewiki.net ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94238]: New comment added
"Krinkle" posted a comment on MediaWiki.r94238. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94238#c26982 Commit summary for MediaWiki.r94238: Oh, right. IE6/7 doesn't support that. ( Thanks TestSwarm, http://toolserver.org/~krinkle/testswarm/job/289/ ) Changing to a normal raises(). (Follows-up r94237) Krinkle's comment: I don't know exactly why or how, but this is the abstracted case: http://jsfiddle.net/teE24/3/ QUnit internally checks if the argument passed for expected is a regex, if it is it does expected.test( e );. This works fine in modern browsers, but in IE7 it returns false. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101656]: New comment added
"Bawolff" posted a comment on MediaWiki.r101656. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101656#c26981 Commit summary for MediaWiki.r101656: Alias NS_MEDIA page views to NS_FILE. Fixes bug 32032. Bawolff's comment: tagging 1.18wmf1 based on [[bugzilla:32785]] (fixes throwing an uncaught exception on urls like http://mediawiki.org/wiki/media:foo?action=edit ) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Proposal for new table image_metadata
On 12/05/2011 08:07 PM, Brion Vibber wrote: > If extracted page text is stored in a better key-value store, we should > make sure it doesn't get pulled in to backwards-compatible metadata blobs > (if we keep em around as they are now) -- but they should be accessible > through some API. One thing to consider is what happens if a user edits metadata, e.g. adds EXIF data that was lost by cropping, or if a new (cropped) version of the image is uploaded with the same name. Another thing is image annotations, that are today always added as plain text in the image description page, http://commons.wikimedia.org/wiki/Commons:Image_annotations A third thing is timed text (video subtitles), which today is added in separate subpages, one for each language, http://commons.wikimedia.org/wiki/Commons:Timed_Text A fourth thing is proofreading: If OCR text was extracted from a PDF or DJvu and then proofread in Wikisource, shouldn't the next person that downloads the PDF file get the new text? Perhaps a system for managing image + text, including wiki editing, could address all four things above? In particular, image annotations and OCR text are both tied to coordinates in the image. (And timed text is tied to a time position in a video stream.) So why are they separate systems? -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r98430]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r98430 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98430 Old status: new > New status: ok Commit summary for MediaWiki.r98430: (bug 30202) Restrict file names on upload to 240 bytes, because wfTimestamp( TS_MW ) . '!' . $fileName should fit in oi_archive_name, which is 255 bytes, and also the maximum file name length on many file systems is 255 bytes. Commit to fix UploadTest to use @dataProvider will follow ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99148]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r99148 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99148 Old status: new > New status: ok Commit summary for MediaWiki.r99148: Solve the FIXME set in r99025. Use $this->mTitle directly at EditPage instead of $this->getContextTitle() $this->mTitle must be set, as it what was used to set $this->isWrongCaseCssJsPage ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r93291]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r93291 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93291 Old status: new > New status: ok Commit summary for MediaWiki.r93291: Unicode space separator characters (Zs) now terminates links Fix 19052 which was only reporting the issue for U+3000 IDEOGRAPHIC SPACE. Covers both external links and images links. See parser tests for examples. Unicode 'Zs' includes all characters from the 'separator, space' category. Characters part of this category are: CharName U+0020 SPACE U+00A0 NO-BREAK SPACE U+1680 OGHAM SPACE MARK U+180E MONGOLIAN VOWEL SEPARATOR U+2000 EN QUAD U+2001 EM QUAD U+2002 EN SPACE U+2003 EM SPACE U+2004 THREE-PER-EM SPACE U+2005 FOUR-PER-EM SPACE U+2006 SIX-PER-EM SPACE U+2007 FIGURE SPACE U+2008 PUNCTUATION SPACE U+2009 THIN SPACE U+200A HAIR SPACE U+202F NARROW NO-BREAK SPACE U+205F MEDIUM MATHEMATICAL SPACE U+3000 IDEOGRAPHIC SPACE TEST PLAN: $ php parserTests.php --quiet This is MediaWiki version 1.19alpha (r93258). Reading tests from "tests/parser/parserTests.txt"... Reading tests from "tests/parser/extraParserTests.txt"... Reading tests from "../mwexts/LabeledSectionTransclusion/lstParserTests.txt"... Passed 686 of 686 tests (100%)... ALL TESTS PASSED! Sounds good :-) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94373]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r94373 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94373 Old status: new > New status: ok Commit summary for MediaWiki.r94373: Improve the ability for extensions to participate in how MediaWiki handles url paths: - Allow extensions to hook into WebRequest::getPathInfo and add to or alter the way titles are extracted from paths - Add a $variant argument to the GetLocalURL hook; It's always had $query, but never had $variant. As a result extensions using GetLocalURL never new if getLocalURL and have the possibility of trying to change the url in cases where they shouldn't and as a result breaking links on wiki with language variants. - Add GetLocalURL::Internal hook for non-interwiki links. These kinds of links internally use a ugly hack for action=render and an extension using GetLocalURL can be buggy in render mode if they don't re-implement the same ugly hack that MW does. This ::Internal hook runs before the hack does so extension authors don't need to be exposed to our ugly hacky code. - Add GetLocalURL::Article hook specifically for url tweaks to pretty urls (ie: Only when we would apply $wgArticlePath); This hook avoids the need for extensions that only want to tweak pretty url output. This hook avoids the need to make a bunch of tests for things like !$title->isExternal(), $query == '', and $variant === false which getLocalURL does and could potentially change in the future making wider GetLocalURL hooks change in function requiring extension updates. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94066]: Revision status changed
"Aaron Schulz" changed the status of MediaWiki.r94066 to "resolved" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94066 Old status: new > New status: resolved Commit summary for MediaWiki.r94066: Adding support for a callback to jquery.byteLimit * Fixes (bug 29455) Add support for a filter callback function in jQuery byteLimit plugin. * Adding unit tests for it * Changing if-statements in mw.Title's helper functions for regular expression matches. It should check wether the value is not null or undefined. Before it was just a plain if-statement which meant that an empty string would also return false, which made the new byteLimit's tests fail (mw.Title.getMain() expects _name to be a valid string when it does ucFirst() and substr() etc.) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105181]: New comment added
"Amire80" posted a comment on MediaWiki.r105181. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105181#c26980 Commit summary for MediaWiki.r105181: Add webfont extension support for monobook skin. Amire80's comment: Some thought about the placement is needed. Currently it says $div.insertAfter( '#p-search');. There are several issues with it: * Some projects customize the sidebar appearance. * Other extensions may fight for this location, the most immediate example being Narayam. * The links after the search may be more important than WebFonts. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r104989]: New comment added, and revision status changed
"Kaldari" changed the status of MediaWiki.r104989 to "ok" and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/104989#c26979 Old Status: new > New Status: ok Commit summary for MediaWiki.r104989: Fixing inclusion of default template for RapidHtml blocks. Adding base cc template for world. Kaldari's comment: Looks good, although those US and CA templates need some layout love. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105223]: Revision status changed
"Pgehres (WMF)" changed the status of MediaWiki.r105223 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105223 Old status: new > New status: ok Commit summary for MediaWiki.r105223: follow-up to r104989 - easier to read regex ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105147]: Revision status changed
"Pgehres (WMF)" changed the status of MediaWiki.r105147 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105147 Old status: new > New status: ok Commit summary for MediaWiki.r105147: commenting out FORBIDDEN countries ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105145]: Revision status changed
"Catrope" changed the status of MediaWiki.r105145 to "resolved" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105145 Old status: new > New status: resolved Commit summary for MediaWiki.r105145: rewriting FundraisingStatistics to use 1 query instead of 6, and heavily cache results from previous years ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105214]: Revision status changed
"Catrope" changed the status of MediaWiki.r105214 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105214 Old status: new > New status: ok Commit summary for MediaWiki.r105214: uncommenting cacheing ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105145]: Revision status changed
"Kaldari" changed the status of MediaWiki.r105145 to "new" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105145 Old status: ok > New status: new Commit summary for MediaWiki.r105145: rewriting FundraisingStatistics to use 1 query instead of 6, and heavily cache results from previous years ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105145]: Revision status changed
"Catrope" changed the status of MediaWiki.r105145 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105145 Old status: new > New status: ok Commit summary for MediaWiki.r105145: rewriting FundraisingStatistics to use 1 query instead of 6, and heavily cache results from previous years ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] ajax help needed
On Mon, Dec 5, 2011 at 11:49 AM, Petr Bena wrote: > Thank you Brion, > > I already implemented api function, it's described in bz ticket, I > forgot to note that, but actually I was looking for someone with > experiences :) who could join me and help finish that extension, it's > no problem for me to insert some div which could be used by script to > insert status there, unfortunately I don't know how to create that > script because I never worked with JS, if no one was interested I will > try to do it myself but that could take months to me to understand how > to implement it, since there is consensus on english wp to have this > and some folks are now already asking me when it would be installed, I > don't like idea that I would work on that several months, while others > who know this could make it in few hours. Everything else should be > completed, all I need is to create a script which would download > status from api and render it properly on page. > If you're going to be online tomorrow (Tuesday), I'll be around most of the time from ~ 10am to 6pm Pacific (18:00 - 01:00 UTC) in #mediawiki on irc.freenode.net, I'll be happy to help you out & give you some code snippets! -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ajax help needed
Thank you Brion, I already implemented api function, it's described in bz ticket, I forgot to note that, but actually I was looking for someone with experiences :) who could join me and help finish that extension, it's no problem for me to insert some div which could be used by script to insert status there, unfortunately I don't know how to create that script because I never worked with JS, if no one was interested I will try to do it myself but that could take months to me to understand how to implement it, since there is consensus on english wp to have this and some folks are now already asking me when it would be installed, I don't like idea that I would work on that several months, while others who know this could make it in few hours. Everything else should be completed, all I need is to create a script which would download status from api and render it properly on page. On Mon, Dec 5, 2011 at 7:38 PM, Brion Vibber wrote: > On Mon, Dec 5, 2011 at 8:29 AM, Petr Bena wrote: > >> Hi, >> >> I have already noted that I work on extension which allows displaying >> of user online status, see >> https://bugzilla.wikimedia.org/show_bug.cgi?id=32128, Krinkle come >> with idea that it could use ajax on user pages for status bar in order >> to avoid cache issues while keep performance of interface (if cache >> would need to be suppressed it would have probably negative effect on >> performance althought it would happen rarely). I like that idea, >> however I have no experience with ajax. If anyone who understand ajax >> wanted to help it would be most appreciated! >> > > You'll want to do a little work in three distinct places: > > 1) Add an API module to return the online state information, or extend > ApiQueryUsers to return that info > (action=query&list=users&ususers=Username&usprop=online ?) > > To write or extend an API module, see docs: > https://www.mediawiki.org/wiki/API%3AExtensions > > > 2) Output scaffolding HTML from your existing hook. > > Don't do the full lookup and output, but you'll at least need an > identifiable spot on the page where you can stick your data once you've > loaded it. Make sure that it degrades gracefully if JavaScript is > unavailable or disabled! (Don't be afraid to use .) > > > 3) Add JavaScript to do the lookup and update the visible state. > > For current versions of MediaWiki, the best way to organize client-side JS > and CSS scripts is through ResourceLoader modules. See docs: > > https://www.mediawiki.org/wiki/ResourceLoader > > > The actual API hit can be done using jQuery's $.ajax() function, which is > much easier than manually dealing with an XMLHTTPRequest object: > > http://api.jquery.com/jQuery.ajax/ > > > Feel free to look at other extensions for how they do things (but beware, > not all extensions have been modernized to use jQuery and ResourceLoader > fully!) > > And don't be shy about asking questions in the #mediawiki channel on > irc.freenode.net -- we try not to bite! > > -- brion vibber (brion @ wikimedia.org / brion @ pobox.com) > > > >> Thanks >> >> ___ >> 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 r105206]: Revision status changed
"Nikerabbit" changed the status of MediaWiki.r105206 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105206 Old status: new > New status: ok Commit summary for MediaWiki.r105206: fix use of __toString to check if is Userlogin ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r102105]: New comment added
"Amire80" posted a comment on MediaWiki.r102105. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102105#c26978 Commit summary for MediaWiki.r102105: Adding dir="ltr" to the label, to prevent wrong appearance of the arithmetic expression. Amire80's comment: This was actually discussed in the Standards Institute of Israel (SII) once, in my presence, and the decision was that it is always left-to-right - but that only applied to Hebrew. The Arabic textbooks i saw had left-to-right math expressions, but i obviously didn't see them all. I emailed the relevant SII discussion list and asked whether anybody knows any details about Arabic. AFAIK if we remove the space, it will display the expression left-to-right even if dir="rtl" will be applied to it, because of the '-' character properties. I don't think that any locales override that, but i might be wrong. So the display will be left-to-right anyway, but the readability may be reduced - "10-8" vs. "10 - 8". ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] QueryPage class help?
On Mon, Dec 5, 2011 at 8:29 PM, Daniel Barrett wrote: >>you should be able to create a QueryPage subclass in >>an extension, set $wgSpecialPages['specialpagename'] = >>'SpecialPageClass'; , add to $wgQueryPages (I forget the exact format >>there), and you should be all set. > > Thanks. I tried that, and when I added the $wgSpecialPages line, I got an > error that MyQueryPage::isListed() was undefined. (This is a SpecialPage > method.) > > Subclassing QueryPage doesn't seem to be enough, since QueryPage is not a > subclass of SpecialPage. This is where I got confused about how QueryPage > and SpecialPage somehow get related. > That's why you should use 1.18.0, where all of this was fixed and QueryPage does actually subclass SpecialPage :) Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] QueryPage class help?
>you should be able to create a QueryPage subclass in >an extension, set $wgSpecialPages['specialpagename'] = >'SpecialPageClass'; , add to $wgQueryPages (I forget the exact format >there), and you should be all set. Thanks. I tried that, and when I added the $wgSpecialPages line, I got an error that MyQueryPage::isListed() was undefined. (This is a SpecialPage method.) Subclassing QueryPage doesn't seem to be enough, since QueryPage is not a subclass of SpecialPage. This is where I got confused about how QueryPage and SpecialPage somehow get related. DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r105180]: Revision status changed
"Nikerabbit" changed the status of MediaWiki.r105180 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105180 Old status: new > New status: ok Commit summary for MediaWiki.r105180: fix typo ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105179]: Revision status changed
"Nikerabbit" changed the status of MediaWiki.r105179 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105179 Old status: new > New status: ok Commit summary for MediaWiki.r105179: r103982: fix typo ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105170]: Revision status changed
"Nikerabbit" changed the status of MediaWiki.r105170 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105170 Old status: deferred > New status: ok Commit summary for MediaWiki.r105170: FU r105167: Fixing parse error, define array ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105167]: Revision status changed
"Nikerabbit" changed the status of MediaWiki.r105167 to "resolved" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105167 Old status: ok > New status: resolved Commit summary for MediaWiki.r105167: r104375: Consistency tweaks in preparation for adding extension to translatewiki.net: * Move message documentation to the 'qqq' section * Fix encoding per Nikerabbit's CR * Fix a typo per Nikerabbit's CR * Extension credits: ** Put authors into an array ** Fix description message key and move the description to the i18n file * Remove a trailing ?> * Some spaces2tabs ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105169]: Revision status changed
"Nikerabbit" changed the status of MediaWiki.r105169 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105169 Old status: deferred > New status: ok Commit summary for MediaWiki.r105169: FU r105167: Fix language code of message documenation en->qqq ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
