Tim Starling wrote:
> Ryan Lane wrote:
>> ParserFunctions is an amazing example of this. MediaWiki
>> simply doesn't work without ParserFunctions. You can tell me it does,
>> and that people can live without it, but I refuse to believe that. We
>> get support issues extremely frequently that end in "install
>> ParserFunctions".
> 
> I wrote ParserFunctions under protest, and I hoped at the time that it
> would not be essential or widely used. That's why it was an extension.
> Maybe the time has come to merge it in.

To me, this has consistently seemed like a "perfect is the enemy of done"
issue. I understand your reluctance to merge ParserFunctions into core, but
there really doesn't appear to be any viable alternative on the horizon. For
years now, we've added extra hassle to nearly every MediaWiki installation
under the pretense that one day, there might be something better than
ParserFunctions.

Similar arguments apply to StringFunctions, which are intentionally disabled
on Wikimedia wikis, even though people have created far worse hacks and
workarounds using functions like {{padleft:}}.

If there's a realistic goal and timeline for an better template syntax
system (JavaScript, Lua, whatever), I think it would be fine to continue
putting this off. But if it really is a pipe dream, I don't think it's
sensible to continue shipping MediaWiki without at least ParserFunctions.

> I also wrote the ImageMap extension, which some might argue should be
> integrated.

I'm not sure who might be arguing for ImageMap to be in core. The largest
use-case of ImageMap I ever saw was as a hack to override the link
destination of images, which was finally properly integrated into image
syntax (by you, as it turns out). I don't think most wiki installations
would find any value in this extension.

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to