Thank for including details of the 1.20wmf8 rollout. If the history bug only affects the RecentChanges table, affected entries will anyway be deleted after 30 days (at least on enwiki), so it might be easier to let the past errors expire naturally instead of applying a retroactive fix to existing data. — Richardguk (talk) 21:44, 23 July 2012 (UTC)[reply]
History pages work on the revision table, not the recentchanges table. Bawolff (talk) 12:29, 24 July 2012 (UTC)[reply]
Bugzilla:37225 was identified because of corruption to article size entries on pages based on recentchanges (watchlists and RecentChanges). It did not seem to corrupt revision entries on history pages, though I'm not sure whether the possibility has been ruled out. "History bug" is a slightly misleading description in the Signpost article. — Richardguk (talk) 12:45, 24 July 2012 (UTC)[reply]
Oh ok, in that case I agree, retro-actively trying to fix RC table seems like a waste of effort. Bawolff (talk) 13:17, 24 July 2012 (UTC)[reply]
Yeah, this is mostly me getting confused, I think, probably because I forget that the watchlists pulls rc entries and not revisions. Apologies for any confusion (I've tweaked the prose slightly). - Jarry1250[Deliberationneeded] 13:46, 24 July 2012 (UTC)[reply]
Well the bug title itself says "history" in it. Bawolff (talk) 14:19, 24 July 2012 (UTC)[reply]
I think you've earned yourself more than a few straws for your community feedback! — Richardguk (talk) 17:48, 24 July 2012 (UTC)[reply]
Enabling the page would still require local community consensus - As far as I understand, MzMcBride's proposal was for something enabled by default, not an optional feature. The reason why ?action=info is optional currently is because it has performance problems, the new action=info should it happen, would not have those problems (or have parts selectively disabled based on miser mode). Bawolff (talk) 12:29, 24 July 2012 (UTC)[reply]
Enabled by default in MediaWiki, maybe, but having it enabled on existing Wikimedia wikis would either require consensus or a pitched battle. - Jarry1250[Deliberationneeded] 13:46, 24 July 2012 (UTC)[reply]
or people could just convinently forget to re-disable it ;) On a serious note though, usually concensus isn't required for newly developed features (Arguably its an old feature that would be re-developed, but the only reason the old feature was disabled is to prevent the servers from coming to a crashing halt) As far as I am aware WM hasn't actively disabled it, wmf wikis are just using the current mediawiki defaults. Bawolff (talk) 14:19, 24 July 2012 (UTC)[reply]
I think we're seeing a sea-change on the view that "consensus isn't required for newly developed features", but perhaps it's more a question of whether any links to the new page are actually visible. - Jarry1250[Deliberationneeded] 14:24, 24 July 2012 (UTC)[reply]
Its what happens when people keep developing somewhat odd (relative to the wiki-way) and highly user-facing features. Although most of the controversial ones have been extensions which traditionally did require concensuss. Bawolff (talk) 14:31, 24 July 2012 (UTC)[reply]
Seems to me that, now that MzMcBride has refined the RFC to adding metadata at ?action=info (instead of moving metadata from edit/editpreview pages to ?action=info), support for the additional parameter should be largely uncontroversial and most editors would probably never even realise that it exists. But I am surprised that there was not more initial concern at the subproposal to disclose the number of watchers for any page, since moderately sophisticated vandals could learn to target pages that are not much watchlisted. — Richardguk (talk) 17:46, 24 July 2012 (UTC)[reply]
Honestly the chance that a feature would get accepted that disclosed the number of watchers a page has when there's already a right restricting that (unwatchedpages) is pretty low in all probability. Bawolff (talk) 19:48, 24 July 2012 (UTC)[reply]
A critical thing to help SVG translation support would be to end the situation where people are driven to convert so much text into path data -- so much more difficult to edit and update, never mind search -- because the text handling and placement of WP's SVG renderer is so appalling. SVG has so much to offer, it's a crying shame that WP's SVG support is so poor, that people are forced to go to workarounds like this. The generally miserable state of libsvg has been an unaddressed issue for years -- will resources ever be put into either bringing it up to the mark, or replacing it with one of the other open-source SVG back-ends, that actually work? Jheald (talk) 11:04, 30 July 2012 (UTC)[reply]
librsvg isn't as bad as it used to be, but agreed that flowRoot support would be a great addition. I think recent calls to reinvestigate used Inkscape to convert to PNGs would be a good idea. - Jarry1250[Deliberationneeded] 11:31, 30 July 2012 (UTC)[reply]
