[MediaWiki-CodeReview] [MediaWiki r113261]: Revision status changed

[MediaWiki Mail]

"Robmoen" changed the status of MediaWiki.r113261 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113261

Old status:  new
New status: ok

Commit summary for MediaWiki.r113261:

Weve decided that the list view will be the primary view for the extension - we 
will develope the zoom view later. Moving the list view to be 
Special:PageTriage and getting rid of Special:PageTriageList

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114269]: Revision status changed

[MediaWiki Mail]

"Preilly" changed the status of MediaWiki.r114269 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114269

Old status:  new
New status: ok

Commit summary for MediaWiki.r114269:

Move declaration of referrer up a line to fix undefined variable

Remove unused global, documentation for title object

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113514]: Revision status changed

[MediaWiki Mail]

"MaxSem" changed the status of MediaWiki.r113514 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113514

Old status:  new
New status: ok

Commit summary for MediaWiki.r113514:

remove description from page output

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113732]: Revision status changed

[MediaWiki Mail]

"MaxSem" changed the status of MediaWiki.r113732 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113732

Old status:  new
New status: ok

Commit summary for MediaWiki.r113732:

add configuration option for disable images

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113741]: Revision status changed

[MediaWiki Mail]

"MaxSem" changed the status of MediaWiki.r113741 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113741

Old status:  new
New status: ok

Commit summary for MediaWiki.r113741:

add carrier custom banner text

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] enwiki revision schema migration in progress

[Asher Feldman]

On Tuesday, March 20, 2012, Roan Kattouw  wrote:
> So yeah /normally/
> you hit DB servers at random and different servers might respond
> differently (or be lagged to different degrees), but in this
> particular case it was always the same DB server returning the same
> lag value. Nothing strange going on here, this is how the maxlag
> parameter works.

How do you feel about a switch to change that behavior (maxlag - 1)? It
would be nice to be continue guiding developers towards throttling API
requests around maxlag without complicating schema migrations by requiring
config deployments before and after every db for this reason only.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r114290]: Revision status changed

[MediaWiki Mail]

"Preilly" changed the status of MediaWiki.r114290 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114290

Old status:  new
New status: ok

Commit summary for MediaWiki.r114290:

update minified js

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114289]: Revision status changed

[MediaWiki Mail]

"Preilly" changed the status of MediaWiki.r114289 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114289

Old status:  new
New status: ok

Commit summary for MediaWiki.r114289:

provide feedback when a search is in progress

currently there is no hint that anything is happening
when you type

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113916]: New comment added, and revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r113916 to "resolved" and commented 
it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113916#c32389

Old Status: fixme
New Status: resolved

Commit summary for MediaWiki.r113916:

AFTv5: sync commit, readded i18n msgs etc.

Catrope's comment:


+ 'articlefeedbackv5-link-close-text1' => 'To remove this widget, go to',
+ 'articlefeedbackv5-link-close-linktext' => '"My Preferences > Appearances"',
+ 'articlefeedbackv5-link-close-linkurl' => '#',
+ 'articlefeedbackv5-link-close-text2' => 'then check this box:',
+ 'articlefeedbackv5-link-cllse-text3' => '"Don\'t show the Article Feedback 
widget."',

Per Siebrand in r113979, this is a lego message which should be cleaned up. 
Create one message with 'To remove this widget, go to $1, then check this box.' 
, and then build the link from the other message and insert it as $1. 
Marking fixme for this oh it's been removed already, marking resolved.


+tipsy {

This was removed later, but for the record, it doesn't work, you probably 
missed a dot here.


+.tipsy-inner {

This was removed later, but for the record: this and other rules concerning 
tipsy should be namespaced so they only affect tipsy tooltips created by 
ArticleFeedbackv5, not any other tooltips that might exist on the page.


+ ' + 
mw.msg( 'articlefeedbackv5-link-close-linktext' ) + '\

This code was removed later, but for the record, this is not a secure way of 
building HTML.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] enwiki revision schema migration in progress

[Roan Kattouw]

On Tue, Mar 20, 2012 at 11:35 AM, Asher Feldman  wrote:
> How do you feel about a switch to change that behavior (maxlag - 1)? It
> would be nice to be continue guiding developers towards throttling API
> requests around maxlag without complicating schema migrations by requiring
> config deployments before and after every db for this reason only.
That sounds reasonable to me, what alternative behavior do you
propose? A flag that, when enabled, causes maxlag to use the 2nd
highest lag instead of the highest lag?

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r113917]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r113917 to "deferred"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113917

Old status:  new
New status: deferred

Commit summary for MediaWiki.r113917:

AFTv5: added first batch of selenium tests for the feedback page

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113951]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r113951 to "deferred"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113951

Old status:  new
New status: deferred

Commit summary for MediaWiki.r113951:

AFTv5: fixed feedback page test prerequisite step

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] enwiki revision schema migration in progress

[Daniel Friesen]

On Tue, 20 Mar 2012 11:35:02 -0700, Asher Feldman   
wrote:



On Tuesday, March 20, 2012, Roan Kattouw  wrote:

So yeah /normally/
you hit DB servers at random and different servers might respond
differently (or be lagged to different degrees), but in this
particular case it was always the same DB server returning the same
lag value. Nothing strange going on here, this is how the maxlag
parameter works.


How do you feel about a switch to change that behavior (maxlag - 1)? It
would be nice to be continue guiding developers towards throttling API
requests around maxlag without complicating schema migrations by  
requiring

config deployments before and after every db for this reason only.


Why don't we have a system to allow databases to be automatically taken  
out of the LB temporarily?


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r113970]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r113970 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113970

Old status:  new
New status: ok

Commit summary for MediaWiki.r113970:

Drop jquery.elastic and allow regular browser scrolling/resizing:
- modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.css:
- Allow the textarea to scroll and, if the browser permits it, 
resize
  manually
- modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.js:
- Dropped jquery.elastic
- Allow the overlay to be resized as well, in case someone has 
a truly
  enormous comment
- modules/jquery.elastic:
- Deleted
- ArticleFeedbackv5.hooks.php:
- Dropped jquery.elastic

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] enwiki revision schema migration in progress

[Jeremy Baron]

On Tue, Mar 20, 2012 at 14:35, Asher Feldman  wrote:
> On Tuesday, March 20, 2012, Roan Kattouw  wrote:
>> So yeah /normally/
>> you hit DB servers at random and different servers might respond
>> differently (or be lagged to different degrees), but in this
>> particular case it was always the same DB server returning the same
>> lag value. Nothing strange going on here, this is how the maxlag
>> parameter works.
>
> How do you feel about a switch to change that behavior (maxlag - 1)? It
> would be nice to be continue guiding developers towards throttling API
> requests around maxlag without complicating schema migrations by requiring
> config deployments before and after every db for this reason only.

