[Bug 40582] 500k logo for Swedish Wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40582

Ronnie  changed:

   What|Removed |Added

 CC||la.val...@yahoo.se

--- Comment #2 from Ronnie  2012-09-28 06:58:56 UTC ---
Regarding your suggestion: File upload is closed on sv.wikipedia.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40587] formatnum magicword

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40587

Raziman T V  changed:

   What|Removed |Added

 CC||razima...@gmail.com

--- Comment #1 from Raziman T V  2012-09-28 06:37:29 UTC 
---
The behavior of formatnum when there are non-numeric characters passed as
argument is in general very different between English and Malayalam.

For example, on trying {{formatnum:x 4200 x}}, the results are:
On enwiki : x 4,200 x
On mlwiki : x, 42

Except for where the commas are placed within numbers (4,20,000 as opposed to
420,000), there shouldn't ideally be any difference between the behavior of
formatnum on en and ml.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40587] New: formatnum magicword

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40587

   Web browser: ---
 Bug #: 40587
   Summary: formatnum magicword
   Product: Wikimedia
   Version: wmf-deployment
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: vss...@gmail.com
Classification: Unclassified
   Mobile Platform: ---


The formatnum magicword works differently in ml and en wikipedia.

Please see a page in english wikipedia using {{formatnum:−5}}. Please note that
the minus sign used here is x2215

http://en.wikipedia.org/w/index.php?title=User:Vssun/sandbox&oldid=514823050

The same function at ml.wikipedia make the entire page blank

http://ml.wikipedia.org/w/index.php?title=%E0%B4%89%E0%B4%AA%E0%B4%AF%E0%B5%8B%E0%B4%95%E0%B5%8D%E0%B4%A4%E0%B4%BE%E0%B4%B5%E0%B5%8D%3AVssun%2Ftest&diff=1429603&oldid=1429602

Changing the minus sign to - (x002D), solves the problem.

http://ml.wikipedia.org/w/index.php?title=%E0%B4%89%E0%B4%AA%E0%B4%AF%E0%B5%8B%E0%B4%95%E0%B5%8D%E0%B4%A4%E0%B4%BE%E0%B4%B5%E0%B5%8D:Vssun/test&diff=next&oldid=1429603

Please correct it in ml.wikipedia to use the formatnum function with both
styles of minus sign.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 36273] jquery.footHovzer module should not cause a scroll bar to appear if total content is shorter than window height

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=36273

Krinkle  changed:

   What|Removed |Added

   Target Milestone|1.20.0 release  |Future release

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40577] Parsoid: Possible performance regression on latest master

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40577

Gabriel Wicke  changed:

   What|Removed |Added

   Priority|Normal  |Low

--- Comment #4 from Gabriel Wicke  2012-09-28 04:37:01 
UTC ---
Yeah, just a steady slowdown in these revisions, and not unexpected for the
extra work on dsr calculations and template round-tripping.

Decreasing the priority for now, can look for optimization opportunities with
node profiler later.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40450] Add namespace name "Category" to categories listed at [[Special:UnusedCategories]]

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40450

Chad H.  changed:

   What|Removed |Added

 CC||innocentkil...@gmail.com

--- Comment #8 from Chad H.  2012-09-28 03:35:34 UTC 
---
(In reply to comment #7)
> Global configuration variables have a pretty high cost. The benefit here is
> very, very limited (in my opinion, a valid use-case for adding the prefixes
> still hasn't even been presented). If users want the prefixes, they can and
> should write a simple JavaScript gadget or similar. I don't see a reason to
> implement a configuration variable here.

Indeed, this does not need a configuration variable.

I don't rightly care one way or the other if the namespace is actually there,
but pick one or the other and just do that for everyone.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40384] HTML validation: Attribute width/height not allowed on element button at this point

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40384

PleaseStand  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pleasest...@live.com
 Resolution||FIXED

--- Comment #3 from PleaseStand  2012-09-28 03:25:04 UTC 
---
gerrit 25606

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24430] "cols" preference is redundant and should be removed

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24430

Chad H.  changed:

   What|Removed |Added

   Target Milestone|1.20.0 release  |Future release

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40586] Chunked uploads: fails immediately when trying to upload large JPEG

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40586

--- Comment #2 from Derrick Coetzee  2012-09-28 01:01:35 
UTC ---
Another update: the file size trials in the previous comment were done on
Chrome on Windows 7 x64 with 8 GB RAM. When moving to Firefox on Ubuntu Linux
64-bit with 2 GB of RAM, the same issue occurred but the maximum size was
considerably higher: somewhere between 175 MB and 277 MB, about twice as much.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 37643] Session may not be started for non-logged-in API edits, causing captcha to fail

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=37643

--- Comment #5 from Brad Jorsch  2012-09-28 
00:37:40 UTC ---
Ok, step by step.

1. Make sure ConfirmEdit is enabled and that it will be using
CaptchaSessionStore.
2. Clear your cookies, if necessary.
3. Make an API request to get an edit token, e.g.
http://localhost/w/api.php?action=query&titles=Sandbox&prop=info&intoken=edit
or http://localhost/w/api.php?action=tokens. Note you will not receive any
session cookie from either of these requests.
4. Make an API request to edit a page, which includes at least one new link.
For example,
http://localhost/w/api.php?action=edit&token=%2B%5C&summary=Test&text=http://www.example.com/&title=Sandbox.
You should get back a response with captcha information. You will receive no
cookie, even though ConfirmEdit tried to save data in the session.
5. Make another API request, supplying the correct captcha information. For
example, if MathCaptcha gave back "3 + 4 = ", you might send
http://localhost/w/api.php?action=edit&token=%2B%5C&summary=Test&text=http://www.example.com/&title=Sandbox&captchaid=1234567890&captchaword=7.
You will get back another response with a different captcha request, and still
no cookie.

When using my patch, in step 4 you ''will'' receive a session cookie, so the
edit will be able to succeed in step 5. In the much more common case that you
already have a session cookie heading into step 4 (e.g. you're logged in), the
"session_id() === ''" test in my patchet will be false so nothing much will
change.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40586] Chunked uploads: fails immediately when trying to upload large JPEG

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40586

--- Comment #1 from Derrick Coetzee  2012-09-28 00:37:13 
UTC ---
An update: I re-encoded the same image at 70% quality, bringing it down to 109
MB, and it uploaded with no problem. At 80% quality (144 MB) it failed. This
suggests the image size/format/generation process are not at issue, but rather
the file size in combination with the file type. Also, the maximum appears to
be somewhere between 109 and 144 MB (perhaps 128MB? might be a browser
limitation?)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 20512] Enable $wgAllowCopyUploads (upload by URL)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=20512

