Wikinews

Wikinews:Water cooler/technical/archives/2010/September

< Wikinews:Water cooler | technical
This is an archive of past discussions from Wikinews:Water cooler/technical/archives/2010. 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.


archiving tamil wikinews

I would like to know how to archive news of age greather than 7 days. Is Category:archived is enough as what published do for publishing the news? Please help me to do it for tamil wikinews. Thanks. Mahir78 (talk) 16:57, 2 September 2010 (UTC)[reply]

The current program for archiving used on en.Wikinews can be found on the archive policy page. There are essentially three steps:
  1. An admin examines articles which are older than 7 days, checking for vandalism and changes, ensuring the article meets policy standards.
  2. The admin adds the {{archived}} template to the article, which adds both the Category:Archived and a brief note stating the article is now part of the wiki's archives.
  3. The admin Protects the article, so contributors can no longer edit the article.
I hope that answers your questions, but if not please ask more. We'll be happy to help tamil wikinews. - Amgine | t 20:20, 2 September 2010 (UTC)[reply]
Thanks for your reply.
I thought after adding template {{archived}} (with Category:Archived in it) will protect automatically (by any settings?). Anyway your points helps me to get started. Thanks a lot for your reply. - Mahir78 (talk) 14:21, 3 September 2010 (UTC)[reply]
Unfortunately, no, no one has written a bot to automatically archive articles which have had the template added. It would be very useful if someone would do so, but there is concern a vandal or new user might edit an article shortly before it is archived, damaging the article. A bot would not notice the vandalism or error, but hopefully a human would do so. - Amgine | t 01:51, 4 September 2010 (UTC)[reply]

Inputbox vs mw:Extension:CreateArticle

Inputbox is used to quickly start an article using a form textbox for the title. It's heavily modded to do searches in mediawiki databases, and in fact that's it's primary purpose these days.

Now that Wikinews no longer allows transclusion of articles, only subpages (which undoubtedly shattered a number of our archived news efforts), there are some project ideas which need to be able to create subpages, rather than main space article titles. This doesn't work for a proposed Wikinews Shorts idea using the current Inputbox extension. However, the derivative CreateArticle extension would allow automated subpage creation, and at the same time seamlessly replace Inputbox if desired (but not necessary; both extensions can work on the same mediawiki installation.)

I think we should make a bug report requesting the extension be added to en.Wikinews. Thoughts? - Amgine | t 20:28, 2 September 2010 (UTC)[reply]

Which part of the Wikinews Shorts idea that need software support? --InfantGorilla (talk) 07:59, 3 September 2010 (UTC)[reply]
Three parts:
  1. In creating the new short, it would be preferred to ensure the title begins with "In brief: ", or a similar prefix.
  2. In marking the short for review, a js tool to add the {{Review short}}.
  3. An extension to Easy Peer Review which notices the article is a short, adding the article to the current date's Wikinews Shorts (creating the short from template if it does not yet exist).
The goal of the system is to build a process which is above all easy to quickly create very brief news articles. This is all about immediate gratification, or at least only slightly delayed gratification, for both the authors and the reviewers. (These will normally be single-source, 3-4 sentences, so quick to fact-check.) - Amgine | t 01:57, 4 September 2010 (UTC)[reply]
Oh, and I was wrong about the transclusion stuff above; there is a leading colon requirement for main namespace transclusions. Boy don't I feel sheepish... - Amgine | t 01:59, 4 September 2010 (UTC)[reply]
The current effort in this direction, Wikinews Shorts: September 2, 2010, clashes badly with our peer review system. One of the transcluded articles has been published, which puts the transcluding aggregate into Category:Published. If the aggregate article got sighted, which could happen accidentally if someone got confused when they saw it in WN:Newsroom#Articles mispublished, and if there didn't also happen to be another transcluded article in some publication-blocking category like Category:Disputed, the aggregate could get published with un-peer-reviewed material in it. A different technical solution is needed. --Pi zero (talk) 16:01, 4 September 2010 (UTC)[reply]
I'm not too happy about the single source thing—the whole point of using at least two sources is to ensure neutrality. Δενδοδγε τ\c 11:24, 4 September 2010 (UTC)[reply]
I don't think single source can ever be acceptable at Wikinews. The multiple source stricture serves multiple functions. Another major one that comes to mind is verification. Juicy stories based on a single source periodically generate a mainstrean media frenzy that is followed by a smaller story about how some bad people deceived the mainstream media. Wikinews should be better than that. --Pi zero (talk) 12:50, 4 September 2010 (UTC)[reply]

