Wikinews

Wikinews:Water cooler/proposals/archives/2011/April

< Wikinews:Water cooler | proposals
This is an archive of past discussions from Wikinews:Water cooler/proposals/archives/2011. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current page.


Proposal: Removal of LQT across the board at en.wikinews

I'm writing this to propose an open vote of all WN members regarding the usage of LQT on Wikinews. As you know, I was a strong opponent of LQT when it was introduced, and seeing it today, my views on the subject haven't changed. It looks absolutely atrocious, like a vBoard gone wrong, the layout is appalling, and it's not as easy to manipulate and handle as a regular talk page for doing stuff like editing (you have to edit each post individually, rather than open the whole page in one go). Frankly, it's an eyesore of the highest order. I made the decision when it was introduced that I will remove it from any article I publish, and that decision hasn't changed. How this goes now, is down to the community. BarkingFish (talk) 18:36, 15 March 2011 (UTC)[reply]

The question is - Should English Wikinews remove and turn off the LiquidThreads (LQT) extension for future articles?

Support

  •   Support as proposer BarkingFish (talk) 18:37, 15 March 2011 (UTC)[reply]
  • Comment—LQT should either be implemented in every talkspace, or not at all. We shouldn't have the oddity of LQT only in the Comments namespace, and I'd much rather it everywhere (or nowhere) than this shoddy almost-nowhere that we have at the moment. We should remove LQT at least until we have a nicer looking/functioning extension, and, if it is to be re-implemented, it should be implemented on every odd-numbered namespace (with an opt-out for User talk). — μ 19:05, 15 March 2011 (UTC) [ED 17 Mar][reply]
(yay for interspersing comments with votes) I'd disagree that it should be implemented on all talk namespaces (As an aside, comments is an even number namespace). The point of LQT (imo) is to provide an interface for users to comment on articles that is harder to screw up. Normal talk pages are easy to screw up if you don't know what you're doing. I've always felt that comment pages are for the (potentially clueless) readers, not for the regulars. (in contrast to normal talk pages which are the opposite) Bawolff ☺☻ 15:30, 17 March 2011 (UTC)[reply]
Append "as well", and my comment makes more sense. I hadn't thought of this as a (rather compelling) argument. It is more user friendly for readers, considering the fact that some long-standing users decide to add asterisks or hash signs where there should be colons (and vice versa). If they can't do it properly, how can new users not find all of this triple-apostrophe nonsense overwhelming? LQT is feature-rich, and perhaps that's not a good thing — what would be wrong with it just creating pseudo-sections for each new comment as supposed to the myriad of namespaces? LQT is user-friendly for the user, but for the power-users that want to do housekeeping, it's a bit of a no-go. — μ 16:03, 17 March 2011 (UTC)[reply]
I dislike LQT as well, but I like it on the comments pages. It is easier for anons to use, due to the fact that it is (more or less) a WYSIWYG editor, with auto-signing. Forcing anon commentors to learn wikicode in order to comment is unlikely to gain us a following;). Gopher65talk 08:22, 20 March 2011 (UTC)[reply]
  •   Support. It's ugly and smells funny. --Brian McNeil / talk 13:01, 17 March 2011 (UTC)[reply]
  •   Support. LQT was sold to me on the grounds that it is easier for newcomers - but the opposite is in fact the case. The links to enter or start threads are inconspicuous compared to the massive edit notice at the top. Many users with vague ideas about (or even considerable experience with) wikis simply edit the page directly. There is no functionality to import these comments into LQT. I used to remove them, citing the almost unnoticeable warning about headers & whatnot, but I no longer have the heart. Blood Red Sandman (Talk) (Contribs) 18:26, 17 March 2011 (UTC)[reply]
Note, we may be able to tweak it to make the link more prominent (For example, turning it into a button maybe [1]). Bawolff ☺☻ 23:44, 17 March 2011 (UTC)[reply]
Whilst we might improve things a bit, I suspect redesign to LQT would be needed to make it properly obvious not to edit the page. Blood Red Sandman (Talk) (Contribs) 22:30, 18 March 2011 (UTC)[reply]
IIRC it is possible to remove the "edit" link from the top of the page via javascript. That might help prevent non-LQT commentary. Tempodivalse [talk] 00:21, 19 March 2011 (UTC)[reply]

Oppose

Comment - The fact that it's undergoing a "redesign" is all very well, but right now, it's foul. Just exactly what is this redesign, and is there anywhere we can see it or a preview thereof? For all I know, the redesign might be even shittier than what we've got now. BarkingFish (talk) 13:10, 17 March 2011 (UTC)[reply]
mw:Extension:LiquidThreads/Redesign Not sure how up to date that is though. I think it was more written as an idea page when people first started thinking about re-designing it. Bawolff ☺☻ 15:23, 17 March 2011 (UTC)[reply]
  • Comment (I hate votes, this comment should not count as a vote). I like it for comments namespace. Its saw a rapid reduction in commenters who aren't familar with wiki screwing up other people's posts. Bawolff ☺☻ 15:18, 17 March 2011 (UTC)[reply]
  • Oppose. LQT looks ugly to those of us who are used to the standard MediaWiki way of carrying out a discussion with section headings and indentations, but it's a lot friendlier to newbies who don't have to deal with a full-fledged editing window and figure out how to format the text properly. LQT is closer to the format most sites use for comments, so most people will have a better grasp of how to use this format rather than standard MediaWiki, which is confusing if you don't know what you're doing. C628 (talk) 15:37, 17 March 2011 (UTC)[reply]
    Comment - As I recently stated on the strategy planning wiki, the idea of improving the experience for newcomers to the site should not impact on the experience for those of us who are already conversant with the tools and the software and how to use it. If an editor doesn't know mediawiki code, this is why the buttons above the edit box exist, along with an explanation of what they do when you touch them. If a newcomer can't push a button, I feel sorry for them. BarkingFish (talk) 21:44, 17 March 2011 (UTC)[reply]
  •   Oppose, although not the ideal comment system and I've frequently become annoyed by the messy way in which it arranges comments, LQT is still better for casual passerby who have no clue how to write with wiki-syntax properly. It is a much more user-friendly way to comment. Tempodivalse [talk] 16:38, 17 March 2011 (UTC)[reply]
  •   Oppose — I hate Liquid Threads, but it works on comments pages due to the fact that it removes the need for anons to learn wikicode and wiki-formatting rules before posting (which none of them ever did, of course:P). Yes it sucks, and hopefully they will make it better, but even if they don't it's better than just tossing our readers into a jungle of random coding rules that they've never seen before ('''''' ==== {| (grrr) '''' ~~~~ ::::).Gopher65talk 08:26, 20 March 2011 (UTC)[reply]
  •   Oppose I too hate LQT, and consider it incompatible with the serious technical discussions that belong on talk pages (seemingly an intrinsic conceptual flaw, not subject to fix by a redesign); but my sense has been that LQT was well suited to commenters unfamiliar with wiki markup, and Gopher's remarks below on repairing mistakes seem to confirm that. --Pi zero (talk) 12:11, 20 March 2011 (UTC)[reply]
  •   Oppose LQT is suit for those unfamiliar with MediaWiki code, a likely large portion of Wikinews' readers. Although those used to using MediaWiki code may dislike it, it's very similar to the comments sections of other sites. —Mikemoral♪♫ 23:36, 23 March 2011 (UTC)[reply]
  •   Oppose It's ok. I've seen people use it. My only complaint is having to clean out the Messages inbox for LQT. That, and I agree with Tempo's comment that the Edit button should be hidden via JS on the Comments: namespace. --Patrick M (TUFKAAP) (talk) 12:49, 6 April 2011 (UTC)[reply]
I've heard several people complain about cleaning out the message box. Would people like it better if reviewing an article does not automatically make you watch the comment page? Bawolff ☺☻ 13:57, 6 April 2011 (UTC)[reply]