--- Comment #34 from Sam Reed (reedy)  2012-09-28 00:34:12 
UTC ---
(In reply to comment #32)
> (In reply to comment #30)
> > Unfortunately I don't know enough about Lucene to tell what would cause
> > problems. The impression I got from Tim is that the search issue was no 
> > longer
> > a problem, but it would be best to get confirmation from him directly or
> > someone familiar with Lucene.
> 
> The Lucene issue was fixed with a hack in the MWSearch extension, but setting
> $wgHTTPProxy would still break any other Http::get() caller that is attempting
> to fetch things from the local intranet. I think the configuration should be
> split: UploadFromUrl should pass a "proxy" option to MWHttpRequest::factory()
> with a value derived from a global variable specific to this feature.

https://gerrit.wikimedia.org/r/#/c/25605/

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40577] Parsoid: Possible performance regression on latest master

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40577

--- Comment #3 from ssas...@wikimedia.org 2012-09-28 00:31:42 UTC ---
Here is a result of timing runs for the Barack Obama page on my laptop (node
version 0.6.12).  I did 5 runs and picked the best value to minimize network
latency effects on my home wifi.  Overall, nothing alarming that I see here.

+-+--+--+--+--+--+--+---+
| Revision| BEST | r1   | r2   | r3   | r4   | r5   | Revision detail  
|
+-+--+--+--+--+--+--+---+
| master  | 51.8 | 57.3 | 51.8 | 54.3 | 53.6 | 52.0 | category rt fix (and
related patches) |
| 78cf1ce | 52.1 | 54.5 | 52.1 | 52.7 | 53.7 | 53.1 | ref tokenizer fix
|
| d12687d | 52.7 | 54.1 | 56.7 | 53.9 | 52.7 | 54.2 | pre-ref tokenizer fix
|
| 53e823a | 51.0 | 51.0 | 51.7 | 51.4 | 52.9 | 53.9 | templ-encap bug fix  
|
| 9ea500c | 51.6 | 52.0 | 52.7 | 52.2 | 51.6 | 53.5 | fix regression in
tpl-affected attrs  |
| 9b91f43 | 50.4 | 52.3 | 50.4 | 51.1 | 52.3 | 54.0 | dont throw away useful
dsr info   |
| 7ed044e | 49.5 | 49.5 | 50.0 | 50.1 | 51.6 | 50.6 | p-wrapping   
|
| af8a6fa | 48.2 | 48.7 | 49.0 | 48.2 | 50.4 | 49.5 | case-insensitive link
handling|
+-+--+--+--+--+--+--+---+

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40586] New: Chunked uploads: fails immediately when trying to upload large JPEG

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40586

   Web browser: ---
 Bug #: 40586
   Summary: Chunked uploads: fails immediately when trying to
upload large JPEG
   Product: MediaWiki extensions
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: UploadWizard
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: d...@moonflare.com
CC: mtrac...@member.fsf.org
Classification: Unclassified
   Mobile Platform: ---


I was trying to upload a JPEG file using chunked uploads. It is 270 MB
(283,562,965 bytes) and 24576 x 29696 (730 megapixels / 729808896 pixels). The
file was created using ImageMagick 6.7.9-8 2012-09-22 Q16 ("convert a.tiff
a.jpg"). As soon as I try to upload it fails immediately at:

Error:
http://bits.wikimedia.org/static-1.20wmf12/extensions/UploadWizard/resources/mw.UploadWizardUpload.js
at line 471: NS_ERROR_FAILURE: Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIDOMFileReader.result]

 if( this.file.type === 'image/jpeg' ) {
 var binReader = new FileReader();
 binReader.onload = function() {
 var binStr;
 if ( typeof binReader.result == 'string' ) {
>binStr = binReader.result;
 } else {

Debugging in Firebug shows that binReader.result is undefined at the time of
failure.

binReader FileReader {readyState=2,onload=[xpconnect wrapped
nsIDOMEventListener],EMPTY=0, more...}
   DONE=2,
   EMPTY=0,
   LOADING=1,
   error=null,
   onloadend=null,
   readyState=2,
   result=undefined,
   constructor=[object FileReader],
   abort=abort(),
   addEventListener=addEventListener(),
   dispatchEvent=dispatchEvent(),
   getInterface=getInterface(),
   readAsArrayBuffer=readAsArrayBuffer(),
   readAsBinaryString=readAsBinaryString(),
   readAsDataURL=readAsDataURL(),
   readAsText=readAsText(),
   removeEventListener=removeEventListener(),
   __proto__=[xpconnect wrapped native prototype] { ... }

I got the same failure in Chrome and Firefox. IE apparently has no chunked
uploads support at all, as I'm unable to upload any file in it, it just claims
to be uploading but uses no bandwidth.

I have no trouble uploading a smaller 90 MB JPEG file.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 32721] VIPS out of memory on large (>100 Mpx) non-progressive JPEG

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=32721

Derrick Coetzee  changed:

   What|Removed |Added

 CC||d...@moonflare.com

--- Comment #11 from Derrick Coetzee  2012-09-28 00:17:07 
UTC ---
Note that if VIPS isn't feasible for PNGs for whatever reason, my pngscale
project is still available and stable:

https://github.com/dcoetzee/pngscale

I've tested it on a variety of files and it appears to be both stable and fast.
Its memory usage is only two scanlines.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38009] enable mobile redirect broken (Certain iOS users getting served desktop site - reports of mobile view not sticking)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38009

--- Comment #21 from Arthur Richards  2012-09-28 
00:16:07 UTC ---
PS big thanks to everyone who's been helping with this - I basically took the
JS that's being used on enwiki in common.js and integrated it with
MobileFrontend to get loaded on the desktop version of the site.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38009] enable mobile redirect broken (Certain iOS users getting served desktop site - reports of mobile view not sticking)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38009

--- Comment #20 from Arthur Richards  2012-09-28 
00:13:54 UTC ---
I believe https://gerrit.wikimedia.org/r/#/c/25596/4 should fix this. When the
changes get merged, I'd like to enable the changes on a single wiki (maybe
mediawiki.org?) to test for a week to ensure this fully resolves the issue
before pushing out everywhere since we don't really have the ability to test
the efficacy of this change for the production cluster outside of the
production cluster, unless someone else has a better testing strategy. The next
MobileFrontend deployment is scheduled for the upcoming Tuesday, hopefully
we'll get this out then.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40511] Special:FeedbackDashboard 'hide' function should be extended to all autoconfirmed editors

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40511

--- Comment #9 from Steven Walling  2012-09-27 23:59:13 
UTC ---
(In reply to comment #4)
> 
> Sadly I think this is pretty high risk right now. We don't currently have any
> other way to delete moodbar comments, the hide function is the ONLY way, after
> that the next escalation is to manually edit the database. This leads us to
> some major issues and the hidden feedback includes things that would normall 
> be
> oversighted such as libel or personal information. This is problematic for 
> even
> sysops to have access to but, I believe, has been a compromise until a full OS
> option is available. In my opinion it seems absolutely unacceptable to have
> autoconfirmed users able to view and undelete at the very least without legal
> approval and a much comprehensive community consensus (with them having a full
> understanding of what they are giving away).
> 

The hide/unhide feature was not built with the oversight use case in mind,
clearly. It wasn't even built for deletion. I don't like starting from the
assumption that we should use it as such, because it means that it gives us an
excuse to lag on building in oversight, and in the meantime cripple the
community's ability to deal with the other kinds of feedback that really need
to be removed.

The number of cases where this scenario would happen are much much smaller than
the amount of really poor feedback or regular vandalism which need to be
removed from the queue. Rather than playing to the edge case here for the tiny
minority of content that merits oversight, I would like us to build in what's
necessary to have a real oversight tool, not misuse something that should be
more widely available and for a different purpose.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38822] Review Wikibase Repo extension for deployment

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38822

--- Comment #7 from Tim Starling  2012-09-27 23:46:01 
UTC ---
(In reply to comment #6)
> Thanks for the feedback, Tim. You are mentioning 5 issues:
> 
> 1) 57KB of site and language data: yes, this has been on our todo list 
> forever.
> I hope we get this moved to a separate resource next week.
> 
> 2) "Wikipedia" should not be hardcoded anywhere - where did you find this?
> Maybe as a default setting, or some such?

In ItemView.php:

/**
 * Returns a list of all the sites that can be used as a target for a site
link.
 *
 * @static
 * @return array
 */