How about just having a new file in the config that lists the servers
currently migrating and the migration script can update and deploy as
it goes. Then apaches can check if a high maxlag is on the lag's
expected list and ignore if it is. Should be fairly safe as long as
it's a file that no human will edit and the deploy only pushes the one
file. But, I don't actually know if it's possible (with current
scripts) to push just one file for the config.

-Jeremy

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r113978]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r113978 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113978

Old status:  new
New status: ok

Commit summary for MediaWiki.r113978:

Changed bucketing for AFT links from 100% E to 1/3 each A, E, and nothing; also 
bumped up the version number (see bug 34406)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113743]: New comment added, and revision status changed

[MediaWiki Mail]

"MaxSem" changed the status of MediaWiki.r113743 to "ok" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113743#c32390

Old Status: new
New Status: ok

Commit summary for MediaWiki.r113743:

add custom banner text and main page redirection to landing page for zero

MaxSem's comment:

TODO: exit after redirecting.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114296]: Revision status changed

[MediaWiki Mail]

"Preilly" changed the status of MediaWiki.r114296 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114296

Old status:  new
New status: ok

Commit summary for MediaWiki.r114296:

fix viewport issues in operamini

certain css rules are not applying and others
dont need to be applied

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113766]: Revision status changed

[MediaWiki Mail]

"MaxSem" changed the status of MediaWiki.r113766 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113766

Old status:  new
New status: ok

Commit summary for MediaWiki.r113766:

add carrier banner text to qqq

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114133]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114133 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114133

Old status:  new
New status: ok

Commit summary for MediaWiki.r114133:

Return correct mask information line so red lines with username/timestamp work 
again

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114135]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114135 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114135

Old status:  new
New status: ok

Commit summary for MediaWiki.r114135:

bug 35035 - hide/show decline oversight link on oversight/unoversight and make 
sure the hide link toggles on oversight

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114165]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114165 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114165

Old status:  new
New status: ok

Commit summary for MediaWiki.r114165:

Name the no-link option X rather than -, and keep track of the link ID 
optionally added to the page (floatingLinkId)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114187]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114187 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114187

Old status:  new
New status: ok

Commit summary for MediaWiki.r114187:

Bug fix: non-url click tracking events were not getting the rev id

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] Setting $wgCategoryCollation to 'uca-default' on WMF wikis

[Helder]

After some talk on IRC with Reedy and Mark, I'm bringing this to the list.

I'm interested in getting $wgCategoryCollation set to 'uca-default' on
Portuguese wikis,
and after searching on Bugzilla I found this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=30996#c5
(Set $wgCategoryCollation to 'uca-default' and rebuild category sort
keys on Wikimedia wikis deployment)
where Tim comments:

The first letter identification code
(maintenance/language/generateCollationData.php) won't work for all languages,
so some wikis will have their category pages broken terribly by this change.
Also, the default collation tables sort a lot of languages incorrectly, and the
amount of breakage that causes will depend on the language in question. So I
recommend doing this change on a language-by-language basis, after checking
each language for correct collation and first-letter behaviour on a test wiki.
(...)
-
So, how could we check whether "Portuguese" wikis would break by doing
this change?
Could we schedule the necessary tests, in order to fix the category
ordering on WMF wikis?

Currently, we still need to use
{{DEFAULTSORT: Page Name without accents }}
on any article whose title has an accent if we want it to be sorted
appropriately in the categories. E.g.:
https://fr.wikipedia.org/w/index.php?title=%C3%89bedj%C3%A9sus&action=edit
https://pt.wikipedia.org/w/index.php?title=%C3%81gua_Boa&oldid=28441112&action=edit
http://es.wikipedia.org/w/index.php?title=%C3%8Dpsilon_Hydrae&action=edit

Best regards,
Helder

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r114189]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114189 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114189

Old status:  new
New status: ok

Commit summary for MediaWiki.r114189:

Updated clicktracking events to Phase 2 names

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114194]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114194 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114194

Old status:  new
New status: ok

Commit summary for MediaWiki.r114194:

bug 35254 - oversight items (request and unrequest oversight, decline 
oversight, oversight and unoversight) now go directly to the suppressionlog 
instead of into the afv5 activity log

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114271]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114271 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114271

Old status:  new
New status: ok

Commit summary for MediaWiki.r114271:

Added a pipe separator, as requested in bug #34406

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114271]: New comment added, and revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114271 to "fixme" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114271#c32391

Old Status: ok
New Status: fixme

Commit summary for MediaWiki.r114271:

Added a pipe separator, as requested in bug #34406

Catrope's comment:

This should use the 'pipe-separator' message instead of hardcoding the pipe 
character.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113783]: New comment added, and revision status changed

[MediaWiki Mail]

"MaxSem" changed the status of MediaWiki.r113783 to "ok" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113783#c32392

Old Status: new
New Status: ok

Commit summary for MediaWiki.r113783:

change zero landing page

MaxSem's comment:

Note: implicit Message to string is a PHP 5.3-only feature.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114291]: Revision status changed

[MediaWiki Mail]

"MaxSem" changed the status of MediaWiki.r114291 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114291

Old status:  new
New status: ok

Commit summary for MediaWiki.r114291:

zero rated links for language homepage links

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114293]: Revision status changed

[MediaWiki Mail]

"MaxSem" changed the status of MediaWiki.r114293 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114293

Old status:  new
New status: ok

Commit summary for MediaWiki.r114293:

redirect to english version of zero for language landing page for only certain 
carriers

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Video codecs and mobile

[Ian Baker]

Thanks for bringing this up, Brion.  I've been hoping we could have this
conversation for a while now.

Before coming to WMF, I worked for a number of years as a broadcast
engineer for a fairly popular video site.  So, I've researched this in some
depth.  Here's a summary.

First, let's talk about the technical difference between the codecs as it
pertains to this discussion:

* h.264 is clearly the best from a technical standpoint.  The encoder
itself has features that aren't present in the others.  Also, it's been on
the market longer so implementations are more highly optimized.  There's
specific hardware support in a lot of devices, and GPU-accelerated decode
support in a lot of software.  h.264 was developed by a number of companies
as an "open" standard, but is covered by many patents.

* WebM (aka VP8) is really not bad, but is technically inferior to h.264
Main and High Profiles[1].  It's a modern codec, but being newer doesn't
make it better.  That said, it's close enough to h.264 that the quality
difference isn't worth being concerned about.  It was developed in a closed
fashion by a single company (ON2), which was then acquired by Google, who
open-licensed it.

