On 6 August 2017, the default version's first word was removed by changing <tspan>Observation</tspan> to just <tspan/>. The default English translation was now just "Screen" instead of "Observation Screen".

In T210960#5350704, @Aklapper wrote:

If anyone feels like proposing a patch in Gerrit and if the proposed fonts are available as Debian packages: The files to edit are https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/mediawiki/manifests/packages/fonts.pp and https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/fc-list

https://gitlab.gnome.org/GNOME/librsvg/issues/48 GNOME 48 "[BZ#641823] transform="rotate(x)" causes incorrect gradient rendering."

I've skimmed the comments going back about 2.5 years. It looks like most bases are covered.

Looking at Meta SVG fonts.svg suggests:

I've been thinking about this request. Adding more fonts seems like it must be a good idea, but many of the fonts above raise questions. Do we need Fira Sans, Linux Biolinum, Cardo, Junicode, Vollkorn, or Avocado? That a font is free is a requirement for Commons, but that does not mean that every free font should be loaded onto Commons. So I'm left to ponder the meaning of "Missing fonts".

should be subtask of T215835

There was a problem with File:999-percentages.svg when used on toolforge. I suspect toolforge cached a local copy of the file. I uploaded a new version of the file to Commons and purged the Commons File: page. I suspect the purge invalidates conventional WMF servers but not toolforge's cache. Toolforge probably thinks the file is still fresh, so it does not contact Commons to see if the file is still current.

File:999-percentages.svg had issues.

Original SVG preview shows. Changes do not show and trigger another popup.

Should be sub of T215835

No, you should not overlook any transform.

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.

The bug looks like the tool scanned the switch element:

The sustainable text starts out as

I edited File:Human leg bones labeled.svg to clean it up and fix the leaders. Originally, the text elements looked something like:

When the page loads, "sustainable" appears on the image over the radial fill, but then the image is overwritten and "sustainable" disappears.

Just a note about the original files.

These issues arise from the underlying graphics, which are less than ideal for translation.

Thank you for the progress update. I'm happy to hear the good news.

The 380kB file in T212660

This ticket is similar T180923, which complained about fc-list and unknown fallbacks.

My take is it is bad. The fc-list should be an accurate reflection of the fonts available to librsvg. I think that problem was raised in another librsvg ticket.

A better option would always serve small (say less than 20kB) SVG files.

Gnome closed issue 319 on 23 August 2018 with commit https://gitlab.gnome.org/GNOME/librsvg/commit/3d84acca9c11482cb0d2f75d379086be21bd4c91

The good news: Gnome #131 and Gnome #256 have been closed.

The cited example is from File:Neural_crest.svg

I'd close this as a dup of T201207 and T202771.

There are several issues.

Ignoring subscripts, font shifts, and other exotica:

The Translation possible - SVG category is/was an invitation to use SVGTranslate on the file or to use a graphics editor to change the strings and upload to a new file name.

In T201207#4510890, @Niharika wrote:

@Glrx I understand that broken translation units are a big problem.

Translate SVG makes the desirable assumption that an SVG switch element holds exactly one translation unit. Each text element is one translations, and separate lines will be tspan child elements. That makes it easy to find translation units.

The tool we build will need to make an assumption too. Is this the right assumption to make?

In T201207#4505427, @Niharika wrote:

Firstly, thank you so much for your thoughts, @Glrx! That's very helpful. I have some follow-up questions for you below:

Many files on Commons are not suitable for translation. Many SVG files need either problem detection or remediation, and that can be helped using the SVGDOM. A simpler approach would have somebody who knows the issues flag a file as a reasonable candidate for translation. If the file is simple, then a translation tool can work on it. Translate SVG tries to recognize some problem SVG files, but in the intervening years many other difficult-to-translate SVG files have appeared.
The SVG files on Commons have many quirks, and neither SVGTranslate nor Translate SVG expected many of them.

Can you list out some of the problems which come up? Examples would be very helpful. It'll help us be more cautious when making technical and design decisions.

