The problem is with the SVG and not with MW or the render. The text is long enough that it overruns the margin. The SVG should defend against this problem by making sure the text has enough room. Although SVG is scalable, fonts do not scale linearly.

Some time ago, I learned that the langtags were stored in the MW database (they are a bit buried in the API). I'm not a MW expert.

MediaWiki uses librsvg to paint SVG files.

I just fixed a text positioning issue in a file and triggered this bug:

• https://commons.wikimedia.org/wiki/File:Basis_of_Membrane_Potential2-en.svg

Another user bitten by the bug:

• https://commons.wikimedia.org/w/index.php?title=Commons:Graphics_village_pump&diff=prev&oldid=821494579

Why is this task stalled? Rust is available on the Debian upgrade.

Yet another victim of the T97233 tspan regression:

• https://commons.wikimedia.org/w/index.php?title=Commons:Graphic_Lab/Illustration_workshop&diff=prev&oldid=814291771#File:Sum_and_difference_of_2_cubes.svg

In T97233#9249205, @hnowlan wrote:

In T97233#9248038, @Glrx wrote:

I see fixing this issue as a high priority. It is confusing many users and probably affects thousands of files. Librsvg does not follow the fundamental rules about painting text.

I raised the priority of T265549 to high (it was low). Librsvg should be upgraded to fix SVG issues independently of upgrading to Bullseye.

When will WMF use Bullseye? IIRC, Buster was promised for July 2022 but was not released until April 2023.

Work on migrating to buster didn't even start until July 2022 so wherever stated that was very incorrect.

Support for Thumbor is in the process of being moved between teams, upgrading librsvg versions will be addressed as soon as we can.

Some rank speculation.

In T337199#9256106, @TheDJ wrote:

Clicking like that takes you to the raw original SVG, which means the browser renders them instead of Mediawiki, and browsers don’t support SVG translations. So yes, this is expected. Translations only work in the thumbnails, and naturally if people make very large drawings, those won’t be very readable, unless you have a desktop screen and use the media viewer. This is documented on the SVG help page and has always been like that.

I see fixing this issue as a high priority. It is confusing many users and probably affects thousands of files. Librsvg does not follow the fundamental rules about painting text.

Following remark of Aklapper in T97233, raising priority to high. Many users are stumbling across that regression bug.

Another victim:

• https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Technical&diff=prev&oldid=811117414

In T337199#9193502, @Bawolff wrote:

So i think related to the fix for T310235.

MediaWiki considers english the default, but maybe thumbor does not. So if something is set to english, mediawiki sees it equals the default and does not send the language along. Thumbor sees no language specified and assumes undefined.

Another complaint:

• https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&diff=prev&oldid=803253221#Clitoris_Anatomy_labels

Another user complaining about en failing:
*https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&diff=prev&oldid=803253221#Clitoris_Anatomy_labels

Another user running into this issue:

In T64986#9173170, @Timeshifter wrote:

I see lots of stuff between style tags in the SVG code. Is the problem this?:

<style>@import url(https://ourworldindata.org/fonts.css)</style>

That is something recently added by OWID.

Possible fix described at T337199 and T337139

When a URL does not specify lang, then set env to {'LC_ALL': 'en'} so rsvg-convert` knows the language should be English ("en").

@hnowlan
There is a related problem at T337199.

Code fix is would be related to T337139 by @hnowlan. Will comment there about the fix.

Another user has problems:

• https://commons.wikimedia.org/w/index.php?title=Help_talk:SVG&diff=prev&oldid=800280167

Gnome issue is

Reopen. Regression error.

To fix T344564 (font fallbacks), we need to upgrade to at least librsvg 2.48.5.

The font specification is done with

style="font-family:Lato, 'Helvetica Neue', Helvetica, Arial, 'Liberation Sans', sans-serif;font-size:18px;background-color:white;text-rendering:geometricPrecision;-webkit-font-smoothing:antialiased"
style="font-family:'Playfair Display', Georgia, 'Times New Roman', 'Liberation Serif', serif"

Another file is displayed incorrectly.

• https://commons.wikimedia.org/wiki/File:CoulombsLaw.svg

Another significant file on Commons that has the problem:

• https://commons.wikimedia.org/w/index.php?title=File:Standard_Model_of_Elementary_Particles.svg&lang=en

This issue was fixed in the 2.40 C-version of librsvg.

It looks like the file does not have a translation in the first 256kB.

This issue is a dup of T97233.

Renderer miscalculates the width of a text chunk.

The SVG file displays Portuguese:

• https://commons.wikimedia.org/w/index.php?title=File:Wikidata_nodes_in_white.svg&lang=pt

Reopen. Fix not complete.

In T335361#8836558, @hnowlan wrote:

For the short term we can hack around this rather than worrying about building a new version which will take time due to the differences in rust build environments in Debian.

Doing the following I see valid images being generated with Window (windowing system).svg:

for i in ar en de ru fr tr; do LC_ALL="$i" /usr/bin/rsvg-convert Window.svg -u -f png -w 800 > $i.png; done

This change should hopefully address this. Thanks for the report and the handy repro cases!

The current version of the file uses Unicode subscripted numbers AND a dy attribute:

This appears to be the same bug as T97233. That bug claims to be fixed in librsvg 2.50.2.

The problem is computing the width of an SVG "text chunk". If the text chunk consists of multiple XML nodes, then librsvg is using the width of the last node as the width of the entire text chunk. (librsvg is correctly tossing out the initial and final whitespace for the text element.)

In T65236#8919944, @JoKalliauer wrote:

@Glrx: According to T65236#8458679 the SVG-file has been fixed, could you provide an image that currently provides this issue and edit the task-description. (Otherwise I find it unclear&confusing.)

@Dzahn: Could you provide the fc-list as you already did in T280718#7025405 ?

In T337199#8887111, @IKhitron wrote:

I need to change the "File:Moscow metro map multilingual future draft.svg". If you still need it please fill free to revert to yesterday's version.

In T337139#8881950, @AntiCompositeNumber wrote:

The right thing to do is avoid locales entirely and pass the langtag through --accept-languages, but that must wait for next version of the operating system.

Packaging our own librsvg version or backporting from bullseye should be more possible than it was on stretch, since most (all?) of the rust buildchain dependency issues should be solved. I don't know if anyone's looked at the feasibility of doing that recently though.

In T337139#8880493, @hnowlan wrote:

Thanks for the report and the test cases. This change attempts to build valid locales to fix both of the issues. I am curious as to whether our approach of using these languages in Thumbor when we used LANG rather than LC_ALL would have ever worked for these language tags.

This bug affects a rather prominent SVG:

In T336917#8878586, @Samwilson wrote:

IIRC, SVG Translate has defined the svg prefix

It's added the svg namespace if it's missing, but it hasn't renamed any existing nodes has it?

Some comments.

This bug should affect all multilingual SVG that does not use English as the default.

T261192

The approach is reasonable.

T280718: Re-evaluate whether keeping around https://noc.wikimedia.org/conf/fc-list is a good practive

Many Noto fonts are in the fc-list, but NotoSansCJK is not Even "CJK" is not in the fc-list.