* Theora is old, and technically inferior.  It can encode video of the same
quality as h.264 or WebM, but it requires more than twice the bitrate to do
it[2].  Client support is poor.  Hardware decoders are less important
because the lower complexity means it decodes pretty quick.

Now, let's talk about the issues:

Licensing is an issue with h.264.  The ways we might be subject to license
terms are by serving content, and by distributing an encoder (as part of
Mediawiki)[3].  We can escape the second easily by not distributing the
actual encoder (libx264).  We would probably need to obtain a license for
serving video, but MPEG-LA has said that no-cost video distribution will be
royalty-free until at least 2015, possibly longer.

Licensing may or may not be an issue with WebM.  It's been alleged that
WebM infringes some of the h.264 patents.  This might be true, or it might
be MPEG-LA's butthurt hyperbole.  I'm not enough of an expert on codecs or
IP to know.  Google assures us that everything is fine, but they also have
a significant stake in everything being fine.  It's impossible to trust any
of the companies involved, so I go with Jason from [1] who says it may be
an issue.  Until this has been litigated, we should keep in mind that
things could change for WebM.

Theora is as patent-free as any other technology.  It's possible somebody's
patents cover it, but if we worry about Theora, we've forsaken the entire
idea of patent-freedom.  However, the bandwidth cost per video served with
Theora is much higher.  Let's be clear about that: Theora is currently the
only codec that actually costs us more money to use.

Here's what I think we should do:

Let's distribute h.264 for the next three years, alongside WebM and Theora.
 Use the free formats whenever possible, and switch to h.264 when necessary.

Let's not make the h.264 files readily downloadable.  Rather, include a
disclaimer explaining that redistribution could subject the user to
MPEG-LA's licensing requirements, and wouldn't you prefer this lovely WebM
file instead?

This gets us good video distribution now, which helps to fulfill our
primary goal: making knowledge available to everyone.

If MPEG-LA decides to start charging for Internet video in 2015, we can
turn off h.264 then.  People will lose access to video content, but they're
people who'd have never had that access before.  Also, it makes a statement
that people will be a lot more likely to notice.

Doing it this way will give the WebM infrastructure a bit more time to
catch up.  Hopefully by 2015 it'll be supported broadly enough that the
Internet won't be so dependent on h.264.

An argument can be made that our lack of h.264 support will drive WebM
adoption, but the mechanism there isn't clear to me.  While we're big, we
aren't much of a player in the streaming video space right now.  It seems
like we're facing a classic chicken-and-egg problem: without a broadly
supported codec, how do we collect and distribute videos, and without lots
of videos, how do we influence the codec market?  Note that YouTube is
still pushing lots of h.264.

The costs of doing it this way are:

* Additional encoding resources to make the h.264 files.
* Additional disk space for storing those files
* Reduced bandwidth costs when serving smaller files
* ... but increased bandwidth costs since more people will actually watch
videos, because they'll work.

As far as a plan goes, I agree with Michael: deploy TMH in the state it's
in (WebM and Theora), get the bugs in transcoding and serving video worked
out, then add in h.264 when that's done.

References:
1: "The first in-depth technical analysis of VP8"
http://x264dev.multimedia.cx/archives/377
2: "Video Encoder Comparison" http://keyj.emphy.de/video-encoder-comparison/
3: "Summary of AVC license 

[MediaWiki-CodeReview] [MediaWiki r114064]: New comment added, and revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114064 to "fixme" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114064#c32393

Old Status: new
New Status: fixme

Commit summary for MediaWiki.r114064:

Brought trigger links into the plugin itself; styled flyover panel:
- modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.js:
* Brought in trigger links, standardized them, and added the 
disable
  flyover.
- New property selectedLinks
- New template disableFlyover
- Added object triggerLinks (like buckets and ctas)
- Added selecting and insertion of trigger links to init()
- New methods selectTriggerLinks(), addTriggerLinks(),
  buildDisableFlyover(), and clickTriggerLink()
- Updated buildLink() to handle a flexible number of 
replacements, and
  to handle tags other than links
- modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.css:
- Updated flyover styles to match latest mockup and to work 
with both
  link E and link A
- Added trigger link styles from ext.articleFeedbackv5.css
- modules/ext.articleFeedbackv5/ext.articleFeedbackv5.css:
- Removed trigger link styles
- modules/ext.articleFeedbackv5/ext.articleFeedbackv5.js:
- Removed building of trigger links
- Plugin is now attached after it's been added to the page, so 
that
  trigger links can be inserted relative to it
- ArticleFeedbackv5.i18n.php:
- Changed messages and wording to match latest mockup
- Put in real doc lines
- ArticleFeedbackv5.hooks.php:
- Updated to match new messages

Catrope's comment:


+ 'articlefeedbackv5-disable-flyover-help-goto' => 'To remove $1, go to',
+ 'articlefeedbackv5-disable-flyover-help-emphasis-text' => 'Article Feedback',
+ 'articlefeedbackv5-disable-flyover-help-location' => 'My preferences > 
Appearance',
+ 'articlefeedbackv5-disable-flyover-help-direction' => 'and check',
+ 'articlefeedbackv5-disable-flyover-prefbutton' => 'Go to my preferences',

This is one big pile of Lego. You should have a master message that looks like 
'To remove $1, got to $2 and check $3' rather than concatenating 
things together with the hardcoded assumption that they'll always be in that 
order in every single one of the 250+ languages we support.


+.tipsy-arrow {
/* @embed */
background-image: url(images/tipsy-flyover.png);
width: 23px;
height: 11px;
+}
+.tipsy-nw .tipsy-arrow {
+ margin-top: -6px;
+}
+.tipsy-se .tipsy-arrow {
margin-top: -11px;
}

The CSS rules for Tipsy here should be namespaced (made more specific) so they 
only apply to Tipsy tooltips created by AFTv5, not to any other Tipsy tooltips 
that might appear on the page.