public static function getSiteDetails() {
...
if ( $site->getType() === Site::TYPE_MEDIAWIKI && $site->getGroup() ===
'wikipedia' ) {

The autocomplete feature that this function services also references Wikipedia
in a message (wikibase-error-autocomplete-connection). 

There doesn't seem to be any way to populate the sites table with data other
than the data that comes from meta.wikimedia.org, I had to patch
Utils::insertDefaultSites() to set up my test instance.

populateInterwiki.php also unconditionally references Wikipedia.

> 3) global variables: will do. The convention changed a couple of times it
> seems, causing confusion. Is our main settings array acceptable as
> $egWBSettings, or would it become $wgWBSettings?

I think $wg is the best convention, since if everything uses it, a
configuration UI can drop the prefix. It's almost universal in extensions
deployed to WMF, the only exception is the Contest extension, which is another
one of Jeroen's projects.

> The last two points are really only relevant to the client, even though the
> code is in Wikibase/lib. These issues shouldn't block the deployment of the
> repo, some of the code, like the pollForChanges script, should probably be
> moved. Anyway: 
> 
> 4) That we have to (potentially) update all Wikipedias after a single edit on
> Wikidata lies in the nature of the project, I would think. We are thinking
> about how to make this more efficient by batching updates. I'll try to prepare
> a writeup explaining how we currently envision the percolation of the changes.

Aren't we talking about a deployment in October? It seems like a pretty basic
feature to be starting so late.

> 5) I have worked on remote DB support for ORMTable (and by extension
> ChangesTable) yesterday, see I261a2a31. I have not yet figured out though how
> to correctly set up a LBFactory_multi to test this. Can you help me with that?
> What would a simple setup for two masters (and no slaves) look like?

Here is my LocalSettings.php, if it helps:

http://paste.tstarling.com/p/drrHMe.html

Apologies for the accumulated cruft. It has configuration for various
multi-wiki features. For multiple masters, it would be basically the same,
except with $wgLBFactoryConf having:

'sectionsByDB' => array(
   'enwiki' => 's1',
),
'sectionLoads' => array(
   's1' => array( 'local1' => 1 ),
   'DEFAULT' => array( 'local2' => 1 ),
),

It's possible to run multiple MySQL servers on the same host. There's a helper
script for it called mysqld_multi:

http://dev.mysql.com/doc/refman/5.1/en/mysqld-multi.html

For MediaWiki, it's necessary to use different IP addresses rather than
different ports to separate the instances.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 1] Documentation is out of date, incomplete (tracking)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=1

Bug 1 depends on bug 37977, which changed state.

Bug 37977 Summary: Need better documentation for how to checkout all extensions 
(for developers)
https://bugzilla.wikimedia.org/show_bug.cgi?id=37977

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 37977] Need better documentation for how to checkout all extensions (for developers)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=37977

Krinkle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Krinkle  2012-09-27 23:33:57 UTC ---
Good enough I'd say. Marking fixed.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 36928] the first line of text does not appear

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=36928

--- Comment #4 from bs...@wikimedia.org 2012-09-27 23:29:21 UTC ---
Now the first line appears but there is a slight issue for template inside
template, as a result, some irrelevant template text is showing up as snippet,
I am working on a new way to solve this problem.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40582] 500k logo for Swedish Wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40582

Dereckson  changed:

   What|Removed |Added

   Keywords||patch-in-gerrit, shell
 Status|UNCONFIRMED |ASSIGNED
 CC||dereck...@espace-win.org
 Ever Confirmed|0   |1

--- Comment #1 from Dereckson  2012-09-27 23:26:07 
UTC ---
Taking this bug. Gerrit change 25599.

File has been protected on Commons.

I suggest you discuss the following config change when you will be willing to
come back at the regular logo: use [[sv:File:Wiki.png]] as logo, so you will be
able to change anytime you want without tech intervention.

You should also consider to use the GillSans bold font in the future, for
visual identity consistency.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40137] Create a Wikidata repository for testing outside labs

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40137

Sam Reed (reedy)  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #5 from Sam Reed (reedy)  2012-09-27 23:25:22 
UTC ---
Just to confirm, we need a wildcard SSL certificate for the wikidata.org
domain?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40137] Create a Wikidata repository for testing outside labs

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40137

Rob Lanphier  changed:

   What|Removed |Added

 CC||ct...@wikimedia.org

--- Comment #4 from Rob Lanphier  2012-09-27 23:04:10 UTC 
---
Sam, could you file RT tickets for the pieces that you aren't going to be able
to do?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 31070] Activating Upload Wizard Extension in fa.wiki

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=31070

--- Comment #14 from Huji  2012-09-27 22:56:22 UTC ---
Thanks for the link. It actually is not complete yet. The checkbox on the
bottom of page is left-aligned, it should be right-aligned. Also, the text in
the tab labels is not centered in the label (it is in English version).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40585] New: Unable to change any user preferences if existing wpwatchlistdays value is a non-integer

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40585

   Web browser: ---
 Bug #: 40585
   Summary: Unable to change any user preferences if existing
wpwatchlistdays value is a non-integer
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Unprioritized
 Component: User preferences
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: richardg...@yahoo.com
CC: agarr...@wikimedia.org
Classification: Unclassified
   Mobile Platform: ---


Special:Preferences validation on enwiki is preventing saving new or existing
preferences where the watchlist duration is a non-integer number of days.

In [[Special:Preferences#mw-prefsection-watchlist]] the wpwatchlistdays input
element has the attribute type="number", ensuring client-side validation that
the number of days is numeric.

But the step="..." attribute is not set. For type="number", W3C standards treat
a missing step as implying a step value of 1, so non-integers are
rejected.[note 1][note 2]

But wpwatchlistdays has previously permitted any positive decimal number (up to
prefs-watchlist-days-max). For example, a user could have a valid value of 0.5,
which would show changes within the previous 12 hours.

In addition to preventing new non-integer values from being set, this excessive
validation prevents the saving of ANY changes to user preferences if there is
an existing non-integer value previously saved.

Worse still, on Chrome, when the validation fails, the mw-prefsection-watchlist
tab is not activated if it is not already showing. So someone with an existing
non-integer wpwatchlistdays setting who is attempting to save unrelated changes
to a different prefsection will see no hint as to why their preferences are not
saved. (In Chrome Developer Tools, a JavaScript console message states: "An
invalid form control with name='wpwatchlistdays' is not focusable." But this is
not visible to most users.)

This bug might have arisen now as a result of client-side validation being
activated by the switch to HTML5.

I'm experiencing this using Chrome 22.0.1229.79 and a pre-existing
prefs-watchlist-days user preference of "0.25" (i.e. 6 hours).

The simplest fix would be to add an additional attribute to the input element
to override the default:

  step="any"

It might also be appropriate to specify min and max attributes, but these will
be caught by server-side validation so their absence is not problematic.


[note 1]
http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#number-state-(type=number)
"The default step is 1"

[note 2]
http://dev.w3.org/html5/spec/common-input-element-attributes.html#concept-input-step-default
"If the attribute is absent, then the allowed value step is the default step
multiplied by the step scale factor. Otherwise, if the attribute's value is an
ASCII case-insensitive match for the string "any", then there is no allowed
value step."

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40584] Feedback Page: Add a checklist in Oversight Request flyout

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40584

Fabrice Florin  changed:

   What|Removed |Added

   Priority|Unprioritized   |Highest
   Severity|normal  |major

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40584] New: Feedback Page: Add a checklist in Oversight Request flyout

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40584

   Web browser: ---
 Bug #: 40584
   Summary: Feedback Page: Add a checklist in Oversight Request
flyout
   Product: MediaWiki extensions
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: ArticleFeedbackv5
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: fflo...@wikimedia.org
CC: mmul...@wikimedia.org
Classification: Unclassified
   Mobile Platform: ---


Created attachment 11145
  --> https://bugzilla.wikimedia.org/attachment.cgi?id=11145
Updated request for oversight mockup

As discussed with Philippe Beaudette and Risker, some oversighters have
reported getting too many requests for oversight for article feedback, many of
which are not relevant. It appears that the number for oversight requests has
doubled recently, with over 200 requests in the queue (to date, 300 posts have
been oversighted, and 150 requests have been declined).

