Template talk:Vector version available

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Info non-talk.svg Template:Vector version available has been protected indefinitely because it is a highly-used or visible template. Use {{Edit request}} on this page to request an edit.

Maintenance category for missing a value[edit]

What about creating a maintenance category for images tagged with the template, but missing a value? --Leyo 20:29, 5 August 2010 (UTC)

I gave a try. Such images should soon be found at Special:WhatLinksHere/Template:Vector version available/error. --Leyo 12:52, 10 August 2010 (UTC)

It would be great if I could get some help for fixing all the errors. --Leyo 15:44, 19 December 2010 (UTC)

I would first ask Bot:CommonsDelinker, because he is guiltily for the most errors. --Perhelion (talk) 18:25, 19 December 2010 (UTC)
Thanks for asking the operator. --Leyo 23:29, 19 December 2010 (UTC)
Some users seem to have mixed it up with {{SVG}}, the request for SVG creation. Why not automatically change it, when not existing? -- sarang사랑 16:11, 20 December 2010 (UTC)

Placement on page[edit]

Where should this template be used on a page? I've seen it used both on the top and bottom of pages, i.e. both above and below {{Information}} and/or {{int:license}} templates. –Tommy Kronkvist (talk), 04:23, 12 August 2010 (UTC).

The predominant "traditional" placement seems to be above the description, but I'm not sure whether there's any real reason for that... AnonMoos (talk) 04:50, 12 August 2010 (UTC)

Poor translation[edit]


In the french version of this svg template, could somebody please change the sentence:

Voir aussi les informations à propos de la manière dont le logiciel MediaWiki supporte les images au format SVG.


Voir aussi les informations à propos de la manière dont le logiciel MediaWiki gère les images au format SVG.

"gère" instead of "supporte", which is here an "anglicisme" or "faux ami" (the verb to support in English does not mean "supporter" in French, and vice versa.

TIA. --Olivier1961 (talk) 11:54, 28 August 2010 (UTC)

You can edit Template:Vector version available/fr by yourself. – Kwj2772 (msg) 11:15, 1 September 2010 (UTC)
Oops, with this {{editprotected}} thing, I didn't realize I could do it myself. Done. Sorry for the trouble. --Olivier1961 (talk) 09:43, 2 September 2010 (UTC)


{{editprotect}} This should go in this cat: Category:SVG marker templates (SVG related) (I've added it at the doc page) like {{Convert to SVG}} --Perhelion (talk) 12:32, 28 October 2010 (UTC)

Well, sure, but you added the category to the doc page, where it belongs, so the category is categorized correctly. I don’t see any other change required. --Mormegil (talk) 19:26, 28 October 2010 (UTC)


In significant most cases the name of the SVG file is quite the same, save the extension. Therefore I think it helpful if the template works when no name is specified; then it assumes the name is the same, but with ".svg" instead of .gif, .png, .jpg or whatever. Whether the template checks the existence of such a file name seems not so necessary, the result is shown immediately by the error message, or the success miniature.
Possibly that needs expensive string operations outdated by now available modules File and FileName. They must be performed only when the file is looked at its description (and when the template is installed), not when the picture is displayed elswhere. So it seems not to bad with the server effort.
May be the number in Special:WhatLinksHere/Template:Vector version available/error will be reduced. If a name fits it cannot be the most wrong picture.
Another possibility, where no touching of this template is needed, would be to build a template that generates the name and passes control to VVA. -- sarang사랑 14:19, 20 December 2010 (UTC)

Some users seem to have mixed up the {{VVA}} with {{SVG}}, the request for SVG creation. Why not automatically change it, when non-existence is encountered? -- sarang사랑 16:11, 20 December 2010 (UTC)

NL translation[edit]

{{editprotected}} Please verify and add Template:Vector version available/nl --Denniss (talk) 02:01, 7 September 2011 (UTC)

Was done by another. – Adrignola talk 20:31, 13 September 2011 (UTC)

Seems a BUG[edit]

When I want to show that different vectorized versions exist to an image, I can do this via "other_versions", or with a gallery, or with something else. When I did it with multiple invocations of {{VVA}} as at ChetBraille.png a funny thing occurs: when I change to another language (no matter at which of the vva-boxes) all show the same vector image, the first one. Shall I check what causes this unexpected behaviour? -- sarang사랑.svg사랑 14:58, 15 November 2011 (UTC)

I would doubt that the error is in the template itself, since it's similar to other errors reported on Commons:Village pump... AnonMoos (talk) 18:26, 15 November 2011 (UTC)

Parameter for quality rating[edit]

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 63,236 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[edit]

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 [1]. In addition, there is another set of visible square-brackets in the replacement statement below the first horizontal line when no parameter is passed.[2]

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)

Pictogram voting info.svg 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)


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


