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

MediaWiki update stuff

Please update MediaWiki:Gadget-UTCLiveClock.js with the enwiki update, due to the MediaWiki update. fetch·comms 19:06, 16 February 2011 (UTC)[reply]

Every page of Hungarian Wikinews appears as a blank one. You can make your browser to render them correctly by hitting the back button once, so I think this is because the addresses are truncated automatically, losing the very last character. This problem occurs on the main page too. Our toolbox (the one with you can insert special characters while editing a page) also stopped working. My best guess is that this problem derives from the latest update, but I am not sure. Could you check it, please? - Xbspiro (talk) 20:16, 20 February 2011 (UTC)[reply]

Looks like its been fixed. Probably caused by using document.write in a js file. Bawolff 19:11, 24 February 2011 (UTC)[reply]
It got fixed on Wednesday, last week. There were several instances of using document.write on HUWN; we replaced them after we got a suggestion to do so on another forum. Thx anyway. - Xbspiro (talk) 13:27, 3 March 2011 (UTC)[reply]

Semi-protect Comments:

Is it possible to protect [create=autoconfirmed] all pages in the Comments namespace? Doing so would no doubt stop creations of comments pages of unpublished articles, as all pages should be created by reviewers only. (Not sure what the deal with old articles without comments would be, though) — μ 00:23, 24 February 2011 (UTC) 00:23, 24 February 2011 (UTC)[reply]

I would oppose this measure. What is the trouble with people commenting on unpublished articles? If the article is later published, then there should be no problem; if it's instead deleted, just delete the comments along with it (like we do to talk pages). Besides, there is also the problem of IPs not being able to comment on old, pre-LQT published articles if this is done. Tempodivalse [talk] 15:58, 3 March 2011 (UTC)[reply]
I tend to agree with Tempo. I don't really see an issue with anons commenting on a yet to be published article. Bawolff 18:18, 3 March 2011 (UTC)[reply]
There are technical problems. For as long as MW does not correctly associate comments pages with articles, they cannot be automatically moved as with talk pages at the same time as an article. Developing pages may expect multiple moves, leaving disassociated comments pages. The other problem is that EzPR is required to create them properly; or, alternatively, they must be set up manually in advance. Comments pages created early by anons invariable do not use LQT and this isn't easily fixable; much to my annoyance, the only practical solution at-present is to remove comments where LQT hasn't been used but should have. LQT fails to support importation of misplaced comments. Blood Red Sandman (Talk) (Contribs) 18:24, 3 March 2011 (UTC)[reply]
In fairness, there is also a plausible content-related rationale for not opening discussion on an article until it's published: prior to publication, the content is unscreened (so it's like discussing a blog entry, which isn't a valid use of Wikinews) and unfixed (so discussion may be about something different from what is later published).
On an unrelated —technical— note, it would be nice if we could "simply" rewire the Haveyoursay template(s) to not offer a redlink for pre-publication articles. The snag being, that's easy to do if one wants to suppress all redlinks, but not if one wants to show the redlink anyway for archived articles. --Pi zero (talk) 23:17, 3 March 2011 (UTC)[reply]
Note, we do have a js hack to automatically move the comment pages. It sounds like a better fix to the problem would be to make comment namespace use lqt by default (which i'm pretty sure is possible) instead of requiring the {{#useliquidthreads}}. That way not currently created comment pages would act as if they had lqt. Bawolff 00:15, 4 March 2011 (UTC)[reply]
  • At least half the Comments contributions pre-publication are to utterly useless, or trolling by people who've created something useless in Main NS. A semi-protect until EZPR creates the valid comments page would be nice, but may be impractical; what of reviewers who are not administrators? --Brian McNeil / talk 06:47, 4 March 2011 (UTC)[reply]
Judging by a simple userspace test I just carried out, [create=autoconfirmed] does not [edit=autoconfirmed] created pages. I don't see why reviewers not being administrators has anything to do with it: if a blanket restriction, akin to the MediaWiki namespace, of edit=autoconfirmed, move=all, create=autoconfirmed, was implemented, all would be well (although, I assume, one might have to create any comments pages of the archives that are yet to exist. (A better option would be to redir a user to talkspace until the page is created, unless forced by &redirect=no, but I doubt that's worth the time and effort) — μ 09:35, 4 March 2011 (UTC)[reply]
Not sure if that came out quite right. I'd have thought the only change wanted would be create=autoconfirmed for comments space; presumably we don't want to prevent IPs from commenting once the comments page exists. --Pi zero (talk) 12:06, 4 March 2011 (UTC)[reply]
Er, create=autoconfirmed edit=all. — μ 14:17, 4 March 2011 (UTC)[reply]
  • No way, most people who use the comments page are IPs and this would decrease activity in that sense. It's simple, delete the comments pages they create (for unpublished articles) and problem solved. --Diego Grez return fire 15:12, 4 March 2011 (UTC)[reply]
