From: Steve Summit <scs(a)eskimo.com> One of Wikipedia's big advantages, IMO, has been that it's written by the same people who are reading it. That means that in theory we tend to focus on the stuff that actually matters to our readers, optimizing our coverage and the degree of effort spent. Unfortunately as Wikipedia's syntax becomes more complex and as our internal heirarchy becomes more rigid I worry that we're losing that to a large degree. The recent mass blanking of television episode articles, for example, doesn't strike me as the sort of thing that is done to benefit the _reader_ in any meaningful way. And we still don't have anonymous article creation functionality back. Using meta-templates to simplify the creation of complex templates such as infoboxes seems like one way to ameliorate this problem, albeit a minor one.

On 21/01/2008, Peter Ansell <ansell.peter(a)gmail.com> wrote: Funny. Citation needed. Also need to show that donations wouldn't drop by a greater amount. Please explain how you would fit one in say [[Canals of Great Britain]] -- geni

From: Peter Ansell <ansell.peter(a)gmail.com> I actually can't tell whether this is intended as a serious position statement or as an over-the-top parody of deletionism. If it's parody, good show. If it's serious... good lord. _Our readers are not our enemies_. We're not some sort of noble guardians of an ivory tower, trying to fight off hordes of yokels unworthy to read our precious works of pure academia. There's no "Us" and "Them" to insert a "versus" between. The more people that find value in our content the better, no matter who they are. If bandwidth reduction is so important, how about we require login to view our pages and bounce non-logged-in viewers to answers.com or one of our other mirrors? (Yes, it's a ridiculous idea. I'm doing the parody thing there).

AboutUs.org <http://www.aboutus.org/Wikipedia.org> also makes interesting use of an infobox in every article. Their stuff is almost exclusively about web domains, so obviously it's external links and the like. But the interesting part is that they can point to a section to glean address info from (they don't do it on the wikipedia domainpage), thus being able to use a Google maps function. This might be really cool for appropriate geography articles on Wikipedia. On Jan 20, 2008 9:28 PM, Peter Ansell &lt;ansell.peter(a)gmail.com&gt; wrote:

On Jan 22, 2008 7:23 AM, SPUI &lt;drspui(a)gmail.com&gt; wrote: I just ported my OpenStreetMap plugin from de to en.wikipedia. Put importScript('User:Magnus Manske/osm.js'); on your monobook.js page (or someone make this a gadget, I'm not sure how), and on pages that have "article coordinates" (on the upper right, below the title baseline), you'll get a link that says "OSM". When you click on it, it will open a map at the top of the article. OSM is free (as in freedom), so no problem transcluding it in the article. Screenshot from de.wikipedia for Berlin: http://magnusmanske.de/wikipedia/wp_osm.png This uses one of my tools on the toolserver to generate the map parameters, and it will get coordinates from related articles and display them (the blue flag things in the screenshot). This, however, takes a few seconds. The map appears pretty quickly, though. The underlying technology is OpenLayers, a free GoogleMaps-like JavaScript. It can also use other layers, e.g., NASA WorldWind. Haven't gotten around to implement that, though. Cheers, Magnus

Steve Summit wrote: Neither doubt nor support for that statement, only an absence of factual data from reliable sources. Ec

David Gerard wrote: Indeed. They're the stealth advance guard of the Semantic Wikipedia, unwittingly beloved by lots of people who either have never heard of the "Semantic" idea, or imagine that they believe it's too theoretical or unnecessarily complicated or otherwise not for them.

Peter Ansell wrote: Oh, but I wasn't talking about the Semantic *Web*! If Semantic MediaWiki, on the other hand, is too complicated for people to use, we've got only ourselves to blame! (Me, I believe there could and ought to be a Semantic MediaWiki that would be as easy if not much easier to use than infoboxes...)

On 21/01/2008, Peter Ansell &lt;ansell.peter(a)gmail.com&gt; wrote: How would you do it for say [[Canals of Great Britain]]? -- geni

From: geni &lt;geniice(a)gmail.com&gt; If we could get those people together and have them help craft an {{infobox}} meta-template, though, that would help future editors make good infoboxes by automating and concealing that complexity.

On 1/20/08, David Gerard &lt;dgerard(a)gmail.com&gt; wrote: Well, that would in fact require changing pretty much every template except for the one(s) which is/are already in the Ideal State, if any exist. Naturally: 1. From the outset, everybody is going to disagree as to the nature of the Ideal State. 2. "Consensus", if reached, should not be abjectly averse to changes in the future. 3. Future changes will be less hampered by bureaucratic inertia if they are easier to implement (and easier to reverse) than the initial standardization process. Of course the easiest strategy would be to have all infobox templates derived from an abstract base class, i.e. a meta-template (which, when edited, would globally affect all templates inheriting their properties from it). —C.W.

Yeah, Infoboxes are a nice touch to articles: lift the heavy, bookish feel from the article and make them more Web 2.0-ish. I agree to that. That would allow a much-needed margin to be added (margin-top: 1px; margin-left: 1px; etc...), which stops the templates clashing by adding an invisible border on the outside (as oppose to padding: 1px, which adds space in the inside of the template's edges. Just a nice touch that makes it look more professional. Anthony User:AGK en.wikipedia.org On 22/01/2008, Bryan Derksen &lt;bryan.derksen(a)shaw.ca&gt; wrote:

Charlotte Webb wrote: I've completed my hijacking of [[Template:Infobox]] without any complaints being raised and have actually started using it in a few reasonably out-of-the-way places (I want to test it in the field without stumbling into any landmines in the process :). So hopefully step one is on the way. I've included the ability to override all the various styles in [[Template:Infobox]] in the same manner as [[Template:Navbox]]. But I wouldn't worry too much about that. I've done a lot of navbox work and I've found that in practice the colors are often changed, a relatively harmless modification in most cases, but the other styling characteristics are much more rarely overridden. And being able to restyle the template helps overcome resistance from editors who are guarding an old-style navbox against intruders, by allowing the guts to be changed with minimal disturbance to the outward appearance. If we didn't allow the CSS to be tweaked using parameters people would do it anyway by inserting divs and spans instead, making it much more awkward to fiddle with in the future. In some far distant time if we decide "all navboxes will have uniform color schemes without exception", we'd be able to override every last one of the overrides simply by editing the root navbox template.