Neutral

  •   Neutral, leaning towards support: I don't feel strongly either way, so I'm going to stay neutral for now, but LQT is somewhat divisive, and applied inconsistently (i.e., on new comment pages, but not old ones or talk pages), as well as being slightly awkward. However, it does make commenting easier for new contributors and casual readers, which can only be a good thing. Δενδοδγε t\c 18:48, 15 March 2011 (UTC)[reply]

Query

It'd be nice to have some stats (Usage of comments page before and after LQT). I felt LQT resulted in an increase in participation in comment pages, but that is purely anecdotal at this point. Bawolff ☺☻ 15:36, 17 March 2011 (UTC)[reply]
I agree that stats would be helpful. To me, it seems both sides are using that as their argument. The supporters claim it's putting people off commenting, the opposers are saying the opposite. Is there any way to compile statistics? (i.e., a bar-graph for activity in comments namespace over project history.) Tempodivalse [talk] 18:50, 17 March 2011 (UTC)[reply]
Number of comments per article per unit time might be somewhat meaningful. It'd be fascinating to see a graph showing distribution of comments over the age of an article.
Mistakes, though, seem to figure prominently on both sides, and I'm not sure how to gather data on them. Ratio of edits per comment might be calculated, but its not clear how to interpret it. Cf. lies, damned lies, and statistics. --Pi zero (talk) 21:00, 17 March 2011 (UTC)[reply]
Looking at the comments below, I'd just like to state that prior to LQT, I spent a LOT of my time on Wikinews formatting comments, signing anon comments, deleting comments that were on the main page rather than in the (hidden) comments tab (I even made a (now obsolete) template for this:P), and other such actions. Many of the edits to those comments pages came from people like BRS and me fixing anon editing errors. So those stats do indeed lie;). After LQT was introduced, my edits of comments pages dropped to almost nothing. Gopher65talk 08:31, 20 March 2011 (UTC)[reply]
While the stats may be helpful (and certainly are interesting), it is also important to realise that the edits in the Comments namespace may depend on the articles published as well. Controversial or high-profile articles are probably going to get more comments than others - Cartman02au (Talk)(AU Portal) 12:16, 20 March 2011 (UTC)[reply]

Limited stats

This is the number of revisions made using LiquidThreads (anything in the thread namespace) This does does not include edits directly to the comments namespace (aka to the header of the comments page).

Number of revisions in Thread namespace
mysql>  select left(rev_timestamp, 4) as Year, substring(rev_timestamp, 5, 2) as Month, count(rev_id) as `Number revs in LQT` from revision, page where rev_page = page_id and page_namespace =90 group by left(rev_timestamp, 6);

+------+-------+--------------------+
| Year | Month | Number revs in LQT |
+------+-------+--------------------+
| 2010 | 02    |                262 |
| 2010 | 03    |                261 |
| 2010 | 04    |                519 |
| 2010 | 05    |                471 |
| 2010 | 06    |                362 |
| 2010 | 07    |                420 |
| 2010 | 08    |                450 |
| 2010 | 09    |                265 |
| 2010 | 10    |                321 |
| 2010 | 11    |                242 |
| 2010 | 12    |                276 |
| 2011 | 01    |                178 |
| 2011 | 02    |                159 |
| 2011 | 03    |                202 |
+------+-------+--------------------+
14 rows in set (0.03 sec)

Up next. Number of edits made to the comments namespace. This includes the initial edit made by EasyPeerReview to create the comments page to begin with. Includes edits to comment page "headers". Basically includes anything in comments (opinions) namespace unless it was done in LQT.

Number of revisions in Comments namespace
mysql>  select left(rev_timestamp, 4) as Year, substring(rev_timestamp, 5, 2) as Month, count(rev_id) as `Number revs in LQT` from revision, page where rev_page = page_id and page_namespace =102 group by left(rev_timestamp, 6);

+------+-------+--------------------+
| Year | Month | Number revs in Comments not using LQT |
+------+-------+--------------------+
| 2007 | 01    |                 17 |
| 2007 | 03    |                 89 |
| 2007 | 04    |                222 |
| 2007 | 05    |                142 |
| 2007 | 06    |                276 |
| 2007 | 07    |                242 |
| 2007 | 08    |                247 |
| 2007 | 09    |                834 |
| 2007 | 10    |                940 |
| 2007 | 11    |                901 |
| 2007 | 12    |                696 |
| 2008 | 01    |               1837 |
| 2008 | 02    |                963 |
| 2008 | 03    |                904 |
| 2008 | 04    |               1011 |
| 2008 | 05    |                851 |
| 2008 | 06    |                894 |
| 2008 | 07    |                819 |
| 2008 | 08    |               1071 |
| 2008 | 09    |               1498 |
| 2008 | 10    |               1365 |
| 2008 | 11    |                882 |
| 2008 | 12    |               1062 |
| 2009 | 01    |               1218 |
| 2009 | 02    |                969 |
| 2009 | 03    |                918 |
| 2009 | 04    |                669 |
| 2009 | 05    |                623 |
| 2009 | 06    |                915 |
| 2009 | 07    |                575 |
| 2009 | 08    |                524 |
| 2009 | 09    |                477 |
| 2009 | 10    |                500 |
| 2009 | 11    |                451 |
| 2009 | 12    |                420 |
| 2010 | 01    |                622 |
| 2010 | 02    |                296 |
| 2010 | 03    |                373 |
| 2010 | 04    |                462 |
| 2010 | 05    |                599 |
| 2010 | 06    |                522 |
| 2010 | 07    |                398 |
| 2010 | 08    |                389 |
| 2010 | 09    |                369 |
| 2010 | 10    |                322 |
| 2010 | 11    |                269 |
| 2010 | 12    |                216 |
| 2011 | 01    |                232 |
| 2011 | 02    |                185 |
| 2011 | 03    |                142 |
+------+-------+--------------------+
50 rows in set (5.27 sec)

Which is much higher then I expected... (/me double checks my query). Bawolff ☺☻ 22:59, 17 March 2011 (UTC)[reply]

p.s. These were all done on the toolserver. Bawolff ☺☻ 23:00, 17 March 2011 (UTC)[reply]
edits deleted

Not sure if this is of interest - The following is number of edits (not pages) that got deleted in these namespaces.

Number of deleted revisions in Thread namespace
mysql>  select left(ar_timestamp, 4) as Year, substring(ar_timestamp, 5, 2) as Month, count(*) as `Number deleted LQT revs` from archive where ar_namespace =90 group by left(ar_timestamp, 6);

+------+-------+-------------------------+
| Year | Month | Number deleted LQT revs |
+------+-------+-------------------------+
| 2010 | 02    |                       7 |
| 2010 | 03    |                       3 |
| 2010 | 04    |                      27 |
| 2010 | 05    |                      24 |
| 2010 | 06    |                      25 |
| 2010 | 07    |                      39 |
| 2010 | 08    |                      32 |
| 2010 | 09    |                      39 |
| 2010 | 10    |                      20 |
| 2010 | 11    |                      22 |
| 2010 | 12    |                      26 |
| 2011 | 01    |                      20 |
| 2011 | 02    |                      10 |
| 2011 | 03    |                       8 |
+------+-------+-------------------------+
14 rows in set (0.01 sec)
Number of deleted revisions in Comments namespace
mysql>  select left(ar_timestamp, 4) as Year, substring(ar_timestamp, 5, 2) as Month, count(*) as `Number deleted revs in Comments ns` from archive where ar_namespace =102 group by left(ar_timestamp, 6);