Instant message

I think we should have some kind of instant messaging extention installed on this wiki to enable users to interect with each other instantly. --Saki (talk) 16:46, 5 September 2010 (UTC)[reply]

Interesting. Despite my dislike for you being on this wiki at all, I'm not going to shoot this right down. It isn't without its merits. However, it would kill the IRC channel, which is opt-in. There is really a lot of overlap to the two, such that I don't think it wholly needed (although I appreciate that people often aren't in IRC - I'm not in right now...). Also, I suspect a lot of epople would feel on-wiki conversations should remain recorded somewhere, something impractical with a messaging installation. That's a view I have a lot of sympathy for. Most people keep archives of their talk, and group discussions are always archived nowadays. Blood Red Sandman (Talk) (Contribs) 16:51, 5 September 2010 (UTC)[reply]
Well, we could set-up a logged IRC channel? --Diego Grez return fire 17:41, 5 September 2010 (UTC)[reply]
Doable, certainly: A logged one and a 'private' one (not that IRC is very private, but you aren't supposed to post stuff from it without permission). My concern is, how long would those logs get? It would, I fear, be unnavigable and hence unworkable. Blood Red Sandman (Talk) (Contribs) 19:01, 5 September 2010 (UTC)[reply]
Perhaps one channel for stuff that eventually becomes "IRC consensus." —Mikemoral♪♫ 19:05, 5 September 2010 (UTC)[reply]
I could set up one of these, with a similar interface to tools:~mwbot/ Diego Grez return fire 19:09, 5 September 2010 (UTC)[reply]

Publicly logged channel

I was bold and created the Freenode channel #wikinews-public. It is being publicly logged in the toolserver (tools:~diegogrez/wikinews-logs/) by (yet another version of) Pitsilemu. Cheers and hoping this new channel is of any help to you! Diego Grez return fire 23:19, 5 September 2010 (UTC)[reply]

Just a comment: I think this was done once before by Brian McNeil? - Amgine | t 20:09, 6 September 2010 (UTC)[reply]

Proposal: Request new "Alert:" namespace

As a response to difficulties reforming shorts and/or briefs, it is proposed that a new namespace be requested, with flagged revisions in place an associated "Alert discussion:", and comment space.

Naming is not fixed, please allow time for discussion if better options appear to exist. However, this would be a publishable namespace, pushed to GNews; a low "entry barrier" to contribution, more manageable for reviewing, and published items should serve as an advert/invite/encouragement to engage in more lengthy reportage.

Likely requirements

  1. New, Category:Published alert.
  2. New main page DPL for these.
  3. Main page adjustments to include these somewhere, have GNews pick them up, and exclude from master full-article DPL.
  4. New, {{Published alert}} template. Suggest vertical, integrate two-column {{V-Social bookmarks}} template for right side. HYS integrated, but view-only option once archived.
  5. Footer {{Alert expander}} template; suggest parameters state=[start | developing | published | archived | archived-linkedto] and title=<full article> where associated article exists, or in development.
  6. Abridged Style Guide.
  7. New/tweaked review tool; shortened/combined criteria.
  8. New sourcing template(s) to reduce their space usage.
  9. Shorter time-to-archived.

Comments, userspace proposed solutions

  • Put forward links to your template suggestions here. Avoid all category use.
  • two points;
1) the idea that 'alerts' aren't news, aren't in the main namespace, says to me they are less-valued.
2) 99% of the issue is the review process. I do not see how you can attract contributors of "this is breaking news brief" when it doesn't get reviewed for a couple days, if ever. (In my experiment 4 news events were covered within 2 hours of initial scoop, 7 within 12 hours; 1 of 7 was reviewed.) - Amgine | t 03:04, 9 September 2010 (UTC)[reply]
  • Re. your experiment: I didn't review any of them because they were marked experiment, and those I looked at first didn't seem to reach the normal standards of shorts. I thought you were testing the infrastructure, and didn't actually intend to get them published. --InfantGorilla (talk) 11:19, 9 September 2010 (UTC)[reply]
  • For obvious reasons, I couldn't work on review; IG highlights where a misunderstanding has arisen (I hope others made that same mistake, and have not just abandoned reviewer duties). I'm looking to, ideally, keep a steady stream of updates to the main page, and GNews. I think the below indicates we could. --Brian McNeil / talk 20:23, 9 September 2010 (UTC)[reply]
