I believe this example is an even clearer demonstration of the usability disaster that is parser functions. And it is just the kind of thing that can be essentially snuck into MediaWiki without the complete community consensus. Perhaps that's not the case - I would be interested in reading a more complete history of the discussions around ParserFunctions if there are significant details I am missing.
When Guido van Rossum makes a change to Python as seemingly trivial as a switch statement, he writes a formal description of the change. The change is then discussed on community mailing lists for a long period of time, and it is compared directly to other submissions. He then polls the community regarding the change at his keynote address, and rejects it if there is no popular support. http://www.python.org/dev/peps/pep-3103/
There absolutely are people out there who would like to have a larger voice in wiki syntax, WikiCreole comes to mind. These folks have usability in mind. ParserFunctions do not.
"*Any changes to the software must be gradual and reversible.* We need to make sure that any changes contribute positively to the community, as ultimately determined by everybody in Wikipedia, in full consultation with the community consensus." -- Jimmy Wales
On Sun, Jan 11, 2009 at 9:11 AM, Alex mrzmanwiki@gmail.com wrote:
Brian wrote:
I believe it is possible to expand the parser functions in place in a non-destructive way. There are always edge cases of course. But if it is not possible, it is a clear violation of a core wiki
principle
- that all changes be easily revertible.
ParserFunctions was checked into SVN in April 2006, presumably enabled around the same time. Its had nearly 3 years for ParserFunctions to integrate themselves into wikitext. By expanding them in place, you're going to be replacing the infobox syntax in articles with table syntax, hardly an improvement. To use a real example: {{Infobox Mountain | Name = Mount Blackmore | Elevation = 10,154 feet (3,094 m) | Location = [[Montana]], [[United States|USA]] | Range = [[Gallatin Range]] | Coordinates = {{coord|45|26|40|N|111|00|10|W|type:mountain_region:US}} | Topographic map = [[United States Geological Survey|USGS]] Mount Blackmore | Easiest route= Hike }}
would be replaced by something like:
{| cellpadding="5" cellspacing="0" class="infobox geography vcard" style="border:1px solid #999966; float:right; clear:right; margin-left:0.75em; margin-top:0.75em; margin-bottom:0.75em; background:#ffffff; width:305px; font-size:95%;" |- class="fn org" ! style="text-align:center; background:#e7dcc3; font-size:110%;" colspan="2"| Mount Blackmore |- |- class="note" | style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3; width:85px;" | [[Summit (topography)|Elevation]] | style="border-top:1px solid #999966; width:220px;" | 10,154 feet (3,094 m) |- | style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3;" | Location | class="label" style="border-top:1px solid #999966;" | [[Montana]], [[United States|USA]] |- | class="note" style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3;" | [[Mountain range|Range]] | style="border-top:1px solid #999966;" | [[Gallatin Range]] |- | style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3;" | [[Geographic coordinate system|Coordinates]] | style="border-top:1px solid #999966;" | {{coord|45|26|40|N|111|00|10|W|type:mountain_region:US}} |- | style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3;" | [[Topographic map|Topo map]] | style="border-top:1px solid #999966;" | [[United States Geological Survey|USGS]] Mount Blackmore |- | style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3;" | Easiest [[Climbing route|route]] | style="border-top:1px solid #999966;" | Hike |- |}
I'm not making this up. I picked a random, small infobox from an article on Special:Random, and expanded it with Special:ExpandTemplates. Like them or not, ParserFunctions do a pretty good job of hiding complex wikitext from the average user, by putting it all in the templates. Without them, you have to A) put the tables directly into articles, which is a lot worse looking than using an infobox, B) Use the infoboxes and show all the unused fields as blank (which is ugly to the readers as well), C) Go back to using the pre-ParserFunctions template hacks, or D) Replace all the infoboxes with SMW.
Of course, infoboxes aren't the only use of ParserFunctions in templates. They're used in all of the "maintenance templates" like {{cleanup}} on enwiki, I would bet there's at least one template that uses a ParserFunction on 75% or more of all the articles on enwiki. Most could be substituted a lot easier than the infoboxes, but the question is, why? Why make the wikitext in articles harder to edit by forcing templates to be replaced by tables? Why make the job of template-coders harder by making it so templates can't be as useful? Rather than 1 infobox that works for all types of settlements, we'd have to have thousands, an infobox that works for a major Chinese city wouldn't work for a small town in America.
Are you saying that we should be able to revert the software to any given revision and expect it to work fine? If we made sure every single software change was fully backwards compatible, you could bet MediaWiki would have far fewer features and a lot more bugs than it does now.
All changes are easily revertible in the short term. When changes exist for years, causing thousands of other changes as a result, how to revert them gets rather difficult (the same is somewhat true of edits to articles as well). You're proposing we install Semantic MediaWiki and rewrite the Parser in a way that will likely not be fully backwards compatible. Neither of these changes will be easily revertible once deployed, especially after 2+ years.
-- Alex (wikipedia:en:User:Mr.Z-man)
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l