[Bug 671] Whitelist non-problematic HTML tags: dfn samp kbd address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671 --- Comment #57 from Michael Zajac 2010-07-28 23:56:58 CDT --- (In reply to comment #56) > Aryeh, in Comment #52: > >> Definitely proper in HTML5 > >> http://www.w3.org/TR/html-markup/address.html > > > > Nope, definitely improper, see above. It represents contact info for the > > or it's in, not arbitrary contact info. > > You quoted too selectively. The rest of it is: "If an address element applies > to a section of a document, then it represents contact information for that > section only." I.e., the element (and I agree it's an odd one) represents > attribution, not arbitrary contact information, but it's scope is actually > undefined (it *defaults* to the whole document, but can be just a "section", > and the interpretation of that term is left open). I think the spec must have changed since that document was updated. In the latest version, it can only apply to an article or body element: > The address element represents the contact information for its nearest > article or body element ancestor. And the rules for determining the scope are specific. See http://www.whatwg.org/specs/web-apps/current-work/#the-address-element -- 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 24576] New namespaces for ml.wikisource
https://bugzilla.wikimedia.org/show_bug.cgi?id=24576 --- Comment #1 from sunil 2010-07-29 04:28:58 UTC --- Names in Malayalam (sucha as രചയിതാവ്) should be the Namespace name and the English names (such as Author) should be the aliases to their respective namespaces. 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 24576] New namespaces for ml.wikisource
https://bugzilla.wikimedia.org/show_bug.cgi?id=24576 p858snake changed: What|Removed |Added Keywords||shell CC||p858sn...@gmail.com -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24576] New: New namespaces for ml.wikisource
https://bugzilla.wikimedia.org/show_bug.cgi?id=24576 Summary: New namespaces for ml.wikisource Product: Wikimedia Version: unspecified Platform: All URL: http://ml.wikisource.org OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: vss...@gmail.com CC: me.prav...@gmail.com, sadik.kha...@gmail.com, shijualexonl...@gmail.com, junu...@gmail.com, kirangop...@gmail.com The following new namespaces may be created for ml.wikisource.org * Author = രചയിതാവ് * Author talk = രചയിതാവിന്റെ സംവാദം * Portal = കവാടം * Portal talk = കവാടത്തിന്റെ സംവാദം * Index = സൂചിക * Index talk = സൂചികയുടെ സംവാദം * Page = താൾ * Page talk = താളിന്റെ സംവാദം Link for local consensus http://ml.wikisource.org/wiki/%E0%B4%B5%E0%B4%BF%E0%B4%95%E0%B5%8D%E0%B4%95%E0%B4%BF%E0%B4%97%E0%B5%8D%E0%B4%B0%E0%B4%A8%E0%B5%8D%E0%B4%A5%E0%B4%B6%E0%B4%BE%E0%B4%B2:%E0%B4%B5%E0%B4%BF%E0%B4%95%E0%B5%8D%E0%B4%95%E0%B4%BF_%E0%B4%AA%E0%B4%9E%E0%B5%8D%E0%B4%9A%E0%B4%BE%E0%B4%AF%E0%B4%A4%E0%B5%8D%E0%B4%A4%E0%B5%8D_%28%E0%B4%B8%E0%B4%BE%E0%B4%99%E0%B5%8D%E0%B4%95%E0%B5%87%E0%B4%A4%E0%B4%BF%E0%B4%95%E0%B4%82%29#New_Namespaces_for_Malayalam_Wikisource -- 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 24575] New: Category and image description pages not purged from file cache or squid cache on link update
https://bugzilla.wikimedia.org/show_bug.cgi?id=24575 Summary: Category and image description pages not purged from file cache or squid cache on link update Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Page editing AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: tstarl...@wikimedia.org When someone adds or removes a category from a page, the relevant category page changes. And when someone adds or removes an image from a page, the relevant image description page changes, due to the list of file links. Cache updates for these changes are handled by LinksUpdate::invalidatePages(). However, this function does not update the HTML file cache (i.e. $wgUseFileCache=true), and it does not purge Squid. Thus, anonymous users see the old versions of categories and image description pages after an edit is made. The fix is made more complicated by the fact that neither of these updates should be done in the same transaction as the main link update. The link update transaction locks a lot of rows, and needs to be closed off as soon as possible. -- 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 671] Whitelist non-problematic HTML tags: dfn samp kbd address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671
--- Comment #56 from S. McCandlish 2010-07-29 01:30:26
UTC ---
Aryeh, in Comment #52:
>> Definitely proper in HTML5
>> http://www.w3.org/TR/html-markup/address.html
>
> Nope, definitely improper, see above. It represents contact info for the
> or it's in, not arbitrary contact info.
You quoted too selectively. The rest of it is: "If an address element applies
to a section of a document, then it represents contact information for that
section only." I.e., the element (and I agree it's an odd one) represents
attribution, not arbitrary contact information, but it's scope is actually
undefined (it *defaults* to the whole document, but can be just a "section",
and the interpretation of that term is left open). This was actually *less*
clear in HTML 4.01, which to my eyes suggested that it was only good for
whole-document attribution except maybe there was an exception, but what sort
of exception wasn't clear. I think that those working on HTML5 are clarifying
for the reality that "a web page" or "a document" in spec terms is, in "Web
2.0" days like these, often a conglomeration of a bunch of different and
different kinds of content from all sorts of sources, such that "section"-based
attribution is frequently necessary.
Michael in Comment #53:
> It's not as specific as one might want, since all contributors' addresses
> are applied to the entire page body, rather than each to its own comment,
> but that's a perfectly valid interpretation. From HTML5:
I'd say it's more specific than many users of address would normally think of,
since it associates content at a very detailed level with specific author
contact information. And it's non-problematic, since each contribution can be
considered a "section" for HTML5 spec purposes, for which the contribution's
author's user talk page, as you note, really is the relevant (i.e.,
non-arbitrary) contact information. Unless I've missed something here.
Aryeh in #52 again:
> But in the end, probably almost no one will use
> it correctly or incorrectly, so meh, whatever.
I concede that possibility. :-)
Aryeh in #52 again:
>> I wonder it we could actually expect editors to not put quotation marks
>> in manually, or have MW work around it if they do? Sounds problematic (and
>> again a good reason to fork that one into its own bug number).
>
> The idea is that they'll be auto-added in CSS
Right. I'm saying that the real-world implementation has been about
half-and-half, and it's been my experience that many people aware of the
element don't know it is supposed to (and fails to, in some browsers)
auto-generate the quotation marks (and specific types, based on language,
nesting, etc.) I'd bet real money that over half of the people who attempt to
use the q element put quotation marks just outside or inside it. So,
implementing it might be (aside from better discussed in a new bug page)
impractical until nothing but very obsolete browsers leave out the quotation
marks, and users get used to the idea of not adding them manually.
Christopher in Comment #54:
> The text in question is a relative link that happens to be reflexive. The
> engine detects that the link is reflexive so it renders the link as STRONG
> (instead of A). I would say it could convert the first reflexive link in the
> intro section of the article body to a DFN equally well, therefore allowing
> DFN is not necessary for this use case. The advantage is that the link uses
> wiki syntax, not HTML syntax.
This presumes that all cases of a reflexive link are defining instances, which
isn't true at all (I'd bet that in the Template namespace there are several
thousand such links that are not defining instances, but simply part of misc.
sentences in template documentation, because of widespread use of {{tl}},
{{tlx}}, etc. It would play havoc with transclusions, too. Basically, we
cannot guarantee any connection between definingness of an instance and
reflexive linking. We can't even 100% guarantee that bold stuff at or near the
top of an article is a defining instance of a term (e.g. list articles often
start with "This is a '''list of whatever'''", and "list of whatever" isn't a
term we're defining. The term is "whatever", and it is defined not at this
instance, but at the main article on the topic that the list is a
[[WP:SUMMARY]] offshoot of. I can think of other issues, but the several
already presented are enough to demonstrate that we cannot simply
operator-overload the linking code to turn all reflexive links into dfn's.
ABX in comment #55:
> How would that work for wiktionaries, wikispecies, wikisources with OCR of
> old encyclopedias and all other places where main definition is placed
> differently than in pedia?
It wouldn't. This is something that, like *almost* everything else in Wiki,
actually needs human judgment applied to it and is best handled with a
template.
--
Configure bugmail: https://bugzilla.wikimedia.org/userp
[Bug 3401] Dealing with non unicode aware browsers part 2
https://bugzilla.wikimedia.org/show_bug.cgi?id=3401 --- Comment #3 from peter green 2010-07-29 00:25:26 UTC --- netscape 4.x was added to the blacklist some time ago. The other browsers don't seem to be causing any problems in practice (I guess the number of users trying to edit from text mode on non utf-8 unix systems is minimal) so this can probablly be closed. -- 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 24542] Create globalsysops-l mailing list to be used by global sysops and stewards
https://bugzilla.wikimedia.org/show_bug.cgi?id=24542 --- Comment #5 from Jyothis Edathoot 2010-07-28 23:55:21 UTC --- This list needs to include both Stewards and Global Sysops. -- 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 24237] SimpleSearch Suggestions match highlighting broken
https://bugzilla.wikimedia.org/show_bug.cgi?id=24237 Derk-Jan Hartman changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #11 from Derk-Jan Hartman 2010-07-29 01:12:20 CEST --- Ok, it's a lot better now. But try this: "Doctor Who (TV series" result Doctor Who (TV series -- 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 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #203 from Philippe Verdy 2010-07-28 22:18:49
UTC ---
May I even suggest that the name of the new column does not even use "sortkey"
i.e. "cl_sort_prefix" instead of "cl_sortkey_prefix"
Why? because this column should NEVER need to convert that prefix itself to a
binary sortkey, it should just still be the humane-readable prefix that was
specified in {{DEFAULTSORT:sort_prefix}} or in [[Category:...|sort_prefix]].
This will avoid confusion, but it will also allow simpler recomputing of actual
sortkeys for various locales, without having to parse the page again for each
locale:
Note that when evaluating and expanding the parameters of
{{DEFAULTSORT:sort_prefix}} and of [[Category:...|sort_prefix]] in the wiki
code of a page (or when transcluding templates), the result text should NEVER
depend on the UI language (so if {{int:lang}} is used in that parameter, it
should evaluate always as if it was {{CONTENTLANGUAGE}}).
--
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 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #202 from Philippe Verdy 2010-07-28 22:06:54 UTC --- I would suggest instead making those proposals in the CLDR project. It already contains lots of data for many languages, related to their expected "sort order" (in fact more generally about their collation). Go to http://www.unicode.org/cldr and visit the existing ressources browser, and the demo of ICU which uses the same data. Our collator should "in fine" use the CLDR tailorings that are already defined, with very minor changes (if they are really needed). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 2482] Special:Import needs to produce log entries for RC
https://bugzilla.wikimedia.org/show_bug.cgi?id=2482 Adam Miller changed: What|Removed |Added CC||gti...@gmail.com --- Comment #2 from Adam Miller 2010-07-28 22:04:14 UTC --- *** Bug 24410 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24410] Serach field problems with whitespace prefix
https://bugzilla.wikimedia.org/show_bug.cgi?id=24410 Adam Miller changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Adam Miller 2010-07-28 22:04:14 UTC --- yeah this is fixed. *** This bug has been marked as a duplicate of bug 2482 *** -- 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 24350] Simplesearch breaks suggestions on vector when disabled
https://bugzilla.wikimedia.org/show_bug.cgi?id=24350 Adam Miller changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Adam Miller 2010-07-28 21:58:30 UTC --- i added it...r70117. Not sure it was needed, but it also doesn't seem to break anything. -- 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 4521] Colon (:) & semicolon (;) shouldn't output as HTML definition list when used for indentation, boldfacing
https://bugzilla.wikimedia.org/show_bug.cgi?id=4521 --- Comment #31 from S. McCandlish 2010-07-28 21:45:46 UTC --- That would work for me too, provided that the corresponding case of ";" without accompanying ":" be treated as a div with class="indent boldface" or whatever, so that both abuses of def. list markup are fixed. PS: If you find that, when you are actually using ";" and ":" for def. lists, that you can't get the layout you want, try using explicit dl, dt, dd markup, and the problems go away (see [[WP:MOSGLOSS]] for details). http://www.savetubevideo.com";>download video http://www.savetubevideo.com";>download video http://www.savetubevideo.com";>download video -- 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 24574] New: Sort order in Special:ListUsers should be case-insensitive
https://bugzilla.wikimedia.org/show_bug.cgi?id=24574 Summary: Sort order in Special:ListUsers should be case-insensitive Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: gnu1...@arcor.de Until now Special:ListUsers sorts Users in this way: AAA, AAB, ..., ABC, ..., AZZZ,AAa,AAb,...Az,...,AZ,...,Aaa,... In short: the aaa-Usernames, differing only in upper-/lowercase-letters appear in 2^3=8 total different places of the log. It should be AAA,AAa,AaA,Aaa,... The ranking depending on upper-/lowercase-letters makes it nearly impossible for Oversights to do a efficient search for libelous Usernames: The vandal only has to create the same name over and over again with different combinations of upper-lower-case letters and the bureaucrat/oversight has to search in dozens of places in the logfiles. -- 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 24573] New: Indent button not working.
https://bugzilla.wikimedia.org/show_bug.cgi?id=24573 Summary: Indent button not working. Product: MediaWiki extensions Version: any Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: Normal Component: FCKeditor AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mrs...@gmail.com I enabled the indent/outdent buttons on my installation. When I click the indent button on the toolbar, the editor actually shows the text indented, but when I look at the wikitext behind the gui, the ':' is not actually there. To verify behavior, I actually save the article and resulting text is not indented. -- 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 23888] Support WebM (matroska/VP8/libogg)
https://bugzilla.wikimedia.org/show_bug.cgi?id=23888 --- Comment #3 from Derk-Jan Hartman 2010-07-28 21:34:26 CEST --- So next to do is added a MatroskaHandler and a Matroska Metadataextracter + parser. It is probably also best is we move the 'player' functionality from OggHandler into a core VideoHandler, of which both OggHandler and MatroskaHandler would be children. Adding mdale and Tim to the ticket, since both seem relevant to such a move. -- 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 23888] Support WebM (matroska/VP8/libogg)
https://bugzilla.wikimedia.org/show_bug.cgi?id=23888 --- Comment #2 from Derk-Jan Hartman 2010-07-28 21:24:55 CEST --- Upload support and filetype recognition added in r70103. -- 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 24572] File with empty link= has no title/tooltip
https://bugzilla.wikimedia.org/show_bug.cgi?id=24572 Siebrand changed: What|Removed |Added CC||s.mazel...@xs4all.nl Version|unspecified |1.17-svn -- 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 24572] New: File with empty link= has no title/tooltip
https://bugzilla.wikimedia.org/show_bug.cgi?id=24572 Summary: File with empty link= has no title/tooltip Product: MediaWiki Version: unspecified Platform: All URL: http://translatewiki.net/w/i.php?title=Translating:New _project&oldid=2190741 OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Images and files AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: s.mazel...@xs4all.nl CC: gpaum...@wikimedia.org, bryan.tongm...@gmail.com, innocentkil...@gmail.com Adding a linkless file with "link=" will result in a file display without a title attribute. Steps: 1. add a file like the following to a wiki page: [[File:Crystal Clear app ksmiletris.png|64px|Alt text|link=]] Observed: http://translatewiki.net/w/images/thumb/Crystal_Clear_app_ksmiletris.png/64px-Crystal_Clear_app_ksmiletris.png"; alt="Alt text"> Expected: title attribute with value "Alt text"; http://translatewiki.net/w/images/thumb/Crystal_Clear_app_ksmiletris.png/64px-Crystal_Clear_app_ksmiletris.png"; alt="Alt text" title="Alt text"> This would show a title/tooltip even if there is no link. -- 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 24564] Fatal errors when using xxlimit=max
https://bugzilla.wikimedia.org/show_bug.cgi?id=24564 Raimond Spekking changed: What|Removed |Added CC||ap...@apper.de --- Comment #8 from Raimond Spekking 2010-07-28 15:28:02 UTC --- *** Bug 24571 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24571] "Internal error" on API request, when rvlimit=max
https://bugzilla.wikimedia.org/show_bug.cgi?id=24571 Raimond Spekking changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Raimond Spekking 2010-07-28 15:28:02 UTC --- *** This bug has been marked as a duplicate of bug 24564 *** -- 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 24571] New: "Internal error" on API request, when rvlimit=max
https://bugzilla.wikimedia.org/show_bug.cgi?id=24571 Summary: "Internal error" on API request, when rvlimit=max Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: Normal Component: API AssignedTo: roan.katt...@gmail.com ReportedBy: ap...@apper.de CC: bryan.tongm...@gmail.com, s...@reedyboy.net, vasi...@gmail.com, soxre...@gmail.com Please have a look at http://de.wikipedia.org/w/api.php?action=query&prop=revisions&pageids=4989893&rvprop=user&rvlimit=max The error is: "Exception Caught: Internal error in ApiResult::setElement: Attempting to add element revisions=500, existing value is 500" (or 5000 instead of 500, when you're a sysop) rvlimit=max doesn't seem to work anymore -- 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 24570] Request: add a "Sign gloss" namespace to en.wiktionary.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=24570 msh210 changed: What|Removed |Added CC||m.ham...@alumni.nyu.edu --- Comment #1 from msh210 2010-07-28 15:24:19 UTC --- More durable URL: http://en.wiktionary.org/?oldid=9560068#Proposal_for_a_new_namespace:_.22Sign_Gloss:.22 -- 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 24570] Request: add a "Sign gloss" namespace to en.wiktionary.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=24570 Huib abigor Laurens changed: What|Removed |Added Keywords||shell CC||abi...@forgotten-beauty.com -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24570] New: Request: add a "Sign gloss" namespace to en.wiktionary.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=24570 Summary: Request: add a "Sign gloss" namespace to en.wiktionary.org Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: benjamin.m.schwa...@gmail.com As per the conversation at: http://en.wiktionary.org/wiki/Wiktionary:BP#Proposal_for_a_new_namespace:_.22Sign_Gloss:.22 we have apparent consensus in favor of the creation of a new namespace named "Sign gloss" in en.wiktionary.org. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24569] New: HTML output mishmash for within list item
https://bugzilla.wikimedia.org/show_bug.cgi?id=24569
Summary: HTML output mishmash for within list item
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Keywords: need-parsertest, parser
Severity: normal
Priority: Normal
Component: Page rendering
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: dann...@email.cz
Given wikisyntax input
* foo
* bar
*
loirem
ipsum
dolor
sit
amet
* baz
* qux
Expected HTML output (padding by myself to emphasize the structure)
foo
bar
loirem
ipsum
dolor
sit
amet
baz
qux
Current HTML output (padding by myself to emphasize the structure)
foo
bar
loirem
ipsum
dolor
sit
amet
baz
qux
Applies to # list as well.
Applies to {{#tag:poem}} as well.
--
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 22881] Greatly improved Export and Import for 1.14.1 (will port into trunk if needed)
https://bugzilla.wikimedia.org/show_bug.cgi?id=22881 Reedy changed: What|Removed |Added Attachment #7222|application/octet-stream|text/plain mime type|| Attachment #7222|0 |1 is patch|| -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 22881] Greatly improved Export and Import for 1.14.1 (will port into trunk if needed)
https://bugzilla.wikimedia.org/show_bug.cgi?id=22881 Reedy changed: What|Removed |Added Attachment #7222|0 |1 is obsolete|| -- 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 24568] New: Javascript error
https://bugzilla.wikimedia.org/show_bug.cgi?id=24568 Summary: Javascript error Product: Wiktionary tools Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: General AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mahi...@gmail.com Created an attachment (id=7602) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7602) Tamil wiktionary bug in monobook.js Have a minor error in Tamil wiktionary http://ta.wiktionary.org/ in monobook.js before ==URL Fixes== it needs to add "/*" before this line at # 195 Please fix 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 22881] Greatly improved Export and Import for 1.14.1 (will port into trunk if needed)
https://bugzilla.wikimedia.org/show_bug.cgi?id=22881 --- Comment #8 from Vitaliy Filippov 2010-07-28 12:21:57 UTC --- Created an attachment (id=7601) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7601) Patch for Trunk MediaWiki (svn70079) Good news everyone ! :-) I ported my patch to MediaWiki 1.17 trunk (svn revision 70079). Can you give it some review 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 24481] Tab "Move" should be visible in Vector skin - copyright issue
https://bugzilla.wikimedia.org/show_bug.cgi?id=24481 --- Comment #5 from Leinad 2010-07-28 12:00:32 UTC --- > What I meant was: is there any data that supports this notion? Sorry, but I'm not a data analyst, I'm admin of Polish Wikipedia, who regularly patrolling RC and I see what's going on. -- 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 24564] Fatal errors when using xxlimit=max
https://bugzilla.wikimedia.org/show_bug.cgi?id=24564 --- Comment #7 from Brad Jorsch 2010-07-28 11:44:24 UTC --- I was going to suggest changing it to $generator->extractRequestParams( false ) and $module->extractRequestParams( false ) in ApiQuery.php, but I guess that works. Your version also causes bug 21310 to be broken in a different, less annoying way. -- 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 24564] Fatal errors when using xxlimit=max
https://bugzilla.wikimedia.org/show_bug.cgi?id=24564 Bryan Tong Minh changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #6 from Bryan Tong Minh 2010-07-28 11:33:00 UTC --- Fixed in r70078, needs deployment. -- 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 24564] Fatal errors when using xxlimit=max
https://bugzilla.wikimedia.org/show_bug.cgi?id=24564 --- Comment #5 from Bryan Tong Minh 2010-07-28 11:17:45 UTC --- The problem is: 1) ApiMain::execute calls extractRequestParams with $parseLimit = true 2) The limit=max gets parsed and added to the result 3) ApiQueryBacklinks::run calls extractRequestParams with $parseLimit = false 4) ApiQueryBacklinks::run calculates its own limit and adds that to the result I will make a fix where for limits calls overwriting is allowed. -- 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 24533] Enable & install whole reveiwer system or extensions on hindi wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24533 --- Comment #6 from mayurkumar 2010-07-28 10:36:42 UTC --- Now if flag rev system is same as reveiwer system then include Bug 24536 with this bug and install or enable *flagged protection too *FlaggedRevs custom configuration ** 1 parameter with 3 levels (unapproved/sighted/reviewed) ** Display latest reviewed version ** Flag all spaces ** Reviewers may set all levels and give following rights to reveiwer *Edit semi-protected pages (autoconfirmed) *Have one's own edits automatically marked as "checked" (autoreview) *Mark revisions as being "checked" (review) *Mark revisions as being "quality" (validate) *View recent changes patrol marks (patrolmarks) *View the list of unreviewed pages (unreviewedpages) *Mark others' edits as patrolled (patrol) -- 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 24567] New: Allow backreferences in Search and replace dialog
https://bugzilla.wikimedia.org/show_bug.cgi?id=24567 Summary: Allow backreferences in Search and replace dialog Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: platoni...@gmail.com CC: roan.katt...@gmail.com, ngau...@wikimedia.org, amil...@wikimedia.org Search and replace dialog in regex mode should allow the use of backreferences. Primarily on the replacer, but there's probably an use case for having them in the search string, too. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24566] New: Search and replace dialog is not well suited for find next / replace next
https://bugzilla.wikimedia.org/show_bug.cgi?id=24566 Summary: Search and replace dialog is not well suited for find next / replace next Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: platoni...@gmail.com CC: roan.katt...@gmail.com, ngau...@wikimedia.org, amil...@wikimedia.org Search and replace dialog appears modal over the page, which gets obscured. This means among other things that the user cannot change the textarea while the dialog is open. This is not a problem for Replace all, but when the user is doing find next / replace next, the text is hard to view, and cannot be scrolled or unmodified (to back out one replace next, change the focus to skip the point where it continues...). -- 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 24533] Enable & install whole reveiwer system or extensions on hindi wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24533 --- Comment #5 from mayurkumar 2010-07-28 10:09:42 UTC --- You can also watch reveiwer's media wiki files at english wiki link-http://en.wikipedia.org/w/index.php?limit=500&title=Special%3AAllMessages&offset=Revreview-hist-basic-user&prefix=revr&filter=all&lang=en to be installed or enable.Without these a reveiwer user is of no use and our purpose can not get resolved.So please install above mentioned media wiki links file in hindi wiki and give following rights to reveiwer group *Edit semi-protected pages (autoconfirmed) *Have one's own edits automatically marked as "checked" (autoreview) *Mark revisions as being "checked" (review) *Mark revisions as being "quality" (validate) *View recent changes patrol marks (patrolmarks) *View the list of unreviewed pages (unreviewedpages) *Mark others' edits as patrolled (patrol) I hope this issue will be resolved aas early as possible, thanks to buzilla team for helping us Regards Mayur kumar(admin hi wiki) -- 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 22093] Native Microsoft SQL Server Support
https://bugzilla.wikimedia.org/show_bug.cgi?id=22093 --- Comment #22 from Max Semenik 2010-07-28 09:39:23 UTC --- (In reply to comment #21) > I've gone through and reverted the whitespace changes caused by stylize.php Thanks, looks much clearer now. -- 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 24564] Fatal errors when using xxlimit=max
https://bugzilla.wikimedia.org/show_bug.cgi?id=24564 --- Comment #4 from Tim Starling 2010-07-28 07:57:50 UTC --- Too late, it's released now. -- 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 24565] API public cache header vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=24565 Tim Starling changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24564] Fatal errors when using xxlimit=max
https://bugzilla.wikimedia.org/show_bug.cgi?id=24564 OverlordQ changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #3 from OverlordQ 2010-07-28 07:53:26 UTC --- Re-opening as problem still occurs[1] if using generators as pointed out[2] in the mailing list. 1 - http://en.wikipedia.org/w/api.php?gbltitle=American&prop=info&action=query&generator=backlinks&gbllimit=max 2 - http://lists.wikimedia.org/pipermail/mediawiki-api/2010-July/001896.html -- 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 24565] New: API public cache header vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=24565 Summary: API public cache header vulnerability Product: MediaWiki Version: 1.15.4 Platform: All OS/Version: All Status: NEW Severity: major Priority: Normal Component: API AssignedTo: tstarl...@wikimedia.org ReportedBy: tstarl...@wikimedia.org CC: bryan.tongm...@gmail.com, s...@reedyboy.net, vasi...@gmail.com, soxre...@gmail.com The API (api.php) in previous versions of MediaWiki sends private cache headers by default for almost all API operations, but allows public cache headers to be sent if they are requested via URL or POST data parameters. We have discovered that this policy allows leakage of private data, if an attacker can access the wiki through the same caching HTTP proxy as the victim user. A user's browser can be tricked into requesting private data with public caching headers, via a CSRF-style attack on an external web page. The attacker would cause the victim's browser to request private data with public caching headers, then the attacker would download the same data from the intermediate HTTP proxy, bypassing access controls. The kinds of things that may be leaked by this bug are: * Article titles and contents (if these are restricted) * The contents of deleted articles * User email addresses * User watchlists The following types of data are not affected and cannot be leaked by this bug: * User passwords * Session IDs * The contents of uploaded files The main mitigating factor is the need for an HTTP proxy to be shared between the victim and the attacker. However, we believe that some hosting providers use caching HTTP proxies to improve performance, without informing their users that they are doing so. Thus we advise all MediaWiki users to upgrade, unless they control both the server and the network path to the wiki's users, and are convinced that there are no HTTP proxies on that network path. Our fix will be included in MediaWiki 1.15.5 and 1.16.0. The following versions are affected: * All versions from MediaWiki 1.8 to 1.14. Note that in MediaWiki 1.8, the API was disabled by default, this would mitigate the attack. * MediaWiki 1.15.0 to 1.15.4. * All beta versions in the MediaWiki 1.16 series. Our fix is comprehensive: it disables public caching for all API modules except those which explicitly declare their data to be public. On private wikis, all responses will be marked private. -- 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
