Commons talk:SVG Translate tool

Blank character

Hi,
How can I "translate" a letter/word by a blank space ? For what I see, when you don't put anything in the translated box, the original language is keept on the image. - Simon Villeneuve 15:26, 20 August 2019 (UTC)[reply]

If a plain space does not work, then try entering a nonbreaking space, Unicode character U 00A0. On Windows, press and hold down the Alt key; on the numeric keypad type "0160", and then release the Alt key. Make sure your numeric keypad is enabled; I toggle mine with the NumLock key. See http://www.fileformat.info/info/unicode/char/00a0/index.htm Glrx (talk) 18:07, 20 August 2019 (UTC)[reply]

Thank you ! I sorted it out yesterday in the afternoon.
I'll finish my French translation of File:Antarctica.svg today. It was really hard mainly because the space between the characters aren't the same in English and French (as far as I can see in the preview window). - Simon Villeneuve 12:21, 21 August 2019 (UTC)[reply]

Problem with Antarctica

Hi again,
I have 2 questions about File:Antarctica.svg :
1- Why there's no option to show the map in French, as I can see, by example, for File:Asymmetric (PSF).svg ?
2- Why the file I have uploaded is lighter (3.93 Mio) than the precedent one (4.32 Mio) ? - Simon Villeneuve 14:45, 21 August 2019 (UTC)[reply]

@NKohli (WMF) and JoKalliauer:

The file page does not show a French (or other language) option due to the lazy scanning behavior of MediaWiki (MW). MW only looks at the first 0.25 or 0.50 Mio (I forget which) of an SVG file and then stops. If it does not find any systemLanguage attributes (the SVG attribute used for language selection), then it presumes the SVG file does not have any. The fix would be to have MW scan the whole file (not likely to happen anytime soon). The workaround is to put an invisible translated phrase at the beginning of the file so MW will find it. (The visible text may not be moved up because it must be painted on top of the 3.5 Mio that describe the geography.)
```
<switch visibility="hidden">
  <text systemLanguage="en">en</text>
  <text systemLanguage="fr">fr</text>
  <text>default</text>
</switch>
```
I believe the byte difference is just spaces and newlines. The original file is about 50,000 lines of indented XML. The output of SVG Translate is 300 lines with no indentation. So the difference could be losing about 10 bytes per line times 50k lines for 0.5 Mio.

It's a beautiful map, but it would be better if the SVG file were under 0.2 Mio. I'd like MW to directly serve small SVG files rather than converting them to PNG files.

Also, the map is yet another example that MW should support textPath. I've seen many such examples recently, and it is changing my view on how important text on a path is.

Glrx (talk) 16:32, 21 August 2019 (UTC)[reply]

Hi
Thanks for this precise and complete answer !
I have putted your "systemlanguage line" in the first line of the file, but it doesn't show the French option on Commons. I don't know why. Does it is already too far ? I've try to put it before, but it broke the file. - Simon Villeneuve 19:14, 21 August 2019 (UTC)[reply]

@Simon Villeneuve: You put the insertion at about the 3 MB mark, so it would not work. I do not want to have an edit collision with you, so let me know when you are not editing the file, and I will insert the code. Also, you should be aware that cache synchronization issues can arise. A displayed image may not be the most recent. Glrx (talk) 19:37, 21 August 2019 (UTC)[reply]

I went ahead an did the edit. If you've made changes, just overwrite mine and I will redo them. The language dropdown works. MB lines really slow my code editor down.... Glrx (talk) 20:02, 21 August 2019 (UTC)[reply]

Thank you for everything !
I still didnt find what you have done. The first line of character exceed the window and I can't find something with "systemLanguage" inside. - Simon Villeneuve 23:35, 21 August 2019 (UTC)[reply]