I hope for substantial time savings per review simply from the smaller size, and some to-be-determined time savings per page because it should be much easier for reviewers to find time to review an alert than a full article. Exactly because alerts will be reviewed faster, we need to be especially clear, from the start, on what reviewers are responsible for. (We already needed to be clearer than we officially have been about review responsibilities for full articles.) The potential for things to go badly wrong, if we're not set up properly for it, increases with speed.
It's not obvious to me (and I do want to understand this point) that the review process would change much, except for smaller scale of application. The standard five review criteria all seem relevant, though "style" has a lot less behind it; I don't get what would be gained by changing them. As for what's behind those five checkboxes, I now think I was overly optimistic when I suggested alerts would reduce the Tips checklist by about half. The only part of "The news story" that would actually go away is "Body"; "Other elements" would lose "Infobox" and at least most of "Peripherals"; and "Sources" wouldn't change at all. --Pi zero (talk) 02:10, 10 September 2010 (UTC)[reply]
  • I like this proposal, but I take no view on the technical issue of whether it needs a new namespace, or the use of categories. It will be great to review or write a fresh short in a coffee break, when I am too busy to contribute more intensively to Wikinews. My favorite prefix is Amgine's suggestion of "In brief:", but "Alert: " sounds good, and the possibility that the word will inhibit the creation of older shorts may be helpful. --InfantGorilla (talk) 11:19, 9 September 2010 (UTC)[reply]
    • This is a point Amgine might concede; the push to GNews, or spread via social networks, is a recruiting tool. Alert: will become dated where older items are highlighted, but In brief: takes too much of the limit on some, such as twitter. I'm sure his substantial vocabulary can come up with a succinct alternate - or we create a new word a-la 'tweet'. The latter is 'memetic warfare' in my way of thinking. --Brian McNeil / talk 20:23, 9 September 2010 (UTC)[reply]
      Not conceded. If you are considering using brief news articles as a recruiting tool the absolute requirement is for the contributor to see xyr work on the main page of Wikinews within, at longest, 1-2 hours. If it goes further, that's an 'attaboy'; first and foremost is getting near-instant feedback and gratification.
      If, on the other hand, you're referring to getting en.Wikinews content out and visible on the internet, thus building our 'brand' recognition and presence in the consciousness of netizens, sure. I don't know that brief news articles will be particularly supportive of that mission - WNdents would likely have greater effect - but they certainly will not harm such an effort. - Amgine | t 23:39, 10 September 2010 (UTC)[reply]

Discussion, general proposal comments

  • General comments on the feasibility, and merits, of this solution.

Alternative naming convention discussion

  • Better naming ideas? Serious flaws with as-proposed.

Votes

Please leave a few days for some input prior to voting. Keep comments associated with votes brief. --Brian McNeil / talk 00:42, 9 September 2010 (UTC)[reply]

Api issues, and gadgets sucking

API had a little boo boo (I have no idea what happened, something about the devs accidentally causing the message cache to rebuild, anyways should be over soon) and many of the gadgets are currently failing. In particular the review alert and review-progress gadgets will throw ugly error messages on every page (I've temporarily disabled the error message, hard refresh if you're seeing it). Also some other gadgets may fail silently, or give an error after using them for a bit (Easy Peer review would be the most prominent one). In any case from what i understand all should be fixed soon, but in the meantime if you see an error in a big red box, don't freak. Cheers. Bawolff ☺☻

