[Bug 14267] The tab on the main page should read main page, not article

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=14267

Daniel Friesen mediawiki-b...@nadir-seen-fire.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #23 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 
2011-01-14 08:55:21 UTC ---
Fixed in r80240.

You can optionally define a 'mainpage-nstab' message to override the tab's text
for the mainpage.
I didn't like 'nstab-mainpage' because it would create an edge case where if
someone created a MainPage: namespace then it's tab and the mainpage's tab
would be shared in a conflicting way. After throwing around some names Tim
suggested 'mainpage-nstab' like the 'mainpage-description' we have.

I had an interesting discussion in irc with Tim on the parser function idea
too. The idea of a {{DISPLAYTITLE}} style parser function to override the tab
text is an interesting idea, and someone is free to try implementing it as
well, it's a much more generic and widely useful feature than the simple
mainpage tab override. But after thinking about how one would implement that, I
ended up settling on the fact that while DISPLAYTITLE works nicely in the
parser output because you only view the page title on that page. But the main
page tab is displayed on the page itself, on it's talkpage, and on all the
other things like delete, and move (in 1.18 Move correctly keeps the page's
tabs). So if we wanted to correctly display the tab we'd end up having to fetch
the parser output (and potentially parse) the article content when we view a
talkpage, the edit page, the move page, etc... just to see if the page defined
some custom ui tab text (which on most wikis will only be 1 page or none at
all). Tim suggested instead we just make it so you'll have to edit
Talk:Main_Page to use the same parserfunction to get the same view... though
that would leave edit, move, etc... with an inconsistent ui in regards to
mainpage tab text.

In any case, open a new bug if you want a more generic parser function to
control the text of a namespace tab. This specific bug should be fixed 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 26724] New: TalkHere throws a fatal error when $wgMaxCredits in not 0

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26724

   Summary: TalkHere throws a fatal error when $wgMaxCredits in
not 0
   Product: MediaWiki extensions
   Version: any
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: [other]
AssignedTo: brightb...@gmail.com
ReportedBy: ialex.w...@gmail.com


When using TalkHere extension with $wgMaxCredits different than 0, the
following error happens:

Catchable fatal error: Argument 1 passed to Credits::getCredits() must be an
instance of Article, instance of TalkHereArticle given, called in
includes/SkinTemplate.php on line 386 and defined in includes/Credits.php on
line 59

-- 
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 26724] TalkHere throws a fatal error when $wgMaxCredits in not

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26724

Daniel Kinzler brightb...@gmail.com changed:

   What|Removed |Added

 CC||brightb...@gmail.com
 AssignedTo|brightb...@gmail.com|wikibugs-l@lists.wikimedia.
   ||org

--- Comment #1 from Daniel Kinzler brightb...@gmail.com 2011-01-14 10:55:00 
UTC ---
What the hell is Credits?

Anyway, I suppose it'S a bug in Credits, not TalkHere: From what I gether,
Credits::getCredits() checks that the argument is an instance of Article,
instead of checking if it's an *compatible* with the Article class. It should
use instanceof instead getclass.

I can't do much about it from my side, so i'm assigning it back to the 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 26725] New: Renaming the Aramaic (arc) Wikipedia to the Syriac (syc) Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26725

   Summary: Renaming the Aramaic (arc) Wikipedia to the Syriac
(syc) Wikipedia
   Product: Wikimedia
   Version: unspecified
  Platform: All
   URL: http://www.arc.wikipedia.org
OS/Version: All
Status: NEW
  Keywords: shell
  Severity: enhancement
  Priority: Normal
 Component: Language setup
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: sume...@hotmail.com


Wikipedia has many projects under several languages. These languages are linked
to ISO-codes (International Organisation for Standardization). Our wikipedia
works under the name of Aramaic, and the ISO code of arc. According to ISO,
this arc is the official Aramaic from 700 till 300 BC. Since we all contribute
in one specific Aramaic dialect thats suits both Western and Eastern Syriac
speakers, that is Classical Syriac, the name of the Aramaic Wikipedia must be
changed to the more proper name the Syriac Wikipedia. By also changing the name
and code (from arc to syc), we will match the ISO code that is given to this
specific Aramaic dialect (syc stands for Classical Syriac). 

Here is the link where the community gave its approval for renaming the wiki:
http://arc.wikipedia.org/wiki/%DC%A1%DC%A1%DC%A0%DC%A0%DC%90:%DC%A6%DC%90%DC%AC%DC%90_%DC%AA%DC%9D%DC%AB%DC%9D%DC%AC%DC%90#Renaming_the_Aramaic_.28arc.29_Wikipedia_to_the_Syriac_.28syc.29_Wikipedia

I've also contacted GerardM of the WMF about this matter. I quote GerardM: My
impression of all this is that it is best to rename the Aramaic Wikipedia and
call it the Syriac Wikipedia and syc.wikipedia.org. The language policy of the
WMF allows in my opinion for such exceptions.

Thank you in advance.

User Michaelovic
administrator (current) Aramaic 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 26715] Unable to change from Kaltura media player owing to players feature not functioning

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26715

--- Comment #2 from Thor Malmjursson thor.malmjurs...@yahoo.co.uk 2011-01-14 
12:42:52 UTC ---
No it doesn't.  However, when I say default player, I mean that the one I
always use (as opposed to the VLC plugins, mplayer plugin, etc) is Cortado.  At
this stage, the error has not repeated. But I am willing to try the player menu
again and see if I can get it to do what it did last time.  I'll make a note
here.  

But for what it's worth, my system does nothing I know of to block the
detection of Java, since it works perfectly well everywhere else I've used it.

-- 
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 26715] Unable to change from Kaltura media player owing to players feature not functioning

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26715

--- Comment #3 from Thor Malmjursson thor.malmjurs...@yahoo.co.uk 2011-01-14 
12:48:05 UTC ---
Just tried again, can't seem to get the Kaltura player to appear at all.  I'll
sort something out and see if I can find where it was enabled, and have another
go 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 26726] New: Only top half of 'Select a media file to upload' is clickable on Chrome / Mac

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26726

   Summary: Only top half of 'Select a media file to upload' is
clickable on Chrome / Mac
   Product: MediaWiki extensions
   Version: any
  Platform: Macintosh
OS/Version: Mac OS X 10.6
Status: NEW
  Severity: major
  Priority: Normal
 Component: UploadWizard
AssignedTo: ne...@wikimedia.org
ReportedBy: hus...@gmail.com
CC: gpaum...@wikimedia.org, asha...@wikimedia.org


OBSERVATION
On Chrome / Mac only the top half of the 'Select a media file to upload' is
clickable. This leads to confusion because people might think the entire button
is not clickable or they done something wrong.

CAUSE
The bug is caused because the click is only possible on the input element,
contained in the div with the 'mwe-upwiz-file-ctrl-container' class.

SOLUTION:
Change the height of the input field with class 'mwe-upwiz-file-input' to 67px
as well.

-- 
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 19986] Wikis waiting to be renamed (Tracking)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=19986

Roan Kattouw roan.katt...@gmail.com changed:

   What|Removed |Added

 Depends on||26725

-- 
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 26725] Renaming the Aramaic (arc) Wikipedia to the Syriac (syc) Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26725

Roan Kattouw roan.katt...@gmail.com changed:

   What|Removed |Added

 Blocks||19986

-- 
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 24720] Upload wizard: Upload link not changing cursor to a hand

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=24720

Husky hus...@gmail.com changed:

   What|Removed |Added

 CC||hus...@gmail.com

--- Comment #2 from Husky hus...@gmail.com 2011-01-14 13:48:48 UTC ---
Not working on Firefox / Mac too. 

