On Thu, Jun 25, 2009 at 10:35 PM, Tim Starlingtstarling@wikimedia.org wrote: <snip>
The community of people who work on such templates is an extremely small, self-selected subset of the community of editors. It is that tiny segment of the community that can code in this accidental programming language, who are not deterred by its density, inconsistency or performance limitations.
There is some truth to this. However, I believe the community of people who would like to see string functions is much, much larger, than just the community of template coders. Most Wikipedians can use templates even if they don't feel comfortable creating them, and many of them have at one time or another encountered practical problems that could be solved with basic string functionality.
<snip>
Introducing a scripting language will not make those accumulated contributions disappear. The task of deciphering them, and converting them to a more accessible form, will remain.
Do you actually have a plan for introducing a scripting language?
Lua, which seems to your favored strategy, was recently LATER-ed on bugzilla by Brion, and suffers from several serious problems. For example the dependency on compiled binaries is highly undesirable. The relative power of a full programming language would require limiting its resources to avoid bad code consuming all memory or flooding Mediawiki with output, and that is only the starting point for considering the risks of malicious or overtaxing code. Not to mention that the comments at Extension talk:Lua suggest several people have failed in attempts to get the Extension working at all.
Even if one gets past that, Lua brings its own grammar, set of function keywords, and methodologies, which will again create a high barrier to participation for people wanting to work with it.
Frankly Lua feels like it creates at least as many usability and portability problems as it solves, and is still a long ways off.
Werdna's suggestion to adapt the AbuseFilter parser into a home-grown Mediawiki scripting language feels lot more natural in terms of control and ability to affect an integrated presentation, but that would also seem quite distant.
If one is going to say "no string functions until the template coding problem is solved", then I'd liked to know if there is really a serious strategy for doing that.
-Robert Rohde