https://bugzilla.wikimedia.org/show_bug.cgi?id=69540
--- Comment #11 from Brad Jorsch <[email protected]> --- (In reply to Jackmcbarn from comment #9) > I wonder if this tradeoff was worth it. Maybe we should have > $wgScribuntoAllowedResourceLoaderModules[] that extensions can add to, and > have a Lua method to pull in any listed there. I think we'd be better off > doing that if it meant keeping this a pure-Lua library only loaded on demand. I don't much like the idea of adding yet-another config variable. It's probably better to allow non-pure-Lua libraries to be loaded on demand. Gerrit change 163211. (In reply to Jackmcbarn from comment #10) > <jackmcbarn> but enwiki infoboxes will continue to be fed to a shell around > capiunto via wikitext. and frame:preprocess is considered evil, up there > next to goto > <hoo> Wikitext and the Parser are awry, sure > <hoo> but I doubt we can get around that > <hoo> still a MediaWiki world > <hoo> and people expect stuff to work "like templates" > <jackmcbarn> before Lua, there was a guarantee that text wouldn't get > preprocessed twice > <jackmcbarn> now this will be preprocessing stuff twice, and it could break > fragile things > <jackmcbarn> (the reason preprocess is considered evil is that all text in > lua should already be preprocessed) > <hoo> I know... but this is supposed to be easy to use and I don't want to > completely throw this over > <hoo> also I'm not sure how that will work with content from Wikdiata Then the fetch-from-Wikidata should preprocess when necessary. Don't go preprocessing everything that comes in from the parser, double-preprocessing is bad. -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
