The Lua extension (Scribunto) is now enabled on test2wiki.
Feedback would be greatly appreciated, especially if it comes in the form of bug reports and feature requests filed in the "Scribunto" component in Bugzilla.
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=Scribunto
-- Tim Starling
On Tue, Aug 14, 2012 at 7:49 PM, Tim Starling tstarling@wikimedia.org wrote:
The Lua extension (Scribunto) is now enabled on test2wiki.
Feedback would be greatly appreciated, especially if it comes in the form of bug reports and feature requests filed in the "Scribunto" component in Bugzilla.
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=Scribunto
Huzzah!
Next step is to deploy this on mediawiki.org, which we plan to do soon (as early as next week). From there, we'll need some time figuring out the performance characteristics of this (making sure we're actually coming out ahead) as well as converting some key templates over. Of course, I'm using "we" pretty loosely; Tim's largely been managing this process himself. :)
Just poking around this evening, I imported some work that TheDJ did over from scribunto.wmflabs.org over to test2, and it seems to work about as well there: http://test2.wikipedia.org/wiki/Template:Coord/testcases
It looks like there still some work to do to finish off that template, but he made a lot of progress.
One obvious target for converting to Lua would be the Cite template. It would be really great to take an article with a long parse time (e.g. the "Barack Obama" or "The Beatles"), import it to test2, and try to get the parse time down to something reasonable simply by converting the Cite+other key templates to Lua.
Rob
On Tuesday, August 14, 2012 at 11:31 PM, Rob Lanphier wrote:
One obvious target for converting to Lua would be the Cite template. It would be really great to take an article with a long parse time (e.g. the "Barack Obama" or "The Beatles"), import it to test2, and try to get the parse time down to something reasonable simply by converting the Cite+other key templates to Lua.
Template:Cite is terrifyingly complex. What are some other key templates?
There must be others like me who want the fame and fortune of being an early adopter, without all that the hard work :)
-- Ori Livneh ori@wikimedia.org
To answer my own question: http://en.wikipedia.org/wiki/Wikipedia:Database_reports/Templates_transclude...
-- Ori Livneh ori@wikimedia.org
On Monday, August 20, 2012 at 12:30 AM, Ori Livneh wrote:
On Tuesday, August 14, 2012 at 11:31 PM, Rob Lanphier wrote:
One obvious target for converting to Lua would be the Cite template. It would be really great to take an article with a long parse time (e.g. the "Barack Obama" or "The Beatles"), import it to test2, and try to get the parse time down to something reasonable simply by converting the Cite+other key templates to Lua.
Template:Cite is terrifyingly complex. What are some other key templates?
There must be others like me who want the fame and fortune of being an early adopter, without all that the hard work :)
-- Ori Livneh ori@wikimedia.org (mailto:ori@wikimedia.org)
I know if I happen to have time to learn Lua, I'd definitely tackle the ArticleHistory template. One of the more complex ones out there.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Mon, Aug 20, 2012 at 3:44 AM, Ori Livneh ori@wikimedia.org wrote:
To answer my own question:
http://en.wikipedia.org/wiki/Wikipedia:Database_reports/Templates_transclude...
-- Ori Livneh ori@wikimedia.org
On Monday, August 20, 2012 at 12:30 AM, Ori Livneh wrote:
On Tuesday, August 14, 2012 at 11:31 PM, Rob Lanphier wrote:
One obvious target for converting to Lua would be the Cite template. It would be really great to take an article with a long parse time (e.g. the "Barack Obama" or "The Beatles"), import it to test2, and try to get the parse time down to something reasonable simply by converting the Cite+other key templates to Lua.
Template:Cite is terrifyingly complex. What are some other key templates?
There must be others like me who want the fame and fortune of being an
early adopter, without all that the hard work :)
-- Ori Livneh ori@wikimedia.org (mailto:ori@wikimedia.org)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ori Livneh wrote:
On Monday, August 20, 2012 at 12:30 AM, Ori Livneh wrote:
On Tuesday, August 14, 2012 at 11:31 PM, Rob Lanphier wrote:
One obvious target for converting to Lua would be the Cite template. It would be really great to take an article with a long parse time (e.g. the "Barack Obama" or "The Beatles"), import it to test2, and try to get the parse time down to something reasonable simply by converting the Cite+other key templates to Lua.
Template:Cite is terrifyingly complex. What are some other key templates?
There must be others like me who want the fame and fortune of being an early adopter, without all that the hard work :)
To answer my own question: https://en.wikipedia.org/wiki/Wikipedia:Database_reports/Templates_transclud... _on_the_most_pages
Templates that are transcluded a lot usually are not the most complex or the most interesting.
As I understand it, brace substitution and recursion depth were/are the big performance killers with ParserFunctions.
I could swear that you used to be able to profile Parser::BraceSubstitution or something similar directly with a ?forceprofile=true or ?forcetrace=true URL parameter, but it doesn't seem to be working now. (?forceprofile=true still outputs an HTML comment with some profiling information; ?forcetrace=true seems to do nothing.)
I believe Tim has created or plans to create better profiling tools for templates. I have no idea what the status of that is.
If you're looking for other nerdy/fun templates to convert, the chess templates come to mind.
MZMcBride
Tim Starling wrote:
The Lua extension (Scribunto) is now enabled on test2wiki.
test2wiki --> https://test2.wikipedia.org
Congrats on the deployment. :-) I'll probably file a few bugs against Scribunto in the coming days.
MZMcBride
Lua is now enabled on www.mediawiki.org.
Note that this is not a temporary deployment. You can rewrite existing templates to use Lua, we're not going to break them by turning it off again.
-- Tim Starling
Hi Tim!
Would you mind you please tell me where
1) the discussion about deploying Lua on mw.org , 2) the announcement that it will be deployed on mw.org on Aug 22. 3) the roadmap and plans of further deployment of Scribunto on Wikipedias and other Wikimedia projects
...took place? I'm sure that such discussions has taken place somewhere, because if not - that's not very mature behavior for open source developer team.
----- Yury Katkov
On Wed, Aug 22, 2012 at 9:36 AM, Tim Starling tstarling@wikimedia.org wrote:
Lua is now enabled on www.mediawiki.org.
Note that this is not a temporary deployment. You can rewrite existing templates to use Lua, we're not going to break them by turning it off again.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Here it is: http://lists.wikimedia.org/pipermail/wikitech-l/2012-August/062329.html
It was on August 15 and it says "next week".
-- Amir
2012/8/22 Yury Katkov katkov.juriy@gmail.com:
Hi Tim!
Would you mind you please tell me where
- the discussion about deploying Lua on mw.org ,
- the announcement that it will be deployed on mw.org on Aug 22.
- the roadmap and plans of further deployment of Scribunto on
Wikipedias and other Wikimedia projects
...took place? I'm sure that such discussions has taken place somewhere, because if not - that's not very mature behavior for open source developer team.
Yury Katkov
On Wed, Aug 22, 2012 at 9:36 AM, Tim Starling tstarling@wikimedia.org wrote:
Lua is now enabled on www.mediawiki.org.
Note that this is not a temporary deployment. You can rewrite existing templates to use Lua, we're not going to break them by turning it off again.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'm very sorry for my bureaucratic tone: I don't want to harm anyone and I'm as excited about new feature as everybody here. That's just seems like pretty important change on a pretty big website with a big community: it's rude to just modify it in all sort of ways without prior discussions, recognizable announcements and publicly available plans. ----- Yury Katkov
On Wed, Aug 22, 2012 at 12:06 PM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
Here it is: http://lists.wikimedia.org/pipermail/wikitech-l/2012-August/062329.html
It was on August 15 and it says "next week".
-- Amir
2012/8/22 Yury Katkov katkov.juriy@gmail.com:
Hi Tim!
Would you mind you please tell me where
- the discussion about deploying Lua on mw.org ,
- the announcement that it will be deployed on mw.org on Aug 22.
- the roadmap and plans of further deployment of Scribunto on
Wikipedias and other Wikimedia projects
...took place? I'm sure that such discussions has taken place somewhere, because if not - that's not very mature behavior for open source developer team.
Yury Katkov
On Wed, Aug 22, 2012 at 9:36 AM, Tim Starling tstarling@wikimedia.org wrote:
Lua is now enabled on www.mediawiki.org.
Note that this is not a temporary deployment. You can rewrite existing templates to use Lua, we're not going to break them by turning it off again.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I have probably used very offensive English phrase without noticing, sorry: I tried to be neutral. ----- Yury Katkov
On Wed, Aug 22, 2012 at 12:11 PM, Domas Mituzas midom.lists@gmail.com wrote:
...took place? I'm sure that such discussions has taken place somewhere, because if not - that's not very mature behavior for open source developer team.
why do you have to be such an ass, by the way?
Domas
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Like Amir said, it was announced a week ago. There were no objections.
There were very few comments on the test2 deployment, probably because the Labs deployment served the same purpose.
What we want from the mediawiki.org deployment is to start building a community of people who will convert templates to Lua, not just because they want to help us test the software, but also because they want to get useful things done. Their comments will help to drive future development.
Our goal is to deploy this extension to all Wikimedia wikis. If you don't like that idea, now would be a good time to say something.
The schedule for deployment has not yet been decided. It will depend on what bug reports and feature requests are submitted by the early adopters. Performance issues may be found, once we have real-world test cases. We will need to decide how much extra development work is needed before a full-scale rollout.
It's been over a year since I started work on Lua support. From the outset, I wanted it to be a project with a constrained scope, a project that can be brought to completion, instead of trailing off into vapour. I wanted to make something happen.
So my inclination is to push for deployment with a minimum of additional development work. But I'm not the target audience; my inclinations have to be weighed against the needs of the users.
-- Tim Starling
On 22/08/12 18:01, Yury Katkov wrote:
Hi Tim!
Would you mind you please tell me where
- the discussion about deploying Lua on mw.org ,
- the announcement that it will be deployed on mw.org on Aug 22.
- the roadmap and plans of further deployment of Scribunto on
Wikipedias and other Wikimedia projects
...took place? I'm sure that such discussions has taken place somewhere, because if not - that's not very mature behavior for open source developer team.
Yury Katkov
On Wed, Aug 22, 2012 at 9:36 AM, Tim Starling tstarling@wikimedia.org wrote:
Lua is now enabled on www.mediawiki.org.
Note that this is not a temporary deployment. You can rewrite existing templates to use Lua, we're not going to break them by turning it off again.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 08/22/2012 12:18 PM, Tim Starling wrote:
So my inclination is to push for deployment with a minimum of additional development work. But I'm not the target audience; my inclinations have to be weighed against the needs of the users.
in the name of countless Wikipedians, who are struggeling with that horrible Template/Magic word/ParserFunctions syntax, I say: thank you :)
This page is dedicated to its victims: http://meta.wikimedia.org/wiki/User:Church_of_emacs/Template_love
Cheers, Tobias
I think Yury has a point. Now would be a good time to maybe discuss exactly what's going on. As exciting a feature it may be, we cannot just "deploy next week" and then have "the schedule for deployment not yet decided". Stuff like this should have a legitimate plan. Furthermore, in alignment with the previous thread on feature development, is there any hard discussion on enwiki, etc. showing the users want this feature? I know sure as hell that I'd love using this feature, but I don't represent all template developers everywhere.
Some good questions we should probably answer (if they haven't been answered already):
- Is Extension:Lua the extension being deployed? If so, why is it still in Subversion and why is it marked experimental? - What QA has been done on this extension? How many test cases have been implemented? - What are the performance impacts of using this v. regular parser functions? (Also, what is faster, PECL or external interpreter?) - Do global variables persist outside of an individual script, i.e., can one global variable be used in multiple <lua> tags in the same template? - Has there been any consideration of implementing a "standard library"? For example, functions that will allow the creation of wikitables and other mediawiki syntax. - What values for the various wgLuaMax* variables are we planning on using on WMF wikis? Has there been testing done to determine what a reasonable maximum call time is?
I probably should have looked into this more earlier, but it's been a busy week for me and I haven't had much time.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Aug 22, 2012 at 8:27 AM, Tobias church.of.emacs.ml@googlemail.comwrote:
On 08/22/2012 12:18 PM, Tim Starling wrote:
So my inclination is to push for deployment with a minimum of additional development work. But I'm not the target audience; my inclinations have to be weighed against the needs of the users.
in the name of countless Wikipedians, who are struggeling with that horrible Template/Magic word/ParserFunctions syntax, I say: thank you :)
This page is dedicated to its victims: http://meta.wikimedia.org/wiki/User:Church_of_emacs/Template_love
Cheers, Tobias
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think Yury has a point. Now would be a good time to maybe discuss exactly what's going on. As exciting a feature it may be, we cannot just "deploy next week" and then have "the schedule for deployment not yet decided".
Stuff like this should have a legitimate plan. Furthermore, in alignment with the previous thread on feature development, is there any hard discussion on enwiki, etc. showing the users want this feature? I know sure as hell that I'd love using this feature, but I don't represent all template developers everywhere.
Anyone else reminded of the recent topic:"Wikimedians are rightfully wary"
I think the sorts of things that MZMcBride was talking about in his op-ed. Sorry for the slightly off topic post, but this seemed like as good a time as any to point out a real life example.
Thank you, Derric Atzrott
On Wed, Aug 22, 2012 at 5:16 PM, Derric Atzrott datzrott@alizeepathology.com wrote:
I think Yury has a point. Now would be a good time to maybe discuss exactly what's going on. As exciting a feature it may be, we cannot just "deploy next week" and then have "the schedule for deployment not yet decided".
Stuff like this should have a legitimate plan. Furthermore, in alignment with the previous thread on feature development, is there any hard discussion on enwiki, etc. showing the users want this feature? I know sure as hell that I'd love using this feature, but I don't represent all template developers everywhere.
Anyone else reminded of the recent topic:"Wikimedians are rightfully wary"
I think the sorts of things that MZMcBride was talking about in his op-ed. Sorry for the slightly off topic post, but this seemed like as good a time as any to point out a real life example.
I don't think that the process of introducing Scribuntu, which we have been talking about for years now, compares in anyway to something like, for example, WikiLove or AFT which essentially were deployed out of nowhere (to make an hyperbole)
Bryan
----- Yury Katkov
On Wed, Aug 22, 2012 at 7:08 PM, Tyler Romeo tylerromeo@gmail.com wrote:
I think Yury has a point. Now would be a good time to maybe discuss exactly what's going on. As exciting a feature it may be, we cannot just "deploy next week" and then have "the schedule for deployment not yet decided". Stuff like this should have a legitimate plan. Furthermore, in alignment with the previous thread on feature development, is there any hard discussion on enwiki, etc. showing the users want this feature? I know sure as hell that I'd love using this feature, but I don't represent all template developers everywhere.
Some good questions we should probably answer (if they haven't been answered already):
- Is Extension:Lua the extension being deployed? If so, why is it still
in Subversion and why is it marked experimental?
as far as I can see this extensions have been deployed : http://www.mediawiki.org/wiki/Extension:Scribunto , not this one: http://www.mediawiki.org/wiki/Extension:Lua
- What QA has been done on this extension? How many test cases have been
implemented?
- What are the performance impacts of using this v. regular parser
functions? (Also, what is faster, PECL or external interpreter?)
- Do global variables persist outside of an individual script, i.e., can
one global variable be used in multiple <lua> tags in the same template?
- Has there been any consideration of implementing a "standard library"?
For example, functions that will allow the creation of wikitables and other mediawiki syntax.
- What values for the various wgLuaMax* variables are we planning on
using on WMF wikis? Has there been testing done to determine what a reasonable maximum call time is?
I probably should have looked into this more earlier, but it's been a busy week for me and I haven't had much time.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Aug 22, 2012 at 8:27 AM, Tobias church.of.emacs.ml@googlemail.comwrote:
On 08/22/2012 12:18 PM, Tim Starling wrote:
So my inclination is to push for deployment with a minimum of additional development work. But I'm not the target audience; my inclinations have to be weighed against the needs of the users.
in the name of countless Wikipedians, who are struggeling with that horrible Template/Magic word/ParserFunctions syntax, I say: thank you :)
This page is dedicated to its victims: http://meta.wikimedia.org/wiki/User:Church_of_emacs/Template_love
Cheers, Tobias
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey Tyler, Many of these issues have already been discussed on this mailing list. Read Rob and Tim's emails from last week to start with. As explained in the previous emails, the extension being deployed is Scribunto. Regarding performance testing, Rob said this would be done once the extension was deployed to mediawiki.org: "From there, we'll need some time figuring out the performance characteristics of this (making sure we're actually coming out ahead) as well as converting some key templates over." Many of the other questions are covered at https://www.mediawiki.org/wiki/Extension:Scribunto.
And not to be overly dismissive, but the idea that Tim needs to prove that en.wiki wants this feature is absurd. The template system on Wikipedia is BROKEN. It takes over 30 seconds for the parser to render large articles, and articles with a really large number of citation templates can't render at all, they simply error with a timeout. The only reason Lua/Scribunto was developed is because the en.wiki community has been vocally complaining about this problem FOR 3 YEARS. Check out https://bugzilla.wikimedia.org/show_bug.cgi?id=19262 for example.
Ryan Kaldari
On Wed, Aug 22, 2012 at 8:08 AM, Tyler Romeo tylerromeo@gmail.com wrote:
I think Yury has a point. Now would be a good time to maybe discuss exactly what's going on. As exciting a feature it may be, we cannot just "deploy next week" and then have "the schedule for deployment not yet decided". Stuff like this should have a legitimate plan. Furthermore, in alignment with the previous thread on feature development, is there any hard discussion on enwiki, etc. showing the users want this feature? I know sure as hell that I'd love using this feature, but I don't represent all template developers everywhere.
Some good questions we should probably answer (if they haven't been answered already):
- Is Extension:Lua the extension being deployed? If so, why is it still
in Subversion and why is it marked experimental?
- What QA has been done on this extension? How many test cases have been
implemented?
- What are the performance impacts of using this v. regular parser
functions? (Also, what is faster, PECL or external interpreter?)
- Do global variables persist outside of an individual script, i.e., can
one global variable be used in multiple <lua> tags in the same template?
- Has there been any consideration of implementing a "standard library"?
For example, functions that will allow the creation of wikitables and other mediawiki syntax.
- What values for the various wgLuaMax* variables are we planning on
using on WMF wikis? Has there been testing done to determine what a reasonable maximum call time is?
I probably should have looked into this more earlier, but it's been a busy week for me and I haven't had much time.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Aug 22, 2012 at 8:27 AM, Tobias church.of.emacs.ml@googlemail.comwrote:
On 08/22/2012 12:18 PM, Tim Starling wrote:
So my inclination is to push for deployment with a minimum of additional development work. But I'm not the target audience; my inclinations have to be weighed against the needs of the users.
in the name of countless Wikipedians, who are struggeling with that horrible Template/Magic word/ParserFunctions syntax, I say: thank you :)
This page is dedicated to its victims: http://meta.wikimedia.org/wiki/User:Church_of_emacs/Template_love
Cheers, Tobias
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Aug 22, 2012 at 2:39 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Hey Tyler, Many of these issues have already been discussed on this mailing list. Read Rob and Tim's emails from last week to start with. As explained in the previous emails, the extension being deployed is Scribunto. Regarding performance testing, Rob said this would be done once the extension was deployed to mediawiki.org: "From there, we'll need some time figuring out the performance characteristics of this (making sure we're actually coming out ahead) as well as converting some key templates over." Many of the other questions are covered at https://www.mediawiki.org/wiki/Extension:Scribunto.
And not to be overly dismissive, but the idea that Tim needs to prove that en.wiki wants this feature is absurd. The template system on Wikipedia is BROKEN. It takes over 30 seconds for the parser to render large articles, and articles with a really large number of citation templates can't render at all, they simply error with a timeout. The only reason Lua/Scribunto was developed is because the en.wiki community has been vocally complaining about this problem FOR 3 YEARS. Check out https://bugzilla.wikimedia.org/show_bug.cgi?id=19262 for example.
Ryan Kaldari
Furthermore, mediawiki.org is a community essentially owned by the developers, not to mention this feature is non-user facing. If people don't want to use it, they don't have to.
I do believe consensus should be sought when enabling extensions like moodbar and what not on enwikipedia, but this is nothing like that situation.
--bawolff
Ah, I thought it was the Lua extension (made sense to me at the time :P). Thanks for pointing that out.
And not to be overly dismissive, but the idea that Tim needs to prove that
en.wiki wants this feature is absurd. The template system on Wikipedia is BROKEN. It takes over 30 seconds for the parser to render large articles, and articles with a really large number of citation templates can't render at all, they simply error with a timeout. The only reason Lua/Scribunto was developed is because the en.wiki community has been vocally complaining about this problem FOR 3 YEARS. Check out https://bugzilla.wikimedia.org/show_bug.cgi?id=19262 for example.
But there's a difference between an issue and a solution. Yes, the templating system is broken, and I'm sure many an editor will confirm that, but just because a system is broken does not mean Lua is automatically the solution. To put it in other words: just because people want a better templating system does not imply they want Lua. What discussion, if any, has there been that WMF wikis want Lua as their templating replacement. As said before, mediawiki.org is mostly developers, so there's no problem with that, but with the op-ed on the Signpost, we should seriously question whether the community wants this feature before randomly forcing it on them.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Aug 22, 2012 at 3:17 PM, bawolff bawolff+wn@gmail.com wrote:
On Wed, Aug 22, 2012 at 2:39 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Hey Tyler, Many of these issues have already been discussed on this mailing list.
Read
Rob and Tim's emails from last week to start with. As explained in the previous emails, the extension being deployed is Scribunto. Regarding performance testing, Rob said this would be done once the extension was deployed to mediawiki.org: "From there, we'll need some time figuring
out
the performance characteristics of this (making sure we're actually
coming
out ahead) as well as converting some key templates over." Many of the other questions are covered at https://www.mediawiki.org/wiki/Extension:Scribunto.
And not to be overly dismissive, but the idea that Tim needs to prove
that
en.wiki wants this feature is absurd. The template system on Wikipedia is BROKEN. It takes over 30 seconds for the parser to render large articles, and articles with a really large number of citation templates can't
render
at all, they simply error with a timeout. The only reason Lua/Scribunto
was
developed is because the en.wiki community has been vocally complaining about this problem FOR 3 YEARS. Check out https://bugzilla.wikimedia.org/show_bug.cgi?id=19262 for example.
Ryan Kaldari
Furthermore, mediawiki.org is a community essentially owned by the developers, not to mention this feature is non-user facing. If people don't want to use it, they don't have to.
I do believe consensus should be sought when enabling extensions like moodbar and what not on enwikipedia, but this is nothing like that situation.
--bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
But there's a difference between an issue and a solution. Yes, the templating system is broken, and I'm sure many an editor will confirm that, but just because a system is broken does not mean Lua is automatically the solution. To put it in other words: just because people want a better templating system does not imply they want Lua. What discussion, if any, has there been that WMF wikis want Lua as their templating replacement. As said before, mediawiki.org is mostly developers, so there's no problem with that, but with the op-ed on the Signpost, we should seriously question whether the community wants this feature before randomly forcing it on them.
Which community should be consulted on this technical decision? What if enwiki wants prolog and dewiki wants lua and enwikitionary wants javascript? Occasionally technical decisions have to be made by the developers. The templating language is a technical decision. It's really not something that is up for editor community debate.
This decision was hashed out over months (really a couple of years if we consider the original iteration of this idea) with the developer community. If the editor community wishes to take part in these kinds of decisions, they should join wikitech-l.
- Ryan
Which community should be consulted on this technical decision? What if enwiki wants prolog and dewiki wants lua and enwikitionary wants javascript? Occasionally technical decisions have to be made by the developers. The templating language is a technical decision. It's really not something that is up for editor community debate.
This decision was hashed out over months (really a couple of years if we consider the original iteration of this idea) with the developer community. If the editor community wishes to take part in these kinds of decisions, they should join wikitech-l.
Most lay users likely won't be able to understand the discussions that take place on wikitech-l. Hell most lay users don't even know it exists.
While I won't weigh in on whether or not the choice of Lua was our decision to make or not, I don't think that the argument that editors should join wikitech-l is a good one.
Perhaps the ambassadors mailing list? But wikitech-l? No.
I am curious though to see if we ever even mentioned this idea to the editors on at least enwiki though. I think such knowledge would greatly help everyone else here in evaluating whether or not we included the community enough on this decision.
Thank you, Derric Atzrott
On Wed, Aug 22, 2012 at 12:49 PM, Derric Atzrott datzrott@alizeepathology.com wrote:
Most lay users likely won't be able to understand the discussions that take place on wikitech-l.
But.. If that is true then how would they be able to know if they want Lua as a solution in the first place.
Most lay users likely won't be able to understand the discussions that take place on wikitech-l. Hell most lay users don't even know it exists.
Lay users don't write templates either. People who write templates are wizards. Templates make my eyes bleed and my mind hurt, and I've been developing for quite a long time.
While I won't weigh in on whether or not the choice of Lua was our decision to make or not, I don't think that the argument that editors should join wikitech-l is a good one.
I don't think the editor community has much reason to participate. The template creator community does. They are more than technical to understand things on wikitech-l.
Perhaps the ambassadors mailing list? But wikitech-l? No.
I am curious though to see if we ever even mentioned this idea to the editors on at least enwiki though. I think such knowledge would greatly help everyone else here in evaluating whether or not we included the community enough on this decision.
The "community" is not a single thing. The community is made up of hundreds of sub-communities. If people are interested in technical decisions, they need to participate where technical decisions are made.
- Ryan
On 22 August 2012 20:58, Ryan Lane rlane32@gmail.com wrote:
I don't think the editor community has much reason to participate. The template creator community does. They are more than technical to understand things on wikitech-l.
AIUI the Lua idea was explicitly run past the few people who write the insanely horrible brainfuck-like ParserFunctions templates. (Is this correct?) They would be the relevant part of the editor community - most of the editor community just want the template itself to work, they neither know nor care about the details of the plumbing.
So, has anyone translated {{cite}} to Lua? Is it comprehensible? Does it run faster?
The "community" is not a single thing. The community is made up of hundreds of sub-communities. If people are interested in technical decisions, they need to participate where technical decisions are made.
Well, one would think so.
- d.
This is the exact kind of attitude the op-ed in the Signpost is addressing. When making major feature decision, such as redoing the entire templating system, we cannot just say to editors "oh, if you want some input, go and join our mailing list". That's just a passive-aggressive way of pushing editors out of the conversation. How many purely editors, i.e., not developers, are on this list actively participating in discussion?
And this isn't a technical decision, it's a requirements decision. We're not deciding what algorithm to use, or what object design to implement, we're deciding what features would be best for the users of Wikipedia. The reason this extension was implemented (hopefully) was so that users could have a better templating experience, but how can you possibly assume to know what is best for the user without asking the users themselves? And no, we cannot be expected to consult every language wiki, but on the other hand we cannot completely ignore the community and suddenly launch this new extension on them as if they'd known about it for years.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Aug 22, 2012 at 3:38 PM, Ryan Lane rlane32@gmail.com wrote:
But there's a difference between an issue and a solution. Yes, the templating system is broken, and I'm sure many an editor will confirm
that,
but just because a system is broken does not mean Lua is automatically
the
solution. To put it in other words: just because people want a better templating system does not imply they want Lua. What discussion, if any, has there been that WMF wikis want Lua as their templating replacement.
As
said before, mediawiki.org is mostly developers, so there's no problem
with
that, but with the op-ed on the Signpost, we should seriously question whether the community wants this feature before randomly forcing it on them.
Which community should be consulted on this technical decision? What if enwiki wants prolog and dewiki wants lua and enwikitionary wants javascript? Occasionally technical decisions have to be made by the developers. The templating language is a technical decision. It's really not something that is up for editor community debate.
This decision was hashed out over months (really a couple of years if we consider the original iteration of this idea) with the developer community. If the editor community wishes to take part in these kinds of decisions, they should join wikitech-l.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Aug 22, 2012 at 3:51 PM, Tyler Romeo tylerromeo@gmail.com wrote:
This is the exact kind of attitude the op-ed in the Signpost is addressing. When making major feature decision, such as redoing the entire templating system, we cannot just say to editors "oh, if you want some input, go and join our mailing list". That's just a passive-aggressive way of pushing editors out of the conversation. How many purely editors, i.e., not developers, are on this list actively participating in discussion?
Which communities? Engaging N editing communities just doesn't scale. Nor, to be perfectly honest, do I think its the appropriate venue. I expect people to join the places technical discussions take place (this list + mediawiki.org), just as I expect I should have to join a wiki's discussion forums to discuss content/community things. I'm perfectly willing to engage anyone on anything I work on, but I don't want to repeat myself in 20 different places.
A long time ago, technical discussions happened on Meta. It was moved off of Meta since there's enough content to warrant its own wiki. Perhaps we can improve on getting notices out to people (hey, we're discussing FooBar, come talk with us [here]), but trying to shift the discussion to hundreds of individual wikis just doesn't work for me.
-Chad
On Wed, Aug 22, 2012 at 4:51 PM, Tyler Romeo tylerromeo@gmail.com wrote:
This is the exact kind of attitude the op-ed in the Signpost is addressing. When making major feature decision, such as redoing the entire templating system, we cannot just say to editors "oh, if you want some input, go and join our mailing list". That's just a passive-aggressive way of pushing editors out of the conversation. How many purely editors, i.e., not developers, are on this list actively participating in discussion?
And this isn't a technical decision, it's a requirements decision. We're not deciding what algorithm to use, or what object design to implement, we're deciding what features would be best for the users of Wikipedia. The reason this extension was implemented (hopefully) was so that users could have a better templating experience, but how can you possibly assume to know what is best for the user without asking the users themselves? And no, we cannot be expected to consult every language wiki, but on the other hand we cannot completely ignore the community and suddenly launch this new extension on them as if they'd known about it for years.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
I think its a little late for this. I'm pretty sure there was discussions with (template editor) users about lua years ago. The whole lua thing has literally been in discussion in some form or another for probably at least 5 years.
From what I understand lua was not chosen just randomly by throwing a
bunch of languages in a hat, there were many requirements, such as sandbox-ability, performance concerns, and ease of implementing resource limits, etc. If I recall lua came out the clear winner.
-bawolff
From what I understand lua was not chosen just randomly by throwing a bunch of languages in a hat, there were many requirements, such as sandbox-ability, performance concerns, and ease of implementing resource limits, etc. If I recall lua came out the clear winner.
This is what I mean when I say it's a technical decision. This discussion has concerns that are simply not possible to address in a non-technical forum.
- Ryan
On Wed, Aug 22, 2012 at 12:51 PM, Tyler Romeo tylerromeo@gmail.com wrote:
And this isn't a technical decision, it's a requirements decision. We're not deciding what algorithm to use, or what object design to implement, we're deciding what features would be best for the users of Wikipedia.
I'm not sure I entirely agree with this assessment. The community has complained about the current templating system -- the requirements decision is arguably that something should be done to improve how templates are created and their overall performance. The technical decision, i.e. what technology to use to solve this issue, is what was decided by selecting LUA. That said, I do agree that we should plan the roll-out rather than just tossing it over the wall -- preparing some initial documentation and tutorials to show HOW and WHY it's easier/faster than the old system would go a long way (imho) to assuage complaints of disconnect from what the community wants.
Nabil
I don't think the editor community has much reason to participate. The template creator community does. They are more than technical to understand things on wikitech-l.
AIUI the Lua idea was explicitly run past the few people who write the insanely horrible brainfuck-like ParserFunctions templates. (Is this correct?) They would be the relevant part of the editor community - most of the editor community just want the template itself to work, they neither know nor care about the details of the plumbing.
Fair enough. That satisfies my threshold for consulting the community.
If the people who would be most affected had a chance to give their input I would say that this project is good to go then.
From what I understand lua was not chosen just randomly by throwing a bunch of languages in a hat, there were many requirements, such as sandbox-ability, performance concerns, and ease of implementing resource limits, etc. If I recall lua came out the clear winner.
This also seems perfectly fair. My points have been refuted and I humbly accept defeat.
That said, I do agree that we should plan the roll-out rather than just tossing it over the wall -- preparing some initial documentation and tutorials to show HOW and WHY it's easier/faster than the old system would go a long way (imho) to assuage complaints of disconnect from what the community wants.
+1 million. This is a must. No one likes change, but anything we can do to make that change easier on people will make things better. The old templating system will still be functional correct?
Thank you, Derric Atzrott
On Wed, Aug 22, 2012 at 4:12 PM, Derric Atzrott datzrott@alizeepathology.com wrote:
I don't think the editor community has much reason to participate. The template creator community does. They are more than technical to understand things on wikitech-l.
AIUI the Lua idea was explicitly run past the few people who write the insanely horrible brainfuck-like ParserFunctions templates. (Is this correct?) They would be the relevant part of the editor community - most of the editor community just want the template itself to work, they neither know nor care about the details of the plumbing.
Fair enough. That satisfies my threshold for consulting the community.
If the people who would be most affected had a chance to give their input I would say that this project is good to go then.
From what I understand lua was not chosen just randomly by throwing a bunch of languages in a hat, there were many requirements, such as sandbox-ability, performance concerns, and ease of implementing resource limits, etc. If I recall lua came out the clear winner.
This also seems perfectly fair. My points have been refuted and I humbly accept defeat.
That said, I do agree that we should plan the roll-out rather than just tossing it over the wall -- preparing some initial documentation and tutorials to show HOW and WHY it's easier/faster than the old system would go a long way (imho) to assuage complaints of disconnect from what the community wants.
+1 million. This is a must. No one likes change, but anything we can do to make that change easier on people will make things better. The old templating system will still be functional correct?
Yes. Nothing that currently works will be removed. This just exposes Lua to people who choose to begin using it.
As far as docs go, I'd suggest looking at [[mw:Lua_scripting]] for starts[0]. It has a lot of the requirements and links to more information, including a tutorial[1].
-Chad
[0] http://www.mediawiki.org/wiki/Lua_scripting [1] http://www.mediawiki.org/wiki/Lua_scripting/Tutorial
As long as people in the templating community were at least consulted with, then that's fine. I'm just saying we cannot randomly throw features onto users without discussing it with them.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Aug 22, 2012 at 4:13 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Aug 22, 2012 at 4:12 PM, Derric Atzrott datzrott@alizeepathology.com wrote:
I don't think the editor community has much reason to participate. The template creator community does. They are more than technical to understand things on wikitech-l.
AIUI the Lua idea was explicitly run past the few people who write the insanely horrible brainfuck-like ParserFunctions templates. (Is this correct?) They would be the relevant part of the editor community - most of the editor community just want the template itself to work, they neither know nor care about the details of the plumbing.
Fair enough. That satisfies my threshold for consulting the community.
If the people who would be most affected had a chance to give their input I would say that this project is good to go then.
From what I understand lua was not chosen just randomly by throwing a bunch of languages in a hat, there were many requirements, such as sandbox-ability, performance concerns, and ease of implementing resource limits, etc. If I recall lua came out the clear winner.
This also seems perfectly fair. My points have been refuted and I humbly accept defeat.
That said, I do agree that we should plan the roll-out rather than just tossing it over the wall -- preparing some initial documentation and tutorials to show HOW and WHY it's easier/faster than the old system would go a long way (imho) to assuage complaints of disconnect from what the community wants.
+1 million. This is a must. No one likes change, but anything we can do to make that change easier on people will make things better. The old templating system will still be functional correct?
Yes. Nothing that currently works will be removed. This just exposes Lua to people who choose to begin using it.
As far as docs go, I'd suggest looking at [[mw:Lua_scripting]] for starts[0]. It has a lot of the requirements and links to more information, including a tutorial[1].
-Chad
[0] http://www.mediawiki.org/wiki/Lua_scripting [1] http://www.mediawiki.org/wiki/Lua_scripting/Tutorial
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Aug 22, 2012 at 1:24 PM, Tyler Romeo tylerromeo@gmail.com wrote:
As long as people in the templating community were at least consulted with, then that's fine. I'm just saying we cannot randomly throw features onto users without discussing it with them.
A good default assumption would be that we've done what we're supposed to be doing as software developers. User testing is a normal part of software development. It's kind of bad faith to assume we're not engaging end-users at all.
- Ryan
On 22 August 2012 16:52, Ryan Lane rlane32@gmail.com wrote:
On Wed, Aug 22, 2012 at 1:24 PM, Tyler Romeo tylerromeo@gmail.com wrote:
As long as people in the templating community were at least consulted
with,
then that's fine. I'm just saying we cannot randomly throw features onto users without discussing it with them.
A good default assumption would be that we've done what we're supposed to be doing as software developers. User testing is a normal part of software development. It's kind of bad faith to assume we're not engaging end-users at all.
I hear what you're saying Ryan - although in fairness there is some history there, and also some very significant challenges on all sides to actually communicate. However, one has to keep in mind that sometimes the definition of "end user" can be pretty different. On reading this thread, I have the sense that lots of people commenting here see template creators/curators as the "end user" - but they aren't in any conventional sense. The end user is the person who actually uses the template.
Risker/Anne
On Wed, 22 Aug 2012 14:01:00 -0700, Risker risker.wp@gmail.com wrote:
On 22 August 2012 16:52, Ryan Lane rlane32@gmail.com wrote:
On Wed, Aug 22, 2012 at 1:24 PM, Tyler Romeo tylerromeo@gmail.com wrote:
As long as people in the templating community were at least consulted
with,
then that's fine. I'm just saying we cannot randomly throw features
onto
users without discussing it with them.
A good default assumption would be that we've done what we're supposed to be doing as software developers. User testing is a normal part of software development. It's kind of bad faith to assume we're not engaging end-users at all.
I hear what you're saying Ryan - although in fairness there is some history there, and also some very significant challenges on all sides to actually communicate. However, one has to keep in mind that sometimes the definition of "end user" can be pretty different. On reading this thread, I have the sense that lots of people commenting here see template creators/curators as the "end user" - but they aren't in any conventional sense. The end user is the person who actually uses the template.
Risker/Anne
How?
I don't see how the user who puts {{cite|...}} and never takes one look at the source for Template:Cite is the end user.
Template inclusion syntax is the same. No matter if cite uses ugly ParserFunctions, Lua, or makes a call out to a custom written extension the syntax used to include the template stays the exact same. I don't see how these users who never even look at template source should care what the template they use is powered by.
I hear what you're saying Ryan - although in fairness there is some history there, and also some very significant challenges on all sides to actually communicate. However, one has to keep in mind that sometimes the definition of "end user" can be pretty different. On reading this thread, I have the sense that lots of people commenting here see template creators/curators as the "end user" - but they aren't in any conventional sense. The end user is the person who actually uses the template.
The end-users for scribunto are template editors. The way the template is called from articles is almost exactly the same. The syntax is so similar to how it currently is that It does nothing to change the experience for a normal editor.
I'd bet that most templates will keep the same arguments when switched over, and the syntax will be mass changed by a bot.
- Ryan
On 22 August 2012 17:17, Ryan Lane rlane32@gmail.com wrote:
I hear what you're saying Ryan - although in fairness there is some
history
there, and also some very significant challenges on all sides to actually communicate. However, one has to keep in mind that sometimes the definition of "end user" can be pretty different. On reading this
thread,
I have the sense that lots of people commenting here see template creators/curators as the "end user" - but they aren't in any conventional sense. The end user is the person who actually uses the template.
The end-users for scribunto are template editors. The way the template is called from articles is almost exactly the same. The syntax is so similar to how it currently is that It does nothing to change the experience for a normal editor.
I'd bet that most templates will keep the same arguments when switched over, and the syntax will be mass changed by a bot.
Hmm. I can understand why scribunto is targeted at template editors - although the argument that the end user is *not* the person using the template is kind of like saying the end-user of a car isn't the driver. Nonetheless, it would be nice not to have browser crashes when opening articles that have tons of templates, so there's still an important win there.
If the use of templates is going to be as miserable after this switch as it is now, then there's a significant opportunity missed. (I know at least 30 people who stopped editing at least in part because of the template morass we currently have. Some of them wrote featured content.) Nonetheless, it's still important to have template *users* try out templates created using scribunto to make sure that they do actually work as expected. Then I guess the fun will be in determining if any problems come from scribunto or from the template writer's work.
Risker/Anne
On Wed, Aug 22, 2012 at 5:36 PM, Risker risker.wp@gmail.com wrote:
If the use of templates is going to be as miserable after this switch as it is now, then there's a significant opportunity missed. (I know at least 30 people who stopped editing at least in part because of the template morass we currently have. Some of them wrote featured content.) Nonetheless, it's still important to have template *users* try out templates created using scribunto to make sure that they do actually work as expected. Then I guess the fun will be in determining if any problems come from scribunto or from the template writer's work.
I believe it will be much better after the switch to Lua. Unlike wikitext, which isn't a programming language (but can be made to act sort of like one), Lua is an actual language. Wikitext programming only came about to begin with due to some quirks in transclusion that allowed {{qif}}. ParserFunctions came to fill that need, but were never really designed to do some of the complex logic that modern templates require.
Lua, as a programming language (but the idea applies if we'd chosen JS, Cobol, or anything else) will handle this sort of thing far more elegantly than endless iterations of adding new ParserFunctions to handle more edge-cases.
Granted, I've never written a complex template (only looked and shuddered).
-Chad
Speaking of complex templates, has there been any work to move existing templates to Lua? Because I'd love to start on the ArticleHistory template if nobody else is doing it.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Aug 22, 2012 at 5:43 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Aug 22, 2012 at 5:36 PM, Risker risker.wp@gmail.com wrote:
If the use of templates is going to be as miserable after this switch as
it
is now, then there's a significant opportunity missed. (I know at least
30
people who stopped editing at least in part because of the template
morass
we currently have. Some of them wrote featured content.) Nonetheless,
it's
still important to have template *users* try out templates created using scribunto to make sure that they do actually work as expected. Then I
guess
the fun will be in determining if any problems come from scribunto or
from
the template writer's work.
I believe it will be much better after the switch to Lua. Unlike wikitext, which isn't a programming language (but can be made to act sort of like one), Lua is an actual language. Wikitext programming only came about to begin with due to some quirks in transclusion that allowed {{qif}}. ParserFunctions came to fill that need, but were never really designed to do some of the complex logic that modern templates require.
Lua, as a programming language (but the idea applies if we'd chosen JS, Cobol, or anything else) will handle this sort of thing far more elegantly than endless iterations of adding new ParserFunctions to handle more edge-cases.
Granted, I've never written a complex template (only looked and shuddered).
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 22 August 2012 22:46, Tyler Romeo tylerromeo@gmail.com wrote:
Speaking of complex templates, has there been any work to move existing templates to Lua? Because I'd love to start on the ArticleHistory template if nobody else is doing it.
I think at this stage it's safe to assume that the field is clear and you get to write the "How To Port A Horrible Template" tutorial ...
Something complicated on en:wp that would not be meaningless on mediawiki.org could be copied there for hacking.
- d.
- d.
On 08/22/2012 05:50 PM, David Gerard wrote:
On 22 August 2012 22:46, Tyler Romeo tylerromeo@gmail.com wrote:
Speaking of complex templates, has there been any work to move existing templates to Lua? Because I'd love to start on the ArticleHistory template if nobody else is doing it.
I think at this stage it's safe to assume that the field is clear and you get to write the "How To Port A Horrible Template" tutorial ...
Something complicated on en:wp that would not be meaningless on mediawiki.org could be copied there for hacking.
Seconding this. Yes, please please go ahead!
On 08/22/2012 05:50 PM, David Gerard wrote:
Something complicated on en:wp that would not be meaningless on mediawiki.org could be copied there for hacking.
I recall that one of Robla's standard articles from enwiki for demonstrating long rendering time was http://en.wikipedia.org/wiki/Barack_Obama. I just did a purge on it and it took 34s to render.
I haven't yet looked at how the article is written or the templates used, but perhaps that would be a good place to start looking.
On Fri, Aug 24, 2012 at 4:59 AM, Mark A. Hershberger mah@everybody.org wrote:
I recall that one of Robla's standard articles from enwiki for demonstrating long rendering time was http://en.wikipedia.org/wiki/Barack_Obama. I just did a purge on it and it took 34s to render.
Hi Mark, thanks for pointing that out. A better way to test this is to preview without (necessarily) changing anything, since the article will still be available to anyone else who requests it during the 34s it takes to parse it. Sucks that we should have to think about that, but that'll hopefully be one of the things that this fixes.
I haven't yet looked at how the article is written or the templates used, but perhaps that would be a good place to start looking.
I'm pretty sure that all of the {{Cite}} templates are the major consumers on that page. Maybe we can just get people to stop citing their sources ;-)
Rob
Hmm. I can understand why scribunto is targeted at template editors - although the argument that the end user is *not* the person using the template is kind of like saying the end-user of a car isn't the driver.
I'd say it's more like saying that the end-user of a crank pin [1] isn't the driver of the car it's in. Which is pretty much true, because the driver will neither think about, nor probably ever see, the crank pin. Yes, they're technically using it, but it's so far below the analytical level they're using to drive that it's not worth considering.
In a similar manner, while Lua (and PHP, and JavaScript, and so on) is being used to generate the page they're viewing, the user has no interest in that, most of the time.
Of course, if we can convince people to learn more about Lua through this very simple editing interface, then that's an awesome win and will lead to a more computer-literate user base. Then maybe we can have this chat again in a different context :)
[1] http://en.wikipedia.org/wiki/Crank_pin
On 23/08/12 07:17, Ryan Lane wrote:
I hear what you're saying Ryan - although in fairness there is some history there, and also some very significant challenges on all sides to actually communicate. However, one has to keep in mind that sometimes the definition of "end user" can be pretty different. On reading this thread, I have the sense that lots of people commenting here see template creators/curators as the "end user" - but they aren't in any conventional sense. The end user is the person who actually uses the template.
The end-users for scribunto are template editors. The way the template is called from articles is almost exactly the same. The syntax is so similar to how it currently is that It does nothing to change the experience for a normal editor.
I'd bet that most templates will keep the same arguments when switched over, and the syntax will be mass changed by a bot.
I think there will be some changes to template invocations. For example, a typical coord invocation looks like this:
{{Coord|33|51|35.9|S|151|12|40|E}}
With the string processing facilities that Lua provides, that might change to:
{{Coord|33°51'35.9"S 151°12'40"E}}
Of course, backwards compatibility would need to be maintained, but that's easy enough.
The same thing would have happened if we enabled StringFunctions, but the performance would have been worse than the original, whereas with Lua, we should be able to parse simple strings like that with a performance much better than the original coord template.
There will still be double braces and pipes, but fixing that is the domain of VisualEditor.
Our metatemplate authors enjoy a challenge. You have to have that kind of mindset to attempt to do complex things in the existing wikitext syntax. I would expect some of them to try really complex things in Lua.
Some of the applications might be whimsical, like a code snippet template for [[Lisp (programming language)]] that contains a complete Lisp interpreter. Others will be more practical, perhaps navbox generation based on a template-free wikitext specification hosted on a separate page.
If we extrapolate from the experience with metatemplates, we can expect Wikipedia's community to tolerate such developments until performance limits are reached, and then to tolerate it some more until they are significantly exceeded. But Lua is so fast compared to wikitext that our Lua developers will have to exercise a lot of creativity to find applications that will exceed the performance limits.
-- Tim Starling
On Thu, Aug 23, 2012 at 2:00 AM, Tim Starling tstarling@wikimedia.orgwrote:
I think there will be some changes to template invocations. For example, a typical coord invocation looks like this:
{{Coord|33|51|35.9|S|151|12|40|E}}
With the string processing facilities that Lua provides, that might change to:
{{Coord|33°51'35.9"S 151°12'40"E}}
Of course, backwards compatibility would need to be maintained, but that's easy enough.
HI all, I can understand that some people might be upset about a new language and change. But in the defense of lua proponents, it is not like the old templates are being deleted here, there are millions of copies of them and they are not going away. Also media wiki as a language is difficult to process, using a standard language for tempaltes might help out. So a migration path that I would think is reasonable and I am sure has been proposed is to make first a compatibility layer that allows old templates to be used in lua and make some "evalold" function to process old template code exactly as it was.
thanks mike
On Thu, Aug 23, 2012 at 4:00 AM, Tim Starling tstarling@wikimedia.org wrote:
But Lua is so fast compared to wikitext that our Lua developers will have to exercise a lot of creativity to find applications that will exceed the performance limits.
Famous words, kept in the archives forever :).
Siebrand
On 23 August 2012 08:18, Siebrand Mazeland (WMF) smazeland@wikimedia.org wrote:
On Thu, Aug 23, 2012 at 4:00 AM, Tim Starling tstarling@wikimedia.org wrote:
But Lua is so fast compared to wikitext that our Lua developers will have to exercise a lot of creativity to find applications that will exceed the performance limits.
Famous words, kept in the archives forever :).
How they will know? Theres some way to get feedback about this, like "rendering time: 3.8 seconds".
...
I read this mail-list for pure entertainment. I am trying to imagine what cool things lua will allow. But seems more a improvement of speed. Speed will allow cool things to happen. So is more like a indirect improvement (and probably a huge one). Speed is sexy but not much entertaining at first, seems a enabler.
So.. This is great news!, and herald of other awesome things to come :DDD
On 23 August 2012 10:38, Tei oscar.vives@gmail.com wrote:
I read this mail-list for pure entertainment. I am trying to imagine what cool things lua will allow. But seems more a improvement of speed. Speed will allow cool things to happen. So is more like a indirect improvement (and probably a huge one). Speed is sexy but not much entertaining at first, seems a enabler.
Speed is secondary. The main thing is that Lua is actually designed to be a usable programming language, whereas ParserFunctions is a Turing tarpit, only accidentally Turing-complete, in which "everything is possible but nothing of interest is easy." [1] Complicated ParserFunctions templates look like several days' Daily WTF [2] because of this.
Even if there were no speed improvement, it would be a vast improvement just in programmability. (Though that would mean much more use of programmatic templates, so in practice we need speed too.)
- d.
[1] https://en.wikipedia.org/wiki/Turing_tarpit [2] http://thedailywtf.com/
On 23/08/12 07:18, Siebrand Mazeland (WMF) wrote:
On Thu, Aug 23, 2012 at 4:00 AM, Tim Starling tstarling@wikimedia.org wrote:
But Lua is so fast compared to wikitext that our Lua developers will have to exercise a lot of creativity to find applications that will exceed the performance limits.
Famous words, kept in the archives forever :).
Siebrand
Indeed. I wonder how long it will be before someone uses Lua templates to do something like this:
-- N.
On 23/08/12 15:10, Neil Harris wrote:
On 23/08/12 07:18, Siebrand Mazeland (WMF) wrote:
On Thu, Aug 23, 2012 at 4:00 AM, Tim Starling tstarling@wikimedia.org wrote:
But Lua is so fast compared to wikitext that our Lua developers will have to exercise a lot of creativity to find applications that will exceed the performance limits.
Famous words, kept in the archives forever :).
Siebrand
Indeed. I wonder how long it will be before someone uses Lua templates to do something like this:
-- N.
Just to clarify, in case anyone gets the wrong impression from my last two posts -- I'm not snarking against Tim here: Lua on MediaWiki is fantastic, will be one of the best things ever for the platform (along with the Visual Editor) and I look forward to using it on Wikipedia!
-- N.
On 23/08/12 03:00, Tim Starling wrote:
On 23/08/12 07:17, Ryan Lane wrote:
The end-users for scribunto are template editors. The way the template is called from articles is almost exactly the same. The syntax is so similar to how it currently is that It does nothing to change the experience for a normal editor.
I'd bet that most templates will keep the same arguments when switched over, and the syntax will be mass changed by a bot.
I think there will be some changes to template invocations. For example, a typical coord invocation looks like this:
{{Coord|33|51|35.9|S|151|12|40|E}}
With the string processing facilities that Lua provides, that might change to:
{{Coord|33°51'35.9"S 151°12'40"E}}
Of course, backwards compatibility would need to be maintained, but that's easy enough.
This falls in the uncanny valley between pedantic correctness and ease of use. On one hand, most users would find the degree sign too hard to type: and on the other, if you are going to insist on using the degree sign, why not also the appropriate punctuation marks for minutes and seconds?
Something like
{{coord|33 51 35.9 S 151 12 40 E}}
would be perfectly good enough: as simple to understand as the existing format, and easier to type.
extending it to:
{{coord|33 51 35.9 S 151 12 40 E display=title type=landmark region=AU}}
would then be trivial.
-- Neil
On 24/08/12 00:01, Neil Harris wrote:
On 23/08/12 03:00, Tim Starling wrote:
{{Coord|33°51'35.9"S 151°12'40"E}}
[...]
This falls in the uncanny valley between pedantic correctness and ease of use. On one hand, most users would find the degree sign too hard to type: and on the other, if you are going to insist on using the degree sign, why not also the appropriate punctuation marks for minutes and seconds?
I'll leave the policy discussions for the people who actually implement it, if and when that happens. There's not much point in arguing about a fantasy.
-- Tim Starling
On 8/22/12 2:01 PM, Risker wrote:
I hear what you're saying Ryan - although in fairness there is some history there, and also some very significant challenges on all sides to actually communicate. However, one has to keep in mind that sometimes the definition of "end user" can be pretty different. On reading this thread, I have the sense that lots of people commenting here see template creators/curators as the "end user" - but they aren't in any conventional sense. The end user is the person who actually uses the template.
I imagine most templates won't actually change at all. The main purpose of Lua/Scribunto is to replace the nightmarish under-the-hood uber-templates templates like Citation/core with something that isn't so nightmarish. Most templates just do simple parameter substitutions and if/else decisions and don't require any real programming language functionality. Templates that have very complex behavior, however, are extremely difficult to implement in WikiText (and very expensive to parse), and there are only a small handful of people who work on these templates. We should certainly recruit those editors to help us test Scribunto now that it's on mediawiki.org. Getting buy-in from them will be critical to the tool's success. As one of the editors who works on templates like Citation/core, I'm personally very excited about the project so far, and can't wait to see it in production.
Ryan Kaldari
Hi!
As long as people in the templating community were at least consulted with, then that's fine. I'm just saying we cannot randomly throw features onto users without discussing it with them.
Same way template editors created whatever they created without discussing with developers, ha ha ha.
BR, (thanks MZMCBRBRBR) Domas
Ahem.
I'll put up my hand as a completely non-technical editor who reads this list on a regular basis, and who shares Ryan's "eye-bleeding" feelings about templates as they are currently developed and utilized, at least on enwiki. I think I can speak for a very large number of editors who have been praying for years for "something" to improve the template use experience, and say thanks to the development team for answering the call and coming up with what seems like a pretty good solution.
I quite agree that it's important to actively seek out and work with template creators and curators to get involved in testing out Lua. But it is also critical to involve those who will be *using* the templates to see if what has been designed will address any or all of their concerns and issues. Making the wiki run faster is, I believe, only one objective in improving the "template experience". If the product that comes out of Lua is as difficult to use as the current templates, then we have only completed half the job. (I use "we" as the big-tent community that includes developers and editors.)
If I may suggest: it's probably not all that hard to identify which projects use a lot of templates (enwiki will always be one), and then find a dozen or so template creators/curators from those projects - ask them to create the most commonly used templates on their project using Lua. Then, ask a larger group of template *users* come and try them out to get the end-user experience. This should give some useful feedback to Tim and anyone working with him. It also has some serious potential to create some evangelists within the project who can build up the positives and start moving their respective communities toward embracing Lua. I don't know if mediawiki is the best place for this - perhaps a test wiki might be easier to deal with, since the Mediawiki community has a very different ethos than every other project - but I think it will be worth the investment.
If ever there was a development project that needs a dedicated ambassador or two, this is the one. It has the potential to significantly affect multiple facets of the user experience. It has the potential to be a very big "win" for everyone - developers, editors, and even readers.
Risker/Anne
I quite agree that it's important to actively seek out and work with template creators and curators to get involved in testing out Lua. But it is also critical to involve those who will be *using* the templates to see if what has been designed will address any or all of their concerns and issues. Making the wiki run faster is, I believe, only one objective in improving the "template experience". If the product that comes out of Lua is as difficult to use as the current templates, then we have only completed half the job. (I use "we" as the big-tent community that includes developers and editors.)
As far as I know, this doesn't really change the template experience from a normal editor's point of view.
- Ryan
Tim Starling wrote:
Our goal is to deploy [Scribunto] to all Wikimedia wikis. If you don't like that idea, now would be a good time to say something.
Hi.
I believe you and I discussed the _need_ to have working interwiki transclusion before this extension sees widespread deployment. I consider this a blocker to widespread deployment. There are _a lot_ of lessons to be learned from Gadgets and I think this one is key.
(For anyone who's unaware, the Gadgets extension allows for essentially JavaScript modules to be installed on a wiki, with a user preference pane that allows users to enable and disable the modules on an individual basis. More information here: https://www.mediawiki.org/wiki/Extension:Gadgets.)
Lua is going to make complex templates even more complex. It may make sense to centralize certain templates. For certain modules, it's definitely going to make sense to centralize. For other modules, it'll make less sense. Perhaps mediawiki.org will be that central repository; perhaps not.
(By the way, you can see that I'm mixing up terminology: templates vs. modules. It's still unclear to me what relationship the Module namespace has to the Template namespace. Is it intended as a supplement? A replacement?)
I don't think it was a bad idea to deploy Scribunto to mediawiki.org. It seemed kind of silly to make a guarantee that Lua won't be disabled at any time in the future, but I think you're okay with possibly looking silly if problems arise and Lua needs to be disabled temporarily. :-)
That said, Tyler is certainly right that before there is a Wikimedia-wide deployment, there should be more thought about how to best utilize and manage this new template scripting language. I'm a huge fan of organic growth (and I think a good deal of organic growth will be needed here to ensure that template monsters don't suddenly show up next week before anyone is armed and ready!), but we also need to make sure we learn from past mistakes and experiences. I think the Gadgets evolution is the best (i.e., closest) model to study, but there may be others to study as well.
Auto categorization, manual categorization, and a few other administrative features are missing (yes, I'll file bugs at some point). We also need better/smarter documentation (including a glossary of terms). But most of these issues aren't necessarily blockers to widespread deployment.
The only other possible blocker that I think has come up is the third party user issue. English Wikipedia templates in particular are horribly common on third-party wikis. I believe you did some work to ensure that Lua/Scribunto would be supported in other hosting environments, but I'm not sure of the status of this. This issue could also be mitigated by centralized modules, of course.
There were very few comments on the test2 deployment, probably because the Labs deployment served the same purpose.
From what I remember, you were the one who created test2. I've never
understood its purpose given the existence of test[1].
MZMcBride
On 8/22/12 7:08 PM, MZMcBride wrote:
Tim Starling wrote:
Our goal is to deploy [Scribunto] to all Wikimedia wikis. If you don't like that idea, now would be a good time to say something.
Hi.
I believe you and I discussed the _need_ to have working interwiki transclusion before this extension sees widespread deployment. I consider this a blocker to widespread deployment. There are _a lot_ of lessons to be learned from Gadgets and I think this one is key.
The templates that need Lua the most (the citation templates) are not translatable between wikis. All the wikis have different standards for doing citations. What expensive templates do you have in mind that would benefit from interwiki transclusion?
Ryan Kaldari
Coordinates and location maps, to start with. I think that most wikis copy these two verbatim.
2012/8/23, Ryan Kaldari rkaldari@wikimedia.org:
On 8/22/12 7:08 PM, MZMcBride wrote:
Tim Starling wrote:
Our goal is to deploy [Scribunto] to all Wikimedia wikis. If you don't like that idea, now would be a good time to say something.
Hi.
I believe you and I discussed the _need_ to have working interwiki transclusion before this extension sees widespread deployment. I consider this a blocker to widespread deployment. There are _a lot_ of lessons to be learned from Gadgets and I think this one is key.
The templates that need Lua the most (the citation templates) are not translatable between wikis. All the wikis have different standards for doing citations. What expensive templates do you have in mind that would benefit from interwiki transclusion?
Ryan Kaldari
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ryan Kaldari wrote:
On 8/22/12 7:08 PM, MZMcBride wrote:
Tim Starling wrote:
Our goal is to deploy [Scribunto] to all Wikimedia wikis. If you don't like that idea, now would be a good time to say something.
I believe you and I discussed the _need_ to have working interwiki transclusion before this extension sees widespread deployment. I consider this a blocker to widespread deployment. There are _a lot_ of lessons to be learned from Gadgets and I think this one is key.
The templates that need Lua the most (the citation templates) are not translatable between wikis. All the wikis have different standards for doing citations. What expensive templates do you have in mind that would benefit from interwiki transclusion?
It's not really about expensive templates, it's about code fragmentation. Gadgets currently have this problem because there are no global gadgets: you get forks of the same code with very minor tweaks spread out across wikis. Or even forks with identical code, but a change to a particular wiki's gadget has to be manually synced to other wikis. It quickly becomes a nightmare. This is my concern with Lua modules, in a nutshell.
MZMcBride
On Thu, Aug 23, 2012 at 4:18 AM, MZMcBride z@mzmcbride.com wrote:
This is my concern with Lua modules, in a nutshell.
So please tell me, what are the options to fix this? Is there going to be a common code repo and maybe an easy way to sync in a git filesystem of template code into the wiki?
Maybe a git extension? or is there one already?
mike
On 08/23/2012 12:30 AM, Mike Dupont wrote:
So please tell me, what are the options to fix this? Is there going to be a common code repo and maybe an easy way to sync in a git filesystem of template code into the wiki?
Gadgets (v2) makes an attempt to fix the "no central repository" problem, so maybe that would be a place to start looking.
But MZ is right. The duplication and inadvertent code forks that result from not having a way to easily re-use templates and Gadgets is a real problem that we should start to address.
I think that is https://bugzilla.wikimedia.org/show_bug.cgi?id=39610 (Scribunto should support global module invocations)
On Fri, Aug 24, 2012 at 9:18 AM, Mark A. Hershberger mah@everybody.org wrote:
On 08/23/2012 12:30 AM, Mike Dupont wrote:
So please tell me, what are the options to fix this? Is there going to be a common code repo and maybe an easy way to sync in a git filesystem of template code into the wiki?
Gadgets (v2) makes an attempt to fix the "no central repository" problem, so maybe that would be a place to start looking.
But MZ is right. The duplication and inadvertent code forks that result from not having a way to easily re-use templates and Gadgets is a real problem that we should start to address.
Human evil is not a problem. It is a mystery. It cannot be solved. -- When Atheism Becomes a Religion, Chris Hedges
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Maybe it's just me opinion, but I believe that even with Lua, the existing templating system is not entirely obsolete. I'm sure ParserFunctions still has a legitimate purpose. For example, what about a template that's just a simple if statement (if this, else that). There's not really a need to make a Lua module for something that basic.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Aug 24, 2012 at 8:56 AM, Helder . helder.wiki@gmail.com wrote:
I think that is https://bugzilla.wikimedia.org/show_bug.cgi?id=39610 (Scribunto should support global module invocations)
On Fri, Aug 24, 2012 at 9:18 AM, Mark A. Hershberger mah@everybody.org wrote:
On 08/23/2012 12:30 AM, Mike Dupont wrote:
So please tell me, what are the options to fix this? Is there going to
be a
common code repo and maybe an easy way to sync in a git filesystem of template code into the wiki?
Gadgets (v2) makes an attempt to fix the "no central repository" problem, so maybe that would be a place to start looking.
But MZ is right. The duplication and inadvertent code forks that result from not having a way to easily re-use templates and Gadgets is a real problem that we should start to address.
Human evil is not a problem. It is a mystery. It cannot be solved. -- When Atheism Becomes a Religion, Chris Hedges
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Maybe it's just me opinion, but I believe that even with Lua, the existing templating system is not entirely obsolete. I'm sure ParserFunctions still has a legitimate purpose. For example, what about a template that's just a simple if statement (if this, else that). There's not really a need to make a Lua module for something that basic.
I'm 100% in agreement on this. I think that Lua will probably be used, and perhaps quite heavily, but only in the more advanced templates. Simple templates will probably continue to use the current standard template creation proccesses. Honestly I can't see why they wouldn't. Its a whole lot simplier for most people than learning Lua and most people don't need Lua, just some people.
Thank you, Derric Atzrott
On 24/08/12 14:07, Derric Atzrott wrote:
Maybe it's just me opinion, but I believe that even with Lua, the existing templating system is not entirely obsolete. I'm sure ParserFunctions still has a legitimate purpose. For example, what about a template that's just a simple if statement (if this, else that). There's not really a need to make a Lua module for something that basic.
I'm 100% in agreement on this. I think that Lua will probably be used, and perhaps quite heavily, but only in the more advanced templates. Simple templates will probably continue to use the current standard template creation proccesses. Honestly I can't see why they wouldn't. Its a whole lot simplier for most people than learning Lua and most people don't need Lua, just some people.
Thank you, Derric Atzrott
That's right. I see the hierarchy as being something like this:
* simple templates written in the existing template markup, exactly as done at present
* complex templates written in Lua, maintained on-wiki, perhaps in a central repositry, but again using normal wiki processes for editing, protection, etc.
* common library routines written in Lua for addressing common utility functions used in many complex templates, maintained somewhere like git, with much stricter check-in rules, and viewed as being part of the core software
Possibly ParserFunctions will end up being semantic sugar for invoking primitives written in Lua, as part of that set of library routines.
-- N.
On 08/22/2012 11:36 PM, Ryan Kaldari wrote:
The templates that need Lua the most (the citation templates) are not translatable between wikis. All the wikis have different standards for doing citations. What expensive templates do you have in mind that would benefit from interwiki transclusion?
Ryan Kaldari
Common function/class libraries. Otherwise we will have hundreds of libraries which are copied from one wiki to another and then we end up with having different outdated libraries across multiple projects (like it happened with gadgets).
—Victor.
On 23/08/12 15:20, Victor Vasiliev wrote:
On 08/22/2012 11:36 PM, Ryan Kaldari wrote:
The templates that need Lua the most (the citation templates) are not translatable between wikis. All the wikis have different standards for doing citations. What expensive templates do you have in mind that would benefit from interwiki transclusion?
Ryan Kaldari
Common function/class libraries. Otherwise we will have hundreds of libraries which are copied from one wiki to another and then we end up with having different outdated libraries across multiple projects (like it happened with gadgets).
—Victor.
Yes. Absolutely this: in some sort of platform-wide repositry, in the same way that Commons does for images.
This is also a real chance to clean up many of the cross-wiki infelicities that have built up in the old template system.
And coord, citation, and infobox templates are the obvious places to start.
-- N.
Yes. Absolutely this: in some sort of platform-wide repositry, in the same
way that Commons does for images.
This is also a real chance to clean up many of the cross-wiki infelicities
that have built up in the old template system.
And coord, citation, and infobox templates are the obvious places to start.
Could probably throw gadgets in the mix too.
Thank you, Derric Atzrott
On Thu, Aug 23, 2012 at 11:39 AM, Derric Atzrott datzrott@alizeepathology.com wrote:
Yes. Absolutely this: in some sort of platform-wide repositry, in the same
way that Commons does for images.
This is also a real chance to clean up many of the cross-wiki infelicities
that have built up in the old template system.
And coord, citation, and infobox templates are the obvious places to start.
Could probably throw gadgets in the mix too.
Some previous discussions on this topic: https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2011/05#Comm...
Support crosswiki template inclusion (transclusion => interwiki templates, etc.) https://bugzilla.wikimedia.org/show_bug.cgi?id=4547
Create "Data Commons" or "Wikidata" project (tracking) https://bugzilla.wikimedia.org/show_bug.cgi?id=30345
Best regards, Helder
Hi everyone! I can see that there are many topics now in this thread and probably I will just add to this chaos one more topic. I should remind everyone about the ghetto minority in MediaWiki community called independent wiki owners and businesses that uses MediaWiki in their solutions. From this point of view I'm interested in the following:
- Lua means to replace ParserFunctions, Variables, Array, etc? What are the plans of supporting these extensions?
----- Yury Katkov
On Fri, Aug 24, 2012 at 7:43 AM, Helder . helder.wiki@gmail.com wrote:
On Thu, Aug 23, 2012 at 11:39 AM, Derric Atzrott datzrott@alizeepathology.com wrote:
Yes. Absolutely this: in some sort of platform-wide repositry, in the same
way that Commons does for images.
This is also a real chance to clean up many of the cross-wiki infelicities
that have built up in the old template system.
And coord, citation, and infobox templates are the obvious places to start.
Could probably throw gadgets in the mix too.
Some previous discussions on this topic: https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2011/05#Comm...
Support crosswiki template inclusion (transclusion => interwiki templates, etc.) https://bugzilla.wikimedia.org/show_bug.cgi?id=4547
Create "Data Commons" or "Wikidata" project (tracking) https://bugzilla.wikimedia.org/show_bug.cgi?id=30345
Best regards, Helder
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 24/08/12 06:37, Yury Katkov wrote:
Hi everyone! I can see that there are many topics now in this thread and probably I will just add to this chaos one more topic. I should remind everyone about the ghetto minority in MediaWiki community called independent wiki owners and businesses that uses MediaWiki in their solutions. From this point of view I'm interested in the following:
- Lua means to replace ParserFunctions, Variables, Array, etc? What
are the plans of supporting these extensions?
Yury Katkov
Perhaps ParserFunctions etc. could eventually be supported in Lua via a syntax extension of the new Lua mechanism, eliminating the need for separate extensions?
-- N.
Hi everyone,
At the risk of repeating what others have said, a quick note in response to Yury:
On Wed, Aug 22, 2012 at 1:01 AM, Yury Katkov katkov.juriy@gmail.com wrote:
Would you mind you please tell me where
- the discussion about deploying Lua on mw.org ,
- the announcement that it will be deployed on mw.org on Aug 22.
Tim and I agreed that a further announcement probably wouldn't be necessary. We make rather large changes to mediawiki.org with less fanfare than what this has already received.
- the roadmap and plans of further deployment of Scribunto on
Wikipedias and other Wikimedia projects
The roadmap generally is published here: http://www.mediawiki.org/wiki/Roadmap
...and is updated frequently. A longer view is available here: http://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals
Additionally, we provide (at least) monthly updates here: https://www.mediawiki.org/wiki/Lua_scripting
Our transition to Lua is one development project without a product manager, which shows in the long-term planning for this. We know there's a lot of planning work needed for a general rollout to the other wikis, and would appreciate volunteers to help out with this. If you're interested, please either send me mail or drop a note on the talk page here: https://www.mediawiki.org/wiki/Talk:Lua_scripting
Thanks! Rob
Are we allowed to import code licensed under GPL (or other free *software* license) to the Module namespace? (this was mentioned in the other thread[1])
Best regards, Helder
[1] http://www.gossamer-threads.com/lists/wiki/wikitech/290192
On Wed, Aug 22, 2012 at 2:36 AM, Tim Starling tstarling@wikimedia.org wrote:
Lua is now enabled on www.mediawiki.org.
Note that this is not a temporary deployment. You can rewrite existing templates to use Lua, we're not going to break them by turning it off again.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 22/08/12 06:36, Tim Starling wrote:
Lua is now enabled on www.mediawiki.org.
Note that this is not a temporary deployment. You can rewrite existing templates to use Lua, we're not going to break them by turning it off again.
-- Tim Starling
Just a thought: has someone yet considered a script for automatically transforming existing templates from template wikisyntax to Lua? I wouldn't have thought it would be too hard for many common cases, although obviously it wouldn't make any sense to translate pathological Wikitext templates into pathological Lua.
Neil
On 23/08/12 01:23, Neil Harris wrote:
Just a thought: has someone yet considered a script for automatically transforming existing templates from template wikisyntax to Lua? I wouldn't have thought it would be too hard for many common cases, although obviously it wouldn't make any sense to translate pathological Wikitext templates into pathological Lua.
Yes, in August 2011 I wrote a wikitext to Lua translator and put it in the LuaFoo extension. The code it generates doesn't actually work, since it replaces parser function calls with calls to nonexistent Lua functions. It was written before we decided what the MediaWiki to Lua interface would look like.
Even if it did work, it would be ugly and slow. I'm not sure if it would be a useful starting point.
-- Tim Starling
wikitech-l@lists.wikimedia.org