Template talk:Vector version available/Archive 1

Reverted the redirection

As it says above, there must be some way to indicate raster images which have a vector counterpart of some kind, but which may not be fully "superseded" (for various reasons). AnonMoos 22:39, 3 February 2007 (UTC)

two template with common goals

why does both this and Template:SupersededSVG exist? --Ysangkok 18:53, 11 March 2007 (UTC)

Because there's no guarantee that a vector version of a file is good quality, or an accurate conversion. Therefore, there must be some way to indicate raster images which have a vector counterpart of some kind, but which may not be fully "superseded" (for various reasons). AnonMoos 22:46, 11 March 2007 (UTC)

You may be right, but most of the pictures tagged with Vector version avaible are in fact superseded: take a sample of some pictures using Vector version. This is because most user don't know the difference of superseded and vectro version. If an image is proposed fo deletion (Commons:Deletion_requests/Superseded), the people who delete the picture check if it is really superseded or not. So I suggest redirecting this template to supersededSVG --DieBuche 11:03, 31 March 2007 (UTC)

Sorry, but if an SVG image "corresponds" to a raster image (or attempts to do so), but is low-quality, or has significant differences from the raster, then there needs to be some way of formally indicating this. There seem to be some admins who are on a deletion rampage on WikiMedia Commons, running around deleting everything in sight which has some kind of SVG counterpart, no matter how crude or primitive or low quality -- and the "vector version available" template is one of the few fragile reeds of protection which exist against these trigger-happy "delete at all costs" types. Only in the last few days, the former image Image:No cross.png was deleted, despite the fact that its alleged "replacement"[sic] Image:No cross.svg is ugly and low-quality, with a number of differences from the original PNG, and an alleged "cross" which barely even looks like a cross! If the existence of the "vector version available" template can help prevent the future occurrence of similar travesties, then it's definitely needed. AnonMoos 12:13, 31 March 2007 (UTC)

I use {{{Vector version available}}} for the reasons outlined by AnonMoos - I feel that as the creator (or tracer) of the images I upload, I am not in a position to impartially judge their worthiness to "supersede" the original. So I use the former, and if someone else later thinks that the images are good enough to supersede, they are welcome to swap the templates. Stannered 00:45, 1 April 2007 (UTC)

Note, not to delete superseded images

Could someone please add this to the template as in Superseded:
<small>The deletion of superseded images has been suspended indefinitely; see [[Commons talk:Deletion requests/Superseded|the discussion]] for more information.</small>

--Matt 17:11, 10 February 2008 (UTC)

Punctuation

{{Editprotected}} Please remove the quotation marks from ("SVG") so that it reads (SVG). They are incorrect and there is absolutely no rational for them being there. See w:quotation mark. Reywas92 21:40, 19 March 2008 (UTC)

Done. —David Levy 18:12, 21 March 2008 (UTC)

Cat

This should go in this cat: Category:Templates for marking as superseded. Evrik 02:23, 28 April 2008 (UTC)

Look above. This particular template very specifically does not mark as superseded... AnonMoos 20:54, 28 April 2008 (UTC)

SVG-Template

as it is constricted to SVGs, please could some admin sort it down into Category:SVG marker templates - or do we have other vector gaphics, we do: .PDF, and we had OpenOffice.org .SXD (I think we dismissed that) - well, both won't be rendered by now.. --W!B: 01:08, 6 May 2008 (UTC)

For the same reason, why specify the file type in the arguments?--Ainlina (talk) 16:53, 2 November 2008 (UTC)

auto translation

Please change, or let me change, this template according to the change in Template:Speedy delete text for making this template auto translated. For users with German interface speeddelete is in German[1], for users with French interface it is in French[2] and so on. (currently works only in English, German, French, Hebrew and Italian but as sysops create more MediaWiki:Lang pages, it can work in all other languages). Thanks, ערן (talk) 06:29, 8 November 2008 (UTC)

 Done I think - please double-check my work.  — Mike.lifeguard | ^@en.wb 18:58, 8 November 2008 (UTC)

Thanks, ערן (talk) 19:38, 8 November 2008 (UTC)

File namespace

{{editprotected}}

Please replace

