[Bug 34330] New: Enhance the titlebar UI
https://bugzilla.wikimedia.org/show_bug.cgi?id=34330 Web browser: --- Bug #: 34330 Summary: Enhance the titlebar UI Product: Wikimedia Mobile Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: android AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: deblo...@gmail.com CC: herman.w...@nitobi.com, tf...@wikimedia.org Classification: Unclassified The dark buttons' (wiki-logo search button) contrast doesn't stand out from the dark titlebar background. And, so it is same for the menu in the tablet-layout. Let's make the search-bar more prominent (but not eye-itchy). -- 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 34305] This is an example bug for 2012 Pune Hackathon
https://bugzilla.wikimedia.org/show_bug.cgi?id=34305
--- Comment #4 from Ashwini ashwini7secur...@gmail.com 2012-02-11 08:16:10
UTC ---
Comment on attachment 9982
-- https://bugzilla.wikimedia.org/attachment.cgi?id=9982
Patch which extends the funtionality of special page
Index: Example/Example.i18n.php
===
--- Example/Example.i18n.php (revision 48)
+++ Example/Example.i18n.php (working copy)
@@ -6,8 +6,10 @@
// English
$messages[ 'en' ] = array(
'example-example' = 'This is an example!',
+ 'example-hello_world'= 'hello $1',
);
+
// Message documentation for translators
$messages[ 'qqq' ] = array(
'example-example' = 'This is just an example message. Nothing
special.',
Index: Example/Example.body.php
===
--- Example/Example.body.php (revision 48)
+++ Example/Example.body.php (working copy)
@@ -9,9 +9,23 @@
/**
* Make your magic happen!
*/
+ function getRandomName(){
+ $name_array=array();
+ $name_array ['en'] = array (
+ 'first'= 'Ashwini',
+ 'second'= 'Arthur',
+);
+}
function execute( $par ) {
global $wgOut;
+ global $wgRequest;
+ $wgOut-addWikiMsg( 'example-hello_world' );
+ echo Hello wikimedia;
- $wgOut-addWikiMsg( 'example-example' );
+
+
$wgOut-addwikimsg('example-hello_world',$this-getRandomName());
+
$wgOut-addwikimsg('example-hello_world',$wgRequest-getText('Ashwini'));
+
+
}
}
--
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 32624] API support for useformat=mobile
https://bugzilla.wikimedia.org/show_bug.cgi?id=32624 Max Semenik maxsem.w...@gmail.com changed: What|Removed |Added CC||maxsem.w...@gmail.com --- Comment #6 from Max Semenik maxsem.w...@gmail.com 2012-02-11 08:16:36 UTC --- I'm currently working on this. It looks the following way: api.php?action=parsepage=foomobileformat=wml As it's part of the normal API, all usual formats are supported, unlike the current hack. -- 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 33243] Narayam IME on fails to replace English characters on mobile
https://bugzilla.wikimedia.org/show_bug.cgi?id=33243 --- Comment #7 from Srikanth Logic srik@gmail.com 2012-02-11 09:06:23 UTC --- Narayam works peacefully on HTC 7 Trophy running Windows Phone, Couldnt verify the validity of text since WebFonts doesnt work. Has none of the above issues mentioned. -- 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 33989] Trunk CategoryTree doesn't list pages of sub categories
https://bugzilla.wikimedia.org/show_bug.cgi?id=33989 --- Comment #14 from Antoine hashar Musso has...@free.fr 2012-02-11 09:56:50 UTC --- That was fast :-) -- 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 19935] Search box highlight
https://bugzilla.wikimedia.org/show_bug.cgi?id=19935 --- Comment #6 from akshay chugh chughaksha...@gmail.com 2012-02-11 11:39:40 UTC --- Created attachment 9983 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9983 text gets higlighted as soon as the focus is brought back to the text box It works fine with Mozilla Firefox and Internet Explorer 9, but it doesnt seem to work in google chrome. -- 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 19935] Search box highlight
https://bugzilla.wikimedia.org/show_bug.cgi?id=19935 --- Comment #7 from Ashwini ashwini7secur...@gmail.com 2012-02-11 11:46:39 UTC --- Created attachment 9984 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9984 Solved problem of the text be highlighted instead of the cursor going to the end of the word solved the problem of the text be highlighted instead of the cursor going to the end of the word check out but its only work in IE and in Firefox. thanks to akhshay. -- 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 34041] Image page provides links to image resolutions greater than those supported by image scalars
https://bugzilla.wikimedia.org/show_bug.cgi?id=34041 Lejonel lejo...@telia.com changed: What|Removed |Added CC||lejo...@telia.com --- Comment #5 from Lejonel lejo...@telia.com 2012-02-11 12:24:03 UTC --- This is easy to fix by changing default value of $wgImageLimits in DefaultSettings.php (or locally in Wikimedias local settings file). $wgImageLimits is also the options for the user preference for image preview size on file description pages. But a 1x1px option is not very useful for that either, since it will not be rendered. -- 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 19935] Search box highlight
https://bugzilla.wikimedia.org/show_bug.cgi?id=19935 Sumana Harihareswara suma...@panix.com changed: What|Removed |Added Keywords||need-review, patch --- Comment #8 from Sumana Harihareswara suma...@panix.com 2012-02-11 12:34:57 UTC --- Hi, Ashwini and Akshay. Thank you for the patches! As you can see in https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Submit_your_changes in order to signal to the development community that this Bugzilla bug report has a patch associated with it that needs review, you should add the keywords patch and need-review I've now done this for you, but in the future, please do it yourself every time you add a patch in Bugzilla. Thanks. Have you run the automated test suites against your patch(es)? That's a very good way to find problems. https://www.mediawiki.org/wiki/Manual:PHP_unit_testing and https://www.mediawiki.org/wiki/Manual:PHP_unit_testing/Installing_PHPUnit will help you. If you have any trouble, please find us in #mediawiki on Freenode and ask! -- 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 19935] Search box highlight
https://bugzilla.wikimedia.org/show_bug.cgi?id=19935 --- Comment #9 from Arthur Richards aricha...@wikimedia.org 2012-02-11 12:43:28 UTC --- (In reply to comment #8) Hi, Ashwini and Akshay. Thank you for the patches! As you can see in https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Submit_your_changes in order to signal to the development community that this Bugzilla bug report has a patch associated with it that needs review, you should add the keywords patch and need-review Unfortunately, they were not able to add the keywords. I assume this was a limitation of the user permissions for newly created accounts? -- 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 34041] Image page provides links to image resolutions greater than those supported by image scalars
https://bugzilla.wikimedia.org/show_bug.cgi?id=34041 --- Comment #6 from Lejonel lejo...@telia.com 2012-02-11 12:45:07 UTC --- (In reply to comment #5) Actually it can be useful since it displays the full resolution of images smaller than 1x1. -- 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 19935] Search box highlight
https://bugzilla.wikimedia.org/show_bug.cgi?id=19935 --- Comment #10 from Sumana Harihareswara suma...@panix.com 2012-02-11 12:48:28 UTC --- (In reply to comment #9) Unfortunately, they were not able to add the keywords. I assume this was a limitation of the user permissions for newly created accounts? Yes, argh. I've added the ability to edit keywords to Akshay's and Ashwini's Bugzilla accounts and will have to consider whether we should modify this lockdown to balance between between security and access/usability. -- 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 33997] SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page
https://bugzilla.wikimedia.org/show_bug.cgi?id=33997 Aashish Mittal ashishmittal.m...@gmail.com changed: What|Removed |Added CC||ashishmittal.m...@gmail.com --- Comment #1 from Aashish Mittal ashishmittal.m...@gmail.com 2012-02-11 12:53:54 UTC --- Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish -- 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 33997] SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page
https://bugzilla.wikimedia.org/show_bug.cgi?id=33997 --- Comment #2 from T. Gries m...@tgries.de 2012-02-11 13:21:28 UTC --- (In reply to comment #1) As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Aashish I think, I need to give a detailed analysis. Allow me to use some bold words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password reset mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to https://server/phase3/index.php/Main_Page - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password reset mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like a temporary password has been successfully mailed to ...) - you goto to your mail - you DO NOT click on the link in your mail (the link goes to https://server/phase3/index.php/Main_Page) - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto https://server/phase3/index.php?title=Special:UserLoginreturnto=Special%3APasswordReset because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at Special:PasswordReset , which is correct behaviour of the Wiki software, but not what a user wants. -- 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 33834] Make Special:MIMESearch more user friendly
https://bugzilla.wikimedia.org/show_bug.cgi?id=33834 --- Comment #1 from Subfader subfa...@gmail.com 2012-02-11 13:31:30 UTC --- Same for the pretty useless Special:UnusedFiles -- 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 34331] New: Make Special:UnusedFiles more useful
https://bugzilla.wikimedia.org/show_bug.cgi?id=34331 Web browser: --- Bug #: 34331 Summary: Make Special:UnusedFiles more useful Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: subfa...@gmail.com Classification: Unclassified Special:UnusedFiles is pretty useless. 1) Add the future MIME type selector from Special:MIMESearch https://bugzilla.wikimedia.org/show_bug.cgi?id=33834 2) Add an user name input to select pages by the uploader / page creator This way it will be possible to make useful queries like List all unused PDF files I uploaded -- 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 33834] Make Special:MIMESearch more user friendly
https://bugzilla.wikimedia.org/show_bug.cgi?id=33834 --- Comment #2 from Subfader subfa...@gmail.com 2012-02-11 13:43:55 UTC --- ^^ = The MIME type selcetor could be used on other specials as well: https://bugzilla.wikimedia.org/show_bug.cgi?id=34331 -- 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 34198] first item in the history shows no information about its size
https://bugzilla.wikimedia.org/show_bug.cgi?id=34198 --- Comment #5 from Umherirrender umherirrender_de...@web.de 2012-02-11 14:20:49 UTC --- Created attachment 9985 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9985 show always a size I have create a patch, which change the two places in HistoryAction and SpecialContributions: If the prevRev or the parentLen not set, use a 0 for the old size. The patch also improves the use of LinkBatch on that two pages. Feel free to modify the 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 34198] first item in the history shows no information about its size
https://bugzilla.wikimedia.org/show_bug.cgi?id=34198 Umherirrender umherirrender_de...@web.de changed: What|Removed |Added Keywords||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 30993] SMW 1.6.1 with SMWSparqlStore: Erroneous SPARQL for property value comparison queries
https://bugzilla.wikimedia.org/show_bug.cgi?id=30993 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added 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 30245] Use full localized name for Special:Log in IRC RC feed
https://bugzilla.wikimedia.org/show_bug.cgi?id=30245 --- Comment #18 from Umherirrender umherirrender_de...@web.de 2012-02-11 14:31:21 UTC --- FYI: reverted with r111006 for 1.19 -- 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 30993] SMW 1.6.1 with SMWSparqlStore: Erroneous SPARQL for property value comparison queries
https://bugzilla.wikimedia.org/show_bug.cgi?id=30993 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 14:44:55 UTC --- Fixed in r111235. The braces are now only placed if not a filter. -- 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 34332] New: add links to COM:OTRS
https://bugzilla.wikimedia.org/show_bug.cgi?id=34332 Web browser: --- Bug #: 34332 Summary: add links to COM:OTRS Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: UploadWizard AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: saibotr...@arcor.de CC: asha...@wikimedia.org, ne...@wikimedia.org Classification: Unclassified See http://commons.wikimedia.org/wiki/Commons_talk:Upload_Wizard#COM:OTRS_and_subst:OP Users have no clue of that needed process when they upload. -- 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 34328] Syntax error in CentralAuthPlugin.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=34328 Sam Reed (reedy) s...@reedyboy.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Sam Reed (reedy) s...@reedyboy.net 2012-02-11 15:03:36 UTC --- Cheers. In future, please mention on what version you spot these errors r111238 -- 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 34333] New: multi file selection with FF10 fails
https://bugzilla.wikimedia.org/show_bug.cgi?id=34333 Web browser: --- Bug #: 34333 Summary: multi file selection with FF10 fails Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: UploadWizard AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: saibotr...@arcor.de CC: asha...@wikimedia.org, ne...@wikimedia.org Classification: Unclassified At least under Linux with FF10. Select two files (with holding down shift key), try to upload, result: testsmiley.jpg This file might be corrupt, or have the wrong extension. testsmiley.png The file you submitted was empty. -- 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 30989] SMW 1.6.1 - Query Modification date property fails when using SMWSparqlStore
https://bugzilla.wikimedia.org/show_bug.cgi?id=30989 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added 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 1310] Recursive tags in extensions.
https://bugzilla.wikimedia.org/show_bug.cgi?id=1310 Gabriel Wicke wi...@wikidev.net changed: What|Removed |Added CC||wi...@wikidev.net --- Comment #23 from Gabriel Wicke wi...@wikidev.net 2012-02-11 15:33:04 UTC --- From an implementation standpoint, simply matching up the closest start/end tag is definitely easier than building a stack to enable nested tag pairs. I am also not convinced that nested tag pairs would be a good UI design, as it seems to make the distinction of regular wiki content and input to an extension harder than necessary. Could you present a compelling use case that demonstrates the need to use the same tags both to delimit the extension inputs and the input itself? -- 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 34334] New: add a footer to Special:Contributions for newbie mode
https://bugzilla.wikimedia.org/show_bug.cgi?id=34334 Web browser: --- Bug #: 34334 Summary: add a footer to Special:Contributions for newbie mode Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: need-review, patch Severity: enhancement Priority: Unprioritized Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: umherirrender_de...@web.de Classification: Unclassified Created attachment 9986 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9986 add a sp-contributions-footer-newbies message as footer On the german wiki we have a legend about the different colors of flagged revs for each item in the footer of Special:Contributions for users and anons. Having a footer also for the newbie mode, makes it possible to show the same legend there. The user can see the colors and have not to look at another place for the legend. I have create a patch, to add a message there. Feel free to modfiy the patch. Thanks. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 1310] Recursive tags in extensions.
https://bugzilla.wikimedia.org/show_bug.cgi?id=1310 --- Comment #24 from Gabriel Wicke wi...@wikidev.net 2012-02-11 15:35:23 UTC --- The last sentence should naturally end with *and in the input itself*. An edit button would be handy sometimes. -- 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 33480] Add Telugu Transliteration input method to Narayam
https://bugzilla.wikimedia.org/show_bug.cgi?id=33480 Veeven vee...@gmail.com changed: What|Removed |Added Attachment #9899|0 |1 is obsolete|| --- Comment #5 from Veeven vee...@gmail.com 2012-02-11 15:41:04 UTC --- Created attachment 9987 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9987 ext.narayam.rules.te.js New script fixing (1) couple of mistakes (ఢ and ధ); (2) adding missed mapping for ఠ. -- 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 30989] SMW 1.6.1 - Query Modification date property fails when using SMWSparqlStore
https://bugzilla.wikimedia.org/show_bug.cgi?id=30989 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 15:44:01 UTC --- Fixed in r111241. However, the problem was not in the wrong query. The query is actually mostly correct. SMW stores dates redundantly in RDF because many RDF stores do not support dates, or only support them in a limited range (in contrast, SMW's date type can store remote past and future times as well as current events). Therefore, every SMW date is also stored in a numerical form that is used for sorting and querying. This had been missing for Modification date, hence the query did not find results. The fix was to store the required data. Therefore, the update will only take effect for new modifications but not fix the entries for existing pages. A general SMW data update (Special:SMWAdmin) could be used to refresh all pages' data. -- 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 34335] New: #time problem in fa.wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=34335
Web browser: ---
Bug #: 34335
Summary: #time problem in fa.wiki
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: reza.ene...@gmail.com
Classification: Unclassified
Hi,
I wanted to use
{{safesubst:#time:Y-m-d|{{{4|}}} {{{2|}}} {{{1|}}}
like http://en.wikipedia.org/wiki/Template:Prod_subcategory_starter
in fa.wiki it shows error. I changed it to
{{safesubst:#time:Y-m-d|{{formatnum:{{{4|}}}|R}} {{formatnum:{{{2|}}}|R}}
{{formatnum:{{{1|}}}|R}} }}
but it doesn't change!
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 33687] Unresolved prefixed name in SPARQL Query
https://bugzilla.wikimedia.org/show_bug.cgi?id=33687 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 16:02:35 UTC --- Thanks for the detailed report. Fixed in r111243 in the way you suggested. As a side remark (not related to this bug, but maybe a new bug/request ...), I note that custom URIs will not work well with the SPARQL backend in general. You should not be able to retrieve pages with custom URIs (using vocabulary import) in #ask queries, since SMW has no way of translating custom URIs (retrieved by SPARQL) back into wiki pages. Anyway, custom URIs should still not lead to critical errors, so it is good that this bug is fixed now. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 34336] New: location entry tooltip should link to [[commons:Commons:Geocoding]]
https://bugzilla.wikimedia.org/show_bug.cgi?id=34336 Web browser: --- Bug #: 34336 Summary: location entry tooltip should link to [[commons:Commons:Geocoding]] Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: UploadWizard AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: saibotr...@arcor.de CC: asha...@wikimedia.org, ne...@wikimedia.org Classification: Unclassified location entry tooltip: Die Koordinaten des Standortes, an dem diese Mediendatei erstellt wurde. The location entry should link to [[commons:Commons:Geocoding]]. Also it should mention that it is not useful to enter a location for all kinds of media. It does not matter where a recording of a flute was made. -- 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 34337] New: tooltips in describe step do not close
https://bugzilla.wikimedia.org/show_bug.cgi?id=34337 Web browser: --- Bug #: 34337 Summary: tooltips in describe step do not close Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: trivial Priority: Unprioritized Component: UploadWizard AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: saibotr...@arcor.de CC: asha...@wikimedia.org, ne...@wikimedia.org Classification: Unclassified ... on clicking on them or somewhere else. The only way to close them is to click exactly where you opened 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 30542] SMWSparqlDatabaseError while running runJobs.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=30542 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #5 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 16:20:44 UTC --- This is very strange. The queries are not malformed SPARQL, and if I run them on my 4Store v1.1.3 directly, then they do not cause any problems. I also don't get results (since I don't have your data) but I can change the namespaces and URIs so that I get results also on my machine. However, your report helped me to find another small problem: the error message reported that the update endpoint had been used, although the query endpoint has really been used (also in your case, according to stack trace). This is fixed in r111244. But the other problem I can only close as works for me. If the problem still occurs, you should try to run the offending queries on your machine (via http://localhost:8000/test/) and see what the exact error message is (if any). If it turns out that the query is really broken, we can fix it in SMW (and you can reopen this bug). If the query is accepted or if it leads to an error in spite of being correct SPARQL, then the problem is with 4Store and should be reported there. -- 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 32280] SMW_SparqlDatabase sends incorrect Accept header with SPARQL query requests
https://bugzilla.wikimedia.org/show_bug.cgi?id=32280 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 16:28:29 UTC --- Good point, thanks for the report. Fixed in r111245 by using your patch. (I am surprised though, that any SPARQL database, upon receiving a request that does not specify the result format, would choose to return anything else than the standard W3C format. But it is good to know that it works with Sesame with this modification.) -- 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 30076] RDF Export
https://bugzilla.wikimedia.org/show_bug.cgi?id=30076 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 16:40:13 UTC --- This would be undesired behaviour. In my current version (SMW 1.7.1 r111232), however, rdf:type and rdfs:subClassOf are used as expected. The same is true for the SMW homepage. So it should have been a temporary glitch that got fixed in the meantime. If the problem persists on your site, please reopen this bug and provide further details about the SMW-related configurations in your LocalSettings. -- 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 31907] Exception in SMW RDF Query Printer
https://bugzilla.wikimedia.org/show_bug.cgi?id=31907 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 16:44:56 UTC --- This issue has been fixed as part of other bug reports. Closing this forgotten report 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 30430] Server aborts connection when running into setting Property of type text around 400 characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=30430 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 16:49:23 UTC --- I am closing this now as there does not seem a way to reproduce this on current versions of SMW. -- 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 32592] v1.6.1 and v1.7.0 / SMW_conceptCache.php --create fails
https://bugzilla.wikimedia.org/show_bug.cgi?id=32592 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #22 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 16:57:48 UTC --- Dear MWJames, you seem to be reporting at least two independent issues here that are not the original failure (which is fixed). If these problems persist, please open separate bug reports on each. A few hints: the 1 elements might be a limitation from the global query limit settings, since it happens to be the default value of $smwgQMaxLimit. This should be checked. The problems with some complex concepts needs more details: do the queries work when using #ask? can the problem be reproduced on the SMW sandbox? are only queries with certain feature combinations affected? -- 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 30076] RDF Export
https://bugzilla.wikimedia.org/show_bug.cgi?id=30076 --- Comment #2 from laurinf laur...@gmail.com 2012-02-11 17:06:50 UTC --- Yes, it looks like a temporary glitch in version 1.5.6 as the problem got solved when I installed SMW 1.6.0. Thank you! -- 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 33705] Sorting by property drops results where that property value is not set
https://bugzilla.wikimedia.org/show_bug.cgi?id=33705 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Severity|critical|enhancement --- Comment #2 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 17:06:51 UTC --- Actually, this is not a bug but the expected behaviour. SMW requires sort properties to be set. If anything else is documented in the manual, then this should be corrected. It might be possible to change the SQL and SPARQL generation procedures to do this differently, but I think there is a risk of this leading to problems with various database tools, even if it is allowed according to the respective standards. And it might have an impact on performance. I leave this open as a feature request in case somebody wants to take this challenge in the future. -- 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 34338] New: Create a mailing list for the Wikidata project proposal
https://bugzilla.wikimedia.org/show_bug.cgi?id=34338 Web browser: --- Bug #: 34338 Summary: Create a mailing list for the Wikidata project proposal Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Mailing lists AssignedTo: b...@caseybrown.org ReportedBy: denny.vrande...@kit.edu CC: phili...@wikimedia.org Classification: Unclassified The proposed Wikidata project http://meta.wikimedia.org/wiki/Wikidata would require (for now) one mailing list for general discussion, announcements, and to allow people to stay informed. I assume we might late branch into a wikidata-dev and wikidata-announce list. Please use denny.vrande...@wikimedia.de as the initial admin for the list. I will then expand the list. The suggested name is wikidata-l -- 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 33705] Request: sort by property values without restricting query results to require this property value
https://bugzilla.wikimedia.org/show_bug.cgi?id=33705 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Summary|Sorting by property drops |Request: sort by property |results where that property |values without restricting |value is not set|query results to require ||this property value -- 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 33705] Request: sort by property values without restricting query results to require this property value
https://bugzilla.wikimedia.org/show_bug.cgi?id=33705 --- Comment #3 from Niklas Laxström niklas.laxst...@gmail.com 2012-02-11 17:44:06 UTC --- The use case is very clear: you have items you want to show in some order, not all of them might have the sorting field set. -- 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 32594] SMW: [[Corresponds to::0 xxx]] causes divizion by zero, internal error message and PHP stack dump
https://bugzilla.wikimedia.org/show_bug.cgi?id=32594 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 17:54:18 UTC --- Fixed in r111248. A warning is not shown though. I don't think this is really necessary in practice. -- 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 31303] site.css has errors per firebug
https://bugzilla.wikimedia.org/show_bug.cgi?id=31303 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Priority|Unprioritized |Low --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 18:02:20 UTC --- Please be a bit more specific. Which site? I do not see any errors in Firebug using SMW. -- 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 30717] nowiki in property throws fatal error
https://bugzilla.wikimedia.org/show_bug.cgi?id=30717 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 18:11:25 UTC --- Fixed in r111250. As usual, nowiki, math, etc. do not work in SMW values since their content is replaced by MediaWiki only later (so SMW does not know what was written there). It is now ensured that even in this case, the value object is initialised properly, so that errors like the above are prevented. -- 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 34198] first item in the history shows no information about its size
https://bugzilla.wikimedia.org/show_bug.cgi?id=34198 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Mark A. Hershberger m...@everybody.org 2012-02-11 18:11:35 UTC --- r111251 -- 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 31377] Fatal error: Call to undefined method SMWDIError::getLatitude()
https://bugzilla.wikimedia.org/show_bug.cgi?id=31377 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Component|Semantic MediaWiki |SemanticMaps AssignedTo|wikibugs-l@lists.wikimedia. |jeroen_ded...@yahoo.com |org | --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 18:17:28 UTC --- I am not sure whether this is an SMW or an SMW bug either. Clearly, SM treats an objects as a coordinate that really is an error. Most likely, this just means that SM forgot to check if the object has errors before accessing it. On the other hand, it could be that SMW returns such an error object in a place where it promises to not do this. Then it would be an SMW issue. But the entry point clearly is SM here, so I reassign this accordingly and let Jeroen decide whether he thinks it should be changed back to SMW. -- 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 34275] Languages with low localisation level and a fallback, show the fallback localisation
https://bugzilla.wikimedia.org/show_bug.cgi?id=34275 Robin Pepermans (SPQRobin) robinp.1...@gmail.com changed: What|Removed |Added Keywords||code-update-regression -- 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 33179] spurious #ask results in namespace query
https://bugzilla.wikimedia.org/show_bug.cgi?id=33179 --- Comment #3 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 18:23:19 UTC --- The bug that kept you from using refreshdata has now been closed, so you could give it another try. However, refreshdata does not clean up duplicate entries in the ID table, if such entries should exists in your case. One radical way to fix the database is to delete and recreate the SMW tables before re-running a refresh. This is also explained in the documentation: http://semantic-mediawiki.org/wiki/Help:Repairing_SMW%27s_data#Rebuilding_everything Doing this should always reset your wiki to a clean default state. Please let us know if the problem persists or if there is any way of reproducing the error (i.e., of creating new duplicates). -- 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 31153] SMW_setup --delete fails for postgresql
https://bugzilla.wikimedia.org/show_bug.cgi?id=31153 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 18:27:45 UTC --- Should be fixed in r111252 (you may or may not want to try 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 29892] SMW persistently shows deleted pages
https://bugzilla.wikimedia.org/show_bug.cgi?id=29892 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 18:32:35 UTC --- *** This bug has been marked as a duplicate of bug 18406 *** -- 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 18406] Pages without wiki content in query results (ghostpages)
https://bugzilla.wikimedia.org/show_bug.cgi?id=18406 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added CC||fastgoldf...@gmail.com --- Comment #2 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 18:32:35 UTC --- *** Bug 29892 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 30669] [[:+]] returns garbage
https://bugzilla.wikimedia.org/show_bug.cgi?id=30669 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 18:35:01 UTC --- Since no additional details have been provided on this issue, I am now closing it. It can be reopened if it is clearer what the problem is. To clarify, the given query should return all pages in the Main namespace, which will naturally involve a lot of garbage on most sites. Independently, Bug18406 might still apply, leading to additional historic garbage to be returned, but this has nothing to do with this query. -- 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 31152] [postgresql] Database upgrades fail when adding NOT NULL fields
https://bugzilla.wikimedia.org/show_bug.cgi?id=31152 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Summary|Database upgrades fail when |[postgresql] Database |adding NOT NULL fields |upgrades fail when adding ||NOT NULL fields Severity|major |normal -- 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 27380] [postgresql] PostgreSQL Error in SMW_SQLStore2.php at 1106
https://bugzilla.wikimedia.org/show_bug.cgi?id=27380 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Summary|PostgreSQL Error in |[postgresql] PostgreSQL |SMW_SQLStore2.php at 1106 |Error in SMW_SQLStore2.php ||at 1106 -- 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 33566] EditWarning should use $.fn.bind instead of window.onbeforeunload directly
https://bugzilla.wikimedia.org/show_bug.cgi?id=33566 --- Comment #5 from Mark A. Hershberger m...@everybody.org 2012-02-11 18:39:49 UTC --- (In reply to comment #4) Created attachment 9948 [details] Untested patch Is there any reason to keep this out of 1.19? -- 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 33886] to support for microdata and rdfa, allow a tags so external links can have ref/rel attributes
https://bugzilla.wikimedia.org/show_bug.cgi?id=33886 Mark A. Hershberger m...@everybody.org 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 32589] v1.6.1 - v1.7.1a2 SMW_conceptCache.php --delete fails
https://bugzilla.wikimedia.org/show_bug.cgi?id=32589 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 18:55:45 UTC --- I hope I fixed this in r111253. Including counter.php is no longer necessary, so I just removed the offending line. The problem you got seems to be related to the recent problem reports of other users about files that could not be found by maintenance scripts (esp. Bug33400), but here it was easier to solve. -- 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 31377] Fatal error: Call to undefined method SMWDIError::getLatitude()
https://bugzilla.wikimedia.org/show_bug.cgi?id=31377 --- Comment #2 from Jeroen De Dauw jeroen_ded...@yahoo.com 2012-02-11 19:18:34 UTC --- Hay Dan, sorry for not getting back to you earlier. I remember fixing something like this at least some months back. Are you sure it is still present in the latest releases? -- 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 33997] SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page
https://bugzilla.wikimedia.org/show_bug.cgi?id=33997
--- Comment #3 from Aashish Mittal ashishmittal.m...@gmail.com 2012-02-11
19:23:56 UTC ---
Created attachment 9988
-- https://bugzilla.wikimedia.org/attachment.cgi?id=9988
changes to SpecialUserLogin to return to Main_Page after a password change
Hello,
Thanks for the detailed explanation. I reproduced the second scenario and was
able to figure out the following solutions for it:
1. Modification of SpecialUserLogin to check if the returntitle is
PasswordReset. If yes, make the returnto empty.
The code snippet is:
# Do not redirect back to PasswordReset (instead to the Main_Page) after a
successful password change
if( is_object( $returnToTitle ) $returnToTitle-isSpecial(
'PasswordReset' ) ) {
$this-mReturnTo = '';
$this-mReturnToQuery = '';
}
In this case, the returnto is still set to PasswordReset in the url, but after
Login submission, the returnto is made emptied. Similar solution exits for the
UserLogout page. In the case of UserLogout, if I manually go to UserLogout and
click on Login, the returnto is set to UserLogout. Hence after successful
login, the user would be returned to Logout page, but similar code prevents it
from going to Logout page.
2. Second solution is to modify the SkinTemplate to modify the login url
itself. In the SkinTemplate, I can check the $wgRequest-getVal('returnto') and
if it is set to PasswordReset, I can modify it to Main_Page. This would change
the returnto in the $loginurl itself and would be used to return the user back
to main page once the user has logged in.
I am attaching a patch for the former, kindly give your review which solution
is more suitable and if the code and the output seems fine.
Thanks in advance.
Regards,
Aashish
--
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 34303] Comments: Server must reject comments if they come from users without comment right.
https://bugzilla.wikimedia.org/show_bug.cgi?id=34303 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added CC||m...@everybody.org --- Comment #4 from Mark A. Hershberger m...@everybody.org 2012-02-11 19:30:48 UTC --- If you provide a fuller patch covering all the conditions you think should be covered, then I can apply it. Please see https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Submit_your_changes for more info on how to do this, if needed. -- 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 34303] Comments: Server must reject comments if they come from users without comment right.
https://bugzilla.wikimedia.org/show_bug.cgi?id=34303 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Keywords|need-review |reviewed Priority|Unprioritized |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 34305] This is an example bug for 2012 Pune Hackathon
https://bugzilla.wikimedia.org/show_bug.cgi?id=34305 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Priority|Unprioritized |Low CC||m...@everybody.org -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 34307] Page doesn't scroll when dragging selection off bottom of window in visual editor
https://bugzilla.wikimedia.org/show_bug.cgi?id=34307 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Priority|Unprioritized |Normal CC||m...@everybody.org -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 34308] HTML/JS/XSS injection in visual editor (attribute sanitation on links)
https://bugzilla.wikimedia.org/show_bug.cgi?id=34308 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Priority|Unprioritized |High CC||m...@everybody.org -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 34314] parser does not preserve whitespace in tag attributes passed to extensions.
https://bugzilla.wikimedia.org/show_bug.cgi?id=34314 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Priority|Unprioritized |Lowest Status|NEW |RESOLVED CC||m...@everybody.org 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 34318] Pages are repeatedly recreated despite deletion and create-protection
https://bugzilla.wikimedia.org/show_bug.cgi?id=34318 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Priority|Unprioritized |High 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 27509] Resourceloader does not honor #REDIRECT in user script pages
https://bugzilla.wikimedia.org/show_bug.cgi?id=27509 duplicate...@googlemail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||duplicate...@googlemail.com Resolution||DUPLICATE --- Comment #4 from duplicate...@googlemail.com 2012-02-11 19:42:01 UTC --- *** This bug has been marked as a duplicate of bug 30074 *** -- 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 30074] Redirecting css/js wiki pages shouldn't cause syntax errors when loaded as a module.
https://bugzilla.wikimedia.org/show_bug.cgi?id=30074 duplicate...@googlemail.com changed: What|Removed |Added CC||dan...@schwen.de --- Comment #8 from duplicate...@googlemail.com 2012-02-11 19:42:01 UTC --- *** Bug 27509 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 33177] spurious #ask results with unknown namespace
https://bugzilla.wikimedia.org/show_bug.cgi?id=33177 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 19:49:34 UTC --- This is normal behaviour. If part of a query is not understood, SMW will run the query anyway with the remaining conditions. In this case, there are no conditions, and all pages (including the historical ones of Bug 18406) are returned. However, I agree that it makes sense to stop query processing in any case if there are errors and no valid conditions were found. This is implemented now in r111255. In general, you can set $smwgIgnoreQueryErrors = false in LocalSettings to make SMW stop query answering when errors are found (whether or not the query is empty). -- 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 34321] Do not escape some entities used in pipe-separator in Special:Contributions
https://bugzilla.wikimedia.org/show_bug.cgi?id=34321 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added CC||m...@everybody.org --- Comment #1 from Mark A. Hershberger m...@everybody.org 2012-02-11 19:51:57 UTC --- Note that it does this only for the sequence of messages which is (histlast)(pipe-separator)(histfirst) and not on the individual lines which are (diff)(pipe-separator)(hist) (Message sequences from uselang=qqx) -- 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 27509] Resourceloader does not honor #REDIRECT in user script pages
https://bugzilla.wikimedia.org/show_bug.cgi?id=27509 mybugs.m...@gmail.com changed: What|Removed |Added CC||mybugs.m...@gmail.com --- Comment #5 from mybugs.m...@gmail.com 2012-02-11 19:57:22 UTC --- *** This bug has been marked as a duplicate of bug 33973 *** -- 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 33973] MediaWiki should follow redirects on css/js pages
https://bugzilla.wikimedia.org/show_bug.cgi?id=33973 mybugs.m...@gmail.com changed: What|Removed |Added CC||dan...@schwen.de --- Comment #1 from mybugs.m...@gmail.com 2012-02-11 19:57:22 UTC --- *** Bug 27509 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 34339] New: ResourceLoader checks touched date twice for some pages
https://bugzilla.wikimedia.org/show_bug.cgi?id=34339
Web browser: ---
Bug #: 34339
Summary: ResourceLoader checks touched date twice for some
pages
Product: MediaWiki
Version: 1.19-svn
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Resource Loader
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: duplicate...@googlemail.com
CC: krinklem...@gmail.com, roan.katt...@gmail.com,
tpars...@wikimedia.org
Classification: Unclassified
For modules with js and css pages, the ResourceLoader is checking the touched
date twice for all pages of that module. The first time, when building the CSS
and the second time, when building the scripts.
For example:
SELECT page_namespace,page_title,page_touched FROM `page` WHERE (page_namespace
= '8' AND page_title IN
('Common.js','Common.css','Vector.js','Vector.css','Print.css') )
Callers:
MediaWiki::run/MediaWiki::main/MediaWiki::finalCleanup/OutputPage::output/SkinTemplate::outputPage/Skin::bottomScripts/OutputPage::getBottomScripts/OutputPage::getScriptsForBottomQueue/OutputPage::makeResourceLoaderLink/ResourceLoaderWikiModule::isKnownEmpty/ResourceLoaderWikiModule::getTitleMtimes/DatabaseBase::select
SELECT page_namespace,page_title,page_touched FROM `page` WHERE (page_namespace
= '8' AND page_title IN
('Common.js','Common.css','Vector.js','Vector.css','Print.css') )
Callers:
MediaWiki::run/MediaWiki::main/MediaWiki::finalCleanup/OutputPage::output/SkinTemplate::outputPage/OutputPage::headElement/OutputPage::buildCssLinks/OutputPage::makeResourceLoaderLink/ResourceLoaderWikiModule::isKnownEmpty/ResourceLoaderWikiModule::getTitleMtimes/DatabaseBase::select
This is the same for the group-*.js/.css pages
(ResourceLoaderUserGroupsModule).
When the module only contains css pages, there is only one select
(ResourceLoaderNoscriptModule)
So you have 5 queries for loggedin users. You can reduce this to 3, maybe
combine all to one query? When this is already done in the ResourceLoader2,
than mark this as FIXED.
Thanks.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19948] Special:UnusedProperties produces database error for PostgreSQL
https://bugzilla.wikimedia.org/show_bug.cgi?id=19948 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #21 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 20:08:04 UTC --- Sorry for keeping you waiting. Patch applied in r111256. I hope this fixes the issue in PostgreSQL. I kept the TEMPORARY keyword for non-postgres databases, since I am not certain that DROP can be done by users that have only DROP TEMPORARY privileges, even if the dropped table happens to be temporary. -- 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 29753] mw.util.tooltipAccessKeyPrefix should be alt-shift for Firefox 3+ and Chromium 12
https://bugzilla.wikimedia.org/show_bug.cgi?id=29753 Christian Stricker chs...@googlemail.com changed: What|Removed |Added CC||chs...@googlemail.com --- Comment #9 from Christian Stricker chs...@googlemail.com 2012-02-11 20:10:59 UTC --- I also use Chrome and read an blog article recently (http://googlesystem.blogspot.com/2012/02/keyboard-accelerators-in-google.html) in which is claimed, that you can override Chrome's default behavior for alt+f and so on. We could also do this with the search shortcut, so users wouldn't have to distinguish between e.g. IE and Chrome, what shortcut to use! -- 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 1310] Recursive tags in extensions.
https://bugzilla.wikimedia.org/show_bug.cgi?id=1310
--- Comment #25 from Bawolff bawolff...@gmail.com 2012-02-11 20:15:23 UTC ---
(In reply to comment #23)
From an implementation standpoint, simply matching up the closest start/end
tag
is definitely easier than building a stack to enable nested tag pairs. I am
also not convinced that nested tag pairs would be a good UI design, as it
seems
to make the distinction of regular wiki content and input to an extension
harder than necessary.
Could you present a compelling use case that demonstrates the need to use the
same tags both to delimit the extension inputs and the input itself?
There are two examples I could see where this may be wanted
* ref tags so people could do nested ref stuff without {{#tag:ref hackery.
* source tag's for when highlighting xml-ish things that have a source
inside them (since they would usually have a closing source tag as well, but
that's more like accidentally fixing an issue then actually fixing an issue).
But I also tend to agree that it may not be worth the effort.
--
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 34041] Image page provides links to image resolutions greater than those supported by image scalars
https://bugzilla.wikimedia.org/show_bug.cgi?id=34041 --- Comment #7 from Bawolff bawolff...@gmail.com 2012-02-11 20:22:47 UTC --- (In reply to comment #5) This is easy to fix by changing default value of $wgImageLimits in DefaultSettings.php (or locally in Wikimedias local settings file). $wgImageLimits is also the options for the user preference for image preview size on file description pages. But a 1x1px option is not very useful for that either, since it will not be rendered. Seems a weird choice for a default then (and it seems to go way back to r5195). (In reply to comment #6) (In reply to comment #5) Actually it can be useful since it displays the full resolution of images smaller than 1x1. We should have a non-hacky way of specifying this in user preferences then. -- 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 29366] Call to undefined method SMWDIContainer::getDVs()
https://bugzilla.wikimedia.org/show_bug.cgi?id=29366 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 20:25:51 UTC --- This has been fixed in the meantime, and getDVs() is not used any more. The problem was also mentioned in Bug 30284 (which is mainly about another issue that may prevent record fields to be addressed using the index parameter). -- 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 34340] New: GenderCache: Extract username from subpages when do the query for LinkBatch
https://bugzilla.wikimedia.org/show_bug.cgi?id=34340
Web browser: ---
Bug #: 34340
Summary: GenderCache: Extract username from subpages when do
the query for LinkBatch
Product: MediaWiki
Version: 1.19-svn
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: duplicate...@googlemail.com
Classification: Unclassified
When adding a user page to the LinkBatch, this results also to a query in
GenderCache to get the gender for the namespace distinction. But GenderCache is
not extracting the user from a title with subpage, like Title::getNsText.
The GenderCache can also do a valid check to the username, because that sounds
cheaper, than a database query, which newer found a row for ips (but after
extracting the subpage). It can maybe cache the invalid username, to avoid
checking that twice.
See r82029#c29083
See the 3 queries done for that:
The LinkBatch query: All is right here.
SELECT page_id,page_namespace,page_title,page_len,page_is_redirect,page_latest
FROM `page` WHERE (page_namespace = '2' AND page_title IN
('127.0.0.1','User/Subpage') ) OR (page_namespace = '1' AND page_title =
'Hauptseite')
Callers:
MediaWiki::run/MediaWiki::main/MediaWiki::performRequest/SpecialPageFactory::executePath/SpecialContributions::execute/IndexPager::getBody/ContribsPager::doBatchLookups/LinkBatch::execute/LinkBatch::executeInto/LinkBatch::doQuery/DatabaseBase::select
The query from GenderCache, you see, that it search for the user with subpage
and search for the ip, which never has a row in the database.
SELECT user_name,up_value FROM `user` LEFT JOIN `user_properties` ON ((user_id
= up_user) AND up_property = 'gender') WHERE user_name IN
('127.0.0.1','User/Subpage')
Callers:
MediaWiki::run/MediaWiki::main/MediaWiki::performRequest/SpecialPageFactory::executePath/SpecialContributions::execute/IndexPager::getBody/ContribsPager::doBatchLookups/LinkBatch::execute/LinkBatch::executeInto/LinkBatch::doGenderQuery/GenderCache::doLinkBatch/GenderCache::doQuery/DatabaseBase::select
The search for the user has not found anything and that trigger a second query,
but now right without the subpage:
SELECT user_name,up_value FROM `user` LEFT JOIN `user_properties` ON ((user_id
= up_user) AND up_property = 'gender') WHERE user_name = 'User'
Callers:
MediaWiki::run/MediaWiki::main/MediaWiki::performRequest/SpecialPageFactory::executePath/SpecialContributions::execute/IndexPager::getBody/ContribsPager::doBatchLookups/LinkBatch::execute/LinkBatch::executeInto/LinkBatch::addResultToCache/LinkCache::addGoodLinkObjFromRow/Title::getPrefixedDBkey/Title::prefix/Title::getNsText/GenderCache::getGenderOf/GenderCache::doQuery/DatabaseBase::select
--
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 23215] Rename the als.*.org projects to gsw.*.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=23215 --- Comment #20 from Clemens Kienzle clemens.kien...@gmx.net 2012-02-11 21:05:42 UTC --- (In reply to comment #19) Just want to note that the request for the macrolanguage code aeg was rejected by SIL. (http://www.sil.org/iso639-3/chg_detail.asp?id=2011-180lang=aeg) Indeed, the reason being that no evidence was provided that swg, gsw, wae are treated as a single language in some contexts *sigh*. So now I guess I'm going to start compiling an exhaustive dialectological reference list and file another request, since dialectologists have been treating all these as a single language for something like the past 150 years or however long the field has been around, something that could have been easily verified even online by checking the site of the Alemannisches Institut (http://alemann.eva-server.de/cms/website.php?id=deralemannischeraum.htm) or this article by Renate Schrambke, one of the leading dialectologists in the field: http://www.alemannisch.de/unser_sprooch/Gliederung.htm -- 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 34341] New: Pls. can you add EtherpadLite Extension to the bugzilla option picker. Thanks
https://bugzilla.wikimedia.org/show_bug.cgi?id=34341 Web browser: --- Bug #: 34341 Summary: Pls. can you add EtherpadLite Extension to the bugzilla option picker. Thanks Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Bugzilla AssignedTo: mhershber...@wikimedia.org ReportedBy: m...@tgries.de CC: innocentkil...@gmail.com, s...@reedyboy.net Classification: Unclassified see subject http://www.mediawiki.org/wiki/Extension:EtherpadLite -- 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 34342] New: Create a new books namespace on he.wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=34342 Web browser: --- Bug #: 34342 Summary: Create a new books namespace on he.wiki Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: wiki.to...@gmail.com Classification: Unclassified Per community concensus here: http://he.wikipedia.org/wiki/%D7%95%D7%A7:%D7%9E#.D7.99.D7.A6.D7.99.D7.A8.D7.AA_.D7.9E.D7.A8.D7.97.D7.91_.22.D7.A1.D7.A4.D7.A8:.22_.D7.A2.D7.91.D7.95.D7.A8_.D7.A1.D7.A4.D7.A8.D7.99_.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94 Please create a new namespace namespace name: ספר namespace talk: שיחת ספר This namespace will be used to hold the PediaPress books just like the book: namespace on en.wiki Thanks -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 34342] Create a new books namespace on he.wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=34342 Bawolff bawolff...@gmail.com changed: What|Removed |Added Keywords||shell CC||bawolff...@gmail.com -- 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 1310] Recursive tags in extensions.
https://bugzilla.wikimedia.org/show_bug.cgi?id=1310 --- Comment #26 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2012-02-11 22:20:52 UTC --- That as a source fix sounds to me more like a hack to fix a non-issue to me. The source isn't written to explicitly do anything special with any source tags inside of it so that does not sound like the thing we should be aiming for. (And sounds like it would break if someone used source to document example arguments to the opening source tag) Switching over to a complete even tag matching could change the behaviour of existing content -- ie: foofoo/foo suddenly having different behaviour -- so I'd reject the patch we have on those grounds alone. We probably also want to write a test to make sure that nowikinowiki/nowiki doesn't suddenly start turning everything after it into nowiki content when it was written expecting it to display a nowiki tag verbatim in the page for documentation. I think that if we do implement recursive tags, it's going to have to be an explicit op-in by extensions feature. ie: Only tags with a specific option will be parsed recursively. We can enable it on ref but we may not want to enable it for source, and definitely don't want it on nowiki. -- 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 30284] Broken +index=x for records
https://bugzilla.wikimedia.org/show_bug.cgi?id=30284 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 22:25:20 UTC --- Thanks, Kazimierz, for your analysis and suggestions. I have fixed the issue in r111267 and r111268. You were mostly right about the cause of the problem, but the main issue was in method getNextDataValue() where the (type record) property was used to create a datavalue object for the selected record field. The code there now finds and uses the correct property for each subvalue, even though this is not very efficient. The comment about the Known limitation is in fact not relevant here. This limiation was always the same and only affects certain result printers (like timeline) that check the type of a printrequest to find out if a value can be used for a special purpose (in the case of timeline, a date-typed record field would not be accepted as a time to display, because the type says record). But this has always been the same. -- 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 34343] New: jQuery UI Button Icons do not display properly in Monobook (causing a new line in the button)
https://bugzilla.wikimedia.org/show_bug.cgi?id=34343
Web browser: ---
Bug #: 34343
Summary: jQuery UI Button Icons do not display properly in
Monobook (causing a new line in the button)
Product: MediaWiki
Version: 1.18.0
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: Unprioritized
Component: Javascript
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: rainerril...@hotmail.com
CC: krinklem...@gmail.com, tpars...@wikimedia.org
Classification: Unclassified
Created attachment 9989
-- https://bugzilla.wikimedia.org/attachment.cgi?id=9989
screenshot of the layoutbug +vector style-solution
MediaWiki 1.18wmf1 (r109351)
// generic
$selector.button({
icons: {
primary: ui-icon-locked
}
})
// Test the following on
//
https://www.mediawiki.org/w/index.php?title=MediaWiki_1.19useskin=monobook#footer
mw.loader.using('jquery.ui.button', function() {
$('button', { text: 'buttontext' }).button({
icons: {
primary: ui-icon-locked
}
}).appendTo('#bodyContent')
});
Should look like this:
http://jqueryui.com/demos/button/#icons
But looks ... (see attachment)
--
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 25807] Date properties sort incorrectly in a 'sortable' class table created via 'output=template'
https://bugzilla.wikimedia.org/show_bug.cgi?id=25807 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #6 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 22:42:02 UTC --- Anyway, something needs to be a *closed* duplicate here. No use having two open bugs for the same issue. I am now declaring this bug to be the duplicate of bug 25768. *** This bug has been marked as a duplicate of bug 25768 *** -- 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 25768] Date returned by query gets treated like string with respect to sorting in table
https://bugzilla.wikimedia.org/show_bug.cgi?id=25768 --- Comment #2 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 22:42:02 UTC --- *** Bug 25807 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 25768] Date returned by query gets treated like string with respect to sorting in table
https://bugzilla.wikimedia.org/show_bug.cgi?id=25768
Markus Krötzsch mar...@semantic-mediawiki.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||FIXED
Severity|critical|normal
--- Comment #3 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11
23:01:57 UTC ---
First, this bug is not critical. Mainly, the issue is a basic limitation of
the recipe at [1] and this recipe should warn about this. SMW takes special
precautions to avoid this problem in its own tables. By using a manually
created table, this special handling is eliminated.
The sortable table code of MediaWiki cannot handle dates. To make them sort
properly, one needs to provide numeric sortkeys using the data-sort-value
attribute in td elements (look at the HTML of any real SMW table for examples).
When manually creating tables, one is in charge of providing this information,
or one needs to use JavaScript that can handle dates natively (which is
difficult due to the complex format). To allow this to be done manually, I have
now (in r111269) added a new output format sortkey to Type:Date by which one
can obtain a numeric sortkey as needed for data-sort-value. For example, the
following query displays dates and their sortkeys:
{{#ask: [[Modification date::+]]
| ?Modification date
| ?Modification date#sortkey
}}
For properties that can have many values, only one sortkey must be used (since
the whole table row is sorted as one, even if many dates are in one cell). This
can be achieved by using +limit like so:
{{#ask: [[testdate::+]]
| ?testdate
| ?testdate#sortkey |+limit=1
}}
It would be nice if the recipe could be extended by all this information, and
ideally with a recipe for building the correct HTML code. This goes as far as
SMW can assist the manual creation of sortable tables, so I am closing this
bug.
[1]
http://smw.referata.com/wiki/Use_the_ask_template_format_to_create_tabular_output
--
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 1310] Recursive tags in extensions.
https://bugzilla.wikimedia.org/show_bug.cgi?id=1310 --- Comment #27 from Gabriel Wicke wi...@wikidev.net 2012-02-11 23:26:49 UTC --- I also share Daniel's concerns about changing the behavior of existing content. In the longer term, I think that it would be desirable to add a fully parsed input mode for extension tag contents. This could take the form of a token stream or a DOM fragment built from those. Extensions could choose between plain-text input and tokens, so this would be opt-in. This is also very close to how this is currently handled in the Parsoid parser (http://mediawiki.org/wiki/Parsoid), although there still are some issues to solve (e.g. an unclosed html comment in the extension content). Nested nowiki is covered by parser tests already, and works as expected. Are there extensions that need nested extension tags, but otherwise unparsed input? -- 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 32661] Datatype quantity does not recognize comma
https://bugzilla.wikimedia.org/show_bug.cgi?id=32661 Markus Krötzsch mar...@semantic-mediawiki.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #7 from Markus Krötzsch mar...@semantic-mediawiki.org 2012-02-11 23:37:21 UTC --- This sounds to me like an upgrade issue. In current SMW, the database should always use . in the database, whatever the surface language. The value is generated using PHP's strval() and recovered with floatval(); no localisation is involved. This is intentional and ensures that values are exchanged between PHP and SQL as simple and fast as possible, while more complex language-specific handling may come later (and only if needed). This also means that, unless PHP would for some reason localise the output of strval(), the smw_atts2 table should never contain a value in pretty printing (neither localised nor with thousands separators). Therefore, the fix suggested in Comment 4 is not required or desired in SMW, and the current behaviour is not a bug. My suggestion is to refresh all stored data using Special:SMWAdmin to make sure that outdated values are fixed. Besides stale data from earlier SMW versions, another possible reason for number-like values with localised decimal separators to appear in the database is that the datatype of the respective properties has been changed at some point (e.g., to String). The value will then be stored verbatim, but using the same table (however, without using the numerical value_num cell as reported above). When changing the type back to Number, such stored values cannot be interpreted properly. This is normal and to be expected (it is more obvious for other types, such as Date). SMW automatically triggers update jobs that should fix all affected database records after a while, but how fast this is depends on the wiki's job queue. SMW can only have one localisation setting for wiki text (just like MediaWiki), i.e., all pages should be in the same language. I am sorry that something got mixed up on your wiki, but as long as this cannot be reproduced anywhere else and analysis of code does not suggest any problem, I can only close this as worksforme. -- 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 33997] SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page
https://bugzilla.wikimedia.org/show_bug.cgi?id=33997 T. Gries m...@tgries.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from T. Gries m...@tgries.de 2012-02-11 23:47:06 UTC --- I tried your patch, this appears to work as expected and described. great. fixed in r111270 -- 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 33973] MediaWiki should follow redirects on css/js pages
https://bugzilla.wikimedia.org/show_bug.cgi?id=33973 Sam Reed (reedy) s...@reedyboy.net changed: What|Removed |Added Priority|Normal |Low -- 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 34342] Create a new books namespace on he.wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=34342 Sam Reed (reedy) s...@reedyboy.net 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 34344] New: provide more filter methods for special:contributions
https://bugzilla.wikimedia.org/show_bug.cgi?id=34344 Web browser: --- Bug #: 34344 Summary: provide more filter methods for special:contributions Product: MediaWiki Version: unspecified Platform: All URL: http://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvo rschläge#Benutzerbeiträge OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: a.d.be...@web.de Classification: Unclassified See also Bug 4597, Bug 33581 Really lots of users (see url) check their own contributions to see whether the pages they've edited were updated. They want to see a list of their contributions, no page duplicates (#33581) and the pages where their edit is still the recent one also hidden. There is already a set of userscripts (overview at [[de:BD:TMg/filterContributions.js]]) to filter the generated lists, but I think this should be a native feature of MediaWiki. It could be one additional checkbox, but I think there should be one checkbox to hide duplicate pages, and a select to switch between no filtering/only top contribs (#4597)/only non-recent ones. I know that the database query won't be easy to construct, but I think it would be OK not to show exactly 20/50/100/... contributions to have such a essential feature built into core. So the filtering could also be done in PHP, which should be quite easy. In future, a better SQL term still can be built. -- 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
