[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #154 from MZMcBride b...@mzmcbride.com --- Just noting here in a comment that bug 26092 (Enable or install string parsing wikimarkup functionality on WMF wikis) has now been marked resolved/fixed. Wikimedia wikis now all have proper string functions (but not StringFunctions) via [[mw:Extension:Scribunto]] and [[mw:Lua]]. :-) Thanks to Brad Jorsch, Tim Starling, Victor Vasiliev, and many others (including the template writers who are now embarking on a massive upgrade) for all of their past, present, and future work on this. It seems we're now on the cusp of greatly reducing parse times of pages, which is really awesome. Related bugs: * bug 26786 – Add functionality (in an extension or MediaWiki) and implement to make English Wikipedia's [[Template:Cite]] work faster * bug 19262 – Pages with a high number of templates suffer extremely slow rendering or read timeout for logged in users -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Bug 6455 depends on bug 26092, which changed state. Bug 26092 Summary: Enable or install string parsing wikimarkup functionality on WMF wikis https://bugzilla.wikimedia.org/show_bug.cgi?id=26092 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 mybugs.m...@gmail.com changed: What|Removed |Added CC||mybugs.m...@gmail.com --- Comment #153 from mybugs.m...@gmail.com 2012-02-27 09:56:41 UTC --- (In reply to comment #152) Victor, I am off from my extension's developing due to various problems, however may I ask you to give an address of the page where the scripting project status will be updated, please? I think that would be https://www.mediawiki.org/wiki/Lua_scripting/status -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Dmitriy Sintsov ques...@rambler.ru changed: What|Removed |Added CC||ques...@rambler.ru --- Comment #152 from Dmitriy Sintsov ques...@rambler.ru 2012-02-27 07:55:47 UTC --- Victor, I am off from my extension's developing due to various problems, however may I ask you to give an address of the page where the scripting project status will be updated, please? One of my extensions already needs strong scripting language and I wonder whether it is already possible to hook / bind Lua calls in separate MW extension. Basically, I need to have few custom Lua functions bound to PHP methods in extension's code and the possibility to execute Lua scripts which use these function calls. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #151 from Victor Vasiliev vasi...@gmail.com 2012-02-25 11:09:05 UTC --- (In reply to comment #149) I don't think injunctions like Please don't change this unless you are a developer. are very cool. It is quite possible that Lua will be decided against (as it was before) and then this should be re-opened. No, proper scripting language is certainly preferred to string functions in wikitext and I cannot imagine what must happen so we reconsider this. And the previous WONTFIX - please don't change was predicated on a stray remark by Tim Starling in a mail list. At WikiMania 2011 Tim changed his mind several times on the best solution including Lua, parser functions, Victor's scripting extension. Lua is an almost-final choice, made by consensus of WMF developers. Even if we change the language, the current plan is to develop infrastructure which is language-independent (so we can just plug in a different language backend without rewriting anything else). Or maybe we should change this bug to provide some form of string handling, and soon because otherwise we might have Lua kicking around for another 6 years and still be no further forward. It's WMF engineering project now, and as far as I am aware the active work on it should begin shortly after 1.19 deployment and git migration. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #149 from Rich Farmbrough rich...@farmbrough.co.uk 2012-02-24 15:35:22 UTC --- It's not about cite templates alone. And I'm glad you say we're going to have a new solution in the next year - Lua has been committed to but it was also the proposed solution back in 2009, and I think it's rather I will believe it when I see it. I don't think injunctions like Please don't change this unless you are a developer. are very cool. It is quite possible that Lua will be decided against (as it was before) and then this should be re-opened. And the previous WONTFIX - please don't change was predicated on a stray remark by Tim Starling in a mail list. At WikiMania 2011 Tim changed his mind several times on the best solution including Lua, parser functions, Victor's scripting extension. Or maybe we should change this bug to provide some form of string handling, and soon because otherwise we might have Lua kicking around for another 6 years and still be no further forward. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #150 from Happy-melon happy.melon.w...@gmail.com 2012-02-24 15:57:24 UTC --- (In reply to comment #149) I don't think injunctions like Please don't change this unless you are a developer. are very cool. It is quite possible that Lua will be decided against (as it was before) and then this should be re-opened. Those two comments are in no way exclusive: a developer would be best placed to know if any change occurs to the commitment to Lua. Although as has been said before, the existence of an alternative is not a prerequisite for WONTFIXing this. Or maybe we should change this bug to provide some form of string handling, and soon because otherwise we might have Lua kicking around for another 6 years and still be no further forward. That would be bug 26092, of which this bug is a dependency. Everyone knows that this is an open, important and complicated issue; if changing the title of a bug were all it took to magically untie the gordian knot, we would have done it by now. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Rich Farmbrough rich...@farmbrough.co.uk changed: What|Removed |Added Priority|Lowest |Highest Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #138 from Rich Farmbrough rich...@farmbrough.co.uk 2011-12-30 17:07:15 UTC --- There is, but we have seen no evaluation of expensive - result is that stuff that is essential is split over several pages... Cite templates would benefit enormously from parser functions, instead of jumping through hoops, simple tests can be made about whether something has a full stop at the end already or not. The bug should be changed form WONTFIX, keeping it at that status because of a stray comment on a mailing list years ago, when at Wikimania 2011 Tim was undecided as to which solution (parser functions, scripting language or Victor's extension) was best. Really I have looked at all three, ANY ONE WILL DO. And if you change your mind from parser functions to one of the others, I WILL PERSONALLY MIGRATE ALL TEMPLATES TO THE NEW SOLUTION. I am re-opening this bug. Please do not casually re-close it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #139 from Ted Kandell ted_kand...@yahoo.com 2011-12-31 03:40:25 UTC --- Finally, some common sense here. There are a huge number of templates that now do pretty much everything. My personal interest is in displaying trees and phylogenies. These are incredibly hard to edit now, not even worth it. I've tried to edit genealogical trees, and have given up, because the presentation is mixed up with the data. My browser would crash before I could even get part of it right by repeated experimentation. Expensive? All of these hoops that everyone has to go though to validate templates without any sort of parser functions really has a collective impact on MediaWiki and Wikipedia. NO solution is much much worse than a an attempt at a bad solution. I don't think anyone even realizes the *lack* of editing by knowledgeable people that is taking place, because of the sheer difficulty in editing data that is not text or inline images. There's a price here, and it isn't whether this or that implementation of trim() regular expressions is more or less efficient. It's been 5 1/2 years since this bug was first opened. Maybe someone can get moving on it before a decade has passed? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #140 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-12-31 04:11:05 UTC --- Are string functions really the solution to the difficulty of editing specialized data. To me that sounds like a really horrible solution that won't actually solve the issue. If data really is complex then string functions sound like something that will only allow a change to 'another' string based data format that will still be too complex for the knowledgeable people to edit. I'd like to see some of those complex data formats. I'm pretty sure that for the most of them the real optimal thing they need is specialized code in a proper programming language to create a format that knowledgeable people can actually understand. And perhaps even add in a ui to make that possible. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455
Jim Craigie j...@jim-craigie.com changed:
What|Removed |Added
CC||j...@jim-craigie.com
--- Comment #141 from Jim Craigie j...@jim-craigie.com 2011-12-31 04:34:05
UTC ---
String functions certainly are a solution to the problem that brought me here -
attempting to construct a template to create the slightly unusual URLs used by
an external site, which requires replacing each instance of a non-alphanumeric
character by an underbar. Easy to do with {{#replace:}}
I was horrified to discover that a perfectly good solution has been implemented
but its activation is being blocked for reasons I still cannot understand.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #142 from Bawolff bawolff...@gmail.com 2011-12-31 04:55:28 UTC --- This is pointless. Can we stop beating the dead horse already? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #143 from Ted Kandell ted_kand...@yahoo.com 2011-12-31 05:31:37 UTC --- Yes, string functions they are *a* solution, that can work right now. Why? How would you implement parsing of say a Newick file, or any specialized data format that you didn't know about yourself, beforehand? There are hundreds of such data formats. Some may be very useful for common sorts of representations in Wikipedia. Will we have to open a bug for each and every one, then hardcode a parser for it, then have someone update that parser whenever a slight change in the format comes out? Or would you rather just implement AJAX and Java instead? BTW, how complex is it to parse a phylogenetic tree format which merely uses nested parentheses, and then display it, when these can be copied from anywhere? http://en.wikipedia.org/wiki/Newick_format The point is that often data in these specialize formats *already exists* out there, somewhere, and just needs to be displayed. If you mean stop beating a dead horse and just release these functions I say yes. But if you mean stop asking for them, you'll never ever get them, forget it ... -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #144 from Ted Kandell ted_kand...@yahoo.com 2011-12-31 05:38:11 UTC --- Examples? Here is the complete grammar for the complex specialized Newick format: The grammar rules Note, | separates alternatives. Tree -- Subtree ; | Branch ; Subtree -- Leaf | Internal Leaf -- Name Internal -- ( BranchSet ) Name BranchSet -- Branch | BranchSet , Branch Branch -- Subtree Length Name -- empty | string Length -- empty | : number Examples: (,,(,)); no nodes are named (A,B,(C,D)); leaf nodes are named (A,B,(C,D)E)F; all nodes are named (:0.1,:0.2,(:0.3,:0.4):0.5); all but root node have a distance to parent (:0.1,:0.2,(:0.3,:0.4):0.5):0.0; all have a distance to parent (A:0.1,B:0.2,(C:0.3,D:0.4):0.5); distances and leaf names (popular) (A:0.1,B:0.2,(C:0.3,D:0.4)E:0.5)F; distances and all names ((B:0.2,(C:0.3,D:0.4)E:0.5)F:0.1)A;a tree rooted on a leaf node (rare) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455
--- Comment #145 from Ted Kandell ted_kand...@yahoo.com 2011-12-31 05:40:53
UTC ---
Here is an example of a current genealogical tree, using templates:
http://fr.wikipedia.org/wiki/Rachi#G.C3.A9n.C3.A9alogie
=== Généalogie ===
center
{{Arbre généalogique/début|style=font-size:75%;}}
{{Arbre généalogique | SAM | | | | | | | | | | | | | | |RSH| | |
|SAM=Samuel|RSH='''Rachi ([[1040]]-[[1104]])'''}}
{{Arbre généalogique | |!| | | |
|,|-|-|-|-|-|-|-|v|-|-|-|^|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|.}}
{{Arbre généalogique |SMH| | |RHL|-|AZR| |KVD|v|RMB| | | | | | | | |SMA| |
|MRM|v|YBN||SMH=Simha ben Samuel de Vitry| RHL=Rachel ''Bellassez''|
AZR=Eliézer ''Jocelyn'' | KVD=Yokheved | RMB=Meïr ben Samuel | MRM=Myriam |
YBN=Judah ben Nathan | SMA=Shémaiah}}
{{Arbre généalogique | |!| | | |,|-|-|-|v|-|-|-|v|-|-|^|-|-|-|-|v|-|-|-|.| | |
|!| | | | |,|-|^|-|.}}
{{Arbre généalogique |SAM|v|HAN| |SLM| |RTM|v|MRM| |RVM| |SBM|v|INC| | |YTV|
|AZR|SAM=Samuel de Vitry|HAN=Hanna| SLM=Salomon |RTM=[[Rabbénou Tam]]
(~[[1100]]-[[1171]])|MRM=Myriam |RVM=Isaac Rivam|SBM=Samuel [[Rashbam]]
(~[[1085]]-[[1158]])|INC=?|YTV=Yom Tov de Falaise|AZR=Eléazar }}
{{Arbre généalogique | | | |!| | | | | |,|-|-|-|v|-|^|-|v|-|-|-|.| | | | | |!|
| | |,|-|-|^|-|-|-|.}}
{{Arbre généalogique | | |RI| | | |ITS| |SLM| |MSH| |ISF| | | |ITS | |YHD| | |
| |ISF|RI=[[Isaac ben Samuel de Dampierre|Isaac de Dampierre]] dit le Ri
(~[[1120]]-[[1195]])|ITS=Isaac|SLM=Salomon|MSH=Moïse|ISF=Joseph| YHD=Judah |
ITS=Isaac}}
{{Arbre généalogique | | | |!| | | | | | | | | | | | | | | | | | | | | | | |
|,|-|-|^|.| | | |,|-|^|.}}
{{Arbre généalogique | | |HNN| | | | | | | | | | | | | | | | | | | | | | |ITS|
|AZR|v|BLA| |LAH|HNN=Elhanan (mort [[1184]])|ITS=Isaac|AZR=Eléazar | BLA=Bila
| LAH=Léah}}
{{Arbre généalogique | | | |!| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | |!| | | | | }}
{{Arbre généalogique | | |SML| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | |YHD| SML=Samuel|YHD=Judah de Paris Sir Léon ([[1166]]-[[1224]])}}
{{Arbre généalogique/fin}}
/center
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #146 from Ted Kandell ted_kand...@yahoo.com 2011-12-31 05:48:42 UTC --- http://fr.wikipedia.org/wiki/Rachi#G.C3.A9n.C3.A9alogie In the above tree, I need to add a father for Shémaiah and make Shémaiah the father of Eliézer Jocelyn. That should be a simple change using the above templates, right? No. = Lack of string functions In the Newick format it would take 1 second, and there are tools to create and edit such files. Now think of the hundreds of other easy-to-parse useful standard data formats ... -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #147 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-12-31 06:10:07 UTC --- This Newick format and that genealogy stuff look like a perfect example of what string functions will NOT solve. String functions are for simple text replacements and tests. What are you going to do, write a whole Newick parser in string functions? If, and that's a big if given that we don't have variables inside WikiText, you can manage to implement Newick parsing inside of a template. That template is going to be insanely complex, trying to make minor tweaks to the template which would be sane in a normal programming language are going to become so hard it's nearly impossible. And to top it off that template is going to be so heavy that it slows down parsing for every page you use it on (multiplied by how much you use it and how much data you input). If we have a use for it, then what it sounds like we could use, if we actually have a use for it, would be a real Newick parser. Just as for whatever other formats there are for things that are in fact useful to Wikipedia. Yes there are hundreds of formats, but when we talk about Wikipedia and implementation we only care about the ones that will output things we want on Wikipedia, and within that only the few formats we actually need. We don't have to implement parsing for dozens of formats that do the same thing when there's one format most people can use that'll work. But I would also like to make the point that what I see as the output of those genealogy I can't consider acceptable. It's horrible, absolutely disgusting. A complete abuse of html tables in a presentational way. I don't want to see a new template that outputs the same garbage. Not only do those need a better system of inputting the information, they need a better output. Something you can't do in templates because it likely involves building a .svg or something. From what I see of Newick and your example your argument also falls short. Newick seams to describe trees that only branch outwards. But that genealogy tree appears to re-connect at various points. In other words, it looks like your example tree actually CAN'T be expressed in Newick. Frankly, it looks like you could use DOT. Wonder what happened to graphviz in all this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 John Du Hart j...@compwhizii.net changed: What|Removed |Added Status|REOPENED|RESOLVED CC||j...@compwhizii.net Resolution||WONTFIX --- Comment #148 from John Du Hart j...@compwhizii.net 2011-12-31 06:11:48 UTC --- I'm reclosing as WONTFIX. It's very clear that we're going to have a new solution in the next year to handle these situations. Whether it be Lua, built in Javascript or an extension to handle cite templates. Whatever the fix is, I think the developers have made a point that string functions simply won't be enabled. Therefore, the bug's original request of setting $wgPFEnableStringFunctions = true on Wikimania wikis will not happen. Hence, WONTFIX. Please don't change this unless you are a developer. (In reply to comment #142) This is pointless. Can we stop beating the dead horse already? Agreed. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Danny B. dann...@email.cz changed: What|Removed |Added Blocks|26092 |29087 Depends on|29087 |26092 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455
--- Comment #136 from Happy-melon happy.melon.w...@gmail.com 2011-11-17
16:21:12 UTC ---
(In reply to comment #135)
So why not simply scale down the limits after installing these functions?
Existing string templates can be re-written as wrappers for using string
functions, functionality wouldn't even be broken, we would have lower limits
for whats possible using templates and functions but we would have more
powerful and sane functions provided. They could be used in a sane way as they
are being used right now with less load on the servers.
Template limits are not just hit using string functions, indeed they're not
even the major cause. The citation templates used on a large article consume
much more of the template resources than string functions, as well as stupid
things like the innumerable {{SubatomicParticle}} calls (and their endless
subtemplates) on [[List of baryons]] etc. Reducing the template limits would
break all these cases, and they're not scenarios which could be 'fixed' with
proper string functions.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Dan Wolff 326...@gmail.com changed: What|Removed |Added CC||326...@gmail.com --- Comment #137 from Dan Wolff 326...@gmail.com 2011-11-17 16:28:16 UTC --- A solution would be to define how expensive a parser function is, and set the string functions as expensive while not changing anything else. That way, other parser functions would work as they currently do, while we get the power of string functions, just that you can't use so many. (I think there is already something like this in place already for some parser functions - not sure though) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added CC||reza.ene...@gmail.com --- Comment #134 from Mark A. Hershberger m...@everybody.org 2011-09-24 18:02:19 UTC --- *** Bug 31136 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Krinkle krinklem...@gmail.com changed: What|Removed |Added Depends on||29087 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Phillip Patriakeas dragonlordofxant...@gmail.com changed: What|Removed |Added Blocks||26092 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Dmitriy c...@uniyar.ac.ru changed: What|Removed |Added CC||c...@uniyar.ac.ru --- Comment #131 from Dmitriy c...@uniyar.ac.ru 2010-12-29 08:09:35 UTC --- (In reply to comment #99) (In reply to comment #98) MZ, are you seriously suggesting that the developers will completely re-implement an extension, when the concerns about the original are *not* implementation-specific? I seriously doubt that. I'm suggesting that the sysadmins in charge of running Wikimedia wikis have said rather unequivocally that this extension is not going to be installed. The StringFunctions extension is a means to an end. There are plenty of other ways to implement string manipulation. For years, there has been discussion of implementing a proper programming language into MediaWiki. The current preferred favorite is not Lua, but JavaScript, actually. If JavaScript is the language of choice, there is PHP SpiderMonkey extension. It still is not absolutely stable (only a beta), however I know that some WMF programmers are good in C, so it is probably possible to make few fixes. The question is, how to make these scripts run at ordinary hosters, where there will be no such PHP extension. In such case, one might try client-side JavaScript (in browser), however passing of function / template parameters from server side to client side might become too inefficient. Perhaps one might limit the JS language features to basic subset. Then to run it through PHP mod, when available, slowly interpret in PHP otherwise. Co-location (where you can compile and install PHP mod yourself) have become more affordable in last years, anyway. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #132 from Dmitriy c...@uniyar.ac.ru 2010-12-29 09:05:23 UTC --- The mod can also register PHP classes in JS: http://devzone.zend.com/article/4704 There is also interesting JavaScript-based server Jaxer: http://jaxer.org/ It allows to share a lot of server-side and client-side code. For example, it allows to run server-side jQuery. Things like parsers could be written in JavaScript then used at both sides, thus minimizing the code duplication. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #133 from MZMcBride b...@mzmcbride.com 2010-12-29 09:10:37 UTC --- (In reply to comment #132) These are interesting, yes. However, these comments are really outside the scope of this bug. File a separate bug (if there isn't one already) or start a thread on the wikitec...@lists.wikimedia.org mailing list if you're interested in further discussion about this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #129 from Juraj Simlovic jsi...@yahoo.com 2010-11-24 19:56:25 UTC --- (In reply to comment #128) I've filed bug 26092 for Unbelievable! :)) Yesterday, I was kinda wondering if there was any way of luring someone into creating a brand new bug as a copy of this one. Despicable me, sorry about that.. :) Of course this solves nothing, but right now I am $50 richer! And all it took was mentioning the devs' reluctancy to read some hundred of comments.. :) ps. Perhaps I should be banned for disrupting, but it was worth it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #130 from Phillip Patriakeas dragonlordofxant...@gmail.com 2010-11-24 23:48:21 UTC --- (In reply to comment #129) (In reply to comment #128) I've filed bug 26092 for Unbelievable! :)) Yesterday, I was kinda wondering if there was any way of luring someone into creating a brand new bug as a copy of this one. Despicable me, sorry about that.. :) Of course this solves nothing, but right now I am $50 richer! And all it took was mentioning the devs' reluctancy to read some hundred of comments.. :) ps. Perhaps I should be banned for disrupting, but it was worth it. Actually, I'd been thinking about it for a while, I just finally decided to stop being lazy and do it already. =) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #127 from Juraj Simlovic jsi...@yahoo.com 2010-11-23 22:42:44 UTC --- (In reply to comment #126) Don't see any reason for the negativity and sarcasm concerning this bug (as in comment above) - it's just a perfectly normal and well-reasoned [...] and will hopefully be considered on its technical merits. Simply put: I do see one. No, it is not. I thought it was back then. The long story short: I've developed these StringFunctions (not all by myself of course, there were subsequently three of us:) because I needed them back then in my own wikies. Then someone started this bug and Tim said no. Then we, out of interest, tried to optimize the extension to be more suitable for wikimedia cluster. And again, Tim said no. Then someone managed to merge StringFunctions into ParserFunctions, which were/are installed on wikimedia cluster. And guess what happend: Tim said no. If it ain't clear already, Tim had his chance to reconsider. The only thing left now is: Let it go. The more comments are posted into this bug, the more it becomes and unusable kid chat wall. No developer is probably going to invest into reading thru a hundred of comments, even if a nugget of gold was lost somewhere within. ...Ahh, who am I kiddin? This attempt of explanation is pointless anyway.. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #128 from Phillip Patriakeas dragonlordofxant...@gmail.com 2010-11-24 02:45:54 UTC --- I've filed bug 26092 for *some* form of string parsing functionality to be enabled on WMF wikis, could we please maybe try to keep from turning it into the same mess this bug is (i.e. if you have something *useful* to contribute, by all means do, but if not, no comments saying we need this s bad, the devs aren't being [fair/reasonable/humane/etc])? Not sure if this bug should be marked as blocking it, but it probably doesn't matter anyways since this one is closed. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #123 from Juraj Simlovic jsi...@yahoo.com 2010-11-22 23:22:45 UTC --- (In reply to comment #122) If it's Tim Starling, then I've already left a note on his en.wp user page, Thinking that he doesn't know about this bug or that he is not watching it is way too naive, so all your pokes do nothing but annoyance. Actually, based on my experience with other big projects I (used to) be part of, this bug reads 123 comments as of right now. My humble guess is that Tim no longer bothers to read this bug, probably has it on his ignore list for a long time already. And I'd fully understand him. The decision has been made (I hope it was not taken lightly) and none of the above changes that (though it pollutes what should have been a technical discussion). The only reason I still read this bug is that it is getting funny, and not because I am interested in it as a dev.. jsimlo ps. Yes, this comment also pollutes this bug. But I simply no longer see any cons of doing it.. :) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #124 from Le Chat cat...@vp.pl 2010-11-23 05:13:36 UTC --- none of the above changes that It should change it really, as we now know that (a) there is continuing user demand for this functionality (b) nothing is happening or likely to happen towards providing it in any other sensible way than the one proposed (c) the use of the very inefficient workarounds without ill effect, the use of the proposed functions on Wikia, etc. prove that this functionality will not (as feared) damage performance. Presumably sysadmins don't have completely closed minds, and are capable of listening to users and arguments and taking a second look at past decisions... -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #125 from MZMcBride b...@mzmcbride.com 2010-11-23 06:16:45 UTC --- (In reply to comment #124) It should change it really, as we now know that (a) there is continuing user demand for this functionality (b) nothing is happening or likely to happen towards providing it in any other sensible way than the one proposed (c) the use of the very inefficient workarounds without ill effect, the use of the proposed functions on Wikia, etc. prove that this functionality will not (as feared) damage performance. Presumably sysadmins don't have completely closed minds, and are capable of listening to users and arguments and taking a second look at past decisions... Hahahahaha You're obviously not very familiar with Wikimedia's software development processes. Right now, some of this ParserFunctions mess (and its use in high use templates like Template:Cite) cause page renderings to take upward of 30 seconds on a large article. And still nobody cares.™ If you think a bit of whining (or is it whinging?) in bug comments or attempting to rally some folks on a village pump is going to push anything forward, you're insane. You'd be better off trying to raise some money for a grant, to be honest. (Though not really; Wikimedia is apparently trying to stop accepting money with strings attached.) If you wrote an extension that implemented JavaScript into MediaWiki templates that also doubled as donation-related software, you might be able to attract some attention to this bug before the 12th of Never. ;-) Otherwise, it's probably best to save your energy for battles you can possibly win. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #126 from Le Chat cat...@vp.pl 2010-11-23 07:29:13 UTC --- Don't see any reason for the negativity and sarcasm concerning this bug (as in comment above) - it's just a perfectly normal and well-reasoned feature request, which will actually *reduce* these page-rendering times you mention, and will hopefully be considered on its technical merits. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #119 from Kevin Norris nykevin.nor...@gmail.com 2010-11-21 08:08:12 UTC --- (In reply to comment #117) (In reply to comment #106) There is community consensus to enable StringFunctions; if the developers do not enable it themselves, the community hereby requests that the WMF instruct the developers to do so. That's not really how it works. The developers *are* WMF, or at least a subset thereof. (Or were you under the impression that volunteer devs opinions' mattered in such cases? LOL) The non-volunteer devs *work for* the WMF. If the WMF decides to listen to the community (and that's a big if), I don't think the devs can reasonably say no. What's more, the developers are primarily responsible for making functionality the community wants available to the community. They aren't doing that here, and that's a Bad Thing. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #120 from Happy-melon happy-me...@live.com 2010-11-21 11:44:02 UTC --- (In reply to comment #119) The non-volunteer devs *work for* the WMF. If the WMF decides to listen to the community (and that's a big if), I don't think the devs can reasonably say no. What's more, the developers are primarily responsible for making functionality the community wants available to the community. They aren't doing that here, and that's a Bad Thing. You're confusing developers (who write code for new features) with sysadmins (who manage the servers and turn features on and off). The developers are their own community around their own project: the MediaWiki software. That community is structured slightly differently to a wiki community (there is a clear hierarchy of authority and other different ways of doing things) but fundamentally it is a volunteer project like any of the WMF's others: developers code things that interest them. Most developers work on areas of MediaWiki which will be of use on Wikimedia wikis, as seeing their code in action on the world's 6th largest website is the most tangible reward for their time, but neither the paid nor unpaid devs are beholden to the other WMF communities (and please remember that enwiki is just one of 800 such groups); any more than one wiki community is beholden to another. Many developers work on parts of MediaWiki which will never be installed on Wikimedia wikis. To say that the developers are primarily responsible for making functionality the community wants available to the community is arrogant and false. The *sysadmins*, most (but not all) of whom are also active developers, are the ones who decide which components of MediaWiki are installed on WMF wikis. There is a strict hierarchy amongst sysadmins, and most of them are WMF paid staff. They *are* expected to take the communities' sentiments into account when making changes, and they are indeed accountable to the Foundation. The sysadmin you're talking about here reports directly to the Foundations' CTO; the CTO reports to the CEO, and the CEO reports to the board. The sysadmin who has made this decision is 'above' 90% of the Foundations' paid staff in the organisational hierarchy. Where, exactly, are you planning to go to get this decision overturned? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #121 from Le Chat cat...@vp.pl 2010-11-21 12:00:04 UTC --- Where, exactly, are you planning to go to get this decision overturned? Rather than initiate some kind of power battle, I think we ought simply to politely draw the sysadmin's attention to this discussion and the apparently strong arguments in favour of changing this decision, and hope that he'll now be persuaded. (If it's Tim Starling, then I've already left a note on his en.wp user page, though others may know of more effective ways of giving him a friendly poke.) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #122 from Max Semenik maxsem.w...@gmail.com 2010-11-21 12:42:08 UTC --- (In reply to comment #121) Rather than initiate some kind of power battle, I think we ought simply to politely draw the sysadmin's attention to this discussion and the apparently strong arguments in favour of changing this decision, and hope that he'll now be persuaded. (If it's Tim Starling, then I've already left a note on his en.wp user page, though others may know of more effective ways of giving him a friendly poke.) Thinking that he doesn't know about this bug or that he is not watching it is way too naive, so all your pokes do nothing but annoyance. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #114 from Tisza Gergő gti...@gmail.com 2010-11-20 11:35:35 UTC --- (In reply to comment #110) Experience has shown that people will just write pages that use up whatever the resource limits are. They'll use the functions to write still more complicated templates, which currently they can't write because of preinclusion size limits. It's not at all obvious it will make anything faster, it will just allow more complexity for the same length limit. [...] Maybe we should enable the string functions, but reduce preinclusion length limit, or impose other limits on template complexity. You make it sound as if complexity would be a bad thing in itself. That is not so - complex tasks require complex solutions, most of the time. MediaWiki itself has become much more complex along the years, the editing workflow became more complex, Vector was a huge jump in the complexity of the editing GUI, and so on. Everyone accepts these as necessary, so why not the same for complex templates? Seems like a bit of NIH syndrome to me (or more precisely, Not Invented By Us, because it *is* invented here, just not by the developers). I sense a good amount of developer hubris in the debates about templates - you should leave this stuff to us, we could do it better. Sure you could - but you could do much less of it. By the same account, we should leave writing encyclopedia articles to professionals, because they are much better at it (except that Nupedia had some 100 articles after three years). This line of thinking is completely contrary to Wikipedia philosophy. Wikipedia is about generativity, community empowerment and ultra-low barriers to entry - you can't seriously suggest that making a feature request and waiting for some developer to pick it up every time someone needs a new template would be a scalable approach. People shouldn't have been writing programs in wikitext to begin with, they should use proper scripts of some type -- extensions or bots or such. This gets thrown around a lot, but how those proper scripts could replace the current template system is never demonstrated. Bots are not much help with dynamic text (and do have problems of their own, like littering page histories). Extensions, as I tried to point above, are not scalable (whatever you might think of the template syntax, it is a lot easier to learn than writing secure and scalable MediaWiki extensions, and we didn't even consider yet the epic fail of code review). The conclusion of the bug about Lua was that templates using scripts interpreted by some external tool are out of the question - they have security issues, and they would break compatibility of Wikipedia with pretty much all other MediaWiki installations. What is left then? Inventing another template language and writing another parser in PHP? IIRC Werdna actually offered to do that and was turned down, because that is still not a proper solution. The proper solution, apparently, is to deny the Wikimedia community of a useful tool, out of purely aesthetic reasons. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #115 from Victor Vasiliev vasi...@gmail.com 2010-11-20 12:20:21 UTC --- (In reply to comment #114) What is left then? Inventing another template language and writing another parser in PHP? IIRC Werdna actually offered to do that and was turned down, because that is still not a proper solution. I was working on a template scripting extension called InlineScripts. It is in Subversion and it was working last time I checked (it's most severe problem was the documentation, or, to be more specific, the absence of it). It was discussed on the developers' conference in April and the only reason I stopped working on it was the lack of time. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #116 from Ted Kandell ted_kand...@yahoo.com 2010-11-21 02:18:18 UTC --- I would like to add a concrete example to this debate, an actual use case. Many entries in Wikipedia describe some sort of phylogenetic data, from genealogies, to the phylogenies of language families, to Y and mitochondrial DNA haplogroups. A standard way of representing such trees is through the Newick format: http://en.wikipedia.org/wiki/Newick_format There are all sorts of template hacks in Wikipeida to represent family trees, genetic trees, language families, and all sorts of other related information. Wouldn't it be better to just add the standard Newick format tree representation to articles, and then use templates to display the data in various sorts of ways? The fundamental information would then be preserved in a standardized display-independent format. Also there are a large number of tools out there that can generate graphic images based on the Newick format. It isn't very difficult to parse a Newick format string and create a basic tree display template from it. However, all this really would need is a full set of string functions. It's true that PHP and MediaWiki wasn't designed to be a kind of parser or compiler, but what sort of alternative can anyone think of? Should we put in a request for MediaWiki developers to support the Newick format, and any number of other important display-independent representations of data widely used in Wikipedia? Who decides, and who does the work? There is a good argument to doing it right and implementing a full scripting language (aside from Javascript?) but in the meantime, all sorts of important data that can't quite be represented as text is being added to Wikipedia in the form of templates. How can all the various sorts of tree data now in Wikipedia be extracted - or just redisplayed using whatever new and better display template comes along? I don't know if this can be added as a bug in and of itself, but it it does point out the fundamental problem. MediaWiki has text, graphic, audio, and video formats, but is missing the ability to parse certain other critical basic information storage formats that the developers never considered. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #117 from Gurch matthew.brit...@btinternet.com 2010-11-21 04:34:31 UTC --- (In reply to comment #106) There is community consensus to enable StringFunctions; if the developers do not enable it themselves, the community hereby requests that the WMF instruct the developers to do so. That's not really how it works. The developers *are* WMF, or at least a subset thereof. (Or were you under the impression that volunteer devs opinions' mattered in such cases? LOL) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Alex Z. mrzmanw...@gmail.com changed: What|Removed |Added CC||mrzmanw...@gmail.com --- Comment #118 from Alex Z. mrzmanw...@gmail.com 2010-11-21 06:23:56 UTC --- (In reply to comment #116) It isn't very difficult to parse a Newick format string and create a basic tree display template from it. However, all this really would need is a full set of string functions. It's true that PHP and MediaWiki wasn't designed to be a kind of parser or compiler, but what sort of alternative can anyone think of? Should we put in a request for MediaWiki developers to support the Newick format, and any number of other important display-independent representations of data widely used in Wikipedia? ... I don't know if this can be added as a bug in and of itself, but it it does point out the fundamental problem. MediaWiki has text, graphic, audio, and video formats, but is missing the ability to parse certain other critical basic information storage formats that the developers never considered. This is kind of the main argument against string functions. Letting users create parsers in wikitext is pretty much exactly the kind of thing that those against it want to avoid. Wikitext is not supposed to be a programming language.[1] This is also a good example of what Aryeh was talking about in comment #110. A well-defined language that has applications in thousands of pages is an excellent candidate for something that should be handled by an extension. Who decides, and who does the work? The same person who decides whether or not to enable string functions would decide to enable a Newick extension. Anyone who knows PHP can do the work. [1] http://lists.wikimedia.org/pipermail/wikitech-l/2009-June/043609.html -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #108 from Rich Farmbrough rich...@farmbrough.co.uk 2010-11-19 14:49:13 UTC --- I'm pretty sure it would garner extensive support. #Pro: less server load #Pro: less page breakage #Pro: easier template programming #Pro: faster page load/render times #Pro: less obscure limits on lengths #Pro: less templates which work fine in test but are useless on an actual page #Con: If we implement a scripting language we may need to migrate some stuff - which we would anyway. Things have moved on in four years, but we are still struggling with ancient functionality. Wikia has more powerful facilities than the WMF projects. I'm disappointed someone re-closed the bug, it was not re-opened lightly. Anyone in doubt as to the importance of this bug is invited to look at VP(T) where I believe almost half the threads are related to it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #109 from Happy-melon happy-me...@live.com 2010-11-19 15:49:52 UTC --- (In reply to comment #108) I'm pretty sure it would garner extensive support. ... Anyone in doubt as to the importance of this bug is invited to look at VP(T) where I believe almost half the threads are related to it. You[1] are making a mistake in assuming that if the enwiki community supports a technical change then, ipso facto, that change should be implemented, irrespective of any 'big picture' considerations. You're[1] not in Kansas any more; the consensus of the enwiki community is not sovereign here. I'm disappointed someone re-closed the bug, it was not re-opened lightly. It was re-opened mistakenly under a [[WP:BRD]] principle which just doesn't apply here. It is perfectly acceptable to comment, where appropriate, on closed bugs; the status applies only to the bug title, not to the discussion underneath. Tim has said that the status of the request Set $wgPFEnableStringFunctions=true on WMF wikis is WONTFIX; that conclusion stands until something (maybe discussion under the closed bug, maybe something else) convinces *him* or *another sysadmin of equal standing* to reconsider it. Someone else changing the status does not somehow reshape the world to make it so. [1] I'm speaking generally, not to anyone specifically. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455
--- Comment #110 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-11-19
16:33:30 UTC ---
(In reply to comment #108)
#Pro: less server load
#Pro: faster page load/render times
Experience has shown that people will just write pages that use up whatever the
resource limits are. They'll use the functions to write still more complicated
templates, which currently they can't write because of preinclusion size
limits. It's not at all obvious it will make anything faster, it will just
allow more complexity for the same length limit.
In support of this, observe that ParserFunctions was only introduced to provide
a sane replacement for [[Template:Qif]], much as this bug requests that
StringFunctions be enabled to replace [[Template:Str len]] and friends. The
explosion of template complexity after ParserFunctions were turned on would
have been impossible (given performance limits) with template hacks. It's a
certainty that that will happen again if we enable StringFunctions, with
template editing becoming even more arcane.
Maybe we should enable the string functions, but reduce preinclusion length
limit, or impose other limits on template complexity.
#Pro: less page breakage
How so?
#Pro: easier template programming
Not if things get even more complicated to compensate, which they will.
#Pro: less obscure limits on lengths
The limits on length will be the same, it's just people will write even more
complicated templates to use up the length limits.
#Con: Templates like {{str len}} will no longer count as much against the
length limit, so the effective limit will be higher and people will be able to
make even more complicated and unmaintainable wikitext pages for things that
should have been written in a real language to start with.
I agree that enabling string functions is the lesser evil, but it's still evil.
People shouldn't have been writing programs in wikitext to begin with, they
should use proper scripts of some type -- extensions or bots or such.
Personally I'd also be okay with restricting or disabling any functions that
people are abusing to emulate string functions, like padright/left, but that
would be much more disruptive, and people will always find ways to abuse
innocent functionality. So unless someone is willing to implement a systematic
solution like a Lua extension, we may as well resign ourselves to making
template programming less painful.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #111 from Le Chat cat...@vp.pl 2010-11-19 17:21:09 UTC --- ...abuse... It's not abuse (which would be putting good tools to bad use), this is putting bad tools to good use. ...proper scripts...extensions... Yes, this seems to be the vicious circle we're in... someone *has* written an extension, but what good did it do him - we're now deprived of the use of the extension, just in case someone abuses it by making better use of it than was anticipated. It would obviously be much much better to have non-trivial logic compiled into the software than to do it via templates, but what choice are we given? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #112 from Marcus Buck w...@marcusbuck.org 2010-11-19 19:35:53 UTC --- As far as I can see all of the StringFunctions are already present in template-implemented versions now. Just in an inefficient way. So any abuse (quotation marks because of Le Chat's good remark) would be possible already now. Does anybody have any ideas in which direction possible abuse could go? I cannot think of any new class of functionality that would become possible if we allowed StringFunctions. The template-based string functions too were not enabled by ParserFunctions alone. Template-based string functions would be impossible without padleft: and padright:. These two are string functions. It's clear that when you provide a single string function and simple logic, that other string functions can be emulated. That door was left open and people walked through. But if StringFunctions do not open new doors nothing bad can happen. I don't see open doors in them. If you do see them, please report. I guess we can safely assume that when you provide functionality people will _always_ test the limits of the functionality. It doesn't matter how few or how amazingly much functionality you provide. They will test it limits. It's almost a law of nature. That's normal and we will never have success with We provide this functionality but please don't fully utilize it. We have to put limitations on functionality because we need to limit the computation cost and rendering time. If we replace the template-based string functions with extension-based StringFunctions we will reduce computation cost and rendering time. That's a good thing. If you want to secure that this gain will not be consumed by increased use of the functions then set limitations on how many instances of the functions can be called on a single page. By the way, I'm sure there are wikis with activated StringFunctions. Are there any reports that these wikis had problems with it? If there are any open doors in them, I'm sure somebody must have discovered them already!? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #113 from Phillip Patriakeas dragonlordofxant...@gmail.com 2010-11-19 20:01:14 UTC --- (In reply to comment #112) By the way, I'm sure there are wikis with activated StringFunctions. Are there any reports that these wikis had problems with it? If there are any open doors in them, I'm sure somebody must have discovered them already!? Wikia - *all* of Wikia - has had StringFunctions enabled for years. I've never heard about any problems they've had as a result of this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 Aryeh Gregor simetrical+wikib...@gmail.com changed: What|Removed |Added Summary|Enable StringFunctions on |Set |WMF wikis |$wgPFEnableStringFunctions ||= true on WMF wikis --- Comment #105 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-11-18 22:08:20 UTC --- Note that string function support was added to ParserFunctions proper in r50997, and disabled by default by Tim in r51497 -- a separate extension is no longer needed. I don't know if anything has happened since June 2009 to cause him to reconsider his opinion. I personally have thought for a long time that enabling string functions is the lesser evil here, given the givens, but it's not my call. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 --- Comment #106 from Kevin Norris nykevin.nor...@gmail.com 2010-11-19 02:04:16 UTC --- Could Tim Sterling please indicate whether his veto on this bug is still outstanding? If it is, I intend to bring it up on [[WP:VPT]] or somewhere and make the following proposal: There is community consensus to enable StringFunctions; if the developers do not enable it themselves, the community hereby requests that the WMF instruct the developers to do so. I really hate to go over your heads on this one, but it appears to be necessary. As Aryeh said, SF is clearly the lesser evil and it's patently ridiculous that the nth most popular site in the world (n=whatever our current Alexa rank is) is using [[Category:String manipulation templates]] instead of native php, especially when the functionality to do so is available and tested. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 6455] Set $wgPFEnableStringFunctions = true on WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=6455 msh210 m.ham...@alumni.nyu.edu changed: What|Removed |Added CC||m.ham...@alumni.nyu.edu --- Comment #107 from msh210 m.ham...@alumni.nyu.edu 2010-11-19 07:21:39 UTC --- (In reply to Kevin Norris's comment #106) If it is, I intend to bring it up on [[WP:VPT]] or somewhere and make the following proposal: There is community consensus to enable StringFunctions; if the developers do not enable it themselves, the community hereby requests that the WMF instruct the developers to do so. If you do bring up such a proposal on-wiki, please link to it in a comment on this bug so that people on other wikis know. Thanks. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
