[Bug 21512] CREDITS file uses wrong transliteration of family name
https://bugzilla.wikimedia.org/show_bug.cgi?id=21512 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added CC||alex.emsenhu...@bluewin.ch Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Alexandre Emsenhuber [IAlex] 2009-11-15 07:53:51 UTC --- Fixed in r59084. -- 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 21514] New: IPv6 on secure.wikimedia.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=21514 Summary: IPv6 on secure.wikimedia.org Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: ipv6 Severity: normal Priority: Normal Component: DNS AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: liang...@gmail.com Is it ok to configure an IPv6 address on secure.wikimedia.org? Maybe this is easier. It can work as a forwarder, just like what it does on HTTPS 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 21339] Transclusion from pages built by a template
https://bugzilla.wikimedia.org/show_bug.cgi?id=21339 --- Comment #1 from Steve Sanbeg 2009-11-15 05:05:28 UTC --- The extension works by retrieving the template, extracting the section, and then doing the normal parse, which would cause any templates in the section to be transcluded. This feature would require doing some kind of recursive template substitution before extracting sections and parsing, which make make it slower without being useful for the normal case. But this does come up form time to time, so it may be useful to have either another function or an argument to the existing function to do this. -- 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 21513] New: Index of Wikisaurus pages truncated.
https://bugzilla.wikimedia.org/show_bug.cgi?id=21513 Summary: Index of Wikisaurus pages truncated. Product: Wikimedia Version: unspecified Platform: All URL: http://en.wiktionary.org/wiki/Wiktionary:All_Wikisaurus_ pages OS/Version: All Status: NEW Severity: major Priority: Normal Component: Downloads AssignedTo: tf...@wikimedia.org ReportedBy: rb_wiktion...@theboults.net This page has some sort of script to display all the pages in Wikisaurus. However, since the number of Wikisaurus entries now exceeds the number that can be displayed on one page, the list runs out at G. Someone "merged" the code for Special:AllPages and Special:PrefixIndex a while ago, in the mistaken idea that they were improving things; they broke a number of things in the process, and now no-one seems to be interested in fixing any of them. Marked as makor as it inhibits use of Wikisaurus, not being able to access most of it by Index. -- 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 2585] Server should return a 404 HTTP status code if the page does not exist
https://bugzilla.wikimedia.org/show_bug.cgi?id=2585 --- Comment #31 from jida...@jidanni.org 2009-11-15 02:28:38 UTC --- As of r59081 for regular pages it still breaks if one appends a %25E9 to the URL: $ GET -PSd http://taizhongbus.jidanni.org/index.php?title=NOSUCHPAGE GET http://taizhongbus.jidanni.org/index.php?title=NOSUCHPAGE --> 404 Not Found $ GET -PSd http://taizhongbus.jidanni.org/index.php?title=NOSUCHPAGE%25E9 GET http://taizhongbus.jidanni.org/index.php?title=NOSUCHPAGE%25E9 --> 200 OK -- 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 21512] CREDITS file uses wrong transliteration of family name
https://bugzilla.wikimedia.org/show_bug.cgi?id=21512 --- Comment #1 from Karun Dambietz 2009-11-15 00:37:07 UTC --- Created an attachment (id=6785) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6785) patch to fix name I have attached a patch that corrects 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 21512] New: CREDITS file uses wrong transliteration of family name
https://bugzilla.wikimedia.org/show_bug.cgi?id=21512 Summary: CREDITS file uses wrong transliteration of family name Product: MediaWiki Version: 1.16-svn Platform: All OS/Version: All Status: NEW Keywords: need-review Severity: trivial Priority: Normal Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: ka...@linux.com Hello, The correct spelling of my family name in the CREDITS file should be Dambietz -- 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 21215] NoLocalSettings.php sometimes fails to display the MW logo
https://bugzilla.wikimedia.org/show_bug.cgi?id=21215 --- Comment #2 from Karun Dambiec 2009-11-15 00:02:23 UTC --- Created an attachment (id=6784) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6784) Patch for review I have completed a patch that fixes the relative path. It needs 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 21215] NoLocalSettings.php sometimes fails to display the MW logo
https://bugzilla.wikimedia.org/show_bug.cgi?id=21215 Karun Dambiec changed: What|Removed |Added Keywords||easy, need-review, patch -- 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 21215] NoLocalSettings.php sometimes fails to display the MW logo
https://bugzilla.wikimedia.org/show_bug.cgi?id=21215 --- Comment #1 from Karun Dambiec 2009-11-14 23:57:32 UTC --- >From looking at includes/templates/NoLocalSettings, it prefixes skins/common/images/mediawiki.png with the $path variable. As it is relative, I propose removing $path from the image source. -- 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 21215] NoLocalSettings.php sometimes fails to display the MW logo
https://bugzilla.wikimedia.org/show_bug.cgi?id=21215 Karun Dambiec changed: What|Removed |Added CC||ka...@linux.com Status|NEW |ASSIGNED -- 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 20812] Wikisource: IPs unable to flag articles as "proofread"
https://bugzilla.wikimedia.org/show_bug.cgi?id=20812 --- Comment #12 from joergens.mi 2009-11-14 23:36:00 UTC --- This seems to be the solution, we have been begging for in the german wikisource. Could anyone be so polite to help Buxul T. to test it and if it's ok activate in wikisource. I think it would be usefull to set the default for $wgProofreadPageAllowIPs to false. This wouldn't change anything for the existing projects. And the projects, which wants to deviate can set this to true. -- 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 18923] uploadcorrupt error message is vague and confusing
https://bugzilla.wikimedia.org/show_bug.cgi?id=18923 Karun Dambiec changed: What|Removed |Added AssignedTo|ka...@linux.com |wikibugs- ||l...@lists.wikimedia.org Status|ASSIGNED|NEW -- 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 21510] Increase $wgAccountCreationThrottle for uem wikiweek
https://bugzilla.wikimedia.org/show_bug.cgi?id=21510 Platonides changed: What|Removed |Added Summary|Increase|Increase |$wgAccountCreationThrottle |$wgAccountCreationThrottle |for uem wikiweel|for uem wikiweek -- 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 21511] Document all parameters that can be used in LocalSettings.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=21511 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #1 from Roan Kattouw 2009-11-14 22:56:28 UTC --- We're aware of this, there's some FIXME comments in the README file. While we do make an effort to make our code usable for other people, it's not our top priority, especially while MediaWiki 1.16 hasn't been released yet. So we'll get to documenting stuff properly eventually, but it could take some more time. -- 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 21226] Make Navigable TOC collapsible
https://bugzilla.wikimedia.org/show_bug.cgi?id=21226 Roan Kattouw changed: What|Removed |Added CC||tpars...@wikimedia.org --- Comment #4 from Roan Kattouw 2009-11-14 21:17:14 UTC --- (In reply to comment #3) > Hmm, doesn't seem to work on e.g. > http://prototype.wikimedia.org/d-en/index.php?title=Taliban&action=edit . > I tested it on my local wiki, and by setting > $wgNavigableTOCCollapseEnable = true; > in LocalSettings.php I got the button to appear, but it seems broken. When > clicking it, the NTOC text disappears, but the edit area is not resized. The > button also disappears, so there is no way to get the text back. > Yes, the collapsing of the NTOC is sort of broken at the moment (was much worse before I took a stab at it); this is a known issue that was probably caused by one of Trevor's restructurings, so either he or Adam should fix it. CCing Trevor for this reason. -- 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 21511] New: Document all parameters that can be used in LocalSettings.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=21511 Summary: Document all parameters that can be used in LocalSettings.php Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: thomasble...@gmx.de CC: wikibugs-l@lists.wikimedia.org While trying out a new version of the UsabilityInitiative extension, I found that some variables that can be set in LocalSettings.php are not documented. They should be added to the README file. Specifically, at least the following settings are undocumented: $wgDefaultUserOptions['wikieditor-highlight'] = 1; $wgDefaultUserOptions['wikieditor-preview'] = 1; $wgDefaultUserOptions['usebetatoolbar'] = 1; $wgDefaultUserOptions['usebetatoolbar-cgd'] = 1; $wgNavigableTOCCollapseEnable = true; $wgNavigableTOCResizable = true; There may be more which I didn't find. -- 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 21226] Make Navigable TOC collapsible
https://bugzilla.wikimedia.org/show_bug.cgi?id=21226 Thomas Bleher changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #3 from Thomas Bleher 2009-11-14 20:52:03 UTC --- Hmm, doesn't seem to work on e.g. http://prototype.wikimedia.org/d-en/index.php?title=Taliban&action=edit . I tested it on my local wiki, and by setting $wgNavigableTOCCollapseEnable = true; in LocalSettings.php I got the button to appear, but it seems broken. When clicking it, the NTOC text disappears, but the edit area is not resized. The button also disappears, so there is no way to get the text back. Tested with the following settings: $wgDefaultUserOptions['skin'] = 'vector'; $wgDefaultUserOptions['usenavigabletoc'] = 1; $wgDefaultUserOptions['wikieditor-highlight'] = 1; $wgDefaultUserOptions['wikieditor-preview'] = 1; $wgDefaultUserOptions['usebetatoolbar'] = 1; $wgDefaultUserOptions['usebetatoolbar-cgd'] = 1; $wgNavigableTOCCollapseEnable = true; $wgVectorUseSimpleSearch = true; $wgEnableJS2system = true; // the following are old IIRC $wgEditToolbarGlobalEnable = true; $wgEditToolbarCGDGlobalEnable = true; $wgNavigableTOCGlobalEnable = true; $wgEditToolbarUserEnable = false; phase3 r59072, UsabilityInitiative r59048 (i.e. from today) Tested using Iceweasel 3.0.6 on Debian Lenny. -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 --- Comment #15 from Siebrand 2009-11-14 19:46:38 UTC --- This is a bug tracker. The bug is clear, and as stated in comment 12, we only expect tech related follow-ups. Failure to comply may result in having your commenting rights in this bug tracker revoked, and previous off topic comments removed. Thank you for your cooperation. -- 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 13287] "Edit" link not working as expected
https://bugzilla.wikimedia.org/show_bug.cgi?id=13287 --- Comment #13 from Philippe Verdy 2009-11-14 19:39:31 UTC --- In simple words: separate clearly the short gadget description string that appears in the Preferences tab, from the full pagename describing it. Make them into two separate ressources, also localizable separately (and still customizable on local wikis that will want to provide their own help page). And drop all links from the short localizable description strings as they are irrelevant. -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 Platonides changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #14 from Platonides 2009-11-14 19:38:13 UTC --- Commit access is not related to Wiki(p|m)edia Community. If WMF decides to hire Andrew to make LiquidThreads work, you can object to it. But really, you're making too much noise for nothing. There was a bug, it was fixed. Please, go on. He has done much more good for liquidthreads than bad. PS: if you're so email sensitive, you can disable being sent emails... -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 --- Comment #13 from Philippe Verdy 2009-11-14 19:33:21 UTC --- Commit access is cannot be reliably given without taking the community into consideration (this is the community that gives them the power to continue their work, and notably those developers that are paid by the Foundation through the donations made by the community, or those that are nominated under the control of the bureau members elected by the community). If they feel that what was made was damaging, they will reject the change and will want the change to be reverted. And even if it is not reverted in the SVN repository, wiki admins will still be able to revert the changes that their local community don't want (and SVN developers will have absolutely no right to force the change on wikis they do not control). And yes, saying that is not an insult, and it is not personnal as this is a matter of policy applicable to anyone. A policy is not a threat. -- 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 9816] Improve security for Special:Userlogin (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=9816 --- Comment #28 from Philippe Verdy 2009-11-14 19:06:56 UTC --- "I do not believe in restricting user's passwords to force them to be stronger: users choose their own passwords, as wisely or as unwisely as they want". Did I suggest that? No. I exactly propose to help user to choose their password wisely, and in fact more freeely that what the other suggestions below are doing, because I don't want to force users to use a mix of capital/lowercase letters, or digits. The algorithm will be relaxed enough to allow users to choose whatever characters they want, or the password length they want, or even pass phrases (when accepting spaces), WITHOUT reducing the search space (in fact it does NOT restrict the search space, but increases it by allowing MORE freedom for users, and MORE difficulties for password crackers). And I also give caution that dictionnary lookups are bad if the dictionnary is wellknown and is enforced in a restrictive way (because it will actually help the password crackers if it is enforced). -- 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 9816] Improve security for Special:Userlogin (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=9816 --- Comment #27 from Philippe Verdy 2009-11-14 18:59:52 UTC --- Note that for dictionnary lookups (when evaluating the bit-length strength), there's already good dictionnaries available: you may just check the existence of the word in an article in the main space of the list of existing Wiktionnaries that have more than about 1 entries. This just requires a single http request per tested wiki. Then the actual computed bit-length strength can be reduced to the base-2 logarithm of the tested Wiktionnary sizes (measured as the number of articles in the main space of the tested wikis, summed together, or to their logarithmic average). The computed numeric value should also be made visible (and should be recomputed each time the user visits its Preferences page, if the algorithm is later updated), in addition to the color-coded visual evaluation of that value (such as, black: insufficient and not acceptable, red: strong warning, yellow: acceptable, green: good, blue: strong). -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #12 from Roan Kattouw 2009-11-14 18:51:24 UTC --- (In reply to comment #11) > This is not "random rants". But clear statements about the negative impact of > the bug, and what it has effectively caused. At the point where we know something is a bug, we don't need another half dozen complaints about how bad it really is, we just care about fixing it. This is why comments on Bugzilla should be technical in nature, either suggesting a solution or pointing out a new incarnation of the bug. You've just been enumerating why one thing (sending people lots of e-mails) is bad, while we all agreed it was a bad thing before you started doing that; hence, these comments are useless. > I have also not insulted anyone (not like the words you just used that are > really unfriendly). Oh really? How about your threat in comment #6 (a totally unrealistic one I might add) to have developers who make a mistake blocked, excluded and stripped of their commit access? (For clarity: the community has no authority over commit access, so any developers potentially scared by this threat need not worry; I expect most know better, though.) Please evaluate whether your comments add something new to the technical discussion, and are not useless like illustrated above, before posting them to Bugzilla. I will now stop responding to any comments that only contain rants or threats, and I suggest others don't take them seriously either (whether to respond is up to them, of course). -- 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 20347] Flood flag for Stragetic Planning
https://bugzilla.wikimedia.org/show_bug.cgi?id=20347
Henk van Deelen changed:
What|Removed |Added
CC||h...@glind.nl
--- Comment #4 from Henk van Deelen 2009-11-14 18:51:00 UTC ---
I could realy use this as I regalarly maitain a lot of pages. Examples:
MediaWiki for site specific translations
[http://strategy.wikimedia.org/w/index.php?title=Special%3APrefixIndex&prefix=Task+forces&namespace=8
like this], or like today when I renamed all english pages to {pagename}/en for
introducing Autotranslate.
--
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 21510] New: Increase $wgAccountCreationThrottle for uem wikiweel
https://bugzilla.wikimedia.org/show_bug.cgi?id=21510 Summary: Increase $wgAccountCreationThrottle for uem wikiweel Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: shell Severity: normal Priority: Normal Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: platoni...@gmail.com Per [[Ticket:2009111310045971]], please increase the number of accounts able to be created ($wgAccountCreationThrottle) at eswiki from 193.147.239.254 ([[European_University_of_Madrid]]) during the week of November the 30, since they will be performing an activity called 'wikiweek' during which they expect many new accounts to be created. This has been done in the past (look for 'Account creation throttle disabled for outreach event' on CommonSettings) but seems that the origin ip wasn't taken into account. -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 --- Comment #11 from Philippe Verdy 2009-11-14 18:42:55 UTC --- This is not "random rants". But clear statements about the negative impact of the bug, and what it has effectively caused. And don't say that I am spamming your mailbox, because you have opted in to receive all comments, and becaause I am not writing to you only, Andrew Garrett. You are not the single recipient, and others may still need to have the opinions of others than just you, before posting similar opinions. As long as the bug is open, other comments will come, confirming it, or proposing other solutions, or evaluating the proposed solutions (and even if YOU consider it closed because you think it was supposed resolved by you, others will still have to evaluate your solution). I have also not insulted anyone (not like the words you just used that are really unfriendly). The concept of the "Emergency Red button" on the WMF mail server(s), as well as its active monitoring, was still not discussed here, and is also part of the solution (to also help prevent future similar bugs), that's why I consider it "helpful" (both technically and as a policy) and clearly not "ranting". -- 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 9816] Improve security for Special:Userlogin (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=9816 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #26 from Roan Kattouw 2009-11-14 18:40:33 UTC --- (In reply to comment #25) > I also don't like captchas. But please don't force users to use at least one > digit or something like that, because instead of increasing the security it > will actually reduce the search space. > > Instead I propose this: > [snip huge proposal] Per comment #18, please open new bugs for new proposals. I'll add as a quick side note that I do not believe in restricting user's passwords to force them to be stronger: users choose their own passwords, as wisely or as unwisely as they want. This is their own responsibility. We can and should help keep their passwords from being compromised by using SSL on every login; I believe there's already an open bug for that. -- 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 9816] Improve security for Special:Userlogin (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=9816 Philippe Verdy changed: What|Removed |Added CC||verd...@wanadoo.fr Priority|High|Normal --- Comment #25 from Philippe Verdy 2009-11-14 18:32:40 UTC --- I also don't like captchas. But please don't force users to use at least one digit or something like that, because instead of increasing the security it will actually reduce the search space. Instead I propose this: (1) convert the password at least to Unicode NFC (and apply any other suitable normalization like compression of whitespaces). Possibly even to NFKC (to avoid compatibility characters). If that password, after normalization, is different from what the user typed, make sure to inform the user to confirm that this is what is happening. (2) compute the basic size S of the alphabet : - if a lowercase ASCII letter is used anywhere in the password, add 26 to the the alphabet size - if an uppercase ASCII letter is used anywhere in the password, add 26 to the the alphabet size - if a decimal ASCII digit is used anywhere in the password, add 10 to the the alphabet size - if a ASCII punctuation is used anywhere in the password, add the size of this ASCII punctuation subset to the alphabet size. - on localized wikis, consider other subsets consisting in non-ASCII letters used in their alphabet (take CLDR data appropriate for that language, remove the characters already part of the previous subsets, and then add the remaining characters to the basic size S). - if other Unicode characters are included, accept them individually by adding 1 to S for each distinct character (but inform users that they may have difficulties to connect from some environments with such password). (3) take the base-2 logarithm of the alphabet size, and multiply by the password length (N). This gives the raw "bit-length" strength of a password. In other words : raw bit-length strength = log2(S)*N (4) if a space is accepted in the password, it should just occur in the middle and not at the begining or end and not in sequences of more than one space. Because of that, a password of length N cannot contain more than (N - 1) DIV 2 spaces, which adds ((N-1)DIV 2)*log(S+1)/log(S) to the row bit-length strength. Of course you can check that basic default passwords is not used (like "" or "1234" or "password" or "admin" or the username itself, or any word contained in the user's own public identity like hist public first name or last name, or any word contained in his user page, or in the first 1KB of his talk page). But using any large dicionary to forbid passwords may actually reduce the bit-length strength rather than increasing it, for brute-force attacks (even if it protects from dictionnary-based attacks), by allowing them to skip too words contained in that known dictionary. And it may also forget many wellknown common words (including first names) from other foreign languages (my opinion is that the dictionary used should just be built from the terminology used in the MediaWiki messages stored in the "MediaWiki:" space, in all its supported languages, and for each extension that is activated in the wiki where the account is created). However, even if a password is not strong enough, users should still not be forbidden access completely: he should be denied from using the secure server, but will be informed that his password is not strong enough to be used there, but he will have the option to go to the non-secure servers. I also suggest then that the user's Preferences panel include such password bit-length strength (computed like above) and a visual color bar indicating him the basic security of his account, and if the bitlength strength is suitable for identification on the secure server. -- 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 21509] Opt-in user flow takes user to log out and opt-out
https://bugzilla.wikimedia.org/show_bug.cgi?id=21509 Roan Kattouw changed: What|Removed |Added AssignedTo|tpars...@wikimedia.org |roan.katt...@gmail.com -- 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 21508] Welcome Beta page has opt-out survey
https://bugzilla.wikimedia.org/show_bug.cgi?id=21508 Roan Kattouw changed: What|Removed |Added AssignedTo|tpars...@wikimedia.org |roan.katt...@gmail.com --- Comment #2 from Roan Kattouw 2009-11-14 18:28:12 UTC --- Is it correct that this only happens when you log in as a user who's already enabled Beta? -- 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 20507] Yahoo 'temporarily' blocking lists.wikimedia.org emails
https://bugzilla.wikimedia.org/show_bug.cgi?id=20507 --- Comment #9 from Andrew Garrett 2009-11-14 18:18:13 UTC --- (In reply to comment #7) > Can this have been caused by users complaining about the emails coming from > the > default (forced) activation of emails being sent by the LiquidThread extension > ? > See Bug 21457 (whose severity should really be elevated to "critical", rather > than current "normal"). A few tens of notification e-mails a day on several low-traffic wikis? Give me a break. -- 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 20507] Yahoo 'temporarily' blocking lists.wikimedia.org emails
https://bugzilla.wikimedia.org/show_bug.cgi?id=20507 Platonides changed: What|Removed |Added CC||agarr...@wikimedia.org --- Comment #8 from Platonides 2009-11-14 18:13:16 UTC --- (In reply to comment #7) > Can this have been caused by users complaining about the emails coming from > the > default (forced) activation of emails being sent by the LiquidThread > extension ? No. I don't think liquidthreads was enabled at that time. Even now, it is only in some development wikis, it's not in any way widespread to cause this (and people testing it should know better...). -- 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 21509] Opt-in user flow takes user to log out and opt-out
https://bugzilla.wikimedia.org/show_bug.cgi?id=21509 Naoko Komura changed: What|Removed |Added Keywords||acai, babaco -- 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 21509] Opt-in user flow takes user to log out and opt-out
https://bugzilla.wikimedia.org/show_bug.cgi?id=21509 --- Comment #1 from Naoko Komura 2009-11-14 18:06:58 UTC --- Created an attachment (id=6783) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6783) user is logged out and never opt-in beta with this flow... -- 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 21509] New: Opt-in user flow takes user to log out and opt-out
https://bugzilla.wikimedia.org/show_bug.cgi?id=21509 Summary: Opt-in user flow takes user to log out and opt-out Product: MediaWiki extensions Version: any Platform: All URL: http://prototype.wikimedia.org/en.wikipedia.org/Main_Pag e OS/Version: All Status: NEW Severity: major Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: nkom...@gmail.com CC: wikibugs-l@lists.wikimedia.org, roan.katt...@gmail.com, pv...@wikimedia.org, wikib...@calcey.com Created an attachment (id=6782) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6782) user is prompted to go to log out page while trying to opt-in filed against r58971 If a user is not logged in, the user wind up logging out with the current opt-in flow. Steps to create: 1) You are logged out user and about to try out the beta 2) Click "Try Beta" 3) You are prompted to log in 4) You log in and get the welcome page with opt-out survey (opt-out survey should not be displayed) 5) You are encouraged to continue using beta by pointing to; If you would like to continue using Beta, you can return to Special:UserLogout 6) Click the link and you are taken to logged out page At this point you are back to using monobook. Why don't we direct users to 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 11547] Use only ASCII characters in email confirmation links
https://bugzilla.wikimedia.org/show_bug.cgi?id=11547 --- Comment #4 from Tisza Gergő 2009-11-14 17:54:55 UTC --- (In reply to comment #2) (In reply to comment #3) You should probably open a new bug to discuss that; this one is about the lack of urlencoding in the confirmation link, which is a wholly unrelated 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 21508] Welcome Beta page has opt-out survey
https://bugzilla.wikimedia.org/show_bug.cgi?id=21508 --- Comment #1 from Naoko Komura 2009-11-14 17:53:47 UTC --- Created an attachment (id=6781) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6781) Wikipedia has optout survey in welcoming page 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 21508] New: Welcome Beta page has opt-out survey
https://bugzilla.wikimedia.org/show_bug.cgi?id=21508 Summary: Welcome Beta page has opt-out survey Product: MediaWiki extensions Version: any Platform: All URL: All production sites OS/Version: All Status: NEW Severity: normal Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: nkom...@gmail.com CC: wikibugs-l@lists.wikimedia.org, roan.katt...@gmail.com, pv...@wikimedia.org Created an attachment (id=6780) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6780) Welcome to Beta page with opt-out survey When a user opt into beta by providing existing user name, "Welcome to Beta" page has opt-out survey as the body of the page. Steps to produce: 1) From default interface as an anonymous user, click "Try Beta" 2) Click "Let's do it!" 3) You are prompted to a log-in page, enter credentials 4) Login successful 5) Click link of "Return to". In this case Special:UsabilityInitiativeOptIn 6) You get "Welcome to Beta" page with opt-out survey -- 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 21501] Insert Links : Link text display
https://bugzilla.wikimedia.org/show_bug.cgi?id=21501 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #2 from Roan Kattouw 2009-11-14 17:51:15 UTC --- (In reply to comment #1) > As the wiki links work in a way that page titles become links, it is fine to > pre-fill the text even the text was not inserted originally. > I guess that makes the bug as originially filed WONTFIX. > However, please remove the separator line from the double brackets -> > [[Example|]], when the text for wiki link is not provided. > [[Example]] and [[Example|]] are not necessarily equivalent: [[The Bay (radio station)|]] and [[Winnipeg, Manitoba|]] expand to [[The Bay (radio station)|The Bay]] and [[Winnipeg, Manitoba|Winnipeg]] respectively (the so-called pipe trick). I could of course look at the logic used for the pipe trick and see if it's simple enough to use in the dialog, so highlighting [[Winnipeg, Manitoba|]] would fill out Winnipeg in the Link text field. -- 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 21478] $wgAllowDisplayTitle not working when $wgCapitalLinks = false
https://bugzilla.wikimedia.org/show_bug.cgi?id=21478 Sorin Sbarnea changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Sorin Sbarnea 2009-11-14 17:44:19 UTC --- I think this may be an invalid bug, after I upgraded the i18n.ro MW to 1.15.1 this is working. Still it does not work on my other wiki that is already updated but I suspect that this may be caused by some other extensions I installed. Thanks and sorry for adding a bug without checking without extensions. -- 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 11547] Use only ASCII characters in email confirmation links
https://bugzilla.wikimedia.org/show_bug.cgi?id=11547 Philippe Verdy changed: What|Removed |Added CC||verd...@wanadoo.fr --- Comment #3 from Philippe Verdy 2009-11-14 17:43:32 UTC --- URL encoding is definitely NOT the correct way to make the "user@" part of emails address valid. Read the RFCs: URL encoding just applies to the hierarchical page name within a domain space (and under a hierarchical protocol like "http(s):" and "ftp(s):"), as well as in query parameters (when they are supported in those protocols). Valid user names in email addresses also use a "safe" alphabet different from that for domain names (which also DO NOT use URL encoding but the encodings supported in IDNA, if they are internationized, and DNS specifications otherwise). For example, the underscore character "_" (which is part of my own email address and cannot be subtituted into a "+" or "-" and not even into "%7E") or the exclamation punctuation mark "!" is perfectly safe (and standard) in the "user@" part (which in fact is not really described as a user name, but as an identity specifier whose internal syntax may contain a user name and some other authorization data, that cannot be safely stripped out or separated (some sites will use the colon ":" instead of the exclamation mark). Mapping any Unicode characters with UTF-8 or other representations into a valid "user@" part of an email address is completely unspecified (there's absolutely no reliable algorithm to do this, as the mapping is completely domain-dependant and may even be different from the mapping used for encoding usernames in URI schemes other than "mailto:";). All that can be done is to check that the "user@" part provided uses the valid ASCII subset which is specific to the "mailto:"; URI scheme (and distinct from the ASCII subsets used: either in the DNS protocol for domain names; or in the server-local address part of HTTP/FTP URLs). Note also that "user@" parts in email addresses are normally CASE-SIGNIFICANT (even if most target SMTP servers, will accept emails using any case, and if some RFCs require that users provide an email address containing a user name that can be used as a valid label in a DNS subdomain, in order to activate some functionality) ; STMP relay agents (as well as senders) MUST NOT change the letter case in a pseudo-canonicalization (because they can't realiably know if the recipient server makes the case distinction) : this could simply break the authorization data which is part of the "user@" part (for example it could contain Base64-encoded binary data, in addition to representing the user identity on the target server where it will be delivered to the target POP3/IMAP/WebMail user's mailbox). -- 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 21478] $wgAllowDisplayTitle not working when $wgCapitalLinks = false
https://bugzilla.wikimedia.org/show_bug.cgi?id=21478 --- Comment #3 from Alexandre Emsenhuber [IAlex] 2009-11-14 17:37:55 UTC --- $wgRestrictDisplayTitle was introduced in 1.14.0, in older versions it'll always behave like "$wgRestrictDisplayTitle = 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 21478] $wgAllowDisplayTitle not working when $wgCapitalLinks = false
https://bugzilla.wikimedia.org/show_bug.cgi?id=21478 --- Comment #2 from Sorin Sbarnea 2009-11-14 17:25:18 UTC --- Please check this wiki page http://i18n.ro/test This is another MediaWiki that I maintain where I observe the same behavior - currently this one is running MW 1.13.2 but I will try to update to latest version 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 20507] Yahoo 'temporarily' blocking lists.wikimedia.org emails
https://bugzilla.wikimedia.org/show_bug.cgi?id=20507 Philippe Verdy changed: What|Removed |Added CC||verd...@wanadoo.fr --- Comment #7 from Philippe Verdy 2009-11-14 17:15:30 UTC --- Can this have been caused by users complaining about the emails coming from the default (forced) activation of emails being sent by the LiquidThread extension ? See Bug 21457 (whose severity should really be elevated to "critical", rather than current "normal"). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 --- Comment #10 from Andrew Garrett 2009-11-14 17:12:44 UTC --- The notifications will be opt-in as soon as the strategy wiki and other wikis with LiquidThreads enabled have received code updates, at which point I will consider this bug resolved. Please do not comment further unless you have something to add to technical discussion of the bug (for example, if the behaviour is not resolved once the updates have been deployed). Random rants about the impact of the bug are thoroughly unhelpful, and result in *my* email inbox being spammed by your unhelpful rants. -- 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 13287] "Edit" link not working as expected
https://bugzilla.wikimedia.org/show_bug.cgi?id=13287 --- Comment #12 from Mike.lifeguard 2009-11-14 17:09:00 UTC --- (In reply to comment #11) > Most probably, all gadgets presented in the Preferences should have at least > one link, not there for "editing" it but going to a more complete description > page (from which you'll find a full description, example snapshots, usage > help, > versioning info, bugs and discussions for corrections, suggestions for > improvements, and a link to its current implementation, which may consist in > more than just a single Javascript source, but could also contain images, > translable/localizable items...) That can and should be implemented by the users writing these scripts. -- 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 16451] GIF scaling limit should be applied to animated GIFs only
https://bugzilla.wikimedia.org/show_bug.cgi?id=16451 --- Comment #35 from zlight...@yahoo.com 2009-11-14 17:08:53 UTC --- The Commons thread says that system administrators can make the change in CommonSettings.php which is linked from here: http://noc.wikimedia.org/conf http://meta.wikimedia.org/wiki/System_administrators#List says "Do not contact random people on this list if you want something done. Instead, go to the [[irc:wikimedia-tech|#wikimedia-tech]] channel on irc.freenode.net." I see the part that needs to be removed: // Disable server-side GIF scaling $wgMediaHandlers['image/gif'] = 'BitmapHandler_ClientOnly'; It is found here: http://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 --- Comment #9 from Philippe Verdy 2009-11-14 17:00:17 UTC --- Note: when I sunddely started receiving emails because of the activation of Lqt and its default behavior, I have received, in just three days, several thousands of emails ! although I do understand that this was caused by a bug, I did not read all of them (in fact I have just read one to see from where they came, and then I deleted them all). But other users will not have had the same "patience" and will have jsut signaled these emails as spam (which they really were), causing MediaWiki sites to be blacklisted in various places across the net. Don't blame those that have blacklisted Wikimedia sites or caused these sites to be blacklisted (due to user complains). Only Wikimedia is fully responsible of this effect. Wikimedia sites are now so large on the net that such bug cannot have them being considered minor. This is really a very critical issue to solve immediately (even if this means that Lqt must be disabled completely on all WMF sites, until is is fixed properly). The WMF should have noticed by itself that this activation had considerably increased the number of emails sent from its servers, and should have pressed the "Emergency Red button" to block ALL emails tentatively sent by the Lqt extension (and if there's still no such "Red button", consider implementing it and implementing also a live statistics monitoring for the volume of emails sent by WMF servers ; in addition, if any extension is autorized to send emails, these emails MUST be traced internally, with specific authorization keys, one for each extension on each wiki, so that they can be blocked/filtered selectively, if any bug occurs in one of the extensions using this capability). -- 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 21501] Insert Links : Link text display
https://bugzilla.wikimedia.org/show_bug.cgi?id=21501 Naoko Komura changed: What|Removed |Added CC||nkom...@gmail.com AssignedTo|tpars...@wikimedia.org |roan.katt...@gmail.com --- Comment #1 from Naoko Komura 2009-11-14 16:59:48 UTC --- As the wiki links work in a way that page titles become links, it is fine to pre-fill the text even the text was not inserted originally. However, please remove the separator line from the double brackets -> [[Example|]], when the text for wiki link is not provided. -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 --- Comment #8 from Philippe Verdy 2009-11-14 16:46:41 UTC --- Note: even "once per visit" is still not enough. This is still causing users to receive undesired emails from a mailing list that they have not opted in actively. MediaWiki should not use the "opt out" procedure (and anyway your fix still does not even implement the "opt out" procedure correctly, ad the emails do not even include any "unsubscribe" link). As the new feature is still not mandatory (coming from a community decision), there's absolutely no reason for allowing it to be enabled by default (instead consider informing users about the new functionality, using Global Site Notices that will first link to a page explaining to users how they can enable/disable it and what will be the impact). So change it immediately so that users will use active "opt in" rather than a bogous "opt out" which was explained nowhere. -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 Mike.lifeguard changed: What|Removed |Added CC||mike.lifegu...@gmail.com --- Comment #7 from Mike.lifeguard 2009-11-14 16:40:54 UTC --- There's also no obvious way to stop receiving the doggamed things. -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 Philippe Verdy changed: What|Removed |Added CC||verd...@wanadoo.fr --- Comment #6 from Philippe Verdy 2009-11-14 16:37:10 UTC --- Really this bug is serious and has caused some users to suddenly receive hundreds of emails (without any limitation) from MediaWiki sites even though they DID NOT "opt in" to receive these emails (even a single email is bad if it is sent automatically and is not a private person-to-person communication). It appears that activating the option by default in Lqt has caused MediaWiki sites to be considered as a source of SPAM (which it really was) and being signaled as such (so Mediawiki sites were blacklisted). Because this forced activation was FULLY EQUIVALENT to force subscribing users to a new mailing list without their consent (assuming that they could "opt out" easily something that this functionality DID NOT even properly implemented: this required users to look by themselves from where all these emails came from and search for the new option that appeared in their preferences to disable it, sometimes in a language or script that they had not even been able to set in order to make the preferences tab usable). As long as there will be no simple way to have global preferences to make sure that no wiki will use some new functionality implemented locally), NEVER redo that in the future. Otherwise we will vote for blocking and excluding the authors of these extensions for severe abuse of user rights, and we'll want to have them removed from the list of users with commit rights in MediaWiki SVN. -- 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 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #18 from Philippe Verdy 2009-11-14 16:25:46 UTC --- I am NOT "speculating" about implementation details. I am only refering to the visible effects of these implementations. This is really different. Some recent changes in some wikis have been made recently (even after this bug was discussed here) that caused similar problems: a new functionality was added without notice in some rarely visited wiki which caused that wiki to send emails for each page that was previously just part of the list of pages to monitor ONLINE (whcich was not an option to monitor them offline by email). Think twice when adding new fucntionality that invades user privacy or user's mailboxes and make this option active by default. Anyway thanks for pointing bug 14950 (which is now really old and more urgently needs a fix now). We do need global overrides (independantly of how it will be implemented) and we still need some local overrides that will allow users to bypass some global defaults in some specific wikis (including their "home" wiki for SUL) that users can "trust" and that they reagularly visit for participating actively. -- 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 13742] Allow for gadgets to be turned on by default
https://bugzilla.wikimedia.org/show_bug.cgi?id=13742 Philippe Verdy changed: What|Removed |Added CC||verd...@wanadoo.fr --- Comment #6 from Philippe Verdy 2009-11-14 16:13:43 UTC --- Adding a gadget and activating it by default is a known source of problems. Somtimes it even breaks the clear intent of users, notably when the functionality breaks or invades their privacy. For example, some gadgets have been activated in discussion pages that automated sending emails to users to inform them that a page "of interest" had been changed. This option was activated by default, and many users have complained that they now received tons of emails, just because in the past they had worked on many pages, even though they had set all their other preferences to NOT send them any email, but instead made their user page on all wikis to inform other users that they could be contacted in the Talk page of their "home" wiki. This activation caused MediaWiki sites to be reported as really SPAMMING (which it really was: the effect of enabling this option by default was completely equivalent to forcing users to subscribe to a new mailing list without their consent, assuming that they could "opt out" something that is not as easy as you think because the preferences panel is sometimes not usable when it is displayed by default in a language or script that they can't easily decipher and where even the language default is not so easy to locate and change). Remember this: activating by default a new function that changes the behavior of the site MUST NOT be activated by default, unless there's a clear decision that the new behavior is MANDATORY FOR ALL (in which case there's not even the need for this option), or if the fact of not activating it for all will cause problems for working and supporting users that have not activated it. Please let users decide by themselves which option they want, but in all cases, do not change the behavior for all users that already have an account where the option was not set. -- 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 13287] "Edit" link not working as expected
https://bugzilla.wikimedia.org/show_bug.cgi?id=13287 Philippe Verdy changed: What|Removed |Added CC||verd...@wanadoo.fr --- Comment #11 from Philippe Verdy 2009-11-14 16:02:40 UTC --- Most probably, all gadgets presented in the Preferences should have at least one link, not there for "editing" it but going to a more complete description page (from which you'll find a full description, example snapshots, usage help, versioning info, bugs and discussions for corrections, suggestions for improvements, and a link to its current implementation, which may consist in more than just a single Javascript source, but could also contain images, translable/localizable items...) My feeling is that each one should show a "details" (or just "help"?) link (which itself is localizable), immediately after the summary line, for reaching this Gadget's description page. The current summary line shown in the Gadgets tab after their respective checkbox is clearly not enough (and even the links that may be present sometimes in some summary lines, do not necessary reach this page but can just link to the description of an associated concept, such as a Wikipedia article). inserting the link within the summary line is not the best place for that as it is really confusive. Ideally, there should also be absolutely NO link WITHIN the summary line itself (this is not necessary if we always have a "details/help" link displayed with each gadget), which should be a basic text. The target page or URL for this "help/details" description page can be anywhere (including on another wiki): it should be up to each gadget to specify the location of their Gadget's help page, and each wiki importing the gadget should also have the possibility to customize this default page (for example to provide local help and local discussion pages, even if the local page contains another link to the default Gadget's detail page, which it really should). The same is true for all other localizable summary lines found in the preferences. This is easy to understand, look at most standalone applications for desktops (Windows, Mac, Linux...) that include such a "help" functionality in their GUI (forms and dialogs) for all user selectable items, and sometimes even for some display-only status. The per-item "help" is needed simply for usability and is much better than just a global help page for a full input form. -- 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 20757] some text of old revisions in early 2005 is blank in the English Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=20757 --- Comment #8 from Graham87 2009-11-14 15:31:10 UTC --- Yet another one: >From http://en.wikipedia.org/w/index.php?title=Physical_Layer&oldid=10138976 to http://en.wikipedia.org/w/index.php?title=Physical_Layer&oldid=13781605, excluding http://en.wikipedia.org/w/index.php?title=Physical_Layer&oldid=10145054. Also, here's an example from March 2004, which has an unusually early date but a relatively high revision ID. It's meant to be a redirect: http://en.wikipedia.org/w/index.php?title=Two-binary,_one-quaternary&oldid=13022503 -- 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 21478] $wgAllowDisplayTitle not working when $wgCapitalLinks = false
https://bugzilla.wikimedia.org/show_bug.cgi?id=21478 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added Summary|$wgAllowDisplayTitle not|$wgAllowDisplayTitle not |working when$wgCapitalLinks |working when $wgCapitalLinks |= false |= false -- 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 21478] $wgAllowDisplayTitle not working when$wgCapitalLinks = false
https://bugzilla.wikimedia.org/show_bug.cgi?id=21478 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added CC||alex.emsenhu...@bluewin.ch --- Comment #1 from Alexandre Emsenhuber [IAlex] 2009-11-14 12:56:18 UTC --- I'm not able to reproduce this bug, either on 1.15.1 or trunk on my local wiki. Can you provide a link to a page where this bug happens? -- 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 21455] Anonymous users see "Watch this page" checkbox when performing delete, move, and protect actions
https://bugzilla.wikimedia.org/show_bug.cgi?id=21455 Matěj Grabovský changed: What|Removed |Added CC||mgrabov...@yahoo.com Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Matěj Grabovský 2009-11-14 11:08:49 UTC --- Fixed in r59058. -- 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 21241] Creation of a new namespace in ia.wiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=21241 --- Comment #3 from Isaac Mansur 2009-11-14 10:25:41 UTC --- As requested by Roan, I opened for consensus [http://ia.wiktionary.org/wiki/Wiktionario:Portal_del_communitate#New_namespace here] in order to see what the community thinks about the new Namespace "Appendice". I left it opened for almost 20 days, and I got three votes for the new namespace. I do really need this new namespace to work better on some lists that were created in the past and that must be kept in a separate namespace. I know there are lots of things to be done there, but considering the small community, it will take some time and I need the more tools, namespaces and instruments I can get. For now, I would thank you if we get the new namespace called "Appendice". Thanks for your attention again. -- 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