To address this issue, we propose to show a checklist of oversightable offenses
in the oversight request flyout, with a prompt asking you to check that list
before you request oversight. This would presumably cut down on the number of
requests, make them more relevant and reduce the overall workload for
oversighters. Note at this point, only admins, reviewers and rollbackers can
request oversight, so this is a limited pool of a few thousand users (called 
'monitors').

Philippe and Risker are going to help us finalize the copy for this checklist,
which could be partly inspired from our current feedback guidelines:
http://en.wikipedia.org/wiki/Wikipedia:Feedback_guidelines

Our help page FAQ could also provide some inspiration:
http://en.wikipedia.org/wiki/Wikipedia:Article_Feedback/Help/Monitors#oversight-request

To get the ball rolling, here some proposed copy we might consider as a
starting point:

"Request Oversight
Before requesting oversight, please check that this post 
contains one of these oversightable offenses:
• private phone numbers
• private email addresses
• pornographic links
• other criteria for oversight

Add a note to explain why you think oversight is needed:

[ text box  ]

(Request oversight button)" 

A mockup is attached, to illustrate how this revised flyout might look.

We will add final copy in a comment on this post, once we have heard back from
Philippe and Risker.

P.S.: If for some reason this checklist does not slow the number of oversight
requests, one more radical option to consider would be to remove the 'Request
oversight' button altogether, and simply have people in the know email
oversighters manually, which will immediately reduce the number of requests. We
would still keep the Oversight button in the UI, so oversight functions would
remain active in this scenario. 

P.P.S.: Personally, I think it is wasteful to ask oversighters to remove email
addresses or phone numbers, when they have no practical way to determine if
they are private or not. Instead, the Wikipedia community might consider
streamlining the oversight policy on these points -- and perhaps remove these
bullet points from the checklist. We could simply ask any monitor to hide posts
that contain such issues. Note that we should no longer see many email
addresses going forward, since the abuse filter now disallows any post that
contains the '@' character.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40577] Parsoid: Possible performance regression on latest master

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40577

--- Comment #2 from Gabriel Wicke  2012-09-27 21:53:07 
UTC ---
The SF page seems to be problematic in the PHP parser too:

[14:14]  bah Fatal error: Maximum function nesting level of '100'
reached, aborting! in /srv/com.leuksman/mw/includes/parser/Preprocessor_DOM.php
on line 985
[14:14]  rendering copy of 'San Francisco'
[14:14]  sigh

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40497] Add editbugs user right to legitimate Bugzilla accounts

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40497

--- Comment #3 from Thehelpfulone  2012-09-27 
21:35:02 UTC ---
(In reply to comment #2)

> Thehelpfulone or some other Bugzilla administrator can generate a list of
> accounts without the "editbugs" user right.

So I can generate a list of users, and a list of users in the "editbugs" group.
We have 16085 users in total, of which 14591 are in the "editbugs" group. That
makes 1494 users that are not in the group. 

The simplest way I can think of adding these users to the group is using the
same regex that allows everyone to set self-whines, which is .* in the User
RegExp field of
 but
I'm not sure how it was done previously - I'll ask around.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40497] Add editbugs user right to legitimate Bugzilla accounts

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40497

--- Comment #2 from MZMcBride  2012-09-27 21:26:58 UTC ---
(In reply to comment #1)
> Not sure either if this issue is a blocker per se.

This bug seems like a classic blocker to me. When people are unable to
effectively and efficiently use Bugzilla, it blocks development work.

>> From some of the comments I've read
> 
> URLs welcome.

https://bugzilla.wikimedia.org/show_bug.cgi?id=29858#c3

Thehelpfulone or some other Bugzilla administrator can generate a list of
accounts without the "editbugs" user right.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40329

--- Comment #25 from Daniel Friesen  
2012-09-27 21:26:03 UTC ---
(In reply to comment #24)
> I have no idea who Strawman is.

Not who, what. It's a type of logical fallacy.
Here's a pretty good description of it:
http://yourlogicalfallacyis.com/strawman

> You say the align attributes need to be removed from the HTML output. I don't
> see why this needs to be done *now*. Because of a future spec that is not even
> finished and that no browser in the world is currently able to fulfill? I say
> the attributes don't need to be removed. They work everywhere. They will work
> everywhere for the next 10 years or more. I say it's stupid to "fix" something
> that is *not* broken. Especially if the *only* thing this "fix" does is to
> actually *break* something.
> 
> Basically you say there is no other way than to stick to a unfinished spec no
> matter if it makes sense or not.

I think I'll make this a bullet-pointed list:
- HTML5 (or as WHATWG calls it "HTML") is a living standard. Completion of the
standard is irrelevant. Individual components of the spec are separate. Some
components are new and in flux, while others are stable and finished
standardization. Removal of presentational attributes is one of those. align is
no longer a standard attribute, that is finished standardization.
- The facts people used to misrepresent to say that HTML5 isn't ready are also
not valid anymore:
http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2022.3F
- Additionally align="" has been deprecated since HTML 4.0. Even if you ignore
current standards and try to use the previous obsolete standards these still
aren't attributes we're supposed to be outputting from our software.
- We use HTML5. This whole discussion about whether HTML5 is finished or not is
pointless. HTML5 is the standard we are using RIGHT NOW to output MediaWiki
markup. Whether something is valid or invalid in a spec we are not using is
irrelevant.

> Like it's a law and not a recommendation.
> 
> I'm not a lawyer. I'm a coder.
> 
> You say you need to remove "invalid" attributes from the output. But at the
> same time you are accepting the *same* invalid attributes as input? This is
> confusing. When I use an align attribute in my code I expect it to work
> according to the spec. Like it did for many years. Now you introduced your own
> spec where it started to *not* work in some cases. This is confusing as hell.
> Till last week it was *my* decision what my code did. Now *you* decide that 
> the
> same code is invalid in some cases but still valid in other cases.

WikiText is not HTML, that's a simple fact you'll have to understand. HTML is
consumed by browsers and it's format is defined by the HTML standard. While
WikiText is consumed (and written) by the MediaWiki parser and human users who
do not follow standards. For a user trying to insert a centered table in the
middle of the page {| align=center makes perfect sense to create a centered
table even though is the wrong way to do it in HTML (which they probably won't
know). So it makes perfect sense to take that as an indication to create a
centered table. Which in CSS means to apply style="margin-left: 0;
margin-right: 0;" as we do now.

> You *dropped* a feature. Why? Where is the documentation for this?
> Where was the "consider changing your templates" warning a year ago?
> Where is the discussion were the community decided to removed this part of 
> the WikiText feature set?

As with everything we change 1.19's RELEASE-NOTES included the introduction of
presentational attribute sanitization.
At the time of introduction neither the  nor nested block quirks were
known so there was no need for any mass notification about incompatibilities
since it was supposed to be compatible.
The table float bug was caused by the relevant info being buried in a separate
section of the spec. After the table float bug was discovered someone tried
fixing it. Which caused bug 40306 since the committer made a mistake and made
that special case apply to more than the one tag it applies to. Then recently
that bug got fixed and deployed. Now the one single remaining issue is the
nested block align quirk.
;) Btw, here's a fun fact. HTML4 does not even appear to specify that
behaviour. In fact it has examples using text-align as a replacement for align.

It's been discussed on the mailing list multiple times. But we don't go asking
for community approval for each and every single change we make for the
software. It's ridiculously unscalable. Nothing would get done.

> Why only this part? Why not simply remove all of the invalid stuff? Why not 
> the
>  garbage? This would be way less confusing. A lot of stuff will break
> but everybody would *know* why. Even people that were not involved in the
> discussion.

Right now the Sanitizer only supports attribute sanitization. We don't have a
way to sanitize whole elements yet. To do that we need to add a new sanitizer
api f

[Bug 35792] SUL account recently created with no attached or unattached accounts, and undeletable

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=35792

Rob Lanphier  changed:

   What|Removed |Added

   Priority|High|Normal

--- Comment #16 from Rob Lanphier  2012-09-27 21:10:44 UTC 
---
This has been a background task for Chris for a while.  Until we can figure out
a reliable repro case, it's going to be difficult to diagnose how to fix this. 
Chris is going to look into ways we can log failures and possibly catch this in
the act.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40511] Special:FeedbackDashboard 'hide' function should be extended to all autoconfirmed editors

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40511

--- Comment #8 from Steven Walling  2012-09-27 21:07:54 
UTC ---
https://gerrit.wikimedia.org/r/#/c/25586/

Courtesy Patrick.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 39877] X-Frame-Options: DENY breaks UploadWizard in IE8, consider using SAMEORIGIN instead

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=39877