I'm not quite sure why this isn't working. 

SOLUTION
1) either investigate why this doesn't work
2) Add a jQuery solution

-- 
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 26076] Upload wizard doesn't complete upload in Firefox 3.6.12 on Ubuntu

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26076

Husky hus...@gmail.com changed:

   What|Removed |Added

 CC||hus...@gmail.com

--- Comment #21 from Husky hus...@gmail.com 2011-01-14 13:55:55 UTC ---
I can reproduce the The server returned an error we did not understand:
permissiondenied error too on Firefox 3.6.13 / Mac, Chrome 8.0.552.231 / Mac
and Safari 5.0.3 / Mac.

-- 
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 26725] Renaming the Aramaic (arc) Wikipedia to the Syriac (syc) Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26725

--- Comment #1 from Michaelovic sume...@hotmail.com 2011-01-14 14:13:24 UTC 
---
One thing to add: The interwiki text on the sidebars on other wikipedias should
be changed from ܐܪܡܝܐ to ܣܘܪܝܝܐ.

Thank you in advance.

User Michaelovic
administrator (current) Aramaic 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 26361] Change timezone for kowikiquote

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26361

Ashar Voultoiz has...@free.fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||has...@free.fr
 Resolution||FIXED

--- Comment #4 from Ashar Voultoiz has...@free.fr 2011-01-14 14:26:27 UTC ---
synced live. result:

23:26 Hashar 2011년 1월 14일 (금) 13:57 (UTC)
Live test for bug 26361
after sync :
Hashar 2011년 1월 14일 (금) 23:26 (KST)

-- 
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 26708] remove table { background-color: white } in Vector and Monobook

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26708

--- Comment #3 from foma...@googlemail.com 2011-01-14 14:32:44 UTC ---
There may be some places in existing projects where the white background color
is implicitly assumed. But there are more places where the white background
color is not needed and a transparent background is not defined. Normally this
is no visible difference, unless there are namespace-specific background colors
or other background colors. And there are more uses for automatic transparent
background then for automatic white background. The skin Modern also doesn't
have white background color for tables. I think the table background color
should not defined in core skins. When there are problems in existing project
they may define this in their local skin definition.

-- 
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 26715] Unable to change from Kaltura media player owing to players feature not functioning

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26715

--- Comment #4 from Michael Dale d...@ucsc.edu 2011-01-14 14:53:51 UTC ---
you can enabled it in preferences - gadgets then look for mwEmbed

alternatively any page with video or audio if you add
withJS=MediaWiki:MwEmbed.js to it should display the player ie: 
http://commons.wikimedia.org/wiki/File:Folgers.ogv?withJS=MediaWiki:MwEmbed.js

Then a button shows up at the top to enable the player for all pages on that
wiki.

-- 
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 26634] Activation of AbuseFilter on Romanian language Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26634

Ashar Voultoiz has...@free.fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||has...@free.fr
 Resolution||FIXED

--- Comment #1 from Ashar Voultoiz has...@free.fr 2011-01-14 15:05:40 UTC ---
Should now be enabled. I reused the same user rights used on the english
wikipedia:

$wgGroupPermissions['sysop']['abusefilter-modify'] = false;
$wgGroupPermissions['abusefilter']['abusefilter-modify'] = true;
$wgGroupPermissions['*']['abusefilter-log-detail'] = true;
$wgGroupPermissions['sysop']['abusefilter-revert'] = true;
$wgGroupPermissions['sysop']['abusefilter-view-private'] = true;

Please reopen or create a new bug if it needs corrections.

-- 
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 25679] Simple English Wikipedia logo needs to be updated

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=25679

Ashar Voultoiz has...@free.fr changed:

   What|Removed |Added

   Keywords|shell   |
 Status|NEW |RESOLVED
 CC||has...@free.fr
 Resolution||FIXED

--- Comment #15 from Ashar Voultoiz has...@free.fr 2011-01-14 15:14:14 UTC ---
simple wikipedia use the standard logo location (Wiki.png).

So it is all about uploading the new version to
http://simple.wikipedia.org/wiki/File:Wiki.png

Removed shell keyword since this does not need sysadmin.
Closing bug since it can be fixed by the users.

-- 
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 26076] Upload wizard doesn't complete upload and gives 'permissiondenied' error in several browsers

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26076

Husky hus...@gmail.com changed:

   What|Removed |Added

Summary|Upload wizard doesn't   |Upload wizard doesn't
   |complete upload in Firefox  |complete upload and gives
   |3.6.12 on Ubuntu|'permissiondenied' error in
   ||several browsers

-- 
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 26717] On Firefox 4 beta the subtitles are displayed only after clicking the CC button

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26717

Michael Dale d...@ucsc.edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Michael Dale d...@ucsc.edu 2011-01-14 15:42:13 UTC ---
Thanks for the bug report. Was an issue of event prorogation handled slightly
differently in firefox 4, made things work more consistently in r80273

Update should be pushed out later today.

-- 
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 26718] Default font for subtitles is too small

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26718

Michael Dale d...@ucsc.edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Michael Dale d...@ucsc.edu 2011-01-14 15:48:37 UTC ---
oky font size is now 15% larger. ( 115% the size of other text on the page for
the small players) When the player is full screen the text size grows to better
fit the player window. in r80274

-- 
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 26719] lines of subtitles overlap

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26719

Michael Dale d...@ucsc.edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Michael Dale d...@ucsc.edu 2011-01-14 15:57:10 UTC ---
ugg that’s not pretty. fixed in r80275 set line-height to 1.6em;

-- 
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 26721] Subtitle lines should be broken more evenly

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26721

Michael Dale d...@ucsc.edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Michael Dale d...@ucsc.edu 2011-01-14 16:17:14 UTC ---
this is kind of tricky problem to solve perfectly via an algorithm, we can
relatively easily evenly divide words pre line, but that is not always the
ideal breaking point. Sometimes its a coma or end of thought. 

What we can do is allow users to include line breaks newlines in the subtitle
wikitext so they decide when the line breaks rather than the word count. This
lets you break on commas or end of more logical breaking points.  

The subtitle parser was not handling br very well so that is fixed in r80276
you can see an example here ( once I push out the update ) 
http://commons.wikimedia.org/wiki/File:Folgers.ogv#t=13
where we break after the comma.

-- 
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 26634] Activation of AbuseFilter on Romanian language Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26634

Andrei Stroe andreistro.e+wikibugzi...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #2 from Andrei Stroe andreistro.e+wikibugzi...@gmail.com 
2011-01-14 16:42:02 UTC ---
Thanks, Ashar. Right now, however, it appears that nobody can add/modify
filters, nor can bureaucrats grant the permission to edit abuse filters to
anyone. There may be some settings missing...

As I said in the initial request, it would be fine if all sysops (we don't have
too many) could be automatically allowed to edit abuse filters, or if the
bureaucrats would be able to grant the abusefilter-modify rights.

-- 
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 26722] Subtitles should be displayed higher in the frame

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26722

Michael Dale d...@ucsc.edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Michael Dale d...@ucsc.edu 2011-01-14 16:46:13 UTC ---
Hmm... I tried leaving the text where its placed when the control bar is
displayed and imho it looks bad, on smaller videos combined with the text font
size increase the video is half covered in text.  I do agree it could be a bit
higher from the bottom so I have updated it to 15px ( before it was 10) in
r80279 which I think this is a happy medium ;)

-- 
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 26723] RTL languages break the alignment in Download text

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26723

Michael Dale d...@ucsc.edu changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||d...@ucsc.edu

