On Tue, Jun 30, 2009 at 10:16 AM, Brion Vibberbrion@wikimedia.org wrote:
As many folks have noted, our current templating system works ok for simple things, but doesn't scale well -- even moderately complex conditionals or text-munging will quickly turn your template source into what appears to be line noise.
In addition to changing the programming language that is used in the template namespace a lot of progress can be made on the readability of articles (and thus how usable they are) by rethinking how we invoke templates, or rather how we make data available to templates.
If you look at the George W. Bush article you see that the first 50 lines of the article are template code and that his birthday is declared multiple times like so:
|birth_date={{birth date and age|mf=yes|1946|7|6}} born July 6, 1946 |DATE OF BIRTH=July 6, 1946
Editors clearly need a better system for declaring facts about articles and then using them in advanced template programming. One can imagine an alternate system where his birthday is only declared once, like so, in the article text: born on [[birthday::July 6, 1946]]. And so on for all the other facts listed in his infobox. Rather than declaring them explicitly in the infobox, you declare them explicitly inline in the text in a highly readable format.
Then there is the issue of calling templates. Where do you place them within the article? Much like MediaWiki itself I suggest we introduce the notion of hooks. Beginning of article, end of article. Beginning of section, end of section. Beginning of paragraph end of paragraph. Template programmers can use these hooks to inject data that is declared explicitly in the article into various points of the article.
This can be thought of as a separation of content and presentation. Articles have the constraint that their source code must, under all circumstances, be highly readable to our visitors. That way our visitors might become encyclopedia writers! Associated with those articles is another page where users can control higher level organizations of the content in the body of text. They can format it in infobox style, process it any way they like using our new programming language, and place it in a variety of locations throughout the article without sacrificing the readability of the wikitext at all.
It will take a little bit more conceptual work to handle all cases, such as inline references, etc.., etc... But the bottom line is that the source code to articles on Wikipedia has become so complicated that it is now too difficult for reasonable people to consider editing. One user said that adding a new programming language to MediaWiki is totally orthogonal to the method that we use to pass data to those programs, or the context in which those programs are called. I couldn't disagree more - one of the major reasons Wikipedia is so unreadable today is because of the way we call templates from articles. From the bottom of the design to the top, it needs to be rethought. I believe that this conversation should be held far beyond wikitech-l and should be made available to subscribers of almost all of our lists and also the large pool of contributors. One of the reasons that we ended up with ParserFunctions is that very few people were involved in the conversation. Do we even understand the problem that needs to be solved? I am not convinced that it has been adequately characterized.
2009/7/1 Brian Brian.Mingus@colorado.edu:
Editors clearly need a better system for declaring facts about articles and then using them in advanced template programming. One can imagine an alternate system where his birthday is only declared once, like so, in the article text: born on [[birthday::July 6, 1946]]. And so on for all the other facts listed in his infobox. Rather than declaring them explicitly in the infobox, you declare them explicitly inline in the text in a highly readable format.
That's the idea behind Semantic MediaWiki. What are the chances of getting that implemented on the Wikimedia wikis? (That's a very different discussion to the one we're having here, though.)
On Tue, Jun 30, 2009 at 6:54 PM, BrianBrian.Mingus@colorado.edu wrote:
On Tue, Jun 30, 2009 at 10:16 AM, Brion Vibberbrion@wikimedia.org wrote:
As many folks have noted, our current templating system works ok for simple things, but doesn't scale well -- even moderately complex conditionals or text-munging will quickly turn your template source into what appears to be line noise.
In addition to changing the programming language that is used in the template namespace a lot of progress can be made on the readability of articles (and thus how usable they are) by rethinking how we invoke templates, or rather how we make data available to templates.
If you look at the George W. Bush article you see that the first 50 lines of the article are template code and that his birthday is declared multiple times like so:
|birth_date={{birth date and age|mf=yes|1946|7|6}} born July 6, 1946 |DATE OF BIRTH=July 6, 1946
Editors clearly need a better system for declaring facts about articles and then using them in advanced template programming. One can imagine an alternate system where his birthday is only declared once, like so, in the article text: born on [[birthday::July 6, 1946]]. And so on for all the other facts listed in his infobox. Rather than declaring them explicitly in the infobox, you declare them explicitly inline in the text in a highly readable format.
Then there is the issue of calling templates. Where do you place them within the article? Much like MediaWiki itself I suggest we introduce the notion of hooks. Beginning of article, end of article. Beginning of section, end of section. Beginning of paragraph end of paragraph. Template programmers can use these hooks to inject data that is declared explicitly in the article into various points of the article.
This can be thought of as a separation of content and presentation. Articles have the constraint that their source code must, under all circumstances, be highly readable to our visitors. That way our visitors might become encyclopedia writers! Associated with those articles is another page where users can control higher level organizations of the content in the body of text. They can format it in infobox style, process it any way they like using our new programming language, and place it in a variety of locations throughout the article without sacrificing the readability of the wikitext at all.
It will take a little bit more conceptual work to handle all cases, such as inline references, etc.., etc... But the bottom line is that the source code to articles on Wikipedia has become so complicated that it is now too difficult for reasonable people to consider editing. One user said that adding a new programming language to MediaWiki is totally orthogonal to the method that we use to pass data to those programs, or the context in which those programs are called. I couldn't disagree more - one of the major reasons Wikipedia is so unreadable today is because of the way we call templates from articles. From the bottom of the design to the top, it needs to be rethought. I believe that this conversation should be held far beyond wikitech-l and should be made available to subscribers of almost all of our lists and also the large pool of contributors. One of the reasons that we ended up with ParserFunctions is that very few people were involved in the conversation. Do we even understand the problem that needs to be solved? I am not convinced that it has been adequately characterized.
I'm not sure how one would make your hook system work in a way that was practical and not totally opaque to the editor.
An idea that has been toyed with a couple of other places is to allow defined blocks and references to them in article text. For example:
An article might start:
<display name="infobox" /> Thomas Jefferson was the third president...
and at the end of the article have:
<define name="infobox"> {{infobox ... }} </define>
It would provide the flexibility to place items where needed in the article while moving the complex wikicode into a separate segment that's less likely to confuse novices. One could also call <display> multiple times if there is an element (like a birth date) that needs to be repeated in some awkward manner.
There is actually code lying around somewhere that implements such a system for <ref> so that the first call would not need to attach the full reference definition but could simply use <ref name="foo" /> if a corresponding <ref_define name="foo">...</ref> appeared later in the text.
Personally, my guess is that a system of placement by reference would make for a more flexible / less confusing approach than trying to create a system of article hooks and attach infoboxes and the like to them.
-Robert Rohde
On Tue, Jun 30, 2009 at 9:16 PM, Robert Rohderarohde@gmail.com wrote:
I'm not sure how one would make your hook system work in a way that was practical and not totally opaque to the editor.
An idea that has been toyed with a couple of other places is to allow defined blocks and references to them in article text. For example:
An article might start:
<display name="infobox" /> Thomas Jefferson was the third president...
and at the end of the article have:
<define name="infobox"> {{infobox ... }} </define>
It would provide the flexibility to place items where needed in the article while moving the complex wikicode into a separate segment that's less likely to confuse novices. One could also call <display> multiple times if there is an element (like a birth date) that needs to be repeated in some awkward manner.
There is actually code lying around somewhere that implements such a system for <ref> so that the first call would not need to attach the full reference definition but could simply use <ref name="foo" /> if a corresponding <ref_define name="foo">...</ref> appeared later in the text.
Personally, my guess is that a system of placement by reference would make for a more flexible / less confusing approach than trying to create a system of article hooks and attach infoboxes and the like to them.
Placement by reference aka "move all the nasty stuff to the bottom" :p
I think this approach would be good combined with the ability to declare facts ala `born on [[birthday::July 6, 1946]]'. That way we no longer have nasty stuff at all - we simply reference a template such as <display name="infobox" /> which gets its arguments from the facts declared in the article which called it.
The method of declaring facts in wikilinks is indeed derived from semantic mediawiki. But I just look at it as a testbed for good ideas, not as an extension for WMF to install.
2009/7/1 Robert Rohde rarohde@gmail.com:
An idea that has been toyed with a couple of other places is to allow defined blocks and references to them in article text. For example:
An article might start:
<display name="infobox" /> Thomas Jefferson was the third president...
This is a marvellous idea, and presumably a lot of the code for it is already in existence (what with <ref> etc). It'd also solve the issue with people wanting to "templatise" content such as infoboxes in order to reduce the clutter on a specific page.
Can anyone see any obvious downsides?
On Tue, Jun 30, 2009 at 8:16 PM, Robert Rohderarohde@gmail.com wrote: <snip>
An idea that has been toyed with a couple of other places is to allow defined blocks and references to them in article text. For example:
An article might start:
<display name="infobox" /> Thomas Jefferson was the third president...
and at the end of the article have:
<define name="infobox"> {{infobox ... }} </define>
It would provide the flexibility to place items where needed in the article while moving the complex wikicode into a separate segment that's less likely to confuse novices. One could also call <display> multiple times if there is an element (like a birth date) that needs to be repeated in some awkward manner.
Returning to a chunk of discussion from last week...
I wrote code as Extension:DelayedDefinition that actually implements the <define> and <display> system suggested previously. I'm not sure the WMF editing communities would actual want to go this way though. It's a pretty drastic step from the point of wikicode layout and a good WYSIWYG would be a better long-term solution to the same problem, so it may have been something of an academic exercise.
Also, there is an enormous hack in the middle of it where it makes a recursive call to Parser::parse (labeled with screaming comments). I realize doing that is the height of all evil, but the existing recursiveTagParse, Hooks, and similar don't actually seem to offer enough control to make this work properly. So, if someone were ever to actually consider this for production use, the parser would probably need to be patched to allow a more appropriate solution.
-Robert Rohde
wikimedia-l@lists.wikimedia.org