This problem is related to T6793 and T125073, but is separate because SVG parsers should not be using WMF language identifiers to interpret SVG IETF langtags.

The code should never be looking for underscores in a systemLanguage attribute.

I noticed that one user made several Kurdish translations in Arabic script that failed to show up. Looking at the SVG, the files had systemLanguage="ku_ARAB" instead of systemLanguage="ku-Arab" (capitalization is not important).

In T279241#6970866, @JoKalliauer wrote:

@Glrx I agree in general it would be poor method to not define dimensions, however it is valid example from the W3C-Test-suite, therefore MediaWiki should take the dimensions of librsvg. And it is imho not the creators fault, that is done on purpose in the official test-suite. If it is not supported it is a bug!

I would decline this request. The creator should always specify a size.

This basic problem is reported in T270889.

Thanks for the note about @ sections. I'd like to see support for (color) and not (color), but that is beyond SVG 1.1.

Thanks for running the test. Resvg has more support than I expected.

Thanks for trying it.

IIRC, resvg uses a simple CSS parser. Could you try rendering

@Aklapper thanks.

tests several SVG 1.1 (CSS 2) selectors.

First, the indicated SVG file, https://commons.wikimedia.org/wiki/File:Multilingual_SVG_example.svg has one switch element with several language clauses. Currently, it does not have a default final clause (i.e., a text element without a systemLanguage attribute). Consequently, if there is not an explicit langtag match, the switch element should not render any text. For the case of "(default language)", no text should be displayed.

I was faked out. Long ID names do work. The file probably has other issues (linearGradient, isolation:isolate, or mix-blend-mode:overlay).

Two proposals: increase the number of bytes read or shift multilingual testing to upload time (when the file is read anyway).

I would close this issue as won't fix.

My current understanding is that WMF already does some sanitization of SVG files.

Where to begin?

SVG language name handling is a mess on many levels.

This issue is the same as T36947. Font sizes in original Command_Pattern.svg were below 5px.

The tool should also give a reasonable error message for

possibly same issue as T221382 which identifies CSS selectors as a problem and points to a discrepancy in appConfig.translations

The message looks OK (but beware that a single text element may have dozens of nested tspan elements.

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

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?

Same cache problem as T231143 and T245356. See also T213126. T216207.

The nested tspan is not "erroneous code" but rather legitimate SVG that the tool does not support.

1. Failing to give a reasonable message for this case looks like a bug. The SVG file contains text. A reasonable user saw the text, wanted to translate that text, and fired up the translate tool. Then tool told him there is no text to translate. Why shouldn't the user take that as anything but a counterfactual. There's an elephant in the room and the tool is telling the user it does not see an elephant.

In T248252#6067865, @JoKalliauer wrote:

@Glrx Your descrition does imho not relate to his bug.

Not supporting text without tspans
https://tools.wmflabs.org/svgtranslate/File:T248252.svg
is a very serious bug!

I would close this ticket as Won't Fix.

Bug hunting is made tedious by the inability to flush the tool's cache. The file must be uploaded to Commons to run the tool, so I've been overwriting the original file and overwriting Test.svg to do tests. After two tests, I need to wait half a day. I did not want to upload a bunch of spurious files just to test ideas.

The original file has a two-line label 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.