Comparison image for illustrating the text handling of different SVG libraries:
https://commons.wikimedia.org/wiki/File:Comparison_raw_text_converted_path.svg

@brion Packed text passage could be solved in SVG 2.0 with the new text properties "inline-size" https://www.w3.org/TR/SVG2/text.html#InlineSize and "shape-inside" https://www.w3.org/TR/SVG2/text.html#TextShapeInside, if SVG 2 is implemented into librsvg but I am very pessimistic with that. Anyway it's true that localization usually requires the active vector artist (usually the original author) to rework the image for minimal collision of elements after the image is translated by another contributor with little knowledge of SVG.

@brion High quality SVG images by User:Kelvinsong made from scratch. He usually duplicates all texts to the higher layer and set it to opacity=0 then path-izes the visible text. I respect him, but I can sincerely say there is absolutely no reason to do that except that Wikimedia and many readers do not have his type of preference, Neue Frutiger, installed which isn't legally free to my knowledge.

The problem I can foresee is that this would further discourage our vector artists from NOT converting text to path because you can't require our readers to have the same typefaces installed on their OS as those specified in the SVG file. Even if they do have the required typefaces, different SVG renderers have different interpretations of kerning (glyph horizontal spacing). I want consistency of text appearance while still maintaining text to be selectable and searchable, and funny though this is what PDF format is capable of while keeping the general file size smaller than the same SVG image which has all its text converted to path, because most vector editors like Inkscape and Adobe Illustrator do not share path object of same glyph of same font during conversion. I use the free RSVG-Convert tool (http://opensourcepack.blogspot.hk/2012/06/rsvg-convert-svg-image-conversion-tool.html) to create PDF version of my SVG. The resultant PDF while is not completely but reasonably consistent to my SVG source.

@Aklapper No. As a complete outsider, the only things I actually know about are that Mozilla's staffers are involved in the SVG 2.0 draft and the fact that Firefox has implemented the SVG 2.0 only paint-order property (can be enabled in the stable release, not just nightly). Nonetheless browsers render SVG in real-time, rasterization is a different story.

@Isarra Of course I understand. I just want to bump this topic up once again. Mozilla keeps updating its SVG renderer and is even preparing for 2.0. I just want to show my great concern that SVG in Wikimedia is dragging behind due to the inactive/passive update of RSVG. If the Foundation has good funding to use then SVG is one thing deserves the investment. My expectation is very simple: Fix the major bugs/glitches and prep for 2.0.

@Gilles I wonder if the software is able to detect if the specific size is actually being used in any wiki page instead of being called merely "for personal use" so the system will remove the thumbnail of the latter case to free up some space.

The bad support of text of RSVG is having a very bad influence to our vector graphic contributors. Font issue aside which has very little to do with RSVG, many SVG contributors prefer to convert text to path due to lack of supports of textPath, writing-mode and really poor scaling and rotating result of text. Even if you scale the SVG image by integral multiplier (e.g. 2, 4, 8), text kerning still looks misinterpreted. If you rotate the text, it just looks bumpy on a rocky road.

There should already be a link to the nominal size if its sane.

There is never a PNG render link of the nominal size unless the SVG native size is coincidentally the same as one of the presets.

Fixed width isn't helpful. It is better to provide the PNG link of the same native/nominal size as the source SVG. Also there should be a width entry box for reader to generate the link of specific size on demand instead of providing bunch of presets.