+ var re = new RegExp("\\$" + i);
+ full = full.replace( re, mw.html.element(

The replace function takes a string too, so you can do full.replace( '$' 
+ i, ... ) and that's equivalent to this code. That will only replace 
the first occurrence though; if you care about replacing multiple occurrences 
of the same parameter, use the g modifier in your regex: re = new 
RegExp("\\$" + i, 'g');.

However, this still suffers from a potential bug where $1 expands to something 
containing the literal string "$2", which is then expanded again, and it's also 
buggy if $10 is used (because that'll get expanded as $1 followed by a literal 
0). If you're paranoid enough to want to fix that (or just like cleaner code), 
you can use a callback with replace():

full.replace( /\$(\d+)/g, function( str, number ) {
var i = parseInt( number, 10 );
return whatTheReplacementShouldBeFor( i );
} );



+ hasTipsy = false;

AFAICT this variable is leaked to the global scope.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] Strange API bevahiour reported by bot owners

[Bináris]

Hi folks,

could you please have a look at this thread?
http://thread.gmane.org/gmane.comp.python.pywikipediabot.general/12551

May that be something in API or shall we debug the bots?

-- 
Bináris
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Strange API bevahiour reported by bot owners

[Dan Collins]

If you can come up with a specific request that consistently yields these
errors then please provide it, that will give a better idea what's going
on. Even just providing a request that causes it intermittently is ok, that
way we have something to go on.
On Mar 20, 2012 3:43 PM, "Bináris"  wrote:

> Hi folks,
>
> could you please have a look at this thread?
> http://thread.gmane.org/gmane.comp.python.pywikipediabot.general/12551
>
> May that be something in API or shall we debug the bots?
>
> --
> Bináris
> ___
> 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] enwiki revision schema migration in progress

[Asher Feldman]

On Tuesday, March 20, 2012, Roan Kattouw  wrote:
> On Tue, Mar 20, 2012 at 11:35 AM, Asher Feldman 
wrote:
>> How do you feel about a switch to change that behavior (maxlag - 1)? It
>> would be nice to be continue guiding developers towards throttling API
>> requests around maxlag without complicating schema migrations by
requiring
>> config deployments before and after every db for this reason only.
> That sounds reasonable to me, what alternative behavior do you
> propose? A flag that, when enabled, causes maxlag to use the 2nd
> highest lag instead of the highest lag?

That was my original thought. Jeremy's idea is good too, though I wonder if
we could do something similar without depending on deployments.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Video codecs and mobile

[Lars Aronsson]

On 03/20/2012 08:06 PM, Ian Baker wrote:

An argument can be made that our lack of h.264 support will drive WebM
adoption, but the mechanism there isn't clear to me.  While we're big, we
aren't much of a player in the streaming video space right now.  It seems
like we're facing a classic chicken-and-egg problem: without a broadly
supported codec, how do we collect and distribute videos, and without lots
of videos, how do we influence the codec market?  Note that YouTube is
still pushing lots of h.264.


I'm not opposed to trying H.264, but I doubt it will solve our problem,
which is that we have too few videos.

The category:Videos from Sweden (an early adopter market) is now at
110 files, which is a ridiculously small number. It has doubled each
year (30 in 2010, 52 in 2011), but that growth is too slow to reach
any significant numbers in the next 2-3 years. I don't see that lack
of H.264 playback is slowing this down, that mechanism isn't clear
to me.

I think that converting whatever comes out of my camera into
something that Commons will accept is part of the problem. This does
not imply that H.264 needs to be stored on Commons, only that
whatever is uploaded gets converted by the server rather than by
the user before upload.

The biggest obstacle, however, I think is that people aren't used
to work creatively with a video camcorder, not the way they work
with a still camera, taking events from different angles, in different
light, with different aperture or focus. It might be that video
requires more specialization, including script-writing and sound
editing, and that we should hope for a few specialized, highly
productive contributors of video (like that German WikiTV project,
or a team driving around capturing streets of every local town),
rather than the everybody-can-contribute approach we have taken
to still photography and text editing.

I was hoping that we would organize video competitions, but I have
held back, because I don't see any crowd with camcorders in their
hands. Now, if we get there in 2013 or 2014, and then discontinue
H.264 playback in 2015, we could be in for a real backlash.


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

Re: [Wikitech-l] Video codecs and mobile

[David Gerard]

On 20 March 2012 20:02, Lars Aronsson  wrote:

> I'm not opposed to trying H.264, but I doubt it will solve our problem,
> which is that we have too few videos.
> The category:Videos from Sweden (an early adopter market) is now at
> 110 files, which is a ridiculously small number. It has doubled each
> year (30 in 2010, 52 in 2011), but that growth is too slow to reach
> any significant numbers in the next 2-3 years. I don't see that lack
> of H.264 playback is slowing this down, that mechanism isn't clear
> to me.
> I think that converting whatever comes out of my camera into
> something that Commons will accept is part of the problem. This does
> not imply that H.264 needs to be stored on Commons, only that
> whatever is uploaded gets converted by the server rather than by
> the user before upload.


Yes. That's the biggest barrier to participation. We need to be able
to ingest whatever comes out of people's cameras.


> I was hoping that we would organize video competitions, but I have
> held back, because I don't see any crowd with camcorders in their
> hands. Now, if we get there in 2013 or 2014, and then discontinue
> H.264 playback in 2015, we could be in for a real backlash.


This is an excellent argument against making ourselves hostage to the
MPEG-LA. Giving people like that any leverage over Wikimedia strikes
me as a *spectacularly* awful idea.

(foundation-l added to cc: - changing the encumbered formats policy is
not a matter to be quietly decided over on a tech list.)


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r113221]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r113221 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113221

Old status:  new
New status: ok

Commit summary for MediaWiki.r113221:

(bug 34302) Add CSS classes to email fields in user preferences

Patch by Nischay Nahata whom I have mentored earlier this week.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113696]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r113696 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113696

Old status:  new
New status: ok

Commit summary for MediaWiki.r113696:

(bug 34978) Use a rev parent batch query to get the diff sizes for history 
pages rather than rely on assumptions that break if any filtering is used.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114016]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114016 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114016

Old status:  new
New status: ok

Commit summary for MediaWiki.r114016:

fix for bug 35057 - also suggested as an upstream change for jquery.elastic

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114013]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114013 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114013

Old status:  new
New status: ok

Commit summary for MediaWiki.r114013:

partial fix for bug 35057 - backporting a patch from jQuery 1.7.2pre

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113458]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r113458 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113458

Old status:  new
New status: ok

Commit summary for MediaWiki.r113458:

partial work-around for jQuery/jQuery.elastic bug, see bug 35057

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113922]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r113922 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113922

Old status:  new
New status: ok

Commit summary for MediaWiki.r113922:

Bug 35051 - [Regression] If heading has a trailing space after == then its name 
is not preloaded into edit summary on section edit. Regression from r105380.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114217]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114217 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114217

Old status:  new
New status: ok

Commit summary for MediaWiki.r114217:

Follow up to r114126: Being more conservative for HipHop compiler

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114126]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114126 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114126

Old status:  new
New status: ok

Commit summary for MediaWiki.r114126:

Sanitizing already existing use of PHP's assert

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114132]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114132 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114132