Rob Lanphier  changed:

   What|Removed |Added

   Priority|Unprioritized   |High

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40511] Special:FeedbackDashboard 'hide' function should be extended to all autoconfirmed editors

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40511

--- Comment #7 from Steven Walling  2012-09-27 21:04:41 
UTC ---
(In reply to comment #3)
> Merged. Expected to appear in 1.20wmf13.

In case he's not reading, I'll ask Siebrand to unmerge for now.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40511] Special:FeedbackDashboard 'hide' function should be extended to all autoconfirmed editors

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40511

--- Comment #6 from Philippe Beaudette  2012-09-27 
20:53:21 UTC ---
Actually, legal has been deeply involved in oversight and content removal here.
:)

I've asked Howie to take a look.

Also, I was under the impression that any community member could weigh in on
these bugs, Steven.  I see this as James weighing in on a bug.  I'm a little
confused as to why you're discouraging that, but maybe we'll discuss that
offline.  :-)

Everyone, let's have the proverbial tea, shall we?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 37977] Need better documentation for how to checkout all extensions (for developers)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=37977

--- Comment #8 from Sam Reed (reedy)  2012-09-27 20:46:42 
UTC ---
https://www.mediawiki.org/w/index.php?title=Git&diff=588079&oldid=586833

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40583] New: Allow ssh access to willow.toolserver.org and nightshade.toolserver.org

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40583

   Web browser: ---
 Bug #: 40583
   Summary: Allow ssh access to willow.toolserver.org and
nightshade.toolserver.org
   Product: Wikimedia Labs
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: General
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: dan...@schwen.de
CC: benap...@gmail.com, rlan...@gmail.com
Classification: Unclassified
   Mobile Platform: ---


Currently ssh access to the login nodes of the toolserver cluster is blocked.
Pleas add an exception for willow.toolserver.org and nightshade.toolserver.org

This wil make migration to labs easier and will allow tunneling of database
connections for teting purposes to get migrated applications running on labs.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40582] 500k logo for Swedish Wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40582

rasmu...@live.se changed:

   What|Removed |Added

   Severity|normal  |enhancement

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40582] 500k logo for Swedish Wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40582

rasmu...@live.se changed:

   What|Removed |Added

   Severity|enhancement |normal

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40582] 500k logo for Swedish Wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40582

rasmu...@live.se changed:

   What|Removed |Added

URL|sv.wikipeida.org|http://sv.wikipedia.org/wik
   ||i/

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40511] Special:FeedbackDashboard 'hide' function should be extended to all autoconfirmed editors

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40511

--- Comment #5 from Steven Walling  2012-09-27 20:39:13 
UTC ---
(In reply to comment #4)
> 
> Sadly I think this is pretty high risk right now. We don't currently have any
> other way to delete moodbar comments, the hide function is the ONLY way, after
> that the next escalation is to manually edit the database.

James,

I'm sorry but you're completely wrong here. 

There has _never_ been deletion of any kind (page deletion, revdeletion, or
oversight) in FeedbackDashboard. Hiding is not a substitute for deletion, and
should not be treated as such. Unhiding feedback is an option at any time when
something is hidden, and there is no log of what has been hidden. There is no
policy which outlines that hiding is equivalent to deletion, and if you look at
the original bugs I linked to, opening hiding to autoconfirmed editors has long
been considered for this very reason. 

> 
> Copying in Philippe because I know he's worked with the moodbar team before on
> some of the privacy and OS issues and will have a better understanding of
> legals needs.

Remember that feedback, unlike wiki pages, does not appear in the wiki anywhere
other than the Special page, and is not a part of XML dumps or accessible via
the API. 

This is why there was no deletion or oversight built into the tool to begin
with. If legal would like to request to features engineering that we need these
features in order to stay protected, they should do that. But it is not up to
legal or you James to make decisions on features or associated permissions.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40511] Special:FeedbackDashboard 'hide' function should be extended to all autoconfirmed editors

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40511

James Alexander  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||jalexan...@wikimedia.org,
   ||pbeaude...@wikimedia.org
 Resolution|FIXED   |

--- Comment #4 from James Alexander  2012-09-27 
20:31:08 UTC ---
I'm reopening this for now because I'm a bit concerned both about the change
and the implementation. 

Sadly I think this is pretty high risk right now. We don't currently have any
other way to delete moodbar comments, the hide function is the ONLY way, after
that the next escalation is to manually edit the database. This leads us to
some major issues and the hidden feedback includes things that would normall be
oversighted such as libel or personal information. This is problematic for even
sysops to have access to but, I believe, has been a compromise until a full OS
option is available. In my opinion it seems absolutely unacceptable to have
autoconfirmed users able to view and undelete at the very least without legal
approval and a much comprehensive community consensus (with them having a full
understanding of what they are giving away).

I'm also hesitant about the implementation. This shouldn't be in moodbar.php,
it's a local change that even if implemented should be in commonsettings, not
in the defaults. 

Copying in Philippe because I know he's worked with the moodbar team before on
some of the privacy and OS issues and will have a better understanding of
legals needs.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 37643] Session may not be started for non-logged-in API edits, causing captcha to fail

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=37643

Chris Steipp  changed:

   What|Removed |Added

 CC||cste...@wikimedia.org

--- Comment #4 from Chris Steipp  2012-09-27 20:26:32 
UTC ---
Brad, can you add some details about the use case that you're seeing fail?

It's probably fine, but I would hate to start any sessions that aren't needed,
since that affects caching. But if there are a few cases where we are missing
sessions, then this is probably a good way to set it.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40582] 500k logo for Swedish Wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40582

rasmu...@live.se changed:

   What|Removed |Added

URL||sv.wikipeida.org

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40582] New: 500k logo for Swedish Wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40582

   Web browser: ---
 Bug #: 40582
   Summary: 500k logo for Swedish Wikipedia
   Product: Wikimedia
   Version: unspecified
  Platform: All
OS/Version: All
Status: UNCONFIRMED
  Severity: enhancement
  Priority: Unprioritized
 Component: Site configuration
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: rasmu...@live.se
CC: benap...@gmail.com, wikimedia.b...@snowolf.eu
Classification: Unclassified
   Mobile Platform: ---


Can you please change the logo at the top of the sidebar to this one:

http://commons.wikimedia.org/w/index.php?title=File:Wikipedia-logo-v2-sv-500k.svg&page=1

Discussion:

http://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen#Bokm.C3.A4ssa_och_50

We have just passed the half-million article milestone.

Thanks

Rasmus 28@sv.wikipedia

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40477] Enable Extension:Education Program on English Wikipedia (with new user rights configuration)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40477

Sage Ross  changed:

   What|Removed |Added

   Keywords||shell

--- Comment #12 from Sage Ross  2012-09-27 19:39:41 UTC ---
The RfC has been formally closed now by an uninvolved admin, so we can turn
this on as soon as it's technically ready.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 39449] IPv6 editors have no AbuseLog

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=39449

