Wikinews

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

< 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.


Capitalization of author in {{source}}

What is going on with {{source}} here?

  • //en.wikinews.org/w/index.php?title=New_insulin-resistance_discovery_may_help_diabetes_sufferers&oldid=1125932#Sources

The first source downcases "ANI" to "Ani", but the third displays "AFP" correctly capitalized?

--InfantGorilla (talk) 21:09, 8 November 2010 (UTC)[reply]

Some bright spark decided that only pre-approved acronyms will capitalise. Unilaterally, as far as I know. Blood Red Sandman (Talk) (Contribs) 21:11, 8 November 2010 (UTC)[reply]
Oh dear. I feel a non-backwards compatible fix coming on. --InfantGorilla (talk) 21:15, 8 November 2010 (UTC)[reply]
It was done in August 2007. The request on the talk page leaves me still not understanding why.
Template talk:Source#Proper capitalization of author parameter
Each time we need another acronym in all caps, Template:Source gets edited to add it to the list; I added NASA about a month ago. I suppose that killed another server kitten. Of course nobody wants to simply remove the downcasing code, since they don't know what might be broken if it were removed. --Pi zero (talk) 23:28, 8 November 2010 (UTC)[reply]
Some acronyms are more important than others and deserve capitalization. Bawolff ☺☻ 00:07, 9 November 2010 (UTC)[reply]
Personally I just use WikEd. That makes switching cases easy to do manually. It doesn't have the problems associated with automated (and by their very nature unintelligent) scripts. Gopher65talk 02:28, 9 November 2010 (UTC)[reply]

Google Creates “Source” Meta Tags To Help ID Original News Sources

Google Creates “Source” Meta Tags To Help ID Original News Sources

Anyone think we should pursue this? --ShakataGaNai ^_^ 23:48, 16 November 2010 (UTC)[reply]

At a glance it sounds interesting. --SVTCobra 02:10, 17 November 2010 (UTC)[reply]
How exactly would we use these. Are we a syndication source? I imagine we'd put the original-source meta tag into the source template (to credit original sources), and put it in the OR template to credit ourselves with original-source when we do something original. Does that sound right? Bawolff ☺☻ 00:30, 19 November 2010 (UTC)[reply]

As a side note, other sites seem to have pictures associated with them in Google News. Is that something we can rectify on our end? — μ 02:11, November 19 2010 (UTC)

  • Yes, we should pursue this. At a glance, I'd say all articles should mark themselves as the syndication source. And, if there's OR involved should mark themselves as the original source. Now, these are META headers, so go in the head tag; can we do that without MW changes?
And, ų, what do you mean about images? --Brian McNeil / talk 11:06, 20 November 2010 (UTC)[reply]
No, we'd need a minor extension to do this. It would probably be a trivial extension though. For the image question - see http://www.google.com/support/news_pub/bin/answer.py?hl=en&answer=13369 . Its possible that google doesn't like that we link to image description pages instead of the image files (that used to be an issue for commons). Bawolff ☺☻ 18:10, 20 November 2010 (UTC)[reply]
If we wrote up the extension, we could probably slide it by fairly easy. I know the exp with RSS was... less than pleasant, but this is WAY less intensive. It shouldn't need to mark all articles as syndication, but simply put up the right headers when it see's the {{source}} template, or some sort of hidden text that template could kick out. --ShakataGaNai ^_^ 06:11, 22 November 2010 (UTC)[reply]
  • The points I'd make are:
  1. We are, always, a syndication source. Our articles are not syndication of others' work.
  2. We should definitely be marking ourselves as the original source when OR is involved.
  3. I don't know if crediting sources we draw from is needed, or appropriate, in regular synthesis pieces. I'd guess Google is expecting that to be used when posting verbatim copy.
Does this seem about right? --Brian McNeil / talk 10:50, 22 November 2010 (UTC)[reply]
My reading of the google page is that they expect the original-source tag to be used to credit the sources in synthesis articles. They also seem to imply that you'd use the original source or the syndication tag, which does not make sense to me. They also seem to want the original source tag to be used only for the source that broke the story, not necessarily the source that we used to write our article. [1] Bawolff ☺☻ 23:07, 22 November 2010 (UTC)[reply]
  • Yuck. But, yes, we shouldn't in any case be citing Numbnutzzz news with author Reuters or AP in any case. We should be going back to the original. I, or someone else, needs to go over this carefully. Can we have multiple META tags for this stuff? Yes, likely "gaming the system" a bit. But, if we do so in good faith, then talk to Google, we get a chance at finding more about how they use the info and expect it to be presented. --Brian McNeil / talk 23:58, 22 November 2010 (UTC)[reply]