+------+-------+------------------------------------+
| Year | Month | Number deleted revs in Comments ns |
+------+-------+------------------------------------+
| 2007 | 01    |                                  2 |
| 2007 | 04    |                                  9 |
| 2007 | 05    |                                  2 |
| 2007 | 06    |                                  3 |
| 2007 | 07    |                                  2 |
| 2007 | 08    |                                  8 |
| 2007 | 09    |                                  1 |
| 2007 | 10    |                                 12 |
| 2007 | 11    |                                 36 |
| 2007 | 12    |                                 31 |
| 2008 | 01    |                                 38 |
| 2008 | 02    |                                 44 |
| 2008 | 03    |                                 34 |
| 2008 | 04    |                                 48 |
| 2008 | 05    |                                 56 |
| 2008 | 06    |                                 25 |
| 2008 | 07    |                                 25 |
| 2008 | 08    |                                 20 |
| 2008 | 09    |                                 17 |
| 2008 | 10    |                                 22 |
| 2008 | 11    |                                 31 |
| 2008 | 12    |                                 25 |
| 2009 | 01    |                                 21 |
| 2009 | 02    |                                 71 |
| 2009 | 03    |                                 49 |
| 2009 | 04    |                                 27 |
| 2009 | 05    |                                 13 |
| 2009 | 06    |                                 10 |
| 2009 | 07    |                                 21 |
| 2009 | 08    |                                 35 |
| 2009 | 09    |                                 24 |
| 2009 | 10    |                                 30 |
| 2009 | 11    |                                 22 |
| 2009 | 12    |                                 17 |
| 2010 | 01    |                                 69 |
| 2010 | 02    |                                 27 |
| 2010 | 03    |                                 13 |
| 2010 | 04    |                                 51 |
| 2010 | 05    |                                 80 |
| 2010 | 06    |                                 55 |
| 2010 | 07    |                                 47 |
| 2010 | 08    |                                 55 |
| 2010 | 09    |                                 57 |
| 2010 | 10    |                                 56 |
| 2010 | 11    |                                 59 |
| 2010 | 12    |                                 54 |
| 2011 | 01    |                                 73 |
| 2011 | 02    |                                125 |
| 2011 | 03    |                                 34 |
+------+-------+------------------------------------+
49 rows in set (0.01 sec)
 
Deleted edits
 
Live edits



Reviewer policy needed

@Ashershow1 - You said, Looking back at that discussion, Mattisse appeared frustrated with the drawn-out, unspecific explanation of why her article had failed. Concise answers, such as "Sentences 3,6, and 12 are unsourced" are ideal.

This was exactly the problem. I could never get a clear answer from the reviewer, and his complaints kept shifting and drifting off into general advice. I strongly believe there needs to be a reviewer policy. The nearest I could find was Wikinews:Tips on reviewing articles.

  • Beginning suggestions for a Reviewer policy
  1. The reviewer should aim to give concise statements, such as "Sentences 3,6, and 12 are unsourced", rather than general reactions to the article without delineating specifically what needs to be changed.
  2. The reviewer should remain task-oriented and continue to give concise statements referring to specific problems, avoiding general "discussions" of the problems or giving advice on general article writing.
  3. The reviewer should consult the sources first, before making statements about the veracity of the article. e.g. the article is "poetic POV" when the reviewer has stated that he has not consulted the sources.
  4. The reviewer should consult the sources before stating there are too many that are probably unused and that more than two or three sources are too many.
  5. The reviewer should make factual statements about the article, and try to refrain from giving their personal pejorative reactions to the article.
  6. The reviewer should strive to remain emotionally uninvolved in the reviewing process, and maintain a professional distance if the writer becomes emotional.
  7. The reviewer should avoid initiating extraneous discussions by suggesting the there is a cultural clash about what an "editor" is, for example. And the reviewer should discourage those discussion if the writer begins them. Such discussion do not belong on the review page, IMO.
  8. The reviewer should concisely answer any questions the writer asks when the writer expresses confusion over what the reviewer's comments mean.
  9. If there is a problem in reviewing the article, the reviewer should be allowed to ask for a second opinion or other collaborative help.
  10. The review should use the writer's talk page to express such material as personal opinions on the article or give general advice on how to write articles and what sources to use.

These a just a few suggestions thrown out there and I may be completely off base. Having been a reviewer and copy writer, I know it is hard work. But if wikinews is seeking to achieve a high standard for its work, then reviewing must be a rigorous, standard-based process, I believe. Mattisse (talk) 19:27, 30 March 2011 (UTC)[reply]

I agree with what is said above. Specifics on the actual role of a reviewer are seriously lacking and have caused needless friction between reviewer and writer. Tempodivalse [talk] 03:46, 31 March 2011 (UTC)[reply]
I also agree with both of the above. I think reviewers also need to be as careful as possible not to interject personal bias. I understand we are all human beings, but reviewers bear a special responsibility and need to be especially mindful. I also believe strongly that we need more qualified reviewers. WikiNews is painfully slow publishing news, we frequently lag other news outlets by more than a day, I believe we can do better. Tadpole256 (talk) 01:30, 15 April 2011 (UTC)[reply]
Avoiding personal bias is one of the basic values of Wikinews. FWIW, it's been my experience that scrupulously avoiding personal bias often gets one accused of personal bias (hence, such accusations come with the package). --Pi zero (talk) 03:16, 15 April 2011 (UTC)[reply]
  • I tend to agree with the sentiments above, but must stress that my opinion is that guidelines should be preferred to "policy", and that people should accept that relatively terse rejections can, and frequently do, take place. By all means, complain about failing reviews being "generalisations", but those are based on experience - a "just no" to how an article is presented. It would be taken as more hurtful were the review failure to state "needs completely rewritting considering policy x, y, z, use of active voice, ..."; however, in a substantial number of cases this, like it or not, is what is presented to reviewers. Far, far too many people appear to think review is an invitation for someone to spend 3-4 times as much effort as the initial author has bringing it up to scratch (I stress, this is not aimed at anyone currently involved in this discussion). Ask yourself: Is that an effective use of reviewers' time? Is it going to lead to yet-more-of-the-same, shoddy, submissions? It is hard to write for Wikinews; equally so, it is already hard to review. Please don't make it so burdensome that articles receive zero attention due to failing them being almost as much work as passing them; such would completely close off access for potential new contributors. --Brian McNeil / talk 13:32, 15 April 2011 (UTC)[reply]

Alternative task for newcomers?

I submit that our basic recruitment/retention problem (hence low rate of acquisition of new community members) is not that our publication standards are high, but rather, that our standards for what newcomers are expected to do are unreasonably high. It isn't reasonable to expect newbies to just come in and write an article right off the bat that will achieve publication quality before going stale. Some of them do, and some who don't have the gumption to stick around; but a lot of folks leave after a first failure, and we've no way of measuring how many are too intimidated by the entry price to even try.

There must be better ways for us to start out newcomers. Here's just one thought.

  • Provide a form that can be filled out, producing a detailed request for a Wikinewsie to produce an article. Perhaps the form would have blanks for answers to the basic questions (very short blanks), for two or three mutually independent sources (upper bound?), a larger box for some further detail (what can we do to help guide/structure this?). The form wouldn't submit without at least two sources, certain basic questions answered, at least x basic questions answered, some further detail. Might be optional places for a picture, an infobox, a pull-quote.
