[Bug 18434] New: Enable the rollback feature on Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=18434 Summary: Enable the rollback feature on Commons Product: Wikimedia Version: unspecified Platform: All URL: http://commons.wikimedia.org/wiki/Commons:Rollback OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: nurtsch-c...@gmx.de Please enable the rollback feature on Commons (in the manner of the one on en.wikipedia) making it possible for sysops to assign/revoke rollback rights to users. *Community consent: http://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2009Feb#Rollback *Policy: http://commons.wikimedia.org/wiki/Commons:Rollback Thank you. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18434] Enable the rollback feature on Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=18434 Reedy s...@reedyboy.net changed: What|Removed |Added Component|General/Unknown |Site requests 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 18435] New: Enable AbuseFilter on Finnish Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=18435 Summary: Enable AbuseFilter on Finnish Wikipedia Product: Wikimedia Version: unspecified Platform: All URL: http://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(käyt ännöt)#Abuse_filter OS/Version: All Status: NEW Keywords: shell Severity: enhancement Priority: Normal Component: Site requests AssignedTo: agarr...@wikimedia.org ReportedBy: str...@wmfbz.mail.kapsi.fi Fiwiki would like the AbuseFilter extension installed with default settings per this consensus: http://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(käytännöt)#Abuse_filter -- 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 6952] Migrate some safe config options to similar in-wiki settings
https://bugzilla.wikimedia.org/show_bug.cgi?id=6952 Happy-melon happy-me...@live.com changed: What|Removed |Added CC||happy-me...@live.com --- Comment #3 from Happy-melon happy-me...@live.com 2009-04-12 12:51:32 UTC --- This is [[mw:Extension:Configure]]. -- 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 18436] New: div#mw-js-message should not use inline style display: block;
https://bugzilla.wikimedia.org/show_bug.cgi?id=18436
Summary: div#mw-js-message should not use inline style display:
block;
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: Watchlist
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: sylvain.brune...@gmail.com
When I add a page to my watchlist by clicking watch tab, a message appears
(div#mw-js-message.mw-js-message-watch) (“The page ... has been added to
your watchlist. [...]”) to indicate that the page has been added.
I tried to add “div#mw-js-message.mw-js-message-watch { display: none; }”
to my monobook.css, because I wanted to automatically hide this message.
Unfortunately, this div uses an inline style display: block;, which stops any
attempt to hide it using CSS.
I think this inline style is not necessary, it could probably be easily
replaced by using other CSS methods.
Please forgive me if I'm wrong, or if the problem has been mentioned yet.
--
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 18437] New: Subpages not activated on enwiki ns 13 15, although enabled in config
https://bugzilla.wikimedia.org/show_bug.cgi?id=18437
Summary: Subpages not activated on enwiki ns 13 15, although
enabled in config
Product: Wikimedia
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Normal
Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: happy-me...@live.com
Preview {{BASEPAGENAME}} on [[Category talk:Foo/bar]]:
Expected: Foo
Actual: Foo/bar
Ditto for [[Help talk:Foo/bar]]. This is indicative that subpages are not
enabled in these namespaces, despite them being explicitly enabled in WM config
(InitialiseSettings.php). I'm not sure if this is a software bug or a
Wikimedia config 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 18437] Subpages not activated on enwiki ns 13 15, (broken declarations in InitialiseSettings)
https://bugzilla.wikimedia.org/show_bug.cgi?id=18437 Happy-melon happy-me...@live.com changed: What|Removed |Added Keywords||shell Summary|Subpages not activated on |Subpages not activated on |enwiki ns 13 15, although |enwiki ns 13 15, (broken |enabled in config |declarations in ||InitialiseSettings) --- Comment #1 from Happy-melon happy-me...@live.com 2009-04-12 15:19:05 UTC --- Davidgothberg identified (http://en.wikipedia.org/w/index.php?diff=283357047) the source of the issue: the per-wiki overrides in InitialiseSettings don't have the complete namespace array, yet by defining a whole array it means the default settings are completely lost. So the line for enwiki reads: 'enwiki'= array(-1=0, 0=0, 1=1, 2=1, 3=1, 4=1, 5=1, 6=0, 7=1, 8=0, 9=1, 10=1, 11=1, 100=1, 101=1), This does not include namespaces 12-15, but the defaults defined in 'default' above are overridden; thus in ns 13 15, where we would expect subpages, we don't get any. The line needs to be changed to: 'enwiki'= array(-1=0, 0=0, 1=1, 2=1, 3=1, 4=1, 5=1, 6=0, 7=1, 8=0, 9=1, 10=1, 11=1, 12=0, 13=1, 14=0, 15=1, 100=1, 101=1), The other wikis where customisation has been made should be fixed too. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18437] Subpages not activated on enwiki ns 13 15, although enabled in config
https://bugzilla.wikimedia.org/show_bug.cgi?id=18437 Andrew Garrett agarr...@wikimedia.org changed: What|Removed |Added CC||agarr...@wikimedia.org Status|NEW |RESOLVED Keywords|shell | Resolution||INVALID Summary|Subpages not activated on |Subpages not activated on |enwiki ns 13 15, (broken |enwiki ns 13 15, although |declarations in |enabled in config |InitialiseSettings) | --- Comment #2 from Andrew Garrett agarr...@wikimedia.org 2009-04-12 15:24:20 UTC --- 'wgNamespacesWithSubpages' = array( ... 'enwiki'= array(-1=0, 0=0, 1=1, 2=1, 3=1, 4=1, 5=1, 6=0, 7=1, 8=0, 9=1, 10=1, 11=1, 100=1, 101=1), It's *not* explicitly enabled in InitialiseSettings.php. If you want subpages in these namespaces, you're going to have to check that nobody minds, and then post a site request. -- 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 18436] div#mw-js-message should not use inline style display: block;
https://bugzilla.wikimedia.org/show_bug.cgi?id=18436 Danny B. dann...@email.cz changed: What|Removed |Added Blocks||12788 -- 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 12788] CSS (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=12788 Danny B. dann...@email.cz changed: What|Removed |Added Depends on||18436 -- 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 11040] Add redirecting page based wg variable(s) to page JS variables
https://bugzilla.wikimedia.org/show_bug.cgi?id=11040 --- Comment #5 from sylvain.brune...@gmail.com 2009-04-12 15:41:32 UTC --- @AlexSm: I think many of the wg- JS variables don't give informations that we cannot get by using DOM or API (wgServer, wgUserName, wgUserLanguage, wgVersion...). But it's more simple and elegant to use generated JS variables, isn't 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 18429] Allow filter rules to consider private data such as source IP, reverse DNS and user agent.
https://bugzilla.wikimedia.org/show_bug.cgi?id=18429 Andrew Garrett agarr...@wikimedia.org changed: What|Removed |Added Summary|Extra functions for |Allow filter rules to |AbuseFilter |consider private data such ||as source IP, reverse DNS ||and user agent. --- Comment #4 from Andrew Garrett agarr...@wikimedia.org 2009-04-12 14:47:26 UTC --- Discussed this on IRC with FT2. My general comments on the outcome of that discussion (from my perspective, FT2 may have different opinions): 1/ Adding additional hierarchy to AbuseFilter is a pain, both programmatically and socially. 2/ The fact that the abuse filter log is viewable by all users is a core principle guiding the Abuse Filter. It is critical that all filters may be assessed on their performance, if not on their construction. Smaller groups/cabals of checkusers, oversighters and what-not may have good intentions, but without the accountability of having the impact of filters assessed by the wider community. Smaller cabals encourage groupthink, and create an environment which may ease carelessness or outright negligence in filter construction. 3/ It would be technically trivial to hide variables containing private data from the abuse filter log, in order to allow them to be sent to filters. 4/ There are concerns (as expressed by Gurch) that the abuse filter log for filters using private data could allow users not identified to the Foundation to guess private information, or at least part of it (for instance, that a particular user edits from a particular IP range). The privacy policy permits disclosure of private data for the purposes of preventing and monitoring abuse of editing privileges, and covers only personally identifiable information. Residing on a particular range is not by itself personally identifiable information, although it may be private information; and while the user-agent header sent by a user is not public data, I would not really classify it as private, per-se, and certainly not personally identifiable. Accordingly, I believe the benefits of hiding log entries for rules considering private data are outweighed by the detrimental effect on filter use transparency (see point 2). -- 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 18437] Subpages not activated on enwiki ns 13 15, although enabled in config
https://bugzilla.wikimedia.org/show_bug.cgi?id=18437 --- Comment #3 from Happy-melon happy-me...@live.com 2009-04-12 15:51:36 UTC --- Only if you assume that the arrays are 'correct' and not an honest mistake by someone who thought the defaults above would 'shine through'. The same could be said of any bug: the only difference between a bug and a feature is that a bug wasn't expected behavior :D If the arrays are *supposed* to be like that why do they *all* contain the namespaces 1-11, even when they're set to the same as the WM and/or MW default, but only some contain the higher namespaces? Equally likely that they were initialised before we added the Help and Category namespaces and someone forgot to update the config when they were brought in. Given that there hasn't AFAIK been *any* discussion on the topic, at least on enwiki, what would have prompted them to be *explicitly* set away from the MW default (which is for subpages in all talkspaces)?? The situation makes no sense unless you consider the arrays to be incomplete, in which case they should be expanded with the MW default in the absence of community consensus to the contrary; right now they're been explicitly overridden *away* from the MW defaults for no reason. We're looking on VPT at enabling subpages in Help:, you're quite right that that's a change from the default which will need consensus and a site request. But I don't believe it's logically defensible to claim that the situation as it stands is the intended behavior, hence bug, not feature. I disagree with your close. -- 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 6952] Migrate some safe config options to similar in-wiki settings
https://bugzilla.wikimedia.org/show_bug.cgi?id=6952 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #4 from Roan Kattouw roan.katt...@gmail.com 2009-04-12 13:54:30 UTC --- (In reply to comment #3) This is [[mw:Extension:Configure]]. Closing this as fixed; please open separate bugs to request more features in Configure or for Configure to be enabled on WMF wikis. -- 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 18437] Subpages not activated on enwiki ns 13 15, although enabled in config
https://bugzilla.wikimedia.org/show_bug.cgi?id=18437 --- Comment #4 from Andrew Garrett agarr...@wikimedia.org 2009-04-12 16:13:54 UTC --- I closed the bug as INVALID because the bug as filed was invalid. I don't think anybody expects a full-blown vote on such a trivial matter, just a general note somewhere prominent that the behaviour will be changing, and a check to see if anybody objects, as with most configuration changes. -- 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 18438] New: Tweak HTML for preview bar (patch)
https://bugzilla.wikimedia.org/show_bug.cgi?id=18438 Summary: Tweak HTML for preview bar (patch) Product: MediaWiki Version: 1.15-svn Platform: All OS/Version: All Status: NEW Keywords: need-review, patch Severity: enhancement Priority: Normal Component: Page rendering AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: happy-me...@live.com Created an attachment (id=6018) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6018) patch against r49247 Currently it's difficult to effectively customise the appearance of the notice that displays when previewing a page; the h2 preview header (and the previewconflict header when it appears) is unidentified and appears outside the div class=previewnote that contains the remember this is only a preview message. Changes in this patch: 1) assign IDs for both h2s so they can be identified individually 2) move both h2s inside the previewnote div so it forms a clearer semantic grouping; move the text-indent:3em CSS rule to the inner p so it doesn't screw up the h2 indentation 3) use an hr instead of a bottom margin; semantically clearer and probably better from an accessibility PoV. -- 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 18437] Subpages not activated on enwiki ns 13 15, although enabled in config
https://bugzilla.wikimedia.org/show_bug.cgi?id=18437 --- Comment #5 from Happy-melon happy-me...@live.com 2009-04-12 16:55:51 UTC --- The issue described is that the actual behaviour doesn't match with what was clearly intended, my first assessment was that the config settings weren't being correctly parsed; then DG pointed out that it was actually that they weren't correctly set in the first place. If the bug summary doesn't accurately describe the issue, then rewrite the summary. Closing as INVALID is saying that you don't consider the *underlying issue* to be a bug and that the current software behavior is correctly expressing the *intention* of the developer who initialised the system. As I said above, I can't agree with that assertion, it makes no logical sense. -- 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 18439] Special:AllMessages crashes X or KDE
https://bugzilla.wikimedia.org/show_bug.cgi?id=18439 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2009-04-12 18:19:15 UTC --- Yes, Special:Allmessages is too big, that's a known bug (see duplicate notice). The fact that KDE crashes because of it is KDE's fault, though: web pages can be huge, and clients should deal with that appropriately. *** This bug has been marked as a duplicate of bug 16497 *** -- 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 16497] Paginate Special:AllMessages
https://bugzilla.wikimedia.org/show_bug.cgi?id=16497 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||mediaw...@blazemonger.com --- Comment #12 from Roan Kattouw roan.katt...@gmail.com 2009-04-12 18:19:15 UTC --- *** Bug 18439 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 15389] Special:AllMessages is too large
https://bugzilla.wikimedia.org/show_bug.cgi?id=15389 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com Blocks|16497 | -- 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 16497] Paginate Special:AllMessages
https://bugzilla.wikimedia.org/show_bug.cgi?id=16497 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Depends on|15389 | -- 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 18440] New: Trivial error in the italian translation
https://bugzilla.wikimedia.org/show_bug.cgi?id=18440 Summary: Trivial error in the italian translation Product: MediaWiki Version: 1.15-svn Platform: All OS/Version: All Status: NEW Keywords: easy, patch Severity: trivial Priority: Normal Component: Internationalization AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: ste.c...@gmail.com Created an attachment (id=6019) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6019) Fix There is a trivial error in the italian translation, the patch is attached. -- 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 18440] Trivial error in the italian translation
https://bugzilla.wikimedia.org/show_bug.cgi?id=18440 Raimond Spekking raimond.spekk...@gmail.com changed: What|Removed |Added CC||raimond.spekk...@gmail.com Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Raimond Spekking raimond.spekk...@gmail.com 2009-04-12 19:02:17 UTC --- Please check your patch, I do not see any difference in the message. It seems identical to http://translatewiki.net/wiki/MediaWiki:Tog-newpageshidepatrolled/it too. Please reopen the bug with a new patch or become a translator at translatewiki.net. Thank a lot. -- 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 18440] Trivial error in the italian translation
https://bugzilla.wikimedia.org/show_bug.cgi?id=18440 --- Comment #2 from Stefano Codari ste.c...@gmail.com 2009-04-12 19:04:22 UTC --- The difference is dell' that became dall' (5th word) -- 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 18440] Trivial error in the italian translation
https://bugzilla.wikimedia.org/show_bug.cgi?id=18440 Stefano Codari ste.c...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | -- 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 18440] Trivial error in the italian translation
https://bugzilla.wikimedia.org/show_bug.cgi?id=18440 Raimond Spekking raimond.spekk...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #3 from Raimond Spekking raimond.spekk...@gmail.com 2009-04-12 19:09:12 UTC --- Sorry, my error. I compared the old version with translatewiki. Fixed in translatewiki.net: http://translatewiki.net/w/i.php?title=MediaWiki:Tog-newpageshidepatrolled/itdiff=1177722oldid=1005179 Will be committed into MediaWiki SVN with the next sync. Thanks for your bugreport. -- 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 18415] Enable the AbuseFilter on the Alemannic Wikipedia [alswiki]
https://bugzilla.wikimedia.org/show_bug.cgi?id=18415 --- Comment #1 from Melancholie wiki.melancho...@web.de 2009-04-12 20:25:24 UTC --- Is there a waiting time? -- 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 18429] Allow filter rules to consider private data such as source IP, reverse DNS and user agent.
https://bugzilla.wikimedia.org/show_bug.cgi?id=18429 Gurch matthew.brit...@btinternet.com changed: What|Removed |Added CC||matthew.brit...@btinternet.c ||om --- Comment #5 from Gurch matthew.brit...@btinternet.com 2009-04-12 20:40:42 UTC --- (In reply to comment #4) Residing on a particular range is not by itself personally identifiable information, although it may be private information; and while the user-agent header sent by a user is not public data, I would not really classify it as private, per-se, and certainly not personally identifiable. You're right, it wouldn't (at least in most cases) count as such. Though it could be used to determine, say, where a user is from. While I personally don't care who knows that, I know there are a lot of people out there who do -- imagine a Contributors from XYZ filter with IP ranges that geolocate to that place, in a private filter looking for (or claiming to look for) a particular abusive user from that area. Now any legitimate user editing from XYZ gets an entry in the abuse log linking their username to place XYZ, and that log entry is visible to everyone, not just admins. It's not exactly Checkuser but it's more disclosure than there currently is (I lack the patience and legal expertise to figure out exactly what the privacy policy's take is on this :) Not sure what user-agent header has to do with anything, that (usually) only identifies the user's browser and OS. Though I am aware checkusers also have access to that information, I don't know what they do with it nor why anyone would want to use it for an abuse filter. -- 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 18374] In log, link to diff of edit/log entry for action when edit/action succeeded
https://bugzilla.wikimedia.org/show_bug.cgi?id=18374 --- Comment #4 from Gurch matthew.brit...@btinternet.com 2009-04-12 20:57:05 UTC --- I've worked around this for my purposes (read recent changes and abuse log, match up items on username and page title, works 99% of the time) so don't worry too much about it. Would probably be considered nice to have in the UI 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 17240] history.js blocks gecko browser with 100% CPU when rendering long history
https://bugzilla.wikimedia.org/show_bug.cgi?id=17240 Jorge Stolfi sto...@ic.unicamp.br changed: What|Removed |Added CC||sto...@ic.unicamp.br --- Comment #5 from Jorge Stolfi sto...@ic.unicamp.br 2009-04-12 21:50:14 UTC --- Sorry to ask, but --- will this bug be fixed eventually, or am I expected to fix it by editing my profile somehow? (I use the standard MonoBook skin with Firefox 3.0.8/Gecko 2009033116) All the best, --stolfi -- 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 18270] Red Links for Userpage/Talk
https://bugzilla.wikimedia.org/show_bug.cgi?id=18270
--- Comment #10 from Platonides platoni...@gmail.com 2009-04-12 22:05:41 UTC
---
No, the problem is with IIS configuration, overriding the 404 page.
You can use this testcase:
?php
header(HTTP/1.x 404 Not Found);
echo 'Nothing here, go to the a href=/main page/a';
?
The above php should show the text Nothing here, go to the main page, but
with your configuration, it'll show the default IIS 404 error.
As a woraround, you can remove from Article.php the lines 841-843:
if( $return404 ) {
$wgRequest-response()-header( HTTP/1.x 404 Not Found );
}
but it is NOT recommended.
The server config should be fixed instead.
--
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 18441] New: rebuildrecentchanges.inc ignores $wgLogRestrictions, adding private logs to RC
https://bugzilla.wikimedia.org/show_bug.cgi?id=18441 Summary: rebuildrecentchanges.inc ignores $wgLogRestrictions, adding private logs to RC Product: MediaWiki Version: 1.15-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Maintenance scripts AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: jida...@jidanni.org In RecentChange.php there is code # Don't add private logs to RC! if( isset($wgLogRestrictions[$type] ... However there is no corresponding code in rebuildrecentchanges.inc. (or they don't go thru a common interface). So running it will expose what was meant to be hid. -- 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 18364] array of boring event types to exclude from recentchanges
https://bugzilla.wikimedia.org/show_bug.cgi?id=18364 --- Comment #9 from jida...@jidanni.org 2009-04-12 22:11:02 UTC --- Some findings when looking for a workaround to showing new account creation: $wgNewUserLog=false will stop new entries from being added, but won't clean up the present ones. And one doesn't want to disable logging of new users just to keep them out of RC. So one turns to $wgLogRestrictions['newusers']='editinterface' just to keep them out of RC, but this does not clean up the present ones, nor does rebuildrecentchanges.php (Bug #18441) help. Probably must resort to a hook... -- 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 18442] New: DefaultSettings.php $wgLogRestrictions doc improvements
https://bugzilla.wikimedia.org/show_bug.cgi?id=18442 Summary: DefaultSettings.php $wgLogRestrictions doc improvements Product: MediaWiki Version: 1.15-svn Platform: All OS/Version: All Status: NEW Keywords: patch Severity: trivial Priority: Normal Component: Documentation AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: jida...@jidanni.org Created an attachment (id=6020) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6020) minor doc improvements -- 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 18429] Allow filter rules to consider private data such as source IP, reverse DNS and user agent.
https://bugzilla.wikimedia.org/show_bug.cgi?id=18429 --- Comment #6 from FT2 ft2.w...@gmail.com 2009-04-12 22:32:36 UTC --- Now any legitimate user editing from XYZ gets an entry in the abuse log linking their username to place XYZ, and that log entry is visible to everyone, not just admins. Incorrect, or else, overlooked the comment on this. See original suggestion: It would be trivial to ensure that a filter function that used the 'user_ip' variable could not be created, nor its logs/history read, by any except checkusers. -- 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 18443] New: auto-insert of whitespace
https://bugzilla.wikimedia.org/show_bug.cgi?id=18443 Summary: auto-insert of whitespace Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: email_metawiki_...@wg-karlsruhe.de CC: raimond.spekk...@gmail.com Problem: There are several places where (thin) non-breaking spaces should be inserted, e.g., between numbers and units. Of course, there exist different spacing rules in different countries. Up to now, inserting thin spaces still leads to problems: nbsp is generally too large, thinsp and U+202f won't be displayed in the wanted way using opera and so on; see e.g. [http://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Typographie_(Zwischenr%C3%A4ume)#Browser-Unterst.C3.BCtzung] (german). There are possibilities to display thin non-breaking spaces by using some html/css tricks, see [http://de.wikipedia.org/wiki/Schmales_Leerzeichen#.C3.9Cbergangsl.C3.B6sungen]. But that would complicate the source of articles too much. Solution: At http://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia/Archiv/2009/Woche_01#.26nbsp.3B (german, but with php source-code) the idea was given to use (localized) regexps for automatically inserting of whitespace in some cases. With this modification we could easily auto-insert even sophisticated things like [http://de.wikipedia.org/wiki/Schmales_Leerzeichen#.C3.9Cbergangsl.C3.B6sungen] without obfuscating the article source code. But: Maybe such a thing would slow down the parsing of wikitext, so I guess it would be the best to implement the idea at test-wiki first. Somebody should profile the parsing after those changes. I could help in generating some fast regexps. -- 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 9767] Microsoft SQL Server/MSSQL support (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=9767 --- Comment #62 from Aryeh Gregor simetrical+wikib...@gmail.com 2009-04-13 00:29:29 UTC --- I guess you should re-request commit access. I don't think you were denied because anyone wanted to deny you -- probably the request just got lost at some point, because granting commit access is one facet of the MediaWiki development process that seems to be particularly dysfunctional right now. If you still want it, I'd remind Brion and/or Tim every month or two if we don't get a saner system in place soon. -- 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. You are the assignee for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 18444] New: Allow modification of default chunk size for low-use svn repositories
https://bugzilla.wikimedia.org/show_bug.cgi?id=18444 Summary: Allow modification of default chunk size for low-use svn repositories Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Keywords: patch Severity: enhancement Priority: Normal Component: CodeReview AssignedTo: jschulz_4...@msn.com ReportedBy: stwalkers...@googlemail.com Created an attachment (id=6021) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6021) CodeReview chunksize config variable For svn repositories where the commit rate is fairly low, a chunk size of 400 is probably way to big to begin with. If the svnImport script is run every 10 minutes or so, then a chunk size of 20 is probably still too big. However, for larger setups, a chunk size of 400 is probably more useful. The solution to this is to make the chunk size configurable, by adding an option $wgCodeReviewImportChunkSize, by default at 400 (the original value). This will allow other users of CodeReview to customize the maximum number of revisions to be pulled in each update. -- 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 18445] New: Additional wgCaptchaRegexes entry
https://bugzilla.wikimedia.org/show_bug.cgi?id=18445 Summary: Additional wgCaptchaRegexes entry Product: Wikimedia Version: unspecified Platform: All URL: http://meta.wikimedia.org/wiki/User:Mike.lifeguard/malbo ts OS/Version: All Status: NEW Keywords: shell Severity: normal Priority: Normal Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mikelifegu...@fastmail.fm CC: mikelifegu...@fastmail.fm Please add: $wgCaptchaRegexes[] = '/Good (?:site|post), admin/'; Tracking pages (this one is for generation 6) in the URL field. -- 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 18364] array of boring event types to exclude from recentchanges
https://bugzilla.wikimedia.org/show_bug.cgi?id=18364 Mike.lifeguard mikelifegu...@fastmail.fm changed: What|Removed |Added CC||jschulz_4...@msn.com --- Comment #10 from Mike.lifeguard mikelifegu...@fastmail.fm 2009-04-13 03:49:48 UTC --- (In reply to comment #2) Note that this is already done for patrol log entries, so there is precedent (although 'patrol' is just hardcoded right now IIRC). There's also a boolean parameter to the LogPage constructor (IIRC) that suppresses creation of an RC entry. I don't think that it is hardcoded, though I can't find the commit presently. IIRC, Aaron added that, so I've CCed him. -- 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