--- Comment #1 from Michael Dale d...@ucsc.edu 2011-01-14 16:49:28 UTC ---
This in theory should be fixed with the migration to the 1_17 Resource Loader
and its RTL magic. Will mark this bug defer and revisit once migration to 1_17
resource loader is complete.

-- 
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 10158] Don't mention allowing others to contact you if $wgEnableUserEmail=false

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=10158

Ashar Voultoiz has...@free.fr changed:

   What|Removed |Added

   Keywords|need-review |
 Status|NEW |RESOLVED
 CC||has...@free.fr
 Resolution||FIXED

--- Comment #10 from Ashar Voultoiz has...@free.fr 2011-01-14 16:54:31 UTC ---
Adapted and committed as r80281.

Should be in Mediawiki 1.18.

-- 
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 25926] Firefogg does not work in Firefox 4.0 beta 7

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=25926

Michael Dale d...@ucsc.edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Michael Dale d...@ucsc.edu 2011-01-14 16:56:43 UTC ---
latest firefogg ( 2.0.11 ) adds compatibility with firefox 4

-- 
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 26727] New: Allow anchor (a) tags in wikitext

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26727

   Summary: Allow anchor (a) tags in wikitext
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: minor
  Priority: Normal
 Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: b...@mzmcbride.com


Currently, Sanitizer.php bans the use of an a tag, even though it's possible
to mostly replicate the effect of an a tag using internal or external link
markup (e.g., [[foo]] or [http://example.com foo]). However, wikimarkup
does not allow for certain attributes to be passed to the rendered a tag, for
example title= and target=.

Obviously a whitelist/blacklist would be needed to allow or disallow certain
attributes from being used, however I believe some of this sanitation is
already built in to MediaWiki or could easily be as necessary. Allowing the a
tag has a number of benefits and it's the usual practice to allow the HTML
equivalents of markup that's allowed in wikitext.

-- 
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 26728] New: Bugzilla homepage has missing sidebar entry

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26728

   Summary: Bugzilla homepage has missing sidebar entry
   Product: Wikimedia
   Version: unspecified
  Platform: All
   URL: https://bugzilla.wikimedia.org/
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Bugzilla
AssignedTo: pdha...@wikimedia.org
ReportedBy: b...@mzmcbride.com
CC: innocentkil...@gmail.com, s...@reedyboy.net


When you visit https://bugzilla.wikimedia.org/ the sidebar does not contain a
Help link in the first section (Navigation). On every other Bugzilla page
(e.g., https://bugzilla.wikimedia.org/show_bug.cgi?id=1 and
https://bugzilla.wikimedia.org/enter_bug.cgi) I've checked, the sidebar is
consistent and contains the Help link. It should be added to the main page
for consistency.

-- 
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 26729] New: Deleted or never-existed categories to return HTTP 404 Not Found

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26729

   Summary: Deleted or never-existed categories to return HTTP 404
Not Found
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Page rendering
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: w...@rhaworth.net


When a category (has been deleted or has never existed) and it has no members
(ie. there are no articles in the category) then an HTTP 404 code should be
returned.

Consider
http://webcache.googleusercontent.com/search?q=cache:tA61J-kDRkMJ:en.wikipedia.org/wiki/Category:Elysiidae
which is Google's cache of en:Category:Elysiidae. Google is continuing to
report it even though the category was deleted more than two years ago. It is
reported because a status code of 200 OK is returned. Presumably the idea of
that was to allow for categories with members but without a category page.

Suggested solutions:

Solution 1 - cheap and, in my view, completely satisfactory. Forget the no
members criterion. Return a 404 Not Found code for every category where no
page exists. Most browsers completely ignore the difference between a 200 and a
404 code - an human viewing a category with members but with no page will see
the information and never know that a 404 was returned. Search engines seeing
such a page will honour the 404 and not index - is that any great loss?

Solution 2 - rigorous. For a category where no page exists, check first if it
has members and send 200 or 404 as appropriate.

-- 
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 26729] Deleted or never-existed categories to return HTTP 404 Not Found

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26729

Roger W Haworth w...@rhaworth.net changed:

   What|Removed |Added

   See Also||https://bugzilla.wikimedia.
   ||org/show_bug.cgi?id=2585

-- 
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 26729] Deleted or never-existed categories to return HTTP 404 Not Found

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26729

MZMcBride b...@mzmcbride.com changed:

   What|Removed |Added

 CC||b...@mzmcbride.com

--- Comment #1 from MZMcBride b...@mzmcbride.com 2011-01-14 17:55:49 UTC ---
Is this a duplicate of bug 2585?

-- 
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 2585] Server should return a 404 HTTP status code if the page does not exist

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=2585

Roger W Haworth w...@rhaworth.net changed:

   What|Removed |Added

 CC||w...@rhaworth.net

--- Comment #35 from Roger W Haworth w...@rhaworth.net 2011-01-14 17:56:39 
UTC ---
Deleted or never-existed categories should return HTTP 404. I have raised this
request as a separate bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=26729

-- 
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 26730] New: Errors in edit review log at en.wikibooks

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26730

   Summary: Errors in edit review log at en.wikibooks
   Product: MediaWiki extensions
   Version: any
  Platform: All
   URL: http://en.wikibooks.org/wiki/Special:Log/stable
OS/Version: All
Status: NEW
  Severity: major
  Priority: Normal
 Component: FlaggedRevs
AssignedTo: ro...@wikimedia.org
ReportedBy: aaron.adrign...@gmail.com
CC: jschulz_4...@msn.com, innocentkil...@gmail.com


Ever since the feature of the flagged revisions extension for choosing whether
more highly rated revisions take precedence over lower rated revisions was
removed, we have had errors in the edit review log at English Wikibooks. 
Specifically, the log entries are spitting out:
lt;stabilization-sel-shortgt;: lt;stabilization-sel-short-1gt;

Background information: flagged revisions is enabled for all pages in the
mainspace, Wikijunior, and Cookbook namespaces with the latest revision shown
by default.  Pages in the Wikijunior namespace have the settings manually
changed to show the latest reviewed revision.  Please include en.wikibooks in
future testing.

-- 
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 26634] Activation of AbuseFilter on Romanian language Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26634

--- Comment #3 from Ashar Voultoiz has...@free.fr 2011-01-14 18:01:29 UTC ---
I applied the english wikipedia model in which Bureaucrats would have to add
people in the 'abusefilter' group. This way you can control who is able to edit
it :)

If you really want any sysop to be able to modify the filters, I would change
the userrights by:

 -$wgGroupPermissions['sysop']['abusefilter-modify'] = false;
 +$wgGroupPermissions['sysop']['abusefilter-modify'] = true;

And remove the 'abusefilter' group :

 -$wgGroupPermissions['abusefilter']['abusefilter-modify'] = true;

-- 
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 26645] Remove any break lines before page content

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26645

duplicate...@googlemail.com changed:

   What|Removed |Added

 CC||duplicate...@googlemail.com

--- Comment #1 from duplicate...@googlemail.com 2011-01-14 18:05:25 UTC ---
The DISPLAYTITLE in [[fr:Modèle:Langue du titre]] leaves the newline before
[[:fr:Modèle:Infobox Connectique]] and that produce a br.

See also bug 23698

-- 
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 26729] Deleted or never-existed categories to return HTTP 404 Not Found

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26729

--- Comment #2 from Roger W Haworth w...@rhaworth.net 2011-01-14 18:06:25 UTC 
---
Bug 2585 is a bit long in the tooth and has already been implemented certainly
for the (article) namespace and probably for all except category. Also the
question of no page but has members is unique to categories. So I felt that a
fresh discussion might help. Incidentally see
http://en.wikipedia.org/wiki/User_talk:RHaworth/Archive_to_2011_Jan_14#Category:Wikipedia_sockpuppets_of_.E2.80.A6
which is where I got involved - one person fussing over being accused of
sock-puppetry.