It would produce a template with the data provided. Someone would try to turn it into an article, requesting help from the author (on xyr talk page) but not necessarily waiting for it. The person who turned it into an article would be involved, so couldn't review it, but it could be a big win on review time anyway because the thing that gets submitted for review is of much better quality than a newcomer's sink-or-swim first attempt.
This would provide much more structure for a newbie, making it easier for them to do than writing from scratch, easier for them to get it right, more likely their first effort wouldn't get shot down, and even somewhat less devastating for xem if it didn't work out after all. It would be easier for a Wikinewsie to turn the result into an article than it would be for a Wikinewsie to fix a poor attempt at a first article, and certainly easier than trying to explain to a newbie how to fix it xyrself within the freshness horizon of the story (especially given that newbies often don't realize they need to fix problems quickly).

--Pi zero (talk) 15:47, 12 April 2011 (UTC)[reply]


This sounds like a really good idea. As a NEWB myself, I would also say, there should be a more obvious way for us new folks to get to know the more established users. I am probably more stubborn than most, and I am determined to stick around and contribute, but I simply don't see a good way to meet / get to know my fellow wiki reporters and editors. Tadpole256 (talk) 01:35, 15 April 2011 (UTC)[reply]

IRC is a very good way. Bawolff ☺☻ 03:00, 15 April 2011 (UTC)[reply]
Exactly. Diego Grez return fire 03:09, 15 April 2011 (UTC)[reply]
I definitely want to jump in on one of the IRC chats, but unless I am mistaken, they are scheduled events right? Like monthly or something? Or is the IRC room always open and in use? Tadpole256 (talk) 21:17, 15 April 2011 (UTC)[reply]
The special logged workshop chat is scheduled. #wikinews and #wikinews-en are both open all the time (and most of our users idle in there a lot, so there's usually somebody to talk to). Because of the fast pace of news work, a lot of what we do happens in IRC, so you'll probably benefit from taking a look. DENDODGE 22:01, 15 April 2011 (UTC)[reply]

Main page header

Hello. Our last print version of Wikinews was a while back. Since then, why don't we remove the Print Edition from {{Main page header}}? --[[::User:Nascar1996|Nascar1996]] ([[::User talk:Nascar1996|talk]] • [[::Special:Contributions/Nascar1996|contribs]]) 17:16, 26 March 2011 (UTC)

I agree, it doesn't look good to have out-of-date PDFs linked from the main page. Print Edition is pretty much dead anyway. If anyone revives it again and it's updated consistently, we can always put it back. Tempodivalse [talk] 17:18, 26 March 2011 (UTC)[reply]
  Done in 1216558 — μ 22:35, 18 April 2011 (UTC)[reply]

About Quiz.

Hello world, i am a regular wikipedian... And recently i switched on to a more extensive use of Wikipedia. Earlier, i just used to read articles on wikipedia. But now i have begun using other wikis too. But i couldnt find the Quiz section. I have a proposal about creating WikiQuiz. Is wikipedia going to have a quiz section very soon? —The preceding unsigned comment was added by Anandtr2006 (talk • contribs)

  • The Quiz is a MediaWiki plugin, as far as I'm aware it was developed for WikiVersity, and we 'purloined' it. It'd take a vote on Wikipedia to install it there, or you could set up quizzes on WikiVersity. --Brian McNeil / talk 11:18, 2 April 2011 (UTC)[reply]
Hah, the irony. — μ 15:18, 19 April 2011 (UTC)[reply]
Or are you asking about a specific quiz? Here at Wikinews we have a World News Quiz, which usually gets updated once a week on Sundays. Our sister project Wikipedia has a specific policy that Wikipedia is not news; here on Wikinews, we specialize in news. And yes, there's some tension (yuck, politics) between the two projects over Wikipedia's In the news feature on its front page. --Pi zero (talk) 11:26, 2 April 2011 (UTC)[reply]

"Cite this article" box

To make it easier for people to cite us as a source in academic texts (because we are, after all, reliable, and conduct plenty of OR), I thought about making something along the lines of w:Special:Cite. So, I came up with this:

Cite this article
Bibliographic details
  • Page name: Wikinews:Water cooler/proposals/archives/2011/April
  • Author: Wikinews contributors
  • Publisher: Wikinews
  • Date of last revision: April 27, 2020, 01:32 UTC
  • Date retrieved: December 18, 2024, 10:27 UTC
  • Permanent link: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-
  • Page version ID: -
See the general disclaimer before citing Wikinews in an academic work.
APA style

Wikinews:Water cooler/proposals/archives/2011/April. (2020, April 27). In Wikinews. Retrieved 10:27, December 18, 2024, from //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-

MLA style

Wikinews contributors. "Wikinews:Water cooler/proposals/archives/2011/April." Wikinews. Wikinews, 27 Apr. 2020. Web. 18 Dec. 2024

MHRA style

Wikinews contributors, 'Wikinews:Water cooler/proposals/archives/2011/April', Wikinews, 27 April 2020, 01:32 UTC, <//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-> [accessed 18 December 2024]

Chicago style

Wikinews contributors, "Wikinews:Water cooler/proposals/archives/2011/April," Wikinews, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (accessed December 18, 2024).

CBE/CSE style

Wikinews contributors. Wikinews:Water cooler/proposals/archives/2011/April [Internet]. Wikinews; 2020 Apr 27, 01:32 UTC [cited 2024 Dec 18]. Available from: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-.

Bluebook style

Wikinews:Water cooler/proposals/archives/2011/April, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (last visited Dec. 18, 2024).

Bluebook: Harvard JOLT style

Wikinews, Wikinews:Water cooler/proposals/archives/2011/April, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (optional description here) (as of Dec. 18, 2024, 10:27 UTC).

AMA style

Wikinews contributors. Wikinews:Water cooler/proposals/archives/2011/April. Wikinews. April 27, 2020, 01:32 UTC. Available at: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-. Accessed December 18, 2024

BibTeX entry
See also: BibTeX
@misc{ wiki:xxx,
  author = "Wikinews contributors",
  title = "Wikinews:Water cooler/proposals/archives/2011/April --- Wikinews",
  year = "2020",
  url = "//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-",
  note = "[Online; accessed 18-December-2024]"
}
When using the LaTeX package url (\usepackage{url} somewhere in the preamble), which tends to give much more nicely formatted web addresses, the following may be preferred:
@misc{ wiki:xxx,
  author = "Wikinews contributors",
  title = "Wikinews:Water cooler/proposals/archives/2011/April --- Wikinews",
  year = "2020",
  url = "\url{//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-}",
  note = "[Online; accessed 18-December-2024]"
}
Wikinews related news

* {{Wikinews|Wikinews:Water cooler/proposals/archives/2011/April|April 27, 2020}}}

which gives
Wikinews discussions

