I presume you are using --zoom

• https://gitlab.gnome.org/GNOME/librsvg/-/blob/main/rsvg-convert.rst

In T271000#8281697, @Samwilson wrote:

Testing notes

Thanks @dom_walden!

---

The first case does not have an xmlns: namespace declaration, but the second does.

The tool already adds the missing namespace if there isn't one.

I doubt that adding the namespace declaration changes the SVG file's elements. The document has already been parsed, so all the elements have had their namespace property set. SVG Translate is using a poor namespace model, so it will treat elements in the default namespace the same way as it would treat elements in the SVG namespace. SVG Translate uses getElementsByTagName() rather than getElementsByTagNameNS(). That poor model is also why the code separately checks for "svg:text". It should not be doing that. T316741: Allow svg namespace prefixes other than 'svg'

I'm looking at tests/Model/Svg/SvgFileTest.php, and I see test cases such as the two starting at line 645

'CSS too complex' => [
    'svg' => '<svg><style>#foo { stroke:1px; } .bar { color:pink; }</style><text>Foo</text></svg>',
    'message' => 'structure-error-css-too-complex',
    'params' => [0 => ''],
],
'tref' => [
    'svg' => '<svg xmlns="http://www.w3.org/2000/svg" version="1.0" xmlns:xlink="http://www.w3.org/1999/xlink">
        <defs><text id="tref-id">Lorem</text></defs>
        <text id="text"><tref xlink:href="#tref-id" /></text></svg>',
    'message' => 'structure-error-contains-tref',
    'params' => [0 => 'text'],
],

The first case does not have an xmlns: namespace declaration, but the second does.

In T316960#8227408, @Aklapper wrote:

Downloaded https://upload.wikimedia.org/wikipedia/commons/archive/b/bd/20220902193021%21Test.svg and replaced
<linearGradient id="lgback" gradientUnits="userSpaceOnUse" x1="0%" x2="100%" y1="0%" y2="0%">
with
<linearGradient id="lgback" gradientUnits="userSpaceOnUse">

The rectangle displays a gradient and no solid red locally in librsvg2-2.52.9. So I assume this got fixed at some point in upstream?

So the main page which a user sees at

• https://svgtranslate.toolforge.org/

Should add a hyper link with text such as "Add or improve the language translations in SVG Translate" that links to

• https://translatewiki.net/wiki/Translating:SVG_Translate

Given that this issue is generally about forging ahead when problems are discovered rather than particular improvements, I would close as Won't Fix.

I tried the DOM in Chromium, and it uses the modern definition for getElementsByTagName(). That is, the method will not find prefixed elements such as svg:text.

Consider relation to radialGradient in T193942 and T143086.

Issue is known at Gnome:

• https://gitlab.gnome.org/GNOME/librsvg/-/issues/169 Support "FillPaint" and "StrokePaint" as filter inputs

The issue is a bit more general.

My suspicion is the uncanonized langtags appear when makeTranslationReady() discovers the SVG is too complex to handle, returns false before canonizing zh-Hans, the return value is ignored, and SVG Translate forges ahead believing all the langtags have been fixed.

Repeating symbols every 360 degrees: T195654 T229174

T40010 reevaluate renderer...

Just guessing here... I do not know PHP or phpdoc.

I've been confused.

Uploaded file to Commons:
https://commons.wikimedia.org/wiki/File:SVG_Translate_test_namespace.svg

The code at 217 concerns wrapping #text nodes in tspan elements or giving up. In the problem file, the text is already wrapped. An svg:tspan element is not a #text node, so it should return false and give up on translating.

Consider a style element that has an @media rule:

• @media printer { text { fill: black; } }

That rule is presumably beyond the ad hoc parser, yet the original regex will succeed.

I suspect that T151735 introduced an ENTITY filter that rejects this text.

In T151735, ATTLIST could be used for script injection attacks by setting default attribute values.

Agree with JoKalliauer that paint-order is not SVG 1.1 Second Edition.

This issue has a 1-character fix.

In T265549#8147272, @Glrx wrote:

I do not know PHP or Python, but here are the changes needed to wiki configuration, SVGHandler.php, and Thumbor's svg.py.

• https://commons.wikimedia.org/wiki/User:Glrx#MediaWiki_upgrades

They are breaking changes. They need the Rust version of librsvg/rsvg-convert. If used with the old version of librsvg, I expect the new command line arg would cause an exception.

MediaWiki could be made compatible by having rsvg and rsvglang entries and testing for a "$lang" substring in the conversion string.

Thumbor is hardwired, so making it compatible with both versions would be more complicated. However, it would be good to allow Thumbor to use both rsvg-convert or resvg.

I do not know PHP or Python, but here are the changes needed to wiki configuration, SVGHandler.php, and Thumbor's svg.py.

In T40010#7996397, @TheDJ wrote:

I would like to note that this can all easily be implemented for non-wmf wikis. If someone just spent some time on adapting SVGHandler (or created an extension to override SVGHandler).

It just CANNOT easily go to WMF production any time soon because of security reviews, thumbor plugins which would have to be made, and the fact that the thumbor install itself is stuck in old systems that require updating all things for which there currently are no WMF budgets..

In T265549#8144450, @tstarling wrote:

In T40010#8144396, @Arthur2e5 wrote:

I am… getting impatient enough to ask: how hard is it to, really, just make our own statically-compiled rsvg-convert binary into a deb package and then deploy it? I mean:

