[Bug 10871] Apply syntax highlighting to eligible pages during diffs and page previews
https://bugzilla.wikimedia.org/show_bug.cgi?id=10871 Erwin Dokter er...@darcoury.nl changed: What|Removed |Added CC||er...@darcoury.nl --- Comment #7 from Erwin Dokter er...@darcoury.nl 2010-12-07 12:12:05 UTC --- 1.16wmf4: Yes, diffs seem fixed and preview of .css and .js files in User: space seems disabled (for good reason), but preview of .css and .js files in MediaWiki: space remains being rendered as wikitext; they also need highlighting, or at least be wrapped in pre. -- 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 26268] Make TopFiveReviewers configurable
https://bugzilla.wikimedia.org/show_bug.cgi?id=26268 --- Comment #4 from Chad H. innocentkil...@gmail.com 2010-12-07 12:27:16 UTC --- (In reply to comment #3) (In reply to comment #2) Save for after the Pending Changes fork There's going to be a Pending Changes fork? Yes, and it was mentioned back over the summer (I'm pretty sure I've talked about it on IRC before). FlaggedRevs is really two extensions: traditional FlaggedRevs and Pending Changes. A good portion of the code is disjoint. From a code maintenance perspective, it makes the most sense in the long run to split off the Pending Changes feature into its own extension. -- 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 26272] New: Duplicated section
https://bugzilla.wikimedia.org/show_bug.cgi?id=26272 Summary: Duplicated section Product: MediaWiki Version: 1.16 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Page rendering AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: ho94...@gmail.com If section title duplicate like == Foo == == Foo == second span tag id is not Foo but Foo_2 but if I add section Foo_2 before second Foo like == Foo == == Foo_2 == == Foo == then span id Foo_2 is duplicated -- 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 26273] New: Database layer should automagically add GROUP BY columns on backends that need them (postgres)
https://bugzilla.wikimedia.org/show_bug.cgi?id=26273 Summary: Database layer should automagically add GROUP BY columns on backends that need them (postgres) Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Database AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: roan.katt...@gmail.com Postgres is pedantic when it comes to GROUP BY queries and demands that all selected columns that aren't used with an aggregate function be in the GROUP BY clause, even if the GROUP BY already covers a unique index (meaning grouping by more columns would have no effect). MySQL is more flexible, causing developers to write queries that fail on Postgres for this reason. Instead of developers having to go through a lot of trouble to construct GROUP BY clauses with the right columns with the ORDER BY columns at the beginning (r68100), the database layer should do this for them. Because the semantics of GROUP BY described here are actually in the SQL standard IIRC, there's likely to be more DB backends, so I think this should be implemented in DatabaseBase::makeSelectOptions() with DB backends needing this functionality overriding needsAllColumnsInGroupBy() or whatever to return true. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 26274] New: Database layer should allow arrays for ORDER BY, GROUP BY, HAVING
https://bugzilla.wikimedia.org/show_bug.cgi?id=26274 Summary: Database layer should allow arrays for ORDER BY, GROUP BY, HAVING Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Database AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: roan.katt...@gmail.com 'ORDER BY' = 'foo, bar' works but 'ORDER BY' = array( 'foo', 'bar' ) doesn't. Same for GROUP BY. We also don't have nice array-based condition building for HAVING like we do for WHERE. -- 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 26222] Change the WikiLogo to the local Wiki.png file
https://bugzilla.wikimedia.org/show_bug.cgi?id=26222 --- Comment #2 from Pandelea Daniel pandelea.dan...@gmail.com 2010-12-07 13:46:57 UTC --- http://ro.wikipedia.org/wiki/Discu%C8%9Bie_Wikipedia:Sfatul_B%C4%83tr%C3%A2nilor#Logo_1_decembrie.2C_16_decembrie.2C_25_decembrie_etc Unfortunately only one administrator answered the discussion after 7 days. I have uploaded the new logo at http://ro.wikipedia.org/wiki/File:Wiki.png -- 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 26239] Palm mobile rendering problem
https://bugzilla.wikimedia.org/show_bug.cgi?id=26239 p...@surdigital.co.uk changed: What|Removed |Added CC||p...@surdigital.co.uk --- Comment #7 from p...@surdigital.co.uk 2010-12-07 13:50:04 UTC --- This is very definetely unfixed, and the bahaviour is the same on both Palm Pre and Palm Pixi. Boht devices are correctly pointing themselves to the mobile site not the desktop site. They are nto displaying the desktop site either, it is an incorrectly formatted version of the mobile site. whatsmyuseragent.com reports: Mozilla/5.0 (webOS/1.4.5; U; en-GB) AppleWebKit/532.2 (KHTML, like Gecko) Version/1.0 Safari/532.2 Pixi/1.1 Does this problem coincide with the introduction of the wikipedia appeal banner? If we donate, will it go away -- 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 26274] Database layer should allow arrays for ORDER BY, GROUP BY, HAVING
https://bugzilla.wikimedia.org/show_bug.cgi?id=26274 --- Comment #1 from Chad H. innocentkil...@gmail.com 2010-12-07 13:59:59 UTC --- Created attachment 7890 -- https://bugzilla.wikimedia.org/attachment.cgi?id=7890 GROUP BY/ORDER BY array() support For GROUP and ORDER BY, would something as simple as this work? -- 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 26274] Database layer should allow arrays for ORDER BY, GROUP BY, HAVING
https://bugzilla.wikimedia.org/show_bug.cgi?id=26274 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 14:04:43 UTC --- (In reply to comment #1) Created attachment 7890 [details] GROUP BY/ORDER BY array() support For GROUP and ORDER BY, would something as simple as this work? I think so -- 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 26179] Cannot upload multiple files simultaneously on live Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=26179 --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 14:07:35 UTC --- Created attachment 7891 -- https://bugzilla.wikimedia.org/attachment.cgi?id=7891 Proposed patch (untested) The attached patch fixes this by moving the upload stash metadata out of $_SESSION altogether and into memcached (or APC or DB cache, whatever's available; it uses CACHE_ANYTHING) keyed by session ID and stash key, so there should be no interference between processes provided you're not trying to upload the same file twice at the same time. Patch is untested, and I'm not sure you like the idea of moving this out of the session even on normal installs where PHP's session locking prevents these concurrency issues from happening. -- 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 7936] Distinguish disambiguation pages in [[Special:Allpages]]
https://bugzilla.wikimedia.org/show_bug.cgi?id=7936 jida...@jidanni.org changed: What|Removed |Added CC||jida...@jidanni.org Depends on||26266 -- 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 26266] Add .allpagesredirect, .redirect-in-category to standard CSS
https://bugzilla.wikimedia.org/show_bug.cgi?id=26266 jida...@jidanni.org changed: What|Removed |Added Blocks||7936 -- 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 10871] Apply syntax highlighting to eligible pages during diffs and page previews
https://bugzilla.wikimedia.org/show_bug.cgi?id=10871 Platonides platoni...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Platonides platoni...@gmail.com 2010-12-07 14:55:57 UTC --- Fixed in r77981. Only pre formatting is used, since the hook used by SyntaxHighlighting is not appropiate there. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25624] Making license and author information api accessible
https://bugzilla.wikimedia.org/show_bug.cgi?id=25624 --- Comment #3 from Krinkle krinklem...@gmail.com 2010-12-07 15:06:42 UTC --- I've been brainstorming a little last weekend for the details of a few things. Wrote it up here: http://meta.wikimedia.org/wiki/User:Krinkle/Files_and_licenses_concept -- Krinkle -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25887] Bugzilla 4.0 is out
https://bugzilla.wikimedia.org/show_bug.cgi?id=25887 --- Comment #4 from Reedy s...@reedyboy.net 2010-12-07 16:09:40 UTC --- Version 4 should be out next Wednesday -- 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 20069] Implement PHP syntax validity (as SVN post commit hook)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20069
Roan Kattouw roan.katt...@gmail.com changed:
What|Removed |Added
CC||roan.katt...@gmail.com
--- Comment #8 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 16:10:11
UTC ---
(In reply to comment #7)
find \( -name \*.php -or -name \*.inc \) -exec php -l \{\} \; | grep -v No
syntax errors detected
I branched REL1_17 today, which caused the pre-commit hook to syntax-check a
full copy of /trunk/phase3 and /trunk/extensions , which succeeded.
--
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 25270] Review queues in CodeReview
https://bugzilla.wikimedia.org/show_bug.cgi?id=25270 --- Comment #9 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 16:11:50 UTC --- I was personally hoping to be able to have queues that you can just throw random stuff in, but this saved searches stuff would be a big step forward already. -- 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 26255] Flaggedrevs.js file contains some syntax errors
https://bugzilla.wikimedia.org/show_bug.cgi?id=26255
Roan Kattouw roan.katt...@gmail.com changed:
What|Removed |Added
CC||roan.katt...@gmail.com
--- Comment #5 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 16:18:37
UTC ---
(In reply to comment #2)
I haven't heard of any browsers having problems with this. But it should be
done anyway.
One thing is it's cleaner to end a statement with a semicolon, although not
strictly required. If the last statement in a file doesn't end with a
semicolon, concatenating files can result in strange bugs.
Declarations like function foo( args ) { code } don't need a semicolon, but
things like var foo = function( args ) { code }; do, because they're statements
(assignments).
--
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 26258] Unknown modifier 'p' in EditPage.php on line 1106
https://bugzilla.wikimedia.org/show_bug.cgi?id=26258 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 16:23:46 UTC --- It's an error in your regex: \/span\s*a\s*href|. //This blocks lt;a href links entirely, forcing wiki syntax The regex is enclosed in /regex here/ , so the / in the span tag needs to be escaped, like so: \/span -- 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 26258] Unknown modifier 'p' in EditPage.php on line 1106
https://bugzilla.wikimedia.org/show_bug.cgi?id=26258 --- Comment #3 from szotsaki szots...@gmail.com 2010-12-07 16:30:24 UTC --- Yes, you're right, I fixed that; thank you! I don't remember from where I copied this snippet. I googled for it but I don't find to fix 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 26261] Bundle ParserFunctions extension with MediaWiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=26261 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #10 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 16:31:02 UTC --- I support bundling ParserFunctions. What does this look like to the installing user, anyway? Are they offered the choice to install PF or not in a non-confusing way? -- 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 9530] Section heading anchors shouldn't begin with invalid characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=9530 --- Comment #31 from Philippe Verdy verd...@wanadoo.fr 2010-12-07 16:34:09 UTC --- I really *didnot* say that Punycode wpould solve the duplicates. In fact you're resaying exactly what I said (even speaking that this was a separate issue). I have never intended that Punycode would solve duplicates. It was just possible to use it as an alternative to the incorrect syntax of existing id's that contain dots. You can argue anything you want but anything generated like: id=.C2.BF is completely invalid. There MUST not ne any dot in id's generated from non-ASCII characters. and the current encoding exposes each UTF-8 byte in its hex form, which is really inefficient (in terms of length) and really unreadable (not more that Punycode), when many more letters outside ASCII are perfectly valid in HTML an XML id's. Why can't we have ids like: id=Résumé (which is perfectly valid) and we still have to see things like: id=R.C2.E9sum.C2.E9 (which is completely invalid) ??? That's ALL what I was commenting (and I did not introduce myself the separate problem of duplicates). You misunderstood or simply did not read my own statements. Punycode was ONLY a suggestion for the first problem. It is of course based on a framework where we absolutely don't need to keep the additional xn-- prefix which is definitely not part of Punycode itself, but part of its use in IDNA (which has a much more restricted subset of valid characters, than the set of valid characters in XML id's). But Punycode still offers a good encoding framework for building valid XML id's for the case were some characters are restricted (we'll still need to encode in some way the presence of dots in NON-encoded section headings). -- 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 9530] Section heading anchors shouldn't begin with invalid characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=9530 --- Comment #32 from Philippe Verdy verd...@wanadoo.fr 2010-12-07 16:37:33 UTC --- See this reference for the syntax of names (and the restricted set) in XML: http://www.w3.org/TR/REC-xml/#NT-Name -- 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 26244] Tesla does funky things
https://bugzilla.wikimedia.org/show_bug.cgi?id=26244 --- Comment #3 from Mark A. Hershberger m...@everybody.org 2010-12-07 16:38:32 UTC --- Created attachment 7892 -- https://bugzilla.wikimedia.org/attachment.cgi?id=7892 mark's phpinfo phpinfo where this bug occurs. -- 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 9530] Section heading anchors shouldn't begin with invalid characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=9530 --- Comment #33 from Philippe Verdy verd...@wanadoo.fr 2010-12-07 16:43:21 UTC --- You'll immediately se that the ONLY ASCII characters valid everywhere in IDs are only the ASCII letters and the underscore; and plenty of other non ASCII characters are accepted which don't need any UTF-8 bytes-based .NN hex encoding like it is done today (in an overlong form). Additional ASCII characters are accepted ONLY after the initial position (this includes the dot, the minus-hyphen, and ASCII digits); additional NON-ASCII characters are also accepted after the first position (notably the combining characters). -- 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 26244] Tesla does funky things
https://bugzilla.wikimedia.org/show_bug.cgi?id=26244 --- Comment #4 from Mark A. Hershberger m...@everybody.org 2010-12-07 16:43:25 UTC --- SearchDbTest shows no errors, but: $ ./phpunit.php includes/ParserOptionsTest.php [.,,] Time: 1 second, Memory: 12.00Mb There was 1 error: 1) ParserOptionsTest::testGetParserCacheKeyWithDynamicDates MWException: Tried to create a ParserCache with an invalid memcached /home/mah/work/code/mediawiki/mw-svn/includes/parser/ParserCache.php:35 /home/mah/work/code/mediawiki/mw-svn/includes/parser/ParserCache.php:22 /home/mah/work/code/mediawiki/mw-svn/maintenance/tests/phpunit/includes/ParserOptionsTest.php:13 /home/mah/work/code/mediawiki/mw-svn/maintenance/tests/phpunit/phpunit.php:34 -- 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 9530] Section heading anchors shouldn't begin with invalid characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=9530 --- Comment #34 from Philippe Verdy verd...@wanadoo.fr 2010-12-07 17:05:17 UTC --- Note that this is most problameatic with non-Latin wikis (see the Chinse, Korean, Japanese, Arabic, Hebrew, Thai wikis !), were almost all characters are hex-encoded (in overlong sequences) and expose an invalid leading dot, when no hex encoding at all was even necessary in most cases. Do you still argue that these hex-encoded ID's are readable ??? They're definitely not ! -- 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 26251] Upload video files 100 MB to Wikimedia Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=26251 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #3 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 17:08:18 UTC --- I'll import these in the next hour or so. For next time, the following things would make this easier: * File description pages as .txt files (so you'd have Foo.ogv and Foo.txt pairs) * Everything (files and description .txt files) in one tarball -- 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 9530] Section heading anchors shouldn't begin with invalid characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=9530 --- Comment #35 from Gadget850 ed.pal...@gmail.com 2010-12-07 17:20:31 UTC --- OK, so leading dots are invalid. Simple fix: add a prefix to all section headers, such as section_ to ensure the id always starts with a valid character. MediaWiki dot encodes UTF characters as needed, which are valid in any position other than the first. The cite.php citation extension does this in the same manner, using cite_ref- and cite_note- as id prefixes to ensure valid HTML output. -- 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 26268] Make TopFiveReviewers configurable
https://bugzilla.wikimedia.org/show_bug.cgi?id=26268 --- Comment #5 from Rob Lanphier ro...@wikimedia.org 2010-12-07 17:56:24 UTC --- (In reply to comment #3) There's going to be a Pending Changes fork? Latest version of the roadmap talks about this some more: http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/Roadmap The fork is contingent on Pending Changes being kept on enwiki. If English Wikipedia drops it, we'll probably drop development on the configuration and focus any dev activity on the traditional FlaggedRevs config. -- 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 24915] Move CSS signatures from body to html
https://bugzilla.wikimedia.org/show_bug.cgi?id=24915
--- Comment #5 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-12-07
18:20:58 UTC ---
(In reply to comment #4)
Styling html and body is the only way to do things that can be done in
Monobook
with #globalWrapper (and Vector does not have a #globalWrapper), such as
making
a page narrower:
html {
background: white; /* needed to prevent body from filling the canvas */
}
body {
background: #f3f3f3;
margin: 0 auto;
width: 80%;
}
True.
Whether rules apply to body or html does not make a difference in most
cases.
It makes a big difference if some rules are applied to both elements, though,
which will be the case if both have the classes during a transition period. So
I don't see any way to switch the classes without a level of disruption that
doesn't seem warranted by the benefits.
But now I see another problem: Page names can contain non-ASCII
characters and non-ASCII characters must not occur before the charset has been
declared. This would mean that the charset must be declared in the HTTP header
(right now this is not strictly necessary because no non-ASCII characters
occur
before the meta charset element).
I think MediaWiki is careful to do this anyway, so this might not be a big
deal.
--
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 9530] Section heading anchors shouldn't begin with invalid characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=9530 --- Comment #36 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-12-07 18:40:15 UTC --- (In reply to comment #31) You can argue anything you want but anything generated like: id=.C2.BF MediaWiki trunk does not create such id's. is completely invalid. Not in HTML5. Why can't we have ids like: id=Résumé (which is perfectly valid) and we still have to see things like: id=R.C2.E9sum.C2.E9 (which is completely invalid) ??? In trunk, the wikitext == Résumé == produces div id=R.C3.A9sum.C3.A9/div h2span class=mw-headline id=RésuméRésumé/span/h2 The link from the table of contents is a href=#Résumé. (The extra div is kept so old links don't break -- it can be removed eventually.) (In reply to comment #32) See this reference for the syntax of names (and the restricted set) in XML: http://www.w3.org/TR/REC-xml/#NT-Name HTML5 does not define the id attribute to be an XML Name. In fact, it has no DTD at all. The restrictions on the id element in HTML5 (in both text/html and XML syntax) are stated here: The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character. The value must not contain any space characters. http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-id-attribute As further evidence that id's in HTML5 are allowed to start with dots in XML as well as text/html format, see this link: http://validator.nu/?doc=data%3Aapplication%2Fxhtml%2Bxml%2C%3Chtml+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22+id%3D%22.%22%3E%3Chead%3E%3Ctitle%3E%3C%2Ftitle%3E%3C%2Fhead%3E%3Cbody%3E%3C%2Fbody%3E%3C%2Fhtml%3E This is not permitted by XHTML 1.0, which we still technically support, but that's obsolete and I don't expect us to care if we break XHTML 1.0 validation in some cases in the future. Eventually we're likely to remove the mode entirely. This bug will be INVALID as soon as $wgHtml5 is removed and set always to true. (In reply to comment #34) Do you still argue that these hex-encoded ID's are readable ??? They're definitely not ! The id's *in trunk* are readable. Example heading taken from he.wikipedia.org: == איפה נמצא העמוד ראשי של מחר? == id generated in trunk: id=איפה_נמצא_העמוד_ראשי_של_מחר? This is valid in HTML5 and works in the (recent-enough) browsers it's been tested in. -- 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 26275] New: Issue with range blocking
https://bugzilla.wikimedia.org/show_bug.cgi?id=26275 Summary: Issue with range blocking Product: MediaWiki Version: wikimedia-deployment Platform: All OS/Version: All Status: NEW Severity: critical Priority: Normal Component: Blocking AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: nakor...@gmail.com While doing a CU check I found an issue with range blocking. I do not want to post the details here. Is there a private channel of communication for this? -- 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 26234] CentralNotice moves content down when a link to a heading is followed
https://bugzilla.wikimedia.org/show_bug.cgi?id=26234 --- Comment #7 from Ryan Kaldari rkald...@wikimedia.org 2010-12-07 18:42:49 UTC --- That's an interesting idea. I know that they used different sizes earlier in the fundraiser, but it does seem like they've started using a standard size recently. I'll ask them if they plan on sticking with that size or 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 26275] Issue with range blocking
https://bugzilla.wikimedia.org/show_bug.cgi?id=26275 Nakor nakor...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Nakor nakor...@gmail.com 2010-12-07 18:46:57 UTC --- Nevermind I figured it out. -- 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 26275] Issue with range blocking
https://bugzilla.wikimedia.org/show_bug.cgi?id=26275 Max Semenik maxsem.w...@gmail.com changed: What|Removed |Added Resolution|FIXED |INVALID Severity|critical|normal -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 26251] Upload video files 100 MB to Wikimedia Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=26251 --- Comment #4 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 18:49:01 UTC --- (In reply to comment #3) For next time, the following things would make this easier: * Don't upload the description pages with borked encoding -- 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 26246] User availability status extension
https://bugzilla.wikimedia.org/show_bug.cgi?id=26246 Krinkle krinklem...@gmail.com changed: What|Removed |Added CC||krinklem...@gmail.com --- Comment #7 from Krinkle krinklem...@gmail.com 2010-12-07 18:51:54 UTC --- Aside from existing extensions, we should not forget that it should work with CentralAuth, assuming we will not differentiate between accounts that are essentially the same. I think logging in/logging out is a good way to do it. a mw_user_status table could exist with columns us_user and us_touched within centralauth. Each row a user that is online. When logging out the entry is removed, when logging it an entry is added. When making an edit or log action (!) the column us_touched is updated.. When viewing user-page or user-talk-page of a user that has this preference enabled for his SUL-account (just like emailadres is centralized) the status returned is either offline (if there is no row in mw_user_status), online (if us_touched is empty or less then X minutes ago) or away (if us_touched is more than X minutes ago). X minutes could be set per-user. ie. if my preference 'status-away-minutes' is set to 5 minutes and John Doe's last action was 5,1 minute ago, I see it as away. Personally I think adding custom statuses and allowing users to set it to away themselfs is too much, but that's just me. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 26251] Upload video files 100 MB to Wikimedia Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=26251 --- Comment #5 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 18:53:58 UTC --- (In reply to comment #4) (In reply to comment #3) For next time, the following things would make this easier: * Don't upload the description pages with borked encoding Strike that, that was just Bugzilla being stupid. -- 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 26239] Palm mobile rendering problem
https://bugzilla.wikimedia.org/show_bug.cgi?id=26239 --- Comment #8 from Aaron aaron.ship...@gmail.com 2010-12-07 18:54:20 UTC --- There has been no software updates pushed out for the Palm Pre since at least August or September. The user agent in the Pre still has the word Pre in it as I checked at whatsmyuseragent.com: Mozilla/5.0 (webOS/1.4.5; U; en-US)AppleWebKit/532.2 (KHTML, like Gecko)Version/1.0 Safari/532.2 Pre/1.0 I don't know what changes were made on the website server, but it's something on your end - nothing to do with changes in the Palm Pre browser. -- 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 26244] Tesla does funky things
https://bugzilla.wikimedia.org/show_bug.cgi?id=26244 --- Comment #5 from Mark A. Hershberger m...@everybody.org 2010-12-07 19:11:46 UTC --- Created attachment 7893 -- https://bugzilla.wikimedia.org/attachment.cgi?id=7893 from my 64bit laptop This is from my other laptop that is also showing the same symptoms -- 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 26251] Upload video files 100 MB to Wikimedia Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=26251 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 19:11:53 UTC --- 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 26244] Tesla does funky things
https://bugzilla.wikimedia.org/show_bug.cgi?id=26244 --- Comment #6 from Max Semenik maxsem.w...@gmail.com 2010-12-07 19:16:56 UTC --- A few differences between Tesla and average developer's setup™: * It uses install.php to setup things from CLI * On Linux, there's no predefined order in which files are returned by file search, therefore tests are run in an unpredictable order. This matters if some tests aren't isolated enough (and we have plenty of such tests, I assure you) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 9530] Section heading anchors shouldn't begin with invalid characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=9530 --- Comment #37 from Philippe Verdy verd...@wanadoo.fr 2010-12-07 19:22:11 UTC --- Yes XHTML 1.0 will be deprecated, but ony its modular design, that highly depends on validation with external schemas that have to be declared in the document. But HTML5 does NOT deprecate the compatibility with XML and it explciitly says that it will support TWO syntaxes for its serialization : the historical SGML-based HTML syntax, AND the XML syntax. The inlydifference is that it will not be modular and the schema for the validation of the content model will be inferred. This means that you'll still be able to use an XML parser, but the schema will not be specified by the document itself, so that the documetn can be processed in standalone mode using a schema provided by the application using the XML parser, instead of by the ocument or by the site producing it. In other words, the XML contraints on names continue to apply to HTML5 for strict conformance, otherwise it will not be possible to use an XML parser for it, or to embed HTML5 in an XML document. XHTML 1.0 is also abandonned because it created a fork from HTML in a separate branch. HTML5 remerges the two branches and deprecates the modular design and free extensions based on non-standard schemas. Note also, that XML documents do not need to validate, but must still observe the conformance rules. Even a non-validating XML parser will choke on invalid ID's if they are presented with the xml:id pseudo-attribute. But I agree with you, id's in HTML5 are not used with a xml:id pseudo-attribute, but by a plain id attribute : if the XML parser does not validate the schema, it will accept an id attribute containing anything. But as soon as you'll want to build a schema for your XML parsed document, it will be impossible to use anything else than the XML type name that restricts its value, if you want the compatibility with schemas built for XHTML 1.0, unless you make this id atribute into an unrestricted text type. -- 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 9530] Section heading anchors shouldn't begin with invalid characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=9530 --- Comment #38 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-12-07 19:31:48 UTC --- (In reply to comment #37) But HTML5 does NOT deprecate the compatibility with XML and it explciitly says that it will support TWO syntaxes for its serialization : the historical SGML-based HTML syntax, AND the XML syntax. Correct. However, the id element is not defined as an XML Name in HTML5's XML syntax. In other words, the XML contraints on names continue to apply to HTML5 for strict conformance, otherwise it will not be possible to use an XML parser for it, or to embed HTML5 in an XML document. You're mistaken. There is no conformance mode in HTML5 that prohibits id=., nor any notion of strict conformance defined anywhere in HTML5. And XML parsers can handle such id's just fine. It will not validate in a DTD that makes id= a Name, but HTML5 has no DTD, so this is fine. But as soon as you'll want to build a schema for your XML parsed document, it will be impossible to use anything else than the XML type name that restricts its value, if you want the compatibility with schemas built for XHTML 1.0, unless you make this id atribute into an unrestricted text type. Correct. Any DTD that's compatible with HTML5's requirements will make id an unrestricted text type. Any DTD that restricts it to Name will incorrectly declare valid HTML5 documents to be invalid. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 26179] Cannot upload multiple files simultaneously on live Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=26179 --- Comment #3 from Neil Kandalgaonkar ne...@wikimedia.org 2010-12-07 20:01:50 UTC --- Okay, there's a number of things here... Somewhat irrelevant to the main thrust here -- making the local cache of the file in UploadStash-files upon storage, rather than a memoized retrieval -- this seems wrong to me as you only get a chance to do this in the same process as the one that created the record. Any subsequent access is slow. If the argument is that the caches are fast anyway then the whole optimization of having UploadStash-files should be removed. Okay, the main thing you did is to: - make entries directly in cache. I verified that there isn't any case in MediaWiki where we have absolutely no cache available, so that seems okay. - but now we're relying on an unspecified number of forms of cache, that will change in the future, to do intraserver communication. Unlike $_SESSION which has to do that even for a website to work, other forms of caching may not. This will happen to work in the MediaWiki cluster since we'll get memcache, and on a typical standalone MediaWiki you'll get a *DBM, so maybe it's okay, but it bothers me a little. - Since you give each upload their own key, they are truly isolated so that probably will fix the concurrency issue. This makes all the uploads truly isolated, which is nice, but also breaks with the convention of storing all of them under a particular key (this is what everyone else does, such as the UploadByUrl, Firefogg uploads) and it also makes it difficult to find all the uploads later if we wanted to. There is no case in the application where we have to do this, but I anticipate we will want to do this later. You might have a really simple solution here but I want to think about it a bit more. Some other ideas to fix it: - It might be as simple as eliminating the line that creates an array in $_SESSION[UploadBase::SESSION_NAME]. This is PHP, multi-dimensional hashes spring into existence on assignment. Depending on how this is implemented maybe that solves it. - Figuring out a locking system to obtain control over $_SESSION[UploadBase::SESSION_KEYNAME]. Of course that means we are starting to implement a database. ;( - Actually use the database -- least desirable from a standpoint of doing a quick fix, but probably the best long term solution -- 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 26276] New: No css seems not to work in Vector and Monobook skin
https://bugzilla.wikimedia.org/show_bug.cgi?id=26276 Summary: No css seems not to work in Vector and Monobook skin Product: MediaWiki Version: 1.17-svn Platform: PC URL: http://wiki.smallbusiness-webdesign.de/index.php/Spezi al:Version OS/Version: Windows Vista Status: NEW Severity: normal Priority: Normal Component: Vector Skin AssignedTo: tpars...@wikimedia.org ReportedBy: j...@jans-seite.de CC: asha...@wikimedia.org Created attachment 7894 -- https://bugzilla.wikimedia.org/attachment.cgi?id=7894 Special:Version in Vector skin with extensions enabled In my wiki the css seems not to work in the Vector and Monobook skin but it works in the Modern skin. For tests I have disabled all extension but there is no change. There are three images as attachments: - Special:Version in Vector skin with extensions enabled - Special:Version in Vector skin with extensions disabled - Special:Version in Modern skin with extensions disabled -- 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 26276] No css seems not to work in Vector and Monobook skin
https://bugzilla.wikimedia.org/show_bug.cgi?id=26276 --- Comment #1 from Jan Luca j...@jans-seite.de 2010-12-07 20:24:11 UTC --- Created attachment 7895 -- https://bugzilla.wikimedia.org/attachment.cgi?id=7895 Special:Version in Vector skin with extensions disabled -- 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 26276] No css seems not to work in Vector and Monobook skin
https://bugzilla.wikimedia.org/show_bug.cgi?id=26276 --- Comment #2 from Jan Luca j...@jans-seite.de 2010-12-07 20:24:45 UTC --- Created attachment 7896 -- https://bugzilla.wikimedia.org/attachment.cgi?id=7896 Special:Version in Modern skin with extensions disabled -- 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 26276] No css seems not to work in Vector and Monobook skin
https://bugzilla.wikimedia.org/show_bug.cgi?id=26276 --- Comment #3 from Roan Kattouw roan.katt...@gmail.com 2010-12-07 20:25:49 UTC --- Have you run update.php? Can you link to your wiki? -- 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 22266] Hits not counted since Jan. 23, 2010
https://bugzilla.wikimedia.org/show_bug.cgi?id=22266 Diederik van Liere dvanli...@gmail.com changed: What|Removed |Added CC||dvanli...@gmail.com --- Comment #1 from Diederik van Liere dvanli...@gmail.com 2010-12-07 20:31:34 UTC --- Hi Nadia, Could you please elaborate or send the URL you are talking about? Else, I will close this report. Best, Diederik -- 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 26244] Tesla does funky things
https://bugzilla.wikimedia.org/show_bug.cgi?id=26244 --- Comment #7 from Platonides platoni...@gmail.com 2010-12-07 20:40:47 UTC --- (In reply to comment #4) SearchDbTest shows no errors, but: $ ./phpunit.php includes/ParserOptionsTest.php [.,,] Time: 1 second, Memory: 12.00Mb There was 1 error: 1) ParserOptionsTest::testGetParserCacheKeyWithDynamicDates MWException: Tried to create a ParserCache with an invalid memcached Here too. Fixed in r78009. Does it help with the other 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 3276] Give image gallerys fluid width
https://bugzilla.wikimedia.org/show_bug.cgi?id=3276
foma...@googlemail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||foma...@googlemail.com
Resolution|FIXED |
--- Comment #33 from foma...@googlemail.com 2010-12-07 21:15:00 UTC ---
r77411 has a problem on Firefox, when there is a floating object. It looks like
a clear:both. The old table-based gallery hasn't this problem.
div style=float:right; width:10em; height:10em; border: 1px solid
redBox/div
gallery
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
/gallery
r77411 defines
ul.gallery { display: inline-block }
It should define
ul.gallery { display: block }
--
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 2542] Tidy sucks (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=2542 Bug 2542 depends on bug 3276, which changed state. Bug 3276 Summary: Give image gallerys fluid width https://bugzilla.wikimedia.org/show_bug.cgi?id=3276 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | -- 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 3770] long words should be broken in image gallery descriptions
https://bugzilla.wikimedia.org/show_bug.cgi?id=3770 Bug 3770 depends on bug 3276, which changed state. Bug 3276 Summary: Give image gallerys fluid width https://bugzilla.wikimedia.org/show_bug.cgi?id=3276 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | -- 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 1] Documentation is out of date, incomplete
https://bugzilla.wikimedia.org/show_bug.cgi?id=1 Krinkle krinklem...@gmail.com changed: What|Removed |Added CC||krinklem...@gmail.com Version|1.13.x |unspecified -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 26244] Tesla does funky things
https://bugzilla.wikimedia.org/show_bug.cgi?id=26244 --- Comment #8 from Platonides platoni...@gmail.com 2010-12-07 23:57:39 UTC --- (In reply to comment #6) * It uses install.php to setup things from CLI Tried with an install.php generated LocalSettings. No change. * On Linux, there's no predefined order in which files are returned by file search, therefore tests are run in an unpredictable order. This matters if some tests aren't isolated enough (and we have plenty of such tests, I assure you) Actually there usually is a sorted order due to the use of trees in the filesystem implementing the folders. r78009 seem to have fixed the tesla 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 5942] Numbered list showing English numerals instead of Bengali numerals
https://bugzilla.wikimedia.org/show_bug.cgi?id=5942 Ragib Hasan ragibha...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Ragib Hasan ragibha...@gmail.com 2010-12-08 00:34:36 UTC --- I confirm that it works in Bengali Wikipedia. -- 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 26276] No css seems not to work in Vector and Monobook skin
https://bugzilla.wikimedia.org/show_bug.cgi?id=26276 --- Comment #4 from Reedy s...@reedyboy.net 2010-12-08 00:41:57 UTC --- (In reply to comment #3) Have you run update.php? Can you link to your wiki? I guess it's the one in the bug url? ;) Re the topic: You've got double negatives Do you mean No css seems to work on Vector and Monobook skin? -- 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 26246] User availability status extension
https://bugzilla.wikimedia.org/show_bug.cgi?id=26246 --- Comment #8 from Rehman rehman.wikime...@live.com 2010-12-08 00:51:42 UTC --- (In reply to comment #7) I think logging in/logging out is a good way to do it. But then, what about the two issues mentioned at the bottom of the proposal? If that's not solved, I'm quite sure many frequent editors would not see this feature as useful as it could be... -- 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 26244] Tesla does funky things
https://bugzilla.wikimedia.org/show_bug.cgi?id=26244 --- Comment #9 from Mark A. Hershberger m...@everybody.org 2010-12-08 01:17:05 UTC --- * On Linux, there's no predefined order in which files are returned by file search. Is this really different than the average developer's setup™?? Most devs I know use Linux. -- 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 26244] Tesla does funky things
https://bugzilla.wikimedia.org/show_bug.cgi?id=26244 --- Comment #10 from Mark A. Hershberger m...@everybody.org 2010-12-08 01:20:13 UTC --- fwiw, this rev (also?) helped me r78005 -- 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 25270] Review queues in CodeReview
https://bugzilla.wikimedia.org/show_bug.cgi?id=25270 p858snake p858sn...@gmail.com changed: What|Removed |Added CC||p858sn...@gmail.com --- Comment #10 from p858snake p858sn...@gmail.com 2010-12-08 01:36:51 UTC --- (In reply to comment #3) Reassigning this to myself, with Roan's permission. My plan is that we would have many review queues, each of them could be public or private. Each queue is merely a filter of different revisions. Why would we need/want private queues? the code is already public. -- 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 15515] Edits miscounted as pending after transwiki import
https://bugzilla.wikimedia.org/show_bug.cgi?id=15515 --- Comment #5 from Aaron Schulz jschulz_4...@msn.com 2010-12-08 05:18:33 UTC --- Tweaks made in r78044. -- 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 25757] Diff page loading seems to stall for logged-in users
https://bugzilla.wikimedia.org/show_bug.cgi?id=25757 Aaron Schulz jschulz_4...@msn.com changed: What|Removed |Added Severity|enhancement |minor -- 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 21526] Bug in Djvu text layer extraction
https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 Tim Starling tstarl...@wikimedia.org changed: What|Removed |Added CC||tstarl...@wikimedia.org --- Comment #14 from Tim Starling tstarl...@wikimedia.org 2010-12-08 06:06:54 UTC --- Deployed now. Note that the effect of create_function() is to create a global function with a random name and to return the name. Calling it in a loop will eventually use up all memory, because there is no way to delete global functions once they are created. For this reason alone, it shouldn't be used. But it is also slow, requiring a parse operation that is uncached by APC, and it's insecure in the sense that eval() is insecure: construction of PHP code can easily lead to arbitrary execution if user input is included in the code. -- 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 26276] No css seems to work on Vector and Monobook skin
https://bugzilla.wikimedia.org/show_bug.cgi?id=26276 Jan Luca j...@jans-seite.de changed: What|Removed |Added Summary|No css seems not to work in |No css seems to work on |Vector and Monobook skin|Vector and Monobook skin --- Comment #5 from Jan Luca j...@jans-seite.de 2010-12-08 06:13:18 UTC --- I have run update.php. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 5942] Numbered list showing English numerals instead of Bengali numerals
https://bugzilla.wikimedia.org/show_bug.cgi?id=5942
--- Comment #7 from Niklas Laxström niklas.laxst...@gmail.com 2010-12-08
07:23:02 UTC ---
You're not testing the same thing. Bengali Wikipedia has the following rule in
MediaWiki:Common.css:
ol{
list-style-type:bengali;
list-style-type:-moz-bengali;
}
However the rule I added to shared.css is:
ol:lang(bn) li {
list-style-type: -moz-bengali;
list-style-type: bengali;
}
--
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 15515] Edits miscounted as pending after transwiki import
https://bugzilla.wikimedia.org/show_bug.cgi?id=15515 --- Comment #6 from Aaron Schulz jschulz_4...@msn.com 2010-12-08 07:34:26 UTC --- More in 78051. -- 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