--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)


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)
Checkmark 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[edit]

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: Stop cross.svg Gtk-ok.svg to explicite the message. ftiercel (talk) 18:48, 19 September 2013 (UTC)

  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg Oppose For the reasons mentioned by ftiercel. Aldaron (talk) 01:17, 29 September 2014 (UTC)

Recommendation for positioning of this template[edit]

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)

Symbol oppose vote.svg 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)


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. SiBr4 (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)

Proposed fix for English version[edit]

{{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>}}|}}

SiBr4 (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 )!! °o° 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. SiBr4 (talk) 09:12, 12 February 2015 (UTC)
Symbol support vote.svg 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)



There are too many variations for redirects of "Vector version available" (altogether transcluded 62 972 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.


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.


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}}. SiBr4 (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)


@Be..anyone, Sarang, 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. SiBr4 (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. 1st categorizing also when from file talk page (edit-protected file descriptions)
  3. 2nd categorizing (when no file name) is of no use
<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. SiBr4 (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. SiBr4 (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.

SiBr4 (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. SiBr4 (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). SiBr4 (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. SiBr4 (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.

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:

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}}.

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. SiBr4 (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...".

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
Gnome-x-office-drawing.svg File:Flag of Washington, D.C..svg is a vector version of this file. It should be used in place of this raster image when not inferior.

File:Vector version available Go-green.svg File:Flag of Washington, D.C..svg

For more information, see Help:SVG.

Alemannisch | Беларуская (тарашкевіца)‎ | বাংলা | Català | Čeština | Dansk | Deutsch | Ελληνικά | English | Español | Eesti | Euskara | فارسی | Suomi | Français | Galego | עברית | Hrvatski | Magyar | Հայերեն | Italiano | 日本語 | ქართული | 한국어 | Lietuvių | Македонски | മലയാളം | Bahasa Melayu | Plattdüütsch | Nederlands | Norsk nynorsk | Norsk bokmål | Occitan | Polski | Português | Português do Brasil | Română | Русский | Slovenčina | Slovenščina | Српски / srpski | Svenska | ไทย | Türkçe | Українська | Vèneto | Tiếng Việt | 中文 | 中文(简体)‎ | 中文(繁體)‎ | 中文(台灣)‎ | +/−

New SVG image

where it should have linked to File:Flag of Washington, D.C..svg. SiBr4 (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, 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 allowd 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. SiBr4 (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 Gnome-go-next.svg fine? Might be a green oneGo-next.svg 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)

{{editprotected}}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 Template:Vector version available/more if beneficial. SiBr4 (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).
Gnome-x-office-drawing.svg Several vector versions of this file are available. These should be used in place of this raster image when not inferior.

Error: Not all of these images exist. Please make sure to use the correct format: {{Vector version available|new image name}}.

For more information, see Help:SVG.

Alemannisch | Беларуская (тарашкевіца)‎ | বাংলা | Català | Čeština | Dansk | Deutsch | Ελληνικά | English | Español | Eesti | Euskara | فارسی | Suomi | Français | Galego | עברית | Hrvatski | Magyar | Հայերեն | Italiano | 日本語 | ქართული | 한국어 | Lietuvių | Македонски | മലയാളം | Bahasa Melayu | Plattdüütsch | Nederlands | Norsk nynorsk | Norsk bokmål | Occitan | Polski | Português | Português do Brasil | Română | Русский | Slovenčina | Slovenščina | Српски / srpski | Svenska | ไทย | Türkçe | Українська | Vèneto | Tiếng Việt | 中文 | 中文(简体)‎ | 中文(繁體)‎ | 中文(台灣)‎ | +/−

SiBr4 (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. SiBr4 (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. SiBr4 (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". SiBr4 (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. SiBr4 (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.) SiBr4 (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 Gnome-go-next.svg 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 Go-green.svg, 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)

Too many redirects[edit]

{{Vector version available}} ( prot. 63 081 times) is redirected by

Redirect 2015-02-17 now
{{supersededSVG}} prot. 10 426× Yes check.svg
{{vva}} prot. 15 435× Yes check.svg
{{nowSVG}} 1 830× Yes check.svg
{{SVG available}} 943× Yes check.svg
{{svg available}} 0¿? 454×
{{vectorversionavailable}} 34×
{{vector available}} 72×
{{SVG version available}} 12×
{{Nous avons aussi SVG}}
{{converted to SVG}}

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.Classic smiley.svgBe..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)