Quiddy wrote:

Kelvin13 might have good advice. He wrote this page of related guidance (that I just found) https://commons.wikimedia.org/wiki/User:Kelvin13/SVG_text_tutorial , which I wish I had seen a few days ago when I was converting an SVG!

I commend Nikerabbit's brain dump. I'm having trouble paging all the details back in.

Adding TheDJ because this is similar to T201274

Tried to do manual upload, but had problems.

I ran SVGTranslate on [[File:Planetary transit.svg]] and keyed in some bogus translations.

MW does not look at class, so bug is in librsvg. Not clear that it has been reported there.

librsvg mishandles hyphenated languages such as zh-Hans.

MW does not look at transform or filter, so this would be an upstream bug with librsvg. I do not know if it has been reported at Gnome.

I'll put a finer point on it: the suggestion would violate the SVG specification, so it should not be done.

I agree with Perhelion and would close this bug as won't fix. "DejaVuSans-Bold" is not a font-family, so we should not expect a font matcher to find it; we would expect a substitution. That substitution would not be bold because the user did not specify font-weight:bold. Maybe some font matchers will do better, but we should not expect that result.

Also same bug as T64987.

Yes, close this as a dup of T64987.

https://gitlab.gnome.org/GNOME/librsvg/issues/95 GNOME #95.

This is the same bug as T184369. AI is putting quotation marks around the font name, and librsvg gets confused by the marks.

Thanks for developing the code, and thanks for your comments and advice.

In T40010#4432887, @JoKalliauer wrote:

@Glrx : If we only talk about renderingquality, we might should change to Inkscape.

At this point, we should not use resvg even if there were a Debian package.

The W3C Validator isn't bad; it just isn't as clever as it once was.

No matter what the priority is, it should be a one line fix to the regex at line 328:

Apparently an upstream bug in librsvg.

line 328: $viewBox = preg_split( '/\s+/', trim( $this->reader->getAttribute( 'viewBox' ) ) );
line 329: if ( count( $viewBox ) == 4 ) {

JoKalliauer is correct.

data: should be followed with a MIME type.

There is nothing wrong with the SVG rendering. The wiki markup produces correct HTML with an img element that displays a Finnish PNG version of the i18n SVG. The image looks fine. The problem is that the fi.WP flagged the addition of the "|lang=fi" parameter as bad wiki markup even though the markup should be correct.

The present bug report is about a few SVG problems. MW supports SVG files with switch element translations. That facility was added a few years ago. It had a few bugs (some not its fault), but it mostly worked. The bugs should be simple to fix. It should not be 250 lines of code.

Will somebody who knows how to use gerrit please pull this abomination back.

The translation tag is Finnish: "tag-virheellinen_wikikoodi"

That's why I said "modulo librsvg's limitations". Librsvg IETF langtag matching only uses the first subtag, so "zh-hans" and "zh-hant" are both treated as if they were "zh". If the "zh-hans" clauses always precede the "zh-hant" clauses, then only "zh-hans" will display.

Hyphenated langtags such as zh-hans are working again at least on en.WP and meta (well, modulo librsvg's limitations). I imagine that implies everywhere because they use the same URL host.

Abandon this patch. It is still confused and far too complicated for issues.

Hahaha. It's just simplest not to mess with the case. I don't see any reason to change it

"With this patch the file page UI will display a dropdown containing all the systemLanguage attributes from the SVG file."

Please abandon 385352.

My take on MW is that the system code uses lowercase langtags everywhere. If I look at language objects, then they will have lowercase langtags such as "zh-hant" rather than "zh-Hant". Only in the display of a langtag to the user is it made IETF canonical, and that is only because it is prettier.

ImagePage.php
line 1057 makes $curLang IETF canonical
line 1058 makes $defaultLang IETF canonical

I'm not a MW programmer and ignorant of gerrit.

In times past, the Commons File: page for a switch-translated file would show a "default" language option along with the explicit systemLanguages used. I don't see that behavior anymore.