<note this reply is entirely in my personal capacity and in no way represents anything official>
On Tue, Sep 2, 2014 at 5:40 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
- The mobile skin obfuscates talk page access because the templates
commonly found on talk pages makes them render horribly.
- The mobile skin special-cases some templates (notably issue templates and
infoboxes) because they would render horribly.
I may be wrong or out of date on this, but I believe a fair bit of this comes from two issues: 1. Layout templates are sometimes designed with desktop widths in mind, so they sometimes don't respond well to smaller screens. 2. The Mobile site strips inline CSS, in an attempt to overcome item #1.
On a technical level, at least #2 is meant to be addressed by https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templat.... Then templates could have associated styles that used proper media queries.
- Media-viewer has a tough time doing to correct thing with attribution
and license information because parsing template-madness is hard.
IMO, the "structured data for Commons" initiative should have come before MediaViewer tried to incorporate attribution and licensing, rather than trying to fake it with parsing templates.
In defense of the MV folks, though, it seems that decision was made when MV had a much smaller scope for the information it would include.
- 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.
I don't think there's any way around this one, VE just needs to improve.
As much as some might like the idea of not having templates like {{hidden top}} and {{hidden bottom}}, the alternative of passing a huge wad of content into {{hidden}} doesn't seem like it's always workable.
* 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
Scribunto isn't a problem with templates, it's the solution ;)
AFAIK, templates were originally designed as just that: plug a few variables into a structure.
But then you realize that sometimes you want to be able to output bits of surrounding structure only if the variable is non-empty, or you want to pad or truncate a value, or you need to use the same variable value in a different case or percent-encoded, or you realize that it's easier to embed {{#switch:{{{var}}}|...}} instead of having 100 subtemplates and transcluding one with {{example/{{{var}}}}} or having a tree of {{#if:}}, or you need to deal with formatting times and dates, so you add parser functions.
And then people use those parser functions to start actually *programming* in templates (like taking advantage of the padding/truncation function to write really awesome/awful implementations of strlen, substr, and so on) to make the user interface of the template easier to use. But doing this programming in a language designed only for templating doesn't lead to anything easy to write or read.
Scribunto answers this by letting people program in a language designed for programming rather than hacking things up in a language designed for templating. And further, Scribunto specifically doesn't support embedding the programming code inside the templates, as allowing that would likely make readability worse rather than better. (Yes, I know some people have done crazy things like writing parsers in Lua so they can embed code in template arguments. While it's a cool hack, I think actually using it would be misguided.)