[[Wikinews:Water cooler/proposals/archives/2011/April]] ([//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- revision -])

which gives

Wikinews:Water cooler/proposals/archives/2011/April (revision -).

Wikipedia

{{Cite web|url=//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-|title=Wikinews:Water cooler/proposals/archives/2011/April|author=Wikinews contributors|authorlink=English Wikinews|date=April 27, 2020|work=English Wikinews|publisher=Wikinews|accessdate=December 18, 2024}}

Note: Some Wikipedians do not consider Wikinews a reliable source; consider placing {{Wikinews|Wikinews:Water cooler/proposals/archives/2011/April}} in a "See also" or "External links" section instead.
Note: The dates and times listed above are all in UTC. The date is that of the last edit—you may wish to use the date of publication instead.

The idea is that it would go right at the bottom of a published article, perhaps as a part of {{Publish}}? It basically uses magic words to automatically generate a set of citations referring to the current page in various different styles.

There are one or two minor issues, but the template is pretty much ready if consensus is in favour, and these can easily be worked out after implementation:

  • It currently uses the date of the last revision. The date of publication would be more difficult to insert, but would (probably) be possible with a parameter that EzPR inserts (that would, of course, require bawolff's hackery). However, the last revision works too—it's just a thought.
  • I can't work out how to insert the time of the last revision. AFAIK, none of the citation styles require it, but a few of them have space for it so including it would be a good idea if it's possible.
  • Do we need links to the Wikipedia articles on each style guide? I doubt it, but it might come in useful for some people...

Of course, you'll probably all hate it and I probably just wasted my time, but it was a nice thought. DENDODGE 13:36, 15 April 2011 (UTC)[reply]

Oh, I forgot to mention that it's also supposed to insert COinS data. But I can't make that work, unfortunately (it is an ugly and esoteric microformat). Maybe somebody more adept with such things than myself could try and take a look at it? DENDODGE 13:39, 15 April 2011 (UTC)[reply]


  Comment Doesn't degrade gracefully with javascript turned off. Ideally, imho, such a creature would be a button that invokes a js tool, and simply isn't there (zero footprint) without javascript.

A prerequisite to deploying such a tool would be getting the date right. --Pi zero (talk) 14:11, 15 April 2011 (UTC)[reply]

It degrades as gracefully as every other collapsible box on the site. I suppose without JavaScript all the boxes are open, so it's really big? TBH, I'd rather have the functionality in a permanantly expanded box than not have the functionality at all.
As for the date, that is easy if Bawolff is willing to make EzPR do it (it just needs to add the data of publication as a parameter to the template). DENDODGE 14:15, 15 April 2011 (UTC)[reply]
I just added the optional parameter {{{pub}}}. It allows one to insert the date manually. When I get around to it, I'll try and get all the dates to be formatted properly (ATM, they're all formatted in the way the date is entered, in defiance of the individual style guides, which sort of defeats the point, but with some {{#formatdate:}} hackery it shouldn't be too hard.
Cite this article
Bibliographic details
  • Page name: Wikinews:Water cooler/proposals/archives/2011/April
  • Author: Wikinews contributors
  • Publisher: Wikinews
  • Date of last revision: April 27, 2020, 01:32 UTC
  • Date retrieved: December 18, 2024, 10:27 UTC
  • Permanent link: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-
  • Page version ID: -
See the general disclaimer before citing Wikinews in an academic work.
APA style

Wikinews:Water cooler/proposals/archives/2011/April. (2020, April 27). In Wikinews. Retrieved 10:27, December 18, 2024, from //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-

MLA style

Wikinews contributors. "Wikinews:Water cooler/proposals/archives/2011/April." Wikinews. Wikinews, 27 Apr. 2020. Web. 18 Dec. 2024

MHRA style

Wikinews contributors, 'Wikinews:Water cooler/proposals/archives/2011/April', Wikinews, 27 April 2020, 01:32 UTC, <//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-> [accessed 18 December 2024]

Chicago style

Wikinews contributors, "Wikinews:Water cooler/proposals/archives/2011/April," Wikinews, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (accessed December 18, 2024).

CBE/CSE style

Wikinews contributors. Wikinews:Water cooler/proposals/archives/2011/April [Internet]. Wikinews; 2020 Apr 27, 01:32 UTC [cited 2024 Dec 18]. Available from: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-.

Bluebook style

Wikinews:Water cooler/proposals/archives/2011/April, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (last visited Dec. 18, 2024).

Bluebook: Harvard JOLT style

Wikinews, Wikinews:Water cooler/proposals/archives/2011/April, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (optional description here) (as of Dec. 18, 2024, 10:27 UTC).

AMA style

Wikinews contributors. Wikinews:Water cooler/proposals/archives/2011/April. Wikinews. April 27, 2020, 01:32 UTC. Available at: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-. Accessed December 18, 2024

BibTeX entry
See also: BibTeX
@misc{ wiki:xxx,
  author = "Wikinews contributors",
  title = "Wikinews:Water cooler/proposals/archives/2011/April --- Wikinews",
  year = "2020",
  url = "//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-",
  note = "[Online; accessed 18-December-2024]"
}
When using the LaTeX package url (\usepackage{url} somewhere in the preamble), which tends to give much more nicely formatted web addresses, the following may be preferred:
@misc{ wiki:xxx,
  author = "Wikinews contributors",
  title = "Wikinews:Water cooler/proposals/archives/2011/April --- Wikinews",
  year = "2020",
  url = "\url{//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-}",
  note = "[Online; accessed 18-December-2024]"
}
Wikinews related news

* {{Wikinews|Wikinews:Water cooler/proposals/archives/2011/April|April 27, 2020}}}

which gives
Wikinews discussions

[[Wikinews:Water cooler/proposals/archives/2011/April]] ([//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- revision -])

which gives

Wikinews:Water cooler/proposals/archives/2011/April (revision -).

Wikipedia

{{Cite web|url=//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-|title=Wikinews:Water cooler/proposals/archives/2011/April|author=Wikinews contributors|authorlink=English Wikinews|date=April 27, 2020|work=English Wikinews|publisher=Wikinews|accessdate=December 18, 2024}}

Note: Some Wikipedians do not consider Wikinews a reliable source; consider placing {{Wikinews|Wikinews:Water cooler/proposals/archives/2011/April}} in a "See also" or "External links" section instead.
Note: The dates and times listed above are all in UTC. The date is that of the last edit—you may wish to use the date of publication instead.

DENDODGE 14:25, 15 April 2011 (UTC)[reply]

Actually, I decided it would be simpler for everyone to use three parameters, y, m, and, d, instead. Hence {{User:Dendodge/Sandbox|y=1984|m=01|d=31}} makes:

Cite this article
Bibliographic details
  • Page name: Wikinews:Water cooler/proposals/archives/2011/April
  • Author: Wikinews contributors
  • Publisher: Wikinews
  • Date of publication: January 31, 1984
  • Date of last revision: April 27, 2020, 01:32 UTC
  • Date retrieved: December 18, 2024, 10:27 UTC
  • Permanent link: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-
  • Page version ID: -
See the general disclaimer before citing Wikinews in an academic work.
APA style

Wikinews:Water cooler/proposals/archives/2011/April. (1984, January 31). In Wikinews. Retrieved 10:27, December 18, 2024, from //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-

MLA style

Wikinews contributors. "Wikinews:Water cooler/proposals/archives/2011/April." Wikinews. Wikinews, 31 Jan. 1984. Web. 18 Dec. 2024

MHRA style

Wikinews contributors, 'Wikinews:Water cooler/proposals/archives/2011/April', Wikinews, 31 January 1984, 01:32 UTC, <//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-> [accessed 18 December 2024]

Chicago style

Wikinews contributors, "Wikinews:Water cooler/proposals/archives/2011/April," Wikinews, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (accessed December 18, 2024).

CBE/CSE style

Wikinews contributors. Wikinews:Water cooler/proposals/archives/2011/April [Internet]. Wikinews; 1984 Jan 31, 01:32 UTC [cited 2024 Dec 18]. Available from: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-.

Bluebook style

Wikinews:Water cooler/proposals/archives/2011/April, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (last visited Dec. 18, 2024).

Bluebook: Harvard JOLT style

Wikinews, Wikinews:Water cooler/proposals/archives/2011/April, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (optional description here) (as of Dec. 18, 2024, 10:27 UTC).

AMA style

Wikinews contributors. Wikinews:Water cooler/proposals/archives/2011/April. Wikinews. January 31, 1984, 01:32 UTC. Available at: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-. Accessed December 18, 2024

BibTeX entry
See also: BibTeX
@misc{ wiki:xxx,
  author = "Wikinews contributors",
  title = "Wikinews:Water cooler/proposals/archives/2011/April --- Wikinews",
  year = "1984",
  url = "//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-",
  note = "[Online; accessed 18-December-2024]"
}
When using the LaTeX package url (\usepackage{url} somewhere in the preamble), which tends to give much more nicely formatted web addresses, the following may be preferred:
@misc{ wiki:xxx,
  author = "Wikinews contributors",
  title = "Wikinews:Water cooler/proposals/archives/2011/April --- Wikinews",
  year = "1984",
  url = "\url{//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-}",
  note = "[Online; accessed 18-December-2024]"
}
Wikinews related news

* {{Wikinews|Wikinews:Water cooler/proposals/archives/2011/April|January 31, 1984}}}

which gives
Wikinews discussions

[[Wikinews:Water cooler/proposals/archives/2011/April]] ([//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- revision -])

which gives

Wikinews:Water cooler/proposals/archives/2011/April (revision -).

Wikipedia

{{Cite web|url=//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-|title=Wikinews:Water cooler/proposals/archives/2011/April|author=Wikinews contributors|authorlink=English Wikinews|date=January 31, 1984|work=English Wikinews|publisher=Wikinews|accessdate=December 18, 2024}}

Note: Some Wikipedians do not consider Wikinews a reliable source; consider placing {{Wikinews|Wikinews:Water cooler/proposals/archives/2011/April}} in a "See also" or "External links" section instead.
Note: The dates and times listed above are all in UTC.

Hopefully, that should work. DENDODGE 14:55, 15 April 2011 (UTC)[reply]

I also fixed the time thing, hence {{User:Dendodge/Sandbox|y=1984|m=01|d=31|t=17:01}} makes:
Cite this article
Bibliographic details
  • Page name: Wikinews:Water cooler/proposals/archives/2011/April
  • Author: Wikinews contributors
  • Publisher: Wikinews
  • Date of publication: January 31, 1984, 17:01 UTC
  • Date of last revision: April 27, 2020, 01:32 UTC
  • Date retrieved: December 18, 2024, 10:27 UTC
  • Permanent link: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-
  • Page version ID: -
See the general disclaimer before citing Wikinews in an academic work.
APA style

Wikinews:Water cooler/proposals/archives/2011/April. (1984, January 31). In Wikinews. Retrieved 10:27, December 18, 2024, from //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-

MLA style

Wikinews contributors. "Wikinews:Water cooler/proposals/archives/2011/April." Wikinews. Wikinews, 31 Jan. 1984. Web. 18 Dec. 2024

MHRA style

Wikinews contributors, 'Wikinews:Water cooler/proposals/archives/2011/April', Wikinews, 31 January 1984, 17:01 UTC, <//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-> [accessed 18 December 2024]

Chicago style

Wikinews contributors, "Wikinews:Water cooler/proposals/archives/2011/April," Wikinews, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (accessed December 18, 2024).

CBE/CSE style

Wikinews contributors. Wikinews:Water cooler/proposals/archives/2011/April [Internet]. Wikinews; 1984 Jan 31, 17:01 UTC [cited 2024 Dec 18]. Available from: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-.

Bluebook style

Wikinews:Water cooler/proposals/archives/2011/April, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (last visited Dec. 18, 2024).

Bluebook: Harvard JOLT style

Wikinews, Wikinews:Water cooler/proposals/archives/2011/April, //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- (optional description here) (as of Dec. 18, 2024, 10:27 UTC).

AMA style

Wikinews contributors. Wikinews:Water cooler/proposals/archives/2011/April. Wikinews. January 31, 1984, 17:01 UTC. Available at: //en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-. Accessed December 18, 2024

BibTeX entry
See also: BibTeX
@misc{ wiki:xxx,
  author = "Wikinews contributors",
  title = "Wikinews:Water cooler/proposals/archives/2011/April --- Wikinews",
  year = "1984",
  url = "//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-",
  note = "[Online; accessed 18-December-2024]"
}
When using the LaTeX package url (\usepackage{url} somewhere in the preamble), which tends to give much more nicely formatted web addresses, the following may be preferred:
@misc{ wiki:xxx,
  author = "Wikinews contributors",
  title = "Wikinews:Water cooler/proposals/archives/2011/April --- Wikinews",
  year = "1984",
  url = "\url{//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-}",
  note = "[Online; accessed 18-December-2024]"
}
Wikinews related news

* {{Wikinews|Wikinews:Water cooler/proposals/archives/2011/April|January 31, 1984}}}

which gives
Wikinews discussions

[[Wikinews:Water cooler/proposals/archives/2011/April]] ([//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=- revision -])

which gives

Wikinews:Water cooler/proposals/archives/2011/April (revision -).

Wikipedia

{{Cite web|url=//en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=-|title=Wikinews:Water cooler/proposals/archives/2011/April|author=Wikinews contributors|authorlink=English Wikinews|date=January 31, 1984|work=English Wikinews|publisher=Wikinews|accessdate=December 18, 2024}}

Note: Some Wikipedians do not consider Wikinews a reliable source; consider placing {{Wikinews|Wikinews:Water cooler/proposals/archives/2011/April}} in a "See also" or "External links" section instead.
Note: The dates and times listed above are all in UTC.

DENDODGE 15:04, 15 April 2011 (UTC)[reply]
With javascript turned off, this monster takes up more space than many (most?) articles. Whereas with javascript turned off it should be either zero-footprint, or a link to some page of related information (how to turn on javascript?). --Pi zero (talk) 16:29, 15 April 2011 (UTC)[reply]
Well, I'm not sure how to go about doing that. Do you have any idea (maybe CSS can do it)? DENDODGE 16:32, 15 April 2011 (UTC)[reply]
Personally I think its a little too much. I'd prefer to just have the extension on wikipedia enabled here (Since that is an extension already enabled on a Wikimedia project, it wouldn't be too much trouble to enable it here). At the end of the day, not too many people want to cite us, so we shouldn't give undue prominence to the citation box. (However with that said, I'd like to mention that it does look like you worked quite hard on this). [as an aside, I should mention hacks to make this work when there is no js are possible] Bawolff ☺☻ 17:12, 15 April 2011 (UTC)[reply]
The problem with implementing the same extension as enWP is that it uses the date of the last revision, and ideally we would use the date of publication instead. I don't know how easy it would be to modify the extension, but since that would need a code review, we may be waiting quite some time for implementation. Of course, I'm happy with whatever we do—I just enjoyed the challenge of making the template. DENDODGE 17:11, 16 April 2011 (UTC)[reply]

I just got COinS working! If you view this page with a citation manager (such as Zotero) installed, you should now have an easy way to import its bibliographic details. Just so you know :) DENDODGE 17:48, 15 April 2011 (UTC)[reply]

Nice one Dendodge! COinS data is great and adding it was on my to-do list. As for the collapsible box I have to agree with Bawolff, it seems like a bit too much clutter to put on every article for only a few people who will want to use it. Installing the Cite extension would be a better solution, and should be fairly easy to do. the wub "?!" 18:01, 15 April 2011 (UTC)[reply]
Well done Dendodgicus! Ave! :D Diego Grez return fire 19:24, 15 April 2011 (UTC)[reply]

┌──────┘
 Isn't this just a more "respectable" version of the social bookmarks? If so, why shouldn't it just be an icon in that template? --Brian McNeil / talk 21:20, 16 April 2011 (UTC)[reply]

That's a thought. Clicking an icon in {{Social bookmarks}} could bring up a box like this using JavaScript—that would appear to solve all our problems—if Bawolff says it's possible, of course. DENDODGE 21:22, 16 April 2011 (UTC)[reply]

COinS

Wikipedia has had COinS data in its various source templates for quite some time, and the response appears to have been positive. Implementing it here would be very simple, if anyone's interested. I have already made the necessary modifications to {{Source}} at User:Dendodge/Sandbox/2 (which is the only source template we ever really use; the others can all be done with minor modifications of that code).

Obviously, that only applies to sources. To get COinS code for an article, we will need some kind of template with date parameters, like the one in the section above except invisible and consisting only of the COinS part—or, of course, the "Cite this article" template I proposed above.

COinS code is as ugly as Nicole de Boer is beautiful, but it's really useful for various bibliography management tools, and for citing WN in general. Would anybody object to me copying my code over to {{Source}}? DENDODGE 18:31, 15 April 2011 (UTC)[reply]

Not a fan of having a literal COinS data inside a display none span (display:none span is visible to people who use lynx for example). If we must have something there, how about a zero-width space, or something like that. Or preferably have the span suround the entire citation (if thats allowed by coins standard). Bawolff ☺☻ 18:47, 15 April 2011 (UTC)[reply]
You can put whatever you like inside the span, as long as the span has something in it. Putting it around the citation would be a good idea. I'll go do it now. :) DENDODGE 18:49, 15 April 2011 (UTC)[reply]
The problem is that COinS data has to be embedded in a title element, so a mouseover reveals all the ugly, ugly, text. A non-breaking space at the end of the citation, therefore, might be a good idea. An example of the ugly mouseover appears below:
Hover over any part of that and you'll see just how ugly it is. Thus, I would suggest a display:none span with a non-breaking space inside. That way, most users won't see anything (but their browser will still parse the COinS data, of course), and users with CSS disabled will get a very small piece of space immediately after the citation that brings up a strange mouse-over—they probably won't even notice it's there. Thoughts? DENDODGE 12:40, 16 April 2011 (UTC)[reply]
Yep, that's how it's implemented on Wikipedia too. Works for me. the wub "?!" 15:24, 16 April 2011 (UTC)[reply]
Well, in that case, I'll go ahead and change it. The example above should remain static, while the example below will soon change to have no ugly title text.
DENDODGE 15:26, 16 April 2011 (UTC)[reply]
(Outdenting because this is a separate thread of discussion on a related topic)

I went ahead and created {{COinS}}, to insert COinS data referring to the current article into a page. It takes three parameters (y, m, and d) to create the date (and defaults to the date of the last revision otherwise). A single data parameter is possible, if you prefer, but I couldn't be bothered to mess about with {{#time:}} to make sure the date is always in YYYY-MM-DD format. Of course, implementation would require Bawolff to modify EzPR, unless we include it as part of {{date}}. DENDODGE 17:08, 16 April 2011 (UTC)[reply]

I've now added a date parameter, which will accept the date in any valid format. This means that it can easily be embedded in {{date}}, as soon as there is consensus. The same is true of my modified {{source}} template. I don't want to do it unilaterally, for concern about the job queue, but I have verified that everything works just fine, if that is anybody's worry. DENDODGE 14:56, 17 April 2011 (UTC)[reply]
  Comment If we're going to mess with the {{date}} template, it'd be nice if we used the same, single edit to introduce a {{documentation}} subpage (so minimizing how many server kittens we kill; they're just so cute). --Pi zero (talk) 15:13, 17 April 2011 (UTC)[reply]
Well, it looks like Diego already went ahead and added it to {{date}}. But stuff we do inside <noinclude> tags shouldn't cause server load, should it? DENDODGE 15:15, 17 April 2011 (UTC)[reply]
I don't think the software is clever enough to realize the change made is noincluded; I understand that's one of the advantages of a documentation subpage for a high-use template (another being ability to give them different protection levels, of course). --Pi zero (talk) 15:24, 17 April 2011 (UTC)[reply]
OK, well, I'll bear that in mind in future. Since {{date}} has already been done, would anybody object if I finished the job and did it to {{source}}, too? DENDODGE 15:26, 17 April 2011 (UTC)[reply]
 
Why would you kill such a nice kitten? :)
Meh, give those techie guys/servers a bit of work while we are trying to make our wiki nicer :) Diego Grez return fire 15:17, 17 April 2011 (UTC)[reply]

Minor nits: Is there a real, documented problem? If so, is this the minimal intervention which will resolve only the real, documented problem? I mean, clearly it would be cool to have embedded Klingon fonts in every article, just in case someone doesn't have Klingon fonts on their computer since it's possible an article might use a character from a Klingon font, but I don't think it's fair to say readers have documented missing Klingon fonts as an issue on en.WN, or that embedding Klingon fonts in every en.WN article would be the minimum response even if they had. - Amgine | t 05:51, 18 April 2011 (UTC)[reply]

That's a reductio ad absurdum, and you know it. COinS does no harm to anybody, has a minimal (even negligible) effect on loading times (it's a span around a non-breaking space—we have hundreds of spans all over the place that are less useful than this, and nobody complains), and it makes things easier if, and when, somebody wants to cite us. I don't understand why people are making such a big fuss about it. You probably wouldn't even know it was there if I hadn't mentioned it here.
I, personally, use Zotero every time I write anything that would require me to cite my sources. While I have never had to cite Wikinews (but would have no qualms about doing so, especially in the case of OR), COinS makes it far, far, easier for me. I expect I'm not the only person who happens to both read Wikinews and use a citation manager...
What harm has the addition of COinS data actually done? Nothing has blown up, and we are no longer the only news source with no form of embedded microformat. If it's good enough for Wikipedia (which, as an exclusively tertiary source, shouldn't even be cited at all), it's good enough for us. DENDODGE 10:43, 18 April 2011 (UTC)[reply]
That's "exclusively tertiary source that professes not to be reliable" :-) --Pi zero (talk) 11:18, 18 April 2011 (UTC)[reply]
As an aside, the klingon font issue is currently being worked on in mediawiki land (WebFonts extension). [btw, I support adding the CoINs data - Well its slightly feature creep, I think the use case is reasonable]. Bawolff ☺☻ 22:27, 18 April 2011 (UTC)[reply]
Bawolff's response, and your own, exactly exemplify why, before solving a problem, we should find out if it really is a problem. People are working on, and maintaining, software which helps no one. Sometimes it's cool and useful eventually, but only if it addresses a real issue people really need fixed. Yes, if people use Zotero this might help them. I use Endnotes, among others. w:Comparison of reference management software shows COinS is supported by 3 of the many listed software, and is not the most-supported import format. If we support COinS, clearly we should also support other formats, and maintain all of those formats, if we are going to do it at all. A classic case of feeping creaturism, since I sincerely doubt you are willing or interested in doing the work to support an NPOV citation framework. - Amgine | t 01:38, 19 April 2011 (UTC)[reply]
TBH, I don't really care either way. I'd like to use other microformats instead/as well, but I'm not as familiar with those. I thought this might be helpful, and proposed it, then somebody else implemented it. I'll get rid of it if you like, but I don't see what harm it's doing—it doesn't even need maintaining (it does everything automatically, and the specification is unlikely to change). I would like to use other formats (hNews, perhaps?), but wouldn't know how to go about implementing those. COinS is an open format, that works with existing wikicode, without the need for any additional extensions etc., and has been in use on Wikipedia for some time—I thought it would be nice for us to have it. But, as I say, I don't really mind. DENDODGE 11:28, 19 April 2011 (UTC)[reply]
Most of the formats listed on the comparison of citation software don't really apply to us (Most of them are stand-alone text or XML formats, not microformats. Its not practical, or useful to support such formats imo). hNews doesn't have anything to do with sources (and would be difficult to support, with very little benefit). Bawolff ☺☻ 15:50, 19 April 2011 (UTC)[reply]
Dendodge, you made the best suggestion in that post. Get rid of it. If we implement one, as Amgine says above, we implement others too. Turn it off, take it out. Too little support by the available software to support us having this in place. BarkingFish (talk) 09:17, 20 April 2011 (UTC)[reply]
Did you actually read Bawolff's post? Most of the other formats are for exchanging references between programs. They can't be embedded in webpages for automated discovery. COinS may only be useful to a few people, but it harms precisely no-one and isn't difficult to support at all (bung it in template, job's a good 'un). As for arguments about server load: w:Wikipedia:Don't worry about performance. No we aren't Wikipedia, but we are thousands of times smaller. If they don't have to worry about it, we certainly shouldn't. the wub "?!" 12:31, 20 April 2011 (UTC)[reply]

Design change to the Correction template

In the spirit of good will, rather than making the change first and then discussing it later, myself and Microchip08 have been looking at ways of redesigning the {{Correction}} template to make it a little more pleasing to the eye, while still attracting people to the notice and doing the exact same job. The result of this is that we both landed on pretty much the same idea, that being a box with no background color, but a thicker red border for the attention grabbing. It would look something like this:

Correction — 2011-04-20
This is a text for æsthetics.


The other one, at least in my opinion, while being attractive, is slightly too dark and a bit strainy on the eyes to read properly. It does need to be attractive, but not eye-wateringly so. Any thoughts on this new look? Ideally, we'd like to implement this, so any suggestions are welcome.

BarkingFish (talk) 23:04, 19 April 2011 (UTC)[reply]

There's also mine and Dendodge's suggestions, although I think BarkingFish's suggestion is the best so far, and I'm all for it. {{Correction}} as it stands is rather horrible, and reeks of GeoCities. The horrible salmon pink doesn't do us any favours. Also worth considering are past iterations. — μchip08 23:13, 19 April 2011 (UTC)[reply]
See also a mockup — μchip08 23:17, 19 April 2011 (UTC)[reply]
I didn't know about Pi zero's suggestion, Microchip, thanks for linking it in :) And if you look at your top one on the page you linked, and mine above, they're near identical (no background color, 5px wide scarlet border...) BarkingFish (talk) 23:20, 19 April 2011 (UTC)[reply]
I set up my (temporary) mockup to compare Template:Correction versus User:BarkingFish/correction as they might look on an actual article.
old, new
Having seen them that way, I like the new one. Let's go with it. --Pi zero (talk) 23:25, 19 April 2011 (UTC)[reply]
On reflection, I'm not sure that massively standing out is a good idea: perhaps a more subtle, UI-blended approach is in order. Stands out enough, and will be obvious to people that read the article, but not so that it derails the user's train of thought. We could also make magic happen and change it depending on the current skin. — μchip08 23:33, 19 April 2011 (UTC)[reply]
We want it to stand out massively; it has to be so eye-catching that readers will see it first, and thereby be inoculated against being misled when they read the article text. In fact... wonder what it would look like if the bold heading, and maybe the explanation, were also in red. (Not tonight, though.) --Pi zero (talk) 01:39, 20 April 2011 (UTC)[reply]
Correction — 2011-04-20
This is a text for æsthetics.
(awful) — μchip08 01:44, 20 April 2011 (UTC)[reply]
both are awful imo. アンパロ Io ti odio! 01:56, 20 April 2011 (UTC)[reply]
More, or less awful than:
 
Correction — 2011-04-20
 

This is a test for æsthetics.
 

— μchip08 01:58, 20 April 2011 (UTC)[reply]
The three of them are a pain to my eyes. I'll think about an alternative tomorrow (today... actually). アンパロ Io ti odio! 02:01, 20 April 2011 (UTC)[reply]

Please, no glaring red. Or pink. I like the version at User:Microchip08/Boxed; if it doesn't stand out enough, maybe change the "Correction — [date]" to a red like d21415? —fetch·comms 02:20, 20 April 2011 (UTC)[reply]

Unconvinced. — μchip08 02:30, 20 April 2011 (UTC)[reply]
+1 to no red, it hurts my eyes. If there must be red, it should be in limited portions. Remember red is like blood and causes stress. Bawolff ☺☻ 02:27, 20 April 2011 (UTC)[reply]
Yes, this one looks proffessional. アンパロ Io ti odio! 02:31, 20 April 2011 (UTC)[reply]
The current problem is that that looks strange on other skins (use the links at the bottom of that page to preview them). My proposal is to use Mediawiki:Modern.css, Mediawiki:Vector.css etc to style them appropriately for each skin. — μchip08 02:36, 20 April 2011 (UTC)[reply]
It doesn't do the job, because it doesn't leap out. We need something that leaps out.
Just trying a couple of things (and not even as they look on an article, at that).

 

Correction — April 20, 2011
This is a test for æsthetics.

 

Correction — April 20, 2011
This is a test for æsthetics.

 

--Pi zero (talk) 02:51, 20 April 2011 (UTC)[reply]
Why do we need something to leap out? We just need something to differentiate to the user that it's not part of the article, not something that jars and throws the user. Most print publications acknowledge errors in the small print of page 16, and I haven't come across a news site that formats their corrections in any other way than simply inline (if they don't just silently update the article). Differentiating is enough, why do we need to do more than that? And the bottom one is at User:Microchip08/Cardboard (or near enough).—The preceding unsigned comment was added by Microchip08 (talk • contribs)
Skipping the lecture on our core ideals, a pro forma correction that appears widely removed from the thing being corrected has no need to be prominent; it might as well be on page 16, it's not going to prevent anyone from being misled when they read the original article anyway. Our situation is quite different: our correction is bundled with the thing being corrected, and we want to make sure our readers will not be misled when they read the article. So they must notice what the correction notice says before they've gone on to read the article, or they will be misled.
I agree with Gryllida, the second one will probably do the job admirably. Pending verification of what it looks like on an actual article. I'm going to try my mockup using that instead (while I can still keep my eyes open). --Pi zero (talk) 03:36, 20 April 2011 (UTC)[reply]
Okay, here they are:
old, new
Yup, does the job admirably. The red grabs your attention, but then doesn't insist on also beating you silly. --Pi zero (talk) 03:47, 20 April 2011 (UTC)[reply]
Would a less garish red be acceptable? For example, as mentioned above, #d21415? — μchip08 03:51, 20 April 2011 (UTC)[reply]
My concern is that a less garish red would fail to do the job, and it was my hope that by reducing the profile of what was red, it wouldn't be a problem — it now isn't a problem for me, and I agreed that the bright red was overbearing on several earlier variants.
But without an actual mockup of what it would look like on an article, I'm guessing. --Pi zero (talk) 04:12, 20 April 2011 (UTC)[reply]
My concern is that the one proposed by Microchip would fail to do the job. My understanding of the redesign was that it was intended to grab attention quickly, which in my own opinion, that would not do. We go from a salmon pink migraine starter to something which practically vanishes barring a bit of red writing? No. If you want me to turn the red down, I'll turn the red down, but it needs to be an attention grabber, not a "meh, there's something there we should read..." BarkingFish (talk) 09:12, 20 April 2011 (UTC)[reply]
Would anybody be opposed to changing the format depending on skin? {{box}} looks particularly out of place in Modern. — μchip08 10:41, 20 April 2011 (UTC)[reply]
Make {{box}} change depending on the skin, then use it for {{correction}}. If there needs to be some red, keep it to the title (though I'm not entirely sure that's necessary), and I would prefer a toned-down shade of red (I would support, for example, #d21415, but even with #ff0000 it looks better than what we have ATM, and better than any of the other suggestions). IMHO, we should use the skin-dependent {{box}} for various other things, too (perhaps even replacing {{ambox}}), but that's a different discussion for a different day. DENDODGE 11:25, 20 April 2011 (UTC)[reply]
Although I'm happy to see a correction notice that looks more professional, it would be entirely inappropriate for it to be painless. Bluntly, it should be painful, something we really don't want to put on our articles. I'll take a look (tonight or tomorrow) at the mockup with different shades of red, and I'll then want to go with whichever is most painful (which I'm not entirely sure will be the bring red, mind you). If it comes to a choice between the status quo and something comfortable, I'd want the status quo. --Pi zero (talk) 01:43, 21 April 2011 (UTC)[reply]
Why not use MC8's vector-like design, but with something like:

Correction — 29 August 1982

and then add a little icon or something to help catch attention? Noticeable it should be, yes; glaringly distracting, no. —fetch·comms 16:06, 21 April 2011 (UTC)[reply]
We're trying to walk a fine line here, certainly. I'm not even sure "noticeable" quite captures it. When you first look at the article, the notice should grab your attention right away, but then it shouldn't continue to drag your attention away from the article as you continue to read.
I like the red-background approach. Here it is mocked up, with several different shades of red.
ff   ee   dd   cc   aa
Of these, I like dd. (In retrospect, I should have just parameterized the mockup by shade.) --Pi zero (talk) 15:15, 22 April 2011 (UTC)[reply]
I like ee or dd. They're not too bright/glaring, but also not too dark. —fetch·comms 02:25, 23 April 2011 (UTC)[reply]

Royal wedding live blog

As I am sure many of you will know, on April 29, 2011, Prince William and Kate Middleton are to be married at Westminster Abbey in London. Arguably, this will be one of the most talked about events in Britain, if not elsewhere, this year. Therefore, latching on to the latest trend of "live blogs", which the Guardian ([2], [3], [4]), Telegraph ([5]) and BBC ([6], [7], [8]) have all begun publishing recently. The idea, if you're not familiar with it, is live updates covering a readily-changing event as it happens. (Wikinews has also done it before, too, although only once.) The idea I have is to publish a page at the beginning of April 29, and publish live updates throughout the day, with sources constantly added to the talk page. I thought I would notify you all of the idea so it can be thrashed out, and to see if anyone else in the UK (or, indeed, anywhere else) would like to help contribute. I have set up this test page in my userspace where things can be tested to see if they work or not, and anyone is free to play about with it. wackywace 14:07, 10 April 2011 (UTC)[reply]

I <3 liveblogs. —fetch·comms 22:12, 16 April 2011 (UTC)[reply]
...and I've just found out I'm busy on the special day, and won't be able to do a live blog. Ah, well. wackywace 09:18, 24 April 2011 (UTC)[reply]
...and now I'm not busy! I'm going to move the live blog into the article space; but will need someone to publish it after 0000GMT tonight, and before 0500GMT tomorrow. Any takers? wackywace 15:51, 28 April 2011 (UTC)[reply]
I might be able to. --[[::User:Nascar1996|Nascar1996]] ([[::User talk:Nascar1996|talk]] • [[::Special:Contributions/Nascar1996|contribs]]) 15:53, 28 April 2011 (UTC)
Retrieved from "https://en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/proposals/archives/2011/April&oldid=4561447"