[Bug 17090] Site notice has layout problem with links in the upper edge.
https://bugzilla.wikimedia.org/show_bug.cgi?id=17090 --- Comment #2 from Purodha Blissenbach bugzilla.wikime...@publi.purodha.net 2009-01-20 08:30:36 UTC --- Unless we get to know how to change (translate) the CentralNotice (-: and access to changing it :-) I'd suggest to disable that rather than the local one. Seriously, I do not object having both, of course. I simply was not aware that we have two kinds of sitenotices now, indeed. The problem reported here is abot the (top most) CentralNotice only. Its two links at the upper edge are not properly aligned. That applies to all WikiMedia wikis, I've seen so far. -- 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 17091] New: Block log entry truncated
https://bugzilla.wikimedia.org/show_bug.cgi?id=17091 Summary: Block log entry truncated Product: MediaWiki Version: unspecified Platform: All URL: http://ksh.wikipedia.org/wiki/Spezial:Jesperrt?uselang=e n OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: bugzilla.wikime...@publi.purodha.net CC: bugzilla.wikime...@publi.purodha.net I blocked a user with auto-IP block, giving a reference to the offending edit (replaced President Obamas Picture with an apes picure yet another time) as an URL of his/her edit diff. Unfortunately, the URL became truncated, rendering its remainder uttely useless, as you can see below. While I cannot object limiting log entry sizes to something reasonable, I'd suggest to either: - lift the limit considerably so as to accomodate the standard texts plus an URL. - warn the blocking admin before his entry gets truncated so as to allow her/him to find a sensible replacement. * 09:19, 20 January 2009, Purodha (Talk | contribs | block) blocked #147 (expires 09:19, 21 January 2009, account creation blocked) (Automatich jesperrt. Ding IP_Adress wood vör kootem vun däm Metmaacher „Black gangsta panther“ jebruch. Dä es jesperrt woode wäje: „ihät motwellesch Shtuß en Sigge erin jeschrevve: http://ksh.wikipedia.org/w/in) (unblock) * 09:19, 20 January 2009, Purodha (Talk | contribs | block) blocked Black gangsta panther (Talk | contribs) (expires 09:19, 20 July 2009, account creation blocked) (hät motwellesch Shtuß en Sigge erin jeschrevve: http://ksh.wikipedia.org/w/index.php title=Barack_Obamadiff=1027385oldid=1026653) (unblock | change block) -- 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 16921] Comments may be cut off on page moves and page protections
https://bugzilla.wikimedia.org/show_bug.cgi?id=16921 Raimond Spekking raimond.spekk...@gmail.com changed: What|Removed |Added CC||bugzilla.wikime...@publi.pur ||odha.net --- Comment #6 from Raimond Spekking raimond.spekk...@gmail.com 2009-01-20 08:46:34 UTC --- *** Bug 17091 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 17091] Block log entry truncated
https://bugzilla.wikimedia.org/show_bug.cgi?id=17091 Raimond Spekking raimond.spekk...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Raimond Spekking raimond.spekk...@gmail.com 2009-01-20 08:46:34 UTC --- *** This bug has been marked as a duplicate of bug 16921 *** -- 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 17075] Type:date should support ISO output format
https://bugzilla.wikimedia.org/show_bug.cgi?id=17075 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Severity|major |enhancement Status|NEW |ASSIGNED Priority|Normal |High Summary|Date not readable by #time |Type:date should support ISO ||output format --- Comment #2 from Markus Krötzsch mar...@semantic-mediawiki.org 2009-01-20 08:53:24 UTC --- I change the contents of this feature request as follows: Type:Date should have an option to select an output format in inline queries (and #show) that conforms to the ISO date specification. The original request, that ''all'' Type:date outputs should be understood by #time is (at best) a bug for #time. It cannot be the goal of SMW to constrict its date support to the limitations of #time. SMW's dates now cover a far larger range (outside of Unix time) and support international date formatting. So it won't be possible, in general, to have #time support all dates that are available in SMW, due to the limitations of strtotime(). It would still be good to have an option to get ISO conformant output. Changing this bug into a (high priority) feature request. -- 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 17053] Hiding log entries with RevisionDelete does not automatically hide the corresponding page history entry
https://bugzilla.wikimedia.org/show_bug.cgi?id=17053 --- Comment #2 from Happy-melon happy_me...@hotmail.co.uk 2009-01-20 08:56:10 UTC --- Well you can pick them up based on timestamp and confirm by comparing the summaries, or we could try to link them; maybe we could use rev_parent_id to link to the log entry, although I'm not 100% sure what that's used for, and there's no reciprocal arrangement (although we couldn't set reciprocal links without three database commits anyway). Remember that these are not arbitrary: if you're hiding a log entry, you *know* how many null revisions are associated with it - for a protect/unprotect/modifyprotect, there's one and for a move there's three - the corresponding move log entry for the other end of the move, and null revisions in both pages' histories. It shouldn't be too hard to locate these and track them down. -- 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 17092] New: Autoblock expiry time versus admin selected block expiry time.
https://bugzilla.wikimedia.org/show_bug.cgi?id=17092 Summary: Autoblock expiry time versus admin selected block expiry time. Product: MediaWiki Version: unspecified Platform: All URL: http://ksh.wikipedia.org/wiki/Spezial:Jesperrt?uselang=e n OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Blocking AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: bugzilla.wikime...@publi.purodha.net CC: bugzilla.wikime...@publi.purodha.net After a user was blocked with auto-IP block, two similar log messages were generated, the later of which is an autoblock message. The wiki block the IP address for a day, while the user per his/her name was blocked for months, i.e. considerably longer. Since autoblocks may be seen in relation to dynamically assigned IP-addresses, this may be a good decision. However, if the admin selected a consideralby shorter period than a day, an autoblock of 1 day would be inappropriate. If that is automatically taken care of (which I did not find a sample for), then this is not-a-bug. On the other hand, I'd see it as a feature request, of low priority though, to make autoblock durations selectable, too, since at times, you know about the typical lifetime of connections, a specific provider has in specific ones of his IP ranges. Here are the log entries FYI: * 09:19, 20 January 2009, Purodha (Talk | contribs | block) blocked #147 (expires 09:19, 21 January 2009, account creation blocked) (Automatich jesperrt. Ding IP_Adress wood vör kootem vun däm Metmaacher „Black gangsta panther“ jebruch. Dä es jesperrt woode wäje: „ihät motwellesch Shtuß en Sigge erin jeschrevve: http://ksh.wikipedia.org/w/in) (unblock) * 09:19, 20 January 2009, Purodha (Talk | contribs | block) blocked Black gangsta panther (Talk | contribs) (expires 09:19, 20 July 2009, account creation blocked) (hät motwellesch Shtuß en Sigge erin jeschrevve: http://ksh.wikipedia.org/w/index.php title=Barack_Obamadiff=1027385oldid=1026653) (unblock | change block) -- 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 17090] Site notice has layout problem with links in the upper edge.
https://bugzilla.wikimedia.org/show_bug.cgi?id=17090 --- Comment #3 from p858snake p858sn...@yahoo.com.au 2009-01-20 09:18:08 UTC --- Created an attachment (id=5709) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=5709) showing additional bugs -- 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 17090] Site notice has layout problem with links in the upper edge.
https://bugzilla.wikimedia.org/show_bug.cgi?id=17090 p858snake p858sn...@yahoo.com.au changed: What|Removed |Added CC||p858sn...@yahoo.com.au --- Comment #4 from p858snake p858sn...@yahoo.com.au 2009-01-20 09:20:20 UTC --- Above attachment shows the bugs where theres: A) a blank line so its not vertical aligned B) the top border hits the page tabs border creating a 2px border on it in some pages. This can easily be fixed by adding a pixel or two in between to separate them. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16921] Comments may be cut off on page moves and page protections
https://bugzilla.wikimedia.org/show_bug.cgi?id=16921 --- Comment #7 from Purodha Blissenbach bugzilla.wikime...@publi.purodha.net 2009-01-20 09:55:41 UTC --- This becomes even worse, inho, with the selectable custom-made comments that are installation/localization dependant. It is also bad in the context of blocks, where you often want to refer to an edit (i.e. an URL of a diff) which is put behind the custom comment. The most significant part, oldid=x, is truncatd most likely. :-( A too restrictive solution was, to subtract punctuation and the longest message size from the count of available characters, and output it as the lenght restriction of the (additional) comment field to the browser, in the hope that it honors the parameter. Since that can be pretty easily implemented, it might be a solution to cope with until a better solution was developped. Better was to warn the user of the possible truncation (like one can be warned when an edit comment was omitted on a normal page edit, if one chooses so in ones preferences), letting him know of the allowance, the number of characters truncated, set the input field size, and if he alters his message, recycle until all fits, or an unaltered message comes a 2nd time. Best was, to allow longer comments per increased data base field length. -- 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 17031] Sanitizer rejects valid xhtml attributes
https://bugzilla.wikimedia.org/show_bug.cgi?id=17031 Garrett gbr...@ucla.edu changed: What|Removed |Added Summary|Sanitizer rejects identifies|Sanitizer rejects valid |valid xhtml attributes |xhtml attributes -- 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 17077] Sysop and bureaucrat rights not effective after adding user via UserLoadFromSession hook .
https://bugzilla.wikimedia.org/show_bug.cgi?id=17077 Sam Sexton puheli...@googlemail.com changed: What|Removed |Added CC||puheli...@googlemail.com --- Comment #2 from Sam Sexton puheli...@googlemail.com 2009-01-20 10:28:09 UTC --- What appears to be the same problem has been reported just below my submission to the Support Desk at http://www.mediawiki.org/wiki/Project:Support_desk/Sections/Extension#Help_please.21_Sysop_users_dont_have_permissions.21. I have asked for further information and will also go now and do some more digging. -- 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 17031] Sanitizer rejects valid xhtml attributes
https://bugzilla.wikimedia.org/show_bug.cgi?id=17031 Garrett gbr...@ucla.edu changed: What|Removed |Added Keywords||need-review -- 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 17077] Sysop and bureaucrat rights not effective after adding user via UserLoadFromSession hook .
https://bugzilla.wikimedia.org/show_bug.cgi?id=17077 --- Comment #3 from Sam Sexton puheli...@googlemail.com 2009-01-20 11:43:28 UTC --- I've just installed the NamespacePermissions extension and the groups required for that are similarly affected. i.e. I (as Sam.Sexton) am in the ns100RW group, but can't create a page in that namespace. As SS I can do so. So, it looks to be a general group permission problem rather than specific to Sysops and Bureaucrats - as expected, but I thought it best to verify. -- 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 17077] Sysop and bureaucrat rights not effective after adding user via UserLoadFromSession hook .
https://bugzilla.wikimedia.org/show_bug.cgi?id=17077 --- Comment #4 from Sam Sexton puheli...@googlemail.com 2009-01-20 14:23:12 UTC --- I've added some debug code to getRights() in User.php and am getting close to the problem: this-effectiveGroup: * this-effectiveGroup: user this-effectiveGroup: autoconfirmed but I'm now in oodles of groups (as Sam.Sexton): (first | last) View (previous 50) (next 50) (20 | 50 | 100 | 250 | 500) * SS (bureaucrat, nsIGRW, sysop) * Sam.Sexton (bureaucrat, nsARCHRW, nsARCH_TalkRW, nsD3PRIVRW, nsD3PRIV_TalkRW, nsDEVRW, nsDEV_TalkRW, nsDOCRW, nsDOC_TalkRW, nsIGRW, nsIG_TalkRW, sysop) * West.Sst-noreply * WikiSysop (bureaucrat, sysop) (first | last) View (previous 50) (next 50) (20 | 50 | 100 | 250 | 500) Hmm - I have had a problem with phpMyAdmin reporting the absence of mcrypt (due to build problems which I reported many weeks ago, but have had no response - I'll go back and try again or see if there's a later version). I would be a little surprised if this were related to the problem, but would feel guilty not mentioning 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 17084] E-mail notifications are sent on every change ( currently a wrong behaviour)
https://bugzilla.wikimedia.org/show_bug.cgi?id=17084 Tom Gries m...@tgries.de changed: What|Removed |Added Severity|enhancement |critical Priority|Normal |High Version|1.15-svn|1.14-svn --- Comment #1 from Tom Gries m...@tgries.de 2009-01-20 14:48:19 UTC --- I increased the severity level, because this function is still misbehaving for an unknown reason, as it currently sends for every change of watched pages (if the user has opted-in to email and email notification). Current version http://www.mediawiki.org/wiki/Special:Version is 1.14alpha -- 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 17094] New: [[[Special:PrefixIndex]] ignores trailing spaces ( or underscores)
https://bugzilla.wikimedia.org/show_bug.cgi?id=17094 Summary: [[[Special:PrefixIndex]] ignores trailing spaces (or underscores) Product: MediaWiki Version: 1.14-svn Platform: All URL: http://meta.wikimedia.org/w/index.php?prefix=A_title=Sp ecial:PrefixIndex OS/Version: All Status: NEW Severity: minor Priority: Normal Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: q...@roger.net.ru Of course, URLs like http://meta.wikimedia.org/wiki/Special:PrefixIndex/A_ are quickly “normalized” to http://meta.wikimedia.org/wiki/Special:PrefixIndex/A by server, although formally (and intuitively) it should mean names starting not just from the letter “A”, but only from the word “A” followed by space. But the bug lies not in URL normalization. http://meta.wikimedia.org/w/index.php?title=Special:PrefixIndexprefix=A_ gives the same output. Even if prefix= is passed not as last argument (so _ is not a last character in the query string), then trailing space in it is silently discarded. -- 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 17077] Sysop and bureaucrat rights not effective after adding user via UserLoadFromSession hook .
https://bugzilla.wikimedia.org/show_bug.cgi?id=17077
--- Comment #5 from Sam Sexton puheli...@googlemail.com 2009-01-20 15:39:39
UTC ---
I've now added some additional code to my hook, to show the real name and
groups after loading the user from the database. I really a PHP novice, so it's
possible I'm not doing this properly, but the relevant code is:
// Load the existing or newly-created user from the database ...
if ( !$user-loadFromDatabase() ) {
logTGST(loadFromDatabase failed for user ID $user-mId);
} else { // Additional debugging ...
logTGST(loadFromDatabase succeeded for user ID $user-mId);
logTGST( real name: $user-mRealName);
logTGST( groups: $user-mGroups);
}
return $user
and the logged output is:
2009-01-20 15:33:37 loadFromDatabase succeeded for user ID 1004
2009-01-20 15:33:37 real name: Sam Sexton
2009-01-20 15:33:37 groups:
So it would _appear_ that either I'm interpreting what getGroups() does
incorrectly, or the group membership is not being recognised correctly. Any
suggestions?!
--
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 17095] New: Allow users to receive e-mail notifications once a day, once a week and new occurrences
https://bugzilla.wikimedia.org/show_bug.cgi?id=17095 Summary: Allow users to receive e-mail notifications once a day, once a week and new occurrences Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: User preferences AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: heldergeov...@gmail.com Currently, every time a page someone is watching is edited, he receive an e-mail notification about that. So, if by any chance lots of pages in his watch list is edited in a day, his inbox will be crowded of e-mails! I would like to have a way of set how often I want to receive the notifications. Good options would be: * new occurrences * once a week * once a day (or even once # days) What do you think about it? [[b:User:Heldergeovane]] -- 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 15227] action=upload should be added to the API
https://bugzilla.wikimedia.org/show_bug.cgi?id=15227 --- Comment #9 from Roan Kattouw roan.katt...@home.nl 2009-01-20 18:21:03 UTC --- (In reply to comment #8) Just as a note, I committed a test version to the new-upload branch. This does not cover Roan's notes as stated in comment #7. Yup, saw it. I'm actively fixing up your API module and parts of your upload branch right now. -- 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 17064] Make Drafts optional
https://bugzilla.wikimedia.org/show_bug.cgi?id=17064 Aryeh Gregor simetrical+wikib...@gmail.com changed: What|Removed |Added CC||simetrical+wikib...@gmail.co ||m --- Comment #9 from Aryeh Gregor simetrical+wikib...@gmail.com 2009-01-20 19:49:23 UTC --- (In reply to comment #8) Eh? We have an option to disable the AJAX search suggestions, too. :P AJAX search suggestions override the browser's recent searches feature, so they actually have an appreciable downside. This does not. The bandwidth of sending a small amount of text every 120 seconds is negligible for practically anyone. If it's not negligible for you, you probably can't edit most Wikipedia articles anyway without at least disabling JS. There is absolutely no example given by anyone so far of how their Wikipedia-editing experience is concretely affected in a negative fashion by having drafts enabled. Until someone comes up with that, I'll support WONTFIX. Preferences should not be added without good reasons: every preference does have a cost in complexity to the user, and in maintenance (extra code paths to check). -- 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 17096] New: Allowing HotCat gadget to add more than one category at a time
https://bugzilla.wikimedia.org/show_bug.cgi?id=17096 Summary: Allowing HotCat gadget to add more than one category at a time Product: MediaWiki Version: unspecified Platform: All URL: http://en.wikinews.org/wiki/MediaWiki:Gadgets- definition#editing-gadgets OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Categories AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: dragonfire1...@gmail.com I am not sure if this is the place for this, but will submit a report anyways. Report for HotCat gadget to be revised to allow additions of more than one category at a time, on en.wikinews.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 17025] Get value of $wgFileExtensions through the API
https://bugzilla.wikimedia.org/show_bug.cgi?id=17025 Brion Vibber br...@wikimedia.org changed: What|Removed |Added CC||br...@wikimedia.org --- Comment #3 from Brion Vibber br...@wikimedia.org 2009-01-20 21:47:14 UTC --- This probably should check if file uploads are actually allowed. :) -- 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 17097] New: DynamicPageList. php call a function not existing in mediawiki 1.14
https://bugzilla.wikimedia.org/show_bug.cgi?id=17097 Summary: DynamicPageList.php call a function not existing in mediawiki 1.14 Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: major Priority: Normal Component: DynamicPageList AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: un1c0...@gmail.com In link 453 of DynamicPageList.php is called link function on a Skin object: $output .= $sk-link($title, htmlspecialchars($titleText), array(), $query, array( 'forcearticlepath', 'known' ) ); In mediawiki of version older than 1.14 this function don't exist and cause this error message: Fatal error: Call to undefined method SkinMonoBook::link() in /var/www/wiki/extensions/DynamicPageList.php on line 459 The problem begin from this commit: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/intersection/DynamicPageList.php?r1=41411r2=41044 -- 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 5280] Oddly named talk pages cannot be unwatched via Special:Watchlist /edit
https://bugzilla.wikimedia.org/show_bug.cgi?id=5280 --- Comment #7 from Brion Vibber br...@wikimedia.org 2009-01-20 22:14:43 UTC --- (This was redone in r45780) Better, but not quite there; it's still allowing pages like 'Talk:Wikipedia:Foo', for which 'Wikipedia:Foo' is an interwiki link. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 17098] New: Add Haskell syntax highlighting
https://bugzilla.wikimedia.org/show_bug.cgi?id=17098 Summary: Add Haskell syntax highlighting Product: Wikimedia Version: unspecified Platform: All URL: http://en.wikipedia.org OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: ger.bruyn...@hotpop.com While editing a Wikipedia article, I tried to use Haskell syntax highlighting with the source tag, but a message about not supporting Haskell was displayed. The page: http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi says that Haskell syntax highlighting exists. -- 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 17035] Check PHP file_uploads settings in Special:Upload
https://bugzilla.wikimedia.org/show_bug.cgi?id=17035 --- Comment #8 from Brion Vibber br...@wikimedia.org 2009-01-20 23:03:19 UTC --- Ahh, that's so much better than just mysteriously failing. :D Thanks! -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 17053] Hiding log entries with RevisionDelete does not automatically hide the corresponding page history entry
https://bugzilla.wikimedia.org/show_bug.cgi?id=17053 --- Comment #3 from Mr.Z-man mrzmanw...@gmail.com 2009-01-20 23:04:30 UTC --- The problem is that the summary in the page history is dependent on a system message, which can be edited, so also can't be guaranteed to be consistent. And as I said, there's no guarantee that timestamps are going to be the same, if you have a protection-conflict on a page, you might have 1 null revision made at the same time a different protection log entry was created. You could compare the user to the log, but its still adding more convolutions. The fact that you know how many null revisions there are doesn't really help all that much. If there's only 1 it makes it easier, but it doesn't really help in establishing a relationship between a log entry and a revision. The only thing I can see that would distinguish a log-null-revision from a normal edit is that rev_len is null, though this is null (I think) for all revisions before it was implemented (sometime in the last couple years I think), so could potentially have issues with older wikis. Also, I'm quite sure if its supposed to be null now, or if that was just an omission when adding the column (null revision adding uses a different function than real revision adding). If its the latter, then its not a reliable option for future revisions either. The other, potentially big, problem, is that logs, since they can apply to deleted and non-existent pages, as well as special pages, use titles rather than pageids. So when a page is moved, the null revisions from the history are now associated with one title (revisions use pageid), while the logs will be associated with another. So when searching for the null revision, it would have to check if the page has been moved, then check if that page has been moved, etc. New pages can be created over the old title though, potentially causing more problems (and those can be moved and the title resused, etc, etc) It would also have to check the archive table for deleted revs, if it can't find it in the revision table. Doing it the other way around, searching from null revision to log entry would have the same problems. -- 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 16867] API: Autoconfirmation
https://bugzilla.wikimedia.org/show_bug.cgi?id=16867 Gurch matthew.brit...@btinternet.com changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #7 from Gurch matthew.brit...@btinternet.com 2009-01-20 23:05:55 UTC --- and reverted. (r45940) -- 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 17099] New: Red-link “discussi on” tab indicated by colour only
https://bugzilla.wikimedia.org/show_bug.cgi?id=17099 Summary: Red-link “discussion” tab indicated by colour only Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: User interface AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mich...@zajac.ca Blocks: 367 When a page has no discussion yet, this status is indicated by the red colour of the “Discussion” link in the tab at the top, but not by other means. This is an accessibility blocker, because information conveyed by colour must also be indicated in text or markup: Priority 1 in WCAG 1.0 (http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-color-convey), Level A in WCAG 2.0 (http://www.w3.org/TR/WCAG20/#visual-audio-contrast-without-color). This could be fixed simply by appending “(page does not exist)” to the title attribute as is done for red links in the body of a page, or by changing the title from “Discussion about the content page” to “Start discussion about the content page”. -- 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 367] Markup accessibility issues (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=367 Michael Zajac mich...@zajac.ca changed: What|Removed |Added Depends on||17099 -- 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 457] Clean up use of header tags in MonoBook skin UI elements
https://bugzilla.wikimedia.org/show_bug.cgi?id=457 Michael Zajac mich...@zajac.ca changed: What|Removed |Added CC||mich...@zajac.ca Blocks||367 --- Comment #18 from Michael Zajac mich...@zajac.ca 2009-01-21 00:31:41 UTC --- This blocks accessibility (Bug 367). Ideally, the headings should be nested in order without skipping any—this deficiency blocks WCAG 1.0 AA and AAA conformance. The site subtitle (h3#siteSub) is not a heading organizing the document or describing the content below, so it shouldn't be marked up as a heading element at all—this blocks WCAG 1.0 AA and AAA, WCAG 2.0 AA and AAA conformance. WCAG 1.0 requires headings to be used and nested correctly (Priority 2, http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-logical-headings) WCAG 2.0 requires headings to describe topic and purpose (AA, http://www.w3.org/TR/WCAG20/#navigation-mechanisms-descriptive) and section headings to organize a document (AAA, http://www.w3.org/TR/WCAG20/#navigation-mechanisms-headings). Proper nesting is recommended, but not required (http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G141). -- 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 367] Markup accessibility issues (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=367 Michael Zajac mich...@zajac.ca changed: What|Removed |Added Depends on||457 -- 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 457] Clean up use of header tags in MonoBook skin UI elements
https://bugzilla.wikimedia.org/show_bug.cgi?id=457 --- Comment #19 from Michael Zajac mich...@zajac.ca 2009-01-21 00:58:07 UTC --- Although WCAG 2.0 doesn't require proper nesting, having sidebar boxes (h5) contained within the last article section (if it's headed by h2, h3, or h4) is an incorrect representation of the document structure, and arguably breaks WCAG 2.0 AAA conformance. the h5's should be changed to h2's, below the page title (h1), and at the same level as the article's main section subheadings (h2). Of course the CSS skins should be adjusted so the presentation remains the same. -- 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 17100] New: parserTest output inherits categories from previous parserTests
https://bugzilla.wikimedia.org/show_bug.cgi?id=17100 Summary: parserTest output inherits categories from previous parserTests Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Categories AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: amelior...@viennan.net Take the following parser test: !! article Category:Foo !! text Foo !! endarticle !! article Category:Bar !! text Bar !! endarticle !! test Category1 !! options cat !! input [[Category:Foo]] !! result a href=/wiki/Category:Foo title=Category:FooFoo/a !! end !! test Category2 !! options cat !! input [[Category:Bar]] !! result a href=/wiki/Category:Bar title=Category:BarFoo/a !! end Both of theses should pass as each only contains one category, however the result is Reading tests from maintenance/parserTests.txt... Running test Category1... PASSED Running test Category2... FAILED! --- /tmp/mwParser-774531766-expected2009-01-21 00:48:24.0 + +++ /tmp/mwParser-774531766-actual 2009-01-21 00:48:24.0 + @@ -1 +1 @@ -a href=/wiki/Category:Bar title=Category:BarBar/a +a href=/wiki/Category:Foo title=Category:FooFoo/a a href=/wiki/Category:Bar title=Category:BarBar/a The result for the second test is inheriting the category from the first test causing it to fail. When run individually they work fine; r...@vector:/var/www/phase3# php maintenance/parserTests.php --regex Category1 This is MediaWiki version 1.15alpha (r45920). Reading tests from maintenance/parserTests.txt... Running test Category1... PASSED Passed 1 of 1 tests (100%)... ALL TESTS PASSED! r...@vector:/var/www/phase3# php maintenance/parserTests.php --regex Category2 This is MediaWiki version 1.15alpha (r45920). Reading tests from maintenance/parserTests.txt... Running test Category2... PASSED Passed 1 of 1 tests (100%)... ALL TESTS PASSED! -- 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 17101] New: Wikimedia badge alt text should match image text
https://bugzilla.wikimedia.org/show_bug.cgi?id=17101 Summary: Wikimedia badge alt text should match image text Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: trivial Priority: Normal Component: User interface AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mich...@zajac.ca Blocks: 367 The Wikimedia badge image at the bottom of the template “A Wikimedia project” has alt text “Wikimedia Foundation”. The alt text should be adjusted to match the graphic text. WCAG 1.0 requires “equivalent text”, and the Samurai Errata specifically requires “an alt text of exactly the same text.” WCAG 2.0 states “when an image contains words that are important to understanding the content, the alt text should include those words.” -- 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 367] Markup accessibility issues (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=367 Michael Zajac mich...@zajac.ca changed: What|Removed |Added Depends on||17101 -- 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 1181] Section edit bug where entire article is overwritten on save
https://bugzilla.wikimedia.org/show_bug.cgi?id=1181 Aaron Schulz jschulz_4...@msn.com changed: What|Removed |Added 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 16025] Call to undefined method SimpleCaptcha::showImage()
https://bugzilla.wikimedia.org/show_bug.cgi?id=16025 Aaron Schulz jschulz_4...@msn.com changed: What|Removed |Added CC||jschulz_4...@msn.com Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Aaron Schulz jschulz_4...@msn.com 2009-01-21 01:26:07 UTC --- Fixed in r45957 -- 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 17102] New: Changelog build tool for CodeReview
https://bugzilla.wikimedia.org/show_bug.cgi?id=17102 Summary: Changelog build tool for CodeReview Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CodeReview AssignedTo: jschulz_4...@msn.com ReportedBy: br...@wikimedia.org I would find it handy to be able to automatically or semi-automatically build a list of new changes in the software when we run updates. The easiest way would be to diff the RELEASE-NOTES file and just spit out all the new entries -- but people frequently forget to update it, and important things don't get listed. A tool to slurp together lines from accepted revisions in core code and whitelisted extensions and build a first-draft what's new list would be pretty helpful. Alternately, a nice bug needs release notes button to plug on any rev. ;) -- 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 8217] Language code of Taiwanese/Holo, Cantonese, Classical Chinese Wikipedias (yue, nan, lzh)
https://bugzilla.wikimedia.org/show_bug.cgi?id=8217 Dylan Wong itsminecook...@gmail.com changed: What|Removed |Added Summary|Language code of|Language code of |Taiwanese/Holo, Cantonese, |Taiwanese/Holo, Cantonese, |Classical Chinese Wikipedias|Classical Chinese Wikipedias |(yue, nan) |(yue, nan, lzh) --- Comment #21 from Dylan Wong itsminecook...@gmail.com 2009-01-21 04:50:42 UTC --- http://www.sil.org/iso639-3/chg_detail.asp?id=2008-089lang=zho http://www.sil.org/iso639-3/cr_files/2008-089_lzh.pdf The exactly ISO 639-3 code of Literary Chinese (Classical Chinese) is lzh, please make a redirect as lzh.wikipedia.org to zh-classical.wikipedia.org, thanks! -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 8217] Language code of Taiwanese/Holo, Cantonese, Classical Chinese Wikipedias (nan, yue, lzh)
https://bugzilla.wikimedia.org/show_bug.cgi?id=8217 Dylan Wong itsminecook...@gmail.com changed: What|Removed |Added Summary|Language code of|Language code of |Taiwanese/Holo, Cantonese, |Taiwanese/Holo, Cantonese, |Classical Chinese Wikipedias|Classical Chinese Wikipedias |(yue, nan, lzh) |(nan, yue, lzh) -- 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 17096] Allowing HotCat gadget to add more than one category at a time
https://bugzilla.wikimedia.org/show_bug.cgi?id=17096 --- Comment #1 from Jason dragonfire1...@gmail.com 2009-01-21 05:37:36 UTC --- Maybe have a limit of lets say 10 at a time? Could maybe add a feature so that someone can have the option of pulling down/roll down another addition. -- 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 17096] Allowing HotCat gadget to add more than one category at a time
https://bugzilla.wikimedia.org/show_bug.cgi?id=17096 Mike.lifeguard mikelifegu...@fastmail.fm changed: What|Removed |Added CC||mikelifegu...@fastmail.fm Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Mike.lifeguard mikelifegu...@fastmail.fm 2009-01-21 05:48:37 UTC --- HotCat is not a component of MediaWiki. Please ask the users who maintain the javascript (they are probably administrators) regarding this issue. -- 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 15493] syntax errors with MSSQL
https://bugzilla.wikimedia.org/show_bug.cgi?id=15493 Nathanael mediaw...@polymorpheus.com changed: What|Removed |Added Attachment #5692 is|0 |1 obsolete|| --- Comment #7 from Nathanael mediaw...@polymorpheus.com 2009-01-21 06:52:39 UTC --- Created an attachment (id=5711) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=5711) Patched DatabaseMssql.php -- 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 17098] Add Haskell syntax highlighting
https://bugzilla.wikimedia.org/show_bug.cgi?id=17098 Raimond Spekking raimond.spekk...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Raimond Spekking raimond.spekk...@gmail.com 2009-01-21 07:29:01 UTC --- The Wikimedia servers are running an older version of GeSHi syntax highlighting: Note that installed GeSHi version (can be revealed by previewing e.g. source lang=-/source) might not be the most recent version; see bugzilla:10967 for Wikimedia sites. An update to the newest version is requested in bug 10967. *** This bug has been marked as a duplicate of bug 10967 *** -- 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 10967] Upgrade to the latest version of GeSHi (1.0.8)
https://bugzilla.wikimedia.org/show_bug.cgi?id=10967 Raimond Spekking raimond.spekk...@gmail.com changed: What|Removed |Added CC||ger.bruyn...@hotpop.com --- Comment #5 from Raimond Spekking raimond.spekk...@gmail.com 2009-01-21 07:29:01 UTC --- *** Bug 17098 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
