<This reply is still my own personal views, and in no way represents anything official> On Tue, Sep 2, 2014 at 10:20 AM, Martijn Hoekstra &lt;martijnhoekstra(a)gmail.com If "we" (TINW) actually want dialogs (which I'm not convinced of beyond a few very special cases), trying to do it in templates with embedded code is the wrong way to do it.

On Tue, Sep 2, 2014 at 11:23 AM, Martijn Hoekstra &lt;martijnhoekstra(a)gmail.com > On Tue, Sep 2, 2014 at 4:46 PM, Brad Jorsch (Anomie) < > bjorsch(a)wikimedia.org&gt; > > > <This reply is still my own personal views, and in no way represents > > anything official> > > > > On Tue, Sep 2, 2014 at 10:20 AM, Martijn Hoekstra < > > martijnhoekstra(a)gmail.com > > > > > > > If we have to resort to such magic to make templates do what we want, > > > templates are quite simply broken; how can we explain that to a > newcomer. > > > "To help with these templates, all you have to know about are wikitext > > > templates, our own implementation of lisp, Javascript, and Lua, and > > you'll > > > be good to go". I suspect the number of people in the world who know > how > > to > > > do that is very close to 1. Especially for usecases like this, we need > > > something less complicated. > > > > > > If "we" (TINW) actually want dialogs (which I'm not convinced of beyond a > > few very special cases), trying to do it in templates with embedded code > is > > the wrong way to do it. > > > > Well, that's the discussion I'm trying to open: If that's the wrong way, is > there a right way (yet) ? I'd like to look at this from the perspective of > what the correct way would be to make that happen. > That would take a more detailed look at what is actually trying to be accomplished with these dialogs. For example, enwiki's Teahouse[1] has a dialog for newbies to more easily post questions, but it's implemented as a gadget that generates the form specific for that page. To what extent to we have actual use cases for many differently-designed dialogs? How does the lisp even enter into the current design? But in general, the answer almost certainly isn't to be doing things with a mess of complex templates with their own custom lisp dialect. [1]: https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions

To be clear, ordinary user of the dialog tools most certainly does *not* involve knowing javascript or Lua or html. The whole point is to arrange that an ordinary wiki users can do wonderful things using *only wiki markup*. (The hypothetical example of a url there is, btw, entirely wrong; but one wouldn't write any sort of url anyway.) The syntax for specifying a typical button would be more like {{dialog/view|page::Name of page}}, but most people wouldn't even have to figure that much out for themselves --- they would copy-and-modify somebody else's markup they'd found somewhere that did something similar to what they wanted, and they'd use common sense for how to modify it. That's part of the great strength of wiki markup: you do simple things, and while doing them you see other, slightly more advanced things that others have done, so later on when you find you want some of those slightly more advanced things, you've seen them before and know where to look for examples. Yes, there is in fact a lisp interpreter written in Lua. It makes up for some other weaknesses of templates. I expect most users not to have to touch that most of the time, and when they do they'll usually be able to just copy others' markup and make slight, obvious modifications. It's so vastly handy that I've used it (you've reminded me) in some of the dialog templates, just because it's so much easier to do things with it. I created it because it was obvious I'd need a powerful succinct way, without the cumbersome notational overhead of templates or Lua (or JavaScript, perish the thought), to specify transformations of the raw content of a wiki page; and the one place thus far where I use it intensively is for just such an application (removing from a wiki page all template calls of one kind, and modifying all those of another kind). I expect to be able to readily build tools, using dialogs and that lisp interpreter, to do things of the same general order as HotCat (only more sophisticated), and given the contrast between a few lines of Lisp and the JavaScript source code for HotCat, I think I'm quite justified in considering it an improvement... if it proves out. (There is some question whether this technique as currently implemented will really scale to manipulating the whole content of large wiki pages, due to practical limitations that may be imposed on the dialog tools by... the template-handling of the wiki software; but we'll see at what scale that becomes a problem, an what might be done under the hood to move the threshold when encountered.) I do agree that templates are rather broken, although frankly the Foundation could --- with some deep insight --- have done things that would have improved them. The current plethora of magic words is a mess, partly because the template call-syntax is heavy and pure template/magic-word usage keeps sending things back to typeless text; both of which problems are not shared by my embedded lisp interpreter, with it's very-low-overhead call syntax and its simple, minimal, but highly useful dynamic type system.

On Tue, Sep 2, 2014 at 12:41 PM, Brad Jorsch (Anomie) &lt;bjorsch(a)wikimedia.org I have a specific reason for disapproving of the separation. Wiki markup was incredibly successful; that's why there /is/ a wikimedian movement. It's not all been made to happen by flower-power. The two key characteristics of wiki markup that, I believe, made it work so spectacularly well are (1) It's very easy to use. It can get to be something of an awful mess at the high end, when the subtly design-flawed template mechanism gets forcibly overused, but when you get down to it, wiki markup is easy --- especially when one takes into account the second key characteristic, (2) it naturally promotes incremental learning. A while back I had a really simple edit to make to a Wikipedia page, and thought I'd try out VisualEditor on it. Eventually I gave up and did it by editing the markup. What I'd wanted to do was to add another simple item to an itemized list. The point here isn't how to do that, directly; the point is, even if I'd been a newbie with no clue how to do that, I'd have had no problem whatsoever with doing it in the absence of VE, because when I edited the markup, I'd have had examples right there in front of me of exactly how to do it. And as I think back, I learned just about everything I know about wiki markup that way. My first few edits were correcting typos, and I saw how wikilinks were done, and so on. At each stage, I'd seen examples of things just a little more advanced than what I'd done myself, because it was all right there in the markup I'd been editing, and when I wanted to do a little more than I had I'd go see how others had done similar things. But Lua is a completely different sort of language, requiring a major step --- and major steps don't belong to the wiki development pattern. Wikis work using volunteer labor because of their incremental approach, both to editing and to /learning/ to edit (and to learning how to participate in the community, but that's another subject). And, Lua is a high-overhead language. You can't just write super-simple expressions and have them work, and build other stuff up. Lisp, on the other hand, has extremely simple, unambiguous, low-overhead syntax. (Even simple template calls have more syntactic overhead than lisp function calls.) Of course, my primary goal was interactive pages, for building wizards, and it was clear to me that Lua wasn't going to help me with those anyway. Scribunto which I maintain is, for the reasons I've attempted to articulate, philosophically incompatible with the factors that make wikis successful. I might add, that I believe these things are /still/ an essential ingredient for making wikis successful, and each time the wiki experience is changed in a way that moves away from those factors, the long-term success of the movement is degraded. Scribunto isn't an improvement to templates; it's trying to half-replace them with something else. My understanding of "improve templates" would exclude a half-replacement (or full replacement), even if the half/full-replacement were to "improve *on* templates". (Actually, I do think Scribunto is an improvement on the status quo ante, but there are other routes that would have also been improvements on that, that I believe would have been better for the long-term health of the wikimedian movement.)

Pardon my long reply; I actually meant to just comment on a couple of things, and got carried away. But I really do find this topic very interesting. On Tue, Sep 2, 2014 at 2:03 PM, Brad Jorsch (Anomie) &lt;bjorsch(a)wikimedia.org&gt; wrote: The templates are extremely complicated in implementation, which is irrelevant. If templates were rejected based on extremely complicated implementation, that would rule out essentially everything that uses Scribuntu under the hood. We already have user studies (which I don't have the links for offhand) that Heh. Studies. Complete this phrase: "Lies, damn lies, and..." :-P Seriously, though, I know from direct observation there are people who have trouble with templates comparable to Wikipedian infoboxes; of course, named parameters are a rather baroque aspect of template call syntax, which I've already remarked is not as light-weight as one could wish. (Although in my experience most people don't get it overly wrong, and after being shown once what they'd not quite gotten right, usually don't get it wrong again.) It does seem a bit surprising to suggest that somebody who can't figure out how to fill in the blanks in an infobox would be more able to write in Lua. The advantage to having the complexity of Lua in modules is that the Tutorials are a /horrible/ way to convey information. As are manuals. This is one of the key weaknesses of wikis, I think, that they're atrocious at passing on wiki-expertise. Users can learn some things by the incremental path I've described, but beyond that, wikis naturally fall back on documents, because that's all the wiki software is good for specifying. Documents. Afaik, /all/ the sister projects complain that they provide these carefully written welcome templates that explain all about how to do things on that project, and nobody reads them. New variant on RTFM. I once put a welcome template on a newcomer's user talk on en.wb and they actually complained to me about it, saying they'd been to lots of different sister projects and they all annoyingly insisted on /welcoming/ them, they'd been welcomed to death, cut it out already. What I think /can/ work is an interactive wizard, where at every step the advice/help for that particular step is right there, in-your-face. Hence my intent to provide tools that enable wiki communities to build their own wizards, completely cutting out the middleman (because the wiki community is where the expertise already resides, and wikis thrive on just-do-it, cutting out the middleman). I don't think most users are going to progress from wiki markup to Lua. Certainly it requires a deeper commitment than the sort of incremental progression I'm advocating. And lowering the bar for participation is also part of what wikis are about. Sure you can; a little boilerplate is needed, but both that and the Oh, lol. What was that you were saying about cargo-cult programming? (This is meant as /good-natured/ ribbing. I invite you to laugh with me.) Seriously, cargo-cult programming, or the equivalent, is how much of wiki contribution works (I suppose we shouldn't open the cargo-cult-professional-programming can of worms). Somebody with deeper understanding might come along later and improve things, and that's good too, but that's later. I mean to avoid cutting off the long tail of users who /don't/ have some sort of programming experience. I'm not worried about those whose experience somehow leaves them able to figure out Lua but not minimalist lisp; I'm not sure that's even a nonempty set, and if it is I doubt it's all that significant. Give me your huddled masses yearning to breathe free any day. Also, most of them don't have to understand more than the surface. I'm not also sure that Lisp's extremely simple syntax is necessarily an It's possible for very compact stuff to be hard to understand because it's so compact (APL comes to mind :-). But if it's all in one place (because it's so compact) that also is an advantage. I don't find the comparison with complicated templates compelling, though; seems to me that's heavy syntax. No, I don't write the Lisp parser in JavaScript. My tools mediate transferring data between different parts of the system, remember. One of the things they can do is snarf the entire raw markup of another wiki page and feed it into the template-expansion process as a template parameter. (No, that's not easy to do, at least I don't know an easy way to do it, and it's the point at which I'm concerned the current implementation may not scale well to large wiki pages.) So the problem of transforming a page --- such as the way HotCat does, or the way the "submit for review" button on a Wikinews article does, or whatever --- is reduced to a string operation. But it's really quite a sophisticated string operation. My embedded specialized lisp dialect has primitives specifically chosen to be good at that sort of thing. I quite agree that my lisp interpreter is not improving templates, but providing in effect an alternative to them in certain cases. It's also an alternative in those cases to Scribuntu --- an alternative that remains embedded in wiki markup.

Lua makes editing templates for most users impossible. Perhaps the English community has enough users to handle all edit requests for Lua templates, most smaller wikis have too less users to do that. It is not just creating a Lua template, but also that the local communities on various wikis need to be able to maintain those templates when an update is needed or a changed is wished for. Depending on other projects is a bad scenario which is not an acceptable solution. I also do not see why it is considered easier... it is actually not easier. The general rule which is applied for the wikis I am active is that almost all templates should be editable by the majority of the community and we should not rely on a small number of users with programming skills. And learning an extra method for editing templates is the other way round, which absolutely does not make editing templates easier but creates an extra doorstep for users to do simple updates. Another general rule applied is KISS: if we can make it simple such is recommended over a complex template with little or no extra functionality. With a complex template, the first question to be asked is if a complex template is really needed. In most cases it is not. Problem solved. Romaine 2014-10-10 1:40 GMT+02:00 Matthew Flaschen &lt;mflaschen(a)wikimedia.org&gt;rg>:

On 09/02/2014 01:35 PM, pi zero wrote: I'm sorry, but both of those assertions are not only wrong, but profoundly misguided. Wikimarkup, and templates, are /relatively/ easy to use for someone who has at least a passing understanding of markup, and at least some familiarity with common computer science idioms (things like separators, arguments, substitution). That set of someones used to be a very high fraction of the original batch of editors (who were, almost by necessity, highly-computer litterate geeks). I would be surprised if it represented even a tenth of a percent of today's Internet users. The typical user, upon seeing {{something|with|stuff}}, will simply turn away saying something along the lines of "I don't know how to program". The only reason templates were a success[1] is because the original wikipedian self-selected by their ability to grok and manipulate those concepts. -- Marc [1] Furthermore, even /whether/ templates were a success is highly debatable. If I look at the current mess, and the troubles caused by it, I doubt it. I'd argue that we did great things /despite/ templates as a mechanism, not because of it.

On 2 September 2014 17:41, Brad Jorsch (Anomie) &lt;bjorsch(a)wikimedia.org&gt; wrote: Speaking generally, rather than about the specific issue at hand, I'm not sure how we can distinguish "something official" from "views as a staff developer". Am I missing something? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk

I agree with the general thrust of Brad's points. There are some known major issues with templating (styling, unreadable parser functions, and templates being used for data like Information on Commons are the most important ones). However, these do not all have the same solutions. Some issues are in a bit stalled but the idea is known (e.g. https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templa…). Others have an understood solution (e.g. Wikidata for meta-data of the sort used on Commons). Finally, I consider the "unreadable parser functions" problem essentially solved. Lua is not perfect, but it's a usable language (and not a Mediawiki-specific one) that is far more readable and writable than complicated nested parser functions. I think we should standardize on JavaScript (for interactivity) and Scribunto (for business logic that supports templates) as the on-wiki languages for non-trivial logic, leaving the wikitext template side for simple presentation. Matt Flaschen

On Sep 3, 2014 4:46 AM, "MZMcBride" &lt;z(a)mzmcbride.com&gt; wrote: Yeah there are a couple of dev issues above. This email is purposefully sent to the broadest list I could find, because it are broad issues, and the dev community is part of the audience of this list. One of the issues (but not the only issue) is that if templates were less troublesome, it would be easier for dev to make great products. It would be easy to say that is their problem, but since everyone benefits from the software being better, helping dev by reducing template madness helps all of us. advances, There are a couple of interlocking problems here. Templates are often inline styled for the desktop. Writing and maintaining inline styles is a bit cumbersome, writing good styles that work for desktop and mobile isn't all that easy, and those two amplify each other. The mobile skin does the wrong thing (stripping inline styles) because the templates have inline styles that aren't suitable for mobile, and they have to do something to get an acceptable end result. The templates don't have suitable styles for mobile because it's so hard to inline style something. If the styling of the templates becomes less cumbersome, we can start making them better suited for mobile, the mobile skin can stop special casing them, and everyone will be happier. Part of the community - the part that makes parsoid/ve - has a problem with some template uses. Ignoring the In practice too, but I think that with Scribunto enabled we can maybe start thinking about deprecating (some) parser functions, or at least throw that possibility on the table. Having a holistic solution would be nice, but starting incrementally seems viable. Also, fortunately, there are (still?) lots of us. If we can find a way to streamline and harness even a fraction of the brain- and willpower of the collective Wikimedia movement, we're golden. That's obviously a big if though - I definitely agree I can't go this alone, or that the WMF can go this alone (for various reasons) for example. Great point. iirc cross wiki Lua modules is the most popular requested Scribunto feature. The same could go for templates, though if we bring templates back to simply putting a few words in a (localised) text template and doing everything else in cross wiki Scribunto modules, it might not even be needed. I think that's the right(tm) way to use templates, but I'm not sure if we can ever give up completely the template power we have at our disposal now; they're versatile and very heavily used for some pretty awesome things. This is definitely in scope of lets improve templates though, so thank you for bringing it up. --Martijn

On Wed, Sep 3, 2014 at 10:04 AM, Wil Sinclair &lt;wllm(a)wllm.com&gt; wrote: Great to hear. Getting my ass in to gear is one of my greatest weaknesses, and from what I know from you you're really good at that. :) A "Mediawiki core templates pack" sounds like a good idea - as would making template and module interdependencies explicit to somewhat avoid the Great Tangle. aside - wikitech-l as well as #mediawiki freenode are in my experience happy to help with individual setup woes, which could help you with the acute import issues /aside Stop rushing me all y'all! ;)

I'm thinking a page on Meta to start with. I'll get round to it when I get home from work tonight CET. On Wed, Sep 3, 2014 at 11:33 AM, Wil Sinclair &lt;wllm(a)wllm.com&gt; wrote:

On Wed, Sep 3, 2014 at 6:04 PM, Wil Sinclair &lt;wllm(a)wllm.com&gt; wrote: This sounds like a bug. Does anyone know of related bugs in bugzilla? One option is to use a tool (e.g. pywikibot) to transfer each template. https://www.mediawiki.org/wiki/Manual:Pywikibot This script transferbot.py does some of the required work, but it would be nice if it was improved to detect and copy any dependencies semi-automatically. https://git.wikimedia.org/blob/pywikibot%2Fcore.git/HEAD/scripts%2Ftransfer… +1 This seems to be unrelated to templates, as they rarely depend on extensions or skins, and deploy of templates is a very different mechanism to deploy of extensions and skins. fwiw, package management systems do include separate packages for commonly needed extensions and skins. (Wouldn't it be nice if all skins could be written in Lua + LESS stored as wikipages on the wiki, instead of distributed as php files; I know of one LESS skin which works well: https://www.mediawiki.org/wiki/Skin:Chameleon ; are there others?) -- John Vandenberg