Do you mean alongside with svg files in File: namespace or as a part of them? I really prefer the second one if it's possible.

Change #1197046 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/core@master] [POC] SVG content model

https://gerrit.wikimedia.org/r/1197046

I created a POC for this. I'm not sure how useful it is though. I was mainly aiming to have the normal transclusion syntax for such pages return the image instead of the code. But it turns out Content's getWikitextForTransclusion() is expected to return wikitext without strip markers, so it doesn't work unless/until <svg> is recognized markup (T334372).

Also, even if it worked, for SVG code to accept parameters (eg. {{{widith|20}}}), the parser will have to be run on the code, which could result in surprises in cases where SVG code looks like wiki code. (Unless there's a way to tell the parser to expand just parameters and ignore other wiki markup?)

Can ACE be adapted for svg with wikitext parameters?

In T407709#11288059, @IKhitron wrote:

Do you mean alongside with svg files in File: namespace or as a part of them? I really prefer the second one if it's possible.

The other possible way is to use the first option, to create an SVG: namespace that looks pretty much like Module:, and to move all existing svg file, on Commons and local ones, from File: to the new namespace.

Both ways are very ambitious. But leaving two different and unconnected ways to save svg on Mediawiki doesn't sound good, FMHO.

Maybe it should be an "XML" content model (or perhaps an SVG model extended an XML content model). for example, i see people put random kml files as a wikipage sometimes, which would make sense to be marked as XML.

I guess there is two versions of this feature request:

• The basic - just mark pages as containing an XML file, and have syntaxhighlight highlight the results on view. Similar to how JSON pages work
• Actually doing something with the SVG. e.g. rendering it on view, allowing transclusions that work meaningfully, etc

I created a POC for this. I'm not sure how useful it is though. I was mainly aiming to have the normal transclusion syntax for such pages return the image instead of the code. But it turns out Content's getWikitextForTransclusion() is expected to return wikitext without strip markers, so it doesn't work unless/until <svg> is recognized markup (T334372).

The interface is kind of frustrating. In an extension I was working on once, i worked around this by making a secret parser function that was only meant for use by getWikitextForTransclusion(). Unfortunately that approach is probably too hacky for core.

And by the way, are you planning a preview/image in view mode?

In T407709#11288068, @SD0001 wrote:

I created a POC for this. I'm not sure how useful it is though. I was mainly aiming to have the normal transclusion syntax for such pages return the image instead of the code. But it turns out Content's getWikitextForTransclusion() is expected to return wikitext without strip markers, so it doesn't work unless/until <svg> is recognized markup (T334372).

Also, even if it worked, for SVG code to accept parameters (eg. {{{widith|20}}}), the parser will have to be run on the code, which could result in surprises in cases where SVG code looks like wiki code. (Unless there's a way to tell the parser to expand just parameters and ignore other wiki markup?)

I'm not neccesarily suggesting that we should do this, but i think the most native-to-svg way to do parameters would be to have entity references in the svg file, and when a parameter is passed to edit the <!ENTITY tag in the internal subset of the dtd to change the entitie's value.