Mormegil  changed:

   What|Removed |Added

   Keywords||ipv6

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40581] New: Article feedback truncates IPv6 addresses of users

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40581

   Web browser: ---
 Bug #: 40581
   Summary: Article feedback truncates IPv6 addresses of users
   Product: MediaWiki extensions
   Version: unspecified
  Platform: All
   URL: http://en.wikipedia.org/wiki/Special:ArticleFeedbackv5
/Karel_(programming_language)/406887
OS/Version: All
Status: NEW
  Keywords: ipv6
  Severity: major
  Priority: Unprioritized
 Component: ArticleFeedbackv5
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: morme...@centrum.cz
CC: mmul...@wikimedia.org
Classification: Unclassified
   Mobile Platform: ---


The article feedback extension stores IP addresses of anonymous users in a
32-character field (af_user_ip varchar(32) NULL), possibly assuming the IP
address is normalized to a colon-less form. Which is not the case, and a
40-character field is needed (like e.g. in recentchanges.rc_ip in core).

Currently, in longer IPv6 addresses, the tail is cut off, see e.g. the linked
URL showing a nonsensical “2001:da8:201:1056:818f:62c9:a132”.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40579] Update Sanitizer to support replacement of whole elements instead of just attributes.

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40579

--- Comment #2 from Daniel Friesen  
2012-09-27 19:23:08 UTC ---
(In reply to comment #1)
> , , and  work in existing browsers, there's no need to
> remove them.

This is part of $wgCleanupPresentationalAttributes. Right now for a purely
technical reason we transform attributes that were removed from HTML but not
elements that were removed from html.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40579] Update Sanitizer to support replacement of whole elements instead of just attributes.

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40579

--- Comment #1 from Brion Vibber  2012-09-27 19:19:42 UTC 
---
, , and  work in existing browsers, there's no need to
remove them.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40576] Add user contribution links to existing user conflicts

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40576

--- Comment #4 from Steven Walling  2012-09-27 19:17:11 
UTC ---
(In reply to comment #3)
> $message .= '' . wfMsg( 'antispoof-conflict-item
> ', $simUser ) . '';
> $message .= '' . wfMessage( 'antispoof-conflict-
> item', $simUser )->escaped() . '';
> 
> 
> Technically, this isn't actually a bug... And should probably be swapped to a
> feature request to have the contribution links...

IMO, I don't think the contribution links provide clear value. The message just
needs to tell the user that a similar name already exists, not tell them what
the person has done.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40576] Add user contribution links to existing user conflicts

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40576

Sam Reed (reedy)  changed:

   What|Removed |Added

Summary|Antispoof escapes message   |Add user contribution links
   |that were changed to work   |to existing user conflicts
   |in an unsupported way by|
   |enwiki, so they now don't   |
   |work|
   Severity|minor   |enhancement

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40013] Connectivity interferes with saved articles (saved pages do not work offline)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40013

--- Comment #9 from Brion Vibber  2012-09-27 19:11:36 UTC 
---
Ok, I can reproduce on Galaxy Nexus / 4.1 the behavior in comment 8. Very
strange.

iOS 6 behavior in comment 7 I can also reproduce -- article saves, but the list
shows up blank. This is with full connectivity the whole time Force-closing
the app and restarting it makes the updated list show, however... and now
things show up in the list without a restart.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40576] Antispoof escapes message that were changed to work in an unsupported way by enwiki, so they now don't work

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40576

Sam Reed (reedy)  changed:

   What|Removed |Added

Summary|Antispoof displaying|Antispoof escapes message
   |parameter   |that were changed to work
   ||in an unsupported way by
   ||enwiki, so they now don't
   ||work

--- Comment #3 from Sam Reed (reedy)  2012-09-27 19:09:37 
UTC ---
$message .= '' . wfMsg( 'antispoof-conflict-item
', $simUser ) . '';
$message .= '' . wfMessage( 'antispoof-conflict-
item', $simUser )->escaped() . '';


Technically, this isn't actually a bug... And should probably be swapped to a
feature request to have the contribution links...

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40580] Show small notice if user tries to tag/nominate a very recently created page

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40580

--- Comment #1 from Erik Moeller  2012-09-27 19:02:58 UTC 
---
(NB - This suggestion is based on a comment by User:Alanl on 
https://en.wikipedia.org/wiki/Wikipedia_talk:Page_Curation#Sort_by )

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40580] New: Show small notice if user tries to tag/nominate a very recently created page

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40580

   Web browser: ---
 Bug #: 40580
   Summary: Show small notice if user tries to tag/nominate a very
recently created page
   Product: MediaWiki extensions
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Unprioritized
 Component: PageTriage
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: e...@wikimedia.org
CC: fflo...@wikimedia.org, rkald...@wikimedia.org
Classification: Unclassified
   Mobile Platform: ---


To reduce biteyness toward new users who are still working on a page, I would
suggest showing a small indicator text below the headings "Add tags" and "Mark
for Deletion" in the curation toolbar, like this:

Note: This page is only x minutes old. The user may still be working on it, so
consider waiting before tagging it if the issues are fixable.

The text could obviously be improved - but the point would be to create a small
affordance to give people time to let articles develop.

I would suggest showing this notice only if x is smaller than, say, 60 minutes.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40315] Highlight trash icon in Curation Toolbar when page is nominated for deletion

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40315

Ryan Kaldari  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Ryan Kaldari  2012-09-27 18:41:46 
UTC ---
Fixed in https://gerrit.wikimedia.org/r/#/c/25523/

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40541] $wgSecureLogin does not redirect to http if wpStickHTTPS is unchecked

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40541

Tyler Romeo  changed:

   What|Removed |Added

   Keywords||patch-in-gerrit

--- Comment #6 from Tyler Romeo  2012-09-27 18:40:29 UTC 
---
https://gerrit.wikimedia.org/r/25530

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40013] Connectivity interferes with saved articles (saved pages do not work offline)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40013

--- Comment #8 from Jon  2012-09-27 18:31:37 UTC ---
When I open the Wikipedia app with no internet connection, unless it was
already open (in my task list), the saved pages list shows up blank.

Please write your e-mail above this line.
User-agent: Mozilla/5.0 (Linux; Android 4.1.1; Nexus 7 Build/JRO03D)
AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166  Safari/535.19

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 4557] tag is deprecated in HTML5; normalize to in parser/sanitizer

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=4557

Daniel Friesen  changed:

   What|Removed |Added

 Blocks||40579

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 19719] HTML5 (tracking)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=19719

Daniel Friesen  changed:

   What|Removed |Added

 Depends on||40579

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 209] XHTML compliance (tracking)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=209

Daniel Friesen  changed:

   What|Removed |Added

 Depends on||40579

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40579] Update Sanitizer to support replacement of whole elements instead of just attributes.

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40579

Daniel Friesen  changed:

   What|Removed |Added

 Blocks||209, 19719
 Depends on||4557

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40578] Disabling "Privacy Policy" and "Disclaimers" by setting content to single minus not working

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40578

--- Comment #2 from Roy Verrips  2012-09-27 18:28:58 UTC ---
Apologies for not adding it in the initial report ... 
http://www.mediawiki.org/wiki/Manual:FAQ in the section "How do I change the
interface text?"

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40541] $wgSecureLogin does not redirect to http if wpStickHTTPS is unchecked

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40541

--- Comment #5 from Chris Steipp  2012-09-27 18:27:27 
UTC ---
I just added a patch for the cookie handling, that I think will allow insecure
links/redirects to work. Gerrit 25525.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40577] Parsoid: Possible performance regression on latest master

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40577

--- Comment #1 from Gabriel Wicke  2012-09-27 18:26:53 
UTC ---
[[:en:Barack Obama]] went from 58 seconds a few weeks ago to 76 seconds on my
laptop, so performance seems to have deteriorated quite a bit.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40579] New: Update Sanitizer to support replacement of whole elements instead of just attributes.

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40579

   Web browser: ---
 Bug #: 40579
   Summary: Update Sanitizer to support replacement of whole