Old status:  new
New status: ok

Commit summary for MediaWiki.r114132:

Removed XmlTest::testNamespaceSelector(); it just breaks when 
$wgDevelopmentWarnings is set to true due to the fact that 
Xml::namespaceSelector() calls wfDeprecated().

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114116]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114116 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114116

Old status:  new
New status: ok

Commit summary for MediaWiki.r114116:

[jquery.byteLimit] Set vars in return this.each loop
* Set vars in return this.each loop. This is the defacto standard plugin 
structure
  but somehow it slipped through this one (it's a 2 line wrapper, easy to miss).
* Added unit test (which failed before this commit)
* Fixes:
-- (bug 35294) jquery.byteLimit shouldn't set element specific variables 
outside the "return this.each" loop.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114140]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114140 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114140

Old status:  new
New status: ok

Commit summary for MediaWiki.r114140:

[Html::namespaceSelector clean up] fix broken html from r114131

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r39787]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r39787 to "old"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/39787

Old status:  new
New status: old

Commit summary for MediaWiki.r39787:

Grammar tweak (bug 14239)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114169]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114169 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114169

Old status:  new
New status: ok

Commit summary for MediaWiki.r114169:

Removing empty created dir

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114241]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114241 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114241

Old status:  new
New status: ok

Commit summary for MediaWiki.r114241:

Backport CryptRand from r110825 and r114233 to REL1_17, REL1_18, and REL1_19 so 
all our supported versions of MediaWiki support proper cryptographic random 
sources for our tokens.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113638]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r113638 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113638

Old status:  new
New status: ok

Commit summary for MediaWiki.r113638:

Rebranched from trunk around r113637

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114228]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114228 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114228

Old status:  new
New status: ok

Commit summary for MediaWiki.r114228:

[FileRepo] Added long-since missing FOR UPDATE to LocalFile::lock(). This might 
help with the weird mismatched metadata for files with two uploads at the same 
time that I keep seeing in the DB.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114143]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114143 to "deferred"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114143

Old status:  new
New status: deferred

Commit summary for MediaWiki.r114143:

Adding Arabic translation of 'Mauritania' to countries.i18n.php

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114285]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114285 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114285

Old status:  new
New status: ok

Commit summary for MediaWiki.r114285:

MFT r114228

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114223]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114223 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114223

Old status:  new
New status: ok

Commit summary for MediaWiki.r114223:

Revert 
r114221,r114216,r114213,r114207,r114206,r114205,r114203,r114202,r114201,r114200,r114197

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114198]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114198 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114198

Old status:  new
New status: ok

Commit summary for MediaWiki.r114198:

Copy MobileFrontend from trunk at r113447

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114160]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114160 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114160

Old status:  new
New status: ok

Commit summary for MediaWiki.r114160:

1.19wmf1 MFT r113910 r113782

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114255]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114255 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114255

Old status:  new
New status: ok

Commit summary for MediaWiki.r114255:

Remove SVG fonts for non latin languages- it does not work.
(These files were present from initial days of extension)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113572]: Revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r113572 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113572

Old status:  new
New status: ok

Commit summary for MediaWiki.r113572:

Add release note for r102026/r107073

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114064]: New comment added

[MediaWiki Mail]

"Rsterbin" posted a comment on MediaWiki.r114064.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114064#c32394

Commit summary for MediaWiki.r114064:

Brought trigger links into the plugin itself; styled flyover panel:
- modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.js:
* Brought in trigger links, standardized them, and added the 
disable
  flyover.
- New property selectedLinks
- New template disableFlyover
- Added object triggerLinks (like buckets and ctas)
- Added selecting and insertion of trigger links to init()
- New methods selectTriggerLinks(), addTriggerLinks(),
  buildDisableFlyover(), and clickTriggerLink()
- Updated buildLink() to handle a flexible number of 
replacements, and
  to handle tags other than links
- modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.css:
- Updated flyover styles to match latest mockup and to work 
with both
  link E and link A
- Added trigger link styles from ext.articleFeedbackv5.css
- modules/ext.articleFeedbackv5/ext.articleFeedbackv5.css:
- Removed trigger link styles
- modules/ext.articleFeedbackv5/ext.articleFeedbackv5.js:
- Removed building of trigger links
- Plugin is now attached after it's been added to the page, so 
that
  trigger links can be inserted relative to it
- ArticleFeedbackv5.i18n.php:
- Changed messages and wording to match latest mockup
- Put in real doc lines
- ArticleFeedbackv5.hooks.php:
- Updated to match new messages

Rsterbin's comment:

Annoyingly enough, your suggestion was what I did first, before I noticed that 
the mockups called for line breaks.  I would LOVE to put it back the way you 
suggest, but Fabrice needs to sign off on not having the line breaks he wanted.

I'll fix the other stuff soon.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114306]: Revision status changed

[MediaWiki Mail]

"Preilly" changed the status of MediaWiki.r114306 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114306

Old status:  new
New status: ok

Commit summary for MediaWiki.r114306:

Added methods to return a desktop view URL (reversing the URL using the mobile 
URL template); Changed 'Desktop view' URL to use new methods; Added 
corresponding test

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] New Plugin for Extension:ConfirmEdit - RFC

[Benjamin Lees]

On Mon, Mar 19, 2012 at 11:41 PM, nischay nahata  wrote:
> However this is what is done in QuestyCaptcha, Is there any way we can add
> localisation to Questions on QuestyCaptcha?

Probably.  Most wikis don't have $wgLoginLanguageSelector enabled, but
this could be handy for those that do.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r114304]: Revision status changed

[MediaWiki Mail]

"Preilly" changed the status of MediaWiki.r114304 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114304

Old status:  new
New status: ok

Commit summary for MediaWiki.r114304:

Fixed converted sections being cached instead of unconverted, renamed section 
format none --> plain

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114162]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114162 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114162

Old status:  new
New status: ok

Commit summary for MediaWiki.r114162:

Reverted r113688, r113691 per CR and filed #61440 upstream.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114232]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114232 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114232

Old status:  new
New status: ok

Commit summary for MediaWiki.r114232:

Better bug reference for r114231.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114231]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114231 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114231

Old status:  new
New status: ok

Commit summary for MediaWiki.r114231:

Fixed a few "strip tag exposed" bugs.
* Introduced Parser::killMarkers() based on the concept from StringFunctions. 
Used it in cases where markerStripCallback() doesn't make sense semantically, 
namely grammar, padleft, padright and anchorencode. Used markerStripCallback() 
in other cases.
* Changed headline unstrip order as suggested by P.Copp on bug 18295
* In CPF::lc() and CPF::uc(), removed the is_callable(). This was a temporary 
testing hack committed by me in r30109, which allowed me to do differential 
testing against a copy of the parser from before that revision.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114182]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114182 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114182