The way I read it, multiple original-source tags seems acceptable (and perhaps even encouraged). Bawolff ☺☻ 03:04, 23 November 2010 (UTC)[reply]
Syndication source
  1. As a first approximation, we are always a syndication source.
  2. But in some cases, perhaps we aren't when we syndicate a story from another commons or public domain source, with minimal re-writing. (Present company may frown on it, but it happens now and again.) We might want to think occasionally about marking another site as the preferred syndication source.
  3. Does Google suggest how we mark an article that translates a syndicated article to/from English?

--InfantGorilla (talk) 12:44, 25 November 2010 (UTC)[reply]

Conditional template in Newarticletext?

Comments welcome on MediaWiki talk:Newarticletext#Mainspace only. --InfantGorilla (talk) 19:56, 18 November 2010 (UTC)[reply]

Flagged Revisions feature update: November 23

We are currently planning to roll out a new version of the FlaggedRevs extension to all wikis on Tuesday, November 23 starting roughly 3:15pm PST (23:15 UTC). This is used for Pending Changes on en.wikipedia.org and Flagged Revisions on many other wikis. This will have a new reject button, some diff page load optimizations to help complicated diff pages load faster by displaying the diff prior to displaying the old revision, and many under-the-hood code improvements.

We have several test environments in place with FlaggedRevs/Pending Changes configured:

Please let us know if you have any problems. Thanks! -- RobLa-WMF (talk) 07:17, 23 November 2010 (UTC)[reply]

To be fair to RobLa there were notices elsewhere, just not in places where you're average Wikinewsie would visit. The changes probably will not significantly affect us. The diff page load optimization probably won't affect us since our pages aren't long enough to have super long render times (although we might notice that it is now being loaded via ajax), The reject button is mostly a cosmetic change from my understanding. Bawolff ☺☻ 00:50, 24 November 2010 (UTC)[reply]
Reject is a hybrid between undo and rollback. It works like rollback, except it rollbacks to the last sighted revision, and it has a confirmation. Could be useful, if we have a multi-username vandal. Hitting one page. Course, undo would be just as fast:P. Gopher65talk 03:21, 24 November 2010 (UTC)[reply]
"there were notices elsewhere, just not in places where you're average Wikinewsie would visit" = "there was no notification to the end users, Wikinews" = no notice. Blood Red Sandman (Talk) (Contribs) 18:33, 25 November 2010 (UTC)[reply]

FR changes - aftermath

  • I'm not criticising the implemented changes. I'm criticising the change management. You never tell your end-users or customers (in this case, us) that a change is going in now; effectively, with zero notice. Yes, yes, MediaWiki is open source, largely driven by volunteer development... In this case it seems to have been non-problematic. However, the approach - at least from where I sit - was unprofessional, very unprofessional. It's done now; perhaps the devs will go and read up on change management post-whingeing and, get to grips with stakeholder and expectations management. --Brian McNeil / talk 10:01, 24 November 2010 (UTC)[reply]
  • Well, there ya go. I suppose this was to be expected. Wikipedia is the primary change driver, discontent there is far higher profile. The devs have done "something" - people might shut up for a couple months. This buys them enough time to do things properly - if they so choose. And, Wikinews has a history of being a willing code-tester (live, not cautious 0.001% play with alpha stuff).
Good systems work involves setting expectations. It also involves a huge amount of listening. Nine times out of ten you're not saying something can't be done but, that it is prohibitively expensive - either computationally, or in developer and data conversion hours. Once that point sinks in you can pull out the magic, questioning, truism Jimbo ran off with; "what is the problem you are trying to solve?" Once people step back from telling the devs point-by-point what code to write, you can define what should be the result or process at a higher level. We don't use DPL2 because it is, computationally, too expensive. Yet it is the 'idealised' solution to many of Wikinews' issues. That is accepted; where I get irked is devs ignoring that there is a near-ideal solution which can't realistically be deployed but, could be quickly coded with no care to performance and all "as-close-as-we-can-get" solutions compared to that.
"Developer on MediaWiki, which powers Wikipedia" won't look shiney on your CV if you show zero history of interacting with end-users and doing real requirements analysis work... The term "Unemployable Prima-Donna" springs to mind but, in Rob's case I know it's too many shouty bosses and not enough hours in the day; been there, done that. --Brian McNeil / talk 01:15, 26 November 2010 (UTC)[reply]
"We don't use DPL2 because it is, computationally, too expensive" Well that and DPL2 is full of security holes (and has a 3300 line function instead of having multiple short functions probably doesn't help matters)... Bawolff ☺☻ 11:40, 26 November 2010 (UTC)[reply]

Rss feed

Rss feed seems to have died btw. I emailed CSpurrier, hopefully he knows what is up. Bawolff ☺☻ 18:07, 28 November 2010 (UTC)[reply]

Seems to have been fixed. Bawolff ☺☻ 00:38, 29 November 2010 (UTC)[reply]
Retrieved from "https://en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/technical/archives/2010/November&oldid=1144459"