elements instead of just attributes.
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: Parser
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: mediawiki-b...@nadir-seen-fire.com
Classification: Unclassified
   Mobile Platform: ---


Currently our Sanitizer is only capable of sanitizing attributes. We cannot
sanitize whole tags (besides just making them not work) so we can't clean up
invalid elements like , , and .

We need to update our Sanitizer code so we can also substitute whole tags. And
we'll need to make sure we also replace the closing tag.

This will probably mean creating a new set of functions to call, deprecating
the old ones, and then fixing the parser to use the new functions. This
involves whole element replacement so it might not be as trivial to do in the
parser as attributes were.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40578] Disabling "Privacy Policy" and "Disclaimers" by setting content to single minus not working

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40578

--- Comment #1 from Sam Reed (reedy)  2012-09-27 18:25:03 
UTC ---
Which documentation? Link?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40578] New: Disabling "Privacy Policy" and "Disclaimers" by setting content to single minus not working

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40578

   Web browser: ---
 Bug #: 40578
   Summary: Disabling "Privacy Policy" and "Disclaimers" by
setting content to single minus not working
   Product: MediaWiki
   Version: 1.19.2
  Platform: Macintosh
OS/Version: Mac OS X 10.8
Status: UNCONFIRMED
  Severity: normal
  Priority: Unprioritized
 Component: Special pages
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: r...@verrips.org
Classification: Unclassified
   Mobile Platform: ---


I've followed the documentation stating to replace the content of "Privacy
Policy" page (:Privacy_policy) and "Disclaimers" page (:General_disclaimer)
with a single minus to remove them from the footer line, but this is not
working for me.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 4557] tag is deprecated in HTML5; normalize to in parser/sanitizer

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=4557

--- Comment #8 from Daniel Friesen  
2012-09-27 18:21:07 UTC ---
Technically HTML5 actually defines  as "The s element represents contents
that are no longer accurate or no longer relevant." rather than as a
strike-through. But that probably doesn't really matter since HTML4 defined
both  and  as strike-through. So whether you used  or 
HTML5 still changes the semantics.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40577] Parsoid: Possible performance regression on latest master

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40577

Gabriel Wicke  changed:

   What|Removed |Added

   Keywords||performance
   Priority|Unprioritized   |Normal

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40577] New: Parsoid: Possible performance regression on latest master

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40577

   Web browser: ---
 Bug #: 40577
   Summary: Parsoid: Possible performance regression on latest
master
   Product: Parsoid
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: JS/General
AssignedTo: gwi...@wikimedia.org
ReportedBy: gwi...@wikimedia.org
CC: ssas...@wikimedia.org
Classification: Unclassified
   Mobile Platform: ---


[[:en:San Francisco]] takes 151 seconds to render, which is way too long.

We should check if this is a regression (by trying with an earlier version) and
do some profiling to identify the expensive bits in this page.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40576] Antispoof displaying parameter

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40576

Sam Reed (reedy)  changed:

   What|Removed |Added

 CC||s.mazel...@xs4all.nl
Summary|Broken HTML on English  |Antispoof displaying
   |Wikipedia account creation  |parameter
   |form error  |
   Severity|normal  |minor

--- Comment #2 from Sam Reed (reedy)  2012-09-27 18:18:08 
UTC ---
Errr, I retract that, slightly.

'antispoof-conflict-item' => '$1', # do not translate or duplicate this message
to other languages

$message .= '';
foreach ( $conflicts as $simUser ) {
$message .= '' . wfMessage( 'antispoof-conflict-item', $simUser
)->escaped() . '';
}

Mix of Siebrands change, and the enwiki customisation of said message

https://en.wikipedia.org/w/index.php?title=MediaWiki:Antispoof-conflict-item&action=edit

$1 (contribs)

'antispoof-conflict-item' => '$1', # do not translate or duplicate this message
to other languages

Probably makes most sense to fix this message upstream, and change the code to
support the desired output. Maybe.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40576] Broken HTML on English Wikipedia account creation form error

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40576

Sam Reed (reedy)  changed:

   What|Removed |Added

   Keywords||i18n

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40576] Broken HTML on English Wikipedia account creation form error

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40576

Sam Reed (reedy)  changed:

   What|Removed |Added

 CC||soxre...@gmail.com
  Component|User login  |AntiSpoof
Product|MediaWiki   |MediaWiki extensions

--- Comment #1 from Sam Reed (reedy)  2012-09-27 18:13:31 
UTC ---
'antispoof-conflict-top'  => 'The name "$1" is too similar to {{PLURAL:$2|the
existing account|the following $2 accounts}}:',

$message = wfMessage( 'antispoof-conflict-top', $name )->numParams(
$numConflicts )->escaped();


I'm guessing the message functions are called wrongly..

Siebrands fault from https://gerrit.wikimedia.org/r/#/c/22363/

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40576] New: Broken HTML on English Wikipedia account creation form error

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40576

   Web browser: ---
 Bug #: 40576
   Summary: Broken HTML on English Wikipedia account creation form
error
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: User login
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: swall...@wikimedia.org
Classification: Unclassified
   Mobile Platform: ---


Created attachment 11144
  --> https://bugzilla.wikimedia.org/attachment.cgi?id=11144
Error screenshot

See the attached file. 

It looks like there is some error output which is broken. When you attempt to
create a username that is too close to an existing username (e.g. one character
different) the error shows the associated user and links to their contribs. The
contributions link is currently broken.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40575] Allow creation of multiple accounts during workshop

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40575

--- Comment #3 from Al-Scandar Solstag  2012-09-27 
17:55:54 UTC ---
Thank you =)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 37615] Article Feedback 5 - Abuse filter issues for common vandalism

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=37615

Fabrice Florin  changed:

   What|Removed |Added

Summary|Article Feedback 5 - Abuse  |Article Feedback 5 - Abuse
   |filter fixes|filter issues for common
   ||vandalism

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 37615] Article Feedback 5 - Abuse filter fixes

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=37615

--- Comment #7 from Fabrice Florin  2012-09-27 17:48:05 
UTC ---
Thanks, Matthias!

I really appreciate your rapid turn-around on this issue.

I just tested all 5 filters in a variety of user modes, and they seem to be
doing their job well. All the swear words I entered were disallowed as
intended, without apparent performance issues. Nicely done!

I just tested these filters in these different user modes, with these results:
- anonymous reader (disallows all foul words)
- registered 'non-autoconfirmed' editor (disallows all foul words)
- autoconfirmed editor (allows all foul words)

I can confirm that the filter only works when I am logging as a
non-auto-confirmed editor, not when I am an auto-confirmed editor. This seems
reasonable, since 98% of the feedback comes from anonymous users. But we may
need to revisit this rule if we find that we get foul language from
auto-confirmed editors.

At this time, none of the filters appear to be hitting the 5% limit for
automatic disabling -- and they seem to only add minimal load on the abuse
fiter extension (e.g.. for #496: 'Of the last 9,056 actions, this filter has
matched 12 (0.13%). On average, its run time is 1.15 ms, and it consumes 215
conditions of the condition limit.').

Also, what does the '(https?|ftp)://)\S{30,}' expression mean in filter 497? Is
it trying to remove any link that includes 'https://' ? (didn't seem to work
for me).

Thanks again for taking care of this important issue, which we have been
wanting to fix for a long time now. If it continues to perform well, I expect
that this could make a big change in reducing the amount of inappropriate
feedback we get from this tool -- and most importantly, reducing the workload
for editors who monitor this feed.

I also want to take this opportunity to thank filter editors like Reaper
Eternal and Sole Soul for all their great work and patient advice, which played
a key role in solving this issue. Much appreciated, you guys!

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 13631] Wikimedia should become an OpenID provider

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=13631