Old status:  new
New status: ok

Commit summary for MediaWiki.r114182:

Make the first line of debug log more consitent between CLI and web call by 
putting the method and the URL directly on the first line

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114243]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114243 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114243

Old status:  new
New status: ok

Commit summary for MediaWiki.r114243:

* (bug 34735) Updated compressOld.php documentation to mention the different 
usages of -s and -n parameters depending on compression type

Based on patch by christ...@quelltextlich.at - 
http://bug-attachment.wikimedia.org/attachment.cgi?id=10105

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114234]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114234 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114234

Old status:  new
New status: ok

Commit summary for MediaWiki.r114234:

(bug 35316) On autocreate, use $this as the "doer" in the newuser log entry, 
since unlike User::addNewUserLogEntry(), there is no way the action could have 
been triggered by a different user. Usually $wgUser is set correctly, but 
there's no need to rely on it here.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114313]: Revision status changed

[MediaWiki Mail]

"Awjrichards" changed the status of MediaWiki.r114313 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114313

Old status:  new
New status: ok

Commit summary for MediaWiki.r114313:

Fix cross-platform line ending madness

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] New Plugin for Extension:ConfirmEdit - RFC

[Antoine Musso]

Le 19/03/12 18:13, Mono wrote:
> What about the people that don't pray to God?

If the extension offer the ability to be presented a new question,
they can just do so :-)


-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Video codecs and mobile

[MZMcBride]

David Gerard wrote:
> On 20 March 2012 01:24, Brion Vibber  wrote:
>> In theory we can produce a configuration with TimedMediaHandler to produce
>> both H.264 and Theora/WebM transcodes, bringing Commons media to life for
>> mobile users and Apple and Microsoft browser users.
>> What do we think about this? What are the pros and cons?
> 
> No. Just because Mozilla has decided to do the wrong thing for
> commercial reasons does not somehow compel us to. It's only pressure
> from users that will get the companies to use unlocked formats.

I agree with David here, though I'd encourage all parties to think about the
issue broadly and in creative ways.

For example, the Wikimedia Foundation has a substantial amount of capital
and could theoretically generate more for a specific purpose like this.
Would buying the rights to codecs like these be feasible? What kind of cost
are we talking about? Are there other solutions that could be considered
that don't compromise Wikimedia's values?

I think we can all agree that Ogg sucks. Are there ways to make it suck
less?

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Mediawiki-l] New Plugin for Extension:ConfirmEdit - RFC

[Antoine Musso]

Le 20/03/12 03:11, nischay nahata a écrit :
> Thanks for your replies, I realize this is a faulty plugin right now for
> following reasons
> 
> * 25% probability
> * securing the questions and answers
> 
> I will see if I can remove them, again this is my first plugin and I am
> trying to learn
> so my apologies :)

Learning from mistakes is the best way to train your brain in fixing
problems. Open source will help you improve your skill:

1) publish your code to the public
2) get flaws exposed
3) Understand what is wrong
4) Fix / amend / rewrite
5) Repeat

If the idea end up being totally wrong. Rethink about it, talk about it
with other people and submit some new code :-)

In the end:

Profit!!!  (please donate to your favorite foundation)


I for one like the idea of making Captcha more meaningful to humans and
harder to solve by bots.

Congrats on your first extension!


-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] enwiki revision schema migration in progress

[MZMcBride]

Roan Kattouw wrote:
> On Tue, Mar 20, 2012 at 7:12 AM, MZMcBride  wrote:
>> Some people have suggested that the current API behavior is intentional.
>> That is, that having different servers return the same error code is better
>> than having different servers return an error code or not. I think this is
>> flawed logic due to the problems that it presents (scripts unable to get
>> past the error code), but it's definitely something that needs investigation
>> for the future.
>
> You're confusing Apache servers and database servers. You're hitting
> different Apache servers at random, those are the srv numbers. Each
> Apache requests the current lag from all the DB servers serving that
> wiki, computes the maximum (in this case db36 wins easily) and checks
> that against your maxlag parameter. Obviously the highest lag is
> greater than your maxlag setting, so it throws an error and bails.
> 
> Had it continued, or had you not set a maxlag parameter, you would
> have hit a DB server at random (except that it wouldn't have let you
> hit db36 because it was lagged to hell and back). So yeah /normally/
> you hit DB servers at random and different servers might respond
> differently (or be lagged to different degrees), but in this
> particular case it was always the same DB server returning the same
> lag value. Nothing strange going on here, this is how the maxlag
> parameter works.

Thank you for this explanation. It was very helpful.

I had some follow-up questions about what to do to mitigate this issue going
forward (particularly server-side), but you and others are already
brainstorming in this thread, so I'll slink back to my quiet world of
client-side scripting. :-)

(And thanks again to Asher for depooling the lagged server, even as a
temporary fix. I was able to do about 2500 talk page deliveries this morning
without any issue.)

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] irc logs

[MZMcBride]

Hi. I'm going to combine replies just so I don't hit wikitech-l a dozen
times.

Petr Bena wrote:
> I created a search engine for irc logs, it works much faster than
> current engine and it's written in php. I will send a source code
> soon.
> 
> http://bots.wmflabs.org/~wm-bot/searchlog/

Fantastic! It seems to be much better than the old search. :-)

> I don't understand html, so output is ugly. If someone wants to help
> to improve it, let me know.

You've got an XSS vulnerability in the current script. You need to escape
all output! In this case, you need to be sure to escape quotation marks in
particular.

Bergi wrote:
> Cool. I didn't know that there had already been an engine?

Yes, I hacked one up some time ago. It lives at
.

Petr Bena wrote:
> Yes there is some python script, but it always took so long for it to
> search something that I always decided to just close browser (10+
> minutes to execute search)

Yes, it's just a very simple (and quite hackish) Python CGI wrapper for the
operating system's grep. As the logs have grown, grepping has taken longer
and longer. Plus the results truncation is done at the Python level, not the
grep level, so a search with a lot of results takes much longer to return
results, as I recall. A proper search index is going to be much better. :D

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r114315]: Revision status changed

[MediaWiki Mail]

"Awjrichards" changed the status of MediaWiki.r114315 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114315

Old status:  new
New status: ok

Commit summary for MediaWiki.r114315:

hide overflowing text

in firefox mobile the labels are not hidden

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114311]: Revision status changed

[MediaWiki Mail]

"Aaron Schulz" changed the status of MediaWiki.r114311 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114311

Old status:  new
New status: ok

