https://bugzilla.wikimedia.org/show_bug.cgi?id=4582
--- Comment #245 from Mr.Z-man <[EMAIL PROTECTED]> 2008-11-28 04:43:19 UTC --- (In reply to comment #244) > (In reply to comment #237) > > (In reply to comment #236) > > > Which patch? > > #1 is out of the question, as Bill points out. > #2, #3 and #4 all prevent linked dates from being links. So they all fix the > "seas of blue" problem. > > #4 also fixes the "ISO cruft for anons/noprefset" problem. The objection that > "the squid cache makes [#4] unworkable" is not the whole story. Squid caching > only applies to anons, so #4 still works fine for the noprefset registered > users. And even *if* the patch were not modified to deal with anons some other > way (eg comment #243), then anons would get to see whatever it was that the > last anon who caused a fetch from MW saw. Which A) is still a whole sight > better than seeing ISO cruft, B) a pretty good weighted-random choice of which > dateformat to display for anons. As I said, the default can be changed rather easily. It can even be changed for en.wikipedia without a change to the software. But having anons see either of 2 date formats depending on the location of the last person who caused a cache update, is just ugly. > The bottom line is that *something* needs to be done at DateFormatter too, > otherwise the "seas of blue" will continue to exist, and people will continue > to go around removing date links, which is inherently destructive. Although > there is a Javascript solution available, its not a viable solution unless > DateFormatter adds the appropriate markup /and/ the admins make the Javascript > site-wide, which is unlikely to happen because -- as we see from the > interminable "discussions" elsewhere -- common-sense is in short supply. I really don't like the idea of having normal wikilink syntax do something, but not actually make a link. It adds even more complexities to wikitext and inconsistencies in parser output. This would probably need approval from Tim/Brion and would probably need a config option to enable it. > Objecting all very well and good, but #3 and #4 are a GoodThing, and if there > are problems with them, then these can be fixed or compensated for. Squid et > al > are not the show-stoppers that they being treated as. 4 will not work correctly with squid caching. I'm not going to introduce code into MediaWiki that I know will be partially broken for Wikimedia. > For those joining the discussion late (e.g. Mr. Z Man and Philippe Verdy): the > title of this bug only tells half the story. This bug is in effect the search > for a technical solution to the perennial discussions at en:wp, which are > provoked by A) the eyesore caused by the linked dates also appearing as links; > B) the fact that only very few dates actually need to be links; C) the > inconsistencies that appear in an article if not every date is linked; D) the > cruft that anons and editors without a datepref get to see, E) the > (preservation of) meta information present in [[date]]s but not in plain > text. > > Patch #3 addresses issues A, B, C, E. Patch #4: A, B, C, D, E. A is basically a matter of personal opinion. B is a local style issue. Just because the English Wikipedia decided it doesn't think dates should be linked anymore, doesn't mean we should force that on every user of MediaWiki. As for C, the patches that simply remove the link wouldn't really address it, since the autoformatting would still happen. Changing the default preference will also mostly fix D (it won't affect existing accounts) without pointless inconsistencies for anon users. > (comment #236) > > People aren't just going to grab a patch and commit it. Especially when the > > last patch seems to be entirely different from what's being requested in > > these > > past several comments. > > This comment borders on stupidity. All the issues noted above are already > mentioned in the top 10 comments on this page, which are from Jan-March > *2006*. > That these issues have not been addressed (and in fact the reason why this bug > was once closed for equally ignorant and stupid reasons) is due solely to dev > apathy and their inability to read (evident again in a recent email). One need > only follow Tony Souter's (en:User:Tony1) comments on this page -- from > engaged > and supportive (comment #14) to disillusioned (comment #158) -- to recognize > how destructive dev negligence has been. > Insulting the people trying to help isn't really going to get them to help. There's hundreds of other open bugs I can work on where I won't be called stupid, ignorant, apathetic, and negligent when I try to figure out WHAT PEOPLE ACTUALLY WANT NOW. Not what people want 2 years ago. Not what people wanted last month. Not things where it has been established won't work. This is basically what I've seen in the few days I've been commenting here: *We want different formatting depending on browser language **That won't work *Well we didn't want that anyway. Just a change to the default and create an easy way to change them with JS **Okay, that sounds easy enough *No, we want [[date]] to not autoformat and have [[:date]] do it instead **Okay *No, we want a completely new syntax for date links **That'll be a little harder *No, we want to wrap dates in a span if we want them to be autoformatted **That's just ugly *Well what we actually want is for [[date]] to not create a link **And that's where we're basically at now. The actual request seems to vary significantly depending on who's making the comment. -- 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 watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