• Rust already builds binaries with rust stuff statically linked in.
• rustup is available for getting us an installation of rust without going through debian, and without interfering with anything stored in a prefix. Only thing that could stop rustup is the glibc version, but even then we could just build it on a newer distro and do static-crt.
• System C deps for librsvg feel… reasonably conservative? I am not ruling out the possibility that it’s too new though.
• deb packages are easily assembled from a DESTDIR structure with dpkg-buildpackage.

We can get this as a stop-gap measure *while* we talk about what else to switch to. The surface for any security review would be minimal compared to anything that requires adding a layer of adaptation to the PHP side (hopefully we just do the language code change).

I think if you wrote a build script for that, and tested it on a stretch container, I would support deploying it.

The header comment for analyse() at line 394 suggests makeTranslationReady() has already been performed. It looks to me like that is called right after loading the file, and it will lowercase the langtags before analyse() is invoked.

SVG Translate finds translations by looking for text elements. It uses $this->document->getElementsByTagName('text') to find those elements.

Describe limitations of the tool.
T250330

I do not know PHP, but is the RegEx pattern starting at line 285 correct?

// Text strings like $1, $2 will cause problems later because
// self::replaceIndicesRecursive() will try to replace them
// with (non-existent) child nodes.
if (preg_match('/$[0-9]/', $text->textContent)) {
    $this->logFileProblem('File {file} has text with $-numbers');
    return false;
}

I'm thinking the $ should be escaped (that is '/\$[0-9]/').

@dom_walden Thanks for checking.

When I've run into this problem, I've used two workarounds.

Yes, I believe the problem is the 7207 x 7003 pixel image. If you are trying to display the image at full size, then you are asking for a 50 Mpixel image.

Same issue as T248136.

The file is in a format that SVG Translate does not know how to handle, but SVG Translate does not recognize that problem.

SVG Translate made a deliberate decision to only work on SVG files with a simple format. It will only handle simple lines of plain text. Handling subscripts, color shifts, and font styling changes are beyond its ability.

MediaWiki uses an old version of librsvg that only matches the first subtag (the zh in zh-hans). That is why zh-hans can "match" zh-hant and produce unexpected results. It is a well-known bug. T154237. Newer versions of librsvg have a different matching algorithm with different problems.

The text element in the description looks acceptable: one text with single-level tspan elements and no #text.

@Samwilson Thanks for working on this problem. It affects many users.

In T20936#235064, @TheDJ wrote:

See also: https://commons.wikimedia.org/w/index.php?title=File:Hairline_crack.svg

Copy text from T279874

Problem was traced to using CSS ID selectors.

Working case: the style element has trailing whitespace.

• https://svgtranslate.toolforge.org/File:Conic_Sections.svg

Failing case: the style element has no characters following the last close brace.

• https://svgtranslate.toolforge.org/File:SVG_Translate_Test_-_Conic_Sections.svg

It no longer displays $0 strings but rather claims "This file does not have any labels available for translation. Please pick another image."

This behavior is by design. CSS selectors that use identifiers complicate the translation.

In T271000#8022050, @TheresNoTime wrote:

Not sure if it's worth looking into more, but the --stylesheet option might let us add a font-face (something like FreeSans )?

SVG Translate should not output files with underscores.

T310230 is the same as this bug, so I will close it.

Thanks for adding more unit tests.

Ah! Looking at another patch, and the case insensitive match has been removed. Great.

In looking at SVGHandler.php around line 570, I see a separate issue

Here are five cases of a Serbian wiki referencing a multilingual SVG.

• https://sr.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B8%D0%BE%D0%B4%D0%BD%D0%B8_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC
• https://sr.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B8%D0%BE%D0%B4%D0%BD%D0%B8_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC?variant=sr-cyrl
• https://sr.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B8%D0%BE%D0%B4%D0%BD%D0%B8_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC?variant=sr-latn
• https://sr.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B8%D0%BE%D0%B4%D0%BD%D0%B8_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC?variant=sr-el
• https://sr.wikipedia.org/sr-el/%D0%9F%D0%B5%D1%80%D0%B8%D0%BE%D0%B4%D0%BD%D0%B8_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC

Possibly a dupe of T154237 and old librsvg bad matching.

This is a duplicate of other issues. T310230 (tlh matches 'tl') T154237

@Winston_Sung
This issue is about a wiki page displaying the SVG in the wiki language if that language is available in the SVG. That functionality works.

I would close this task as can't fix for won't fix.

I love this SvgHandler.php change

@TheDJ
ImagePage.php 1118-1131 seems a little off.

ImagePage.php has some IETF or SVG-specific code in it.

Here's what I understand.

I would like WMF to directly serve SVG files. Today's browsers offer reasonable SVG support. Letting the browser render the image also allows for dynamic interaction.

Just helped out another user with a failed Chinese translation:

For me, lang and uselang have different types. For example, they should not be treated as the same. They should not be tested for equality without converting one type to the other. Such conversions are not guaranteed; there may not be an isomorphic mapping.

In T309426#7991816, @TheDJ wrote:

Will be deployed next week

I believe this feature has been working for a couple of years now, so I would close this issue. The feature was needed to make SVG Translate work seamlessly.

I believe this issue has been fixed, but separate issues remain.

Instead of

text[@systemLanguage='$language']