The file that loads initially is also being produced by our invocation of rsvg, so it seems like that the error is being introduced by our manipulation of the SVG. (This is good.)

We should be able to add a test based a minimal part of the above SVG file to confirm that we're modifying all the tspan's attributes correctly. I wonder if some part of the style attribute is malformed?

The file has text element stroke and fill properties countermanded by tspan elements. Generally, text should not be stroked in an SVG file unless one is looking for special effects. The "Pinna" rendering is the most dramatic for the bug. Look at "Pinna" in the tool's rendering; only the strokes are visible and the fill is none. On Commons, the text is not stroked but filled with saturated red.

<text
   x="121.01102"
   y="329.13699"
   id="text4209"
   xml:space="preserve"
   style="font-size:60px;fill:none;stroke:#000000;stroke-width:1px"><tspan
     x="121.01102"
     y="329.13699"
     id="tspan4211"
     style="font-size:60px;fill:#ff0000;stroke:none">Pinna</tspan></text>

The tool is using the text element paint context when it should be using the tspan context.

Other text has the red fill in the text element; text looks darker and bolder in the tool due to the black 1px stroke.

I was not able to reproduce this on staging or production, using the svg in the description. I also compared the SVG downloaded from svgtranslate with the one from Commons. The <tspan> style attribute is being preserved correctly.

Lots of visual comparisons of svgtranslate and Commons was done in T215580#5115279 (and incidentally as part of other testing). While there can sometimes be differences in font rendering (probably due to rsvg), nothing like described here.

Suggesting this is fixed.