-- 
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 26657] Pressing Enter in history pages should display the diff between selected revisions

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26657

duplicate...@googlemail.com changed:

   What|Removed |Added

 CC||duplicate...@googlemail.com
  Component|History/Diffs   |Revision deletion
 AssignedTo|wikibugs-l@lists.wikimedia. |jschulz_4...@msn.com
   |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 26727] Allow anchor (a) tags in wikitext

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26727

duplicate...@googlemail.com changed:

   What|Removed |Added

 CC||duplicate...@googlemail.com

--- Comment #1 from duplicate...@googlemail.com 2011-01-14 18:31:34 UTC ---
related: bug 18460

-- 
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 26727] Allow anchor (a) tags in wikitext

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26727

MZMcBride b...@mzmcbride.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from MZMcBride b...@mzmcbride.com 2011-01-14 18:33:13 UTC ---


*** This bug has been marked as a duplicate of bug 18460 ***

-- 
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 18460] Allow a .../a (currently prevented)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18460

MZMcBride b...@mzmcbride.com changed:

   What|Removed |Added

 CC||b...@mzmcbride.com

--- Comment #1 from MZMcBride b...@mzmcbride.com 2011-01-14 18:33:13 UTC ---
*** Bug 26727 has been marked as a duplicate of this bug. ***

-- 
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 26713] Wikihiero not rendering with PHP 5.3.4

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26713

Reedy s...@reedyboy.net changed:

   What|Removed |Added

   Keywords|need-review, patch  |
 Status|NEW |RESOLVED
 CC||s...@reedyboy.net
 Resolution||INVALID

--- Comment #3 from Reedy s...@reedyboy.net 2011-01-14 18:33:15 UTC ---
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/wikihiero/wikihiero.php?view=annotate

From what I can see, it's already  in trunk, and has been since before 18926
(which was just whitespace changes)

So I've no idea what happened to the copy you are using...

-- 
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 18460] Allow anchor (a) tags in wikitext (currently prevented)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18460

MZMcBride b...@mzmcbride.com changed:

   What|Removed |Added

Summary|Allow a .../a   |Allow anchor (a) tags in
   |(currently prevented)   |wikitext (currently
   ||prevented)

--- Comment #2 from MZMcBride b...@mzmcbride.com 2011-01-14 18:34:04 UTC ---
(Copied from bug 26727#c0)
Currently, Sanitizer.php bans the use of an a tag, even though it's possible
to mostly replicate the effect of an a tag using internal or external link
markup (e.g., [[foo]] or [http://example.com foo]). However, wikimarkup
does not allow for certain attributes to be passed to the rendered a tag, for
example title= and target=.

Obviously a whitelist/blacklist would be needed to allow or disallow certain
attributes from being used, however I believe some of this sanitation is
already built in to MediaWiki or could easily be as necessary. Allowing the a
tag has a number of benefits and it's the usual practice to allow the HTML
equivalents of markup that's allowed in wikitext.

-- 
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 26634] Activation of AbuseFilter on Romanian language Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26634

--- Comment #4 from Andrei Stroe andreistro.e+wikibugzi...@gmail.com 
2011-01-14 18:44:27 UTC ---
The en.wp model would be sufficient, and it would allow us to develop our own
policy; but right now, for some reason, bureaucrats can't add users to the
abusefilter group. Maybe there's another setting for this group, maybe add
'abusefilter' to the $wgAddGroups['bureaucrat'] list?

-- 
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 26730] Errors in edit review log at en.wikibooks

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26730

Aaron Schulz jschulz_4...@msn.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Aaron Schulz jschulz_4...@msn.com 2011-01-14 19:03:36 UTC 
---
Fixed in r80297.

-- 
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 26729] Deleted or never-existed categories to return HTTP 404 Not Found

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26729

Liangent liang...@gmail.com changed:

   What|Removed |Added

 CC||liang...@gmail.com

--- Comment #3 from Liangent liang...@gmail.com 2011-01-14 19:09:37 UTC ---
I remember MSIE has an option which decides whether a standard (included in
MSIE distribution) page or the page sent together with HTTP 404 should be used
when it meets HTTP 404.

-- 
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 26731] New: Parser-serialiseHalfParsedText($text) does not save strip items if $text begins with a strip marker

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26731

   Summary: Parser-serialiseHalfParsedText($text) does not save
strip items if $text begins with a strip marker
   Product: MediaWiki
   Version: 1.16.0
  Platform: All
OS/Version: All
Status: NEW
  Keywords: easy
  Severity: minor
  Priority: Normal
 Component: Page rendering
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: foxlit.mwzi...@go-hero.net


The serialiseHalfParsedText method in the Parser class attempts to store all
strip markers, links, etc needed to render a bit of wikitext. It finds the
strip markers in the provided text using a while loop; in 1.16.0, this is in
includes/parser/Parser.php, line 5087:
while( ( $start_pos = strpos( $text, $this-mUniqPrefix, $pos ) )  ( $end_pos
= strpos( $text, self::MARKER_SUFFIX, $pos ) ) )

If $text begins with a strip marker, $start_pos will be assigned 0; which
causes the while condition to be false; so serialiseHalfParsedText will not
store any strip markers at all; checking whether the strpos return is identical
to FALSE would fix this.

While I'm running into this issue on 1.16.0, the same while loop exists in SVN
revision 80248.

-- 
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 26714] Allow banner to run only in the languages we have translations for

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26714

--- Comment #1 from Ryan Kaldari rkald...@wikimedia.org 2011-01-14 19:28:57 
UTC ---
The current language selection interface is solely for targeting a campaign to
a particular language project (or projects), it has no relation to what
language the campaign's banners are served in (or available in). So for example
if you use the interface to target a banner to the French wikipedia, it will
still be displayed in English, German, etc, if those translations are available
and a user has their interface language set to one of those. So for that
reason, the two proposed solutions won't work.

The essential problem here is that decisions about what banners are served are
decided completely based on campaign information, and campaigns have no
knowledge of banner content/settings/translations.

I'm not sure there's a good way to solve this without rewriting CentralNotice.
Also, there is the question of what should happen in the case that the banner
is not available in the user's language. Should they get a fall-back banner? If
so, how is it chosen? What if no banners are available in the user's language?
Would they get no banner, an English banner, or a notice that translation is
needed? It seems that we would need to add another layer of interface to the
tool to handle these situations.

In the past this problem has been mitigated by added a Help translate link to
all the banners. Not sure why that wasn't used this year, though.

-- 
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 26732] New: Install RSS import extension on http://mediawiki.org

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26732

   Summary: Install RSS import extension on http://mediawiki.org
   Product: Wikimedia
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Site requests
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: z...@fooassociates.com
CC: ro...@wikimedia.org


On MediaWiki.org, please install an extension that will allow import of RSS
feeds.

The extension should manage the import of RSS feeds securely and robustly.  I
don't have an opinion on which extension is best (or even if any extension is
good enough for our purposes.)

The extension also needs to only allow trusted users on MediaWiki.org to set up
RSS imports – it's too risky (in several different senses) to include arbitrary
content from unknown sources.