It will be fixed as soon as the message cache has finished its rebuild. I have no idea how long that will take, but it shouldn't be much longer. BarkingFish (talk) 23:58, 16 September 2010 (UTC)[reply]
Should be fixed now, from the talk i'm overhearing, it sounds like an extension configuration item was placed after the all extensions must come before this line on http://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php Bawolff ☺☻ 00:25, 17 September 2010 (UTC)[reply]

It appears that action=parse in the api was disabled today - [1] . I don't know what the deal with that is, but in the mean time, wiktLookup won't work, and WN:ML won't do previews properly (however, it might still work otherwise, ymmv). Bawolff ☺☻ 17:36, 21 September 2010 (UTC)[reply]

for the curious, see [2]. Bawolff ☺☻ 17:52, 21 September 2010 (UTC)[reply]

Hello all,

is there interest in a gadget invoked from the edit toolbar that would provide authors with a list of potential links to Wikipedia articles (say, in a pop-up where you can check or uncheck each link suggestion, and the links will then be applied to the article)? I just met with Tal Keinan from a company called SemantiNet, and they've built a complex structured database of content from Wikipedia and other sources that, they think, would make this fairly easy to do with reasonable accuracy at disambiguation etc. They're happy to do the coding for this if there's interest here -- basically it would send the article wiki text to their web service, which would send back the Wikipedia link suggestions, which the gadget would offer in a pop-up to accept or reject. Thoughts?--Eloquence (talk) 21:08, 20 September 2010 (UTC)[reply]

en.WN articles tend already to be over-larded with en.WP links. I'd rather see links where appropriate to en.WT; at least, for those of us being mauled for using a vocabulary. - Amgine | t 22:08, 20 September 2010 (UTC)[reply]
[editconflict] Eloquence edits! Am I stuck in some weird time warp? Personally I'm a fan of links, and like to see as many as possible (where relevant obviously) to both wiktionary and wikipedia. The obvious questions about this that come to mind is: (the automatic question when someone proposes using an external web service to do something) privacy (although considering your position in the wmf you're probably much more familiar with that issue than I am). The second question is how does this compare to just taking every word in the article, seeing if an article exists with that title (possibly lopping off 's and the like)? Bawolff ☺☻ 22:55, 20 September 2010 (UTC)[reply]
Regarding the privacy issue: Given that it would be an ancillary, optional gadget that doesn't track or load anything unless users explicitly call it, I don't think it's a big deal, but it might be good to have a disclaimer visible somewhere. I don't know if they can provide Wiktionary indexing, but I'll ask. --Eloquence (talk) 07:50, 21 September 2010 (UTC)[reply]
  • I, in principle, like the idea. However, local links should always trump enWP ones. If they can present a good, proposed, functional specification I'd be happy to pick it apart in terms of applying enWN local-link policy. First, though, you might want to point them at the amazing Wiktionary hover gadget. I'd assume they have stats on frequency of specific word usage; as Amgine says, WT is under-represented in the link stakes and Wikinewsies tend to exploit the full range available in English. --Brian McNeil / talk 10:46, 21 September 2010 (UTC)[reply]
    Local links which are not news articles. That's going to be a very complex algorithm, since it would need to check the link *is* a redirect, and is to a non-main namespace (portal or category). And it needs to not be a date, of course. Using any of the word complexity scores, or just syllable count, could be used to link to en.WT if it doesn't exist on en.WN. - Amgine | t 16:34, 21 September 2010 (UTC)[reply]
  • I have to respectfully disagree that application of local-link policy is a complex algorithm. It's about four to eight bullet points in a competently written specification. For virtually all cases your picking ones where Eloquence's friends wold think a link to WP is appropriate; then, checking for a local link that is a redirect to a category or portal which, itself, is in a people or geographic category. They could have an enWN db dump on their server and the hit would be tiny. Are there no good programmers left anymore? Nobody who knows you spend 60%+ of the time getting the spec right? --Brian McNeil / talk 16:06, 22 September 2010 (UTC)[reply]
    Show me your code! specs don't bring home the data. - Amgine | t 01:35, 25 September 2010 (UTC)[reply]
Retrieved from "https://en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/technical/archives/2010/September&oldid=1110533"