Feature summary: add the missing link from LUA interpreter to SVG rasterizer on wikimedia commons

Who would benefit:

• all users (faster wikis)
• users with older and simpler web browsers
• WMF (decreased maintainance cost, bloat, and energy bills)
• commons contributors and sysops (less mass-type content)
• other contributors (easier to find desired image)

Problem:

• SVG supports multilinguality to some degree, but not parameters
• wikis support the parameter "lang=" that can be abused https://commons.wikimedia.org/wiki/Category:SVG_files_abusing_the_switch_feature but this hack does not work well
• having many files differing in details is a common scenario, examples: https://commons.wikimedia.org/wiki/Category:Sixteen-pointed_compass_roses_(blue_or_white,_grey,_pink)#40_new_files https://commons.wikimedia.org/wiki/Category:SVG_chess_pieces https://commons.wikimedia.org/wiki/Category:SVG_chess_pieces/Standard https://commons.wikimedia.org/wiki/Category:SVG_Taxonomy_diagrams_(Pengo)
• there are 40 multilingual files of topic "Sixteen-pointed_compass_roses_(blue_or_white,_grey,_pink)"
  • every of them has a separate description text, thus 80 histories for one image
  • how to add a language? I run my generator existing on my local computer, resulting in 40 local files and 40 local descriptions, subsequently I upload 40 files and 40 descriptions one at a time (an alternative is a painful and prolonged bot request)
• presence of many similar files generates the illusion of usefulness and advancement, but is in fact waste of resources and maintainance nightmare, ie I advocate the principle "one generator is much better than hundreds of files"
• it repeatedly happened to me when searching for a file that I indeed found many files, but none of them was usable, because the one with desired language had wrong background or wrong detail highlighted, and vice-versa, not to talk about old PNG JPG and GIF files

Proposed solution:

• allow to generate SVG by LUA modules accepting parameters, for all language, other details (such as background color, highlighting), and size (thus language and size would be controlled only by those parameters and nothing else)
• for example, " https://commons.wikimedia.org/wiki/File:CompassRose_(mul)_16_blue_intercardinal.svg?lang=da " could be replaced by "File:CompassRose16|lang=da|bkg=blue|hl=intercardinal|width=200" ie only ONE file instead of 40
• this does not require adding any new major technologies, but only the missing link from existing LUA interpreter to existing SVG rasterizer
• this should be available on commons only in order to prevent further worsening of major problem T121470 staled forever
• this is an alternative to T334372 inline SVG and has the benefit that the concept of rasterization of SVG is preserved, and support for inline SVG is not required from the browser
• create a new namespace (preliminarily called "Gensvg:") on commons where LUA modules can be executed
• prevent those "Gensvg:" modules from taking any other input than parameters such as "mw.site.stats" or "os.time" ie implement a strict principle "outcome depends on parameters and nothing else" in that namespace
• prevent those "Gensvg:" modules from interacting with ordinary modules or templates
• prevent those "Gensvg:" modules from outputting garbage, multilingual SVG, animated SVG, too small (say below 20px x 2px), too huge (say over 1000px x 1000px) and whatever is undesirable
• restrict "Gensvg:" modules to one function per module
• set up two methods for calling them, such as (any wiki) [[Gensvg:CompassRose16|lang=da|bkg=blue|hl=intercardinal|width=200]] for displaying the image (sent as PNG to the browser), as well as a method for testing with built-in "pre" such as (only commons) {{#gensvg:CompassRose16|lang=da|bkg=blue|hl=intercardinal|width=200}} diaplaying the generated SVG code
• so my generator currently existing on my computer only would be at commons as "Gensvg:CompassRose16" where it would be much more useful
• this does not affect existing LUA modules or existing SVG files (redundant files could and should be deleted via the ordinary deletion process)

This task is not of the type " add as many features as quickly as possible ", but of the type " improve the overall system efficiency ".