@Aklapper I'm not shure if the file is invalid, if I insert the source-code in https://validator.w3.org/#validate_by_input there are only warnings, but no error. (i.e. valid)

I don't know why the file is recognized as text/plain and not as image/svg+xml.

@Glrx You are the expert on SVG-standartization and about xml-validation. Can you comment on that?

@JoKalliauer: You are right, thanks for the correction!

I think this falls out from the inner workings of Commons. Commons tells the world the file is plain text, so why should SVG Translate believe otherwise?

The file description on Commons is
https://commons.wikimedia.org/wiki/File:Diagram_human_cell_nucleus_ru.svg

If you access the actual SVG file from a browser, it displays as text:
https://upload.wikimedia.org/wikipedia/commons/7/7c/Diagram_human_cell_nucleus_ru.svg

If you look at the response header from Commons, it has
content-type: text/plain
That's why the browser displays text.

It may also be the reason that SVG Translate says it is not an SVG file. SVG Translate asks Commons for the file, Commons responds with the file saying it is just plain text, and SVG Translate believes Commons. Alternatively, SVG Translate may ask for Accept: image/svg+xml and get a negative response.

IIRC, there was some comment that Commons will serve an XML file as plain text unless the file has an XML processing instruction. So the file would need
<?xml version="1.0" encoding="UTF-8"?>
but it would not need the DOCTYPE.

I'd lay the bug on Commons. If Commons displays the image aa an SVG file, then it should serve that file as content-type: image/svg+xml. There may be a security issue here.

As far as the SVG Translate error message goes, it should add that it might be an SVG file that is missing its XML processing instruction. That would be better for the user. I do not think SVG translate needs to investigate files that are text/plain to see if they are actually SVG files. That may be a security issue.

Yep, it seems that it is Commons doing something inconsistent. The tool looks at the Content-Type header of the response for the SVG file, and fails if it's not image/svg+xml (which happens, as you say, when <?xml version="1.0" encoding="UTF-8"?> is missing).

I guess the difference is that MediaWiki does extra checks to see if a file is SVG, but whatever is serving the actual file is not.

We could switch to looking for <svg if the Content-Type check fails maybe? Or should these files actually be fixed on Commons?

I vote for fixing the files on Commons. Every XML file should start with an XML processing instruction.

https://www.w3.org/TR/xml/#sec-prolog-dtd states

"Definition: XML documents should begin with an XML declaration which specifies the version of XML being used."

If a file does not start with the XML processing instruction, then it is not XML (and therefore not SVG). I'm OK with being narrow-minded and prescriptive here.

SVG Translate could also refuse to process any encoding that does not say it is UTF-8. Or does SVG Translate's XML parser handle other encodings? The SVG Translate output will have to be UTF-8 for Arabic, Chinese, and many other languages. I think librsvg believes everything is UTF-8, so everything on Commons must be UTF-8 compatible.

A commons 'bot could find and fix SVG files without the appropriate prolog.

I would close report this as won't fix. Quite simply, SVG Translate requires Commons to serve files with the correct content-type header,
and Commons should serve SVG as image/svg+xml.

If anything needs to be fixed, it is the part of MediaWiki that serves SVG files as text.

If anything, the report to fix is T131012 (which claimed back then that files were served as content-type: text/html or application/xml rather than text/plain). Also T44725.