==Background==
Last week, I added a news section to the MediaWiki.org developer hub article
(http://mediawiki.org/wiki/Developer_hub#Developer_news).

Chatting about this with RobLa, he noted that all of these news items should
have gone on the tech blog (http://techblog.wikimedia.org) and that it would be
likely best to post developer news in one central place and then pull the feed
into places where news is needed.

As a side note, we should categorize posts on the tech blog so that we can
differentiate between timely posts (like a post about service outages or the
engineering updates) and posts means to encourage action (like a post about
making extensions use resource loader before 1.17 is released.)

-- 
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 26367] Uploading fails with internal error: key 'ljg40qoexthbj3vu8f9875e5uspj37n.' is not in a proper format

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26367

Roan Kattouw roan.katt...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #12 from Roan Kattouw roan.katt...@gmail.com 2011-01-14 19:36:19 
UTC ---
(In reply to comment #11)
 (In reply to comment #5)
  This should be fixed by r79835.
 
 On my wiki, r79835 indeed fixes the issue I saw
Marking as FIXED then.

-- 
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 26611] Bugs that should be fixed for 1.17 WMF deployment (tracking)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26611

Bug 26611 depends on bug 26367, which changed state.

Bug 26367 Summary: Uploading fails with internal error: key 
'ljg40qoexthbj3vu8f9875e5uspj37n.' is not in a proper format
https://bugzilla.wikimedia.org/show_bug.cgi?id=26367

   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 26732] Install RSS import extension on http://mediawiki.org

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26732

MZMcBride b...@mzmcbride.com changed:

   What|Removed |Added

 CC||b...@mzmcbride.com

--- Comment #1 from MZMcBride b...@mzmcbride.com 2011-01-14 19:41:15 UTC ---
http://www.mediawiki.org/wiki/Extension:RSS is already installed on a Wikimedia
wiki (http://wikimediafoundation.org). It shouldn't be an issue to enable it
elsewhere.

-- 
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 26732] Install RSS import extension on http://mediawiki.org

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26732

MZMcBride b...@mzmcbride.com 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 26732] Install RSS import extension on http://mediawiki.org

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26732

--- Comment #2 from Reedy s...@reedyboy.net 2011-01-14 19:42:20 UTC ---
RoanKattouw Need to ask Tim-away before deploying elsewhere though

-- 
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 26714] Allow banner to run only in the languages we have translations for

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26714

--- Comment #2 from James Alexander jalexan...@wikimedia.org 2011-01-14 
19:53:43 UTC ---
Aye the help translate link is nice but we found that having links on the
banner that weren't the donate link (including the translate link)draw a large
(and very significant) amount of traffic away from the donate page (in the 100s
of thousands) and that most people who would translate will still find their
way to us. Putting it in the meta sitenotice though was a good idea.

Regarding the language focusing part. We've essentially ignored the fact that
we are targeting projects and not languages (despite knowing the difference and
quietly giving Philippe the caveat every once in a while) because the vast vast
vast majority of the readers are going to be anonymous and all anonymous
readers will see it in the default content language.

-- 
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 26713] Wikihiero not rendering with PHP 5.3.4

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26713

Dan Nessett dness...@yahoo.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |

--- Comment #4 from Dan Nessett dness...@yahoo.com 2011-01-14 19:54:33 UTC ---
(In reply to comment #3)
 http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/wikihiero/wikihiero.php?view=annotate
 
 From what I can see, it's already  in trunk, and has been since before 18926
 (which was just whitespace changes)
 
 So I've no idea what happened to the copy you are using...

This occurred on a fresh check out of REL1_16_1
(http://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_16_1/). If you look at
that tagged branch
(http://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_16_1/extensions/wikihiero/wikihiero.php?revision=79565view=markup),
the revision of Wikihiero is 79565. So, the most stable version of MW does not
contain the bug fix.

-- 
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 26713] Wikihiero not rendering with PHP 5.3.4

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26713

--- Comment #5 from Reedy s...@reedyboy.net 2011-01-14 19:59:22 UTC ---
http://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_16_1/extensions/wikihiero/wikihiero.php?annotate=79565

52hashar18926// MediaWiki entry point
53  function WikiHieroLoader( $text, $attribs, $parser ) {

And it's there in
http://upload.wikimedia.org/ext-dist/wikihiero-MW1.16-r66255.tar.gz

I'm beyond confused

-- 
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 26634] Activation of AbuseFilter on Romanian language Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26634

--- Comment #5 from Ashar Voultoiz has...@free.fr 2011-01-14 20:07:53 UTC ---
Ok I have allowed bureaucrats to add/remove users in the 'abusefilter' group.
Looks better 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 26634] Activation of AbuseFilter on Romanian language Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26634

Andrei Stroe andreistro.e+wikibugzi...@gmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Andrei Stroe andreistro.e+wikibugzi...@gmail.com 
2011-01-14 20:13:11 UTC ---
Thank you, it's all right now. I'm changing issue status to resolved, I hope
it's ok with the lifecycle policies.

-- 
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 26634] Activation of AbuseFilter on Romanian language Wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26634

Ashar Voultoiz has...@free.fr changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #7 from Ashar Voultoiz has...@free.fr 2011-01-14 20:19:05 UTC ---
Looks like anyone is allowed to resolve a bug is created.
Create a new bug if you need a 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 26663] Request for selecting a portion of media for playback

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26663

Michael Dale d...@ucsc.edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Michael Dale d...@ucsc.edu 2011-01-14 20:19:16 UTC ---
I have added temporal url support in r80284 and deployed it to the gadget. 

Its based on: 
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-dimensions

This works on video pages like so: 
http://commons.wikimedia.org/wiki/File:Folgers.ogv#t=10 ( start at 10 second go
to end ) 
or 
http://commons.wikimedia.org/wiki/File:Folgers.ogv#t=10,20 ( from 10 seconds to
20 seconds )

Until the updated timed media handler extension is deployed you have to use the
following template on videos to support time offsets ( Once we deploy the
updated timed media handler we can switch the template syntax over to the
proper format  )
http://commons.wikimedia.org/wiki/Template:Temporal_Media_Fragment

Here is the example on commons:  
http://commons.wikimedia.org/wiki/User:Mdale/TestTemporalUrls

Here is an example on wikisource:
http://en.wikisource.org/wiki/User:Mdale/TestTemporalUrls?withJS=MediaWiki:MwEmbed.js

If there is community consensus we could turn it on by default for wikisource.
( mwEmbed has been enabled by default in some other small wikis )

-- 
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 26713] Wikihiero not rendering with PHP 5.3.4

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26713

--- Comment #6 from Ashar Voultoiz has...@free.fr 2011-01-14 20:28:45 UTC ---
Please note the patch is mixed up. User actually request to remove the
ampersand used to pass the parser by reference.

-- 
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 26733] New: Wrap initial table creation in transaction

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26733

   Summary: Wrap initial table creation in transaction
   Product: MediaWiki
   Version: 1.17
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Installation
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: roan.katt...@gmail.com
CC: innocentkil...@gmail.com
Blocks: 26611


Due to a local snafu one of the last lines in my tables.sql contained an SQL
error. This caused all tables to be created, then that line to fail and the
lines below to be skipped. However, when running the installer again it refused
to run tables.sql because the tables were already there.

We should wrap the inital table creation in a transaction so any failure
anywhere in tables.sql causes no tables to be created whatsoever.

-- 
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 26611] Bugs that should be fixed for 1.17 WMF deployment (tracking)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26611

Roan Kattouw roan.katt...@gmail.com changed:

   What|Removed |Added

 Depends on||26733

-- 
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 26713] Wikihiero not rendering with PHP 5.3.4

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26713

--- Comment #7 from Reedy s...@reedyboy.net 2011-01-14 20:36:30 UTC ---
Right

r80319

Needs backporting to 1.17 and 1.16

-- 
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 26713] Wikihiero not rendering with PHP 5.3.4

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26713

Reedy s...@reedyboy.net changed:

   What|Removed |Added

 Status|REOPENED|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 26733] Wrap initial table creation in transaction

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26733

