Wikinews:Water cooler/technical/archives/2011/February

MediaWiki:Gadget-searchbox.js

Hello, I've installed wikt:fr:MediaWiki:Gadget-searchbox.js from wikt:pl:MediaWiki:Gadget-searchbox.js. It adds the text treatment functions: "go to line n°", "change the capitalization", "search and replace" (eventually "replace all") and sort alphabetically. JackPotte (talk) 20:43, 9 February 2011 (UTC)

1.17

In a couple days, the devs are going to update all wikimedia sites to mediawiki 1.17 on feb 8 (7:00 utc)[1]. Given that the servers haven't been updated in forever, this brings all sorts of new features/bug fixes/etc. One of the new features is something called the Resource Loader, which should make js related stuff faster. However this has the potential to break some javascript. With any luck, nothing will break, but if any of the local javascript does break, please yell at me. (If anything else breaks, file a bug at bugzilla:). Bawolff ☺☻ 04:29, 5 February 2011 (UTC)

p.s. I should mention i have tested some of the very important scripts ahead of time, and nothing has broken horribly. Bawolff ☺☻ 06:10, 5 February 2011 (UTC)

I observe (using Firefox and monobook), in no particular order,

• When I'm entering a string in the search box, with javascript on, there's no autocompletion.
• Diffs, with javascript on, now come out wrong for a moment and then right themselves. Which from a user's point of view means things take longer. This is an improvement? Scientists, who ought to know, // Assure us that it must be so.
• Diffs with javascript off effectively do not work at all, rendering the wiki software rather unusable.

--Pi zero (talk) 11:55, 14 February 2011 (UTC)

Which browser for the search autocompletion? The diff thing is currently bugzilla:27418 (that bug is more from the flash of unstyled content is bad then doesn't work w/o js presepective though). Bawolff ☺☻ 23:16, 14 February 2011 (UTC)

Firefox 3.6.13. -Pi zero (talk) 23:31, 14 February 2011 (UTC)

Autocompletion works this morning. --Pi zero (talk) 15:03, 17 February 2011 (UTC)

┌────────────────┘
I see Editintro notcurrent when editing articles published much less than 24 hours ago. --Pi zero (talk) 02:09, 15 February 2011 (UTC)

Could be some sort of a timezone issues perhaps? (although js should use utc). How much less than 24 hours are we talking (with age being considered relative to whats in the {{date}} template). Bawolff ☺☻ 02:31, 15 February 2011 (UTC)

At the moment I'm getting it on the last article published yesterday UTC (about 4:30 ago), but not on the one published today UTC (about 3:10 ago). Suggesting something that's going by date only — mildly surprising since the test appears to use miliseconds. --Pi zero (talk) 03:39, 15 February 2011 (UTC)

Evidently it is, indeed, looking only at the day. Just after midnight UTC, both articles published yesterday show notcurrent — the first published slightly less than 24 hours ago, the other a little over six. --Pi zero (talk) 00:15, 16 February 2011 (UTC)

Its going by miliseconds (everything is represented using number of ms since midnight Jan 1, 1970 UTC), but using the number of ms since midnight on the date entered in the {{date}} template. Perhaps 48 hours would be better. Bawolff ☺☻ 01:11, 16 February 2011 (UTC)

Regarding the temporary misdisplay when a diff is first viewed, and that with javascript turned off the misdisplay is never corrected — I've just been noticing that the same happens with the opinions tab on articles: it isn't there at first, then gets added moments later iff javascript is turned on. --Pi zero (talk) 15:22, 15 February 2011 (UTC)

Thats nothing new though. Because we use js hacks to do the opinion tab, they get added after page load currently. Bawolff ☺☻ 01:11, 16 February 2011 (UTC)

There's also a similar issue of flash-of-unstyled-content with the main page, probably due to how we put main page css in mediawiki:Common.css/Main_Page. We should maybe consider moving that css back in to the main common.css since the main page is the first point of entry, we don't want flash-of-unstyledness there. Bawolff ☺☻ 01:50, 16 February 2011 (UTC)

mw:Extension:ReaderFeedback

Cross-water-cooler link: Wikinews:Water cooler/assistance#Page ratings. - Amgine | ^t 17:01, 18 February 2011 (UTC)

Bugsplat: Hard-coded Comments tabs

Just found bugzilla:11586 whilst looking for something else on Bugzilla; do we still want this? If so, we'd probably want consensus again (being four years since the bug was filed). If not, it'd be nice if the bug were closed. It also appears to have been superseded by javascript – and if it hasn't, reopening a vote might goad the devs into doing something. — μ 21:56, 15 February 2011 (UTC)

For reference: original discussion(as far as I can make out) — μ 01:35, 16 February 2011 (UTC)

If I'm following this correctly, it would make the tabs work right in opinions (comments) space, and make the opinions tab work right without javascript in mainspace. Have I got that right? Sounds excellent. --Pi zero (talk) 22:56, 15 February 2011 (UTC)

Yes that is the gist, except that tabs should already work in opinions namespace if you have js. Basically it just moves the js code into php. It wasn't exactly superceeded by js, since it was written after the js was introduced. The extension somewhat fell through the cracks, and is a tad old now, and is not compatible with 1.18 (or at least didn't work when I tested it). We should fix it before trying to get it to go live, if we want to do that. Bawolff ☺☻ 00:44, 16 February 2011 (UTC)

For me anyway, in monobook, comments pages always lack main/talk tabs, regardless of js. The tabs do appear using vector, I see now that you've tipped me off to it. --Pi zero (talk) 01:10, 16 February 2011 (UTC)

yeah, i think that is because i never got around to fixing a bug it had on monobook. Bawolff ☺☻ 01:12, 16 February 2011 (UTC)