{{#ifeq:{{NAMESPACE}}|Image|[[Category:Vector version available|{{PAGENAME}}]]}}

in <includeonly> to

{{#ifeq:{{NAMESPACE}}|File|[[Category:Vector version available|{{PAGENAME}}]]}}

. This correctly collects files into Category:Vector version available. --fryed-peach (talk) 19:57, 6 January 2009 (UTC)

 Done — Mike.lifeguard | ^@en.wb 05:35, 7 January 2009 (UTC)

Could I add a simple example of usage?

{{editprotected}}

Just adding something like Example code: {{vector version available|new image name.svg}}, would do the trick, like in the instructional {{Convert to SVG}}-secton in Category:Global Warming Art images.

The reason I'm asking is because I wanted to use the but then didn't find any instructions on the actual template page. Please tell me if I've misunderstood completely. Thanks. Jarl Arntzen (talk) 21:27, 14 July 2009 (UTC)

Now after adding it to the documentation I realize you meant the template itself... I'll add it to Template:Vector version available/en. Rocket000 (talk) 04:39, 15 July 2009 (UTC)

 Done Now it will display an error message when you use it wrong or try to link to a non-existent image. It will remind you of the correct syntax. This only works on File: pages (that's why it's not displaying an error in the example). Rocket000 (talk) 04:57, 15 July 2009 (UTC)

Linking of images

Would it be possible to link files on other wikis? I know a couple of cases where a vector version is available on another wiki that I would like to link, so somebody can transfer it if needed. I think a preview of the file would not be possible. In that case a message could be displayed that the file is on another wiki. --Cwbm (commons) (talk) 12:23, 22 October 2009 (UTC)

 Comment: I removed {{Editprotected}}, because it's not a request to make an edit, but rather a question if something is possible. --The Evil IP address (talk) 23:02, 28 October 2009 (UTC)

---

In most cases, it would be raster images on Wikipedias linking to an alternative vector image on Commons, not the reverse... AnonMoos (talk) 15:47, 16 November 2009 (UTC)

Umm? This doesn't make sense?

when superior sounds weird, shouldn't it be 'when possible'? -- 16:43, 16 June 2008 68.9.226.101

When the SVG image is better in overall quality and suitability for intended purpose than the raster image is (which is not always the case). AnonMoos (talk) 18:06, 16 June 2008 (UTC)

I agree, the wording is sloppy, and every time I see it I cringe. "It should be used in place of this raster image when superior.." when superior what? When superior quality is needed?--98.232.98.144 03:13, 29 April 2009 (UTC)

Not sure how to state it better than "When the SVG image is better in overall quality and suitability for the intended purpose than the raster image is (which is not always the case)", as I already did directly above. AnonMoos (talk) 12:08, 29 April 2009 (UTC)

{{Edit protected}}Or we could just go with: "when not inferior" instead of "when superior"? SamB (talk) 04:54, 11 March 2014 (UTC)

 Done Implied consensus assumed after 4 months. -- Rillke^(q?) 18:52, 14 July 2014 (UTC)

Armenian

Please, add Armenian version.--Pandukht (talk) 18:37, 16 June 2010 (UTC)

 Done--DieBuche (talk) 19:58, 16 June 2010 (UTC)

Parameter for quality rating

It may be useful to add an optional parameter to this template, for specifying the graphical quality of the SVG alternative; I thought that it could consist of a number from 1 to 5, when 3 stands for 'quite exactly the same quality as the original' for example: {{Vector version available|New_Image.svg|4}} would indicate that New_Image.svg is a little better than the raster one. If the rating is lower than 3, the template could suggest not to replace the current image with the vector one, but to create a new one. In the future, we could use a voting tool to show the average rating for SVG replacements. --Ricordisamoa (talk but not stalk) 01:25, 2 January 2013 (UTC)

However, that would mean that the rating information about the SVG would not be on the SVG file's description page... AnonMoos (talk) 21:46, 2 January 2013 (UTC)

The rating could be inserted in the SVG file's description page and retrieved at runtime by the template, of course (I don't know if and how this can be done); however, some SVG images can be used to replace multiple raster ones, and so they would need as many ratings, and this could create problems. Your choice. --Ricordisamoa (talk but not stalk) 23:46, 2 January 2013 (UTC)

@AnonMoos: yes, because an SVG image can supersede several raster ones, with varying degrees of accuracy. Information where it's needed. --Ricordisamoa 15:21, 17 April 2014 (UTC)

Support - I've been caught by this, lured into using someone's inaccurate hand-reconstruction over an official PNG - David Gerard (talk) 16:01, 18 October 2013 (UTC)

Moreover, consider that we have currently 112,745 files in a single "Vector version available" category, while we could have five distinct subcategories hosting all files by accuracy as compared to the original. --Ricordisamoa 18:02, 13 April 2014 (UTC)

Do you think someone would care for updating this template when improving a vector version? If so, you have my support. If you add a parameter, please migrate the template so it makes use of the translate extension and we can easily update all translations. Thanks in advance. -- Rillke^(q?) 20:58, 13 April 2014 (UTC)

I can think of very few users who usually convert raster images into SVG. It would be wise to notice them, and maybe to create an AbuseFilter warning for those who insert {{Vector version available}} without rating. Then, a JavaScript tool should be created to help users assess existing vector alternatives. But the present consensus is IMHO not sufficient to proceed. --Ricordisamoa 15:14, 17 April 2014 (UTC)

Bug: visible wiki-markup when target svg does not exist

When {{Vector version available}} is used in a way that points to a .svg that does not actually exist, there are visible closing square-brackets preceding the "Error: No image by that name exists." message. See for example [3]. In addition, there is another set of visible square-brackets in the replacement statement below the first horizontal line when no parameter is passed.[4]

The first issue appears to be in Template:Vector version available/en in the false fallback branch here:

{{#ifexist:{{{1}}}|[[:{{{1}}}]] is a vector version of this file.
It should be used in place of this raster image when superior.|{{{1}}}]]: <span class="error">Error: No image by that name exists.

The underlined close brackets do not appear to have a corresponding open. Maybe it should be [[:{{{1}}}]]?

The second issue is probably in Template:Vector version available/layout but I don't have time to look more deeply into it at the moment. DMacks (talk) 07:36, 28 February 2013 (UTC)

 Info Cases with missing parameter are listed under Special:WhatLinksHere/Template:Vector version available/error. It might be an option to change the template in the way that pages with an error get into a maintenance category to get more attention. --Leyo 08:42, 28 February 2013 (UTC)

It did so. The cases are now (or soon) in Category:Vector version available/error. --Leyo 15:43, 23 July 2013 (UTC)

Redirect

I think, we should create a redirect from Template:Vector. It would be simple for placing in the source code. For example:

{{Vector|Example.svg}}

--Rezonansowy (talk) 07:22, 9 May 2013 (UTC)

Short synonym is {{Vva}}. "Vector" is somewhat ambiguous (could also be a synonym of {{SVG}} etc.). AnonMoos (talk) 15:00, 9 May 2013 (UTC)

Background

Template needs an optional background parameter for white vectors, e.g., here.   — C M B J   05:16, 18 May 2013 (UTC)

 Done. Now default. Extra param would require editing all language subpages; this could be done after someone migrated this template to the translate extension. -- Rillke^(q?) 20:55, 13 April 2014 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Rillke^(q?) 20:55, 13 April 2014 (UTC)

More appropriate colors (resolved)

I think this template should mostly red to indicate that it is wrong to use this image and another image should be used instead. I would add those images: to explicite the message. ftiercel (talk) 18:48, 19 September 2013 (UTC)

•  Oppose --Leyo 08:51, 20 September 2013 (UTC)

  Why? ftiercel (talk) 22:11, 20 September 2013 (UTC)

Because this template only states that a vector of some kind is available, but does nothing to vouch for the quality of the SVG, or whether the SVG can serve as a truly equivalent replacement for the raster image. See some of the old comments in sections above... AnonMoos (talk) 19:03, 23 September 2013 (UTC)

OK. ftiercel (talk) 17:23, 27 September 2013 (UTC)

•  Oppose For the reasons mentioned by ftiercel. Aldaron (talk) 01:17, 29 September 2014 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 14:28, 27 January 2018 (UTC)

Recommendation for positioning of this template

According to the question on Template talk:Convert to SVG#Recommendation for positioning of this template, also raises it here. However, there are only two possibilities.

1. On the very top of the desc.: I mean this overvalued the importance of this template, often the SVG are not better.
2. On |Other versions=: I mean this should be the only one reasonable if present.

   Objections to put this on the template doc? ↔ User: Perhelion (Commons: = crap?) 07:54, 27 September 2014 (UTC)

3. Below the information template is also an option, especially if there are e.g. multilingual versions in |Other versions=. --Leyo 12:37, 27 September 2014 (UTC)

 Oppose should be on top so that you can directly compare the images. --Cwbm (commons) (talk) 22:02, 29 September 2014 (UTC)

Ok this is a point and also seems to the most practice. ↔ User: Perhelion (Commons: = crap?) 15:33, 2 October 2014 (UTC)

But this is not a substantial argumentation, because this template displays only a thumb (like under |Other_versions=), so you can not really compare an image. So for me I'll put this template now always in |Other versions=. ↔ User: Perhelion (Commons: = crap?) 12:53, 16 October 2014 (UTC)

Help:SVG

{{Editprotect}} Commons:Transition to SVG was apparently an ancient (2007) failed dogma crusade, why not link to the far better Help:SVG page in this template? –Be..anyone (talk) 13:21, 28 December 2014 (UTC)

Supporting the {{Editprotected}} in the next section I've added another for the suggestion below (nobody objected, one neutral witness).

old en

|moreInfo=For more information about vector graphics, read about [[Commons:Transition to SVG|Commons transition to SVG]].<br />There is also [[:meta:SVG image support|information about MediaWiki's support of SVG images]].

new en

|moreInfo=For more information see [[Help:SVG]].

old de:

|moreInfo=Zu mehr Informationen über Vektorgrafiken lies bitte die [[Help:SVG|SVG}{{en Artikel ''[[Commons:Wechsel zu SVG]]''.<br />Es ist außerdem eine Seite verfügbar, die [[m:SVG image support|Informationen über die Unterstützung von SVG-Grafiken durch MediaWiki]] enthält.

new de:

|moreInfo=Für weitere Informationen siehe [[Help:SVG]].

A German translation of Help:SVG actually doesn't exist at the moment. The French, Portuguese, and Spanish translations might be seriously obsolete, but they can't be worse than Commons:Transition to SVG (on hold since August 2007) or the historical m:SVG image support. –Be..anyone (talk) 23:47, 26 January 2015 (UTC)

Apparently {{Vector version available/sandbox/en}} would implement the new en suggestion above when deployed. I've adopted this English version to update the unprotected German version. Summary, de fixed, en sandbox ready for deployment. –Be..anyone (talk) 15:24, 15 February 2015 (UTC)

Btw. can someone delete this (nonsense) Help:SVG de (the author has also agreed, I've 2 times set a DR on this, an replace the link here Help:Contents/de, could be rather link to de:Help:SVG). ↔ User: Perhelion (Commons: = crap?)  19:08, 15 February 2015 (UTC)

Not sure about updating /en (or for that matter /de) already without updating the main template and /layout at the same time – /sandbox/en uses a new |imageDoesNotExist= parameter for the does-not-exist error, which the current /layout does not use and therefore won't display unless /sandbox/layout is also deployed. SiBr₄ (talk) 10:48, 17 February 2015 (UTC)

WTH are Special:Diff/149852864 and Special:Diff/150312914 supposed to do as long as I still get Transition to SVG instead of Help:SVG for en-GB and en? This edit request has nothing to do with code adding a File: after checking that all possible variants of fILE: (8) plus iMAGE: (16) are really missing. –Be..anyone (talk) 17:11, 1 March 2015 (UTC)

IMHO we do not need to to make a useless update of a template used more than 63000 times when everything - including your cosmetic request - will be replaced anyway within the next few days. Just keep patience for a short while. sarang♥사랑 07:33, 2 March 2015 (UTC)

@Sarang: the next mutilation of this edit request will go to AN/I. Obviously those "few days" since 2014-12-28 are taking longer. Edit requests can be contested or supported, e.g., with an {{Oppose}}, or disabled as either rejected or done. Disabling without doing anything just does not fly, the servers will survive one or two or a hundred changes on 63000 files without problems. –Be..anyone (talk) 05:51, 15 March 2015 (UTC)

The sandbox version, which includes the change, is now deployed. SiBr₄ (talk) 22:46, 20 March 2015 (UTC)

Thanks, works for me (en-GB test). –Be..anyone (talk) 20:21, 27 March 2015 (UTC)

Proposed fix for English version

{{editprotected|technical=1}} There are several oddities in the code for the English version of this template:

1. The text of the notice when the namespace prefix is included in the first parameter (e.g. {{vva|File:Filename.svg}}) is different from the text without it (e.g. {{vva|Filename.svg}}). This is due to a July 2014 edit, which changed "superior" to "not inferior" in the first #ifexist case, but not in the second.
2. If a title is entered that does not exist in File: namespace but does exist in the main namespace, the template does not give the does-not-exist error, but just links to the gallery page. Try adding {{vva|Main Page}} to any page in File: namespace.
3. And as noted a few sections above this one, there is some stray code {{{1}}}]]: at the start of the text for a nonexisting file.

The following code for line 3 combines the two #ifexist cases to consolidate the template messages (preventing inconsistencies as described at #1), and fixes #2 and #3.

|imageExists={{#ifeq:{{NAMESPACE}}|File|{{#ifexist:File:{{PAGENAME:{{{1}}}}}|[[:File:{{PAGENAME:{{{1}}}}}]] is a vector version of this file.<br/>It should be used in place of this raster image when not inferior.|<span class="error">Error: No image by that name exists. Please make sure to use the correct format: {{tlp|vector version available|''new image name''.svg}}.</span>}}|}}

SiBr₄ (talk) 15:15, 19 January 2015 (UTC)

@SiBr4: Yes, you are fully right! (In the German version this fault is not.) There are much more mistakes in this template. I suggest a strong rewrite of the file check method. Currently the parameter gets with ifexists five times checked (3 in /layout and 2 in /en )!! This is unbelievable (because ifexists is server-unfriendlyness), only one check is really needed in the main template! And yes, the expensive use of {{NAMESPACE}} is also completely nonsense, because there is no dynamically namespace for this template (only File). I would create a test case for my suggestion!? PS: I've created a server friendly Lua replacement for {{NowSVG}}. So I also Suggest an error parameter in the /layout page. The English subpage seems the only one with this (as I said this error can be checked once in the main template). ↔ User: Perhelion (Commons: = crap?)  00:31, 5 February 2015 (UTC)

Yes, the /layout subpage should be changed the same way:

<div style="margin-left:auto; margin-right: auto; text-align:center; font-size:90%;">File:{{PAGENAME}} [[File:Gnome-go-next.svg|link=|12px|middle]] [[:File:{{PAGENAME:{{{1}}}}}]]</div>

|img=<div class="com-checker">{{#ifexist:File:{{PAGENAME:{{{1}}}}}|[[File:{{PAGENAME:{{{1}}}}}|{{{svgImageLabel}}}|150x150px]]}}</div>

This additionally reduces the number of #ifexists from 3 to 1. SiBr₄ (talk) 09:12, 12 February 2015 (UTC)

 Support not inferior as used in Rillke's edit. And less #ifexist where not needed are also good. –Be..anyone (talk) 09:50, 5 February 2015 (UTC)

Improvements

Proliferation

There are too many variations for redirects of "Vector version available" (altogether transcluded 62 972 times)

• {{Vva}} (15 380 times)
• {{VVA}} (466 times)
• {{NowSVG}} (1 822 times)
• {{SVG available}} (943 times)
• {{Converted to SVG}} (70 times)

Do we really need so many choices? Or would it be preferable to reduce that to two or three variations?
Theoretically "Converted to SVG" bears the comfort to change "Convert to SVG" after conversion occurred; especially when no name must be given if same name.

Substitution

Building on #Suggestion: The prevalent majority of transclusions is for the same name (save the extension ".svg"). Since the modules for file names are available, it is quite easy and server friendly to generate the name of the SVG file. Offering the substitution of the optional file name would increase the comfort.

Expansion

As mentioned several times on this page, some but not all SVG files supersede the file in access. With an additional parameter that can be combined, transcluding/embedding {{Superseded}} when desired, such increasing the comfort. sarang♥사랑 07:43, 11 February 2015 (UTC)

I would support to delete VVA and Converted to SVG (this names exist also not on en:Template:Vector version available). I would also suggest the same for {{SVG}} (there are much more. Note, every name need to include in a user script)

@Substitution: I'm not sure here, but I have nothing concrete about it.

@Expansion: I mean to much parameter for an extensive used template is not that server friendly. I suggest to use {{TracedSVG}} instead, because a SVG should always be superior as it is intended to expect (compare also from today Help_talk:SVG#When_to_use_PNG_over_SVG.3F). But I'm also open for other opinions.

↔ User: Perhelion (Commons: = crap?)  08:46, 11 February 2015 (UTC)

For names also existing on enwiki a #REDIRECT instead of a deletion might be good enough. But as long as this template is fully protected with edit requests pending creating one new unprotected clone daily should our primary duty. –Be..anyone (talk) 01:28, 12 February 2015 (UTC)

All five but {{NowSVG}} are already redirects to this template. NowSVG is a wrapper that fills in the original filename with the extension replaced, which is what Sarang suggests, and could be built into the main {{Vector version available}}. SiBr₄ (talk) 08:55, 12 February 2015 (UTC)

Yes, NowSVG had been a former redirect which has been violated by me for this usage (or example). sarang♥사랑 14:18, 12 February 2015 (UTC)

Please keep {{Vva}} and {{NowSVG}}, it's a nice short name to write instead of this long {{Vector version available}}, non-English speakers can make typos on the word "available"... Thanks. Thibaut120094 (talk) 07:10, 17 February 2015 (UTC)

I am noyt destroying everything, {{Vva}} and {{NowSWG}} are kept. sarang♥사랑 20:27, 19 February 2015 (UTC)

I have just used template {{SVG available}}. But this is no longer a redirect to {{Vector version available}}. Can someone please take a look on this whether this is vandalism or something useful? Note: It is only used once in the moment (by me :-)), not 900 times as stated above. -Torsch (talk) 18:27, 19 February 2015 (UTC)

Hi Torsch, I gave it a look and saw that you tried to use {{svg available}} - not {{SVG available}}! As you may see at #Too many redirects some of the too many redirects are removed. There are even shorter redirects, but not each one for any typing error. I hope you can make with that, at least within a short time. sarang♥사랑 19:39, 19 February 2015 (UTC)

Sandbox

@Be..anyone, Sarang, and Perhelion: I created some template sandboxes at {{Vector version available/sandbox}}, {{Vector version available/sandbox/layout}} and {{Vector version available/sandbox/en}}, and implemented the suggested changes from the three previous sections. That way all changes can be requested at once with a single {{Editprotected}}.

For some tests that compare the sandbox with the current main template, see Special:Permalink/149852684#Testing Template:Vector version available. SiBr₄ (talk) 11:09, 12 February 2015 (UTC)

Thank you. I made some suggestions at {{Vector version available/sandbox}}. I'll check the others too.

Considering the fact that the ifexist test is only for preventing from giving wrong file names (whether explicitely or generated, whether at editing time or later when the target file might be deleted) I have no good feeling that it is executed every time and at each file where very close to 100% will be nominating an existing file name. How about care nothing at all - the display will just be a redlink like File:Not existing file.svg or so? Keep in mind, this will happen just a very few times, a possibly maintenance category will be empty most of the time - and I cannot see an urgent need to repair faults like that. Anyway, when it is found necessary the #invoke:File|fileExists|file= should be used, of course only once. sarang♥사랑 12:43, 12 February 2015 (UTC)

Remarks to the sandbox version:

1. ucfirst is not needed, occurs automatically
2. 1^st categorizing also when from file talk page (edit-protected file descriptions)
3. 2^nd categorizing (when no file name) is of no use

Suggestion:

<includeonly>{{Autotranslate|1={{{1|{{#invoke:FileName|removeExtension}}.svg}}}|base=Vector version available/sandbox}}{{#switch:{{NAMESPACENUMBER}}|6|7=[[Category:Vector version available|{{PAGENAME}}]]}}</includeonly>

— Preceding unsigned comment added by Sarang (talk • contribs)

@Sarang: I've moved your comment from the sandbox itself to here. Feel free to edit the sandbox code yourself; that's what a sandbox is for! :)

Regarding your remarks:

1. The ucfirst function was copied straightly from the current template, which has had it since 2010. Removing it doesn't break anything, though if the parameter uses a lowercase first letter, the file name would display that way too.
2. If I understand correctly, you would put the template on the file talk page instead of the file page if the latter is protected, and have the talk page appear in Category:Vector version available? I can't say I agree with that; just request the VVA template to be added to the file page using {{Editprotected}} in such cases.
3. {{NowSVG}} includes a tracking category for pages that use the automatic filename; I kept it (with the category name changed) since it may be useful for tracking instances where the first parameter is erroneously omitted. If a tracking category for non-existing files is kept, that would take care of most wrong usages though. SiBr₄ (talk) 12:58, 12 February 2015 (UTC)

I made some edits to each sandbox. All parser functions and markup are now in the /layout subpage instead of /en, and only one #ifexist is used across all three templates. /layout now adds the text from |imageExists= and Category:Vector version available if the image exists, and an error specified by the new |imageDoesNotExist= and Category:Vector version available/error if it doesn't. SiBr₄ (talk) 13:23, 12 February 2015 (UTC)

Thank you for moving, I wrote it there because liked to put your coding and mine together.

1. If just one file name is given, without a piped display name, AFAIK it is displayed uc (see my redlink example above). But never mind, neither using or not would do any harm.
2. Abusing the talk page is just a possibility used also by some other templates; when an editprotected is created the ns:7 option just let the talk page appear as long the editprot is pending. But I won't mind if that is not pleased.
3. Yes, I had a whitespaced category in NowSVG, and Perhelion activated it. As I estimate, it may make some sense to have a maintenance category when the file doesn't exist (if the existence check will finally be performed by the template). But whether the file name is typed or generated is IMHO of null interest (except only for a temporary maintenance test case).

To state it again: redlinks will always occur. If they can be avoided in a not server-stressing cheap way, fine. If the effort for the precaution is too expensive and they happen, not bad. I am always keeping in mind that we talk about an extensively used template! When some files mentioned e.g. in other versions don't exist, a redlink is shown; that isn't nice - but it is not bad. Of course we can check everything, and display different error messages, and fill maintenance categories - but we should do that only as long the advantage justifies the effort (of the server, not of the template programmer). I am not convinced that we need the existence check.

BTW, most editors will preview their input, and see immediately when they give a wrong file name. Some editors don't care, may be they will also not care an error display, so it becomes the duty of the reparation team to check the error category... But if there is no error category, and no immediate error recognition is provided, it is not the worst thing.

Sorry, I lack the intimate knowledge of the system to tell exactly how much effort the ex-check will cause. I am thinking of asking people knowing more, how good or bad either way may be.

@SiBr4: , your solution is very good, an example how templates should work, and in any view better than the current template. sarang♥사랑 14:18, 12 February 2015 (UTC)

It looks all nice to me. You both have my voice. It would be nice to have a performance check before and after. ↔ User: Perhelion (Commons: = crap?)  16:25, 12 February 2015 (UTC)

I don't think we really need to worry about performance. Some quick tests using the parser profiling data seem to confirm this: both the live template and the sandbox take about 0.1 second to load on an empty page, and the mutual difference is less than one hundredth of a second. I think the benefits of an error message and tracking category far outweigh the few milliseconds that can be saved. That the template is used on many pages does not matter; obviously the loading times multiply if the template is used many times on the same page (which this one shouldn't be).

1. An unpiped link starting with a lowercase letter is shown with the lowercase letter, though it correctly links to the uppercase-first version: File:example.png. Far from a big deal though.
2. Currently, only seven file talk pages use Template:Vector version available, and in only three cases the corresponding file page is protected. If the template is on the talk page, it is much less likely to be seen than if it's on the file page, which is the main reason why I don't think we should encourage sticking it on the file talk page.

   The template works correctly in all namespaces either way; the question is whether to allow file talk pages in Category:Vector version available. It may be better to allow them, since that helps track usages of the template on talk pages when they should be on the file page.

SiBr₄ (talk) 13:52, 14 February 2015 (UTC)

Regarding 1., the first letter is only changed to uppercase when you link to a non-existing file without colon: [[File:somefile.svg]] → File:Somefile.svg and [[:File:somefile.svg]] → File:somefile.svg. It appears the PAGENAME magic word used to remove the namespace already changes the first letter to uppercase, so the ucfirst actually is completely unnecessary. SiBr₄ (talk) 14:04, 14 February 2015 (UTC)

SiBr4, you helped me to get rid of my concerns. I do not see any more reasons for anxiety about server resources, and we can work out a good solution - with a clear and prominent error message when the file name fails. Do you think it is enough to have an English message, or shall we try to nationalize it? Any solution would be easy when the error is displayed by a subtemplate; this may also be an additional possibility to find saved erroneous transclusions. sarang♥사랑 14:22, 15 February 2015 (UTC)

The short English error message text I added here is a fallback, so it only displays if a language subpage hasn't localized it using the |imageDoesNotExist= parameter. Since the parameter is new in the sandbox version, no subpages have done that yet (except the German one, which Be..anyone just changed, and the sandbox English version). SiBr₄ (talk) 16:30, 15 February 2015 (UTC)

I changed something at the sandbox templates, to keep them tight. The coding looks horrible but now it works perfectly: with (I took Rva for the name)

1. {{Rva}}
2. {{Rva|}}
3. {{Rva|test}}
4. {{Rva|Test}}
5. {{Rva|Test.svg}}
6. {{Rva|test.png}}
7. {{Rva|Test.gif}}
8. {{Rva|test.jpg}}

where no value or just the pipe takes the PAGENAME, otherwise the name in parameter 1 whether it has any file extension or none, always with .svg.
I think we offer a bit more comfort if the user does not need to type the redundant ".svg". May be that can be expressed in the error display?
I used Module:File twice, and ucfirst for better cosmetics. I didn't change the other code. sarang♥사랑 19:34, 15 February 2015 (UTC)

I changed the ucfirst: back to PAGENAME:, so inputs like {{Rva|File:Test.svg}} still work too. SiBr₄ (talk) 19:46, 15 February 2015 (UTC)

Good! I forgot this variation. Now it can be added

1. {{Rva|File:Test}}
2. {{Rva|fiLE:test.TiF}}

or    1 = [File:] filename [.any extension] where only filename is case sensitive, except its first letter. Your template accepts every currency! sarang♥사랑

Hi again.

File:Augsburg Tram 6.svg is a vector version of this file. File:Vector version available/Archive 1 → File:Augsburg Tram 6.svg ---- For more information, see Help:SVG. In other languages

 

Some images like GlagolitsaThita.gif want to show that not only one SVG exists, and instead of transcluding VVA twice or more often we may offer to show that in one VVA box - at least one other suggestion. I made a small expansion to allow that, at the moment four more SVGs (can be expanded but I do not think that more are really in need), but I had difficulties with a good looking display. Now it may look like:

Several vector versions of this file are available. File:Vector version available/Archive 1 → File:Augsburg Tram 1.svg File:Augsburg Tram 2.svg File:Augsburg Tram 3.svg ---- For more information, see Help:SVG. In other languages

 

I also adjusted the error text: no extension is required, so it seemed better to change

• Error: No image by that name exists. Please make sure to use the correct format: {{Vector version available|new image name.svg}}.     to
• Error: No SVG image by that name exists. Please make sure to use the correct format: {{Vector version available|new image name}}.

File:Vector version available/Archive 1.svg is a vector version of this file. File:Vector version available/Archive 1 → File:Vector version available/Archive 1.svg ---- For more information, see Help:SVG. In other languages

New SVG image

 

The documentation will get a detailed explanation how the parameter 1 can be provided; only par1 can be empty, other parms need a file name.

The expansion works somehow, we can either look for a better formatting, we can let it poor as it is now, but when you do not like I would nevertheless prefer let the code but won't mention the possibility. sarang♥사랑 10:30, 16 February 2015 (UTC)

The additional files are now listed and displayed underneath the first one, and the message changes to "Several vector versions..." if multiple parameters are present. I'd really set the maximum number of SVGs to 3 at most; I don't think more than that is ever necessary, and larger groups of files are better placed in other_versions. SiBr₄ (talk) 11:55, 17 February 2015 (UTC)

Multi-VVA is apparently Feature_creep, the GIF (or other bitmaps) would normally match only one SVG, and that SVG would normally show its other versions (for small sets of related images, more than ten is better handled by a category or gallery.) –Be..anyone (talk) 13:11, 17 February 2015 (UTC)

Great! Looks good. More than one VVA is very seldom, but it occurs, I saw nowhere more than 1 additionol picture. It is quite enough to display 2 or three, but it does not matter to show more. With two vector versions it looks very good. How about telling "...One of these should...".

Several vector versions of this file are available. File:Vector version available/Archive 1 → File:Augsburg Tram 1.svg File:Augsburg Tram 2.svg ---- For more information, see Help:SVG. In other languages

 

Of course in that test environment the PAGENAME "File:Vector version available" is silly, but that does not disturb, the template is for use in file descriptions. Looks like putting your work into reality soon! If you agree I start with the new documentation. sarang♥사랑 15:02, 17 February 2015 (UTC)

To me "One of these should be used" sounds like "only one (unspecified) SVG version should be used" rather than "either SVG may be used". I reduced the supported number of SVGs to three, since even if four or more vector versions exist and are not mutually redundant, they can be listed as other versions in the information template, where the differences can be explained.

Also, I found a bug: the extension-removing module removes the last period and following text from a string even if it is not a valid file extension. That means filenames with periods in them are wrecked if the extension is not included in the parameter. For example, {{Vector version available/sandbox|Flag of Washington, D.C.}} results in

File:Flag of Washington, D.C.svg is a vector version of this file. File:Vector version available/Archive 1 → File:Flag of Washington, D.C.svg ---- For more information, see Help:SVG. In other languages

 

where it should have linked to File:Flag of Washington, D.C..svg. SiBr₄ (talk) 17:19, 17 February 2015 (UTC)

@SiBr4: The "Either one of these.." sounds a good solution; but the "These ..." version I can live with also.

Three is quite enough!

In the meantime I am thinking the "superseded"-flag would be fine but nobody would use it.

The erorr in the module should be maintained; until that occurs, the docu will tell to give the extension in these cases. sarang♥사랑 17:51, 17 February 2015 (UTC)

I mentioned the case in Module talk:File, let's hope that Rillke will fix it. sarang♥사랑 19:34, 17 February 2015 (UTC)

@Be..anyone and Sarang: I mean I could agree all, but please don't import the /en Sandbox in /de before the main-template is changed as it don't work !! Example! (displays File:File) Don't worry, looking forward, keep working. ↔ User: Perhelion (Commons: = crap?)  16:56, 17 February 2015 (UTC)

It had been never allowed to use the prefix "File:", only the new version will tolerate it. I removed the prefix, now it works (old+new).

It cannot last a too long time until everything is done, I think tomorrow. Anybody knows how to get rid of the protection in a fast way? E.g. some admin friends? Otherwise I will try.

Either we get the protection level lowered, or we must prepare the codes working in the production evironment. sarang♥사랑 17:11, 17 February 2015 (UTC)

Parameters with "File:" prefix are allowed in the current template; it checks for existence of the given file name with and without additional namespace prefix separately. The problem is that these checks are currently in the language subpages, and /sandbox/en doesn't have them (instead the main /sandbox completes the filename if necessary). I re-added some stuff to /de so it works again. SiBr₄ (talk) 17:39, 17 February 2015 (UTC)

Because it will soon be needed I started to adjust the original /doc. Please feel free to correct my poor English, und verbessere die deutsche Beschreibung! Now are just 3 redirects mentioned, and only in the docu. I tried to explain the possibilities how file names are now to be specified.
One thing: is a blue arrow fine? Might be a green one is better? If desired I can create a really fine arrow.
May be a final version of the three new templates should be transfered into User:Sarang/T (it is free for use!) or some similar page, that simplifies the work of the admin. sarang♥사랑 11:35, 18 February 2015 (UTC)

---

{{editprotect}}Please reset for a short time the protection level of {{Vector version available}}, {{Vector version available/layout}} and {{Vector version available/en}} to autoconfirmed. sarang♥사랑 17:34, 17 February 2015 (UTC)

The sources are now ready for replacing in {{Sandbox/vva}}. To mention something technical: When I looked for allowing more files, I thought it better to make the treating for the more files in a separate subtemplate used only when there are more than one file, because this happens but it happens very seldom. In the few cases when it comes to work a lot of processing and all the prepairing can be done by this subtemplate, it won't bother the main templates. Now the processing is included in "layout", and the error processing for the additional files is a bit poor. O.K., this additional option does not need so much attention; it is more a ‹nice to have› than a ‹sine qua non› request. IMHO the new template is not only satisfying, it is an example how other templates should work. sarang♥사랑 20:27, 19 February 2015 (UTC)

I'll look into the errors for non-existing secondary and tertiary files, reincarnating the subtemplate Vector version available/more if beneficial. SiBr₄ (talk) 20:55, 19 February 2015 (UTC)

See it now. An error message is given if at least one of the files does not exist. The main message "... is a vector version..."/"Several vector versions..." is now also displayed in case of an error; that can be easily changed if wanted. I also changed the right-hand thumbnails so each has its own shadow (which is now done by the /more subtemplate).

Several vector versions of this file are available. File:Vector version available/Archive 1 → File:Example.svg File:NonExistingFile.svg File:Test.svg ---- For more information, see Help:SVG. In other languages

New SVG image

 

SiBr₄ (talk) 12:29, 20 February 2015 (UTC)

Display format and error handling is perfect now!

But still one thing I do not like so much: At the moment the main template performs always all the additional invokes. Just realize that < 10 files (of > 63000) will be glad about a second SVG nomination. Therefore I intended just to pass the parameters, later check whether there is any value and then -not earlier- let the /more do its part; depending everything (or as much as possible} of all extra processing if more than one file: checking whether two or three, formatting of display (and errors), and returning it to /layout which will use it instead of the 'standard' output. This strategy will minimize any overhead and avoid completely the complete useless invokings. Sure you can agree? sarang♥사랑 15:54, 20 February 2015 (UTC)

I'm not sure what exact invocations that should be saved you refer to. The /more page was re-purposed to provide the formatting for the thumbnail boxes regardless of the number of SVGs; it no longer contains any existence checks or error messages. If you're referring to the existence checks in /layout, I'm beginning to think it's better to just use the #ifexist parser function. Using the fileExists function of Module:File takes 20–30 ms (as opposed to 7–9 for the parser function) and actually also counts as an expensive parser function instance. If no second or third parameter is provided, the invalid page title "File:" is checked, which using Lua results in a script error after 30–50 ms, and which using #ifexist returns nothing, takes the usual <10 ms and doesn't even count as expensive. SiBr₄ (talk) 20:58, 20 February 2015 (UTC)

This astonishes me, in a bad manner. Sure the parser function and the module are using at one point the same system function to check existence; but when the module is not better or faster or less expensive - what for? The parser function seems easier to use in a template. Looks like that the parser is executed more directly, and in the module case it must be searched, opened by LUA and performed ...

Seems that there is some more work and testing to do ere you make it public. sarang♥사랑 17:11, 22 February 2015 (UTC)

It now uses #ifexist again. I wrapped the second and third parameters in {{Vector version available/sandbox}} in #ifs so they are empty if undefined. The parameters used to default to ".svg", so /layout would check for existence of "File:.svg", which would not be inexpensive. The #ifs also save ~40 ms by not pointlessly executing the woExtension Lua function thrice if only one file is given. SiBr₄ (talk) 13:23, 23 February 2015 (UTC)

@SiBr4: With a workaround-template I could solve the problem with "Flag of Washington, D.C. icon", see {{Vector version available/sandbox}}. sarang♥사랑 13:39, 27 February 2015 (UTC)

I don't particularly like how the filename must be specified twice when using that template. With my very basic Lua knowledge I created an all-in-one module at w:Module:Sandbox/SiBr4; it removes the namespace prefix as well as any valid extension (test here). While the time difference isn't much (38 ms for the template, 28 ms for the module), it greatly reduces several other factors in the parser profiling data. The new module also works for capitalized extensions such as "JPG" and "PNG". SiBr₄ (talk) 15:20, 1 March 2015 (UTC)

Of course that's much better to have an own module specialized for that need! It can be used by other templates as well (e.g. {{Bva}}). You think it better to remove namespaces by the module instead by the PAGENAME construct? I am not so sure there. The workaround template can not only remove the extension but also parse the extension, a very seldom needed function. With the restriction to lower case only... Now you need to define your module, as e.g. Module:IsolateFilename or a better name you prefere. Congratulations! The old template will be replaced soon? BTW, I have not the slightest idea why he has reactivated the old Help:SVG discussion. I am not sure whether he knows by himself. sarang♥사랑 07:25, 2 March 2015 (UTC)

The difference is minimal; removing the namespace using Lua, it takes 10 ms more than with PAGENAME, but the include size reduces from 36 to 16. I put the namespace removal in the new module since it saves some small bits of code in the template.

I created the module at Module:StripFilename. I'll edit the template sandbox in a few hours. SiBr₄ (talk) 11:16, 2 March 2015 (UTC)

Ok, you had good reasons for your decision. I will change the docu, that only namespaces "file" and "image" are ignored. (with PAGENAME every namespace is removed, even so exotic ones as "template" or "user", and all talk namespaces too as long it's English; does not make sense, file and image is quite enough).

Shall I care for an admin to shift the codes? Then it can be done today, most probably. sarang♥사랑 14:43, 2 March 2015 (UTC)

I updated {{Sandbox/vva}} with the new versions of each template; there is a simple trick to copy a page's source code to another page, by substituting the msgnw function. I think it's ready now. (Compare the sandboxes with the live templates using these links: VVA en layout.) SiBr₄ (talk) 13:58, 3 March 2015 (UTC)

I gave it an overview, but rely on your meticulous testing. It looks really good, has a clear structure and will be efficient. The entry pipe trick is ingenious! I will look for a living admin. sarang♥사랑 18:23, 3 March 2015 (UTC)

Sorry, nobody alive this hour. I asked Leyo, sure he will do it soon. sarang♥사랑 18:49, 3 March 2015 (UTC)

Last question @SiBr4: The blue right-arrow looks a bit washed-out (because of gradients that are not visible at this size) and also a bit too down in the line. I tried to make a better one , in green. Please look at the layout! When you agree, I will replace it Because Leyo is now there I changed it; if you disagree another upload can replace the file anytime. BTW, it can be changed later, which is not so preferable with the Gnome icon. sarang♥사랑 06:18, 4 March 2015 (UTC)

I don't mind whether the arrow is blue or green; both look good enough to me. I changed the new arrow to be somewhat darker though (revert if it looks worse). SiBr₄ (talk) 10:20, 4 March 2015 (UTC)

The darker green looks better. Leyo seems to need some persuading... If he doesn't come into motion today I'll ask somebody else. sarang♥사랑

@SiBr4: Leyo hadn't been active yet, so I come back in very last minute to a previuous idea: With a named parameter meaning "supersedes" the /en can react by telling instead of " should be used in place of this raster image when not inferior" something like " is considered a better image and should replace this raster image". Other functions of the template {{Supersedes}} can be included. How about that? It depends only the nationalized subtemplates, but they need the parameter. Shall I stop the Leyo action? sarang♥사랑 13:45, 4 March 2015 (UTC)

File:Augsburg Tram 7.svg is a vector version of this file. File:Vector version available/Archive 1 → File:Augsburg Tram 7.svg ---- For more information, see Help:SVG. In other languages

 

Several vector versions of this file are available. File:Vector version available/Archive 1 → File:Augsburg Tram 8.svg File:Augsburg Tram 9.svg ---- For more information, see Help:SVG. In other languages

 

That would likely lead to disagreements regarding which version is better, I imagine. Doing the opposite (assuming the SVG is superior unless a parameter is set) could also be an option. A question to consider is whether the template should be used at all if the SVG is considered inferior. SiBr₄ (talk) 15:57, 4 March 2015 (UTC)

You are right, this problem exists, of course. It depends on the user setting the tag, either with the template "Supersedes" or with a "Vva" parameter, when he thinks one quality is better than the other. Currently "Vva" is strict neutral, and to express an opinion an additional template is necessary. In both cases the template or the parameter can be removed, causing the removal of the file out from the category. I would like the parameter version more than the insertion of the additional template, because of more comfort, but when you dislike it just forget it. It is just now we have the possibility (until the admin will come into action), and it is easy to expand; the category can be handled in the layout ({{#ifeq:{{NAMESPACE}}|File|[[Category:Vector version available]]{{#if:{{{5|}}}|[[Cat.....]]}}}}). You decide! sarang♥사랑 16:57, 4 March 2015 (UTC)

Even an inferior SVG can be useful. E.g. when used as a very small icon 12×12 px, an image of 200 bytes is sufficient for that special use and you do not need to use the 200 KB version. IMHO it should always be told about the existence of a SVG version, so the user of the picture can decide whether it is appropriate for his intentions or not.
Another thing is when somebody adding the VVA template wants to recommend the use of the SVG, from his point of view. Nowadays the template "Superseded" (and "Supersedes" on the other side) needs to be added to achieve the categorizing; as I thought this can be done as well with a small expansion of VVA, slightly changing the text. Please look at Mplwp logo.png to see better what I am talking of!

Otherwise it can be done with a template stub as {{Vector version supersedes/sandbox}}; just the parameter needs to be passed through. Example:

File:Augsburg Tram 64.svg is a vector version of this file. (reason: I love this image) File:Vector version available/Archive 1 → File:Augsburg Tram 64.svg ---- For more information, see Help:SVG. In other languages

 

sarang♥사랑 10:26, 5 March 2015 (UTC)

"[T]he user of the picture can decide whether it is appropriate" – That was my main objection against a parameter for the quality of the vector version. The person who sees the tag should decide for him-/herself which file to use.

I agree building something into the VVA template is preferable to using both {{VVA}} and {{Superseded}}. In case there are good, objective reasons for one file to be considered better, though, other than the quality (e.g. factual errors in the bitmap version), {{superseded}} is better used on its own than {{VVA}}, since the former includes a parameter to specify the reason for the supersession (which wasn't documented until now). Since SVGs are almost always higher quality than rasters I suggested using a parameter for cases in which the SVG is not better (embedded bitmaps, autotraced, etc.). A maintenance subcategory Inferior vector version available could be created for these cases. Note that Category:Vector version available is a subcategory of Category:Superseded, so they shouldn't be both set.

Regarding the current sandbox, what if multiple SVGs are set and only a subset is superior to the raster? SiBr₄ (talk) 19:40, 6 March 2015 (UTC)

Considering that very very few transclusions will use the multiple SVG option, and that the supersedes option will sure also not be used too often, it is not very likely that both will meet together. When the supersedes parameter is set it is just a note that something can be made, and the categorizing is as well not much more than the expression of an opinion of somebody. Others can decide whether they conclude and will use the SVG file, or one of them if more are mentioned.

If you really believe that it may cause difficulties, then accept the supersedes option only when just one file is specified.

To offer a parameter to qualify the SVG image(s) as either superior or inferior seems to me a good idea. The creation of the text becomes a bit more complicated, and for exotic languages translation help will be needed. I am sure that you are able to keep the clear and straight structure of the templates even when this additions are included. Because I only thought about supersession (=superior), another solution is needed to set either this or the inferior state. Correct categorizing without contradiction will not be a problem. sarang♥사랑 17:49, 8 March 2015 (UTC)

Thinking it over, I got some ideas. The templates can be written to accept and allow everything, not only quality=superior or quality=inferior but also better, high or poor, questionable and also abbreviations of everything, as q=s or qu=p ... But IMHO this comfort can cause troubles e.g. when needing a pattern for VFC; when something is to be told about the quality it should be done with complete parameter name and attributes.

Thus the transclusion {{Vector version available/sandbox|AK Flag Tartan.tif|quality=inferior|reason=embedded raster}} shows

File:AK Flag Tartan.svg is a vector version of this file. (reason: embedded raster) File:Vector version available/Archive 1 → File:AK Flag Tartan.svg ---- For more information, see Help:SVG. In other languages

 

When an image is considered to be in question of course it should always contain more information what's wrong with it.
I made the first changes to the sandbox templates, please check it whether it meets your thoughts. sarang♥사랑 05:05, 9 March 2015 (UTC)

Commons Delinker is a tool causing often troubles; it removes links to files. The tests for file existence are well performed but later any one of the file links can be removed leaving nothing between two "pipe" separators. The template cannot recognize whether this occured later or initial, nor is there any hint which file link has been removed. As long this practice of removals is used the templates will have to deal somehow with vanished links; either with error statements or with trying to function nevertheless as good as possible. To ensure the function also in such a case it seems better to test even for the specification of file1, and to allow e.g. file1 + file3 without file2 specified:

Several vector versions of this file are available. File:Vector version available/Archive 1 → File:Augsburg Tram 1.svg File:Augsburg Tram 3.svg ---- For more information, see Help:SVG. In other languages

 

From the eight possible combinations from 0-0-0 to 1-1-1 the first file will always be inserted when (initial or later) absent, so only four combinations x-0-0 to x-1-1 remain. x-0-0 is the standard case. x-1-0 is two files, x-1-1 is three files defined. Just x-0-1 should work even with the "hole" inbetween. The other possibility is to state an error, as it has been.

I changed the sandbox to handle that. By testing whether specified the ifexist is now only performed when an entry exists. BTW, string is a mighty help, but AFAIK the padleft function is less expensive and is in this situation equivalent. sarang♥사랑 13:29, 10 March 2015 (UTC)

• Regarding the quality option: I'm still not sure how good an idea it is. Should eventually all files be marked as either "good" or "bad", so that the default state would only be for files not yet assessed? Would it be disallowed/discouraged for the vectorizer to mark his/her own file as "good" while placing the template on the bitmap file page?

  It is just an option, allowing helpful hints if used, and causing possibly confusion if misused. Nevertheless it can be helpful, and the category (or categories) can be checked for correct usage. I am expecting it to be used rather seldom, but it will allow to be used by another template like {{vector version superior}} or {{vector version inferior}} (vvs or vvi) if somebody thinks we need such templates. Therefore I am thinking any abbreviation (like q=s) is not necessary.

• Would it be an idea to only omit "when not inferior" in the "good" message? Explicitly stating a file has a "better quality" implies it has had a full review or something like that. Also, the current message for "bad" files says "it should be used in place of this raster image but it is of questionable quality", i.e. it should be used even though it's bad – that should probably be changed as well.

  Instead of "should" I intended to use "could", it was not done yet. In the example below for unnested text it is now included.

• I agree regarding the "holes". CommonsDelinker can still break the template by removing the first file, since that will fill in the transcluding page's name rather than being treated as empty, though I guess we can't do much about that.

  The removal of the first file can cause either an error (does not exist), or nomination of an unwanted file (rather very improbable) or it is just removing a superfluous specification.

  Delinking 2^nd and/or 3^rd files are helpful, because they don't exist. Only the file history can tell whether a hole was drilled initially or later.

SiBr₄ (talk) 22:02, 10 March 2015 (UTC) -- I inserted my comment above sarang♥사랑 09:45, 11 March 2015 (UTC)

I changed /sandbox/en after my suggestion, and added a |reason= parameter that I think is necessary, were the quality option to stay:

File:Example.svg is a vector version of this file. (reason: embedded raster graphics) File:Vector version available/Archive 1 → File:Example.svg ---- For more information, see Help:SVG. In other languages

 

File:Example.svg is a vector version of this file. (reason: it uses the correct colors) File:Vector version available/Archive 1 → File:Example.svg ---- For more information, see Help:SVG. In other languages

 

Regarding the needed translations: that was already a problem because the |imageDoesNotExist= parameter is new. I solved that earlier by including a brief English fallback message "Image does not exist" in /layout. The same could be done for the quality parameters, though that would require that the /language subpages use different parameters for each message, as opposed to using switches within the |imageExists= parameter (like /sandbox/en does now). Ideally, /language pages should include as few switches as possible anyway. SiBr₄ (talk) 11:48, 11 March 2015 (UTC)

My full agreement that /language pages should be as simple as possible. At the moment I do not understand why "the /language subpages use different parameters for each message"; anyway the reason makes problems: when not restricted to a very small set of reasons that can be preallocated with LangSwitch and needs to use the keywords (this will never function), some free text remains untranslated, hopefully not in some Bangladeshi idiom. It might be better only to declare the super/inferiority, and expect that the other file may contain some explications whats good or wrong. The offering of this parameter is a good idea, but it should be used sparingly and wise. I am still assuming that quality will be used seldom, and reason seldomer.

Mainly it will be like with Superseded, which is used by SupersededPNG, SupersededSVG and SupersededMIDI; it depends on these templates to prepare a good reason text. The three over-templates guarantee a certain conformity, but using the parameter individually opens the gates of the hell; I believe that might have been the reason why it wasn't documented! Let me recommend to see it this way, and don't think about it too much - you offer it but you cannot influence its use. sarang♥사랑 17:40, 11 March 2015 (UTC)

I meant that fallback messages in /layout are not possible unless /language pages (currently only /sandbox/en) include separate parameters for each message; e.g. |imageInferior=It has been marked.... Currently, the quality parameter would be completely ignored in languages other than English. (Thinking of it, the new categories such as Category:Superior vector version available wouldn't be set if using a language whose template subpage doesn't yet pass through the new parameters, so wouldn't that mean a page's categorization depends on the language set by the viewer?)

Currently about 1,300 file pages use {{Superseded}} (not including its redirects) with second parameter, despite it never having been mentioned in the documentation; hardly any values for the reason on those pages are in languages other than English. Of course it's a problem that custom reasons are not translated, and some may add them in exotic languages, but I think being able to specify why one file should (not) be used instead of another is crucial if you let people declare a file "superior" or "inferior". Differences other than the resolution are not always obvious from a 150x150px thumbnail. I don't think a manageably small set of predefined, translated reasons would be sufficient in all cases. SiBr₄ (talk) 20:11, 11 March 2015 (UTC)

To keep /language pages simple: They get the parameters #1 to #6 and pass them to /layout. Changing the parameter name from 4 to n seems a minor but avoidable complication.

Suggestion:

• Pass the number to /language, then it needs only to check the value whether > 1 but nothing else but don't pass it from there to /layout; this minor test is easy to make there.
• Another possibility is to prepare (1) imageExists (2) imageDoesNotExist (3) imagesExist (4) imagesDontExist. Then only /layout and no other template needs to care about the number. At the moment the /language pages provide only (1), fallbacks are necessary for the other text tokens until all pages are maintained. This seems to me the best way to simplify logical needs for the /language pages, and the system is somehow kept running even when not maintained.

For checking reasons I replaced the Plural in /layout. It is now rather simpler. As a consequence parameter #5 and #6 should become #4 and #5. sarang♥사랑 13:08, 12 March 2015 (UTC)

National versions

There are 50 "localized" templates, and they all will need to be maintained. There are different cases:

1. File ... should be used ... if not inferior
2. File ... should be used ... it is superior
3. File ... could be used ... but is inferior
4. Several ... should be used ... if not inferior
5. SVG image does not exist
6. Not all of these images exist

+ 2 more if quality can mentioned also for more files - IMHO not recommended

Because some of the localized versions must be edited by people knowing the language but not extremly intimate with this template it should be easy to them, and the text to be generated should not be too nested.

An extremly easy text arrangement may look like

{{Vector version available/sandbox/layout
|1={{{1<noinclude>|Example.svg</noinclude>}}}
|2={{{2|}}}
|3={{{3|}}}
|4={{{4|}}}
|imageExists=[[:File:{{{1}}}]] is a vector version of this file. It should be used in place of this raster image when not inferior.
|superiorExists=[[:File:{{{1}}}]] is a vector version of this file. It should be used in place of this raster image{{{5|}}}}.
|inferiorExists=[[:File:{{{1}}}]] is a vector version of this file. It has been marked as inferior to this raster image{{{5|}}}}.
|imagesExist=Several vector versions of this file are available. These should be used in place of this raster image when not inferior.
|imageDoesNotExist=Error: No SVG image by that name exists. Please make sure to use the correct format: {{tlp|Vector version available|''new image name''}}.
|imagesDontExist=Error: Not all of these images exist.
|moreInfo=For more information, see [[Help:SVG]].
|svgImageLabel=New SVG image
|lang=en
}}

This example shows the avoidance of any conditional coding. Instead it provides eight parameters; to avoid any ifs the text strings are double and triple defined. The template receives parameters #1 to #5; parameters #1 to #4 are passed to /layout, where the decision about #4=quality can occur. The reason parameter #5, if any, is taken as-it-is, the user (or the over-template) setting it has to care for formatting, punctuation and/or spacing, and may also care for multi language solutions.
While not all /language pages are maintained, /layout gets from them just parameter #1 and three of the text parameters. With that it will work just as before, no error occurs. Any 2^nd and 3^rd file is ignored, quality and reason are not supported.
The parameters moreInfo and svgImageLabel are also candidates for a langsw solution, this might be better and more up-to-date than passing the parameters. sarang♥사랑 14:08, 13 March 2015 (UTC)

A similar suggestion is now at the sandbox. To avoid the double/triple repetitions of text, I divided the main message between a common |imageExists=... is a vector version of this file, and the varying remaining parts. For the same reason I kept the PLURALs for now; I think they have easily enough understood purposes to stay, and avoid us having to add three separate parameters with in one case only one word different.

The #ifs for the "(reason: )" part will be harder to get rid of. I'm trying to find a way to move the #ifs to either other template while keeping the text itself at /language for translation. SiBr₄ (talk) 20:09, 13 March 2015 (UTC)

Of course the extreme simplification is much too extreme, I just gave it a try how it would look without any conditions. The #ifs for reason are easily avoidable if you delegate the formatting etc. to the invoker, whether a mortal user or another template. I rather think it will hardly ever be supported individually, if there are templates with some built-in reasons. And when somebody thinks she wants to specify an own reason for herself she should care for the format. No template can foresee what kind of text the users want to show, and when no formatting is done users can enjoy all freedom; instead of being pressed between two brackets.

I made it this way with the more text for {{Created with}}. It is at the end of the standard text defaulted with a full stop, it needs to start with the "<nowiki/> " sequence or a punctuation and has to contain the final full stop. It is seldom used. For an example, there is specified "more=: animated SVG". When you too think that this will be sufficient it reduces the problems. Instead of reason you can call it also more, because it can be used for everything else too, and not only when a quality is specified.

You know that the templates you are now finishing will be an example for some other templates, as {{Bitmap version available}}, {{Supersedes}}, {{Superseded}} and others of this kind. They all may use the /more template therefore it should finally get another name, more neutral, e.g. something with file and display. But that's not essential. sarang♥사랑 18:04, 14 March 2015 (UTC)

Now the custom reason is set by /layout and is no longer part of the superior/inferior message, so it can be used without the quality parameter set. The code is a lot better that way. The reason is still marked with brackets/italics and a translatable "reason:" to clarify it is a custom addition rather than part of the template message.

File:Example.svg is a vector version of this file. (reason: Lorem ipsum dolor sit amet) File:Vector version available/Archive 1 → File:Example.svg ---- For more information, see Help:SVG. In other languages

 

SiBr₄ (talk) 19:06, 14 March 2015 (UTC)

Yes, that's better to keep quality and reason independent from each other. Be..anyone becomes inpatient with his desired update, seems better to come to an end within the next days. sarang♥사랑 08:53, 15 March 2015 (UTC)

Performance check

@Sarang and SiBr4: Hey guys, I've not completely read all the huge text here, but let me give a feedback. I'm not sure to put that many functionality all together, especially more than one file. I mean include this template twice or 3 times (I never seen a need before and I mean this should also not a common good procedure) should not that problem. If this really happen than I would prefer an option to make the other template smaller or nondescript, that would also solve the now existing unsolved problems. But in the other hand I can live with it. ^^

Another point: As we can see now under COM:T the template inclusion is not working correctly, because due the parser-limit on this page. So I suggest to put all ifexist in the main-template and made an 7. parameter like : |7={{#ifeq:{{#ifexist:File:{{{1|<noinclude>Example.svg</noinclude>}}}|1|0}}{{#if:{{{2|}}}|{{#ifexist:File:{{{2}}}|1|0}}|1}}{{#if:{{{3|}}}|{{#ifexist:File:{{{3}}}|1|0}}|1}}|111|1|}} In the other hand, we could let the Error on this page. PS: I've set the layout in HTML for parser reason and more clearer code. ↔ User: Perhelion (Commons: = crap?)  16:27, 21 March 2015 (UTC)

Sorry, I do not understand what's on. All the three #ifexist are only in the main template; the possibility to specify more files is seldom used but helpful when there is no need anymore for multiple transclusions. I do not know about unsolved problems. And the function and advantage of the 7^th parameter is a riddle for me. The template is optimized for usage in many thousand files, and not for an explanation in COM:T. sarang♥사랑 16:53, 21 March 2015 (UTC)

As we can see my idea is working: User:Perhelion/sandbox#footer additional parameters get automatically added if the ext.translation is installed, so the next step is to install this. ↔ User: Perhelion (Commons: = crap?)  17:03, 21 March 2015 (UTC)

I mean /layout is not the main template, what is then "Vector version available/sandbox"!? Yes the 7. parameter is not that lucky but has no performance lost.

@"I do not know about unsolved problems." I mean the "quality" (and "reason") is only working for one file!? ↔ User: Perhelion (Commons: = crap?)  17:21, 21 March 2015 (UTC)

All in all it looks good.

@ifexist: a small improvement: As you said if parameter 1 is left the error occurs always, so the check must like this (all in the first check): {{#ifexist:File:{{{1|<noinclude>Example.svg</noinclude>}}}|1{{#if:{{{2|}}}|{{#ifexist:File:{{{2}}}|1|}}|1}}{{#if:{{{3|}}}|{{#ifexist:File:{{{3}}}|1|}}|1}}|}} ↔ User: Perhelion (Commons: = crap?)  18:14, 21 March 2015 (UTC)

Sorry, I remembered the wrong way, #ifexist's are in /layout, you are right. But what is the difference whether in main or in /layout, it has to occur and it should be only once, I cannot see an advantage.

Yes, "quality" and "reason" works only when one file. More files will always have different qualities, and this will become much to complicated for the template and for the user. More files are seldom, and when there really quality is needed for more files then use the template for each one and specify the reason for each one. The "more files" option is nice to use, but IMHO is no need to combine more & quality.

Dear Perhelion, the discussion had been open for weeks and for everybody, your suggestions had been welcome. The decisions had to be made; the template works good and fulfils all known requests plus some future wishes; I cannot see the need to change something. There is enough else to do! The next challenges are {{Bitmap version available}}, {{Supersedes}} and {{Superseded}} just to mention some. You are invited to contribute your ideas. sarang♥사랑 18:01, 21 March 2015 (UTC)

Ok, then we forget the 7. parameter. I try another solution for COM:T. Its was only an idea. Keep working, have a nice weekend. ↔ User: Perhelion (Commons: = crap?)  18:22, 21 March 2015 (UTC)

The #ifexist you suggest can't be performed like that. Therefore in the main template the objects are determined, by i.e. removing name space, replacing extension and, for the first file, assuming the file name when absent. This is passed via /language to /layout, and there the check is easy. Performing the existence check in the main template would have been a complicated nested code much more difficult to read and to maintain. Instead of {{#ifexist:File:{{{2}}}| it would have to be {{#ifexist:File:{{#invoke:StripFilename|main|{{{2}}}}}.svg}}|, and more complicated for File1. As another consequence the invoke would have to be performed once for the existence and a second time for passing the value - twice for each file. sarang♥사랑 18:35, 21 March 2015 (UTC)

The reason parameter works fine for multiple files:

Several vector versions of this file are available. (reason: Example.svg is superior because X; Test.svg is inferior because Y) File:Vector version available/Archive 1 → File:Example.svg File:Test.svg For more information, see Help:SVG. In other languages

 

The quality parameter doesn't, though. We could add "quality2" and "quality3" options, but that would make the templates a lot more difficult, and details on which of multiple files to use and why can be given with the reason parameter, like above. SiBr₄ (talk) 20:10, 21 March 2015 (UTC)

It is fine like that, more than sufficient. Until now the 63000 transclusions worked without the new helpful options; in some cases their afterward introduction is advised. When wishes and new needs may come up by the time it can be thought how to meet them. For the moment everything that should work is working. Some old errors are now coming up:

• often parameter 2 contains some explanatory text - it had been ignored, now it is interpretet as file 2 resulting an error.
• often meanwhile deleted files are mentioned, without common delinking; only solution is removal of the template.
• hundreds of files nominated a SVG version not yet existing — Preceding unsigned comment added by Sarang (talk • contribs)

I ran AWB over the contents of the error category some days ago to fix them (adding "|reason=" where a reason had been given as second param, removing links to deleted files, changing the template to {{Superseded}} where a bitmap had been specified, etc.). I could do that again now that more files have shown up in the category. SiBr₄ (talk) 12:29, 22 March 2015 (UTC)

While walking through the files in the error category, I found a problem with the template's transclusion on File:Cusitas.png. The linked SVG file, File:Cushitic languages.SVG, has an uppercase "SVG" extension, which is changed to "svg" by the template, resulting in a does-not-exist error. As a workaround I created File:Cushitic languages.svg as a redirect. SiBr₄ (talk) 13:57, 22 March 2015 (UTC)

I think we should also remove this extension feature, this is also not suggestive and not really helpful in all. ↔ User: Perhelion (Commons: = crap?)  14:02, 22 March 2015 (UTC)

In my opinion for uppercase .SVG either a redirect or a rename is a good answer; to me it seems an unwanted variation. It does not disturb in most cases, but it is of no use and causes handling problems with templates like that one. sarang♥사랑 15:38, 22 March 2015 (UTC)

Of the eight permutations from .svg to .SVG only the first one should be used, the others are deprecated. I created for test Sample.SvG as a redirect to Sample.svg, the six remaining possibilities don't exist: Sample.svG, Sample.sVg, Sample.sVG, Sample.Svg, Sample.SVg, Sample.SVG.

It would be no technical problem to change the template for these rare cases that it won't change such a permutation to the standard ".svg" and accept instead such a value of the parameter. But IMHO the use of permutations should not be supported. When a drastic rename is not advised a swift redirect will meet this problem whenever it occurs. sarang♥사랑 05:53, 24 March 2015 (UTC)

If this is true, go on (I personally be not sure here, I thought SVG uppercase is also ok, simply because the upload-software allowed it). ↔ User: Perhelion (Commons: = crap?)  08:39, 24 March 2015 (UTC)

For reference, these are all lowercase-extension redirects I created to circumvent this problem. SiBr₄ (talk) 21:27, 25 March 2015 (UTC)

@COM:T: I've another objective suggestion, due the defect of the only one of all COM:T. I see Sarang has tried again a display there (but he seems not fully understand what happens, as I mentioned the talk page for the Lua error). The point is the "Commons-Delinker" support, which is to much in all (if we remove this the template works there as expected, very probable we also save a ifeq). Because so we can made the valid display as default and the "error" as secondary query (which not appears on parser stop). Let see the situation, is this "Commons-Delinker" support really needed?? Which template has this too? Is this not a scenario what happens very rare, maybe one times in one year!? Anyway when this really happen, everyone can simple fix this and maybe also about the error-cate. Bots should fix templates not vice versa (as we go "The template is optimized for usage in many thousand files"). So decide what is better, a defective permanent (docu-) representation for all or a possible error that will make itself almost never noticeable. Btw: you have done a great work. Regards ↔ User: Perhelion (Commons: = crap?)  13:30, 22 March 2015 (UTC)

Again difficulties to understand - what is the commons delinker support ? sarang♥사랑 15:38, 22 March 2015 (UTC)

I mean your 1-1-1. Maybe I should write my suggestion first in the sandbox to be more clear. ↔ User: Perhelion (Commons: = crap?)  19:45, 22 March 2015 (UTC)

Inserting the template transclusion into COM:T is without any chance, the page has too many expensive parser function calls, and that one more is not served. As a workaround I made an image of the template's output to display it there, to avoid the #ifexist. sarang♥사랑 13:13, 23 March 2015 (UTC)

Come on sarang (keep calm ;)) there are possible solutions (as I said, ok one additional check, but this check should never be normal used on file use). So I show your simply what I meant in the Sandbox. I also not understand fully why you removed the full normal name of vva there (and also substituted the Superseded template)!? But if not agree it is ok, you current solution is good anyhow. See you later.

PS: What about to mention a user-script in the docu, which add this template "automatically" (possible prefilled with file exiting check, and remove the same time all other existing svg/vva templates)!? ↔ User: Perhelion (Commons: = crap?)  10:02, 24 March 2015 (UTC)

So you want to "save" an almost-harmless #ifeq, while adding an expensive fourth #ifexist just to avoid a template error at one page (an error that, ironically, is a result of the page already using too many expensive parser functions)? Not that one more #ifexist would cause major problems on other pages, but what I think should be done at Commons:Templates is reducing the number of expensive functions to less than the MediaWiki limit of 500. This can be done either by splitting the list onto multiple pages, or by finding out which of the 64 listed templates use excessively many expensive functions and changing these templates (there must be some that use over a dozen of them). SiBr₄ (talk) 21:27, 25 March 2015 (UTC)

 Done OK yes we forget this COM:T thing, I was just wondering that this template is the only one not working there. Sorry ↔ User: Perhelion (Commons: = crap?)  22:40, 25 March 2015 (UTC)

The templates embedded on Commons:Templates that use the most expensive parser functions are {{Picture of the day}} (94, embedded twice), {{Redeye/en}} (403) and {{Move}} (406). The ridiculously high numbers for the latter two (each is close to crossing the 500 limit by itself) seem to be due to checks for existence of template subpages for each possible language code using #ifexist, by a function of Module:Languages strangely named "langLinksNonExpensive". The source of most #ifexists used by the PotD template is Template:Picture of the day/desc. Something should really be changed at those pages. SiBr₄ (talk) 12:26, 26 March 2015 (UTC)

Too many redirects

{{Vector version available}} ( prot. 63 081 times, currently more than 92K ) is redirected by

Redirect	2015-02-17	now
{{SupersededSVG}} prot.	10 426×
{{Vva}} prot.	15 435×
{{NowSVG}}	1 830×
{{SVG available}}	943×
{{Svg available}} 0	454×	113
{{Vectorversionavailable}}	34×	0×
{{Vector available}}	72×	0×
{{SVG version available}}	12×	191
{{JetztAuchSVG}}	0×	0×
{{Nous avons aussi SVG}}	0×	0×
{{VVA}}	0×	~2K
{{Converted to SVG}}	0×	0×
User:Alkab/SVG	0×	0×
{{SVG版利用可能}}	new	0×
{{Достъпна векторна версия}}	new	0×

IMHO "SVG available" or "SVG version available" are good names, while "vectorversionavailable" is horrible...
Transclusions of "svg available" I would change to "SVG available".
The name "SupersededSVG" tries to express another fact than "available" (in my understanding it should be used for SVG files where a better version exists - I did not find that), but it is used very often.
BTW, "vva" is the complement to "bva" (our next workshop!). sarang♥사랑 15:40, 17 February 2015 (UTC)

Keep {{Svg available}} as plausible {{lc:{{SVG available}}}} alias and decree victory on this front with a {{speedy|unused unintuitive obsolete alias of {{Vva}}}} for {{Vectorversionavailable}}, {{Vector available}}, and {{SVG version available}}. Or let those three redirects rot in peace, they cause no harm. –Be..anyone (talk) 05:47, 18 February 2015 (UTC)

Too late, soon after your remark the deletion occurred. Of course there is neither harm nor danger by this flood of redirects, but now it is easier to overview? I am sure, soon people will create again plenty of redirects... sarang♥사랑 12:13, 18 February 2015 (UTC)

@Be..anyone: , die DR Diskussion für {{Svg available}} ist eröffnet, damit du argumentieren kannst. Du kannst ja auch noch Mitstreiter mobilisieren, dann verbessert sich die Aussicht. sarang♥사랑 11:48, 19 February 2015 (UTC)

Translations

Language	Status
Alemannisch	Updated using English placeholders
Arabic	Done (created after change)
Belarusian (Taraškievica orthography)	Done
Bengali	Done
Catalan	Done
Chechen	Updated using English placeholders
Czech	Done
Danish	Updated using English placeholders
German	Done
Greek	Updated using English placeholders
English	Done
Spanish	Done
Estonian	Updated using English placeholders
Basque	Done
Persian
Finnish	Done
French	Done
Frisian	Done (created after change)
Galician	Done
Hebrew	Updated using English placeholders
Croatian	Updated using English placeholders
Hungarian	Done ()
Armenian	Updated using English placeholders
Italian
Japanese	Done
Georgian	Updated using English placeholders
Korean	Done
Lithuanian	Updated using English placeholders
Macedonian
Malayalam
Malay	Updated using English placeholders
Low German
Dutch	Done
Norwegian Nynorsk
Norwegian (bokmål)
Occitan
Polish
Portuguese	Sandbox exists
Brazilian Portuguese
Romanian
Russian
Slovak
Slovenian	Updated using English placeholders
Serbian
Swedish
Thai
Turkish
Ukrainian
Venetian
Vietnamese
Chinese	Redirect to zh-hans
Chinese (China)	Redirect to zh-hans
Simplified Chinese	Done
Traditional Chinese	Done
Chinese (Malaysia)	Redirect to zh-hans
Chinese (Taiwan)	Redirect to zh-hant

Now that the changes to the template have been made, the many translations need to be updated with the new options. The English subpage was changed together with the template; I've done the Dutch one. Other translations can be based on those versions, and the existing translations. SiBr₄ (talk) 12:56, 18 March 2015 (UTC)

I do suggest to implement the Autotranslate #Translate Extension for this!? ↔ User: Perhelion (Commons: = crap?)  13:49, 18 March 2015 (UTC)

@Perhelion: It looks like that would make translating somewhat easier for those unfamiliar with template code, but would require moving and editing all 50+ subpages in order to make the extension work, and making sure the template still works in the meantime. I doubt whether it's worth it, though maybe it is. SiBr₄ (talk) 22:44, 20 March 2015 (UTC)

That would make all a lot easier (also for people with code knowledge). The subpages get all created and maintained by a bot. And if it's once installed, an future code updated for each get very simple. ↔ User: Perhelion (Commons: = crap?)  23:54, 20 March 2015 (UTC)

The problem is, the subpages already exist. Do you mean they should be recreated from scratch as subpages of /i18n and the originals deleted? SiBr₄ (talk) 20:22, 21 March 2015 (UTC).

The ext. will support this, as we can see here mw:Help:Extension:Translate/Page translation administration #Migrating to page translation. Maybe we can invite some experienced translation admin in here. ↔ User: Perhelion (Commons: = crap?)  14:11, 22 March 2015 (UTC)

Bug report (resolved)

@Sarang, SiBr4, and Perhelion: Hi, {{vva|Beispiel.SVG}} renders Beispiel-SVG.svg instead of Beispiel.SVG. Please get rid of the "extension guessing" games, just take whatever is specified verbatim, and show an error if it doesn't exist. Or take whatever is specified verbatim, if it doesn't exist try specified + .svg (lower case), and if that also doesn't exist give up and show an error, red, blinking, ugly, automatically blocking the user, and rebooting commons. –Be..anyone (talk) 04:57, 28 March 2015 (UTC)

Update: I've restored the 2013 variant as {{Vector version available/old}}, that's based on the current version for the auto-translation business, but avoids the string module overhead. Works like a charme, but of course without the new error tracking. For now {{NowSVG}} is a redirect to the unprotected /old. Maybe use a similar unprotected /new to fix the protected thing. –Be..anyone (talk) 05:29, 28 March 2015 (UTC)

When this is becoming a real problem it can be met. In the following citation I underlined my contribution from March 24:

While walking through the files in the error category, I found a problem with the template's transclusion on File:Cusitas.png. The linked SVG file, File:Cushitic languages.SVG, has an uppercase "SVG" extension, which is changed to "svg" by the template, resulting in a does-not-exist error. As a workaround I created File:Cushitic languages.svg as a redirect. SiBr₄ 13:57, 22 March 2015

I think we should also remove this extension feature, this is also not suggestive and not really helpful in all. Perhelion 14:02, 22 March 2015

In my opinion for uppercase .SVG either a redirect or a rename is a good answer; to me it seems an unwanted variation. It does not disturb in most cases, but it is of no use and causes handling problems with templates like that one. sarang 15:38, 22 March 2015

Of the eight permutations from .svg to .SVG only the first one should be used, the others are deprecated. I created for test Sample.SvG as a redirect to Sample.svg, the six remaining possibilities don't exist: Sample.svG, Sample.sVg, Sample.sVG, Sample.Svg, Sample.SVg, Sample.SVG.

It would be no technical problem to change the template for these rare cases that it won't change such a permutation to the standard ".svg" and accept instead such a value of the parameter. But IMHO the use of permutations should not be supported. When a drastic rename is not advised a swift redirect will meet this problem whenever it occurs. sarang 05:53, 24 March 2015

If this is true, go on (I personally be not sure here, I thought SVG uppercase is also ok, simply because the upload-software allowed it) Perhelion 08:39, 24 March 2015

For reference, these are all lowercase-extension redirects I created to circumvent this problem. SiBr₄ 21:27, 25 March 2015

Obviously the problem occurs just in 15 to 20 cases of ~ 63 000. One solution for the very rare cases where an exotic extension must be served the template can be expanded, e.g. changing the final "svg" in {{Autotranslate |1={{#invoke:StripFilename|main|{{#if:{{{1<includeonly>|</includeonly>}}}|{{{1|Example}}}|{{PAGENAME}}}}}}.svg to {{{extension|svg}}}. With this workaround the default "svg" (for the first file) can be overwritten with every desired string of text.

@Be..anyone: Please take another name and do not use {{NowSVG}} for your tests! They cause numerous errors because {{Vector version available/old}} does not contain the advantages of the now available template. sarang♥사랑 08:13, 28 March 2015 (UTC)

This bug is now fixed in the sandbox version:

Several vector versions of this file are available. File:Vector version available/Archive 1 → File:Beispiel-SVG.svg File:Beispiel.SVG ---- For more information, see Help:SVG. In other languages

 

One more thing I think we should consider changing is that the template currently always replaces any file extension by "svg". Maybe it could only do that if the first parameter is undefined, and somehow return an error if a non-SVG is explicitly specified.

Also, I've seen several files in the error category (File:Cancer biomarker figure.png, File:Phonetic and phonemic transcriptions of audio record of Received Pronunciation.jpg and File:Excerpt from CDC 2003 Table 1.png) that tried to link to a PDF file containing vector image data. I changed {{VVA}} to {{Superseded}} in these few cases, though would it be reasonable for the VVA template to support PDF files as well as SVGs? SiBr₄ (talk) 12:29, 28 March 2015 (UTC)

My opinion (other users may think that this all was nonsense) is that VVA should only link to vector versions, and to nothing else.

The automatic extension replace will be helpful in most cases; an intentional not-svg extension will be very seldom and is IMHO an error. The automatic replacement will normally build an undefinded file name and maintainance can occur.

I am still thinking that upper case or mixed case extensions need not to be served by this template. The named file Beispiel.SVG is nowhere used, and I do not believe that there are more cases where a simple rename of a wrong-named file makes troubles.

You made your fixes in the module which is not pretected. When you perform it by the main function nothing else must be done! The current main function can be kept with another function name. With a slight update of the docu (module and template) everything is done. sarang♥사랑 16:31, 28 March 2015 (UTC)

Arguably, the PDFs are vector versions of the above files.

I didn't only change the module; to move the test live, the main template will need to be updated to not add ".svg" to each file name, since the new Lua function now does that. The "main" function is better kept, for use in other templates and pages. SiBr₄ (talk) 16:58, 28 March 2015 (UTC)

Unbreak now, that's the same bug, still showing an unrelated SVG beispiel.svg instead of exactly one specified beispiel.SVG. The layout permitting two "available" SVGs instead of only one is nice, but it should show only one SVG as specified. If users actually want two SVGs for some reason they should say so, explicitly. Otherwise you created an obscure attack vector, where folks could play games with svg svG sVg Svg SVg SvG sVG SVG. Conflicts about slightly different political maps or (shudder) slightly different flags / CoAs exist, they don't need a new "pointy upload" feature (even bypassing page protection.) –Be..anyone (talk) 06:22, 8 May 2015 (UTC)

Steinsplitter, would you be willing to make the main Template:Vector version available use the "svg" Lua function instead of "main" and remove the explicit ".svg" extension, as shown in this diff (disregarding the difference in the documentation template)? That fixes the problem with capitalized extensions described in this section. SiBr₄ (talk) 18:36, 8 May 2015 (UTC)

Sure :-) Done. --Steinsplitter (talk) 19:02, 8 May 2015 (UTC)

Thanks. The change that makes sure the capitalization of the "SVG" extension is preserved is now live:

File:Beispiel.SVG is a vector version of this file. File:Vector version available/Archive 1 → File:Beispiel.SVG For more information, see Help:SVG. In other languages

 

@Be..anyone: I don't understand most of your comment, unfortunately. Are you suggesting files with nonstandard extension capitalizations shouldn't be shown at all? SiBr₄ (talk) 21:40, 8 May 2015 (UTC)

File:Beispiel.png is good now, {{NowSVG|Beispiel.SVG}} shows the wanted SVG, not something else, thanks. Be..anyone (talk) 05:34, 8 April 2016 (UTC)

Related issue

Not really a bug but an ugly format:

File:Coa Hungary County Veszprém (history).svg is a vector version of this file. File:Vector version available/Archive 1 → File:Coa Hungary County Veszprém (history).svg For more information, see Help:SVG. In other languages

 

The module should replace understrokes by spaces, like the PAGENAME: would do. sarang♥사랑 18:00, 7 April 2015 (UTC)

PAGENAME url-decoding underscores is new for me, but apparently it does. I added the feature to the "svg" function used by the sandbox:

File:Coa Hungary County Veszprém (history).svg is a vector version of this file. File:Vector version available/Archive 1 → File:Coa Hungary County Veszprém (history).svg ---- For more information, see Help:SVG. In other languages

 

SiBr₄ (talk) 19:33, 7 April 2015 (UTC)

I don't think this will work for PDF files.

Is there any way to replace the words "raster image" with "PDF file"? I don't think PDFs count as raster images. Dustin (talk) 00:40, 30 April 2015 (UTC)

A PDF document may include either raster or vector graphics (or just text). If a PDF with a raster image is superseded by an SVG, this template's wording suffices. If a PDF with a vector image is superseded by an SVG, use {{Superseded}} instead. SiBr₄ (talk) 12:06, 2 May 2015 (UTC)

Hm* I use anyway VVA for PDF because as we can see PDF get rendered as JPEG... But anyway, there would be a easy way to insert dynamically the exact current file extension. ↔ User: Perhelion (Commons: = crap?)  16:18, 22 June 2015 (UTC)

There is. The problem is that, in cases like that, the SVG is not really a "vector version of this file" because the PDF contains vector graphics as much as the SVG does. I did not know about the artifacts added by MediaWiki in the rasterization of vector PDFs. SiBr₄ (talk) 17:55, 22 June 2015 (UTC)

Ok, I think you are right to use the {{superseded}} instead for this, but this text "vector version of this file" could also be replaced by "SVG version of this file"!? ↔ User: Perhelion (Commons: = crap?)  22:56, 22 June 2015 (UTC)

Is it a bug or is it a feature?

What I see is "1. REDIRECTTemplate:Clear" displayed in every box lately? Any idea? -- MaxxL - talk 18:23, 9 November 2015 (UTC)

This edit created a double redirect from {{Clr}} to Template:{{Vector version available/Archive 1}} to {{Clear}}, causing all 160,000 usages of Clr to break. Jarekt, could you fix this by redirecting Clr to Clear? SiBr₄ (talk) 19:35, 9 November 2015 (UTC)

 Done --Jarekt (talk) 19:52, 9 November 2015 (UTC)

@Jarekt: Sorry, but you didn't. Please edit Template:Clr to point directly to Template:Clear to fix the double redirect. SiBr₄ (talk) 20:01, 9 November 2015 (UTC)

That was strange: That tab was still saving the page. I saved it in a different tab. --Jarekt (talk) 20:16, 9 November 2015 (UTC)

Add id (edit request)

{{Edit request}} Please made this /sandbox version live. As similar with other templates, for possible script and bot work an id is necessary to easy identify data. ↔ User: Perhelion 08:44, 9 May 2016 (UTC)

 Done Awesome! Thank you! ~riley (talk) 17:18, 18 May 2016 (UTC)

Lang switch treatment

Because I missed this possibility I added now the option to specify a language <switch> for the SVG file: By simply using the parameter "lang=xx" the xx-language version of the file is displayed, and it is also shown right of the file name. Moreover, it is possible to display different language versions (up to three) of one file, if this should become ever useful.

It may look like

File:Gerrit patchset 25838 test.svg is a vector version of this file. File:Vector version available/Archive 1 → File:Gerrit patchset 25838 test.svg | lang=de  ---- For more information, see Help:SVG. In other languages

 

and with more SVG files

Several vector versions of this file are available. File:Vector version available/Archive 1 → File:Gerrit patchset 25838 test.svg | lang=es File:Gerrit patchset 25838 test.svg | lang=fr File:Gerrit patchset 25838 test.svg | lang=it ---- For more information, see Help:SVG. In other languages

 

while the standard format is still

File:Gerrit patchset 25838 test.svg is a vector version of this file. File:Vector version available/Archive 1 → File:Gerrit patchset 25838 test.svg ---- For more information, see Help:SVG. In other languages

 

@SiBr₄: how about that? Any objections? sarang♥사랑 16:35, 2 September 2016 (UTC)

@Sarang: I'm assuming the purpose is to mark PNGs in language xx as superseded by a multilingual SVG and demonstrate the SVG in that language? I like the idea, but would simply say the SVG is multilingual without displaying the language code (e.g. "... is a multilingual vector version" in the top line), as this way it's unclear that "lang=xx" means "this SVG has multiple language options, including xx" as opposed to simply "this SVG is in language xx". Also, if my assumption is correct, what's the use of allowing a different language for each linked SVG file? SiBr₄ (talk) 21:57, 5 September 2016 (UTC)

SiBr₄ -- This template does not "mark as superseded", as discussed at length in the archives to this talk page. AnonMoos (talk) 12:58, 6 September 2016 (UTC)

@SiBr₄: Showing a special language (e.g. for a PNG in that language) seems rather easy than telling it verbally. Specifying a reason for superior quality as "... is multilingual ..." is easy with the current template. More difficult is to tell that in all the languages: Either we need in each case of such a file the same amount of much coding, or we provide a translation stub; an expansion of the template seems better anyway.

But I will check that option, and try to prepare the translation for some languages. sarang♥사랑 14:43, 7 September 2016 (UTC)

I didn't mean including it in the "reason" parameter, but in the first sentence ("File:Example.svg is a vector version of this file."). That would indeed require editing all language subpages again. Alternatively, a text such as "multilingual" could be added in brackets after the filename (where "lang=xx" is now in the draft).

Listing all languages of an SVG seems to me like something that should be done on the SVG file page, not in this template; hence, I see no need to display multiple translated versions of the same file. Just use the language of the raster file only. SiBr₄ (talk) 17:47, 8 September 2016 (UTC)

Allow abbreviations

It is a bit tedious always to type the long names for "quality" ansd "reason". Furthermore, it should be possible to specify quality even for more than one file. Please change the two lines

|5={{#if:{{{2|}}}{{{3|}}}||{{#switch:{{{quality}}}|s|superior=s|i|inferior=i}}}}

|6={{{reason|}}}

against

|5={{#if:{{{2|}}}{{{3|}}}|{{#switch:{{{allquality|{{{aq}}}}}}|s|superior=s|i|inferior=i}}<!--

-->|{{#switch:{{{quality|{{{q|{{{allquality|{{{aq}}}}}}}}}}}}|s|superior=s|i|inferior=i}}}}

|6={{{reason|{{{r|}}}}}}

(Don't use the sandbox, it has another base!) When it is done, I will maintain the documentation. -- sarang♥사랑 09:29, 21 May 2017 (UTC)

 Done --jdx ^Re: 15:50, 24 May 2017 (UTC)

As a matter of fact, the expansion (quality when more than one file) works well, but the displayed text in the different national versions is designed for quality of only one file. If somebody has too much time he/she can care for the now more complicated possibilities; it will be rather very seldom that more files and quality option occur - IMHO we can live with that little inconsistency... -- sarang♥사랑 17:07, 24 May 2017 (UTC)

Svg with bitmap

I have tried to see if we have a template to be used when a svg file includes a bitmapp. I haven't been able to find it but maybe it exist and I just can't find it.
If it doesn't exist I would propose that template with that message "this svg file includes a bitmapp and is therefore not a true svg file" or something similar.
I don't know what the process looks like to get something like this done or if there is an interest/need for this from other users here. So give me feedback and information on this, thanks. --Goran tek-en (talk) 18:11, 1 June 2017 (UTC)

They all should be listed on Commons:SVG marker templates. See {{BadSVG}} and for a related issue, {{TracedSVG}}. Note that some SVG files have small bitmaps added to a basically vector file for technical effects; those would not usually be added to Template:BadSVG... AnonMoos (talk) 14:14, 2 June 2017 (UTC)

Thanks for that information. But even if an svg contains only a small bitmapp you still have the problem with enlarging it so to me they should also be marked in some way. --Goran tek-en (talk) 16:43, 2 June 2017 (UTC)

I've also talked with Sarang about this. I suggest to add an option for this template to mark a lower importance of this issue with bitmap integration compared. -- User: Perhelion 17:13, 2 June 2017 (UTC)

Hi Perhelion, nice to meet you there at this construction site. I just tried to clearify the docu of BadSVG with a link to BadSVG-t; that is a small fix to not display the alarming large box when bitmap parts are only needed to show topographic structures. Images with that tag are categorized not into a maintenance category but to SVG maps with topographic raster graphics instead. We can discuss further parameters for BadSVG to mark more cases of useful bitmap embeddings.

I was hesitating to include that into original BadSVG because of the needed adaption of all the national versions - I do not know most of the languages; but when help for translations can be arranged we can proceed with that work.

Since it might be a good option to mark SVG files with Image generation, using its parameters, it may be sufficient when it works (for the moment) only that way, with a subtemplate of Image generation and its description mainly there. -- sarang♥사랑 05:39, 3 June 2017 (UTC)

Goran -- such images have small bitmaps which only take up a small percentage of the viewing box, often to get around limitations with the SVG renderer or the SVG format itself. It would be very crude and heavy-handed to lump such SVG files together with so-called SVGs which are nothing but an SVG wrapper around a PNG. See previous discussion at Template talk:BadSVG#Instruction... AnonMoos (talk) 21:48, 2 June 2017 (UTC)

I agree to above and I also think that it should not be that big alarming template. But it's still very important and useful information whenever a svg includes a bitmap. This doesn't only concern topographic maps, it is used in illustrations also so there should be a template (not a category) just to inform that there is a bitmap within this svg file, pure information, no fingers held up or judgement.

I don't really have the knowledge of how this type of work is done but could we not just edit BadSVG-t and remove to show its topographic structures. from it. Then it will be neutral and of bigger use. --Goran tek-en (talk) 10:15, 3 June 2017 (UTC)

Actually I think it's wrong to call a svg which includes a bitmap for a "bad" svg, {{BadSVG}}. Bad is something which is broken or not working. This is just a svg file which for some reason includes a bitmap probably to achieve what the creator wants. So both the name and the graphic sign in it is wrong to me. It should just show/give the information it does and not show that the file is bad in any way. --Goran tek-en (talk) 14:38, 3 June 2017 (UTC)

All the "bad" templates (BadSVG, BadJPEG) indicate that the data in the image file is not really suitable for the image format. So the purpose of "BadSVG" is not to mark all SVGs that have an embedded bitmap of any kind. AnonMoos (talk) 03:49, 4 June 2017 (UTC)

Full agreement: we need to differentiate cases where bitmaps are "bad" in the meaning of "good" SVG, and when they are used just to accomplish something (as structures) in a way better than by SVG code. Where Pgf-CDATA is always "bad", and an invisible (and useless) bitmap patterns as Adobe Illustrator Pattern PEO.svg are also, mere bitmaps disguised as SVG like Flag of Goshogawara, Aomori.svg are really BadSVG; on the other hand the structures aren't, and this fact should be distinguished. If the template name "BadSVG-t" is better to change to e.g. "TopoRaster" or something else expressing what it describes I will suppose that. -- sarang♥사랑 04:48, 4 June 2017 (UTC)

I've removed that from dozens of files, but I've always called it "Adobe cruft" I didn't know there was a category for it. Apparently it theoretically can have some uses if you re-open such a file in Adobe Illustrator. Anyway, the conclusion is that if there is to be a template documenting non-bad uses of bitmaps in SVG files, then it must not have "bad" in its name... AnonMoos (talk) 07:48, 4 June 2017 (UTC)

@AnonMoos: it's your native language, make suggestions for the name of the mentioned template; besides of the one for topographics possibly we might have more in future for other topic(s) - either distinct templates, or just a parameter. -- sarang♥사랑 09:13, 4 June 2017 (UTC)

I really don't think we should use the word topo because there might be other reasons to use a bitmap. I think it's better to have a wider usage for this, there are so many templates already.

• To me it's not necessary to use the word bad in any of those templates, how can it be bad if the file works?
  
• As it's now someone has to judge what is good or bad, for that person, maybe not for me. I think we should try to see it in a neutral way.
• But who really decide on things like this, is there a group or what? --Goran tek-en (talk) 14:53, 4 June 2017 (UTC)

Goran_tek-en -- there's widespread agreement among involved people on Commons that a PNG in an SVG wrapper with no vector data is an inappropriate use of the SVG file format, while an abstract (non-photographic) diagram is an inappropriate use of the JPEG file format, etc. You raise some philosophical issues, but people here are not generally paralyzed from taking action by such theoretical metaphysics.
Sarang -- I assume that by "topo" you mean satellite photos etc. use as the basis for a map, with added vector elements (such as national borders). But that's not the only non-bad use for bitmaps in SVG... AnonMoos (talk) 15:47, 4 June 2017 (UTC)

@AnonMoos: I agree on that if a svg only includes a bitmap and no additional vector stuff then it's a misuse or lack of knowledge, but still it's not bad, it's working. It should instead be something like "improper use of svg, extract image from svg". --Goran tek-en (talk) 17:31, 4 June 2017 (UTC)

I doubt whether most of the people involved in such issues on Wikimedia Commons really want to split semantic hairs over "bad" vs. "improper". The word "bad" adequately conveys the idea that there are problems with an image... AnonMoos (talk) 17:42, 4 June 2017 (UTC)

English text

What does "when not inferior" mean in the text? "It should be used in place of this raster image when not inferior." When not inferior what? @sikander (talk) 03:38, 5 January 2018 (UTC)

When the vector image is not inferior in quality and suitability for intended purpose to the raster image... AnonMoos (talk) 00:20, 9 January 2018 (UTC)

It should be "if not inferior". "when not inferior" implies that it's just a question of time until the vector image will magically stop being inferior. --Hbf878 (talk) 14:56, 13 August 2018 (UTC)

It's not magic, just humanpower. Whatever failings of the SVG can be discussed and then corrected by uploading new versions. This is also true of the raster files of course, but given SVG's other advantages, alongside the fact that changes can have less unintended effects on quality due to the semantic nature of the XML format, it makes sense to phrase proper conversion to SVG as an improvement. Arlo James Barnes 03:54, 28 January 2019 (UTC)

links to svg instead of pdf

File:Regelquerschnitt JoKa.svg is a vector version of this file. File:Vector version available/Archive 1 → File:Regelquerschnitt JoKa.svg For more information, see Help:SVG. In other languages

 

Using the code {{vva|File:Regelquerschnitt_JoKa.pdf}} on Regelquerschnitt JoKa.png links to Regelquerschnitt JoKa.SVG instead of Regelquerschnitt JoKa.PDF, but since the PDF has a higher quality, every editing should be done from the PDF. — Johannes Kalliauer - Talk | Contributions 14:27, 27 January 2018 (UTC)

First off, PDF is not considered an editable format on Commons. Starting with a PDF file and editing it to generate another PDF file is a rather specialized skill, or can require highly specialized software (which is sometimes quite expensive). Second, PDF files are not inherently vector -- many of them contain raster images only. AnonMoos (talk) 05:26, 30 January 2018 (UTC)

@AnonMoos: 1) As you can see the File:Regelquerschnitt_JoKa.svg is derived from File:Regelquerschnitt_JoKa.pdf, see source in File:Regelquerschnitt_JoKa.svg, therefore the PDF has higher quality. I used Inkscape, to convert to SVG, that's not very expensive (63MB to pay to your internet provider). SVG ist not very suitable for CAD-Plans, with a specific scale, which have to be printed 1:1. Therefore SVG is in my option the wrong format.

2) I don't care about othter case, I talk about a very specific case, and I'm shure it is not the only one. Just because the template can't be used on every page, does not mean the template should be deleted, most templates are for a specific case. I can also argue that many SVGs contain raster images only: Template:BadSVG. I think in count of number there are more SVG on Commons that contain only raster images than PDF that only contain raster images. There I don't get your point. In my opinion PDF is the most popular vector graphics format for printing (SVGs are not inherently for printing), which can even handle more completed stuff (f.e 3D-Objects) than just SVGs. Even in Messenging (f.e. Facebook) you can often send PDFs, but hardy SVGs.

 — Johannes Kalliauer - Talk | Contributions 20:51, 15 February 2018 (UTC)

Third, "Vector version available" implies that the other file is a vector graphic, and the template replaces any other file extension with ".svg", or adds it when none is passed. You may consider that a restriction, but it is thought to be an advantage! -- sarang♥사랑 18:11, 15 February 2018 (UTC)

@Sarang: Isn't Regelquerschnitt JoKa.pdf a vector graphic? (I might did not understand you fully.)  — Johannes Kalliauer - Talk | Contributions 20:51, 15 February 2018 (UTC)

For wikimedia, a scalable vector graphic can be recognized by the file extension ".svg"; it consists of SVG code, a composition of commands that are interpreted by a special software (this is a very rough explanation, but it explains it in an easy way). -- sarang♥사랑 22:23, 15 February 2018 (UTC)

@Sarang: Encapsulated_PostScript is also a 'vector graphic' which is 'scalable', also it is called 'Encapsulated PostScript', also it does not conatain SVG code. Are you agreeing that Eps is a vector graphic?  — Johannes Kalliauer - Talk | Contributions 16:50, 16 February 2018 (UTC)

---

JoKalliauer -- if a vector PDF is converted to a vector SVG, and the conversion is done right, then there shouldn't be any intrinsic quality difference. If you want to specify that an SVG file is derived from a PDF file, then you should use a "Derived from" template... AnonMoos (talk) 07:50, 16 February 2018 (UTC)

Thanks  — Johannes Kalliauer - Talk | Contributions 16:50, 16 February 2018 (UTC)

More expansions

The sandbox got more parameters, for language (lang/lang2/lang3) and creator of the new file (by/by2/by3)

File:Augsburg Tram 4.svg is a vector version of this file. File:Vector version available/Archive 1 → File:Augsburg Tram 4.svg (by Omnidom 999) ---- For more information, see Help:SVG. In other languages

 

Several vector versions of this file are available. File:Vector version available/Archive 1 → File:Augsburg Tram 4.svg  by JoKalliauer File:Augsburg Tram 5.svg | lang=be  by Omnidom 999 File:Augsburg Tram 6.svg | lang=fr ---- For more information, see Help:SVG. In other languages

 

just as an suggestion. -- sarang♥사랑 18:44, 15 February 2018 (UTC)

[resolved] Error with filenames containing special characters

Hello, I don't know if everyone is aware of this, but if the new vector image filename contains unusual characters such as &, ɑ, Δ..., there is following error message: "Error: No SVG image by that name exists. Please make sure to use the correct format: ". Despite that, the thumbnail of the new vector image is displayed correctly.
Examples:
File:MCC_to_MIC_&_HCl.png
File:Bovine_β-casomorphin_7.png
Best regards --Hbf878 (talk) 14:49, 13 August 2018 (UTC)

Hello Hbf, this is not a bug. The most similar templates don't accept URL encoded names and I disagree to support automatic decoding of every file. -- User: Perhelion 17:46, 13 August 2018 (UTC)

The issue with that is that the raster versions of those files are then added to Category:Vector_version_available/error, where they definitely don't belong because there is no error, neither in the raster image nor in the vector image. --Hbf878 (talk) 09:33, 7 September 2018 (UTC)

I just took a look at Category:Vector_version_available/error and the pages of aforementioned files and saw that the issue has been resolved. Thanks to whoever fixed it. --Hbf878 (talk) 11:12, 6 October 2018 (UTC)

I saw that error message because of the = sign character in File:Window function and frequency response - Gaussian (sigma = 0.4).svg.
But this workaround fixes it: File:Window function and frequency response - Gaussian (sigma & #61; 0.4).svg.
(Remove the blank between & and #. It's just there to prevent rendering an = sign, so you can see everything.)
--Bob K (talk) 14:12, 23 September 2019 (UTC)

Parameters not working

Parameters "Second SVG" and "quality" seems to not work. Piotr Bart (talk) 19:16, 22 August 2019 (UTC)