Reedy s...@reedyboy.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||s...@reedyboy.net
 Resolution||FIXED

--- Comment #1 from Reedy s...@reedyboy.net 2011-01-14 20:43:39 UTC ---
r80322

-- 
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 26611] Bugs that should be fixed for 1.17 WMF deployment (tracking)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26611

Bug 26611 depends on bug 26733, which changed state.

Bug 26733 Summary: Wrap initial table creation in transaction
https://bugzilla.wikimedia.org/show_bug.cgi?id=26733

   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 25624] Making license and author information api accessible

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=25624

Bryan Tong Minh bryan.tongm...@gmail.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|wikibugs-l@lists.wikimedia. |bryan.tongm...@gmail.com
   |org |

--- Comment #4 from Bryan Tong Minh bryan.tongm...@gmail.com 2011-01-14 
20:45:51 UTC ---
We've been discussing this here in Amsterdam with Krinkle, Roan and me, have
made some changes to the page mentioned in comment #3 and are implementing this
in the license-work branch.

I'll assign this to myself, but feel free to work on 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 24650] Fix API to work with categorylinks changes

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=24650

--- Comment #4 from Reedy s...@reedyboy.net 2011-01-14 21:34:24 UTC ---
(In reply to comment #2)
 (In reply to comment #1)
  So we're missing the index as we're not sorting on cl_type
  
 Besides sorting we should also actually be doing stuff with cl_type
 (outputting, filtering).

r80324 allows cl_type to be shown and allows filtering on cl_type

 
  We're using cl_sortkey as a continue. That probably needs changing.
  
 Yes, needs to be some compound key that forms a unique index.

That's the next job... See what I can come up with.

 
  ApiQueryCategories:
  
  Output of sortkey is probably pointless now...?
 Let's keep it around for back compat. It's also not totally useless (useful 
 for
 e.g. debugging collations and the like).

(In reply to comment #3)
  Output of sortkey is probably pointless now...?
 Let's keep it around for back compat. It's also not totally useless (useful 
 for
 e.g. debugging collations and the like).
 
 How about anywhere a sortkey is displayed in the api, we now have two fields,
 sortkey would be the human readable sortkey based cl_sortkey_prefix (on the
 assumption that most people using the api for sortkeys currently use it to
 display to user, not to sort things), and then another field, rawsortkey that
 has the binary sortkey in it.
 
 Does that sound like the right course of action?

That seems sane. Hopefully people aren't doing anything, but we have no idea.

Keeping the names more like the cols is probably a better idea

Roan, what do you think about what Bawolff suggested?

-- 
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 26714] Allow banner to run only in the languages we have translations for

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26714

--- Comment #3 from Ryan Kaldari rkald...@wikimedia.org 2011-01-14 22:08:53 
UTC ---
Well if we're ignoring the user-language distinction, and you don't want to
target languages manually, there's really no point in even having the interface
for targeting languages at all. The targeting should just be automatic based on
which translations are available.

Assuming we wanted to switch to such a system, there are still a few issues:
1. What constitutes having a translation? Would 100% of the messages have to be
translated, just 1, something in between?
2. The weights and allocations would no longer be reliable across an entire
project type (you might have dramatically different actual allocations for
various languages)
3. We still would need to figure out what do to in the case in which no
translated banners were available. Do we show nothing?

-- 
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 26714] Allow banner to run only in the languages we have translations for

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26714

--- Comment #4 from James Alexander jalexan...@wikimedia.org 2011-01-14 
22:20:08 UTC ---
While I'm not in any way against having an option to target only to where
translations are in the system if the option is manual or automatic the choice
must be manual. Even when we have lots of translations (for example the Jimmy
banner) we will always have multiple times when we only want to be sending that
banner to 1 or a handful of projects/languages (in fact most campaigns were
like that) or the alternative of sending it to all projects even if we don't
have the translation yet.

Perhaps I wasn't clear about the user/language distinction. We've basically
been working on a content-language = user-language assumption with the
knowledge that while it isn't perfectly correct it is for the vast majority of
readers because all anons will use the content-language and logged in users
should all understand it if we don't have a translation yet.

I actually think that targeting by by content-language is far more flexible and
better overall, if we have to select manually then that's the trade off.
Obviously it would always be nice to have 'lots of options' but each option
adds a large amount of complexity into the system. 

In regards to question 3: Currently we fall back to English which I think is
what we want to do. If we're doing the target by what we have available
option then it would be none but we need to keep the current targeting system
at some level and if we do the English fall back makes sense. I don't know if
it is only English? I know we have some Chinese dialects that do not appear to
be falling back as they should (From what I'm told we have 6 language dialects
and we've always used 3 translations but have to manually copy over specific
ones to the extra 3 because they don't fall back to zh for example).

-- 
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 26734] New: Warning messages should handle redirects

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26734

   Summary: Warning messages should handle redirects
   Product: MediaWiki extensions
   Version: any
  Platform: All
   URL: http://ro.wikipedia.org/wiki/Special:Filtru_abuzuri/1
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: AbuseFilter
AssignedTo: agarr...@wikimedia.org
ReportedBy: crangasi2...@yahoo.com
CC: wikibugs-l@lists.wikimedia.org


AbuseFilter allows using MediaWiki pages as custom warning messages to users.
However, most wikipedias already use warning messages in the Template
namespaces. The obvious solution is to allow redirect from the MediaWiki pages
to the corresponding Templates.

-- 
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 25445] please create a mobile home page for the romanian wikipedia

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=25445

crangasi2...@yahoo.com changed:

   What|Removed |Added

   Keywords||easy

--- Comment #3 from crangasi2...@yahoo.com 2011-01-14 22:31:14 UTC ---
This looks like an easy fix. Could somebody take a look?

-- 
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 26716] use external editor preference causes problems when people who don't know what they're doing play with it

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26716

--- Comment #4 from Bawolff bawolff...@gmail.com 2011-01-14 22:52:54 UTC ---
I wonder how often people (correctly) use that preference. I believe that the
majority of people who use external editors, use it for images. I wonder if
people who use it for articles, generally use the url parameter method. If
people generally use the url method, we might consider removing the preference
altogether.

Be good to get some stats on how widely used it is.

-- 
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 18460] Allow anchor (a) tags in wikitext (currently prevented)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18460

Bawolff bawolff...@gmail.com changed:

   What|Removed |Added

 CC||bawolff...@gmail.com

--- Comment #3 from Bawolff bawolff...@gmail.com 2011-01-14 23:03:22 UTC ---
for example title= and target=

Would we really want to allow target? I'm personally not a fan of pop ups.

-- 
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 26735] New: Add thumbnail / width option to Special:FilePath (like thumb.php?w=SIZE and [[File:Img|SIZEpx]])

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26735

   Summary: Add thumbnail / width option to Special:FilePath (like
thumb.php?w=SIZE and [[File:Img|SIZEpx]])
   Product: MediaWiki
   Version: 1.18-svn
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Images and files
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: krinklem...@gmail.com
CC: gpaum...@wikimedia.org, bryan.tongm...@gmail.com


When building plugins that use material from commons (such as from WordPress)
it would be ideal not to 
* Not have to hardcode thumbpath to upload.wikimedia which breaks in case of
redirects
* Not have to make an API-call to get the current path

Reason for getting path is mostly because a file could become a redirect and a
normal thumb will brake, while Special:FilePath and API calls stay functional
because they resolve redirects.


Syntax:

/wiki/Special:FilePath/Image.jpg/200

/w/index.php?title=Special:FilePathfile=Image.jpgwidth=200

-- 
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 26735] Add thumbnail / width option to Special:FilePath (like thumb.php?w=SIZE and [[File:Img|SIZEpx]])

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26735