--- Comment #16 from Tyler Romeo  2012-09-27 17:31:46 UTC 
---
(In reply to comment #15)
> (In reply to comment #14)
> > [...]
> > That still doesn't change my point. OAuth is the appropriate tool for 
> > external
> > applications to verify a user's identity and then perform operations on that
> > user's behalf.
> 
> The point of TUSC isn't necessarily to perform operations on a user's behalf,
> but for example just to ensure their consent to aggregate personal data as
> required by https://wiki.toolserver.org/view/Rules#Privacy_Policy.  That's a
> subset of what OAuth offers, but can very well be accomplished with OpenID.

But that's still something that should be done with OAuth. You may not be doing
stuff on behalf of the user, but you are accessing the user's data, which is a
permission that can be granted using OAuth. OpenID is supposed to be used for
single sign-on.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40575] Allow creation of multiple accounts during workshop

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40575

Krenair  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Krenair  2012-09-27 17:17:03 UTC ---
Merged by Demon.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40575] Allow creation of multiple accounts during workshop

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40575

Krenair  changed:

   What|Removed |Added

 CC||kren...@gmail.com

--- Comment #1 from Krenair  2012-09-27 17:11:51 UTC ---
Gerrit change 25514

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38273] Tidy occasionally isn't executed

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38273

Bartosz Dziewoński  changed:

   What|Removed |Added

   Keywords|shell   |patch, patch-need-review
  Component|General/Unknown |Maintenance scripts
Product|Wikimedia   |MediaWiki
   Target Milestone|--- |1.20.0 release

--- Comment #28 from Bartosz Dziewoński  2012-09-27 
17:10:52 UTC ---
Comment 23 contains what could be a patch. Could somebody competent look at
this?

(Updating component and project.)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40575] Allow creation of multiple accounts during workshop

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40575

Al-Scandar Solstag  changed:

   What|Removed |Added

   Keywords||shell

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40575] New: Allow creation of multiple accounts during workshop

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40575

   Web browser: ---
 Bug #: 40575
   Summary: Allow creation of multiple accounts during workshop
   Product: Wikimedia
   Version: wmf-deployment
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: Site configuration
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: sols...@member.fsf.org
CC: benap...@gmail.com, wikimedia.b...@snowolf.eu
Classification: Unclassified
   Mobile Platform: ---


Ni!

IP address 177.32.49.25 will host a Wikimedia editing workshop today, and might
need to create a large number of accounts between (UTC) today 18:00 and
tomorrow 2:00.

Workshop info, in Portuguese:

http://pt.wikiversity.org/wiki/Portal:Cidades_Sustentáveis

Thanks and sorry for the late request,

Solstag

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 13631] Wikimedia should become an OpenID provider

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=13631

--- Comment #15 from Tim Landscheidt  2012-09-27 
16:57:36 UTC ---
(In reply to comment #14)
> [...]
> That still doesn't change my point. OAuth is the appropriate tool for external
> applications to verify a user's identity and then perform operations on that
> user's behalf.

The point of TUSC isn't necessarily to perform operations on a user's behalf,
but for example just to ensure their consent to aggregate personal data as
required by https://wiki.toolserver.org/view/Rules#Privacy_Policy.  That's a
subset of what OAuth offers, but can very well be accomplished with OpenID.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40137] Create a Wikidata repository for testing outside labs

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40137

--- Comment #3 from denny vrandecic  2012-09-27 
16:56:01 UTC ---
And CentralAuth to a new second level domain.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38273] Tidy occasionally isn't executed

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38273

--- Comment #27 from Redrose64  2012-09-27 16:51:47 
UTC ---
Also mw29

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40137] Create a Wikidata repository for testing outside labs

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40137

--- Comment #2 from denny vrandecic  2012-09-27 
16:27:59 UTC ---
set up wikidata.org with SSL and DNS and everything else that is needed, but
keep it closed first

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 12663] ImageMagick in SafeMode

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=12663

--- Comment #5 from Nubie Riox  2012-09-27 16:19:49 UTC ---
FYI (sorry for spamming), I've also tried the solutions indicated in this talk,
including the patch (which comes from mediawiki 1.20.x ?!) and the workaround
from the last reply (applied with And without the patch):

http://www.mediawiki.org/wiki/Thread:Talk:MediaWiki_1.19/Thumbnails_didn't_work_since_Update_to_1.19/reply_(45)

Thumbnails are still not working, keeping safe_mode enabled.

However, thanks for your attention.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40552] Rename globals $wb* to $wgWB* and $egWB* to $wgWB* (2)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40552

Aude  changed:

   What|Removed |Added

 CC||aude.w...@gmail.com

--- Comment #1 from Aude  2012-09-27 16:18:04 UTC ---
https://gerrit.wikimedia.org/r/#/c/25511/ for $wbStores and $wbcStores

still need to update the $egWB* stuff

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 39793] placeholder text color in search bar in Firefox 15 is black instead of gray

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=39793

Krinkle  changed:

   What|Removed |Added

   Keywords|patch-in-gerrit |
 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.20.0 release

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40541] $wgSecureLogin does not redirect to http if wpStickHTTPS is unchecked

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40541

--- Comment #4 from Tyler Romeo  2012-09-27 15:54:24 UTC 
---
Well, unfortunately it's not that easy a fix. I'm working on it now, but the
big problem is that say, for example, a hook injects HTML into the login
complete page. The redirect does not occur automatically, and instead the user
is given a sort of "login success" page and a link returning to where they
were. The returnto link is added using OutputPage::addReturnTo, which in turn
uses the Linker, and in that workflow there is no way to change the protocol.
Right now I'm working on adding an option to the Linker so that you can force
the link to have a certain protocol.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 13631] Wikimedia should become an OpenID provider

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=13631

--- Comment #14 from Tyler Romeo  2012-09-27 15:51:32 UTC 
---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #0)
> > > Too facilitate verification of a Wikimedia user for external tools 
> > > without the
> > > need to give the password to that tool, Wikimedia should become an OpenID
> > > provider.
> 
> > (In reply to comment #6)
> > > This would also greatly benefit the Toolserver. Right now, toolserver 
> > > tools
> > > can't be personalized without some major effort, and the hassle for users 
> > > to
> > > create an extra account. Using OpenID would also allow simple 
> > > implementation of
> > > opt-in services, which are using nasty workarounds right now. -- 
> 
> > OpenID is not the proper tool for either of these. OpenID is made so that 
> > users
> > can use their identity on one site to log in to another site. If our aim to
> > allow users to let external tools access their account without a password,
> > OAuth would be the thing to enable.
> > [...]
> 
> That's not what Daniel wrote.  The aim is to allow external tools to verify
> that a user has authority over a wiki account.  Take a look at
> http://toolserver.org/~magnus/tusc.php to understand what hoops users now have
> to jump through.

That still doesn't change my point. OAuth is the appropriate tool for external
applications to verify a user's identity and then perform operations on that
user's behalf.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40574] New: API: param generatexml needs wikitext

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40574

   Web browser: ---
 Bug #: 40574
   Summary: API: param generatexml needs wikitext
   Product: MediaWiki
   Version: 1.20-git
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: API
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: duplicate...@googlemail.com
CC: bryan.tongm...@gmail.com, roan.katt...@gmail.com,
s...@reedyboy.net
Classification: Unclassified
   Mobile Platform: ---


When using prop=revisions&rvgeneratexml= the param rvprop with value content
must be set

when using action=parse&generatexml= the param prop with value wikitext must be
set

This should mention on the generated help page. Thanks.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38273] Tidy occasionally isn't executed

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38273

--- Comment #26 from Redrose64  2012-09-27 15:36:40 
UTC ---
A new one: srv200 did this too

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40523] Properly escape output

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40523

denny vrandecic  changed:

   What|Removed |Added

 Blocks||40573

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l