[Bug 32722] allow resolution of MyXXX pages to their respective redirect targets via the API
https://bugzilla.wikimedia.org/show_bug.cgi?id=32722 --- Comment #6 from billinghurst billinghu...@gmail.com 2012-09-24 06:48:58 UTC --- I am comfortable with the bulk of the responses about specialpagealiases being available and I believe that it will then need to be matched with subsidiary pages at [[mw:API:Meta]]. I had expected, though had been unable to find that information. I had hoped that there may have been the ability to get a simple list, however, a little digging through using that parameter will be necessary. Bryan, you mention that that the 4x SpecialMy are easily determinable, I don't find them so, and I think that was my initial reflection, and I would encourage the consideration of where they may become more evident. I have more recently seen that when you know for what you are looking that you can find bits through the api via [path]api.php?action=querymeta=allmessages The issue is that you need to know for what to search, so it is a little circular in approach. Again though this may be addressed by documentation at mw, it just isn't explicitly stated (from my looking). In lieu of that being available I will endeavour to get it into the Help pages at MW, and hopefully it will be updated as time passes. If it is WONTFIX so be it, if there are some thought bubbles for the future, that is great. Thanks to all for your work, and your efforts, I appreciate 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 28128] Consider whether {{PLURAL:}} should handle fractional numbers
https://bugzilla.wikimedia.org/show_bug.cgi?id=28128 Nemo_bis federicol...@tiscali.it changed: What|Removed |Added CC||federicol...@tiscali.it --- Comment #7 from Nemo_bis federicol...@tiscali.it 2012-09-24 07:07:31 UTC --- (In reply to comment #6) Since we switched to CLDR which *can* take fractions into account, I consider this fixed. It of course depends on the supplied rules for a language how it works. Does this mean that this sentence can be removed from [[mw:Localisation]]? «You should not expect PLURAL to handle fractional numbers (like 44.5), so it's probably a good idea to round the number to the nearest integer if PLURAL is necessary in the context (bugzilla:28128)». -- 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 40468] New: Rendering to PDF failure RuntimeError: command failed with returncode 9
https://bugzilla.wikimedia.org/show_bug.cgi?id=40468 Web browser: --- Bug #: 40468 Summary: Rendering to PDF failure RuntimeError: command failed with returncode 9 Product: MediaWiki extensions Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Collection AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mwal...@wikimedia.org CC: developm...@pediapress.com Classification: Unclassified Mobile Platform: --- Attempted to run a collection to PDF job with the following URL: http://en.wikipedia.org/w/index.php?title=Special:Bookbookcmd=renderingreturn_to=Book%3AGuide+to+the+Constellationscollection_id=a16ec1f0c6cc071ewriter=rl It failed with the following: An error occurred on the render server: RuntimeError: command failed with returncode 9: ['mw-render', '-w', 'rl', '-c', 'cache/a1/a16ec1f0c6cc071e/collection.zip', '-o', 'cache/a1/a16ec1f0c6cc071e/output.rl', '--status', 'qserve://localhost:14311/a16ec1f0c6cc071e:render-rl', '--template-blacklist', 'MediaWiki:PDF Template Blacklist', '--template-exclusion-category', 'Exclude in print', '--print-template-prefix', 'Print', '--print-template-pattern', '$1/Print', '--language', 'en'] Last Output: 64% rendering 84.4260240964% rendering 84.4607228916% rendering 84.4665060241% rendering 84.5012048193% rendering 84.5359036145% rendering 84.6168674699% rendering 84.6631325301% rendering 84.6631325301%... ...88.9831325301% rendering in function system, file /home/pp/local/bin/nslave.py, line 64 I attempted another collection render run immediately after which did successfully render. http://en.wikipedia.org/w/index.php?title=Special:Bookbookcmd=renderingreturn_to=Book%3ASpace+Shuttlecollection_id=4accde1caa0f0035writer=rl -- 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 40469] New: adding automatically the sub-pages as new watchlist
https://bugzilla.wikimedia.org/show_bug.cgi?id=40469 Web browser: --- Bug #: 40469 Summary: adding automatically the sub-pages as new watchlist Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Watchlist AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: reza.ene...@gmail.com Classification: Unclassified Mobile Platform: --- In many cases we need that specific page's new sub-pages will added automatically to watchist for example in http://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval new requests will be added to sub-page and it is not possible to watch them -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40470] New: move page will make watchlist useless
https://bugzilla.wikimedia.org/show_bug.cgi?id=40470 Web browser: --- Bug #: 40470 Summary: move page will make watchlist useless Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Watchlist AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: reza.ene...@gmail.com Classification: Unclassified Mobile Platform: --- After moving page that was in user's watchlist Mediawiki doesn't recognize the target page as watchlist and it can be used as Vandalism In my opinion it should be as option for users who wants to flow specific page -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40186] Change logo/favicon for Es.Wikt (Es.Wt) and change the name of the flags 'Autopatrullero' and 'Patrullero' to 'Autoverificado' and 'Verificador'
https://bugzilla.wikimedia.org/show_bug.cgi?id=40186 Dereckson dereck...@espace-win.org changed: What|Removed |Added Keywords|shellpolicy |shell --- Comment #29 from Dereckson dereck...@espace-win.org 2012-09-24 08:16:54 UTC --- Thank you for the clarification. I'm going to prepare the new change. [ shellpolicy - shell ] -- 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 40186] Change logo/favicon for Es.Wikt (Es.Wt) and change the name of the flags 'Autopatrullero' and 'Patrullero' to 'Autoverificado' and 'Verificador'
https://bugzilla.wikimedia.org/show_bug.cgi?id=40186 --- Comment #30 from Dereckson dereck...@espace-win.org 2012-09-24 08:23:29 UTC --- Gerrit change #23610 now configures http://bits.wikimedia.org/favicon/piece.ico as favicon. -- 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 40465] Powered by Mediawiki and a Wikimedia project buttons and targets should be localizable
https://bugzilla.wikimedia.org/show_bug.cgi?id=40465 Dereckson dereck...@espace-win.org changed: What|Removed |Added Keywords||design, i18n Priority|Unprioritized |Low CC||dereck...@espace-win.org, ||s.mazel...@xs4all.nl Severity|normal |minor --- Comment #1 from Dereckson dereck...@espace-win.org 2012-09-24 08:30:33 UTC --- [ Priority/severity : low/minor. +i18n design keywords. ] We first should provide to achieve this a framework to create new buttons. If a designer could provide the buttons without text and the font instruction, I could prepare an ImageMagick script to generate localized ones. Then we need to create on translatewiki a project for this specific translation and see how to implement the localization. -- 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 40471] New: I have installed and am running on MySQL and get the fatal error going to the main index.php page
https://bugzilla.wikimedia.org/show_bug.cgi?id=40471
Web browser: ---
Bug #: 40471
Summary: I have installed and am running on MySQL and get the
fatal error going to the main index.php page
Product: MediaWiki
Version: 1.19.2
Platform: PC
OS/Version: Windows Server 2008
Status: UNCONFIRMED
Severity: blocker
Priority: Unprioritized
Component: Database
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: jbmetr...@yahoo.com
Classification: Unclassified
Mobile Platform: ---
Fatal error: Call to undefined function mysql_error() in
C:\inetpub\wwwroot\wiki\includes\db\DatabaseMysql.php on line 305
This is the code in the file (which comes from a plain vanilla install) with
the arrow pointing to the line the error refers to:
function lastError() {
if ( $this-mConn ) {
# Even if it's non-zero, it can still be invalid
wfSuppressWarnings();
$error = mysql_error( $this-mConn );
if ( !$error ) {
$error = mysql_error();
}
wfRestoreWarnings();
} else {
===$error = mysql_error();
}
if( $error ) {
$error .= ' (' . $this-mServer . ')';
}
return $error;
}
--
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 40471] I have installed and am running on MySQL and get the fatal error going to the main index.php page
https://bugzilla.wikimedia.org/show_bug.cgi?id=40471 Marcin Cieślak marcin.cies...@gmail.com changed: What|Removed |Added CC||marcin.cies...@gmail.com --- Comment #1 from Marcin Cieślak marcin.cies...@gmail.com 2012-09-24 08:35:49 UTC --- What does your http://your-wiki/path/mw-config/ say? -- 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 38829] When dialog to insert an image is invoked on a selection, prefill the fields accordingly
https://bugzilla.wikimedia.org/show_bug.cgi?id=38829 --- Comment #1 from Michael M. listenle...@gmail.com 2012-09-24 08:36:42 UTC --- Created attachment 11138 -- https://bugzilla.wikimedia.org/attachment.cgi?id=11138 JavaScript snippet The attached file contains a function that takes a string as argument and returns either false if it wasn't able to parse it, or an object with the following members: pre - whitespace before the image post - whitespace after fileName - normalized name of the file (without namespace) caption - caption (if present) fileSize - size without px (if present) fileFloat - English keyword for the float parameter (if present) fileFormat - English keyword for the format parameter (if present) Whoever is going to fix this bug only has to integrate this function into the code, i.e. call it when the dialog is opened with the selected text and set the inputs and selects to the returned values. -- 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 38972] Rethink shared table configuration setup for synching repo and client (8)
https://bugzilla.wikimedia.org/show_bug.cgi?id=38972 Daniel Kinzler daniel.kinz...@wikimedia.de changed: What|Removed |Added Priority|Highest |Normal Status|ASSIGNED|NEW Severity|critical|normal --- Comment #5 from Daniel Kinzler daniel.kinz...@wikimedia.de 2012-09-24 08:59:05 UTC --- lowering prio and unassignig. this is not critical and should be discussed again before being picked up again. -- 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 37882] Fatal error, undefined method HistoryBlobStub::uncompress() when running update.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=37882 Marcin Cieślak marcin.cies...@gmail.com changed: What|Removed |Added CC||marcin.cies...@gmail.com --- Comment #2 from Marcin Cieślak marcin.cies...@gmail.com 2012-09-24 09:06:44 UTC --- Can you drop example of the serialized data? (a database dump or something like that) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40240] view source on Main_Page should be an edit to the sandbox
https://bugzilla.wikimedia.org/show_bug.cgi?id=40240 --- Comment #4 from Antoine hashar Musso has...@free.fr 2012-09-24 09:13:04 UTC --- (In reply to comment #3) Yeah, that would seem hella confusing to get sent to some other page. Indeed, maybe the link can send them instead to a page dedicated to welcoming newcomers ? Kind of like the UploadWizard has a basic tutorial picture. Also, do people really spend time on the main page? I'd think most readers are coming in at articles... Hard to say without click tracking, but the enwiki Main_Page definitely has a lot of traffic. According to http://stats.grok.se/en/top it received 15Millions views so far in September. -- 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 40186] Change logo/favicon for Es.Wikt (Es.Wt) and change the name of the flags 'Autopatrullero' and 'Patrullero' to 'Autoverificado' and 'Verificador'
https://bugzilla.wikimedia.org/show_bug.cgi?id=40186 --- Comment #31 from Antoine hashar Musso has...@free.fr 2012-09-24 09:20:40 UTC --- (In reply to comment #30) Gerrit change #23610 now configures http://bits.wikimedia.org/favicon/piece.ico as favicon. Deployed on live site. Thanks Dereckson :-] -- 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 40436] Add WP as alias on sewiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=40436 Antoine hashar Musso has...@free.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||has...@free.fr Resolution||FIXED --- Comment #4 from Antoine hashar Musso has...@free.fr 2012-09-24 09:29:20 UTC --- I have deployed the change on live site. There was 4 conflicts in the database hence: [[WP:Gáffestohpu]] has been renamed to [[Wikipedia:Gáffestohpubroken]] [[Geavaheaddji:Gálaniitoluodda]] has been renamed to [[Geavaheaddji:Gálaniitoluoddabroken]]. [[Wikipedia:Gáffestohpu]] has been renamed to [[Wikipedia:Gáffestohpu/broken]] [[Veahkki:Sisdoallu]] has been renamed to [[Veahkki:Sisdoallu/broken]] You will want to look at all those articles and find out which version is the correct one :-) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40419] extension assets not available on bits.beta.wmflabs.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=40419 Antoine hashar Musso has...@free.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Antoine hashar Musso has...@free.fr 2012-09-24 09:37:43 UTC --- I have deployed the change. Extension assets are now available \O/ -- 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 40468] Rendering to PDF failure RuntimeError: command failed with returncode 9
https://bugzilla.wikimedia.org/show_bug.cgi?id=40468 Volker Haas volker.h...@pediapress.com changed: What|Removed |Added CC||volker.h...@pediapress.com --- Comment #1 from Volker Haas volker.h...@pediapress.com 2012-09-24 09:38:45 UTC --- The problem is caused by the size (and content) of the book. The rendering software uses ~1.5GBytes of memory and needs around 15 minutes to render the collection (on my desktop computer which is probably faster than the render servers). - The rendering process is killed. The only solution I can currently offer is to split the collection into at least two parts. -- 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 39366] Use of edit token in ApiModifyItem
https://bugzilla.wikimedia.org/show_bug.cgi?id=39366 --- Comment #2 from jeb...@gmail.com 2012-09-24 09:42:51 UTC --- Change I7cee30ea: Kill use of gettoken -- 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 40462] Category sorting broken on pt.wikipedia.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=40462 --- Comment #3 from Siebrand s.mazel...@xs4all.nl 2012-09-24 09:45:14 UTC --- @todo FIXME: Needs unit tests -- 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 39366] Use of edit token in ApiModifyItem
https://bugzilla.wikimedia.org/show_bug.cgi?id=39366 --- Comment #3 from jeb...@gmail.com 2012-09-24 09:45:23 UTC --- When I tried to change the tests into using the edittoken (the UI already does that) I got a lot of failures and they seems to emerge from a session failure. There are some print statements in there that needs to be removed when the patchset works. -- 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 40138] Remove Bugzilla and migrate to a wiki (with perhaps a bug-tracking extension) for bug-tracking
https://bugzilla.wikimedia.org/show_bug.cgi?id=40138 --- Comment #11 from Rainer Rillke @commons.wikimedia rainerril...@hotmail.com 2012-09-24 09:53:32 UTC --- https://commons.wikimedia.org/w/index.php?title=Commons%3AHelp_deskdiff=78974710oldid=78971117 Unfortunatly, I have never used bugzilla earlier. I tried and failed. It requires great efforts from my side with translation and merely understanding, so I doubt in the success of my future attempts. =[ Maybe, someone else will report? -- 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 40472] New: MediaWiki:Mwe-upwiz-license-custom gets wrong $2 passed OR Link to custom copyright tag select invalid due to deed appended to URL
https://bugzilla.wikimedia.org/show_bug.cgi?id=40472 Web browser: --- Bug #: 40472 Summary: MediaWiki:Mwe-upwiz-license-custom gets wrong $2 passed OR Link to custom copyright tag select invalid due to deed appended to URL Product: MediaWiki extensions Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: UploadWizard AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: rainerril...@hotmail.com CC: mtrac...@member.fsf.org Classification: Unclassified Mobile Platform: --- Tested for uselang=fr ru and de Steps to reproduce: * https://commons.wikimedia.org/wiki/Special:UploadWizard?uselang=de * Upload dummy file * Proceed * Select Diese Datei ist nicht meine eigene Arbeit. (The file is not my own work) * Click Ein weiterer, nicht oben erwähnter Grund. (Further reason) * The word Lizenzangabe (copyright tag) links to the wrong page (https://commons.wikimedia.org/wiki/Commons:Lizenzvorlagendeed.de -- we got even spam on that page!) (it would link to the right page if deed.de wouldn't be appended) Expected result: * Valid link to https://commons.wikimedia.org/wiki/Commons:Lizenzvorlagen -- 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 40462] Category sorting broken on pt.wikipedia.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=40462 mybugs.m...@gmail.com changed: What|Removed |Added Keywords||need-unittest -- 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 40472] MediaWiki:Mwe-upwiz-license-custom gets wrong $2 passed OR Link to custom copyright tag select invalid due to deed appended to URL
https://bugzilla.wikimedia.org/show_bug.cgi?id=40472 --- Comment #1 from Rainer Rillke @commons.wikimedia rainerril...@hotmail.com 2012-09-24 10:13:59 UTC --- BTW, this seems to happen while parsing; UploadWizardConfig.licenses.custom.msg looks Ok -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 39866] Add Anexos to content namespaces on Spanish Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=39866 --- Comment #15 from Antoine hashar Musso has...@free.fr 2012-09-24 10:15:38 UTC --- (In reply to comment #13) A maintenance script has still to run to update es.wikipedia statistics count. I guess it's maintenance/updateArticleCount.php So that script is going to take an awful long time to run. I have sent a mail to Asher (DBA / performance engineer) about it and find out if it is safe to run it. The sequence should be: # Get current statistics mwscript showStats.php --wiki=eswiki # Update article count: mwscript updateArticleCount.php --wiki=eswiki --update # Get new statistics mwscript showStats.php --wiki=eswiki -- 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 40473] New: Lohit Punjabi font problems
https://bugzilla.wikimedia.org/show_bug.cgi?id=40473 Web browser: --- Bug #: 40473 Summary: Lohit Punjabi font problems Product: MediaWiki extensions Version: unspecified Platform: All OS/Version: All Status: UNCONFIRMED Severity: normal Priority: Unprioritized Component: WebFonts AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: zariek...@hotmail.co.uk CC: asha...@wikimedia.org, s.mazel...@xs4all.nl, santhosh.thottin...@gmail.com, srik@gmail.com Classification: Unclassified Mobile Platform: --- Created attachment 11139 -- https://bugzilla.wikimedia.org/attachment.cgi?id=11139 A screenshot of the article about the year 1999 in the Punjabi wikipedia, the overlaping digits are clearly visable and the crooked letters are also shown. The Lohit Punjabi font is the default font on the Gurmukhi Punjabi Wikipedia and it had many problems and bugs that make it difficult for readers. The Gurmukhi digit 9 (੯) always seems to overlap with the letter/number next to it. The font also does not join the letters properly making it look crooked and untidy. -- 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 40462] Category sorting broken on pt.wikipedia.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=40462 Nemo_bis federicol...@tiscali.it changed: What|Removed |Added Keywords||i18n CC||federicol...@tiscali.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 40468] Rendering to PDF failure RuntimeError: command failed with returncode 9
https://bugzilla.wikimedia.org/show_bug.cgi?id=40468 rupesh rupeshbe...@gmail.com changed: What|Removed |Added CC||rupeshbe...@gmail.com --- Comment #2 from rupesh rupeshbe...@gmail.com 2012-09-24 11:16:42 UTC --- That worked fine.. 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 37601] Tests introduced in tests/phpunit/includes/db/TestORMRowTest.php fail on PostgreSQL
https://bugzilla.wikimedia.org/show_bug.cgi?id=37601 Jeroen De Dauw jeroen_ded...@yahoo.com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|wikibugs-l@lists.wikimedia. |jeroen_ded...@yahoo.com |org | --- Comment #3 from Jeroen De Dauw jeroen_ded...@yahoo.com 2012-09-24 11:18:57 UTC --- Marcin: thanks for pointing this out Aaron: the ORMTable/Row code is not using safeQuery. I can in fact not find the method, so am guessing it got killed? Tim Landscheidt: thanks for the patch. Will also try to look at the blob issue soonish. -- 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 40474] New: Set Transwiki namespace on Chinese wikimedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=40474 Web browser: --- Bug #: 40474 Summary: Set Transwiki namespace on Chinese wikimedia Product: Wikimedia Version: wmf-deployment Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Site configuration AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: shiz...@gmail.com CC: benap...@gmail.com, wikimedia.b...@snowolf.eu Classification: Unclassified Mobile Platform: --- Plese Set Transwiki namespace on Chinese wiktionary, Chinese wikibooks, Chinese wikiquote, Chinese wikisource. And set wgImportTargetNamespace='Transwiki' see https://meta.wikimedia.org/wiki/Requests_for_comment/Transwiki_on_zh_wikimedia -- 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 40474] Set Transwiki namespace on Chinese wikimedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=40474 shi zhao shiz...@gmail.com changed: What|Removed |Added Keywords||shell URL||https://meta.wikimedia.org/ ||wiki/Requests_for_comment/T ||ranswiki_on_zh_wikimedia See Also||https://bugzilla.wikimedia. ||org/show_bug.cgi?id=25181 -- 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 40475] New: wfTimestamp is deprecated
https://bugzilla.wikimedia.org/show_bug.cgi?id=40475 Web browser: --- Bug #: 40475 Summary: wfTimestamp is deprecated Product: MediaWiki extensions Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: WikidataRepo AssignedTo: wikidata-b...@lists.wikimedia.org ReportedBy: jeb...@gmail.com CC: wikidata-b...@lists.wikimedia.org Classification: Unclassified Mobile Platform: --- The function is used a few places, should be replaced by direct use of the MWTiestamp class I guess... -- 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 40344] Bugzilla auto-linking mangling Gerrit URL
https://bugzilla.wikimedia.org/show_bug.cgi?id=40344 MZMcBride b...@mzmcbride.com changed: What|Removed |Added CC||a9016...@gmx.de, ||krinklem...@gmail.com, ||suma...@wikimedia.org --- Comment #2 from MZMcBride b...@mzmcbride.com 2012-09-24 13:04:52 UTC --- (In reply to comment #1) I've noticed this as well and it is most annoying! I wonder if the latest Bugzilla upgrade fixes this? I doubt it has anything to do with Bugzilla directly. Wikimedia has a Bugzilla extension that performs a few auto-linking regexen on Bugzilla comments. I imagine this particular regex just needs a tweak. -- 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 40476] New: Add a type marker to the entity output by the API
https://bugzilla.wikimedia.org/show_bug.cgi?id=40476 Web browser: --- Bug #: 40476 Summary: Add a type marker to the entity output by the API Product: MediaWiki extensions Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: WikidataRepo AssignedTo: wikidata-b...@lists.wikimedia.org ReportedBy: jeb...@gmail.com CC: wikidata-b...@lists.wikimedia.org Classification: Unclassified Mobile Platform: --- After the change from using item and items into entity and entities it is necessary to specify the individual types of entities in the output from the API. Preferably with a key-value -pair type. In some cases it could be valid to only output this type marker if the EntityContent is fetched from the page, or if it is available through some other means. -- 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 40476] Add a type marker to the entity output by the API
https://bugzilla.wikimedia.org/show_bug.cgi?id=40476 jeb...@gmail.com 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 on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40195] ArticleFeedbackv5 generating bad recent changes entries
https://bugzilla.wikimedia.org/show_bug.cgi?id=40195
--- Comment #20 from Matthias Mullie mmul...@wikimedia.org 2012-09-24
14:17:04 UTC ---
Just looked at the data in the db and it's just fine in there:
mysql SELECT log_params FROM logging WHERE log_id = 44672742;
+-+
| log_params |
+-+
| a:2:{s:10:feedbackId;i:254606;s:6:pageId;i:102952;} |
+-+
1 row in set (0.00 sec)
Still some cache persisting, apparently.
--
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 40422] Review and deploy FormatNum extension
https://bugzilla.wikimedia.org/show_bug.cgi?id=40422 Sumana Harihareswara suma...@wikimedia.org changed: What|Removed |Added CC||suma...@wikimedia.org --- Comment #2 from Sumana Harihareswara suma...@wikimedia.org 2012-09-24 14:26:19 UTC --- The procedure at https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment says that, since FormatNum is a user-facing feature, it needs a design review https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment . Can Dereckson or DaSch start getting that design review? 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 40422] Review and deploy FormatNum extension
https://bugzilla.wikimedia.org/show_bug.cgi?id=40422
Platonides platoni...@gmail.com changed:
What|Removed |Added
CC||platoni...@gmail.com
--- Comment #3 from Platonides platoni...@gmail.com 2012-09-24 14:38:17 UTC
---
Why did slwiki and fawiki request it? Doesn't the core {{formatnum: }} work for
them? (yes, there's a name clash, quite bad for the proposed extension)
If the number format configured for their language is wrong, it should be fixed
in the language files, not workarounded with an extension.
--
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 40476] Add a type marker to the entity output by the API
https://bugzilla.wikimedia.org/show_bug.cgi?id=40476 --- Comment #1 from jeb...@gmail.com 2012-09-24 14:41:54 UTC --- https://gerrit.wikimedia.org/r/#/c/24808/ -- 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 40471] I have installed and am running on MySQL and get the fatal error going to the main index.php page
https://bugzilla.wikimedia.org/show_bug.cgi?id=40471 Krenair kren...@gmail.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kren...@gmail.com Resolution||INVALID --- Comment #2 from Krenair kren...@gmail.com 2012-09-24 14:44:20 UTC --- The MySQL module for PHP is not loaded. On windows I think this is php_mysql.dll. -- 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 40477] New: Enable Extension:Education Program on English Wikipedia (with new user rights configuration)
https://bugzilla.wikimedia.org/show_bug.cgi?id=40477 Web browser: --- Bug #: 40477 Summary: Enable Extension:Education Program on English Wikipedia (with new user rights configuration) Product: Wikimedia Version: wmf-deployment Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Extension setup AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: rages...@gmail.com Classification: Unclassified Mobile Platform: --- Per the result of the related RfC, please enable the Education Program extension on English Wikipedia. http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Education_Program_extension The user rights should be configured somewhat differently from the version currently deployed at test2. Per the RfC, it should user the following usergroups and associated rights: Course coordinators (ep-coordinator usergroup) Trusted editors who are given full access to the education program extension. They can create and delete course pages and institution pages, assign the ep-instructor right to users leading courses, assign the ep-campus and ep-online rights for users who are assisting the course (respectively) in-person or online, and remove a reviewer or student from a course. Administrators have access to all the rights of the ep-coordinator usergroup, and can grant the right to trusted editors according to community-determined criteria. Campus volunteers (ep-campus usergroup) Users who are working with courses in person to help instructors and/or students learn to contribute to Wikipedia. Users in the ep-campus usergroup may edit course pages and institution pages and may sign up on a course page to be a campus volunteer for a course. Admins and course coordinators should grant the campus volunteer right to Campus Ambassadors working with Wikipedia Education Program courses as well as editors in good standing who wish to volunteer in person helping other courses. Online volunteers (ep-online usergroup) Users who volunteer to help specific courses on-wiki. Users in the ep-online usergroup may edit course pages and institution pages and may sign up on a course page to be an online volunteer for a course. Course instructors (ep-instructor usergroup) Users who are running Wikipedia assignments and other organized editing events using the course pages through the Education Program extension. This includes, but is not limited to, instructors who are participating in the [[WP:WEP|Wikipedia Education Program]]. Users in the ep-instructor usergroup may create and edit course pages and institution pages and may sign up as an instructor for a course. They also may remove a student from a course they instruct. Admins and course coordinators should grant the course instructor right to everyone who seems to be leading a legitimate course. -- 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 40478] New: AbuseFilter needs regression tests
https://bugzilla.wikimedia.org/show_bug.cgi?id=40478 Web browser: --- Bug #: 40478 Summary: AbuseFilter needs regression tests Product: MediaWiki extensions Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: AbuseFilter AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: t...@tim-landscheidt.de CC: agarr...@wikimedia.org Classification: Unclassified Mobile Platform: --- There are no unit tests in AbuseFilter at the moment. Even phpTest.php has to be called manually. There should be a test suite that simulates common uses. -- 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 40477] Enable Extension:Education Program on English Wikipedia (with new user rights configuration)
https://bugzilla.wikimedia.org/show_bug.cgi?id=40477 --- Comment #1 from Sage Ross rages...@gmail.com 2012-09-24 15:01:04 UTC --- See Jeroen De Dauw, the developer of the extension, about the configuration modifications. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 35944] App should have larger font size settings
https://bugzilla.wikimedia.org/show_bug.cgi?id=35944 Jon jrob...@wikimedia.org changed: What|Removed |Added Priority|Normal |High --- Comment #3 from Jon jrob...@wikimedia.org 2012-09-24 15:05:46 UTC --- More feedback: For those of us above a certain age, even the large font size is VERY hard to read using the app on a nexus. Could this feature be a little more flexible please? -- 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 37705] Render interlanguage links in SkinTemplate.php sidebar ucfirst per context language rules
https://bugzilla.wikimedia.org/show_bug.cgi?id=37705 David Levy lifeisunf...@gmail.com changed: What|Removed |Added CC||lifeisunf...@gmail.com --- Comment #23 from David Levy lifeisunf...@gmail.com 2012-09-24 15:09:35 UTC --- Is the problem with the norsk (nynorsk) and norsk (bokmål) links (related to the use of the LRE mark as the first character) being worked on? -- 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 32311] activating Extension:FormatNum in fa.wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=32311
Dereckson dereck...@espace-win.org changed:
What|Removed |Added
Keywords|patch-need-review |
CC||dereck...@espace-win.org
See Also||https://bugzilla.wikimedia.
||org/show_bug.cgi?id=35753
--- Comment #7 from Dereckson dereck...@espace-win.org 2012-09-24 15:12:05
UTC ---
Platonides said in Bug #40422 comment #3:
Why did slwiki and fawiki request it? Doesn't the core {{formatnum: }} work
for
them? (yes, there's a name clash, quite bad for the proposed extension)
If the number format configured for their language is wrong, it should be
fixed
in the language files, not workarounded with an extension.
It would be nice to indicate if (i) your need is covered by bug 37573 (ii) we
would need to do other stuff in our core FORMATNUM (iii) you really the need
FormatNum extension.
--
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 40422] Review and deploy FormatNum extension
https://bugzilla.wikimedia.org/show_bug.cgi?id=40422 --- Comment #4 from Dereckson dereck...@espace-win.org 2012-09-24 15:15:12 UTC --- I don't know for fa., so I asked them recopying your question in this bug. For sl., it's because they want to be able to format number with comma as thousand separator. Note there could be other side reasons, as the bug 40186 description says: Unlike English, our language uses commas as decimal mark, which is the main reason we need the extension. -- 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 39866] Add Anexos to content namespaces on Spanish Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=39866 --- Comment #16 from Dereckson dereck...@espace-win.org 2012-09-24 15:17:17 UTC --- I've an alternative suggestion to avoid to count pages the number is already known. (1) Count the pages in references namespace (2) Add this number to the current count Whether manually, whether under the form of a script. -- 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 40431] Centralised feedback page not visible.
https://bugzilla.wikimedia.org/show_bug.cgi?id=40431 --- Comment #6 from Matthias Mullie mmul...@wikimedia.org 2012-09-24 15:18:06 UTC --- Apparently this is caused if you tick the turn off the AFT5 widget preference. Indeed (which is silly. Not wanting to see the widget != not wanting to triage feedback) Makes sense, change pushed to Gerrit (https://gerrit.wikimedia.org/r/#/c/24811/) prototype Can we not just implement this in PHP? As much as possible has been moved to JS because of possible cache issues related to doing it in PHP Note: this is probably not related to the issue reported, but IE8 reports a NON-FATAL javascript error for 'easyblock' from the feedback page: This appears to be some user script -- 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 40186] Change logo/favicon for Es.Wikt (Es.Wt) and change the name of the flags 'Autopatrullero' and 'Patrullero' to 'Autoverificado' and 'Verificador'
https://bugzilla.wikimedia.org/show_bug.cgi?id=40186 Dereckson dereck...@espace-win.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #32 from Dereckson dereck...@espace-win.org 2012-09-24 15:19:16 UTC --- Every configuration task from this bug is now done. -- 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 40138] Remove Bugzilla and migrate to a wiki (with perhaps a bug-tracking extension) for bug-tracking
https://bugzilla.wikimedia.org/show_bug.cgi?id=40138 --- Comment #12 from Dereckson dereck...@espace-win.org 2012-09-24 15:20:57 UTC --- Thank you to have reported it yourself in bug 40472. -- 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 39803] Talkpage link not appearing
https://bugzilla.wikimedia.org/show_bug.cgi?id=39803 --- Comment #4 from Matthias Mullie mmul...@wikimedia.org 2012-09-24 15:27:25 UTC --- I am seeing the talk page link on http://en.wikipedia.org/wiki/Washington,_D.C. I'm assuming it was a cache issue, unless you are still not seeing 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 39803] Talkpage link not appearing
https://bugzilla.wikimedia.org/show_bug.cgi?id=39803 --- Comment #5 from Matthias Mullie mmul...@wikimedia.org 2012-09-24 15:28:23 UTC --- (Also: if AFT is disabled in preferences, this link is not being displayed) -- 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 39803] Talkpage link not appearing
https://bugzilla.wikimedia.org/show_bug.cgi?id=39803 --- Comment #6 from Oliver Keyes oke...@wikimedia.org 2012-09-24 15:36:54 UTC --- Ahh. I'd suggest we display the talkpage link even if the form is disabled. -- 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 40464] Placeholder attribute of search box is not set until load
https://bugzilla.wikimedia.org/show_bug.cgi?id=40464 Krinkle krinklem...@gmail.com changed: What|Removed |Added Keywords||easy Priority|Unprioritized |Low Target Milestone|--- |1.20.0 release Severity|normal |minor -- 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 39410] Featuring oversight-requested posts
https://bugzilla.wikimedia.org/show_bug.cgi?id=39410 --- Comment #2 from Matthias Mullie mmul...@wikimedia.org 2012-09-24 16:03:36 UTC --- Taking the first one as example (http://en.wikipedia.org/wiki/Special:ArticleFeedbackv5/Higgs_boson/150728), the reason appears to be the large amount of helpful votes (106-23=83), which means +83 on relevance score, making the score unusually high. This keeps it at the top of the relevance-score based filter (which is the one anon users see by default) which makes it even more likely for users to mark it as helpful, ... You get the picture. Maybe we should only display feedback within the last month for the relevant filter (not yet sure how I'll implement this once sharded though, so other ideas are welcome as well) Or we make sure that only a certain amount of positive actions count to the relevance score, a number that it just a bit under the negative score that hiding/resolving packs? Also: it might help to have marking something as resolved also automatically unfeature the feedback post if it was previously featured (because it now keeps the 50 points it received upon featuring) Had this been done, the feedback had probably never been up there for so long and it wouldn't have had the chance to run away from other articles. -- 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 39587] Resolved - an exclusion filter or different weighting?
https://bugzilla.wikimedia.org/show_bug.cgi?id=39587 --- Comment #6 from Matthias Mullie mmul...@wikimedia.org 2012-09-24 16:04:49 UTC --- Taking the first one as example (http://en.wikipedia.org/wiki/Special:ArticleFeedbackv5/Higgs_boson/150728), the reason appears to be the large amount of helpful votes (106-23=83), which means +83 on relevance score, making the score unusually high. This keeps it at the top of the relevance-score based filter (which is the one anon users see by default) which makes it even more likely for users to mark it as helpful, ... You get the picture. Maybe we should only display feedback within the last month for the relevant filter (not yet sure how I'll implement this once sharded though, so other ideas are welcome as well) Or we make sure that only a certain amount of positive actions count to the relevance score, a number that it just a bit under the negative score that hiding/resolving packs? Also: it might help to have marking something as resolved also automatically unfeature the feedback post if it was previously featured (because it now keeps the 50 points it received upon featuring) Had this been done, the feedback had probably never been up there for so long and it wouldn't have had the chance to run away from other articles. -- 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 39410] Featuring oversight-requested posts
https://bugzilla.wikimedia.org/show_bug.cgi?id=39410 --- Comment #3 from Matthias Mullie mmul...@wikimedia.org 2012-09-24 16:05:19 UTC --- Above comment is in wrong thread - belongs here: https://bugzilla.wikimedia.org/show_bug.cgi?id=39587 -- 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 40222] Corrected logo for Sanskrit Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=40222 --- Comment #11 from hemantbugzi...@gmail.com 2012-09-24 16:09:51 UTC --- All right. I've left msgs here: http://commons.wikimedia.org/wiki/Commons_talk:Auto-protected_files/global/logos and here:http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Blocks_and_protections#Please_update_this_image . Let's see. -- 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 39803] Talkpage link not appearing
https://bugzilla.wikimedia.org/show_bug.cgi?id=39803 --- Comment #7 from Matthias Mullie mmul...@wikimedia.org 2012-09-24 16:10:16 UTC --- Ok, up on Gerrit (https://gerrit.wikimedia.org/r/#/c/24811/) prototype -- 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 37106] Article revisions should display the article title at the time of the revision
https://bugzilla.wikimedia.org/show_bug.cgi?id=37106 --- Comment #2 from johnnymrni...@gmail.com 2012-09-24 16:10:31 UTC --- All versions that I know of, see the history of any WP article that has been moved. For example, this article was moved from Sorcerer (computer game) to Sorcerer (video game), but the old diffs do not mention that. http://en.wikipedia.org/w/index.php?title=Sorcerer_%28video_game%29oldid=212542060 -- 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 40255] Ask additional copyright questions of users claiming own work
https://bugzilla.wikimedia.org/show_bug.cgi?id=40255 --- Comment #2 from Rd232 rd...@hotmail.com 2012-09-24 16:15:24 UTC --- I appreciate this is not an easy request to fulfil, so allow me to add an easy way to slightly improve matters: point people to https://commons.wikimedia.org/wiki/Commons:Own_work on the relevant UploadWizard page, with an appropriate are you sure it's 'own work'? people often misunderstand the concept, please read this page. Could even be a checkbox for yes I've read Commons:Own work. NB I appreciate Commons:own work is currently a crappy draft, but that's fairly easily and quickly fixed: just give a few days' warning at COM:VP that the UploadWizard will soon reference it and I'm sure it'll be up to scratch. And frankly even that crappy draft is better than allowing people to just rely on their own (often mistaken) assumptions without any hint that those assumptions may be wrong. -- 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 40329] Block elements inside elements with align= should use margin:auto; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #19 from TMg mr.h...@gmx.de 2012-09-24 16:24:22 UTC --- (In reply to comment #18) two users on different browsers may see two different things What are you talking about? This is not true. In the previous Wikipedia setup with HTML5 disabled all users got the same HTML output and it looked the same in all web browsers. Now this is broken. It does *not* look the same when a template is tested locally for example. The hack creates a *different* result when the finished code is finally put into a template. The hack *changes* the *meaning* of the code no matter if these attributes were used for a reason or not. This is confusing as hell. It makes creating templates a mess (not that it isn't a mess anyway). None of your examples ever changed the *meaning* of some code, not even the ID example. You just contradicted yourself. You just said that you were ok with align being removed from the whitelist. Yet that breaks things. I will try to speak very slow: Either remove all align attributes (drop it from the whitelist) or let them pass through (keep it whitelisted). In other words, either break *everything* or *nothing*. The current hack breaks some *random* stuff. This is not only confusing, it's completely unnecessary because every web browser is able to handle the align attributes well. You are replicating something that clearly is the responsibility of the web browser. While fixing an issue that doesn't look broken when you look at it is really hard. Again, this must be a joke. That's exactly the problem of the current hack. It makes broken code *not* look broken. It does not fix anything. It does not help people to fix their outdated template code. It does the *opposite*. It's a stupid counterproductive hack. All it does is adding confusion and breaking some random templates for no good reason. It's still a valid point that translations still work in most situations Again, *not* translating this worked in *all* situations till last week. You can't say all the templates we developed in the past years are broken. They are *not*. They were tested in all browsers. Nothing was broken till you started to change our code. -- 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 40329] Don't use hacks to replicate a browser function, either let align= pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 TMg mr.h...@gmx.de changed: What|Removed |Added Summary|Block elements inside |Don't use hacks to |elements with align= |replicate a browser |should use margin:auto; in |function, either let |HTML5 |align= pass through or ||not; in HTML5 -- 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 40462] Category sorting broken on pt.wikipedia.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=40462 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #4 from Roan Kattouw roan.katt...@gmail.com 2012-09-24 16:25:32 UTC --- (In reply to comment #3) @todo FIXME: Needs unit tests Unit tests don't address this, necessarily. The sorting order is presumably consistent in both lucid and precise, in that Alucid sorts before Blucid and Aprecise sorts before Bprecise, it's just that Blucid sorts before Aprecise which is causing problems with a mixed-distro cluster. If something is due to interaction between two machines running different software, it's generally hard to write a unit test for 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 40386] Installation of FormatNum on sl.wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=40386 Robin Pepermans (SPQRobin) robinp.1...@gmail.com changed: What|Removed |Added CC||robinp.1...@gmail.com --- Comment #2 from Robin Pepermans (SPQRobin) robinp.1...@gmail.com 2012-09-24 16:26:18 UTC --- If comma vs. decimal is the only reason, then the extension shouldn't be needed because commas and decimals are already marked correctly in MessagesSl.php ($separatorTransformTable). Though iirc formatnum does have some weird behaviour... But improvements to formatnum should go to core imho. -- 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 40422] Review and deploy FormatNum extension
https://bugzilla.wikimedia.org/show_bug.cgi?id=40422 --- Comment #5 from Platonides platoni...@gmail.com 2012-09-24 16:26:18 UTC --- For sl., it's because they want to be able to format number with comma as thousand separator. Note there could be other side reasons, as the bug 40186 description says: Unlike English, our language uses commas as decimal mark, which is the main reason we need the extension. Then the change should go into the message file. Something like separatorTransformTable = array( ',' = '.', '.' = ',' ); [assuming they use . thousands mark ] Wrong 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 40386] Installation of FormatNum on sl.wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=40386 Platonides platoni...@gmail.com changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #3 from Platonides platoni...@gmail.com 2012-09-24 16:29:26 UTC --- What should be the thousands separator for Slovenian? -- 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 40479] New: File extensions should be automatically decided by MIME type
https://bugzilla.wikimedia.org/show_bug.cgi?id=40479 Web browser: --- Bug #: 40479 Summary: File extensions should be automatically decided by MIME type Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Uploading AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: johnnymrni...@gmail.com CC: bryan.tongm...@gmail.com Classification: Unclassified Mobile Platform: --- Breaking this of related bug 32660, which was broken off of bug 4421. This would also solve bug 29284. As MW detects the MIME type of the file as it is being uploaded, it should not rely on the uploader to provide a file extension. Rather the file type should be set automatically by the software. Any extension detected in the name should be automatically removed. For example if Cheese.JPEG is uploaded, but the MIME type is PNG, the file should be named Cheese.png, and not Cheese.JPEG.png. If that MIME type is correct, it should simply be named Cheese.jpg. This should also create a notice for the uploader, so they don't lose track of their uploaded file. Obviously this will not fix existing issues mentioned in the first two bugs, but it will prevent future issues. -- 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 40479] File extensions should be automatically decided by MIME type at upload
https://bugzilla.wikimedia.org/show_bug.cgi?id=40479 johnnymrni...@gmail.com changed: What|Removed |Added Summary|File extensions should be |File extensions should be |automatically decided by|automatically decided by |MIME type |MIME type at 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 29284] Upload form should make file extensions lowercase automatically
https://bugzilla.wikimedia.org/show_bug.cgi?id=29284 johnnymrni...@gmail.com changed: What|Removed |Added CC||johnnymrni...@gmail.com --- Comment #2 from johnnymrni...@gmail.com 2012-09-24 16:41:36 UTC --- Noting that bug 40479 would resolve this issue. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 28128] Consider whether {{PLURAL:}} should handle fractional numbers
https://bugzilla.wikimedia.org/show_bug.cgi?id=28128 --- Comment #8 from Niklas Laxström niklas.laxst...@gmail.com 2012-09-24 16:41:55 UTC --- Yes, but like I said I don't expect all our plural rules to be perfect yet in that regard. -- 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 40329] Don't use hacks to replicate a browser function, either let align= pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #20 from Jesús Martínez Novo martinezn...@gmail.com 2012-09-24 16:42:11 UTC --- Just FYI: Bug 40306 is handling the problem with the align properties in HTML5 not being translated correctly to CSS. That bug was fixed and changes were already deployed to Wikimedia servers, so the original problem is no longer occurring. Yes, align properties aren't being outputted now, but browsers should render now the tables correctly as if they were still there. I think that transforming properties to valid HTML5/CSS syntax is fine, when it's done properly and without breaking things. No need to completely drop the align support *now*. The gradually remove support from those elements/attributes is being handled on bug 24529. Is it really necessary to leave this bug open and continue commenting on it? What is it's current purpose? -- 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 32660] File extensions for the same file type should not allow variations of a file name (File:X.jpg, File:X.jpeg, File:X.JPG should all refer to the same file)
https://bugzilla.wikimedia.org/show_bug.cgi?id=32660 --- Comment #12 from johnnymrni...@gmail.com 2012-09-24 16:44:11 UTC --- I'm breaking the upload fix into a separate bug Bug 40479 File extensions should be automatically decided by MIME type at upload. This will help with future issues, but will not fix any existing ones. -- 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 30519] Request to supply a working, up-to-date mediawiki version based on the current Wikipedia version
https://bugzilla.wikimedia.org/show_bug.cgi?id=30519 Gregor Hagedorn g.m.haged...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Gregor Hagedorn g.m.haged...@gmail.com 2012-09-24 16:46:51 UTC --- I appreciate the much closer cycle now achieved with 1.20, many thanks to all who have worked hard towards this. This essentially closes this feature request. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 johnnymrni...@gmail.com changed: What|Removed |Added CC||johnnymrni...@gmail.com --- Comment #81 from johnnymrni...@gmail.com 2012-09-24 16:47:00 UTC --- Bug 32660 was broken off of here, and I'm breaking another bug off of that, Bug 40479 File extensions should be automatically decided by MIME type at upload. It won't fix this bug, but it would be a step in the right direction. -- 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 29693] Resource Loader loads CSS multiple times
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693 --- Comment #10 from Roan Kattouw roan.katt...@gmail.com 2012-09-24 16:58:52 UTC --- (In reply to comment #9) Why does RL load gadget's CSS twice? One time it ships CSS with JavaScript and writing this into the DOM and one time CSS is delivered in a separate CSS file duplicating the style definitions. You can easily see it opening Firebug on Wikimedia Commons and inspecting an element that was created by one of our Gadgets that both consist of a JavaScript and CSS (e.g. the slideshow start button) This behavior was apparently introduced in November 2011 to make Gadget CSS load on time. * Is this intended behaviour? Ideally the CSS wouldn't be loaded twice, no. The reason it's currently done is to work around the fact that you can't currently set the position=top property on a Gadget to make it load before the page renders. * Is this documented (except in your source files that I can't search any more since Krinkle's SVN search is down)? No. * Are there intentions to optimise this issue? The rewrite of the Gadgets extension in the RL2 branch fixes this by only bundling the CSS with the JS, rather than loading it separately. This does mean that, unless position=top is set in the Gadget properties, the CSS will load after the page renders, right before the JS executes. This is fine if you're only styling things that your JS creates, but it's ugly if you're styling things that MediaWiki puts on the page. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40479] File extensions should be automatically decided by MIME type at upload
https://bugzilla.wikimedia.org/show_bug.cgi?id=40479 --- Comment #1 from johnnymrni...@gmail.com 2012-09-24 16:58:59 UTC --- Hopefully this should also prevent files with unknown or unsupported MIME types from being uploaded with a supported extension. So Trojan.XXX shouldn't be uploaded as Trojan.gif. This would mean a list of extensions that unknown MIME type uploads are checked against. -- 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 29693] Resource Loader loads CSS multiple times
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693 --- Comment #11 from Roan Kattouw roan.katt...@gmail.com 2012-09-24 17:01:52 UTC --- (In reply to comment #10) (In reply to comment #9) Why does RL load gadget's CSS twice? One time it ships CSS with JavaScript and writing this into the DOM and one time CSS is delivered in a separate CSS file duplicating the style definitions. You can easily see it opening Firebug on Wikimedia Commons and inspecting an element that was created by one of our Gadgets that both consist of a JavaScript and CSS (e.g. the slideshow start button) This behavior was apparently introduced in November 2011 to make Gadget CSS load on time. bug 40284 has been filed for this, linking this response from there. -- 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 40284] The CSS of each gadget is included two times
https://bugzilla.wikimedia.org/show_bug.cgi?id=40284 --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2012-09-24 17:02:43 UTC --- This was also brought up in bug 29693 comment 9, see my response there for an explanation of why this is currently happening. -- 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 40240] view source on Main_Page should be an edit to the sandbox
https://bugzilla.wikimedia.org/show_bug.cgi?id=40240 --- Comment #5 from Bawolff bawolff...@gmail.com 2012-09-24 17:10:37 UTC --- (In reply to comment #4) (In reply to comment #3) Yeah, that would seem hella confusing to get sent to some other page. Indeed, maybe the link can send them instead to a page dedicated to welcoming newcomers ? Kind of like the UploadWizard has a basic tutorial picture. I bet the users could probably already do that by putting parser funcs in various mediawiki ns messages. -- 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 40479] File extensions should be automatically decided by MIME type at upload
https://bugzilla.wikimedia.org/show_bug.cgi?id=40479 Sven Manguard svenmangu...@gmail.com changed: What|Removed |Added CC||svenmangu...@gmail.com --- Comment #2 from Sven Manguard svenmangu...@gmail.com 2012-09-24 17:11:20 UTC --- This is fantastic. I recommend that you use the shortest form in all lowercase as the chosen extension (i.e. .jpg instead of .jpeg or .JPG. This is because .jpg is the most common variant for jpegs by a great deal, and .tif is the most common varient for tiffs by something of a large-ish margin. My one concern is the handling of .ogg and .ogv. These two can /occasionally/ but not always be used interchangeably, or at the very least, have been. We can't eliminate either, but we might (I lack the technical knowledge to tell for certain) run into problems with this. Thanks for doing this, Sven -- 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 39587] Resolved - an exclusion filter or different weighting?
https://bugzilla.wikimedia.org/show_bug.cgi?id=39587 --- Comment #7 from Oliver Keyes oke...@wikimedia.org 2012-09-24 17:11:53 UTC --- That sounds sensible. Any way we can have if you hit resolves, voids all other markins and adds -10 or whatever? -- 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 40329] Don't use hacks to replicate a browser function, either let align= pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #21 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2012-09-24 17:14:11 UTC --- (In reply to comment #19) (In reply to comment #18) two users on different browsers may see two different things What are you talking about? This is not true. In the previous Wikipedia setup with HTML5 disabled all users got the same HTML output and it looked the same in all web browsers. Now this is broken. It does *not* look the same when a template is tested locally for example. The hack creates a *different* result when the finished code is finally put into a template. The hack *changes* the *meaning* of the code no matter if these attributes were used for a reason or not. This is confusing as hell. It makes creating templates a mess (not that it isn't a mess anyway). None of your examples ever changed the *meaning* of some code, not even the ID example. You originally said because you never can say how browsers were handling it (and different browsers handle stuff differently) which seamed to imply the suggestion of a browser quirk where different browsers have different results for the same deprecated markup. That's what this separate sub-discussion was about. You just contradicted yourself. You just said that you were ok with align being removed from the whitelist. Yet that breaks things. I will try to speak very slow: Either remove all align attributes (drop it from the whitelist) or let them pass through (keep it whitelisted). In other words, either break *everything* or *nothing*. The current hack breaks some *random* stuff. This is not only confusing, it's completely unnecessary because every web browser is able to handle the align attributes well. You are replicating something that clearly is the responsibility of the web browser. Browsers support deprecated and removed html so that they can correctly render ancient websites written using HTML 3.2. We are not outputting HTML 3.2, so it's our responsibility to not output stuff that was removed. As the maintainers of WikiText it is also our responsibility to ensure that pages written in WikiText continue to work except when there is a bug we have to fix and we can't fix that bug without breaking a minimal number of pages. Outputting invalid HTML is a bug. Breaking every article when we are capable of only breaking 5 of every 6. Hence fixing the bug by translating WikiText to use valid HTML that keeps as many articles working as we can is preferable to just breaking everything that relied on the bug. While fixing an issue that doesn't look broken when you look at it is really hard. Again, this must be a joke. That's exactly the problem of the current hack. It makes broken code *not* look broken. It does not fix anything. It does not help people to fix their outdated template code. It does the *opposite*. It's a stupid counterproductive hack. All it does is adding confusion and breaking some random templates for no good reason. If the output doesn't look broken to you. The output doesn't rely on browser quirks that would cause it to look broken to another user. And the output is not invalid html that constitutes a bug we need to fix. Then your wiki page is not broken. ie: If you use align=center in WikiText, and the translation to style=text-align: center; in HTML looks ok in your articles. Then there is no reason to stop using align=center. You're writing WikiText not HTML, so whether your WikiText validates under the HTML spec is irrelevant. When the output is valid. It's only broken if it looks broken. It's still a valid point that translations still work in most situations Again, *not* translating this worked in *all* situations till last week. You can't say all the templates we developed in the past years are broken. They are *not*. They were tested in all browsers. Nothing was broken till you started to change our code. Yes, they were broken. Our code outputted attributes that were deprecated and removed from html into page output. ie: MediaWiki outputted incorrect markup. Which is a bug in the software. And you made templates dependent on browser quirks and MediaWiki outputting bad markup forever... ie: You relied on a bug in the software. So yes, your templates were broken And now we're fixing the bug, repurposing that WikiText to output valid HTML/CSS that is as close as we possibly can to how you wrote templates intending to behave. -- 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 40479] File extensions should be automatically decided by MIME type at upload
https://bugzilla.wikimedia.org/show_bug.cgi?id=40479 Bawolff bawolff...@gmail.com changed: What|Removed |Added CC||bawolff...@gmail.com --- Comment #3 from Bawolff bawolff...@gmail.com 2012-09-24 17:26:58 UTC --- Say someone uploads a file named: esp. cute dogs.jpg Ignoring the fact commons probably doesn't need yet another pic of someone's puppies, the period denotes the esp is an abbreviation for especially. Under this proposal would you like us to A) prevent the file being uploaded B) Auto rename it to esp.jpg C) Magically recognize the . cute dogs is not an extension, and let it through. -- 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 40463] Uncaught TypeError: Cannot call method 'canHaveChildren' of null
https://bugzilla.wikimedia.org/show_bug.cgi?id=40463 James Forrester jforres...@wikimedia.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from James Forrester jforres...@wikimedia.org 2012-09-24 17:29:25 UTC --- Thought this one got fixed, but clearly not. :-) -- 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 29693] ResourceLoader should not load CSS again if it was already included with only=styles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693 Krinkle krinklem...@gmail.com changed: What|Removed |Added CC||krinklem...@gmail.com Summary|Resource Loader loads CSS |ResourceLoader should not |multiple times |load CSS again if it was ||already included with ||only=styles -- 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 40479] File extensions should be automatically decided by MIME type at upload
https://bugzilla.wikimedia.org/show_bug.cgi?id=40479 --- Comment #4 from johnnymrni...@gmail.com 2012-09-24 17:32:25 UTC --- (In reply to comment #2) This is fantastic. I recommend that you use the shortest form in all lowercase as the chosen extension (i.e. .jpg instead of .jpeg or .JPG. This is because .jpg is the most common variant for jpegs by a great deal, and .tif is the most common varient for tiffs by something of a large-ish margin. My one concern is the handling of .ogg and .ogv. These two can /occasionally/ but not always be used interchangeably, or at the very least, have been. We can't eliminate either, but we might (I lack the technical knowledge to tell for certain) run into problems with this. Thanks for doing this, Sven .ogg is used generically for the container format, but .ogv is designed solely for OGG video, and .oga is solely for OGG audio. As they have separate MIME types, there shouldn't be an issue. The main source of conflation is that OGG audio codec is called OGG Vorbis, so some people assume that the extension .ogv is for that (I know I did). Worst case, if there is some issue with OGG, or people are super-attached to the generic extension, the MIME type can be left alone for now. The vast majority of uploads are pictures, and I'd rather see only those issues resolved than none at all. -- 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 40284] The CSS of each gadget is included two times
https://bugzilla.wikimedia.org/show_bug.cgi?id=40284 --- Comment #2 from Krinkle krinklem...@gmail.com 2012-09-24 17:32:50 UTC --- I was going to duplicate with bug 29693. Whatever solution (if any) is considered, it can be applied to Gadgets similarly. One possible way (though not an option for gadget) is to require that modules be split in a part that contains style for server output and a module with javascript and styling for that. That's how we do it in core for some of these cases. Note that this split up can not (should not) be automated because some stylesheets are only relevant in a scripted context and visa versa. The only problem is that we don't have a way to tell gadgets that it should be loaded as a link only with only=styles. Effectively adding a new type of module (dynamic bottom, dynamic top, static top), which can't have scripts. -- 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 40479] File extensions should be automatically decided by MIME type at upload
https://bugzilla.wikimedia.org/show_bug.cgi?id=40479 --- Comment #5 from johnnymrni...@gmail.com 2012-09-24 17:36:04 UTC --- (In reply to comment #3) Say someone uploads a file named: esp. cute dogs.jpg Ignoring the fact commons probably doesn't need yet another pic of someone's puppies, the period denotes the esp is an abbreviation for especially. Under this proposal would you like us to A) prevent the file being uploaded B) Auto rename it to esp.jpg C) Magically recognize the . cute dogs is not an extension, and let it through. The software already knows which extensions belong to which MIME types, it's not magic. As . cute dogs is not an extension, there would be no issue. There is no reason to attack every period, only known extensions. Even unknown extensions should be safe, as long as their MIME type is equally unknown. If the MIME type is known, it's appended. So if a JPEG is uploaded as esp. cute dogs.dog, it would become esp. cute dogs.dog.jpg, and the uploaded is asked if they wish to continue. -- 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 40479] File extensions should be automatically decided by MIME type at upload
https://bugzilla.wikimedia.org/show_bug.cgi?id=40479 --- Comment #6 from johnnymrni...@gmail.com 2012-09-24 17:42:20 UTC --- To be absolutely clear, this should only relate to extensions at the end of the file. So exe.gif.png.jpg would be a fine name for a JPEG, if bizarre. -- 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 29693] ResourceLoader should not load CSS again if it was already included with only=styles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693 --- Comment #12 from Subfader subfa...@gmail.com 2012-09-24 17:55:34 UTC --- The fucked up Ressource Loader (sorry for the strong language) is the reason why I still cannot upgrade from MW 1.16. I wait for RL 2. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align= pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #22 from TMg mr.h...@gmx.de 2012-09-24 17:56:12 UTC --- (In reply to comment #20) when it's done properly and without breaking things. It is not done properly. It breaks things. This is what this bug is about. See my example in the first comment. (In reply to comment #21) You originally said because you never can say how browsers were handling it (and different browsers handle stuff differently) I have not said that. it's our responsibility to not output stuff that was removed. It was not removed. Every web browser in the world is able to render align attributes properly. With your current hack you are doing the job of the we browser and you are doing it bad. There is no need to replicate something that *every* web browser in the world can do by it's own. it is also our responsibility to ensure that pages written in WikiText continue to work Then do this please. Currently an unknown number of WikiText pages do not continue to work. except when there is a bug we have to fix What bug? There was no bug with the align properties. It worked fine for decades and it will continue to work for decades. Breaking every article What are you talking about? Absolutely nothing will break if you output the align attributes. It's only broken if it looks broken. Again, what are you talking about? It *does* look broken. This is what this bug is about. MediaWiki outputted incorrect markup. Then drop your support for this markup if you consider it incorrect. Tell the people it will be dropped, give them some time and then drop it. Either this or continue to support it. But don't change the *meaning* of *my* code. So yes, your templates were broken No, they were not. They worked fine and they will work find for the next decades. I tested them in every browser. There was no bug. *You* introduced a 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 29693] ResourceLoader should not load CSS again if it was already included with only=styles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693 --- Comment #13 from Roan Kattouw roan.katt...@gmail.com 2012-09-24 17:56:55 UTC --- (In reply to comment #12) The fucked up Ressource Loader (sorry for the strong language) is the reason why I still cannot upgrade from MW 1.16. I wait for RL 2. 1.17 was buggy because some fixes that made it into production accidentally didn't make it into the tarball, but have you tried using 1.19? Did you encounter any RL-related problems with 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 29693] ResourceLoader should not load CSS again if it was already included with only=styles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693 --- Comment #14 from Subfader subfa...@gmail.com 2012-09-24 18:01:31 UTC --- No I havent't but reading that CSS is adding CSS twice to fix a problem RL created itself makes RL look a bad and not very trustworthy. My wiki is extremely customized. Upgrading means lot of manual adjustment to core code and testing. I won't upgrade now when RL will be fixed in RL 2 soon after I upgraded. -- 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 40480] New: Scribunto: Undefined class constant 'PERCENT'
https://bugzilla.wikimedia.org/show_bug.cgi?id=40480 Web browser: --- Bug #: 40480 Summary: Scribunto: Undefined class constant 'PERCENT' Product: MediaWiki extensions Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Scribunto AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: s...@reedyboy.net CC: tstarl...@wikimedia.org, vasi...@gmail.com Classification: Unclassified Mobile Platform: --- Fatal error: Undefined class constant 'PERCENT' in /usr/local/apache/common-local/php-1.20wmf12/extensions/Scribunto/engines/LuaSandbox/Engine.php on line 17 -- 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 40480] Scribunto: Undefined class constant 'PERCENT'
https://bugzilla.wikimedia.org/show_bug.cgi?id=40480 --- Comment #1 from Sam Reed (reedy) s...@reedyboy.net 2012-09-24 18:05:12 UTC --- From srv229 Sep 24 18:01:10 10.0.2.229 apache2[23797]: PHP Fatal error: Undefined class constant 'PERCENT' in /usr/local/apache/common-local/php-1.20wmf12/extensions/Scribunto/engines/LuaSandbox/Engine.php on line 17 -- 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 29693] ResourceLoader should not load CSS again if it was already included with only=styles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693 --- Comment #15 from Krinkle krinklem...@gmail.com 2012-09-24 18:09:39 UTC --- (In reply to comment #12) The fucked up Ressource Loader (sorry for the strong language) is the reason why I still cannot upgrade from MW 1.16. I wait for RL 2. RL2 is Gadgets 2.0, this has nothing to do with ResourceLoader in MediaWiki core. There were a few bugs in MediaWiki core that blocked Gadgets 2.0, but those have already been resolved and were released in MediaWiki 1.19 and are now in MediaWiki 1.20alpha as well. So in a way you could say that as far as MediaWiki core is concerned RL2 is ready and released. Can you be more specific what you were waiting for RL-related? -- 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 29693] ResourceLoader should not load CSS again if it was already included with only=styles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693 --- Comment #16 from Krinkle krinklem...@gmail.com 2012-09-24 18:12:36 UTC --- (In reply to comment #14) No I havent't but reading that CSS is adding CSS twice to fix a problem RL created itself makes RL look a bad and not very trustworthy. It doesn't just load it twice, that's non-sense. The way this happens is by design but there are a few modules that have not been converted correctly and as such get their css applied twice. Its minimal. As for stability, speed and efficiency for the client side (users using a web browser) I believe, ResourceLoader is most definitely an improvement over how it was in MediaWiki 1.16. So unless you actually tried upgrading and have a tangible problem, I'd say, upgrade and enjoy. -- 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