You may be viewing a cached version of the file. The first several lines of the file should be relatively short. Open the SVG file (https://upload.wikimedia.org/wikipedia/commons/c/c0/Antarctica.svg) in Chrome and then right click to view page source. Lines 20 to 24. Glrx (talk) 01:17, 22 August 2019 (UTC)[reply]

I corrected phab:T35245 (slightly misplaced text, see "Qeen Maud Mtns"), but not phab:T36947 (bad kering), but sadly I noticed that the french version got some minor textissues, which I tried to improve. — Johannes Kalliauer - Talk | Contributions 09:31, 25 August 2019 (UTC)[reply]

Sadly, the file has many text issues, and the translation tool some of those issues more difficult to sort out. Glrx (talk) 15:55, 25 August 2019 (UTC)[reply]

Could we use wikimarkup?

As Japanese applies double byte characters, it often sees characters overflow from the desired area. See File:ORES edit quality flow ca.svg, in which I translated and tried to break a text string with _br/_ but failed. If _small_ tag could be applied, or any font size adjuster enabled, more zh and ko, as well as CEE language users are encouraged to apply this handy app. Also, how do we revert edit, or delete translated svg like the one above? --Omotecho (talk) 09:11, 20 September 2019 (UTC)[reply]

Omotecho, I guess, the edits can be canceled as usual: any file page also has its respective history page. -- Ата ^(talk) 14:21, 13 October 2019 (UTC)[reply]

Problem with comparison_satellite_navigation_orbits.svg

Hello!

On File_talk:comparison_satellite_navigation_orbits.svg#Request_for_machine-readable_text_labels, @Scouten: found that your tool doesn't fully support this SVG – only "sea level" was offered for translation. Other labels were internationalised using switch and systemLanguage (English and Spanish are supported as of today), as can be seen by opening the file in a text editor.

If there's a bug in the SVG, can you please help me debug it, or otherwise, is it possible for your tool to be updated to support them?

Thanks,
cmɢʟee ⋅τaʟκ 00:13, 17 November 2019 (UTC)[reply]

@Cmglee:

The file is too complicated.

In general, the SVG translation tool understands simple text and tspan elements. It expects a switch element to contain only text elements. Wander outside of that model, and the tool will either give up or get confused.

The orbits file is far outside that simple model. Instead of text elements, the children of some switch elements are a (anchor) elements. Within those anchor elements, there are path elements.

To do a translation, one is asking that the anchor element's xlink:href attribute be translated (i.e., make it point to a different Wiki article) and that the path element be adjusted for the translated text. The tool is only meant to deal with simple text; it does not recognize links or graphic elements such as lines, paths, and borders.

If you want the translation tool to work, then only put text within switch elements. Used fixed leader lines.

The file is also semantically confused. The switch element selects content that is rendered; it does not select metadata. It is not for choosing different desc elements for the file. A desc element describes its immediate parent. The desc elements in the file are describing the (empty) switch element rather than the entire SVG file (i.e., the svg element). There is not a good way to do what you want. SVG 2.0 allows multiple title and desc elements; the lang attribute specifies the applicable langtag, but browsers may not support the attribute.

Glrx (talk) 18:39, 9 April 2020 (UTC)[reply]

Thank you very much for the detailed analysis, @Glrx: you're right about there being <a> elements in the <switch> and that URLs are not easily translatable. Is it possible to show a warning or error when a switch element contains non-text elements so that the user knows what the problem is? Thanks, too, for telling me about the desc elements; I didn't realise it pertains only to its parent. Cheers, cmɢʟee ⋅τaʟκ 00:06, 10 April 2020 (UTC)[reply]

@Cmglee: Although it is possible for a translation tool to emit warnings, the designers probably chose to remain quiet. A switch element may work fine without translation, so emitting a message that the switch element was skipped may confuse rather than help. Having the program try to analyze what the switch is doing to avoid extraneous warnings is too hard for what the tool was trying to be. When the program gets confused, it is usually obvious to the user that it is not working. In the larger view, effort would be better spent toward other improvements such as linebreaking.

BTW, I forgot to mention that the orbits image has a anchors with target="info" attributes. I do not believe that Is a legitimate value for that attribute.

Glrx (talk) 04:30, 10 April 2020 (UTC)[reply]

Thanks again, @Glrx: I made a test SVG and found that it seems to pick up the strings well, except for the <a> as you pointed out. A bigger issue is that it caches the file, and uploading a new SVG doesn't refresh it, despite shife-reloading the page or using another browser.

The target parameter is valid, and is useful to avoid the linked page loading over the SVG and losing its state, if the user can toggle different elements on and off. Cheers, cmɢʟee ⋅τaʟκ 16:37, 11 April 2020 (UTC)[reply]

@Cmglee:

Hi. I looked iIn your link http://stackoverflow.com/a/7017568, but I do not see it using or recommending target="info". Although target is a valid attribute, the value should be something like _blank or _top (which are values given in the link). Glrx (talk) 22:41, 17 April 2020 (UTC)[reply]

Hi @Glrx: you're right; that page claims that only the values starting with underscores are valid. However, I remembered from early days of HTML that one could instead name the window (now tab) without prefixing an underscore. http://stackoverflow.com/a/35703051 explains this in the context of HTML files, but I've found that it applies to SVG too. cmɢʟee ⋅τaʟκ 23:15, 17 April 2020 (UTC)[reply]

"This file does not have any labels available for translation" yet it does

Why does [1] says there's no text to translate? Is it a bug? The RedBurn (talk) 12:03, 31 December 2019 (UTC)[reply]

Indeed, it looks like it. The RedBurn (talk) 11:28, 3 January 2020 (UTC)[reply]

There's a task opened for it: The RedBurn (talk) 11:35, 3 January 2020 (UTC)[reply]

Tracked in Phabricator
Task T231143

@The RedBurn: I think it does not understand <text><tspan><tspan>...</tspan></tspan></text>, which is a pitty since inscape always converts flowRoots to two tspans. — Johannes Kalliauer - Talk | Contributions 22:55, 14 January 2020 (UTC)[reply]

It seems to be working now. However, the percentage labels and people icons are embedded bitmaps, which are not recommended for this purpose (it's fine for e.g. topological maps or renders to be annotated). This SVG and File:Air_pollution_exposure_in_cities_-_EU_limits_vs_WHO_guidelines_-_fr.svg should be redrawn. cmɢʟee ⋅τaʟκ 19:38, 11 April 2020 (UTC)[reply]

Done Redrawn as File:Air_pollution_exposure_in_cities_-_EU_limits_vs_WHO_guidelines.svg cmɢʟee ⋅τaʟκ 21:59, 11 April 2020 (UTC)[reply]

"This file does not have any labels available for translation"... but why?

Tracked in Phabricator
Task T231143

Hello, Itried to use the translation tool but I have to admit I am confused. I try to translate this file but I always get "This file does not have any labels available for translation" error. I modified my file, added tspan with x and y coordinates, removed break lines but nothing helps. Is there any way to understand what the issue may be exactly? Why, even if there are elements that are compliant, it still keeps saying that ther are no lables for translation? Thanks --Ikonact (talk) 08:18, 9 April 2020 (UTC)[reply]

Maybe the file is too big. When the translate tool was developed, all SVG files were supposed to be less than 10 MB. You've uploaded a larger file, so that limit is no longer in place, but perhaps the tool enforces a 10 MB limit. Glrx (talk) 19:50, 9 April 2020 (UTC)[reply]

@Ikonact: & @Glrx: After many many tests, I've identified the problem to be the existence of ID selectors (lines starting with hashes) in the stylesheet:

#layer-cities-label text {font-size:32px; font-weight:bold;}
#layer-towns-label text {font-size:24px; font-weight:bold;}
#layer-peaks-label text {font-size:12px; font-style: italic;}
#layer-river-names-label {font-size:8px; fill:#0978AB; font-family:'DejaVu Sans', sans-serif;}
#topo {fill:none;stroke:none; stroke-width:0.5;}

After I replaced them with class selectors, it works! I confirm that a simpler SVG triggers this bug.

@The RedBurn: & @JoKalliauer: This is a very serious bug as many SVGs have ID selector styles and I don't see a reason that the tool shouldn't support them. Can someone please help me raise a bug report? Additionally, the tool messes up the source code, making further changes very difficult; it's far from being properly tested, but e.g. my language extractor tries to preserve it as well as possible.

Thanks,
cmɢʟee ⋅τaʟκ 18:24, 11 April 2020 (UTC)[reply]

@NKohli (WMF):

I'd been doing similar tests on File:Herzlinie.svg and came to the same CSS id rule conclusion. See Phab:T231143 mentioned in the section above. Glrx (talk) 02:07, 12 April 2020 (UTC)[reply]

@Cmglee: & @Glrx: Thanks, it worked. I just removed the ID selectors in the stylesheet and there was no problem to use the svg translation tool. I will take this work around in consideration when generating my svg files. Thanks again. I see it was added to the FAQ as it is not obvious to come to this solution. --Ikonact (talk) 10:36, 12 April 2020 (UTC)[reply]

Thanks everyone. Glad to help! cmɢʟee ⋅τaʟκ 15:00, 12 April 2020 (UTC)[reply]

@Glrx and JoKalliauer: Pinging IFried (WMF) who owns this project now. Ilana, if you need help/context on it, feel free to reach out. This conversation related to T231143 to the best of my knowledge. I see Sam commented on it not too long ago. -- NKohli (WMF) (talk) 23:12, 15 April 2020 (UTC)[reply]

@Cmglee and The RedBurn: Strangely this ping in Special:Diff/410617850 didn't arive.

@Cmglee: According to https://phabricator.wikimedia.org/T231143#6050199 you can use : https://tools.wmflabs.org/svgtranslate-test/ with https://commons.wikimedia.beta.wmflabs.org/wiki/Main_Page for example https://tools.wmflabs.org/svgtranslate-test/File:2014_Ebola_Outbreak_Monthly_Cases_per_day.svg

Afaik Files here will be storred "forever" even they got deleted. (Please send me a message if I should delete them, maybe now or maybe after resolving this bug.)

Only my personal opinion: (I know internal-CSS-style has some advantages.) I personally completly avoid CSS, since it leads more often to rendering bugs (than inline-style), this CSS-feature ist not supported by any svg-optimizers (not by scour, not by svgcleaner, not by svgo). I find it confusing that one element can contain a xml-atribute a inline-style and in internal-style, and they have different priorities, therfore changing inline-style to xml-attribute changes rendering (if interal-CCS-style exists).

I think on Commons:SVG_Translate_tool#Q:_Why_do_I_see_the_message_This_file_does_not_have_any_labels_available_for_translation? there are very serous bugs. (Currently only a very specific pattern is supported, therefore I guess more than one third of Commons-svg-images (that should be supported) are not supported, therefore I mostly use old texteditor by hand to generate multilang-svgs. Imho the supported patterns should be raised to >95% (=19 out of 20files).)

— Johannes Kalliauer - Talk | Contributions 20:29, 16 April 2020 (UTC)[reply]

very serious Bugs

@Cmglee: I added examples to Commons:SVG_Translate_tool#Q:_Why_do_I_see_the_message_This_file_does_not_have_any_labels_available_for_translation?, maybe the assumed reason is wrong, but the problem imho persist. I consider to not support ‎<text>...‎</text> without ‎<tspan>...‎</tspan> as a very serious bug, since it is a minimal simplest possible pattern.

In my opinion the SVG Translate tool is in a alpha-stage, which still can be helpfull. Maybe I suggested a too large project (I only wanted to fix the download-function of Jarry's tool).

To be honest: As far as I remember the old tool by @Jarry1250: did better (but imho Jearry's Tool did not contain such a beautiful interface, but who cares about the inteface if the tool is not working). @IFried (WMF): Maybe you should change the backend to Jarry1250's tool. (Maybe even offer both backends.)

— Johannes Kalliauer - Talk | Contributions 21:18, 16 April 2020 (UTC)[reply]

Hi everyone, I agree that it must support bare <text>...</text>.

I wonder if trying to make a multilingual SVG from a monolingual one may be overly ambitious. As far as I remember, Jarry's tool just found all strings that are not in < and >, comments and style sheets, and offered them for translation, changes which are simply substituted in and the new file offered for download. Barring updating the file encoding (possibly causing mojibake) and generating false positives, it seems simple enough. Trying to intelligently detect visual text strings seems fraught with edge cases, and still doesn't fix new strings which are too long or strings converted into paths. (I think the preview window is the best thing about the new tool, though).

Regardless, is there anything I can do to help? I've experience in programming, but not a WMF tool. To not clutter up this page, please message me on user_talk:cmglee if so. Cheers, cmɢʟee ⋅τaʟκ 01:39, 18 April 2020 (UTC)[reply]

P.S. IMO, one of the most serious bugs now is that it doesn't purge its cache, so one can't run the tool again right after updating the file.

Svgtranslated files with no language extension and/or seemingly nonexistant

Hi there, thanks for your work with this, I find the tool can be really helpful, still I found some strange outputs. I translated this Czechoslovakia map to Basque a pair of days ago. All went find during translation. However, I was expecting a file with a eu.svg extension (for Basque) at the output, still I got the same ca.svg file, but with a Basque version in it.

As I found out, under the "Open in MediaViewer" option just under the map image, it showed other language options, meaning that when I take the ca.svg map into the EUWP it shows the Basque language version automatically. I could confirm that here. Still the Basque language option does not show in the "Other versions" sections below, which makes the file ghostly and cannot be identified by category (like svg files in Basque). Is that related to the chache purging issues talked about above?

Today I translated this English language default file (no language extension) into Basque with svgtranslate. While the translation went smoothly, the original EN file has been updated into the Basque version, so no language extension added, but this time there was not either an option under "Open in MediaViewer" to show the map in Basque (the main map image remains in English). When I posted the file in a Basque WP article, it did not even show in Basque, see again here.

How can I create a language extension automatically, and/or make the Basque version file visible ("Other versions") along with other languages? Best regards Iñaki LL (talk) 12:47, 25 April 2020 (UTC)[reply]

@Iñaki LL:

SVG Translate puts the translation in the same file; it does not create a separate file.

Other versions is done with a wiki template file. You must click the edit button and add the information. I've done that for the template.

The Category listing requires adding the category inclusion on the SVG description page.

The 1930s map is too big and probably has fallen victim to MediaWiki only scanning the front of the file. If it does not find a translation in the first few hundred kilobytes, it decides there are no translations.

You can use SVG Translate to add translations to most files. Making the file "visible" requires additional manual edits.

Glrx (talk) 04:29, 28 April 2020 (UTC)[reply]

Thanks Glrx for checking my post and examples. Ok, so should I download the default file and then upload with a language tag in the name (_eu.svg, or _en.svg, or...), right? (However, will not the system reject the upload initially, since it may detect it is the same map as the default language map?) For the category listing, do you mean adding the "Basque language svg" category manually into the ca language tag file? Regards Iñaki LL (talk) 14:44, 28 April 2020 (UTC)[reply]

@Iñaki LL: No, you should not upload the file to name_eu.svg. That file would not display the desired language either. The file needs a dummy translation at the top of the file. The SVG Translate tool should install that dummy, but it does not. Glrx (talk) 00:54, 1 May 2020 (UTC)[reply]

Understood. Thanks Iñaki LL (talk) 09:53, 1 May 2020 (UTC)[reply]

Renaming element id prevents translation on use

Hi tool developers,

I found an issue with translating a text element which is used. In the example in the thumbnail, I originally had

<text id="lg" transform="translate(19800,-155)" dy="0.7ex"><tspan class="big">Lost Generation</tspan><tspan x="0" dy="40">&#8727;1883&#8211;1900</tspan></text>
...
<use xlink:href="#lg"/>

When @Aniol: added Catalan, the tool changed it to

<switch><text id="lg-ca" transform="translate(19800,-155)" dy="0.7ex" systemLanguage="ca"><tspan class="big" id="trsvg17-ca">Generació perduda</tspan><tspan x="0" dy="40" id="trsvg18-ca">∗1883–1900</tspan></text><text id="lg" transform="translate(19800,-155)" dy="0.7ex"><tspan class="big" id="trsvg17">Lost Generation</tspan><tspan x="0" dy="40" id="trsvg18">∗1883–1900</tspan></text></switch>

As the translation's id is renamed lg-ca, the use element picks up the original with id="lg".

I'm unsure what a good solution is; if the Catalan version isn't renamed (also has id="lg"), there is a conflict of two elements with the same id. A remedy is to also switch the use:

<switch><use xlink:href="#lg-ca" systemLanguage="ca"/><use xlink:href="#lg"/></switch>

but it would be difficult to tell which use elements in the file must be switched, especially if it's nested deeper:

<switch><use id="nested-ca" xlink:href="#lg-ca" systemLanguage="ca"/><use id="nested" xlink:href="#lg"/></switch>
...
<use xlink:href="#nested"/>

I suppose the SVG creator could do

<g id="lg"><text transform="translate(19800,-155)" dy="0.7ex"><tspan class="big">Lost Generation</tspan><tspan x="0" dy="40">&#8727;1883&#8211;1900</tspan></text></g>
...
<use xlink:href="#lg"/>

but that looks clumsy and involves going back to fix many files with this pattern. Does anyone have a solution?

Thanks,
cmɢʟee ⋅τaʟκ 00:56, 17 July 2020 (UTC)[reply]

In general, SVG Translate should not change id attributes. If the element has an id, then the tool should use that name. If an element needs an id attribute, then the tool may generate a new ncname; it must check that the name is not already in use.

Some cases are hard. If the tool changes a text element into a switch element, then moving the id attribute to the new parent may be in order. It may break some CSS, but I'm not sure what can be done without an SVG DOM.

Glrx (talk) 03:34, 7 March 2021 (UTC)[reply]

Strange behavior of the tool

I could not find any information how to tell the tool how I want things done. I saw that it creates for each text element a useless and superfluous tspan bracket, which gives no sense at all. More bad, it generates also for each text element two id labels, which are also completely useless and superfluous.

I know that Wikimedia owns unlimited storage capacities, no need to keep files at a reasonable size; but bloating SVG code has more disadvantages: at least it becomes more difficult to read when treated with a text editor. I try to make slim files with efficient SVG code, without useless definitions.

When I tried the tool it made of a simple line

<text systemLanguage="de,en,es,pt">Mineral</text>

the following 4 lines

<text systemLanguage="de" id="trsvg23"><tspan id="trsvg10">Mineral</tspan></text>
<text systemLanguage="en" id="trsvg23"><tspan id="trsvg10">Mineral</tspan></text>
<text systemLanguage="es" id="trsvg23"><tspan id="trsvg10">Mineral</tspan></text>
<text systemLanguage="pt" id="trsvg23"><tspan id="trsvg10">Mineral</tspan></text>

bloating 49 bytes to 332; for the librsvg it is exactly the same, just with a lot of filler.

For the W3C validator the tool's changes will result in many errors, because each id must be unique.

I suggest to stop that nonsense, or at least to allow parametrizing whether one wants to get that stuff, or not. Otherwise we will need another tool, to clean the code afterwards. -- sarang♥사랑 16:00, 20 July 2020 (UTC)[reply]

In your example, I would instead get

<text systemLanguage="de" id="trsvg23-de"><tspan id="trsvg10-de">Mineral</tspan></text>
<text systemLanguage="en" id="trsvg23-en"><tspan id="trsvg10-en">Mineral</tspan></text>
<text systemLanguage="es" id="trsvg23-es"><tspan id="trsvg10-es">Mineral</tspan></text>
<text systemLanguage="pt" id="trsvg23-pt"><tspan id="trsvg10-pt">Mineral</tspan></text>

but that leads to the previous issue. Cheers, cmɢʟee ⋅τaʟκ 23:07, 20 July 2020 (UTC)[reply]

Ok, this will generate unique labels (has the tool been changed since my test?), but how about the parametrizing? IMHO are graphics drawn with a text editor in most cases very easy to read and to maintain, with no need to use that tool. -- sarang♥사랑 19:22, 21 July 2020 (UTC)[reply]

I can accept that most editors are not willing or able to edit SVG code directly, just as I wouldn't edit Office documents' XML. I'm unsure what benefit there is to add the ids. Could a tool developer please comment? Thanks, cmɢʟee ⋅τaʟκ 23:16, 24 July 2020 (UTC)[reply]

@NKohli (WMF): maybe you know who to ask? — Johannes Kalliauer - Talk | Contributions 17:16, 27 July 2020 (UTC)[reply]

It's been a while since I was in touch with this tool, unfortunately. Pinging IFried (WMF) and SWilson (WMF) in case they can help. -- NKohli (WMF) (talk) 22:36, 31 July 2020 (UTC)[reply]

do not overwrite files in Category:SVG simplification by text switch

Please do not upload a version translated with the buggy SVG Translate without first cleaning it from all the garbage the tool adds!

This file is saved in human-editable plain text format. Any editing of the image or creation of any derivative work should be performed using a text editor. Please do not upload edits saved or exported with Inkscape or similar vector graphics editors, as well as with automated tools such as SVG Translate.

Please do not upload a version translated with the buggy SVG Translate without first cleaning it from all the garbage the tool adds!

Files in Category:SVG simplification by text switch should not be overwritten by Commons:SVG Translate tool, see Commons:Overwriting existing files#Controversial or contested changes. — Johannes Kalliauer - Talk | Contributions 22:57, 6 March 2021 (UTC)[reply]

Instead of checking for such categories, the tool should check that all the switch, text, and tspan elements are in a normal form. If anything is amiss, then it should refuse to translate.

Normal form for a tspan element is

the content is a single #text node. That is, there are no tspan element children. SVG Translate does not handle font shifts, font style shifts (e.g., bold or italic or underline), interior color changes, subscripts, or superscripts.

Normal form for a text element is

the content is one #text node (i.e., the text to translate), or
the content is only normal tspan elements with no #text nodes. (This requirement may be relaxed to #text nodes only containing whitespace and xml:space is not "preserve".) Each tspan after the first starts a new text chunk (i.e., has an x or a y attribute).

Normal form for a switch is all child elements are normal text elements and each of those text elements has the same number of normal tspan elements. (The requirement for the same number of tspan elements may be relaxed if the tool can handle a differing number of tspan elements. In the past, the tool has deleted unmatched tspan elements.

Normal form also requires that any element with a systemLanguage attribute must be a text element and its parent element must be a switch element.

Normal form implies that switch elements do not have descendant switch elements.

The normal form requirement is to avoid processing complicated switch elements. Some SVG files on Commons have mixed children in a switch. For example, most of the children might be text elements, but some children might be g elements that not only display text, but also add geometric lines.

Glrx (talk) 04:08, 7 March 2021 (UTC)[reply]

@JoKalliauer and Glrx: I restored a lighter suggestion of SVG Translate Tool within the default Translate template, but we need a more balanced solutions. Do we have something at hand ? Should we request emergency WMF's developers ? Hiding the SVG Translate Tool is not satisfying. We could turn off its citation on page tagged as using switch. (See Template_talk:Translate#Removal_of_toolforge:svgtranslate_from_the_template). Yug (talk) 22:14, 22 March 2021 (UTC)[reply]

@Yug:

I do not know how to respond because this is a difficult issue.

In general, we want to see SVG diagrams translated into other languages.

One translation method is to read the original SVG into a graphics editor, translate the text labels, and then write the edited file with the original filename suffixed with an IETF language tag. That is the typical way that SVG (and even PNG) files are translated. Many users can translate words and phrases, but they do not know how to use graphics editing applications.

Another translation method is to do the same operation as the graphics editor, but to do it with a text editor. Using a text editor requires some understanding of XML, SVG, and/or pattern matching. That ability is also beyond many Commons users.

Those methods also have the disadvantage of creating independent files. Licensing information is often garbled or lost. Improving the illustration in one of the language versions does not automatically improve the related files. There are about 40 language versions of File:Bicycle diagram-en.svg; there are both subtle improvements and dramatic changes in these versions.

SVG has the switch element that can be used to make an SVG file multilingual. That was the easiest route for some Commons users to introduce multilingual SVG files. A few changes to the code in MW make $lang work.

The primary advantage of switch is ordinary editors could use the original version of SVG Translate to add translations to SVG files. The original SVG Translate, like the current program, works with simple SVG files but often tries to edit files it does not understand.

More troubling is that many graphic editing applications probably do not support the switch element. Inkscape is probably the only application that has a chance of working on a multilingual file. Many times a well meaning editor has used a graphics editor on an SVG file with switch translations, changed the labels to add a new language, and then overwritten the original file. The result is all the other translations are lost. That also means translating a file with switch may prevent the original author from making subsequent changes without eliminating the added translations. There are many graphic artists that can draw fabulous images, but the tools that they use do not allow them to handle translations.

The templates above show that several creators are frustrated when blunt tools are applied to organized files. Using Inkscape on a file can introduce a lot of unstructured style attributes. SVG Translate can introduce a lot of extraneous id attributes, delete some tspan elements, and get confused by font shifts and subscripts. It is understandable that some creators do not want certain tools applied to their work.

Technically, switch translations are not a great solution.

In particular, a good solution would allow any one to use their favorite graphics editing application on any Commons SVG file.

For MediaWiki, there are additional problems. A balanced solution needs a lot of planning. MW needs to figure out what it wants to do with SVG files; current SVG limitations (e.g., no support of textPath) are significant limitations for any method of translation. SVG Translate has problems and should do better, but there are more fundamental issues. Although there are better solutions, they are not at hand. Emergency use of WMF developers gains nothing without clear plans. I want WMF to provide better SVG support, but I do not see that happening anytime soon.

Glrx (talk) 03:51, 23 March 2021 (UTC)[reply]

I cleaned up several files, and I also used the SVG-translate-tool, so I understand both sides. I mentioned it here, to try to come to a solution that works for everyone. Currently the template is often ignored, which makes the template imho a bit useless. Currently both sides imho live their own way. I see too many WMF-bugs, not sure where to first apply the WMF-developers.

I currently don't see any solution to solve the issue, however users of translate-tool should know it is an easy solution, but it is controversial, because it ruins the structure of the svg. (So inform the users that this tool sometimes not desired.)

I personally think it is better to use svg-translate-tool, than to not translate or to upload as a new file.

@Sarang: Maybe you want to comment on that. — Johannes Kalliauer - Talk | Contributions 09:41, 23 March 2021 (UTC)[reply]

Thank you Johannes - yes I want to comment it. First, I am preferring the translation of SVG files with one multilang version, i.e. the switch method. This can be very easy when no problems occur, e.g. with the space when texts become much longer in some languages. Independent if the creation method, whether it is drawn by a tool or 'by hand', it will be a good idea to have all texts prior to the drawing, which offers the possibility to edit & translate only the text by hand - without a tool. IMHO even rather unexperienced users will then be able to add translations.

Keep the text leading will not be always possible, esp. when text is written over drawn areas; if that is the case the text may be at the end of the code, which will give problems with very large files, and maybe a bit more difficult for unexperienced users.

I would like to use the toolforge translate tool - when it would not generate such a lot of garbage. It would be easy to clean the code after translation, I could do that with very simple REGEX instructions, but I have not enough knowledge with JS to make the necessary frame for such a helper tool. Maybe somebody can cooperate with me? The other possibility would be that e.g. a parameter of the tool allows to suppress the generation of the useless IDs and other unneeded cruft. Of course, a tool will never be able to recognize synergies, as an experienced human programmer can, but as long the tool-generated code remains readable I won't blame the tool.

IMHO the tool bears the advantage that it offers many users the possibility to add translations, and when it is also possible at least to clean the code after some additional translations, I won't fight against it. But currently the tool is bloating and complicating the code to a mere unradability, and the cleaning is too difficult. -- sarang♥사랑 10:36, 23 March 2021 (UTC)[reply]

Hello Sarang, Glrx, JoKalliauer, thanks for this brainstorming.

Testing and documenting the rightful regex would definitively help : it takes out one bottleneck. Maybe creating a subpage /Wishlist with minimal problem definition, some xml code samples before and after, together with the regex which did the clean up. It can write down a clear workable fix for this specific issue. For the HTML-JS UI, it can be delegated later, and we will have more weight to call for help if the issue is well defined and the regex is already there.

I'am definitively of the opinion we should fix the tool. The tool is great since it gives everyone the ability to translate graphics. It's literally the wiki spirit. We have to push this tool to the finishing line. 09:35, 24 March 2021 (UTC) — Preceding unsigned comment added by Yug (talk • contribs) 09:35, 24 March 2021 (UTC) (UTC)[reply]

To show what is being talked about

An example to show the difference is Astronomical unit.svg; with the three languages en, de, sl it had a file size of 2072 bytes.

After usage of the translate tool After cleaning the code

Using SVG Translate Tool and adding th as the 4th language, the size increased to 3639 bytes and the text switch coding part looked this way: The text switch coding part after cleaning (with some REGEX instructions) looks this way:

<g font-family="DejaVu Sans" font-weight="bold">
<g font-size="16">
<switch transform="translate(460,300)">
<text systemLanguage="en" id="trsvg25"><tspan id="trsvg1">Earth</tspan></text>
<text systemLanguage="de" id="trsvg26"><tspan id="trsvg2">Erde</tspan></text>
<text systemLanguage="sl" id="trsvg27"><tspan id="trsvg3">Zemlja</tspan></text>
<text id="trsvg28-th" systemLanguage="th"><tspan id="trsvg4-th">โลก</tspan></text><text id="trsvg28"><tspan id="trsvg4">Earth</tspan></text></switch>
<switch transform="translate(300,360)">
<text systemLanguage="en" id="trsvg29"><tspan id="trsvg5">Mercury</tspan></text>
<text systemLanguage="de" id="trsvg30"><tspan id="trsvg6">Merkur</tspan></text>
<text systemLanguage="sl" id="trsvg31"><tspan id="trsvg7">Merkur</tspan></text>
<text id="trsvg32-th" systemLanguage="th"><tspan id="trsvg8-th">ดาวพุธ</tspan></text><text id="trsvg32"><tspan id="trsvg8">Mercury</tspan></text></switch>
<switch transform="translate(155,270)">
<text systemLanguage="en" id="trsvg33"><tspan id="trsvg9">Venus</tspan></text>
<text systemLanguage="de" id="trsvg34"><tspan id="trsvg10">Venus</tspan></text>
<text systemLanguage="sl" id="trsvg35"><tspan id="trsvg11">Venera</tspan></text>
<text id="trsvg36-th" systemLanguage="th"><tspan id="trsvg12-th">ดาวศุกร์</tspan></text><text id="trsvg36"><tspan id="trsvg12">Venus</tspan></text></switch>
<g text-anchor="end">
<switch transform="translate(270,300)">
<text systemLanguage="en" id="trsvg37"><tspan id="trsvg13">Sun</tspan></text>
<text systemLanguage="de" id="trsvg38"><tspan id="trsvg14">Sonne</tspan></text>
<text systemLanguage="sl" id="trsvg39"><tspan id="trsvg15">Sonce</tspan></text>
<text id="trsvg40-th" systemLanguage="th"><tspan id="trsvg16-th">ดวงอาทิตย์</tspan></text><text id="trsvg40"><tspan id="trsvg16">Sun</tspan></text></switch>
<switch transform="translate(427,76)">
<text systemLanguage="en" id="trsvg41"><tspan id="trsvg17">Mars</tspan></text>
<text systemLanguage="de" id="trsvg42"><tspan id="trsvg18">Mars</tspan></text>
<text systemLanguage="sl" id="trsvg43"><tspan id="trsvg19">Mars</tspan></text>
<text id="trsvg44-th" systemLanguage="th"><tspan id="trsvg20-th">ดาวอังคาร</tspan></text><text id="trsvg44"><tspan id="trsvg20">Mars</tspan></text></switch>
</g>
<g font-size="27" text-anchor="middle">
<switch transform="translate(365,280)">
<text systemLanguage="en" id="trsvg45"><tspan id="trsvg21">~1 au</tspan></text>
<text systemLanguage="de" id="trsvg46"><tspan id="trsvg22">~1 AE</tspan></text>
<text systemLanguage="sl" id="trsvg47"><tspan id="trsvg23">~1 a.e.</tspan></text>
<text id="trsvg48-th" systemLanguage="th"><tspan id="trsvg24-th">~1 au</tspan></text><text id="trsvg48"><tspan id="trsvg24">~1 au</tspan></text></switch>
</g>
</g>

The useless size enlarging is not the problem - but the code became now very unreadable and much more difficult to edit.

<g font-family="DejaVu Sans" font-weight="bold">
<g font-size="16">
<switch transform="translate(460,300)">
<text systemLanguage="en">Earth</text>
<text systemLanguage="de">Erde</text>
<text systemLanguage="sl">Zemlja</text>
<text systemLanguage="th">โลก</text>
<text>Earth</text></switch>
<switch transform="translate(300,360)">
<text systemLanguage="en">Mercury</text>
<text systemLanguage="de">Merkur</text>
<text systemLanguage="sl">Merkur</text>
<text systemLanguage="th">ดาวพุธ</text>
<text>Mercury</text></switch>
<switch transform="translate(155,270)">
<text systemLanguage="en">Venus</text>
<text systemLanguage="de">Venus</text>
<text systemLanguage="sl">Venera</text>
<text systemLanguage="th">ดาวศุกร์</text>
<text>Venus</text></switch>
<g text-anchor="end">
<switch transform="translate(270,300)">
<text systemLanguage="en">Sun</text>
<text systemLanguage="de">Sonne</text>
<text systemLanguage="sl">Sonce</text>
<text systemLanguage="th">ดวงอาทิตย์</text>
<text>Sun</text></switch>
<switch transform="translate(427,76)">
<text systemLanguage="en">Mars</text>
<text systemLanguage="de">Mars</text>
<text systemLanguage="sl">Mars</text>
<text systemLanguage="th">ดาวอังคาร</text>
<text>Mars</text></switch>
</g>
<g font-size="27" text-anchor="middle">
<switch transform="translate(365,280)">
<text systemLanguage="en">~1 au</text>
<text systemLanguage="de">~1 AE</text>
<text systemLanguage="sl">~1 a.e.</text>
<text systemLanguage="th">~1 au</text>
<text>~1 au</text></switch>
</g>
</g>

Note: Because the default language is English, it is not necessary to repeat the English text for the default.

IMHO it will now be not too difficult to add more languages using a text editor. -- sarang♥사랑 09:40, 24 March 2021 (UTC)[reply]

I see . It's possible those id="trsvg\d " are created so to pair the UI field with the svg ids. But they could be removed before saving, yes. The good news is, SVG translate likely already has built-in code to manipulate these ids. Yug (talk) 11:03, 24 March 2021 (UTC)[reply]

I would recommend 3 successive regex. This JS is demoed here :

Before

JS Regex match

JS Regex replacement

After

</text><text

/</text><text/g

'</text>\n<text'

</text>
<text

<tspan id="trsvg20-th">ดาวอังคาร</tspan>

/<tspan id=\"trsvg\d (-[a-z]{2})*\">(. )<\/tspan>/g

'$2'

ดาวอังคาร

id="trsvg20-th"

/id=\"trsvg\d (-[a-z]{2})*\"/g

''

(nothing)

IMPORTANT: this is only a demo. This regex approach is very risky since it could fail with special characters or rare languages. Manipulating XML nodes would be more solid.

Note: While this answer Sarang's concern, I haven't closely reviewed other concerns. Yug (talk) 14:05, 24 March 2021 (UTC)[reply]

@Yug: I see the (. ) dangerous, I would use something like ([]\[[:alnum:]\$\^\\\_\{\}= #\,\"\.\’\&\;\/Επιβάτες¸\°\'\"\@\:\ −-]*) or ([^<]*)

What happens with: (I think svg-translate-tool cannot create such text, but might exist other-where)

<tspan id="trsvg20-th"> abc <tspan font-weight="bold"> bold </tspan> xyz </tspan> ABC <tspan dy="10"> 2 </tspan>

it should get: (the first and the last tspan should be kept)

abc <tspan font-weight="bold"> bold </tspan> xyz  ABC <tspan dy="10"> 2 </tspan>

— Johannes Kalliauer - Talk | Contributions 18:45, 24 March 2021 (UTC)[reply]

@Yug and JoKalliauer: REGEX treatment is just a help to avoid the need for tedious editing of every single occurrence; of course such automated changes are subject to a meticulous check! -- sarang♥사랑 08:42, 25 March 2021 (UTC)[reply]

@Yug, Sarang, and JoKalliauer: I have a few comments.

Although the extraneous id attributes add clutter to the SVG and make it less readable, they do not have a significant impact on network bandwidth. Even though the attributes use a lot of characters, those attributes do not add a lot of information to the file, and therefore they are easily compressed. When the WMF servers transfer an SVG file, they transfer a compressed copy. XML is verbose, but much of XML's verbosity is easily compressed. Although adding one more language may increase the file size by 1.5 kB, the size transferred over the network may only increase by 0.3 kB.

Size of File:Astronomical unit.svg
Version	Uncompressed	Compressed	Comments
2020-10-11	2.1 kB	1.3 kB	indented
2020-12-05	3.6 kB	1.6 kB	indented with `id` attributes added by SVG Translate
2021-03-24	2.1 kB	1.4 kB	not indented and cleaned

Although reducing file size is a worthy goal, that reduction may not be as dramatic as one might think. I've asked WMF how important network bandwidth is to them, but I have not received a response.

The file size issue is further complicated by WMF serving PNG files rather than serving the underlying SVG. Right now, WMF does not care much about SVG file size because those files are usually just transferred on its server IO channels or internal networks; the PNG files are the ones that consume external network bandwidth. Even if pointless attributes increased an SVG file by 5 MB, that increase would not affect the size of the outgoing PNG. It would only consume more diskspace (which is cheap), more internal bandwidth, more RAM, and more CPU. None of those resources seem to be crippling to WMF right now.

I am all for reducing clutter in SVG files. Pointless attributes serve no purpose. I often edit SVG files with a text editor, so I like to see indented XML rather than a single line or all lines starting at the the left margin. Spaces compress really well, so they have minimal cost. Indentation is a minor personal preference, I realize that one cannot indent XML without running afoul of xml:space="preserve", and I do not like the indenting games that Inkscape plays.

Although a regex can be powerful, it is not a good method of manipulating SVG. It is too easy for a regex to capture something that we did not intend (e.g., characters within a #text node) or to miss something we wanted it to catch (e.g. <tspan> and <svg:tspan>). It is far better to use XML's Document Object Model (DOM) and walk the document tree rather than look for particular text strings. Commons:Commons SVG Checker uses the DOM, and SVG Translate uses the DOM. Programs that use the DOM can easily consult the document tree for context: it is OK to delete #text nodes within a switch, but #text nodes within text, tspan, and textPath elements require more scrutiny. Blindly removing id attributes can have consequences. Some CSS may refer to a particular tspan element. I've seen switch translations that instead of copying a text element, they use that text element.

Glrx (talk) 18:51, 24 March 2021 (UTC)[reply]

Hi @Glrx: , your very interesting mentioning goes far beyond of translating problems, it is of general interest and should serve others at a place where it can be found. Some thoughts you may find at User talk:Glrx#SVG matters.

Depending the above discussions, the code shown above as "After cleaning the code" has IMHO the advantage that every user with medium edit skills will be able to add more languages simply with a text editor, no need to know about SVG, rules and principles of operation - just easy copying the scheme which is clearly recognizeable. Seeing all the other translated languages may offer the possibility for simplify matters (as e.g. Merkur the same in de and sl, Venus the same in en and de, Mars the same in three languges: systemLanguage="en,de,sl") which is kept hidden in a black box when the tool is used. -- sarang♥사랑 07:00, 25 March 2021 (UTC)[reply]

@Sarang: MW is multilingual, so translating diagrams is important to the project. Unfortunately, different translation methods impact other SVG tools. On my list of things to do are some round trip tests on some editors: import an SVG file, make an edit, and export an SVG file.

Ideally, SVG Translate should be easier to use than a text editor. Of course, it has problems. SVG Translate will work on some Inkscape files; the input SVG need be neither pretty nor compact.

I do not know how often SVG Translate is used, but when Covid broke last year, SVG Translate was used on several diagrams.

Although SVG 1.0 allowed systemLanguage="en,de,sl", very few user agents did it correctly until about two years ago. IIRC, Chrome, Edge, and Firefox now work; I do not know if Safari does it right. To maximize compatibility, use one langtag instead of a list of langtags.

Glrx (talk) 20:56, 25 March 2021 (UTC)[reply]

@Glrx: You are right with all you mention. Nevertheless, I think that a good structured multilang SVG should be as easy to expand as some wikitext; in both cases previews are essential, and with the SVG EDIT tool of Rillke each alteration of an SVG file can be seen immediatly (yes, multilang is more difficult).

Simple drawings thought primary for use within wikipedia should function there, I confess that I won't care too much how they render within other environments. The multiple langtag example for the above file would not be necessary, the th langtag is enough and all other languages can be represented by the default. But that may be very special just for this case. I tend to set no langtag at all for text identical to the default, or to set no default when it will be the same as English; when this is done with the needed care no problems will occur - and other users, or the translate tool, will it undertand, too. But I agree that this is not-necessary sophistication -- sarang♥사랑 09:23, 26 March 2021 (UTC)[reply]

@Sarang: There are some subtle issues due to language preferences.

A multilanguage SVG should have a default clause so some text will display if none of the systemLanguage attributes match. Nothing surprising there.

Users can set language preferences in their browser. When someone makes a HTTP request, the browser will send an Accept-Language header. The header informs the server so the server can deliver its content in the best language for the user. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language

I might specify "en,de;q=0.4,ru;q=0.1" to tell the server to provide English, if the server does not have English, then give me German, and the server does not have those language, then provide Russian.

SVG uses the same preferences as the header (but the SVG agent may or may not follow the numerical preferences: SMIL allowReorder processing).

If the SVG has a systemLanguage attribute for each language, then everything work. If, however, the default clause is used for some languages, the user may not get his preference.

<switch>
  <text systemLanguage="de">Sonne</text>
  <text>Sun</text>
</switch>

Although I prefer English, my secondary preference for German will match, so SVG will display "Sonne" rather than "Sun". For consistent displays, we need to avoid matches to lower preferences. That mean explicitly identifying the intended languages rather than relying on the defautl.

There are other language matching problems. If the SVG user agent does not use SMIL allowReorder semantics, then the order of the systemLanguage attributes matters. The default langtag should be the first clause of the switch element. In addition, the order of the languages in all the switch elements should be the same. If the langtag order is not consistent, then the SVG will show a mix of English, German, and Russian text instead of just one of the languages.

Glrx (talk) 19:43, 26 March 2021 (UTC)[reply]

Cat:Translated by SVG Translate tool

Is there such category ? Quickly scanning around I found none. Yug (talk) 15:48, 22 March 2021 (UTC)[reply]

Is there any need for such a category? It could be a maintenance category, set by the translate tool and removed after disgarbaging the file - but as long as no clearing/cleaning possibility exists, neither automatically nor manually triggered, I cannot see usefulness. -- sarang♥사랑 06:14, 24 March 2021 (UTC)[reply]

There is metric benefit.

As per above, the SVG Translate Tools can in some case degrade the files, which have to be fixed. Keeping track of edited files would help.

There are probably other usages I don't think off as of now. Yug (talk) 09:28, 24 March 2021 (UTC)[reply]

@Yug: As far as I understand you, you are thinking of a maintenanceCat (which must be set by the tool), and maybe also a category for the files after beeing maintained? -- sarang♥사랑 07:00, 25 March 2021 (UTC)[reply]

URL passing the file title

Is there a way to share a link to the https://svgtranslate.toolforge.org/ which would also pass the file-to-translate's title ? Something like https://svgtranslate.toolforge.org/?title=Gibraltar map-fr.svg Yug (talk) 15:48, 22 March 2021 (UTC)[reply]

@Yug: looks like either of these work

Glrx (talk) 19:48, 22 March 2021 (UTC)[reply]

@Glrx: thank you. I missed that ! Yug (talk) 22:07, 22 March 2021 (UTC)[reply]

Cyrillic letters work?

Hi, I translated the File:Brandenburg,_administrative_divisions_-_de_-_colored.svg into Bulgarian and uploaded it to Commons as you can see in the file history. However, the translation has not been stored in the file. I have just seen that the same issue comes across with the Ukrainian language. Is it possible that the tool does not support Cyrillic script?--Liglioto (talk) 22:00, 24 May 2022 (UTC)[reply]

@Liglioto:

SVG Translate handles Bulgarian. You've run into two separate issues.

When the file is larger than 250 kB, MediaWiki software may not notice that the file holds translations. Your map is 425 kB.
The image is not displaying any SVG text elements. You can see that by displaying the SVG in a browser: none of the text can be selected. All of the displayed text has been converted to curves, and the those curves are what you see. That is the SVG group "Outlines". The text that you translated is in the group "TT", but that group has display="none", so it is not shown.

SVG Translate does not warn about these problems.

The fix is more involved that just changing the display attribute; numbers also appear.

Glrx (talk) 02:23, 25 May 2022 (UTC)[reply]

@Glrx:

Thank you very much for your detailed response. What might be the easiest solution you recommend? Liglioto (talk) 06:11, 25 May 2022 (UTC)[reply]

@Liglioto:

I had tried a simple fix, but it did not work. The text elements have different formatting, and some numbers need to be replaced with letters. The changes are significant enough that they must be done carefully. I do not have a lot of time right, but I will try to get to it. If I do not fix it in the next four days, then submit a request at Commons:Graphic Lab/Illustration workshop.

Glrx (talk) 17:13, 26 May 2022 (UTC)[reply]

@Liglioto:

Bulgarian is now visible.

Sorry for the delay, but there have been other priorities and the conversion took a lot more work than I expected.

The file still has aan ugly trick in it: text that compresses the x-axis.

Glrx (talk) 05:35, 10 July 2022 (UTC)[reply]

@Glrx Hi, thank you a lot! It looks really perfect already. Just a small detail: the lable "Ostprignitz-Ruppin" is not centered and goes over to "Oberhavel". Maybe, you could fit it.

Thank you again for the good job! Liglioto (talk) 07:28, 11 July 2022 (UTC)[reply]

@Liglioto:

I removed the anisotropic scaling and centered the text. There was not a good balance. Some normal/bold font weight changes did not improve matters. Furthermore, it looks like DejaVu Sans is the only Commons font that supports condensed and condensed bold, but it may not have the Cyrillic code points for that stretch and weight. I'd need to find more time for tests. Looks like reimposing anisotropy or using a smaller font is the only workaround.

Further discussion should be at File talk:Brandenburg,_administrative_divisions_-_de_-_colored.svg.

Glrx (talk) 21:39, 13 July 2022 (UTC)[reply]

I translated the zh-tw version of File:2022 Russian invasion of Ukraine.svg

Note: copied from User talk:Glrx

I translated the zh-tw version of this file, How do I use the translated version? — Preceding unsigned comment added by Twistinez-Taiwaner (talk • contribs) 11:04, 26 May 2022 (UTC) — Preceding unsigned comment added by Twistinez-Taiwaner (talk • contribs) 11:04, 26 May 2022 (UTC)[reply]

@Twistinez-Taiwaner and WDoran (WMF):

You are a victim of buggy software, dubious workarounds, and narrow standards. These problems have been around for years.

First, WMF does not directly serve SVG but rather converts the SVG to a PNG and serves that PNG. The conversion uses an outdated version of librsvg that does not handle hyphenated IETF language tags correctly. WMF's version of librsvg does not process language tags correctly. It treats zh-TW and zh-CN as equivalent. The rasterizer has been updated, but it will probably fail with Chinese languages. The rasterizer and the WMF software need to be fixed.

Second, because librsvg does not distinguish zh-TW and zh-CN, SVG Translate adopted a workaround that uses the non-standard IETF language tags. For zh-TW, SVG Translate uses zh_TW. Those nonstandard language tags let SVG Translate trick the buggy librsvg into displaying the Chinese text. However, those nonstandard language tags make the translations unusable everywhere else. SVG Translate is an application. It is not part of the core MediaWiki software. MediaWiki uses standard, hyphenated, language tags. MediaWiki has also become more intransigent: in many places, it will reject language tags that do no conform to its view of proper language tags. Consequently, the zh_TW language tag does not work in MediaWiki. SVG Translate has misled you.

Third, there are many ways to specify Chinese languages with IETF language tags. You used zh-TW. Taiwan has a preferred script of traditional Chinese characters. One could also use zh-Hant-TW. Under one set of matching rules, zh-TW and zh-Hant-TW are equivalent. However, SVG uses a simpler matching rule that does not make them equivalent. WMF sites use just two versions of Chinese: zh-Hans and zh-Hant; WMF does not distinguish regions such as Taiwan (TW), Hong Kong (HK), and mainland China (CN). So for WMF sites, those two IETF language tags are the ones to use. (WMF software is still broken; it will select zh-, but it will not distinguish the two scripts).

Fourth, SVG Translate only targets WMF sites, so it should not offer to translate to zh-TW. However, SVG Translate would still emit the nonstandard language codes zh_Hans and zh_Hant, so the code would still be unusable on WMF sites.

In the SVG source, I changed one systemLanguage attribute from zh_HANT to zh-HANT. That makes the title in the legend show up.

To fix it, I will have to edit all the Chinese language systemLanguage attributes.

Glrx (talk) 16:34, 26 May 2022 (UTC)[reply]

Supporting Chinese characters?

Tracked in Phabricator
Task T271000
RESOLVED

Hello. Recently I am trying to translate some svg files to Chinese, but it seems not working. In the svg files it only shows some box with four characters (alphabet or numbers) inside. Can someone teach me how to fix it? Many thanks. (Sorry for my bad English) Z423x5c6 (talk) 15:49, 8 June 2022 (UTC)[reply]

@Z423x5c6:

Which files were you trying to translate?

SVG Translate expects an SVG file to have SVG text elements, but many SVG files do not have those elements. Instead, the SVG files have drawn the text using curves. SVG Translate cannot translate those curves.

SVG Translatee also expects that text to follow a specific, simple, syntax. If the text does not follow that syntax, then SVG Translate will refuse to translate the text.

My guess is the files you wanted to translate do not have text that is suitable for SVG Translate.

Glrx (talk) 18:16, 8 June 2022 (UTC)[reply]

@Glrx: I was trying to translate File:Diagramma di Venn dei numeri-ru.svg. The labels on the left hand side show up correctly. I tried again today and when I input the Chinese characters, the text in the SVG becomes blank. Z423x5c6 (talk) 11:42, 9 June 2022 (UTC)[reply]

@Z423x5c6:

What a mess. There are at least 13 versions of this file; see {{Other versions/Diagramma di Venn dei numeri}}. Most are monolingual. They use different names.

The file you were trying to edit is the Russian version File:Diagramma di Venn dei numeri-ru.svg (5 January 2018). That file is suitable for SVG Translate but not ideal. It is a derivative of File:Diagramma di Venn dei numeri.svg (2 October 2010). Normally, the original file would be the file on which to use SVG Translate. However, that file is not suitable for SVG Translate; its text has converted the text to geometric curves. The English File:Venn Diagram of Numbers.svg (28 August 2018) has been used by SVG Translate. It is derived from the original, and it has a few translations already. It does not center its text. It should have used the Italian filename. It also triggers some MediaWiki bugs. I added Italian to the English version.

So add your Chinese to File:Venn Diagram of Numbers.svg:

https://svgtranslate.toolforge.org/File:Venn_Diagram_of_Numbers.svg

I'm not sure what to say about the text not showing up in the SVG. If I choose zh-Hans and type "foo" into a box and move to another bos, then "foo" shows up in the SVG. The text will not show up on Commons because SVG Translate uses the bogus language tag zh_HANS.

Glrx (talk) 16:22, 9 June 2022 (UTC)[reply]

I tried using the link you give, but it is still not working. The text is still not showing up in the SVG. I think I am giving up. Many thanks for trying to solve my problem. Z423x5c6 (talk) 17:20, 9 June 2022 (UTC)[reply]

@Z423x5c6:

Your translations were added to the file, but SVG Translate put them in as zh_HANS. I changed that code to zh-hans to get around the bug with SVG Translate. You can now select Chinese in the dropdown box and it will show your translations.

The text is not centered, but I should be able to fix that later.

Glrx (talk) 18:34, 9 June 2022 (UTC)[reply]

@Glrx:

Maybe let me just capture the screen and show you. Some mysterious boxes are shown instead of the actual Chinese characters that I want. I think it is some sort of Big-5 code of those characters? Z423x5c6 (talk) 19:34, 9 June 2022 (UTC)[reply]

@Z423x5c6: Those boxes are showing that the font does not have glyphs for those characters. That's a bit of surprise to me because I think SVG Translate asks a WMF server to create a PNG from the SVG, and the fonts on the WMF server should have the characters. When I make a change that includes Chinese characters, then I just get no text on the image. If my change has only Latin characters, then it does display. I do not know why that happens.

SVG Translate has problems, and I do not know what to say. SVG Translate is completely broken for Chinese. You should be able to add Chinese to some SVG files, but you will not be able to make the Chinese display on Commons without some additional edits to the SVG. Glrx (talk) 19:54, 9 June 2022 (UTC)[reply]

Label is not translated

Tracked in Phabricator
Task T327573

I have an issue with the file File:Viewing angle and air masses (reduced).svg. I'm trying to replace angles to 90-x. In the translation all the labels are translatable but the "90" one. Moreover tool suggests to translate it (and even add <switch> tags around it, so I just adjust the text using text editor), but doesn't add translated version of the text. This true for both preview and after upload. What am I doing wrongly? Amishaa (talk) 10:08, 20 January 2023 (UTC)[reply]

It looks like you made it work. Glrx (talk) 20:25, 20 January 2023 (UTC)[reply]

Nope, the tool didn't work, I had to update svg manually (downloaded it, open in text editor, made the change upload as new version). With the current version, thought, the problem is not present anymore, adding languages work as expected (as well as changing the current ru translation). I uploaded the version, that tool doesn't work well with, as File:Viewing angle and air masses (test upload).svg (and updated pictures in the discussion). Amishaa (talk) 22:02, 20 January 2023 (UTC)[reply]

The offending text is

<g fill="none" color="black" stroke="currentColor" stroke-width="1.00" stroke-linecap="butt" stroke-linejoin="miter">
	<path stroke="black" d="M574.82,422.40 L574.82,413.40 M574.82,54.01 L574.82,63.01  "/>
	<g transform="translate(574.82,444.30)" stroke="none" fill="black" font-family="Arial" font-size="12.00" text-anchor="middle">
		<switch><text id="trsvg48"><tspan font-family="Arial" id="trsvg20"> 90</tspan></text></switch>
	</g>
</g>

If I run SVG Translate, it displays the "90" and allows me to enter "0", but it does not write the translated text in the SVG output.

The ids trsvg48 and trsvg20 are unique.

Glrx (talk) 03:41, 21 January 2023 (UTC)[reply]

Thumbnail issues

Hello. I translated some maps using SVG translator but after downloading them to Commons I see that they haven't changed from the version I used for translation (English, French, Makedonian) File:Colombia relief location map cropped-lt.svg, File:Dagestan topographic map-lt.svg, File:Azerbaijan topographic map-lt.svg, File:Map of Bangladesh-lt.svg. Although thumbnails indicate no changes, when you open it as a raw file, the traslations are displayed correctly. I have tried to purge cache, to use different browsers but in vain. It seems, this is issue at Commons. How to sort it out? // And another thing, as I try to use "Upload to Commons" button, it overwrites the file I translate instead of letting to upload it with a different language prefix (for ex. [2]), so I have to download my translation and upload it as usual. Hugo.arg (talk) 10:00, 11 March 2023 (UTC)[reply]

@Hugo.arg:

You are misusing SVG Translate because you have run into a couple of bugs on Commons.

When using SVG Translate, you should overwrite the the original file. SVG Translate makes multilingual files: one file holds several translations.

You cannot see the lt translation because the files are over 256 kB: Commons only looks at the first 256 kB to determine if an SVG file has translations.

File:Colombia relief location map cropped-lt.svg -- nominated for deletion. File:Colombia relief location map cropped.svg restored; Commons workaround.
File:Dagestan topographic map-lt.svg (needs to be figured out)
File:Azerbaijan topographic map-lt.svg (-mk / needs to be figured out)
File:Map of Bangladesh-lt.svg -- Dup of -en; -lt and -l2 nominated for deletion; -en added Commons workaround

Glrx (talk) 17:39, 11 March 2023 (UTC)[reply]

How to mark that some texts should not be translated?

Hi,

All is in the title. For a specific examples, there is file around chemical compound that use letters that are chemical symbols and thus should not be translated. See for instance File:Cysteine-to-allicin-2D-skeletal.svg (I also have a <style> problem, not sure what would be best to do about it).

Cheers, VIGNERON (talk) 13:33, 7 September 2023 (UTC)[reply]

@VIGNERON:

In theory: A few years ago, one would add the attribute its:translate="no" (w:Internationalization Tag Set). With the advent of HTML 5, one could add the attribute translate="no" (The translate attribute). SVG 2.0 drafts had a similar translate attribute for a time, but I believe it is now gone. Translation programs were supposed to recognize those attributes and skip translating the marked text.

In practice: SVG Translate ignores the attributes and does not have an alternative mechanism. A simple workaround has the translator just ignoring those items. If something is not translated, then SVG will display the default clause. It works in many cases, but it can also create unexpected displays when the SVG is viewed in a browser. Redundant translations do not have the problem.

It also gets more complicated: translate="no" is too blunt an instrument and has other subtle problems. For Latin languages, we do not need to translate small integers such as "125". An Arabic language may or may not want to translate the number. Latin languages are happy with the metric distance "125 km". A Cyrillic language will want to use "125 км". In western European chemical diagrams, it is simpler to write the chemical symbol "C" rather than "carbon". In Chinese, the illustration may want to use "碳".

Glrx (talk) 18:40, 7 September 2023 (UTC)[reply]

Adding translations should automatically add the respective lang cat & other version

Could this tool please be changed so it also automatically adds the language's respective category to the file? It would check the categories and get the subcats of Category:SVG by language (like Category:Chinese-language SVG diagrams) and then add the respective subcat of the cat above (here Category:SVG diagrams by language) for the added language. I think it should also add the new translated SVG image to the "Other versions" field of the file. Example: a user recently uploading a new translated version of File:Celltypes.svg did not add the cat for the language it was translated into and didn't add the variant to the other versions gallery.

Otherwise, the categories will be incomplete which also means people searching for images in some language using a language category won't find it, it may impact the search results, and people looking at the file looking for a variant to use, e.g. for some other language Wikipedia, won't see it. There are more problems. It also wastes contributors time to have to add these things manually and means these cats and other versions fields are pretty unreliable.

The same thing is done for other language subtitles with {{Closed captions}} so it would be really good if the same thing was implemented here. It could be a candidate for a bot request to add these cats afterwards or add a cat to files with incomplete language-cats or e.g. add sth like {{SVGTranslated}}. Prototyperspective (talk) 14:36, 18 September 2024 (UTC)[reply]

Commons talk:SVG Translate tool

Contents

Blank character

Problem with Antarctica

Could we use wikimarkup?

Problem with comparison_satellite_navigation_orbits.svg

"This file does not have any labels available for translation" yet it does

"This file does not have any labels available for translation"... but why?

very serious Bugs

Svgtranslated files with no language extension and/or seemingly nonexistant

Renaming element id prevents translation on use

Strange behavior of the tool

do not overwrite files in Category:SVG simplification by text switch

To show what is being talked about

Cat:Translated by SVG Translate tool

URL passing the file title

Cyrillic letters work?

I translated the zh-tw version of File:2022 Russian invasion of Ukraine.svg

Supporting Chinese characters?

Label is not translated

Thumbnail issues

How to mark that some texts should not be translated?

Adding translations should automatically add the respective lang cat & other version

Navigation menu

Commons talk:SVG Translate tool

Blank character

Problem with Antarctica

Could we use wikimarkup?

Problem with comparison_satellite_navigation_orbits.svg

"This file does not have any labels available for translation" yet it does

"This file does not have any labels available for translation"... but why?

very serious Bugs

Svgtranslated files with no language extension and/or seemingly nonexistant

Renaming element id prevents translation on use

Strange behavior of the tool

do not overwrite files in Category:SVG simplification by text switch

To show what is being talked about

Cat:Translated by SVG Translate tool

URL passing the file title

Cyrillic letters work?

I translated the zh-tw version of File:2022 Russian invasion of Ukraine.svg

Supporting Chinese characters?

Label is not translated

Thumbnail issues

How to mark that some texts should not be translated?

Adding translations should automatically add the respective lang cat & other version

Navigation menu

Search