Commit summary for MediaWiki.r114311:

* Use local context to get messages
* Use Language::userTimeAndDate() instead of Language::timeanddate() to display 
the date with user preferences
* Set the form's action to $wgScript instead of direct link to the page since 
it makes a GET request (and the title would be displayed twice with pretty URLs 
since there's already a 

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114117]: New comment added, and revision status changed

[MediaWiki Mail]

"Aaron Schulz" changed the status of MediaWiki.r114117 to "ok" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114117#c32395

Old Status: new
New Status: ok

Commit summary for MediaWiki.r114117:

* (bug 35303) Make proxy and DNS blacklist blocking work again

Aaron Schulz's comment:

Block could use some more accessors.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Video codecs and mobile

[MZMcBride]

Michael Dale wrote:
> On 03/20/2012 03:15 AM, David Gerard wrote:
>> We should definitely be able to ingest H.264. (This has been on the
>> wishlist forever and is a much harder problem than it sounds.)
> 
> Once TMH is deployed,  practically speaking .. upload to youtube ->
> import to commons .. will probably be the easiest path for a while.
> Especially given the tight integration youtube has with every phone, and
> any capture device with web.
> 
> But yes the feature should be developed, and it is more difficult then
> it sounds when you want to carefully consider things like making the
> source file available.

Is there any timeline for a deployment of TimedMediaHandler?

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Mediawiki-l] New Plugin for Extension:ConfirmEdit - RFC

[Yuvi Panda]

On Wednesday 21 March 2012 at 3:20 AM, Antoine Musso wrote:
> Congrats on your first extension!
> 
> 

+1
 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Video codecs and mobile

[MZMcBride]

Brion Vibber wrote:
> As some may know, we've restricted videos on Wikimedia sites to the
> freely-licensed Ogg Theora codec for some years, with some intention to
> support other non-patent-encumbered formats like WebM.

Any thoughts on ?

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r114317]: New comment added

[MediaWiki Mail]

"Jeroen De Dauw" posted a comment on MediaWiki.r114317.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114317#c32396

Commit summary for MediaWiki.r114317:

Fix for r97507 - default for 'delim' parameter is ''

Jeroen De Dauw's comment:

How do you figure this? Looking at my commit again, it seems the default 
delimiter already was a comma.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114317]: New comment added

[MediaWiki Mail]

"Yaron Koren" posted a comment on MediaWiki.r114317.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114317#c32397

Commit summary for MediaWiki.r114317:

Fix for r97507 - default for 'delim' parameter is ''

Yaron Koren's comment:

Right - I changed it from a comma to blank.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114318]: Revision status changed

[MediaWiki Mail]

"Preilly" changed the status of MediaWiki.r114318 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114318

Old status:  new
New status: ok

Commit summary for MediaWiki.r114318:

Return intros only to OpenSearchXml to avoid returning just 1 result:)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Setting $wgCategoryCollation to 'uca-default' on WMF wikis

[K. Peachey]

On Wed, Mar 21, 2012 at 4:54 AM, Helder  wrote:
> So, how could we check whether "Portuguese" wikis would break by doing
> this change?

As Tim said:
* Set one of the test wikis (Testwiki, Testwiki2) to Portuguese
* change to said collation
* do some editing
* see if it breaks

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r114319]: New comment added, and revision status changed

[MediaWiki Mail]

"Reedy" changed the status of MediaWiki.r114319 to "ok" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114319#c32398

Old Status: new
New Status: ok

Commit summary for MediaWiki.r114319:

:facepalm:

Reedy's comment:

Why didn't we implement a smily commit summary parser?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Video codecs and mobile

[David Gerard]

On 20 March 2012 19:06, Ian Baker  wrote:

> * WebM (aka VP8) is really not bad, but is technically inferior to h.264
> Main and High Profiles[1].

This comparison appears specious in the context of this thread, which
is the iPhone - the iPhone (which is the context of this thread)
doesn't support Main or High, only Baseline.

How does VP8 compare to H.264 Baseline profile?

(Up to 640x480, 'cos the iPhone doesn't go any higher of course. Is
the proposal to limit Wikimedia video to 640x480 as well, for the
mobile market?)


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Code freeze and temporary reverts for Gerrit migration

[Roan Kattouw]

As you all probably know, the Gerrit migration is going to happen in a
little over 24 hours. For the SVN repositories being migrated (core
and all WMF-deployed extensions), I am doing three special things
today.

First, I am identifying all unreviewed revisions and reviewing those
that 1) I am capable of reviewing and 2) that I feel are small enough
and/or important enough to review.

Second, I am reverting all remaining unreviewed revisions and tagging
them with the 'gerritmigration' tag. These reverts are temporary, and
I will resubmit the reverted revisions into Gerrit after the
switchover. They will then have to go through the code review process
in Gerrit. It will be a bit weird and awkward to review so many
revisions, but this ensures that we can migrate to Gerrit with a clean
repository free of unreviewed code. I'll be doing these reverts in
logical chunks where possible, but I will eventually revert everything
that's unreviewed, so don't take it personally :) .

Third, I am declaring a code freeze effective immediately. It's not a
complete freeze, but stricter than the preceding slush (so maybe it's
froyo or something?). Essentially, the freeze means that as of right
now, we are pretty much going to do pre-commit review. If you want to
commit something between now and the Gerrit migration, you will need
to get your patch reviewed by someone *before* you commit it, and that
person will have to OK the revision in CodeReview shortly after it's
committed. I will periodically check the repository, and any new
commits that are unreviewed and have been sitting in the repo for more
than an hour will be reverted on sight, tagged with 'gerritmigration'
and resubmitted into Gerrit after the migration.

I realize that this is kind of a sudden and unilateral decree that I'm
imposing here, and I apologize for that. However, it's only for 24
hours and it's what needs to be done in order for the Gerrit migration
tomorrow to happen smoothly, so I hope you'll understand.

Roan

P.S.: Any help with the reviewing, reverting, tagging and/or
resubmitting revisions would be appreciated, but please find me on IRC
before you start helping me; if I am not on IRC, that means I'm not
working and you can go right ahead.

P.P.S.: Before anyone asks: in the (IMO unlikely) event that the
Gerrit migration doesn't happen tomorrow and is delayed to next week
or beyond, the code freeze automatically ends at 23:59 PDT (that's Mar
22, 07:59 UTC).

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Strange API bevahiour reported by bot owners

[Hilbrand Hamstra]

I posted a similar message a few days ago...

