[Bug 25522] language code change for Samogitian: "bat-smg" to "sgs"
https://bugzilla.wikimedia.org/show_bug.cgi?id=25522 Siebrand changed: What|Removed |Added Keywords||shell CC||s.mazel...@xs4all.nl --- Comment #4 from Siebrand 2010-11-01 06:47:06 UTC --- Completed from MediaWiki POV in r75244, r75241 and r75240. Wikimedia could make changes now if it wanted to, but history tells us projects will/can not be renamed. -- 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 25521] wrong case in file name /SemanticresultFormats.php';
https://bugzilla.wikimedia.org/show_bug.cgi?id=25521 Siebrand changed: What|Removed |Added Status|NEW |RESOLVED CC||s.mazel...@xs4all.nl Resolution||FIXED --- Comment #2 from Siebrand 2010-11-01 06:44:25 UTC --- Fixed in r75779. Thanks for the report. -- 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 25521] wrong case in file name /SemanticresultFormats.php';
https://bugzilla.wikimedia.org/show_bug.cgi?id=25521 Jesse PW (Pathoschild) changed: What|Removed |Added CC||pathoschild+wmb...@gmail.co ||m Severity|enhancement |critical --- Comment #1 from Jesse PW (Pathoschild) 2010-11-01 04:45:20 UTC --- Changed to critical, since this causes fatal PHP errors when activating the extension. (It's a trivial fix, 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 25734] New: API: possible issue with revids validation
https://bugzilla.wikimedia.org/show_bug.cgi?id=25734 Summary: API: possible issue with revids validation Product: MediaWiki Version: 1.17-svn Platform: All URL: http://en.wikipedia.org/w/api.php?action=query&revids= -1|123 OS/Version: All Status: NEW Severity: normal Priority: Normal Component: API AssignedTo: roan.katt...@gmail.com ReportedBy: matthew.brit...@btinternet.com CC: bryan.tongm...@gmail.com, s...@reedyboy.net, vasi...@gmail.com, soxre...@gmail.com http://en.wikipedia.org/w/api.php?action=query&revids=123|456 -- works (returns details of revisions) http://en.wikipedia.org/w/api.php?action=query&revids=-1 -- works (returns "badrevids") http://en.wikipedia.org/w/api.php?action=query&revids=-1|123 -- the request times out. Any other sequence of IDs that mixes valid and invalid IDs produces the same behavior, e.g. http://en.wikipedia.org/w/api.php?action=query&revids=10|20|30|40|-50|60 Cannot reproduce locally with trunk, so may already be fixed. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25733] New: CentralAuth: local-only login option not supported by the API
https://bugzilla.wikimedia.org/show_bug.cgi?id=25733 Summary: CentralAuth: local-only login option not supported by the API Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CentralAuth AssignedTo: vasi...@gmail.com ReportedBy: matthew.brit...@btinternet.com CC: agarr...@wikimedia.org Bug 20852 added an option to only log in locally. Currently this option has no API support. API support should be added, as there is even more reason there to want to do a local login only. -- 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 25732] New: Possible integration between ConfirmAccount and CentralAuth
https://bugzilla.wikimedia.org/show_bug.cgi?id=25732 Summary: Possible integration between ConfirmAccount and CentralAuth Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: ConfirmAccount AssignedTo: jschulz_4...@msn.com ReportedBy: wikimedia.lest...@gmail.com CC: wikibugs-l@lists.wikimedia.org I'm not sure if this is the correct place to do this request, but is possible a integration between ConfirmAccount and CentralAuth? Actually if ConfirmAccount is enabled, the option to create a account is "false", because of this centralauth cannot create new accounts. My question/request is if have a possible integration between this two extensions. Thanks -- 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 24313] Please remove the Preference setting to "Mark all edits minor by default" from en.wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24313 --- Comment #31 from MC10 2010-11-01 01:52:28 UTC --- And please, _just_ en.wiki, not from MediaWiki completely. -- 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 25729] Add a #switchskin ParserFunction
https://bugzilla.wikimedia.org/show_bug.cgi?id=25729 --- Comment #2 from MC10 2010-11-01 01:49:29 UTC --- That actually is a good idea. I'll open a new bug request. Can you close this for me? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25722] Non-existent file namespace pages have a "edit" tab instead of a "create" tab
https://bugzilla.wikimedia.org/show_bug.cgi?id=25722 --- Comment #5 from Rehman 2010-11-01 01:35:17 UTC --- @Derk: Yes, I use EN-UK. @Bawolff: Its probably because of the language variant, as Derk said. Cant we make it to show a red "Create" on all English variants (or maybe in all languages (translated 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 25722] Non-existent file namespace pages have a "edit" tab instead of a "create" tab
https://bugzilla.wikimedia.org/show_bug.cgi?id=25722 Derk-Jan Hartman changed: What|Removed |Added CC||hart...@videolan.org --- Comment #4 from Derk-Jan Hartman 2010-11-01 00:39:03 UTC --- Perhaps Rehman, you do not use the interface language "English", but one of the English variants ? -- 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 25725] Unwanted linebreaks in diffs when span.diffchange is present
https://bugzilla.wikimedia.org/show_bug.cgi?id=25725 Derk-Jan Hartman changed: What|Removed |Added Status|NEW |RESOLVED CC||hart...@videolan.org Resolution||FIXED --- Comment #4 from Derk-Jan Hartman 2010-11-01 00:15:13 UTC --- It seems the linebreaks are used as word boundaries, and the the diff line routines are reused for word level comparison. Fixed in r75769, by line-ending squashing the work comparison results. -- 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 25517] Assignment in conditions should be avoided
https://bugzilla.wikimedia.org/show_bug.cgi?id=25517 --- Comment #3 from Reedy 2010-10-31 23:52:50 UTC --- http://www.mediawiki.org/wiki/Manual:Coding_conventions#Assignment_expressions Turns out it's in the coding conventions... -- 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 25726] Use .live to attach the handler for ext.vector.collapsibleNav.js
https://bugzilla.wikimedia.org/show_bug.cgi?id=25726 Derk-Jan Hartman changed: What|Removed |Added CC||hart...@videolan.org --- Comment #1 from Derk-Jan Hartman 2010-10-31 23:28:43 UTC --- I like the idea. Wouldn't delegate() be more efficient however ? http://api.jquery.com/delegate/ vs http://api.jquery.com/live/ -- 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 19633] Scale up thumbnails of small SVG
https://bugzilla.wikimedia.org/show_bug.cgi?id=19633 Derk-Jan Hartman changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Derk-Jan Hartman 2010-10-31 22:05:39 UTC --- Fixed with r75748 and r75749 -- 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 25731] "This upgrade script can't convert it, so it will remain mysql4." error when upgrading/reinstalling
https://bugzilla.wikimedia.org/show_bug.cgi?id=25731 --- Comment #1 from Krinkle 2010-10-31 22:04:04 UTC --- So, the problem is that after this message (see attachment screenshot). Nothing happends anymore. No options, no activity (atleast doesn't appear to be). All I can see in the activity monitor is a 404 error for a bullet-image that's being loaded for the second time (but this time in /skins/skins) -- Krinkle -- 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 25731] New: "This upgrade script can't convert it, so it will remain mysql4." error when upgrading/reinstalling
https://bugzilla.wikimedia.org/show_bug.cgi?id=25731 Summary: "This upgrade script can't convert it, so it will remain mysql4." error when upgrading/reinstalling Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Installation AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: krinklem...@gmail.com Created attachment 7771 --> https://bugzilla.wikimedia.org/attachment.cgi?id=7771 Screenshot of the page, showing the (possibly related) 404 error of the image Two weeks ago locally installed the trunk with MySQL. Today I deleted my LocalSettings.php and some other files that were created by the installer and/or by me. I reverted everything to the state as it was and then 'svn up'ed to the latest revision (r75747) and I went through the installer again giving it the name and access to my existing (albeit pretty much empty) mw database. I got the message that it's possible to upgrade, and to do so click Continue (I found it weird though, there's no "clean install" option, only continue or back). After clicking continue I get this on http://localhost/svn/wiki/config/index.php?page=Upgrade Upgrade existing installation Warning: you requested the binary schema, but the existing database has the mysql4 schema. This upgrade script can't convert it, so it will remain mysql4. -- 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 24000] Update rsvg so styling SVG images with CSS works properly on Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=24000 Ilmari Karonen changed: What|Removed |Added CC||nos...@vyznev.net --- Comment #8 from Ilmari Karonen 2010-10-31 21:48:30 UTC --- The latest version of librsvg is 2.32.0. 2.22.2 is almost 1.5 years old. It seems like it would be high time for an upgrade. -- 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 25730] LiquidThreads sends me to page "API" telling me of some edit conflict
https://bugzilla.wikimedia.org/show_bug.cgi?id=25730 MZMcBride changed: What|Removed |Added CC||b...@mzmcbride.com Summary|Liquid Threats sends me to |LiquidThreads sends me to |page "API" telling me of|page "API" telling me of |some edit conflict |some edit conflict -- 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 25730] Liquid Threats sends me to page "API" telling me of some edit conflict
https://bugzilla.wikimedia.org/show_bug.cgi?id=25730 Niklas Laxström changed: What|Removed |Added Status|NEW |RESOLVED CC||niklas.laxst...@gmail.com Resolution||DUPLICATE --- Comment #1 from Niklas Laxström 2010-10-31 21:32:48 UTC --- *** This bug has been marked as a duplicate of bug 25393 *** -- 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 25393] Some new threads go to API page instead
https://bugzilla.wikimedia.org/show_bug.cgi?id=25393 Niklas Laxström changed: What|Removed |Added CC||theevilipaddr...@hotmail.de --- Comment #4 from Niklas Laxström 2010-10-31 21:32:48 UTC --- *** Bug 25730 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 on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25730] New: Liquid Threats sends me to page "API" telling me of some edit conflict
https://bugzilla.wikimedia.org/show_bug.cgi?id=25730 Summary: Liquid Threats sends me to page "API" telling me of some edit conflict Product: MediaWiki extensions Version: any Platform: All URL: http://translatewiki.net/wiki/Support OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: LiquidThreads AssignedTo: agarr...@wikimedia.org ReportedBy: theevilipaddr...@hotmail.de CC: amil...@wikimedia.org, bhar...@wikimedia.org Today, I wanted to write something on Translatewiki's Support page with Liquid Threads, but then something crazy happened. I think it might be due to a too long title, but I'm not sure. So I typed {{msg-mw|explainconflict}} in a German interface and the following text {{msg-mw|explainconflict}} should use {{int:savearticle}} instead of "Save page". into the textarea of the AJAX interface (NoScript disabled). Previewing worked, but on pressing the Save button, it led me to the page "API", with the current page content in the upper textarea and mine in the lower one. Above the textarea, was, ironically as it may seem, the [[MediaWiki:Explainconflict]] blurb about an edit conflict. Then, trying to do the same without the AJAX interface, I was not led to this page, but it sent me to the page "Thread:59945cdbd103a6894eee31435e0004f8", telling me that the subject I entered was invalid (the [[MediaWiki:Lqt invalid subject]] blurb). I have now easily solved the problem by setting a |notext=yes}} at the end which drastically shortens the page title, but I still think that it was pretty difficult to understand the cause for the error and that it should be improved. Also, I'm apparently not the only one having this problem, see http://translatewiki.net/w/i.php?title=Special%3ALog&type=delete&user=&page=API&year=&month=-1 or http://translatewiki.net/w/i.php?title=API&action=history -- 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 25295] Improve reviewer experience when multiple simultaneous users review Pending Changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=25295 Bug 25295 depends on bug 24043, which changed state. Bug 24043 Summary: Change edit review checkbox to "accept this page *with* my edits" https://bugzilla.wikimedia.org/show_bug.cgi?id=24043 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24043] Change edit review checkbox to "accept this page *with* my edits"
https://bugzilla.wikimedia.org/show_bug.cgi?id=24043 Aaron Schulz changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Aaron Schulz 2010-10-31 21:18:05 UTC --- Done in r75747. -- 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 25729] Add a #switchskin ParserFunction
https://bugzilla.wikimedia.org/show_bug.cgi?id=25729 Casey Brown changed: What|Removed |Added CC||b...@caseybrown.org --- Comment #1 from Casey Brown 2010-10-31 19:21:24 UTC --- It would probably be better to create new skin-specific magic words for things like the user's current skin and the wiki's default skin. Then you could just use the existing ParserFunction and do something like {{#switch:{{CURRENTSKIN}}|monobook=bleh|#default=bleh2}}. -- 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 8697] Provide "mark these n changes as patrolled" button
https://bugzilla.wikimedia.org/show_bug.cgi?id=8697 Christoffer changed: What|Removed |Added CC||chst...@hotmail.com --- Comment #10 from Christoffer 2010-10-31 19:18:24 UTC --- No progress yet? If it could speed up the process somewhat; let it at first only work with the edits of one user, just like the rollback function. Most of the time, to my own experience at least (on a small wiki), that would be enough. -- 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 25729] New: Add a #switchskin ParserFunction
https://bugzilla.wikimedia.org/show_bug.cgi?id=25729 Summary: Add a #switchskin ParserFunction Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: ParserFunctions AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mathsma...@gmail.com I am asking if a #switchskin ParserFunction can be added, which basically does the following: {{#switchskin: |monobook=text displayed if Monobook is used |vector=text displayed if Vector is used |#default=text displayed if any other skin is used }} This ParserFunction should be similar to how #switch is used, but is switched by the skin a user/IP is using. It would be useful to display different versions of CSS for different skins, as skins implement CSS differently. It can also be used to display different messages to different skin users. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25728] New: Mail sender ("WikiAdmin") should be configurable
https://bugzilla.wikimedia.org/show_bug.cgi?id=25728 Summary: Mail sender ("WikiAdmin") should be configurable Product: MediaWiki Version: 1.16-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Email AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mediawiki-b...@cboltz.de Mediawiki sends all notification mails about changed pages using the sender name "WikiAdmin". This is hardcoded in includes/UserMailer.php, line 484: $adminAddress = new MailAddress( $wgPasswordSender, 'WikiAdmin' ); Now imagine you are working on multiple wikis - all will send you mails with the sender name "WikiAdmin", only the sender mail address differs ($wgPasswordSender). Please replace the hardcoded "WikiAdmin" with a configurable variable (which would default to WikiAdmin). Something like this: $adminAddress = new MailAddress( $wgPasswordSender, $wgPasswordSenderName ); -- 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 25727] Bugzilla unusable with mouse when using Konqueror as browser
https://bugzilla.wikimedia.org/show_bug.cgi?id=25727 Christian Boltz changed: What|Removed |Added Severity|enhancement |trivial -- 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 25727] New: Bugzilla unusable with mouse when using Konqueror as browser
https://bugzilla.wikimedia.org/show_bug.cgi?id=25727 Summary: Bugzilla unusable with mouse when using Konqueror as browser Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Bugzilla AssignedTo: pdha...@wikimedia.org ReportedBy: mediawiki-b...@cboltz.de CC: innocentkil...@gmail.com, s...@reedyboy.net Bugzilla is nearly unusable with the mouse when using Konqueror (from KDE 4.4.4) as browser. The reason for this is that the search field covers the whole size of the window. It's transparent (as in "you still see everything"), but it catches all mouse clicks. This happens on all bugzilla pages (for example search results, single bug view) that have the search box on the top-right corner. I tracked down the problem to vector.css (line 145): #simpleSearch > button#searchButton { height:100%; } I could fix the problem by adding the following line to my user CSS: #simpleSearch > button#searchButton { height: 1.5em !important; } Please change the height in vector.css to something like 1.5em so that bugzilla works in Konqueror. (The "!important" is to make sure it really overrides the online CSS, it won't be needed in vector.css.) -- 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 25726] New: Use .live to attach the handler for ext.vector.collapsibleNav.js
https://bugzilla.wikimedia.org/show_bug.cgi?id=25726 Summary: Use .live to attach the handler for ext.vector.collapsibleNav.js Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Vector Skin AssignedTo: tpars...@wikimedia.org ReportedBy: diebu...@gmail.com CC: asha...@wikimedia.org Created attachment 7770 --> https://bugzilla.wikimedia.org/attachment.cgi?id=7770 .mousedown -> .live See the patch. This would enable us to append other sections later on & have them work immediately. (eg. relevant for http://commons.wikimedia.org/wiki/MediaWiki:InterProject.js) Tested on localhost, can't see any regressions -- 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 23321] TOR nodes not being properly blocked
https://bugzilla.wikimedia.org/show_bug.cgi?id=23321 --- Comment #20 from zzuuzz 2010-10-31 18:38:54 UTC --- Here are some more going back to the start of October. These are just the ones I've blocked. I'm aware there have been others. Again I've included the uptime as reported a few minutes ago. All were confirmed at the time I blocked them. 115.84.182.227 uptime 324953 194.0.229.54uptime 1713811 178.63.198.71 now defunct 117.18.75.235 uptime 325500 89.16.175.194 uptime 55151 85.217.65.155 uptime 788037 77.109.139.87 uptime 1604624 78.229.64.71uptime 4392 194.154.227.109 uptime 8252751 62.141.53.224 uptime 1158035 78.129.227.207 now defunct 109.174.52.21 now defunct 137.56.163.46 uptime 874168 128.6.224.107 uptime 7717424 178.18.16.119 now defunct 61.32.46.9 now defunct 137.56.163.64 uptime 794079 74.208.213.82 uptime 270456 91.213.50.235 uptime 3088635 71.80.220.255 uptime 324747 96.232.187.242 now defunct 78.46.39.228uptime 894958 193.34.144.124 uptime 2466579 91.203.170.121 uptime 27816 69.175.122.198 now defunct 216.194.67.53 now defunct -- 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 25725] Unwanted linebreaks in diffs when span.diffchange is present
https://bugzilla.wikimedia.org/show_bug.cgi?id=25725 --- Comment #3 from Erwin Dokter 2010-10-31 18:14:51 UTC --- That would be an idea. On the other hand, if the original text doesn't contain non-breaking spaces, neither should the diff text, as it would introduce unwanted characters during copy/paste. -- 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 24626] Add an "autopatrolled" status for frwiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=24626 Quentinv57 changed: What|Removed |Added Severity|normal |enhancement -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25674] Allow blocked users to edit their talk page on frwiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=25674 Quentinv57 changed: What|Removed |Added Severity|normal |enhancement -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 323] edits where the rev_user_text and ar_user_text fields contain underscores, initial lower-case letters or consecutive spaces, which could occur in the Phase I and II software, are inaccessibl
https://bugzilla.wikimedia.org/show_bug.cgi?id=323 --- Comment #39 from Nemo_bis 2010-10-31 18:09:35 UTC --- Some edits of renamed users are affected, too, and have not been moved to the new username: compare http://meta.wikimedia.org/w/index.php?title=Special:Undelete&target=Native+American+Affairs×tamp=20020127003202 by [[m:user:maveric149]] (lowercase: see also [[m:Special:Contributions/maveric149]] which for some reason is not empty) and http://meta.wikimedia.org/w/index.php?title=Wikimedia_bank_account_history_for_2004&action=history which was created after the user was renamed to Daniel_Mayer (http://meta.wikimedia.org/w/index.php?title=User:Maveric149&diff=1352761&oldid=157121) and is now under the correct username Mav (I've just restored this page). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25725] Unwanted linebreaks in diffs when span.diffchange is present
https://bugzilla.wikimedia.org/show_bug.cgi?id=25725 Bawolff changed: What|Removed |Added CC||bawolff...@gmail.com --- Comment #2 from Bawolff 2010-10-31 18:07:38 UTC --- Theoretically, shouldn't the diff engine be using non-breaking spaces for any significant whitespace so using css white-space type hacks are unnecessary? -- 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 25725] Unwanted linebreaks in diffs when span.diffchange is present
https://bugzilla.wikimedia.org/show_bug.cgi?id=25725 --- Comment #1 from Erwin Dokter 2010-10-31 18:04:31 UTC --- Created attachment 7769 --> https://bugzilla.wikimedia.org/attachment.cgi?id=7769 Screenshot showing fault -- 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 25725] New: Unwanted linebreaks in diffs when span.diffchange is present
https://bugzilla.wikimedia.org/show_bug.cgi?id=25725 Summary: Unwanted linebreaks in diffs when span.diffchange is present Product: MediaWiki Version: 1.16 Platform: All URL: http://en.wikipedia.org/w/index.php?title=User:Edokter /vector.css&diff=prev&oldid=393815275 OS/Version: All Status: NEW Severity: minor Priority: Normal Component: History/Diffs AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: er...@darcoury.nl When adding some CSS to my userskin in order to show indents in diffs (see url for code), it revealed that DifferenceEngine.php (I think) is inserting unwnated linebreaks in the output HTML. While not 'illegal', it does thwart the intended effect. This only happens if the line contains a span.diffchange (the red text); other lines are fine. Below is the HTML output; note that line without a diffchange are one line, but the lines with a diffchange have a linebreak after and before , which breaks pre-wrap behaviour. Screenshot: http://en.wikipedia.org/wiki/File:Diff_with_unwanted_linebreaks.gif } } /* Preserve white-space in diffs */ /* Preserve white-space in diffs */ - table.div td div { + table.diff td div { white-space: pre-wrap; white-space: pre-wrap; } } -- 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 16992] Special:UncategorizedPages bug on hr Wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=16992 Paucabot changed: What|Removed |Added CC||pauca...@gmail.com --- Comment #2 from Paucabot 2010-10-31 17:49:17 UTC --- Maybe related to this bug: Some pages in Catalan Wikipedia appear in Special:UncategorizedPages (http://ca.wikipedia.org/wiki/Especial:P%C3%A0gines_sense_categoria) although they are already categorized. The page is regularly updated (every two or three days) but this pages are stalled there from august. Example: http://ca.wikipedia.org/wiki/Aissenas The pattern they seem to folllow is that all of them have been renamed lately. The difference with hr is that wrongly categorized files are not redirects: they are actual articles. 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 25719] site setting mistake in koi.wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=25719 Roan Kattouw changed: What|Removed |Added Status|NEW |RESOLVED CC||roan.katt...@gmail.com Resolution||FIXED --- Comment #2 from Roan Kattouw 2010-10-31 17:25:29 UTC --- Added the slash. -- 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 25707] Allow "html" in exif tags
https://bugzilla.wikimedia.org/show_bug.cgi?id=25707 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #8 from Roan Kattouw 2010-10-31 17:24:06 UTC --- We don't arbitrarily filter some HTML. We have code to predict whether IE will think a file is HTML or not (based on Tim's reengineering of the IE MIME type detection code) and filter based on 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 25569] Create the Gagauz Wikipedia (wp/gag)
https://bugzilla.wikimedia.org/show_bug.cgi?id=25569 --- Comment #3 from Milos Rancic 2010-10-31 17:23:07 UTC --- Validity of the language used on Gagauz test project has been confirmed by a relevant linguist, test project is active, the most used messages of the MediaWiki interface has been localized. There is no rule which forbids helping to a project by non-native speakers. -- 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 25717] Resource loader breaks the "Hide/show extended details" toggle on the image metadata table on file pages.
https://bugzilla.wikimedia.org/show_bug.cgi?id=25717 Roan Kattouw changed: What|Removed |Added Status|NEW |ASSIGNED 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 25569] Create the Gagauz Wikipedia (wp/gag)
https://bugzilla.wikimedia.org/show_bug.cgi?id=25569 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #2 from Roan Kattouw 2010-10-31 17:03:10 UTC --- (In reply to comment #1) > Please note that the editors seem to have fudged some facts to win approval > under false pretenses: > http://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Gagauz_2#Comment > > People from Turkey (the language is mostly spoken in Moldova and Ukraine) who > have lied about being native speakers, as well as people who don't even claim > to be speakers of Gagauz, seem to be the main contributors to this project so > far. Take those complaints to the language committee, not to the developers/sysadmins. -- 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 25724] New: WikiEditor Layout broken in Opera
https://bugzilla.wikimedia.org/show_bug.cgi?id=25724 Summary: WikiEditor Layout broken in Opera Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: accnospam...@yahoo.de CC: roan.katt...@gmail.com, amil...@wikimedia.org, asha...@wikimedia.org Created attachment 7768 --> https://bugzilla.wikimedia.org/attachment.cgi?id=7768 Screenshot Opera doesn't receive the styles for ".wikiEditor-ui-toolbar .group .label" (see screenshot in attachment) so the layout for "advanced" is broken (not floated). If I put those rules in [[Mediawiki:Vector.css]] everything is fine (because that CSS is always loaded for every page visit). So maybe it has to do something with that "ressource loader" thingy (I don't understand that yet). Sorry for my poor english ;) -- 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 25685] Search filter for pages that contain a template
https://bugzilla.wikimedia.org/show_bug.cgi?id=25685 Roan Kattouw changed: What|Removed |Added Status|NEW |RESOLVED CC||roan.katt...@gmail.com Resolution||WORKSFORME --- Comment #7 from Roan Kattouw 2010-10-31 16:45:53 UTC --- WORKSFORME: http://en.wikipedia.org/w/api.php?action=query&list=embeddedin&eititle=Template:Infobox -- 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 23321] TOR nodes not being properly blocked
https://bugzilla.wikimedia.org/show_bug.cgi?id=23321 --- Comment #19 from zzuuzz 2010-10-31 16:45:47 UTC --- Here's a sample from the last 24 hours. I've included the uptime reported by Tor as it was a few minutes ago, so it's not accurate but should give some idea. Of course many of the longer term nodes have been manually blocked by admins, but they pop up from time to time. This one for instance: 174.36.199.203 was editing recently. 108.7.61.129uptime 468929 66.8.152.121uptime 148865 206.248.138.177 uptime 3283382 82.95.152.30uptime 1274475 91.200.79.122 uptime 8601 67.182.56.220 uptime 130268 92.243.189.2uptime 549 88.161.177.191 uptime 915 46.4.208.206uptime 207156 66.58.182.38uptime 714921 99.251.211.225 uptime 12627 88.166.161.41 uptime 742 109.91.187.162 uptime 7138 88.160.214.26 uptime 507 109.191.8.168 uptime 183 66.74.163.57uptime 915 98.126.1.234uptime 426215 -- 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 25693] Change logo on tawikisource
https://bugzilla.wikimedia.org/show_bug.cgi?id=25693 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@gmail.com Summary|Need to change the logo |Change logo on tawikisource -- 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 23321] TOR nodes not being properly blocked
https://bugzilla.wikimedia.org/show_bug.cgi?id=23321 --- Comment #18 from Andrew Garrett 2010-10-31 16:16:40 UTC --- I'll try to take a look at this in the next couple of weeks, but I need specifics. -- 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 23321] TOR nodes not being properly blocked
https://bugzilla.wikimedia.org/show_bug.cgi?id=23321 --- Comment #17 from Platonides 2010-10-31 16:12:56 UTC --- Can you provide specific instances? The possible holes it occurs to me are the refetching time, some error, or new nodes which were added since the last update (the node list is cached for 30 minutes). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25720] substitute LOCALTIMESTAMP can differ from REVISIONTIMESTAMP
https://bugzilla.wikimedia.org/show_bug.cgi?id=25720 Bawolff changed: What|Removed |Added CC||bawolff...@gmail.com --- Comment #1 from Bawolff 2010-10-31 16:10:48 UTC --- Is this something we care about? -- 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 25722] Non-existent file namespace pages have a "edit" tab instead of a "create" tab
https://bugzilla.wikimedia.org/show_bug.cgi?id=25722 Bawolff changed: What|Removed |Added Summary|Non-existent file namespace |Non-existent file namespace |pages have a blue "edit"|pages have a "edit" tab |tab instead of a red|instead of a "create" tab |"create" tab| -- 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 25722] Non-existent file namespace pages have a blue "edit" tab instead of a red "create" tab
https://bugzilla.wikimedia.org/show_bug.cgi?id=25722 Bawolff changed: What|Removed |Added CC||bawolff...@gmail.com Summary|Updating page tabs |Non-existent file namespace ||pages have a blue "edit" ||tab instead of a red ||"create" tab --- Comment #3 from Bawolff 2010-10-31 16:08:52 UTC --- I'm Changing summary to be more specific (hopefully I understood you right). Trying a random page... http://en.wikipedia.org/wiki/File:Fdbaskdfsajbjkdsajkdsf.jpg I see a blue tab labelled "create". Can you give a link to a page where your issue occurs? -- 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 25718] Title->getLocalURL does not respect $wgArticlePath when given a query
https://bugzilla.wikimedia.org/show_bug.cgi?id=25718 Bryan Tong Minh changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25718] Title->getLocalURL does not respect $wgArticlePath when given a query
https://bugzilla.wikimedia.org/show_bug.cgi?id=25718 --- Comment #14 from Kiran Jonnalagadda 2010-10-31 14:56:45 UTC --- Thank you for the most excellent comment, Daniel. getLocalURL is far too core to MediaWiki to make changes without understanding the implications thoroughly, which I clearly don't. I propose this ticket be marked 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 25723] New: Unable to login after install
https://bugzilla.wikimedia.org/show_bug.cgi?id=25723 Summary: Unable to login after install Product: MediaWiki extensions Version: any Platform: All URL: http://wiki.millioncms.com OS/Version: All Status: NEW Severity: major Priority: Normal Component: Configure AssignedTo: ialex.w...@gmail.com ReportedBy: invicti...@live.co.uk Before we installed this extension although, we had another extension, we were perfectly able to login however, after installing this extension whenever anyone attempted to login they got an error saying "The password field is empty". -- 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 19633] Scale up thumbnails of small SVG
https://bugzilla.wikimedia.org/show_bug.cgi?id=19633 --- Comment #6 from Derk-Jan Hartman 2010-10-31 14:43:11 UTC --- hmm, this is totally the wrong patch btw. It seems that I have lost that one. :( -- 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 25718] Title->getLocalURL does not respect $wgArticlePath when given a query
https://bugzilla.wikimedia.org/show_bug.cgi?id=25718 --- Comment #13 from Daniel Friesen 2010-10-31 14:38:31 UTC --- I just took an actual look at the patch and larger look at the code, I see two things staring at me... Firstly, it feels for some reason to me that something is wrong with the $variant stuff... I'm not quite up to speed on the variant stuff, so it's either a MW bug where variant handling that should be in the second block isn't there. Or variant handling is supposed to be done only for /short/Urls and the patch adds a new location where /short/Urls end up showing up but is missing variant handling code. Or it's only meant to happen when $query is empty and I'm just to far behind. Though that's probably less of an issue compared to this. Looking at Line 821 I see what seams to be part of a feature that appears to allow you to pass "-" to getLocalURL as a method of saying to getLocalURL "I don't have any query, but I want you to give me a long index.php style url because I have a case where getting short urls will cause chaos, so NO short urls", although it does look like a tweak would be nice so there is no trailing &. The way the patch is written seams to break that... if this patch is applied it looks like $query = "-" will start outputting short urls when getLocalURL was explicitly asked to output long urls, and additionally this will be done without variant handling that would have otherwise been done. Also now that I notice the comment, the &title= showing up in a short url does not look like proper implementation of a feature, even without the other issues I'd reject the patch till that was fixed. Re-reading comments again, it looks to me you have a lingering misunderstanding of $wgArticlePath, $wgActionPaths and what those blocks of code actually do. Firstly of course, that note on how in default config robots.txt can't be used is moot, the robots.txt stuff is an advanced configuration for advanced robots optimized shorturl style configuration and for the reasons you describe requires use of short urls to function. Just because a "default" configuration doesn't support it doesn't mean that it should be broken universally (this patch) when it is only supported in an advanced configuration. I should also point out that if MediaWiki detects that the server is able to support it, MediaWiki actually sets up $wgArticlePath to work in a /index.php/Article form, so robots.txt IS actually usable by default on the right server by disallowing "/index.php?". Now for the actual misunderstanding you commented "As far as I can tell, there is no use case within MediaWiki's default configuration that touches line 824 of Title.php -- there is never a URL that includes a query but not an action parameter (apart from the default 'view' action, which also bypasses line 824)." As I understand from this -- even taking your later comment on history into account -- you believe that calls to getLocalURL containing a query with an action parameter are always caught by the chunk of code between lines 807-819. That is incorrect. The block of code there is ONLY ever applied if the non-default $wgActionPaths (NOT $wgArticlePath, but $wgActionPaths) which in fact there are very very few MediaWiki installations that actually enable. So in actuality the code in lines 810-817 which does things with getLocalURL calls that have a action= in the query is actually almost NEVER run, at least not unless the wiki is one of the rare few wiki that have specially configured $wgActionPaths. The line 824 you believe is being bypassed by default in fact is actually NEVER EVER bypassed by default. By default config line 824 handles every single call to getLocalURL which contains anything at all inside the $query. And to re-iterate, the expected behavior for getLocalURL and the like is that urls with no query, and not marked with a faux "-" query to disallow shorturls will have a shorturl returned if possible. While any url with a query is ALWAYS returned in long index.php form. Changing things so that things that currently output long urls output short urls will break things. I forgot about it, but there is another reason why that /w/ robots.txt trick is used. The nature of most pages that use queries is that they are dynamic. In other words they likely contain links within them which could cause search engines to endlessly spider dynamically generated content that the wiki does not want them to spider (ie: search queries). So changing these to short urls may cause dynamic things to suddenly start being spidered by search engines when they were originally intended not to. Because of this, I believe that ANY feature we add that allows getLocalURL to return short urls with queries instead of long urls MUST be an explicit opt-in where getLocalURL is passed with an extra optional argument telling it that shorturls with queries are ok and that any code changed to use this be done by someone understanding the potential ramific
[Bug 25718] Title->getLocalURL does not respect $wgArticlePath when given a query
https://bugzilla.wikimedia.org/show_bug.cgi?id=25718 --- Comment #12 from Kiran Jonnalagadda 2010-10-31 13:06:54 UTC --- > Whoops. Completely wrong here. History browsing uses query parameters without > an action. ... and those URLs are generated without touching line 824 of Title.php, so the presence of this patch makes no difference. >From the documentation for getLocalURL: http://svn.wikimedia.org/doc/classTitle.html#a75d9fae7aabf6187318c5a298b01c5ef > $queryMixed: an optional query string; if not specified, > $wgArticlePath will be used. So the documentation is specific: $wgArticlePath is only used when no query is specified. This patch does the logically expected thing, but violates the documented expectation. -- 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 25718] Title->getLocalURL does not respect $wgArticlePath when given a query
https://bugzilla.wikimedia.org/show_bug.cgi?id=25718 --- Comment #11 from Kiran Jonnalagadda 2010-10-31 12:49:33 UTC --- > As far as I can tell, there is no use case within MediaWiki's default > configuration that touches line 824 of Title.php -- there is never a URL that > includes a query but not an action parameter (apart from the default 'view' > action, which also bypasses line 824). Whoops. Completely wrong here. History browsing uses query parameters without an action. -- 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 25718] Title->getLocalURL does not respect $wgArticlePath when given a query
https://bugzilla.wikimedia.org/show_bug.cgi?id=25718 --- Comment #10 from Kiran Jonnalagadda 2010-10-31 12:05:31 UTC --- One possible solution is to define a new 'null' or 'none' action in $wgActionPaths that gets looked up when no action is called for (this being different from the default 'view' action). getLocalURL can then use the installation's preferred URL syntax instead of assuming the use of pretty or ugly URLs. -- 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 25642] Unclean $wgSMTP pear mail package loading
https://bugzilla.wikimedia.org/show_bug.cgi?id=25642 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added Status|NEW |RESOLVED CC||ialex.w...@gmail.com Resolution||FIXED --- Comment #2 from Alexandre Emsenhuber [IAlex] 2010-10-31 11:47:42 UTC --- Patch applied in r75715 with some modifications. -- 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 25718] Title->getLocalURL does not respect $wgArticlePath when given a query
https://bugzilla.wikimedia.org/show_bug.cgi?id=25718 --- Comment #9 from Kiran Jonnalagadda 2010-10-31 11:47:34 UTC --- Thank you, Daniel. This is a great explanation. However, the exact same problem exists without the patch, in MediaWiki's default configuration with ugly URLs. Consider the URLs it would generate for an installation in /wiki: /wiki/index.php?title=Example_page /wiki/index.php?title=Example_page&month=11&year=2010 There is no way to use robots.txt to disallow the second URL without blocking the first. This, therefore, is a problem for the Semantic Result Formats extension to fix. It is not introduced by this patch. As far as I can tell, there is no use case within MediaWiki's default configuration that touches line 824 of Title.php -- there is never a URL that includes a query but not an action parameter (apart from the default 'view' action, which also bypasses line 824). Does MediaWiki come with unit tests to verify this? I'm new to the source. It appears that the patch touches an area of code that is rarely used and hence has been long overlooked. The indexing problem it potentially causes with SRF Calendar already exists without the patch. The patch only makes the function behave consistently. -- 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 23321] TOR nodes not being properly blocked
https://bugzilla.wikimedia.org/show_bug.cgi?id=23321 zzuuzz changed: What|Removed |Added Status|RESOLVED|REOPENED CC||zzu...@gmail.com Resolution|FIXED | --- Comment #16 from zzuuzz 2010-10-31 10:48:21 UTC --- I've reopened this bug, having followed it since it was first raised I can tell you that this extension has just been getting worse and is currently next to useless on enwiki. I've been consistently blocking several Tor nodes on most days since this was first raised. Now the vandals are really catching on and causing problems. I can't determine any pattern - it affects long term permanent nodes as well as more dynamic ones. All the nodes have been able to exit to Wikipedia according to any Tor checker. There's a serious failure happening somewhere, so perhaps someone could take another look. -- 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 25722] Updating page tabs
https://bugzilla.wikimedia.org/show_bug.cgi?id=25722 --- Comment #2 from Rehman 2010-10-31 09:46:14 UTC --- Sorry it the first time I'm using bugzulla. I have copied the original proposal from Wikipedia (copied from: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=393945185#Page_tabs): In the "File:" namespace (using the current new Vector theme), we used to have tabs like (in the respective colours): 1. For a file that exists: '''File''', '''Discussion''', '''Read''', '''Edit''', '''View history''' 2. For a file that doesn't exist: '''File''', '''Discussion''', '''Create''' These tabs were then changed to: 3. For a file that exists: '''File''', '''Talk''', '''Read''', '''Edit''', '''History''' 4. For a file that doesn't exist: '''File''', '''Talk''', '''Edit''' For an editor who frequently works within the File: namespace, the new colouring could be quite misleading and wastes valuable time. In sample 4, I propose renaming the blue "Edit" tab to "Create" as it was before. If this needs too much work across multiple namespaces, then at least recolour it to red. Kind regards, Rehman -- 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 25722] Updating page tabs
https://bugzilla.wikimedia.org/show_bug.cgi?id=25722 Niklas Laxström changed: What|Removed |Added CC||niklas.laxst...@gmail.com --- Comment #1 from Niklas Laxström 2010-10-31 09:41:19 UTC --- Forgot to add an description? -- 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 23731] Mostlinkedtemplates counts transclusions not links
https://bugzilla.wikimedia.org/show_bug.cgi?id=23731 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added Status|NEW |RESOLVED CC||ialex.w...@gmail.com Resolution||FIXED --- Comment #3 from Alexandre Emsenhuber [IAlex] 2010-10-31 09:37:21 UTC --- Fixed in r75713. -- 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 22768] Special:Version: add message 'others'
https://bugzilla.wikimedia.org/show_bug.cgi?id=22768 --- Comment #2 from Umherirrender 2010-10-31 09:34:49 UTC --- The core credits has a message 'version-poweredby-others' (r71367). Is 'others' still plain text input? Still WONTFIX or REOPEN? -- 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 23731] Mostlinkedtemplates counts transclusions not links
https://bugzilla.wikimedia.org/show_bug.cgi?id=23731 --- Comment #2 from Umherirrender 2010-10-31 09:22:43 UTC --- Maybe the text "Used on $1 pages" is better (compare with bug 23732). -- 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 25722] New: Updating page tabs
https://bugzilla.wikimedia.org/show_bug.cgi?id=25722 Summary: Updating page tabs Product: MediaWiki Version: unspecified Platform: All URL: http://en.wikipedia.org/w/index.php?title=Wikipedia:Vi llage_pump_%28technical%29&oldid=393945185#Page_tabs OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Vector Skin AssignedTo: tpars...@wikimedia.org ReportedBy: rehman.abub...@hotmail.com CC: asha...@wikimedia.org, rehman.abub...@hotmail.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 25721] New: Adding better parsing for single closing braces at the end of a parameter
https://bugzilla.wikimedia.org/show_bug.cgi?id=25721 Summary: Adding better parsing for single closing braces at the end of a parameter Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Templates AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: umherirrender_de...@web.de When have a parameter with a single braces at the end of the parameter, the braces does not go to the parameter: {{template|1={text}}} get parsed as {{template|1={text}} } (parameter 1 is {text) not as {{template|1={text} }} (parameter 1 is {text}). Adding a space behind the closing braces is the only way to avoid the wrong parsing. In my opinion the preprocessor should respect balanced single braces, so the example get parsed better. -- 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 25720] New: substitute LOCALTIMESTAMP can differ from REVISIONTIMESTAMP
https://bugzilla.wikimedia.org/show_bug.cgi?id=25720 Summary: substitute LOCALTIMESTAMP can differ from REVISIONTIMESTAMP Product: MediaWiki Version: unspecified Platform: All URL: http://de.wikipedia.org/w/index.php?oldid=80926825 OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Page editing AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: umherirrender_de...@web.de See URL, there is a difference between REVISIONTIMESTAMP and the substituted LOCALTIMESTAMP from 1 second. This can happen, when the parsing of that page is not in the same second than the storing in database. This can affect all timevariable (LOCAL* and CURRENT*, maybe parser function #time/timel). -- 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 19516] function userAdjust() handled user time zone not correct
https://bugzilla.wikimedia.org/show_bug.cgi?id=19516 --- Comment #2 from Umherirrender 2010-10-31 07:07:52 UTC --- I have created testpages: * Summertime: ** URL: http://de.wikipedia.org/w/index.php?oldid=80378354 ** REVISIONTIMESTAMP: 20101017135817 ** LOCALTIMESTAMP: 20101017145817 ** UTC-Timestamp of Revision: 2010-10-17T12:58:17Z * Wintertime: ** URL: http://de.wikipedia.org/w/index.php?oldid=80927014 ** REVISIONTIMESTAMP: 20101031075756 ** LOCALTIMESTAMP: 20101031075756 ** UTC-Timestamp of Revision: 2010-10-31T06:57:56Z When looking now at summertime, you will see that REVISIONTIMESTAMP and LOCALTIMESTAMP are not the same (differ by one hour). -- 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