Name me a recently published article that has an associated comments page created by an anonymous editor. To reiterate, Comments: pages are only ever created by reviewers. Any comments page created by an IP was created before publication, and as such is deleted. I am proposing a restriction on creation, not editing: IPs will still be able to post messages, but they will have to wait for someone to "open" the forum (which is automatically done on publication by EPR) before doing so. — μ 17:07, 4 March 2011 (UTC)[reply]

Interface tweak

I've just edited MediaWiki:Revreview-check-flag-u to try and tidy the review interface marginally: compare a new mainspace article with a a metaspace page. — μ 18:58, 7 March 2011 (UTC)[reply]

I've also prevented the WN:PROD deletion reasons appearing in the dropdown for non-namespace articles, and the disassociated comments page from appearing on non-comments pages. I'd like to also prevent the {{abandoned}} reason from appearing if there are no pages in the Abandoned category (to prevent overzealous deleting without fair warning). Thought I'd better seek consensus for that one though (and I'm not sure if PAGESINCAT is cached or not). — μ 20:47, 7 March 2011 (UTC)[reply]
PAGESINCAT is cached in the category table, but its updated each time things added/deleted from category, so probably work. However, personally i'd think it'd be kind of confusing for the menu to change in such a fashion (Sometimes the entry is there, sometimes it isn't, without it being clear why). Bawolff

Ambox type=serious appears in blue

{{ambox}} has been appearing in blue when the |type= parameter is set to serious. Why is this? Has something ahppened to the CSS? More importantly, how do we make it red again? See {{delete}} for an example. Δενδοδγε t\c 22:10, 18 March 2011 (UTC)[reply]

I think [1] is a likely culprit but haven't really checked. Is all that css really needed? Seems like a lot of extra fluff we don't use. (Remember more css = longer loading time. Not very much longer, but we still shouldn't put unneeded stuff in there just 'cause). Bawolff 22:18, 18 March 2011 (UTC)[reply]

Blocking user pages from Wikipedia news feeds

How do I block user pages from showing up on Wikipedia news feeds, e.g., User:Mono/Sandbox at Portal:United States/Wikipedia? -- RichardF 17:33, 19 March 2011 (UTC)[reply]

  •   Fixed - it was a specific problem with that page. Only published articles should have {{Publish}} in them, and, in turn, therefore only published articles should be in Category:Published. The news feed above (as with all these news feeds) relies on the published category to prevent stuff like that going through to Wikipedia. There may be a way to limit it to sighted articles, like what we do with the Main Page, but if there is I don't know what - I'm not technical in the least. Blood Red Sandman (Talk) (Contribs) 17:41, 19 March 2011 (UTC)[reply]
Thanks! You're "technical" enough for me!  :-) RichardF 17:59, 19 March 2011 (UTC)[reply]
There are several DPL qualifiers that such feeds should always use:
           notcategory=No publish
Cf. {{Topic cat}}. --Pi zero (talk) 18:27, 19 March 2011 (UTC)[reply]
We should perhaps put this all in a template for Wikipedia users (Something like {{DPL}}) Bawolff 22:48, 19 March 2011 (UTC)[reply]

All of the above qualifier were included. For some reason, "namespace=0" didn't keep out the user page, which I thought it should. - RichardF 02:32, 20 March 2011 (UTC)[reply]

Actually, no. I added most of those qualifiers (all but the first) just before I made the above comment, so when you observed the problem they weren't in place. My bad for not saying that in my comment. Sorry for the confusion. --Pi zero (talk) 12:22, 20 March 2011 (UTC)[reply]
Ahhh, now I get it! I was thinking of when you added those qualifiers to Portal:Science and technology/Wikipedia. Thanks! -- RichardF 15:32, 20 March 2011 (UTC)[reply]