Krinkle krinklem...@gmail.com changed:

   What|Removed |Added

 CC||krinklem...@gmail.com
 AssignedTo|wikibugs-l@lists.wikimedia. |roan.katt...@gmail.com
   |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 26714] Allow banner to run only in the languages we have translations for

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26714

--- Comment #5 from Ryan Kaldari rkald...@wikimedia.org 2011-01-14 23:22:56 
UTC ---
I'll give some more thought to this. Perhaps Casey's original suggestions are
the best approach.

Also, it does appear that fall-back languages do not work in CentralNotice
(other than English). There is another bug open about that: bug 17107.

-- 
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 19262] Large pages with a high number of particular templates have unacceptably slow rendering time for logged in users

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=19262

MZMcBride b...@mzmcbride.com changed:

   What|Removed |Added

 CC||b...@mzmcbride.com
Summary|large pages with a lot of   |Large pages with a high
   |links still slow|number of particular
   ||templates have unacceptably
   ||slow rendering time for
   ||logged in users

--- Comment #2 from MZMcBride b...@mzmcbride.com 2011-01-14 23:23:14 UTC ---
I don't believe this problem is related to the number of links. I believe it is
due to the number of instances of particular templates such as [[Template:Cite
book]]. A simple test should be sufficient to demonstrate this.