centralauth_Session=128f7721167ed94f452ce5701080; path=/; domain=.
wikipedia.org; httponlynlwikiUserID=180134; expires=Fri, 14-Sep-2012
22:52:04 GMT; path=/; httponly nlwikiUserName=WriteroscarBot; expires=Fri,
14-Sep-2012 22:52:04 GMT; path=/;
httponlycentralauth_Token=759de902f87f59e15bf5db9e43a7;
expires=Fri, 14-Sep-2012 22:52:04 GMT; path=/; domain=.wikipedia.org;
httponlycentralauth_User=WriteroscarBot; expires=Fri, 14-Sep-2012 22:52:04
GMT; path=/; domain=.wikipedia.org; httponly

Hi,

I'm having some troubles with the Edit action of the API. Logging in/
logging out it all works perfectly fine. I'm sending with my request the
cookies as shown above. The edit action succeeds, but it shows my IP as the
editing user and not my username. I only have this problem using the dutch
website (nl.wikipedia.org version 1.19wmf1). Not if use a WikiMedia
installation on my own website (version: *1.18.1).
*

Regards,
Brand

Op 20 maart 2012 20:47 schreef Dan Collins  het
volgende:

> If you can come up with a specific request that consistently yields these
> errors then please provide it, that will give a better idea what's going
> on. Even just providing a request that causes it intermittently is ok, that
> way we have something to go on.
> On Mar 20, 2012 3:43 PM, "Bináris"  wrote:
>
> > Hi folks,
> >
> > could you please have a look at this thread?
> > http://thread.gmane.org/gmane.comp.python.pywikipediabot.general/12551
> >
> > May that be something in API or shall we debug the bots?
> >
> > --
> > Bináris
> > ___
> > 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

Re: [Wikitech-l] Video codecs and mobile

[Ian Baker]

On Tue, Mar 20, 2012 at 3:38 PM, David Gerard  wrote:

> On 20 March 2012 19:06, Ian Baker  wrote:
>
> > * WebM (aka VP8) is really not bad, but is technically inferior to h.264
> > Main and High Profiles[1].
>
> This comparison appears specious in the context of this thread, which
> is the iPhone - the iPhone (which is the context of this thread)
> doesn't support Main or High, only Baseline.
>
> How does VP8 compare to H.264 Baseline profile?
>

Good point.  VP8 is pretty similar to h.264 Baseline.  I'd be surprised if
even a person with considerable digital video experience would notice the
difference.

However, in the context of the iPhone, there's no good way to play VP8.
 Even if the software problem were solved, the lack of a hardware decoder
means it'd completely destroy the battery life.

For our purposes, encoding files with Main or High profiles could be used
to drop the bitrate without compromising quality, thereby saving bandwidth.
 It's not a huge difference, though, and I don't think we'd bother.  As I
said, VP8 and h.264 are mostly interchangeable from a technical standpoint.
 I brought it up to debunk the notion that because VP8 is newer, that
automatically makes it better.

But... there are other platforms that have a crappy video playback
experience with WebM or Theora.  I don't think this thread is just about
the iPhone, though mobile is certainly the hardest problem to solve here.

We've also been talking about h.264 ingest, which is completely different
and arguably more important.  There are millions of HD camcorders wandering
the world inside people's phones, which are also reasonably capable video
editing platforms.  We could be taking advantage of that.

-Ian
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Video codecs and mobile

[David Gerard]

On 20 March 2012 23:00, Ian Baker  wrote:

> We've also been talking about h.264 ingest, which is completely different
> and arguably more important.  There are millions of HD camcorders wandering
> the world inside people's phones, which are also reasonably capable video
> editing platforms.  We could be taking advantage of that.


That we definitely need. We need to be able to take in anything that
comes out of people's cameras.

It's storing and serving it that's going to be problematic. Imagine
the deletionfest on Commons ...


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code freeze and temporary reverts for Gerrit migration

[Jeroen De Dauw]

Hey,

> WMF-deployed extensions

Does this include extension worked on by WMF people and to be deployed on
WMF wikis? In particular, should I quit committing to Education Program or
can I happily carry on?

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r114324]: Revision status changed

[MediaWiki Mail]

"Aaron Schulz" changed the status of MediaWiki.r114324 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114324

Old status:  new
New status: ok

Commit summary for MediaWiki.r114324:

Security paranoia, reject requests to router.php that aren't from the 
cli-server sapi.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114325]: Revision status changed

[MediaWiki Mail]

"Aaron Schulz" changed the status of MediaWiki.r114325 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114325

Old status:  new
New status: ok

Commit summary for MediaWiki.r114325:

Backport r114324 to 1.19 so we don't end up releasing a version of MediaWiki 
with an open router.php.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Code freeze and temporary reverts for Gerrit migration

[Roan Kattouw]

On Tue, Mar 20, 2012 at 4:08 PM, Jeroen De Dauw  wrote:
> Hey,
>
>> WMF-deployed extensions
>
> Does this include extension worked on by WMF people and to be deployed on
> WMF wikis? In particular, should I quit committing to Education Program or
> can I happily carry on?
>
This includes extensions that are *currently* deployed on WMF, no more
and no less. So EducationProgram is "safe" and you can happily
continue committing to it. However, I have temporarily reverted some
of the things you put in core to support EP, because they were largely
unreviewed and were new features rather than bug fixes (let alone
important/urgent bug fixes).

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r114326]: Revision status changed

[MediaWiki Mail]

"Robmoen" changed the status of MediaWiki.r114326 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114326

Old status:  new
New status: ok

Commit summary for MediaWiki.r114326:

Revert r114067, r114071, r114075, r114079, r114081, r114082, r114084, r114086, 
r114088, r114089, r114101, r114118, r114137, r114147, r114164, r114172, 
r114175, r114180, r114208, r114209, r114215, r114219, r114226, r114321, r114322.

This reverts the SpecialCachedPage and formatDuration sagas, with some 
collateral damage here and there. All of these revisions are tagged with 
'gerritmigration' and will be resubmitted into Gerrit after the Gerrit 
switchover. See also 
http://lists.wikimedia.org/pipermail/wikitech-l/2012-March/059124.html

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114312]: Revision status changed

[MediaWiki Mail]

"Robmoen" changed the status of MediaWiki.r114312 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114312

Old status:  new
New status: ok

Commit summary for MediaWiki.r114312:

add missing parameter to constructor and remove redundant parameter from 
function

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r112958]: Revision status changed

[MediaWiki Mail]

"^demon" changed the status of MediaWiki.r112958 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/112958

Old status:  new
New status: ok

Commit summary for MediaWiki.r112958:

[FileBackend]
* Various documentation improvements.
* Moved a few protected FileBackendStoreShardListIterator functions down. Same 
with normalizeContainerPath().

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview