Wikiversity:Colloquium/archives/March 2013

Web Standards Project closes down

Apparently the web standards project closes down. They do have a nice curriculum for web standards one could decide to copy: http://interact.webstandards.org/curriculum The license is http://creativecommons.org/licenses/by/3.0/us/. --Bernhard Fastenrath 12:39, 2 March 2013 (UTC)[reply]

Vote for the most exciting research work about Wikipedia

Hi all,

Wikimédia France launched an international research award aiming to reward the most influential research work on Wikimedia projects and free knowledge. After the initial submission of research papers by the community of researchers who study Wikimedia projects, a jury have selected five finalists among a thirty proposals. You can find summaries and full texts below :

It's now up to you to choose the most influential. For that, please visit this page : http://meta.wikimedia.org/wiki/Research:Wikimedia_France_Research_Award/nominated_papers and vote. Voting will close on Monday, March 11. The announcement of the winner is scheduled for the end of March.

If you have any question, please use the project talk page, thanks !

--CarolAnnO (discusscontribs) 09:30, 6 March 2013 (UTC)[reply]

Bot request - sandbox cleaning

Hi, I operate WillieBot (talk • email • contribs • stats • logs • global account) on other wikis. I'd like to deploy sandbox cleaning to this wiki with this script. Mono (talk) 00:13, 10 March 2013 (UTC)[reply]

User pages please

I am never sure what confidence to have in contributions where the contributor has not created a user page. There are some in the displayed contributions above. Can we appeal for everyone to create user pages for themselves as a token of their benevolent motivation? User talk pages, too, as an indication of their wish to receive communications from others. Thanks. Droflet (discusscontribs) 12:04, 10 March 2013 (UTC)[reply]

Convert complex templates to Lua to make them faster and more powerful

(Please consider translating this message for the benefit of your fellow Wikimedians)

Greetings. As you might have seen on the Wikimedia tech blog or the tech ambassadors list, a new functionality called "Lua" is being enabled on all Wikimedia sites today. Lua is a scripting language that enables you to write faster and more powerful MediaWiki templates.

If you have questions about how to convert existing templates to Lua (or how to create new ones), we'll be holding two support sessions on IRC next week: one on Wednesday (for Oceania, Asia & America) and one on Friday (for Europe, Africa & America); see m:IRC office hours for the details. If you can't make it, you can also get help at mw:Talk:Lua scripting.

If you'd like to learn about this kind of events earlier in advance, consider becoming a Tech ambassador by subscribing to the mailing list. You will also be able to help your fellow Wikimedians have a voice in technical discussions and be notified of important decisions.

Guillaume Paumier, via the Global message delivery system. 19:12, 13 March 2013 (UTC) (wrong page? You can fix it.)[reply]

Approval for posting content.

I'm interested in posting content to the C Programming course. See This page I've placed my material in a sandbox. I note that the history shows no activity for one year. Who reviews and approves my content ? If approved, who moves content from the sandbox to the actual site ? TIA

--Srfpala (discusscontribs) 20:06, 19 March 2013 (UTC) srfpala 19 March 2013[reply]

Welcome Srfpala! There's no approval process here. If it's been abandoned for a year, you can probably jump right in. But, you might consider using the topic's Discuss page first and describe what you are considering, and put a link to your sandbox since you already have it. Anyone who is watching that page will see your post, and can respond there. If you don't get a response, you should "be bold" and start improving the content.
Something to note when you provide links. External links (with http) use single brackets. Internal links to Wikiversity articles can skip the http and start at the page title, but use double brackets to surround the link.
Let us know if you have any other questions. -- Dave Braunschweig (discusscontribs) 01:38, 20 March 2013 (UTC)[reply]

Crowdsourcing research & Documenting crony capitalism

I can use help with a general research effort into Documenting crony capitalism. My goal is to crowdsource research and investigative journalism in this area. So far, I've created 3 Wikiversity pages with Category:Documenting crony capitalism. initiative on Wikiversity and elsewhere. The goal of this initiative is to crowdsource research and investigative journalism on the inner workings of w:crony capitalism in government, and thereby help ordinary humans represent their interests more effectively in the halls of power.

In this effort I could use help with some technical problems:

  1. Can the Creative commons attribution NONCOMMERCIAL share-alike (CC by nc sa) license be used on for selected portions of pages? I ask, because the Center for Responsive Politics distributes their data under the "CC by nc sa" license, which is incompatible with the standard Wikimedia "CC by sa" license. It would make this work much easier if we could have procedures for applying the noncommercial restriction to portions of pages containing analyses derived from data from the Center for Responsive Politics.
  2. How can different articles in this initiative be constructed (tagged?) to facilitate the compilation of various kinds summaries? I'm aware of Wikidata but have yet to learn enough about it to determine whether and how it might be used to support this -- or if I should be looking at something different.
  3. What's the best way to document sources of data used in Wikimedia articles and how a particular analysis can be updated? Currently, I add a sample data set and / or functions with instructions on how to obtain and use them to the 'Ecdat' package for R, available on R-Forge and the Comprehensive R Archive Network (CRAN). However, I suspect there might be a better way to do this.
  4. Is there some table facility for Wikimedia projects that is more w:WYSIWYG? The existing table facilities for the w:MediaWiki software seem fairly clumsy to me.

I'm pursuing the Documenting crony capitalism initiative in collaboration w:Lawrence Lessig's w:Rootstrikers, but I hope to extend this collaboration to other organizations that either provide relevant data or would be interested in using the results. To this end, I'm scheduled to attend the 2013 w:National Conference for Media Reform, April 4-7, and the {http://www.rootstrikers.org/conference Conference to Restore the Republic}, April 20. I hope there to recruit more people to contribute to this initiative and use the results of it.

Thanks, DavidMCEddy (discusscontribs) 00:37, 22 March 2013 (UTC)[reply]

Hi David, sorry to see your thread going unanswered thus far. Your questions are hard ones, and I will probably be of no use. I wanted to encourage and perhaps connect your project though. I recall that I might have already introduced you to User:Dblackal. He is currently running a 3rd year Investigative Journalism subject at the University of Wollongong, asking his students to attempt to get stories up in Wikinews. He and his students are very new to MediaWikis, but I thought you might recruit interest from his student group, and I think Dblackal would be personally interested in your project. Here's a Wikiversity page documenting the Wikinews assignment as it was the first time running last year. You may have to contact him off wiki however.
Regarding your questions:
  1. I don't think it will fly, but the Wikimedia projects are governed under USA copyright law, and you may be able to argue Fair Use, especially if the use is on Wikiversity. I haven't seen this tested though.
  2. I think you should use a category or a sub category for the articles (as a form of tagging)
  3. ...
  4. In the past, I used OpenOffice, now LibreOffice to create tables, and it had an export to Wikitext function that I would copy-paste into the wiki.
Hope this is of some use, or just encouraging. Good luck Leighblackall (discusscontribs) 00:43, 27 March 2013 (UTC)[reply]
  1. Non-commercial goes against Wikimedia policy. I notice the OpenSecrets website provides a link for people wishing to get permission to use information from their website for commercial use. How about contacting CRP and asking for permission to license their data under CC-BY-SA? Maybe wishful thinking, if you can figure out how or where CRP obtains its information, maybe you can discover whether the original data is in the public domain or the sources uses a freer license. Last option is to consider whether the data may fall under fair use.
  2. I think this question might need clarification for a clear answer, since you mention wikidata. Use templates to include data in multiple resources. Use categories to group related resources.
  3. See Help:Extension:Cite for how to cite sources.
  4. See Commons:Convert tables and charts to wiki code or image files -- darklama  12:22, 27 March 2013 (UTC)[reply]

A question about a Template family enhancement proposal - is this the right place?

If this is not the right place to put this technical question, please would someone say where I should ask it!

There are some additional features in the Collapse_top Template that I would find useful if they were introduced. They would be extra parameters for the header and would include text color, font family and font size. (In case you wonder, font style - bold, italic - can be changed by normal wikimarkup using single quote marks so this parameter is not needed).

These extra parameters are easy to add and I have experimented with a copy of the template in my user area in Wikiversity.

I note that the Wikiversity Collapse_top Template is NOT a copy of the mediawiki, which is puzzling.

But can I just go ahead and change the Wikiversity template (along with the documentation) or is there a good reason to retain Collapse_top in its current simplicity? Or does anyone have a watching brief on this family of Templates and would want to agree proposed changes first?

The additional items for the template would be put in the NavHead style attribute list:

