[Bug 24542] Create globalsysops-l mailing list to be used by global sysops and stewards
https://bugzilla.wikimedia.org/show_bug.cgi?id=24542 Reedy changed: What|Removed |Added AssignedTo|wikibug...@lists.wikimedia. |cb...@wikimedia.org |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 11267] User should be able to set fallback language(s) in preferences
https://bugzilla.wikimedia.org/show_bug.cgi?id=11267 --- Comment #11 from Purodha Blissenbach 2010-07-26 06:01:10 UTC --- (In reply to comment #10) > Well, there are some local messages used on some wikis, which are not part of > MediaWiki core or its extensions, so such fallback is not nonsense in general, > however those are rare cases. Well, there is a fallback for missing messages: This assures, no message goes undisplayed, even if may be not functioning is some very special contexts, and for those "messages" of a more technical nature, that are not plainly displayed or sent out as e-mails. Btw: One of the disadvantages of our current language (and fallback) treatment is, we cannot choose to have this fallback. Being able to ?uselang=und (undefined) or ?uselang=zxx (no linguistic content) would imho be a great help to localizers who happen to stumble over messages having typing errors, or not translated optimally regarding context. Redisplaing a wiki page with messages replaced by usually tells you at once, which message to amend. Currently, localizers have to find messages via text searches in the message contents, which is cumbersome for text made up from several messages, and at least is quite time consuming. -- 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 24348] Semantic Datas get passed over from one Article to another
https://bugzilla.wikimedia.org/show_bug.cgi?id=24348 Daniel Werner changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- 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 24348] Semantic Datas get passed over from one Article to another
https://bugzilla.wikimedia.org/show_bug.cgi?id=24348 --- Comment #3 from Daniel Werner 2010-07-26 05:53:44 UTC --- Now I was able to solve the problem. The problem was not a SMW bug, it was provoked by a bug in the Variables Extension, Array Extension and HashTables Extension. Variables defined there were like superglobals in case of some job queue updates, semantic updates and page import. I thought I checked for this bug already but I had some unexpected behavior so my test at the first time was negative untill I found some strange behavior on my last page import. I fixed this bug in all of the three extensions above. Everybody using those extensions (especially together with SMW) should update them. -- 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 24542] New: Create globalsysops-l mailing list to be used by global sysops and stewards
https://bugzilla.wikimedia.org/show_bug.cgi?id=24542 Summary: Create globalsysops-l mailing list to be used by global sysops and stewards Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Mailing lists AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mill...@gmail.com The list should have closed subscription, but public archives. Ad me as an admin initially, while I suppose that some others would become list admins, too. -- 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 15491] ins or del 1st occurrence in blockquote causes bogus newline
https://bugzilla.wikimedia.org/show_bug.cgi?id=15491 --- Comment #6 from S. McCandlish 2010-07-25 21:45:29 UTC --- Aryeh: Fair enough, but your argument assumes that screen reader users will go with the defaults. For purely presentational markup, that's a "safe" option generally (vision impaired users are unlikely to care if something is italicized [as opposed to emphasized]. But not customizing at least some of the more important semantic elements will lead to confusing, even total gibberish output, especially in the case of del and ins. Ergo, it seems a very long bet that experienced screen reader users do not customize them to work around such 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 671] Whitelist non-problematic HTML tags: dfn samp kbd address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671 --- Comment #51 from S. McCandlish 2010-07-25 21:31:04 UTC --- * On dfn and address: --- Comment #49 from Aryeh Gregor 2010-07-25 18:39:44 UTC --- > [reasonable summary of the debate, elided] > Counter-counter-counter-argument: . . . :( Right. It may not be helpful in places like this to play devil's advocate, since the other side is liable to take it seriously and argue against the position. :-/ > Phrased thus, I can see no serious argument for not whitelisting these tags. > It makes things more consistent if anything. I'll get some other developers' > opinions, and if no one objects, I'll go ahead and whitelist and > . Huzzah! * On kbd + samp --- Comment #49 from Aryeh Gregor 2010-07-25 18:39:44 UTC --- > As for and , we may as well wait until that HTML5 bug is > resolved, which should be within a few months. This has waited 5.5 years, > so a few months more won't kill anyone. Works for me. At this point I'd sacrifice a goat or something to get even half of this resolved. * On other stuff: --- Comment #48 from Christopher Yeleighton 2010-07-25 08:42:53 UTC --- > http://en.wikipedia.org/w/index.php?title=Newt_Gingrich&oldid=375340399 Why would we do that? The text is question isn't a link, so it shouldn't be marked up as one. And doing so wouldn't fix anything, since there isn't anything in that syntax or its [mis]use that tells the parser "this is the defining instance", something that requires human judgment. --- Comment #49 from Aryeh Gregor 2010-07-25 18:39:44 UTC --- > It doesn't really matter, but you're not supposed to remove > blocking/dependencies once they're fixed. They're supposed to stay there. My bad. In my own uses of Bugzilla, we've simply removed dependencies after they become moot. Didn't realize WMF's wanted to keep them. I can see where it could be useful in a project this complex (fixed bugs show up struck-through, but can still be accessed, e.g. because maybe one wasn't fully fixed with regard to a blocked bug and needs re-opening). But one of them here is not, because this bug was listed as blocking another because of the abbr element, but that element has been whitelisted *and removed from this bug*, so this bug is no longer relevant to the other at all. > My proposal there doesn't affect . Right. Should have written "Aryeh's proposal over there about two of them". HTMLWG: Okay, I can concede on that, if your HTML5 proposal is rejected AND you appeal the rejection AND the appeal looks like it might go somewhere. I would not want us to postpone implementation of kbd and samp for a year or more otherwise, though. Kind of a WP:SNOWBALL thing, really. But, I've already agreed that if there's genuine uncertainty, they shouldn't be implemented. --- Comment #50 from Michael Zajac 2010-07-25 18:53:33 UTC --- > Regarding use cases for the address element, I forgot to mention the best one: > to mark up a talk-page user sig. Definitely proper in HTML5 http://www.w3.org/TR/html-markup/address.html Some might question this application in HTML 4.01/XHTML 1.0 http://www.w3.org/TR/REC-html40/struct/global.html#edef-ADDRESS since it vaguely refers to "a major part" of a page, whatever that means. HTML5 just says "section", which can be whatever you want it to be without any "major" or "minor" value-judgment baggage. Do we care? * On q in HTML5 having auto-generated quotation marks Ick. 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). -- 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 4521] Colon (:) & semicolon (;) shouldn't output as HTML definition list when used for indentation, boldfacing
https://bugzilla.wikimedia.org/show_bug.cgi?id=4521 S. McCandlish changed: What|Removed |Added Summary|Colon (:) should not output |Colon (:) & semicolon (;) |as HTML definition list |shouldn't output as HTML |when used for indentation |definition list when used ||for indentation, boldfacing --- Comment #29 from S. McCandlish 2010-07-25 21:10:28 UTC --- Updating bug title to reflect related problem. Colon is output as a definition list definition (dd element), and semicolon, often abused for boldfacing and creating pseudo-headings, outputs a definition list term (dt element). Both of these should be replaced with CSS, at least if they are not in an actual definition list. There are three ways to handle this: 1) Stop connecting this wikimarkup in any way to definition lists (which would have to be HTML-coded manually, like blockquotes and various other things that MediaWiki doesn't have special wikimarkup for). 2) Have the parser test the conditions of the markup, such that if the material is formatted like: ;A1 :A2 ;B1 :B2 it is treated as a definition list, but if it has blank lines between any of these, or a ; without one or more :'s or vice versa, or otherwise doesn't fit this pattern, treat it as CSS-styled, non-list text. 3) Always treat this markup as CSS-style regular prose, unless it is inside an explicit HTML dl element, in which case always treat it as a definition list (regardless of whitespacing and regardless of missing definitions or terms). 4) Or some combination of these. I'm marginally against option 1, and feel that 3 should usually apply (always apply in the case of explicit dl markup), but can't see anything wrong with MW doing some very limited guesswork as in option 2. -- 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 22621] Improve stylize.php brace handling/addition
https://bugzilla.wikimedia.org/show_bug.cgi?id=22621
Reedy changed:
What|Removed |Added
Summary|Improve stylize.php to add |Improve stylize.php brace
|braces etc |handling/addition
--- Comment #1 from Reedy 2010-07-25 20:25:30 UTC ---
Would be nice if it could also change
if ( $blah )
{
$doSomething();
}
into
if ( $blah ) {
$doSomething();
}
--
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 24529] Incrementally remove support for HTML elements removed from or deprecated in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=24529
--- Comment #3 from Aryeh Gregor 2010-07-25
20:17:24 UTC ---
(In reply to comment #2)
> The tt element and other simple cases can be fixed in the wikicode with AWB
> and
> other scripting tools and bots, after being fixed in engine to not actually
> reach the user agent as a tt element, but a span with monospaced font. On
> installations other than Wikipedia, they'll need to write their own (or adapt
> WP's) tools, or fix it manually.
If people step up who are willing and able to fix all the breakage, I don't
mind disabling support in the software. But not before all existing uses are
removed, and people commit to fixing any stragglers.
> I'm not sure that allowing the tt element in the wikicode is a huge deal. We
> also allow br elements without a closing / in them
Which is allowed in HTML5.
> we allow the p element without a closing /p tag
Which is allowed in HTML5.
> I think that tt should be removed from the editor-facing
> documentation, so that new instances of it are not added to the wikicode,
> willynilly, forever. The help pages on editing should direct users to a
> {{monospace}} template or something (which would use the span and
> font-family).
I agree, but of course, this isn't the right place to ask. It's a wiki, change
it. :) (Or get consensus, whatever.)
> For HTML5-verboten attributes... Yeah, that'll be big fun. I don't have any
> particular ideas with regard to table stuff especially.
That's much harder, yeah. Of course, it wouldn't be a big deal if people would
just not use presentational tables, but good luck with that one . . .
--
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 15607] Implement the Interlanguage extension in Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=15607 --- Comment #41 from Nikola Smolenski 2010-07-25 20:07:01 UTC --- I have solved the problem of automatic updates. I have made another extension, called Interlanguage Central extension, that works in pair with Interlanguage extension and purges appropriate pages on dependent wikis when interlanguage links are changed on the central wiki. The source code is on http://www.mediawiki.org/wiki/Extension:Interlanguage#Source and it is installed on http://testwiki.smolenski.rs -- 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 24519] RevDel'd imported edits may be blanked
https://bugzilla.wikimedia.org/show_bug.cgi?id=24519 OpenTheWindows changed: What|Removed |Added Summary|RevDel'd transwikied edits |RevDel'd imported edits may |may be blanked |be blanked -- 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 24519] RevDel'd transwikied edits may be blanked
https://bugzilla.wikimedia.org/show_bug.cgi?id=24519 --- Comment #2 from OpenTheWindows 2010-07-25 20:06:29 UTC --- Import from file is also affected. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24519] RevDel'd transwikied edits may be blanked
https://bugzilla.wikimedia.org/show_bug.cgi?id=24519 --- Comment #1 from OpenTheWindows 2010-07-25 20:05:01 UTC --- I have tested with export files. It correctly says that the revision is partly deleted. I'm testing with import from file. -- 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 24529] Incrementally remove support for HTML elements removed from or deprecated in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=24529
--- Comment #2 from S. McCandlish 2010-07-25 20:04:21
UTC ---
The tt element and other simple cases can be fixed in the wikicode with AWB and
other scripting tools and bots, after being fixed in engine to not actually
reach the user agent as a tt element, but a span with monospaced font. On
installations other than Wikipedia, they'll need to write their own (or adapt
WP's) tools, or fix it manually.
I'm not sure that allowing the tt element in the wikicode is a huge deal. We
also allow br elements without a closing / in them, we allow the p element
without a closing /p tag, etc., and it all gets fixed on the fly before it hits
the browser. I think that tt should be removed from the editor-facing
documentation, so that new instances of it are not added to the wikicode,
willynilly, forever. The help pages on editing should direct users to a
{{monospace}} template or something (which would use the span and font-family).
For HTML5-verboten attributes... Yeah, that'll be big fun. I don't have any
particular ideas with regard to table stuff especially.
--
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 24541] Unclosed (and presumably other formatting tags) reformat whole page
https://bugzilla.wikimedia.org/show_bug.cgi?id=24541 --- Comment #2 from Reedy 2010-07-25 19:47:14 UTC --- More reason to be able to edit comments? -- 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 24541] Unclosed (and presumably other formatting tags) reformat whole page
https://bugzilla.wikimedia.org/show_bug.cgi?id=24541 --- Comment #1 from Reedy 2010-07-25 19:46:10 UTC --- Created an attachment (id=7591) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7591) See more bad formatting! -- 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 24541] New: Unclosed (and presumably other formatting tags) reformat whole page
https://bugzilla.wikimedia.org/show_bug.cgi?id=24541 Summary: Unclosed (and presumably other formatting tags) reformat whole page Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: CodeReview AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: s...@reedyboy.net CC: innocentkil...@gmail.com Created an attachment (id=7590) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7590) See bad formatting! I put a but forgot to close it on a comment on r58150 It's reformatted the whole page to look strange See screenshots -- 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 23932] Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, figure, footer, header, hgroup, mark, nav, section, time
https://bugzilla.wikimedia.org/show_bug.cgi?id=23932 Michael Zajac changed: What|Removed |Added Summary|Enable, whitelist, and |Enable, whitelist, and |incorporate semantic HTML5 |incorporate semantic HTML5 |elements: article, aside, |elements: article, aside, |dialog, figure, footer, |figure, footer, header, |header, hgroup, mark, nav, |hgroup, mark, nav, section, |section, time |time -- 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 #50 from Michael Zajac 2010-07-25 13:53:33 CDT --- Regarding use cases for the address element, I forgot to mention the best one: to mark up a talk-page user sig. -- 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 #49 from Aryeh Gregor 2010-07-25 18:39:44 UTC --- Sigh. Okay, frankly, I wasn't really so much against whitelisting these, and I was mostly just responding to particular arguments that I thought were unreasonable, and to some degree playing devil's advocate. In my view, the issue basically boils down to this: Argument in favor of whitelisting: They're not very useful, but they're practically the only HTML elements we don't whitelist, and it won't hurt anything. We already whitelist similarly marginal elements like and . So what's the point in not whitelisting these? Counter-argument: Wikitext is not meant to be HTML. It's meant to be a simplified language that non-technical users can easily learn, without unnecessary features that might be confusing. We don't have to allow everything that HTML does -- wikitext serves a different purpose from HTML, and it's completely reasonable for us to draw the line at a different place. Since wikitext aims to be simplified, any new language construct needs to be concretely justified. Counter-counter-argument: So it's okay to allow , but is too confusing? Not to mention the fact that we have template syntax which causes grown men to break down into uncontrollable sobbing, and on several well-documented occasions has caused onlookers to spontaneously gouge their eyes out in sheer horror. But , oh no, that's just way too complicated. Especially what with how and have been whitelisted for a long time, and they've demonstrably caused the total collapse of the Wikipedia user base as we know it, what with everyone using them all over the place. Come on, get real. Counter-counter-counter-argument: . . . :( Phrased thus, I can see no serious argument for not whitelisting these tags. It makes things more consistent if anything. I'll get some other developers' opinions, and if no one objects, I'll go ahead and whitelist and . As for and , we may as well wait until that HTML5 bug is resolved, which should be within a few months. This has waited 5.5 years, so a few months more won't kill anyone. I'll just respond to one or two points here: (In reply to comment #45) > HTML5 goes flip-flop about this. The version I have in memory cache says > quotation marks should be explicit inside Q. The current version says the opposite, and I think it has for a long time: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-q-element (In reply to comment #47) > We can concede that implementation of the kbd and samp pair is also > temporarily > problematic because of alleged uncertainty over at HTML5, and should thus > arguably be deferred in MW for the short term. Personally, I'm near certain > that Aryeh's HTML5 proposal won't succeed, because HTML5 has been moving > toward > significantly increased, not reduced, semantic tagging, and in 5 weeks it's > met > nothing but skepticism. Three (i.e., less than two more) months is probably > enough time to see which way that wind blows). The way the HTML5 bug tracker works is that everyone is free to comment, but the editor (Ian Hickson, a.k.a. Hixie) has the sole right to make a decision. Hixie normally handles bugs in batches every few months, so I expect he'll decide within a few months. When Hixie makes a decision, it can be appealed to the HTMLWG, which can take like a year, but most of his decisions are not appealed (and I certainly would not appeal whatever decision he makes here). So the people who have commented so far on the HTML5 bug are irrelevant (since it's Hixie's decision alone at this point), but it will be resolved definitively sooner or later. If he WONTFIXes, can add the elements at that point, if the developers agree on that now. > I'm not going to spend hundreds and hundreds of real dollars buying expensive > software to satisfy your nitpicking, especially since you seem so adamantly > opposed to this (alone among *all* active respondents on this thread, I might > add) that I doubt you'd be satisfied anyway. > > I'm also not going to spam around asking for blind users to send me copies of > their style sheets, for the same reason, and because interpreting them would > be > necessarily subjective and extremely time-consuming, and because I have more > productive things to do, and so do they, and surely so do you. That's fine, but then you should not have claimed that these things are "certain" or "nearly certain", since you have no actual evidence. I don't ask for you to invest any effort at all in testing anything, but I do ask that you accurately represent how well-supported your statements are. Note that JAWS has a trial version, so I managed to test it out in like ten minutes; and there are open-source screen readers too (see bug 15491 comment 4). > What is or isn't useful on Wikipedia itself isn't really of any concern here, > since this is open software. MediaWiki is much bro
[Bug 15491] ins or del 1st occurrence in blockquote causes bogus newline
https://bugzilla.wikimedia.org/show_bug.cgi?id=15491 Aryeh Gregor changed: What|Removed |Added Keywords|easy| --- Comment #5 from Aryeh Gregor 2010-07-25 18:34:58 UTC --- (BTW, I've looked at the code for this, and I don't think it's easy. Removing keyword.) -- 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 15491] ins or del 1st occurrence in blockquote causes bogus newline
https://bugzilla.wikimedia.org/show_bug.cgi?id=15491 --- Comment #4 from Aryeh Gregor 2010-07-25 18:34:27 UTC --- (In reply to comment #3) > ALL of them, as far as I know. I'm unaware of any screen reader that will do > anything with pure-presentation markup (b, i, u, s, font, etc.), which are > only > useful for [fully-]sighted user, unless the user overrides the default > behavior > of ignoring them. Screen readers generally *will* do something audibly > different with each sematic markup tag (again, unless overridden). Instead of > pestering me about this sort of thing bug after bug after bug, please just go > do some research on Web accessibility; this is honestly getting very tedious. I do know something (not a lot, I freely admit) about web accessibility. What I knew about screen readers made me believe that and would be treated the same. I just downloaded the JAWS trial version, and I have confirmed that without my reconfiguring anything, all markup like , , , , whatever seems to be totally ignored. Specifically, this page: data:text/html,TestHello when loaded in Firefox, is read as "One hundred percent. Page has no links. Test hello". It's read in exactly the same way if I replace by anything else, like or or or or . There is no change in tone or anything. "Foo bar baz quuz" is read as "Foo bar baz quuz". I don't blame you for not being willing to put in the work to test things. I also don't blame you for being overconfident and assuming that your knowledge of screen readers was correct. But I really have to object to the fact that when you made a statement without providing any supporting evidence, and were asked to provide evidence, your response was to tell *me* to do the research, in a condescending tone no less. If you do not have evidence, you should say so. Not having evidence beyond hearsay and rumor is fine, but you should not act as though your claims are well-supported and obviously correct when they are not. So, anyway, I did do the research. At least for this screen reader -- the most popular one in the world, in its default configuration as far as I can tell -- you are mistaken. If, again, you have specific evidence to the contrary, I would be interested in hearing it, just as a matter of general knowledge about screen readers. But in the future, I will continue to "pester" you and everyone else for evidence when you make claims that I suspect are incorrect. Of course, this is still a bug and should still be fixed. But correct conclusions do not justify erroneous arguments. -- 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 24525] [[Special:MyPage/skin.css]] doesnt refer to user's skin in he.wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=24525 --- Comment #2 from yonidebest 2010-07-25 17:43:40 UTC --- Peharps it should be built-it. Thanks, Derk-Jan. -- 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 24529] Incrementally remove support for HTML elements removed from or deprecated in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=24529 --- Comment #1 from Aryeh Gregor 2010-07-25 17:36:28 UTC --- I have no objection in principle to migrating away from using these somehow, so I agree that this bug should not be closed. However, there has to be some migration plan that does not force Wikipedia users to do unnecessarily large amounts of work, and someone has to code it up. These are obstacles that I suspect are prohibitive for the foreseeable future. It's conceivable that we could do some auto-translation of to and so forth, but that still leaves the invalid markup in the page source, so it's less than ideal. Note that it's not just elements here, but attributes too. For example, cellspacing="" and cellpadding="" are obsolete and invalid in HTML5 as well. The full list is here: http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#non-conforming-features We don't allow most of those anyway, but there are an awful lot we do currently permit. Some of them (particularly table attributes) cannot be easily, reliably, and automatically converted to use CSS. -- 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 23932] Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, dialog, figure, footer, header, hgroup, mark, nav, section, time
https://bugzilla.wikimedia.org/show_bug.cgi?id=23932 --- Comment #8 from Aryeh Gregor 2010-07-25 17:31:50 UTC --- Wikipedia's goal is to provide knowledge to everyone in the world, not just people whose browsers we like to work with. Giving significant numbers of people reduced functionality is okay if necessary, but breaking their use of the site is absolutely not okay. The goal of my comments in Bugzilla is to communicate with particular people, and if they have to actually follow the link to the bug report proper rather than reading my comments in their broken mail client, that's not a big deal to me. Wikimedia's Bugzilla has completely different goals from Wikipedia itself, and so different standards are entirely appropriate. -- 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 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #189 from Aryeh Gregor 2010-07-25
17:22:32 UTC ---
(In reply to comment #186)
> That'a a bad assumption : even the highest quality collations will need to be
> updated from time to time:
> - Unicode evolves and new characters get encoded (new versions are published
> about every 1-2 years after synchronization and final balloting at both ISO
> WG2
> and the UTC.
> - The content of the Unicode DUCET is NOT stable: characters are inserted in
> the sequence so that the full list of collation weights needs to be offseted
> where the new characters get inserted.
> - Collations for languages get corrected. We should be able to upgrade these
> rules when the CLDR project produces new tailorings (CLDR updates are
> published
> separately, about every 1-2 years.)
It's not critical for most wikis to use the very latest collations, though.
The English Wikipedia, for example, will do fine with even very out-of-date
collations, since the article names overwhelmingly use characters that have
been in Unicode for an extremely long time. The same is true for most other
large wikis; but on the other hand, to change collations on small wikis will be
fast in any event.
However, Tim Starling independently suggested a cl_collation column, and my
initial implementation does have one. The current one doesn't allow the same
row to be stored multiple times with different collations, so sorting might
still be wrong as the collation is updated, but this might not be a big problem
in practice. If it is, we can go with your idea of extending the primary key
to (cl_collation, cl_from, cl_to) instead of (cl_from, cl_to).
> Anyway you did not reply to the idea of first developin the parser functions
> and test them. Developping the SQL schema extension should not be attempted
> before at least the first function {{SORTKEY:text|locale|level}} has been
> fully
> developed and tested on specific pages (it can be tested easily in tables).
>
> The second function {{COLLATIONMAP:text|locale|level|clusters}} is not needed
> immediately to develop the schema, but will be useful to restore the
> functionality of headings. Headings don't need to be stored as they can be
> computed on the fly, directly by reading sequentially the sorted result set
> from the SQL query:
I tried to figure out what you were talking about here, and eventually figured
out that you just want me to expose Language::convertToSortkey() and
Language::firstLetterForLists() (as they're currently called) as parser
functions, for the benefit of lists. That might be useful, and should be easy
to do, although it's not part of my assigned job here.
> You can compute headings from the returned page names, or from the existing
> stored "cl_sortkey" which should be used now ONLY to store the plain-text
> specified in articles with {{DEFAULTSORT:sortkey}} and
> [[category:...|sortkey]].
I've introduced cl_raw_sortkey to store that, while retaining cl_sortkey for
actual sorting. Based on your feedback, it might make more sense to rename
cl_raw_sortkey to cl_sortkey_prefix, put {{defaultsort:}} into it, and make it
the empty string by default.
(In reply to comment #187)
> This does not require any change in the schema. This can be made immediately
> by
> MediaWiki developers and will not influence the developement of all
> corrections
> needed for bug #164 itself.
Correct. I'll probably do it anyway in the course of the work I'm doing,
though, since I'll be rewriting CategoryPage.php's sort logic in any case.
> For example in people's names whose page name is "FirstNames LastName" but
> that
> we want to sort as if they were "LastName, FirstNames" by indicating only
> {{DEFAULTSORT:LastName !}} (it should not needed to include the FirstNames in
> the wiki text, as this sort hint will not be unique and the group of pages
> using the same hint will still need to sort within this group using their
> natural order).
I can append the page title to cl_raw_sortkey before computing cl_sortkey.
That shouldn't be a problem. As noted above, maybe renaming it to
cl_sortkey_prefix would make more sense.
(In reply to comment #188)
> An "interface" function is DEFINITELY NOT an "implementation" detail. My
> comment #180 _correctly_ describes and summarizes what is really wanted.
Unfortunately, it's hard for me to understand what you're saing. However, I
think I've got it now, at least mostly. I don't think parser functions are
essential, here, and they're not strictly part of this bug. They can be added
after the initial implementation is finished.
> It correctly explains the dependancies and why any change in the SQL schema
> can
> be and should be delayed. In fact I consider the step (1) in my plan to have a
> high priority on all the rest, and it does not imply any immediate change in
> the schema to support it.
Writing those functions is not part of my job. I expect the i18n people will
handle that.
[Bug 21526] Bug in Djvu text layer extraction
https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 --- Comment #12 from Simon Lipp 2010-07-25 15:17:25 UTC --- Well, in the meanwhile, it’s still possible to manually fix the broken djvu files ; my own pdf to djvu converter has these lines : # Workaround for MediaWiki bug #21526 # see https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 $text =~ s/"(?=\s*\))//g; A quick look at man djvused give me this simple command to fix a djvu file (untested): cp thefile.djvu thefile-fixed.djvu; djvused thefile.djvu -e output-all | perl -pe 's/"(?=\s*\))//g' | djvused thefile-fixed.djvu -s -- 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 --- Comment #11 from Andrew Billinghurst 2010-07-25 14:44:47 UTC --- It would be nice if this bug fix could be considered out of session to look to be implemented at the Wikisource sites ahead of scheduled updates (next full application review). It is a minor bug that has major impediments for works for consideration. It leaves a blank page, misaligns text, and requires every subsequent pages in a work to be moved incrementally forward. Simple equations, even if we have only 20 works broken, and DjVu files are typically 200-500 pages in size, that would already start to equate to somewhere between 2000-8000 page moves. Thanks for any consideration that could be made to this request. -- 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 24540] Logo switch on fj.wikiquote
https://bugzilla.wikimedia.org/show_bug.cgi?id=24540 Casey Brown changed: What|Removed |Added Status|RESOLVED|REOPENED CC||cbrown1...@gmail.com Resolution|FIXED | --- Comment #2 from Casey Brown 2010-07-25 14:15:26 UTC --- (In reply to comment #0) > Requesting logo switch on http://vi.wikiquote.org/. > http://fj.wikipedia.org/wiki/File:Wiki.png has been uploaded > Thanks Sorry, but what? :-) You mentioned vi.wikiquote in the first line of this request, but fj.wikipedia in the second line and fj.wikiquote in the header... which is it? Also, "FIXED" is used when the bug is actually fixed. We either leave it open or close it as "INVALID" or "LATER" if there are 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 24540] Logo switch on fj.wikiquote
https://bugzilla.wikimedia.org/show_bug.cgi?id=24540 Trần Nguyễn Minh Huy 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 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 24517] Usage of $this in static methods
https://bugzilla.wikimedia.org/show_bug.cgi?id=24517 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added Status|NEW |RESOLVED CC||alex.emsenhu...@bluewin.ch Resolution||FIXED --- Comment #2 from Alexandre Emsenhuber [IAlex] 2010-07-25 11:41:23 UTC --- Fixed in r69869. -- 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 24534] enable hide/show patrol edits in Special:recentchanges in hindi wiki with recent changes patrol
https://bugzilla.wikimedia.org/show_bug.cgi?id=24534 --- Comment #1 from mayurkumar 2010-07-25 10:38:29 UTC --- However paroller user has been enabled by you but this feature is remainning.Without it we can make no use of autoproller user or patrol edits.Our community consessus is at our village pump link-http://hi.wikipedia.org/wiki/%E0%A4%B5%E0%A4%BF%E0%A4%95%E0%A4%BF%E0%A4%AA%E0%A5%80%E0%A4%A1%E0%A4%BF%E0%A4%AF%E0%A4%BE:%E0%A4%9A%E0%A5%8C%E0%A4%AA%E0%A4%BE%E0%A4%B2#Apply_reveiwer_.26_partrolled_system_and_Enable_Some_User_Groups_.28autopatroller.2C_reveiwers.29. Thank you Regards Mayurkumar -- 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 24540] Logo switch on fj.wikiquote
https://bugzilla.wikimedia.org/show_bug.cgi?id=24540 p858snake changed: What|Removed |Added Keywords||shell CC||p858sn...@gmail.com --- Comment #1 from p858snake 2010-07-25 10:23:04 UTC --- * File will need to be protected * I'm pretty sure the files need to be 135x135 -- 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 24540] New: Logo switch on fj.wikiquote
https://bugzilla.wikimedia.org/show_bug.cgi?id=24540 Summary: Logo switch on fj.wikiquote 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: minhhuyw...@gmail.com Requesting logo switch on http://vi.wikiquote.org/. http://fj.wikipedia.org/wiki/File:Wiki.png has been uploaded 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 671] Whitelist non-problematic HTML tags: dfn samp kbd address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671
--- Comment #48 from Christopher Yeleighton 2010-07-25
08:42:53 UTC ---
(In reply to comment #47)
> * On the idea of applying dfn with a template to the boldfaced term at the top
> of an article's lead (e.g. "{{leadterm|elektrokardiogram}}"):
>
> --- Comment #45 from Christopher Yeleighton 2010-07-22
> 19:33:30 UTC (In reply to comment #41) ---
> > I would rather say [[{subst:PAGENAME}]] and leave inserting the DFN tags to
> > the engine. (I admit I have changed my position on this subject.)
>
> I don't follow you. Where would this link appear (presumably with correct
> double squiggly bracketing) and why? If you mean to suggest that PAGENAME can
> be used in the lead, that won't actually work in hundreds of thousands of
> cases
> because of disambiguation and because (especially in bio articles, e.g. [[Newt
> Gingrich]]) the article title and the subject of the article as given in the
> lead often do not match even when the article title is not disambiguated.
Just use "|".
http://en.wikipedia.org/w/index.php?title=Newt_Gingrich&oldid=375340399>
--
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 24188] Bold and Italic Icons in Vector toolbar to 'B' and 'I' in Malayalam
https://bugzilla.wikimedia.org/show_bug.cgi?id=24188 --- Comment #3 from Shiju Alex 2010-07-25 08:09:05 UTC --- Hello, Could you please update this ASAP. We are planning to create some videos based to explain the new interface. So we want this to be updated before we start capturing the video. Thanks -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
