In T250607#7620975, @SyntaxTerror wrote:

I reopened this task because the problem doesn't seem to be solved.

It still occurs on [[:File:Accumulated Cyclone Energy of North Atlantic hurricanes, OWID.svg]] that have this error message:
This file can not be translated with this tool because it contains unsupported SVG (nested tspan in #tspan1286) in the following text: CC BY

I have mixed feelings about this request.

Copying my comment at T5593:

I believe simple Unicode hieroglyphs already display on Windows browsers because Windows has a hieroglyph font.

In T26768#7484862, @Aklapper wrote:

No updates, otherwise they'd be mentioned here. (In general.)

That file is 652 kB, so it is a dupe of T270880 and T270999.

librsvg2.50 fails, so Gnome probably does not know about this bug.

I would decline this ticket. It asks for a mechanism that is not needed.

See T261192#7109006

In T261192#7108572, @Aklapper wrote:

librsvg 2.52.x will have a new --accept-language parameter, which will allow to specify the user's preferred languages by passing the HTTP Accept-Language header to librsvg: https://gitlab.gnome.org/GNOME/librsvg/-/issues/356 (Not sure if it will get backported to the 2.50.x series)

I agree with you.

Thanks for volunteering to do this topic and expanding the audience.

@JoKalliauer Thanks for showing that hyphens do not work, that 2.50 shows the default when there is no match, and that simply substituting an underscore for a hyphen does not solve the problem.

In T265549#7096973, @Dzahn wrote:

edit: I had pasted results but from 2.44.10 until I realized it is about anything > 2.44.10. so removed that again. nevermind me.

@Dzahn Thank you very much. The test results (now removed) suggest that hyphens are death. I do not know why the switch element's default clause "other" was not displayed. That suggests something else is awry. The SVG file validates.

The Commons file

• https://commons.wikimedia.org/w/index.php?title=File%3ASystemLanguage.svg

offers a quick and easy switch diagnostic because it displays the IETF language code.

In T261192#7093797, @JoKalliauer wrote:

librsvg would like to make it Wikimedia easy to have localized SVGs. (ref)

So the librsvg-developer asked to point Wikimedia People to librsvg#735 RFC: meta-issue for localized SVGs and and tell that comments there are welcome. The developer would like to know our opinion on how to do localized SVGs.

In T261192#7090977, @JoKalliauer wrote:

@Glrx: Sorry I do not understand language-interaction between MediaWiki and librsvg. Is it correct it is reported upstream at:

• https://gitlab.gnome.org/GNOME/librsvg/-/issues/131
• https://gitlab.gnome.org/GNOME/librsvg/-/issues/256

In T274052#7072464, @JoKalliauer wrote:

So for dummies: (default language) in Commons should not return systemLanguage="en", but the one without any systemLanguage.

Yes, that should be the meaning for (default language). It is the meaning that Arthur2e5 expected.

Here's my take.

I would decline this task.

In T40010#7055163, @Patrick87 wrote:

Incidentally we're just having a very similar discussion in the Inkscape project, and I believe I can clarify some things here:

Usage of system locale

Our current opinion is that usage of the system locale (for example $LANG variable of the form "de_DE.UTF-8" which holds a POSIX locale) is the most suitable thing to do for many applications:

• The SVG spec simply states "Evaluates to "true" if one of the language tags indicated by user preferences is a case-insensitive match"
• It does not say anything about how applications are supposed to enable the user to state their preferences.
• Implementing something similar to how browsers allows users to set Accept-Language to "arbitrary" values, certainly is *one* way to go but is likely to be overkill for most applications.
• Considering the system locale therefore is the most obvious way to derive the user's preferences.
• If for example the user prefers "es_ES" locale it's only reasonable to present them with "es-ES,es" (in that order).

If XML or SVG required strong type checking, then attributes such as id=" lg" or id="0lg" would raise exceptions Applications were sort of expected to validate XML input against a DTD and refuse to process bad input. That was a nice theory, but Java would take 6 seconds to validate an XML file, and that was just too high a penalty. So few applications complain about their input. I like it when one of my browsers throws an SVG syntax error.

With a specific locale string of LANG=es_ES.utf8 (which is a transliteration of es-ES to a locale string), librsvg displays systemLanguage="es" text. It should only display text that is at least es-ES. See T261192#7053643

In T261192#7053643, @Aklapper wrote:

In T261192#7046365, @Glrx wrote:

could you try executing librsvg locally

$:acko\> rpm -q librsvg2
librsvg2-2.50.3-1.fc33.x86_64
$:acko\> wget -q https://upload.wikimedia.org/wikipedia/commons/1/1e/Multilingual_SVG_example.svg
$:acko\> LANG=es_ES.utf8 rsvg-convert -w 512 -h 360 -o result.png  Multilingual_SVG_example.svg

and result.png is displayed with Spanish text.

@RazrFalcon This bug is very low priority; the old librsvg didn't do it right, so it will have almost no impact on WMF's SVG files.

Well, I was hoping for confirmation rather than another setback.

Generally, SVG 1.1 incorporated a subset of CSS 2. Therefore one should be able to use style attributes with url() syntax

• <circle cx="100" cy="100" r="20" style="fill:url('#idname')" />

If CSS url() syntax with quotation marks is allowed in style attributes, then it should be allowed in fill attributes.

@AntiCompositeNumber @JoKalliauer @RazrFalcon
From my Commons talk page ( https://commons.wikimedia.org/wiki/User_talk:Glrx#fill=%22url('#gfuser')%22_allowed ) on 28 Feb 2020:

@AntiCompositeNumber Thanks. A wonderful test.

@AntiCompositeNumber Thanks. Your systems are not setting LANGUAGE. I'm hoping that LANGUAGE being set on jewiki.net explains the behavior.

@Kghbln Thanks for running the tests.

@Kghbln I'm puzzled, too.

@AntiCompositeNumber Thanks.

@Aklapper or @Kghbln could you try executing librsvg locally on

• https://commons.wikimedia.org/wiki/File:Multilingual_SVG_example.svg
• https://upload.wikimedia.org/wikipedia/commons/1/1e/Multilingual_SVG_example.svg

We need to simulate what happens in rasterize with a $lang argument at

• https://doc.wikimedia.org/mediawiki-core/master/php/SvgHandler_8php_source.html#l00318

That is, set LANG environment variable to es and

• rsvg-convert -w 512 -h 360 -o result.png Multilingual_SVG_example.svg

and see if the result is in Spanish.

In T261192#7040784, @Kghbln wrote:

However it now appears to me that the issue is the contents of the svg and not MediaWiki?

No. The contents of the SVG files look OK. However, some multilingual SVG files display other languages while others do not. What is different about the working and non-working SVG files? That difference may expose the bug. You proposed that the difference was when the SVG file was uploaded. I looked for differences in the SVG files. It looks like you were right.

The failure happens for simple, non-hyphenated, IETF langtags such as de. Regions are not being set. The system processes some files correctly but fails with other files. That suggests that $LANG=de is not begin expanded into a more complex langtag such as de-DE and then failing to match the available systemLanguage attributes. That files uploaded before the upgrade work sounds like a red herring; all files should be getting the same processing (assuming the cache has been cleared or aged out - ?action=purge did not change the results).

The regex should test that trailing chararacters do not have a left brace or a right brace. A right brace may appear with CSS at-sign rules.

In T40010#7032186, @RazrFalcon wrote:

From what you've said, I just expect some CSS surprises.

The main limitation is that CSS3/"CSS4" would not work. And mainly because of processing and not parsing. Something like CSS variables is pretty hard to implement.

In T40010#7031903, @RazrFalcon wrote:

@Glrx

I suspect that most modern browsers have sufficient SVG support.

Sadly, it's not true. Or at least as long as "browsers" is Chrome. Firefox has a pretty bad textPath support, while Chrome is pretty bad with effects.
Firefox has issues even with clipPath and doesn't support baseline-shift (aka subscript/superscript) at all.
And no browser support enable-background, albeit it was deprecated in SVG2.
Overall, browsers are way better than librsvg, but you still need workarounds for them. And more importantly, browser specific one.

In T270836#6727649, @Aklapper wrote:

In T270836#6726228, @Verdy_p wrote:

According to the Gnome project, this has to go fgurther upstream into a bug of Pango.

Where does "the GNOME project" say so?

The issue is the Symbol font does not use Unicode code points. SVG agents look at the file and believe they are rendering a "q". If the agent happens to have the Symbol font, then it tells that font to render a "q"; the font's q just happens to look like a theta. Otherwise, the agent chooses a font with normal code points, and that font will paint a glyph that looks like a "q".

I returned BirdBeaksA.svg to the state where it had a nested tspan and ran SVG Translate.

It looks like a font issue to me, and I do not see any of the images as "wrong".

The new version of librsvg is not an acceptable renderer:

1. it does not take an IETF langtag (major)
2. it does not handle textPath (medium)

A one-character fix is needed.

So the style element tickles the bug.

Tried new version, and it worked.

The issue is much more complicated.

added style element with CRLFs; hope cache times out so it can be tested....

I uploaded the current Conic Sections.svg file but without its style element.

Uploaded test file File:SVG Translate Test - bad langtags.svg

Tried again. SVG Translate may be adding the sr_EC langtags, so I need another way to test this problem.

I (and presumably most of those seeking the font list) want the font list that is on the image scalers; that is, the list of fonts used for converting SVG files to PNG bitmaps. I'm not interested in font lists used in generating PDF files; PDF files can flow their text, so they do not have the same constraints as SVG 1.1 files (which has no flowed text). PDF files also allow subsequent font substitution; that is not possible after an SVG file has been converted to PNG. I could see some PDF users being particular about PDF CJK font choices, but that is not an immediate concern to me.

SVG Translate is still using the old file iwth sr_EC langtags.

I've purged Conic Sections.svg waited half a day, but SVG Translate is working on the old file (with sr_EC langtags).

File is > 256kB, so dupe of T270889. See also T270999.

conf/fc-list has useful information, and there have been several requests for updated information on MW fonts.

I removed the nested tspan, waited for the cache to clear overnight, clicked the SVG Translate link above, and SVG Translate found no text to translate.

The file has deeply nested tspan element: <text><tspan><tspan>Not to scale</tspan></tspan></text>.

$ strings were also reported in T231143.

The issue seems to have been fixed.

I would close report this as won't fix. Quite simply, SVG Translate requires Commons to serve files with the correct content-type header,
and Commons should serve SVG as image/svg+xml.

The same problem happened to that file again.

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