Board Thread:Lua Help/@comment-166269-20150217184425/@comment-166269-20150220160501

In regard to Wikipedia's template and Lua situation, you're trying to oversimplify a complicated issue. (And therefore, I apologize in advance for the wall of text that follows.)

Because of its visibility, Wikipedia naturally attracts a great many people, and because of the nature of the work, it tends to select specifically for technically-minded people - the same type of people you'd expect to find working on any given software project. This means there will always be a supply of editors with the ability to learn template coding and even Lua, assuming they ever spend the time and effort to do so (and my experience on Wikipedia shows me that while the number who are will always be low, it is also nonzero). So a supply of editors able and willing to write and maintain templates and modules is guaranteed for the foreseeable future. (Note that this is not an argument that the current interface is sufficient, either here or on Wikipedia, just an observation of trends. It's well-established that, generally speaking, the interface tends to be quite unfriendly to new and even some experienced editors; this was the driving force behind the development of Vector and continues to drive skin improvements today.)

The interest in using something other than the old ParserFunction-based system for templates has been around for years, far longer than Scribunto's been around. There were discussions of enabling some form of templating system utilizing a proper programming language for years before the plan for Scribunto materialized, and general sentiments stretch back even further - the development of ParserFunctions itself was originally in response to the use of template parameter logic to emulate (very, very crudely - see wikipedia:Template:Qif) basic logic control structures. For that matter, the entire Template namespace was a response to the need to be able to transclude blocks of content to multiple pages, with a certain amount of control over their display. So the interest in having some form of programmatic control over the display of pages has been present almost since day one of Wikipedia, even before anyone interested had quite realized a proper programming environment was what they actually needed or were looking for.

The specific question of Navbox being converted is similar: Navbox has had technical restrictions since day one limiting its output to 20 rows; if more than 20 were used, it caused unacceptable slowdowns in parsing of pages. Even given its limitation to 20 rows, and its high degree of optimization, though, Navbox was an absolute behemoth, and a transclusion of just four or five navboxes of a reasonable size (maybe 8-12 rows each) could be enough to significantly limit the number and nature of other templates transcluded onto a page. The citation templates were even worse; only a few more than 100 translations of them on a page could push that page over the transclusion limits, which was a significant issue for lists with even just several hundred items or for large, well-referenced articles that could not really be split. Template editors realized very early on that ParserFunctions are very limited, objectively speaking, both in terms of features they can support and in terms of server load, and they have been some of the biggest advocates for a new programming language-based system.

As to MediaWiki developers: I'm not claiming this is accurate, since I don't pay much attention to Wikimedia hiring practices, but I don't recall any new hires being announced specifically for Lua or Scribunto; as far as I can recall, that entire workload has been handled by the preexisting pool of devs.