Hi Martijn. Thanks for starting this thread.
Martijn Hoekstra [roughly] wrote:
* Catalog the problems with [dev issue]. Make a
comprehensive list that
enumerates the problems with [dev issue] we have now, categorise the
problems (right now I'm roughly thinking in style, wikitext parsing
rules and generated HTML, creation and writing issues (let's hope there
is little of this one left after Scribunto), and usability by editors).
* Note which quirks that lead to technical difficulties are used in the
wild as features rather than bugs.
* Brainstorm possible (partial) solutions.
* Find candidates that have high bang-for-buck possible solutions
without impeding future improvements much.
* Refine those solutions so we know quite exactly what it will fix, what
it won't fix, and what it would possibly break.
* Define sane fallback procedures for when things break; this should
mainly come from the editing communities, but could probably use some
guidance of what is possible/easy/logical/feasible from a technical POV
from the development community.
* Fix [dev issue].
I don't disagree with what you're saying, but I don't think it's really
specific to templates. We should roughly be following these steps for most
development issues, no?
There won't be a "one size fits all" approach to templates.
In the recent discussions/debacles about technical and
stylistic advances,
a recurring theme is that the use of some templates causes major
headaches, and a commonly heard complaint from the developers and
designers is that their products exhibit problems and shortcoming because
of that. Anecdotal evidence I've lately encountered includes:
* The mobile skin obfuscates talk page access because the templates
commonly found on talk pages makes them render horribly.
Talk page templates are dumb. We should integrate their functionality into
a MediaWiki extension. We currently have people going around assessing
articles on talk pages and adding talk page banners using iterator tools
such as AutoWikiBrowser. These are fine people and they're doing fine
work, but the mechanism by which they're doing it is sorely lacking.
We can easily store and manage page properties such as an article's
quality assessment or which WikiProjects are interested in the article in
a structured database. We already track (and can query!) by many page
properties. Let's leverage the software platform we've built.
Regardless of whether we use a built-in tool or we continue to use
templates, you're talking about trashing templates because of CSS issues.
That doesn't make much sense to me. Templates make life vastly easier. We
can likely update most talk page templates on large wikis with a single
edit to a meta-template or perhaps even just a CSS edit. That's great!
* The mobile skin special-cases some templates (notably
issue templates
and infoboxes) because they would render horribly.
Second mention of the mobile skin. Perhaps it's the mobile skin that needs
work. I think the mobile experience is horribly and painfully deficient
and flawed. Any help you can provide in trying to make it better would
surely be welcome. I've tried a few times and it only results in sadness.
* Media-viewer has a tough time doing to correct thing
with attribution
and license information because parsing template-madness is hard.
Structured data, a.k.a. Wikidata, as Brad noted.
* VE development has spent a large amount of time
around templates, and
it's still one of its weakest suits. Template substitution is still a
problem, as well as templates that produce wikitext that in itself
doesn't map cleanly to HTML tokens.
VisualEditor actually doesn't deal with wikitext, as I understand it, it
deals only with HTML. The Parsoid team deals with wikitext and they knew
what they were getting into long before this project started. There was a
commitment made to support most wikitext. And so it goes.
And as Brad notes, both VisualEditor and Parsoid will have to deal with
annoying use-cases. (Of all the features, I think {{hidden top}}-type
functionality will probably be one of the easier features to implement.)
* Scribunto has been developed specifically because
writing and
maintaining templates with more complicated logic is horrible, both
from a writers/maintainers perspective as well as from a performance
perspective
This isn't really an argument against templates. Scribunto is part of the
solution, not part of the problem. In theory, anyway.
All this together is sufficient to assert we have a
template problem.
I think there's a reasonable case to be made against specific uses of
templates (talk page templates are an easy target, as discussed above).
The steps you laid out here make sense and seem reasonable, but you'll
have to do a new pass-through of these steps for each general template
use-case you discover and wish to address. And each pass-through takes
close to a year in my experience, if not longer. And that's with dedicated
development resources.
One point that you didn't hit on which is an even easier target for
criticism is that there's currently no easy way of sharing templates
between wikis (no interwiki templates). We need to shrink the overall
number of templates by finding common patterns between wikis and smartly
sharing code _and_ man-power. If you want to make a substantive impact on
the number of templates, I'd strongly suggest figuring out a way to revive
interwiki transclusion or an equivalent sharing mechanism.
MZMcBride