Current code for Header section:

<div class="NavHead" style="background-color:{{{bg|#CCFFCC}}}; padding:0px 1em;">{{{title|{{{reason|{{{1|Extended content}}}}}}}}}</div>

Proposed:

<<div class="NavHead" style="color:{{{textcolor|}}};background-color:{{{bg|#CCFFCC}}}; padding:0px 1em; font-size: {{{titlesize|}}}; font-family:'{{{titlefont|}}}'; ">{{{title|{{{reason|{{{1|Extended content}}}}}}}}}</div>

I.e Added attributes:

  • color:
  • font-size:
  • font-family:

This set of attributes would enable a collapsible box to have a bigger header with bigger text (the header expands with the font size), in a chosen color and with chosen font. There are a number of places in the wikiversity learning project that I work on where such a 'Pretty Box' would be beneficial.

So should I change it for general use? (It would retain its compatibility with existing calls to this template because it is merely adding three optional parameters. It won't break anything!)

Or just produce a 'private' template for our own use?

Droflet (discusscontribs) 13:14, 21 March 2013 (UTC)[reply]

I vote for improving the existing template as long as it doesn't break anything. But, in the code above I see two leading << (less than signs) where I think there should be only one. Regarding approach, I'd rather see it implemented as a single style parameter, similar to how Template:Navbox and many others are implemented. This way, any style can be added as needed, rather than having to implement different parameters for the many different style options. In other words, this could be implemented simply as:
<div class="NavHead" style="background-color:{{{bg|#CCFFCC}}}; padding:0px 1em;{{{style|}}}">{{{title|{{{reason|{{{1|Extended content}}}}}}}}}</div>
If it turns out to be not quite that simple, a condition could be used so that style would replace bg and the padding instead.
Dave Braunschweig (discusscontribs) 20:11, 21 March 2013 (UTC)[reply]
Thanks for your quick response. Yes, the extra 'less than' sign was a typo.
As an erstwhile programmer I appreciate your approach which makes it generic for any style attribute you wish to use. I fear, however, it complicates it even more for those who have had enough trouble mastering the wiki markup language.
I have put in the line above that you suggested to replace mine and I finally got it to work; it is easy to make an error in the syntax in the string for the 'style' parameter passed which makes it fail to work. So I think there is an argument, for the sake of simplicity, for 'exposing' just a limited number of the most useful attributes. Actually you can do both; the last attribute set in the template overrides any value of the same attribute set earlier. So the call to the 'style' template can still go at the end for the expert to make use of.
My proposal then is that I add the specific attribute-setting parameters for
  • color: (called titletextcolor so as to distinguish it from the content text color)
  • font-size: (called titlesize) and
  • font-family: (called titlefont) plus also
  • {{{style}}}, which will be at the end.
to the NavHead line of the Collapse_top template and document this. I won't proceed until I have your approval, Dave Braunschweig, (and anyone else's comments too).
Droflet (discusscontribs) 13:03, 22 March 2013 (UTC)[reply]
Here's my concern with that approach. When we use just {{{style|}}}, when no style is provided, absolutely nothing is generated. With a line of color:{{{textcolor|}}}, when no textcolor is provided, it injects an empty color:. I suspect this won't validate, and could cause problems in browsers now or in the future. Instead, these should be generated with a conditional, something like, {{#if:{{{textcolor}}}|color:{{{textcolor}}}|}}. Note that I haven't tested this condition, but it is similar to others I've written and appears to match the documentation at http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions.
As a developer, I believe in the KISS approach. Simple and easy to maintain is better. My preference would be to just have the style parameter and keep the template itself simple, as well as consistent with other templates in the family. Otherwise, as a tie-breaker, I'd say to find examples of similar templates at wikis with more traffic (Wikipedia or Wikibooks) and see what approach they took with templates like this. Consistency is good. It allows more code sharing and requires less debugging.
Dave Braunschweig (discusscontribs) 03:38, 23 March 2013 (UTC)[reply]
What we are agreed on, then, is that it would be useful to have the {{{style}}} parameter within the Collapse_top template. I'll put that in when I get time because it certainly must have good, clear documentation to explain to the non-template-expert how to set up the compound parameter. From the developer's point of view this is a worthy application of KISS.
It adds a complication, however, from the point of view of the non-expert if that non-expert wants to use more than the basic Collapse box because setting up the parameter is not as straightforward as with other templates. Maybe we should conclude that non-experts should not even attempt to dabble in enhancing basic components! Further thought needs to be given to this in the collapse box instance.
Droflet (discusscontribs) 12:08, 23 March 2013 (UTC)[reply]
I recommend that we create a Template:Style that accepts a variety of CCS styles by name and generates the appropriate style content that could be included in calls to any of the templates that have a Style property. This provides a modular solution, allows for code reuse, and greatly simplifies all other templates needing a style parameter. Let me know if you want to give it a go on your own or if you want me to start it.
Dave Braunschweig (discusscontribs) 02:53, 25 March 2013 (UTC)[reply]

I like the idea of a generic style template. Could go a step further and implement most of the logic in Lua to normalize passed arguments to sane values, ensure decent color contrasts, and maybe allowing passing of [[File:Whatever.jpg]] as an alternative to urls for CSS attributes that can use images. -- darklama  18:04, 25 March 2013 (UTC)[reply]

Can I change my mind? I think that 'normal' wikitext editors should not be expected to use the html-type of attributes e.g. {{Collapse_top|style=height:30px;color:yellow;font-size:14pt;font-family:Comic Sans MS;padding:2px 1em; color:green|bg=blue}}. I think that they should use the wikitext parameter syntax which would be, for example, {{Collapse_top|height=30px|headtextcolor=yellow|font-size=14pt|font-family=Comic Sans MS|padding=2px 1em| color=green|bg=blue}}. The html type should be reserved for use in templates - and even Lua could be used in such expert-driven back-end processing.
This means that ALL the parameter names that a user might want to use ought to be listed and described in the documentation of the template. My current conclusion at this point in time is that this is OK for the Collapse_top template because there are very few attributes from all the possible attributes (See [1]) that are likely to be at all applicable, useful or necessary. Apart from the one already there for the Header text (I.e. background-color; padding is not actually implemented) I would suggest the only other useful ones would be (titletext)color and font-family plus perhaps font-size. (Bold and Italic can be applied by wikimarkup single quotes and size by big/small tags).
For other templates then a style template would probably be very useful on the lines you both have suggested.
So I propose that
  • (titletext)color and font-family parameters (with defaults that work) are added to the Collapse_top template and
  • a general Style template is written for use elsewhere
  • At this stage I am not suggesting any changes to the NavFrame and NavContent lines in the template (but the parameter passing documentation relating to the NavFrame part needs specifying better).
Droflet (discusscontribs) 13:03, 28 March 2013 (UTC)[reply]
The major drawback of that approach is templates can end up with a long list of parameters that need to be supported, one parameter per CSS style per html element included in the template if every single thing is to be changeable. Basically:
<div {{style|attr={{{attr|}}}|...}}><--
-->{{#if:{{{header|}}}|<div {{style|attr={{{header attr|{{{attr|}}}}}}|...}}>{{{header|}}}</div>}}<!--
--><div {{style|attr={{{title attr|{{{attr|}}}}}|...}}>{{{title|}}}</div><!--
--><div {{style|attr={{{body attr|{{{attr|}}}}}}|...}}>{{{body|}}</div><!--
-->{{#if:{{{footer|}}}|<div {{style|attr={{{footer attr|{{{attr|}}}}}}|...}}>{{{footer}}}</div>}}<!--
--></div>
Then when the template is used, a page can end up being pretty long just from all the parameters being passed:
{{some template
| attr = value
| ...
| header attr = value
| ...
| title attr = value
| ...
| body attr = value
| ...
| footer attr = value
| ...
| header = whatever | title = whatever | body = whatever | footer = whatever
}}
I think the people meant to be helped by this would end up creating another template with some preset values, just to avoid needing to remember all the parameter names and to pass all the parameters everywhere. People will do the same even if preset values are included for everything and many different preset values are desired. I know I would anyways. Is anyone really being helped by that level of flexibility if in the end people will want something simpler and easier to remember, which is the rational for all the parameters to begin with? I favor a single style parameter per element as well. A Lua style template, like {{style|style={{{style|}}}}} could make things easier by addressing common mistakes and expectations in the passed parameter, making templates more forgiving of bad values. -- darklama  14:54, 28 March 2013 (UTC)[reply]