If I copy the current text of [[List of chess books, A-L]]] (oldid:
http://en.wikipedia.org/w/index.php?oldid=407667664) into a sandbox, it takes
approximately 39.5 seconds to render according to the page source (!-- Served
by srv195 in 39.529 secs. --), using ?action=purge
(http://en.wikipedia.org/w/index.php?oldid=407920835action=purge) while
logged in.

If I take the same text, put it through [[Special:ExpandTemplates]] and save it
to my sandbox, it takes approximately 5.3 seconds to render according to the
page source (!-- Served by srv273 in 5.353 secs. --), using ?action=purge
(http://en.wikipedia.org/w/index.php?oldid=407924303action=purge) while
logged in.

Special:ExpandTemplates, of course, full expands the templates, their
ParserFunctions parser functions, and other magic word variables, while leaving
the links. This makes it fairly clear that it is not the number of links that
is to blame for the slow rendering time, but is instead the number of instances
of particular templates.

I'm updating the bug summary from large pages with a lot of links still slow
to Large pages with a high number of particular templates have unacceptably
slow rendering time for logged in users accordingly.

-- 
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 26381] Special:BannerController breaks all JS on live site

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26381

--- Comment #8 from Ryan Kaldari rkald...@wikimedia.org 2011-01-14 23:34:44 
UTC ---
@Lupo: '[]' is the correct json encoding for an empty array. That shouldn't
cause any problems. In fact, '[]' is the value that is normally expected to be
returned (when we aren't running banners).

-- 
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 24923] Uploads fail with !$wgStrictFileExtensions and non-preferred extension

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=24923

--- Comment #6 from Nahor nahor.j+mediaw...@gmail.com 2011-01-14 23:39:03 UTC 
---
Comment on attachment 7651
  -- https://bugzilla.wikimedia.org/attachment.cgi?id=7651
REL1_16 patch


+  if( $wgCheckFileExtensions  $wgStrictFileExtensions ) 
{
+  global $wgFileExtensions, 
$wgAjaxUploadInterface;
+  $vars['wgFileExtensions'] = $wgFileExtensions;
+  }

if wgFileExtensions is not defined in JavaScript, it prevents the rest from
working like pre-filling the destination filename field.
You should set wgFileExtensions to NULL when wgCheckFileExtensions or
wgStrictFileExtensions are false.
else {
$vars['wgFileExtensions'] =  NULL;
}

-- 
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 18460] Allow anchor (a) tags in wikitext (currently prevented)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18460

--- Comment #4 from MZMcBride b...@mzmcbride.com 2011-01-14 23:47:23 UTC ---
(In reply to comment #3)
 for example title= and target=
 
 Would we really want to allow target? I'm personally not a fan of pop ups.

That's probably something that could have a sensible default with a
configuration variable to override. An array of blacklisted/whitelisted
attributes that could be overridden on a per-wiki basis. I'm personally more
concerned that there is currently a blanket ban on the a HTML element,
banning even simple use-cases like a href=http://en.wikipedia.org;my
link/a (making, for example, copying and pasting horribly difficult).

-- 
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 18460] Allow anchor (a) tags in wikitext (currently prevented)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18460

Krinkle krinklem...@gmail.com changed:

   What|Removed |Added

 CC||krinklem...@gmail.com

--- Comment #5 from Krinkle krinklem...@gmail.com 2011-01-14 23:53:47 UTC ---
Titles/tooltips: span title
Jump-to-anchors: span id
LInk: [http:// ]

All other attributes to anchor tags I think are either unwanted, risky or
redundant.
Further more they would greatly make the wikitext more complex and
non-standard.

Wikitext is characterbased ('', * {| {{ etc.) with some xml but introducing
more HTML is not something I think should even be considered.

-- 
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 18460] Allow anchor (a) tags in wikitext (currently prevented)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18460

Roan Kattouw roan.katt...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||roan.katt...@gmail.com
 Resolution||WONTFIX

--- Comment #6 from Roan Kattouw roan.katt...@gmail.com 2011-01-14 23:55:31 
UTC ---
(In reply to comment #5)
 Titles/tooltips: span title
 Jump-to-anchors: span id
 LInk: [http:// ]
 
 All other attributes to anchor tags I think are either unwanted, risky or
 redundant.
It's also not trivial to whitelist a only for name= but not for other
purposes (links).

Marking WONTFIX.

-- 
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 24650] Fix API to work with categorylinks changes

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=24650

Reedy s...@reedyboy.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Reedy s...@reedyboy.net 2011-01-15 00:14:06 UTC ---
Right, all done by r80362, RELEASE-NOTES in r80363

Going to log a related bug too...

-- 
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 22744] Add/Update indexes for queries done by the API

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=22744

Bug 22744 depends on bug 24650, which changed state.

Bug 24650 Summary: Fix API to work with categorylinks changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=24650

   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 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 26611] Bugs that should be fixed for 1.17 WMF deployment (tracking)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26611

Bug 26611 depends on bug 24650, which changed state.

Bug 24650 Summary: Fix API to work with categorylinks changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=24650

   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 26679] Edit box text appears to jump back and forth whilst typing

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26679

--- Comment #2 from Thor Malmjursson thor.malmjurs...@yahoo.co.uk 2011-01-15 
00:15:33 UTC ---
(In reply to comment #0)

Further to the original report and details on the Village Pump at Commons, I
can now confirm this bug is occurring in 3 separate browsers, each unrelated. 
As well as the initial report against Firefox 3.6.13 in KDE 4.4.5 (Mandriva
2010.2), I'm also experiencing this issue in Opera 10.1.63 (same DM and OS) and
also in the Chromium browser.  

The error ceased in Konqueror (the fourth one I have), after turning off
Javascript, but not in the other three.

-- 
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 18460] Allow anchor (a) tags in wikitext (currently prevented)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18460

MZMcBride b...@mzmcbride.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |

--- Comment #7 from MZMcBride b...@mzmcbride.com 2011-01-15 00:25:01 UTC ---
(In reply to comment #5)
 Titles/tooltips: span title
 Jump-to-anchors: span id

You're aware that MediaWiki itself uses a, not span for anchors? For
example, in the page source there is a id=top/a. I can't remember the
exact reason why this was implemented in this way, but I do recall there being
one.

 LInk: [http:// ]
 
 All other attributes to anchor tags I think are either unwanted, risky or
 redundant.

That's a lot of attributes you're talking about. People regularly come into
MediaWiki and want to add target= capabilities, for example. So much so that
there is a configuration variable ($wgExternalLinkTarget) that modifies the
target for all links. This is obviously sub-optimal if there are only
particular links that a user wishes to have a target=.

I don't think anyone objects to banning the risky attributes. I object to
banning non-risky attributes like id=, title=, and href= (once you strip
out dangerous pieces like javascript:), though.

 Further more they would greatly make the wikitext more complex and
 non-standard.
 
 Wikitext is characterbased ('', * {| {{ etc.) with some xml but introducing
 more HTML is not something I think should even be considered.

You suggested using span title=a link[http://example.com/ example]/span.
Do you really believe that's better for users than a
href=http://example.com/; title=a linkexample/a? There is going to be
some HTML in wikitext no matter what. I suggest using standard code, not
forcing users to use workarounds and hacks in order to fight the
sanitizer/parser, when these attributes are perfectly valid and safe.

(In reply to comment #6)
 It's also not trivial to whitelist a only for name= but not for other
 purposes (links).

The level of triviality doesn't matter. There are definitely legitimate
use-cases for using a and it breaks the standard that rendered wikitext HTML
be valid in actual HTML. (Are there any other HTML elements that fall outside
this rule?)

The reason that I suggested adding this feature wouldn't be very difficult is
that attributes are already stripped in certain elements. For example, span
onmouseover=alert('crap')Oh no/span becomes spanOh no/span
currently.

 Marking WONTFIX.

Re-opening.

Another use-case to consider is that people may want this functionality so much
that they're willing to modify Sanitizer.php to allow the a HTML element, not
realizing the potential risks (a seems like a fairly simple tag on the
surface). MediaWiki should provide a way to enable this element in a sane, safe
way.

-- 
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 26736] New: Usefulness of using (start|end)sortkey in ApiQueryCategoryMembers

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26736

   Summary: Usefulness of using (start|end)sortkey in
ApiQueryCategoryMembers
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: minor
  Priority: Normal
 Component: API
AssignedTo: roan.katt...@gmail.com
ReportedBy: s...@reedyboy.net
CC: simetrical+wikib...@gmail.com,
bryan.tongm...@gmail.com, s...@reedyboy.net,
vasi...@gmail.com, soxre...@gmail.com
Blocks: 26611


If the field is likely to be moving towards a binary field, this field becomes
less useful.

I'm not sure replacing it with doing it on the more human readable
sortkey_prefix...

Do we just deprecate and remove the parameters in 1.17 then?

Or leave it while it's semi useful..?

-- 
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 26611] Bugs that should be fixed for 1.17 WMF deployment (tracking)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26611

Reedy s...@reedyboy.net changed:

   What|Removed |Added

 Depends on||26736

-- 
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 26713] Wikihiero not rendering with PHP 5.3.4

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26713

--- Comment #8 from Dan Nessett dness...@yahoo.com 2011-01-15 00:41:02 UTC ---
(In reply to comment #6)
 Please note the patch is mixed up. User actually request to remove the
 ampersand used to pass the parser by reference.

(In reply to comment #6)
 Please note the patch is mixed up. User actually request to remove the
 ampersand used to pass the parser by reference.

Mea Culpa. Yes, the patch was backwards. My apologies.

-- 
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 18460] Allow anchor (a) tags in wikitext (currently prevented)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18460

p858snake p858sn...@gmail.com changed:

   What|Removed |Added

 CC||p858sn...@gmail.com

--- Comment #8 from p858snake p858sn...@gmail.com 2011-01-15 00:54:43 UTC ---
(In reply to comment #7)
 (In reply to comment #5)
  Titles/tooltips: span title
  Jump-to-anchors: span id
 
 You're aware that MediaWiki itself uses a, not span for anchors? For
 example, in the page source there is a id=top/a. I can't remember the
 exact reason why this was implemented in this way, but I do recall there being
 one.
AFAIK that was to keep BC with IE something (5.x?) which we no longer support
that different like using another method. As for your example, That is the only
one I can quickly see in the page source I'm looking at (A fairly simple low
content page (Cop_This! on en.wikip)) and everywhere else appears to use divs
or spans for their id'ing and anchoring.

That example also seems redundant (at least in vector) because the content div
is declared directly on top of it and we double id that to be both content and
top if we really wanted to.

eg a section header w/ edit link
 h2span class=editsection[a 
 href=/w/index.php?title=Cop_This!amp;action=editamp;section=1 title=Edit 
 section: Synopsisedit/a]/span span class=mw-headline 
 id=SynopsisSynopsis/span/h2


As for the a title= part of this discussion, I believe that is decrapulated
by the current standards, and when used with most (if not all?) browsers when
wrapping text it will be displayed as a hyper-link even if not pointing
somewhere. The only benefit of it, That i can think of is that its shorter.

-- 
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 26614] action=parse shows different sortkey then one outputted by prop=categories (prefix vs actual binary sortkey)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26614

--- Comment #6 from Reedy s...@reedyboy.net 2011-01-15 01:01:18 UTC ---
This isn't actually an API par se, it's more the parser sort of.

Where is it actually output from a parse query? I can't see it anywhere
obviously.

bug 24650 has been fixed now.

Where are these actually used anywhere by anyone? I'm poking around, and have
logged bug 26736 as a related bug, depending on this perceived usefulness..

Especially, as per Aryeh, it may move further from being a human readable
thing, which is probably useless.


++---+
| cl_sortkey | cl_sortkey_prefix |
++---+
| FULLTWOLOW |   |
| MAIN 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 11281] Allow more/fewer than 200 pages to be viewed at once in a category

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=11281

Bawolff bawolff...@gmail.com changed:

   What|Removed |Added

 CC||bawolff...@gmail.com

--- Comment #1 from Bawolff bawolff...@gmail.com 2011-01-15 01:09:35 UTC ---
Note, $wgCategoryPagingLimit can be set in LocalSettings.php for something
other then 200, but it sounds like you're looking for a non-hard coded limit.

-- 
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 26737] New: new category stuff doesn't play nicely with __NOGALLERY__ magic word (specifically paging doesn't work)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26737

   Summary: new category stuff doesn't play nicely with
__NOGALLERY__ magic word (specifically paging doesn't
work)
   Product: MediaWiki
   Version: 1.17
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Normal
 Component: Categories
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: bawolff...@gmail.com
CC: simetrical+wikib...@gmail.com
Blocks: 26611


If you put __NOGALLERY__ in a category page (with images), the paging doesn't
work properly.

Images are listed with normal articles. Since we are now paging them
separately, I'd expect them in their own section (but in a list not in a
gallery).

Clicking next 200, gets next 200 articles, but the same images are still there.

If there are more than 200 images, there are no paging links for images.

-- 
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 26611] Bugs that should be fixed for 1.17 WMF deployment (tracking)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26611

Bawolff bawolff...@gmail.com changed:

   What|Removed |Added

 Depends on||26737

-- 
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 18460] Allow anchor (a) tags in wikitext (currently prevented)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=18460

--- Comment #9 from Bawolff bawolff...@gmail.com 2011-01-15 01:34:47 UTC ---
The other usecase i could see is to make the microformat people happy.

-- 
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 26737] new category stuff doesn't play nicely with __NOGALLERY__ magic word (specifically paging doesn't work)

2011-01-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=26737

--- Comment #1 from Bawolff bawolff...@gmail.com 2011-01-15 01:46:18 UTC ---
Note, feature works on 1.16 and is in use on commons:
http://commons.wikimedia.org/wiki/Category:Music_sound

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


  1   2   >