Template talk:Valid SVG

From Wikimedia Commons, the free media repository
Jump to: navigation, search

URL reference parameter[edit]

Is it better to give the url reference as parameter? The question rise since if the url is not given the validator try to validate the referring page that is the page Image:xyz instead of the image itself xyz.svg -- AnyFile 12:56, 29 July 2007 (UTC)

One more point. This template apply to the whole page, that is to a Image:xxxx page, not a single image. So if a newer version is uploaded the template refer to the generic Image:xxxx page, even if the validation was done with the older image.

So it would be much better if it was written which version of the image was checked.

But I have a serious problem in find a way to specify a specific version of the image and its url if the image is the last one (current image).

The same things apply with the url. If I use the url parameter as explained in the noinclude section of this parameter, this url always refers to the last version of the image, which may not be the one I have checked. The problem here is that while I have a way to get the a permanent url to a version that now is an old version of an image, I have no way to get a permanent link to the specific version of the image that now is the current version. -- AnyFile 10:16, 8 February 2008 (UTC)

You can use [[Media:Filename.svg]] to get the current direct URL to the SVG but I have not found a way to combine it with an external link to the validator.w3.org URL yet:
Media:Flag of Germany.svg valid
--Matt 08:57, 19 February 2008 (UTC)
Got it to work using the magic word {{filepath:}}: valid. The url= parameter is now obsolet. --Matt 12:56, 3 March 2008 (UTC)
Cool. Thank you very much. --norro 21:23, 3 March 2008 (UTC)

Invalid SVG[edit]

Shouldn't there be a template (and category) for invalid SVG files as well? ––Bender235 (talk) 21:27, 13 July 2008 (UTC)

I may go ahead and create {{InvalidSVG}}. ––Bender235 (talk) 12:22, 25 July 2008 (UTC)

I have nothing to say against this template. However, is there any advantage that comes with this template? --norro 10:50, 27 July 2008 (UTC)
Just marking those SVGs that need to fixed. That's it. ––Bender235 (talk) 20:45, 28 July 2008 (UTC)
Please not that svg files which come up as invalid shouldn't necessarily be fixed. As an example metadata tags are classified as invalid by the validator even when they are not. This is even true for the examples for how to use the metadata parameters on the w3 documentation pages. /Lokal_Profil 23:12, 7 August 2008 (UTC)
Can you give an example? I find it hard to believe that the W3C validator is not able to validate XML defined by W3C itself. --norro 08:49, 8 August 2008 (UTC)
Stick the code at http://www.w3.org/TR/SVG/metadata.html#Example into http://validator.w3.org/#validate_by_input. I got 20 errors. The first copule of errors might not be relevant but the later batch (linked to RDF) always occur in files with metadata. /Lokal_Profil 13:31, 8 August 2008 (UTC)
It appears the SVG working group is moving away from DTDs and towards XML schemas. I think the W3C validator only uses DTDs to do validation, so that may not be all that useful for SVGs. See here. I'm not sure if there is a good way to validate SVGs at the moment; the W3C looks like it has an initial attempt here, but the online version isn't working and the downloadable version (last I tried it) still has issues with unexpected namespaces (which are used by Inkscape, which I think otherwise outputs valid SVG but will fail the old DTD validator). Carl Lindberg (talk) 19:01, 27 September 2008 (UTC)


Shouldn't there be a bot to evaluate all the images as to whether or not they're valid?Smallman12q (talk) 19:31, 3 February 2010 (UTC)

Image URL not working[edit]

The {{fullurl:}} parser function is not including the URL scheme. As a result the URLs being sent look like //commons.wikimedia.org/... instead of http://commons.wikimedia.org/.... Is this a bug in MediaWiki that should be reported or should I just add http: to the templates manually? --ScottyWZ (talk) 20:01, 11 September 2011 (UTC)

Don't know, but just added. -- πϵρήλιο 14:33, 13 September 2011 (UTC)
All local full urls should now be coded as relative urls, rather than hard urls, so they work whether a person is using a standard http or a secure https login. Otherwise one is dropped out of their login mode, and becomes just an IP address.  — billinghurst sDrewth 00:55, 13 November 2011 (UTC)
This one was a little bit different -- it was the URL provided to the W3C servers, to retrieve the SVG and test it, so it had to be a full URL (and did not need to be https). As such, it was eventually hardcoded http, though I refactored the template some to make it easier to make the change across all the translated subtemplates. Carl Lindberg (talk) 02:55, 13 November 2011 (UTC)

Template broken(?)[edit]

This template seems to be no longer working. When I click on it to get a page validation from W3C, the following error message is displayed at W3C:

Sorry! This document can not be checked.

  1. Error
     I got the following unexpected response when trying to retrieve http:////commons.wikimedia.org/wiki/Special:Filepath/Pushing3.svg:

•••Life of Riley (TC) 01:40, 13 September 2011 (UTC)

I've fixed, ok now? -- πϵρήλιο 14:31, 13 September 2011 (UTC)
Looks like most of the translated versions still need to be fixed. You did the English one. The German one looks like it has a similar fix, and also uses the filepath magic word instead of going through Special:Filepath -- that seems a better way as well. Carl Lindberg (talk) 18:41, 13 September 2011 (UTC)
I fixed English and a couple other of the localized ones. I haven't dealt with translated templates much, but would it be a good idea to pass the w3.org URL as an argument to the translated subtemplates, so that if the URL constructions needs to change again (due to either our changes or w3.org) we only need to change one place? That part (the URL to go to) doesn't seem too language-dependent. Carl Lindberg (talk) 13:54, 15 September 2011 (UTC)
Yes indeed, that would be recommended. -- πϵρήλιο 21:08, 15 September 2011 (UTC)
I think I've done them all now. Oddly there is an Arabic translation of the template documentation, but no Arabic version of the template itself... Carl Lindberg (talk) 23:47, 19 September 2011 (UTC)
  • Template fixed now. Thank you! •••Life of Riley (TC) 19:00, 17 September 2011 (UTC)

Not working with odd filenames[edit]

The {{urlencode:{{filepath:{{PAGENAME}}}}}} does not work, it returns nothing, if the filename contains Unicode U+0027 «'» (typewriter apostrophe), as with Hornblower's double-beat valve.svg or 'Klaviatura' drawn by Ivan v. 3.svg. Is there a workaround to fix it? -- sarang사랑 08:40, 20 July 2012 (UTC)

The problem is filepath, not urlencode. PAGENAME already escapes the apostrophe, which is confusing filepath it looks like. Not sure of the fix yet. Carl Lindberg (talk) 12:34, 20 July 2012 (UTC)
Ah, problem is mentioned in Bugzilla16474, with this template mentioned specifically. I re-applied the workaround mentioned in that ticket, which I think used to be here but which I must have broken when I refactored the template, not realizing why the extra complication was there. Carl Lindberg (talk) 12:53, 20 July 2012 (UTC)

#source anchor[edit]

Is the #source anchor at the end of the URL really necessary ? I have to scroll up everytime to see the result of the check... Thibaut120094 (talk) 13:33, 10 January 2015 (UTC)

Presumably most folks are not interested in the warnings for a valid SVG, many warnings actually aren't interesting. If that's so we're in the minority wanting to see warnings always... –Be..anyone (talk) 16:38, 10 January 2015 (UTC)
The #source anchor is not really necessary. Also the source per se is not a default value of the Validator, so this is all in all is more for experienced people. So I also propose to remove this anchor. User: Perhelion (Commons: = crap?)  10:04, 11 January 2015 (UTC)
@Thibaut120094: If somebody wants to use the link IMHO it is in most times useful to see the source. Files are tagged either with ValidSVG or InvalidSVG; the link in ValidSVG shows the source, the link in InvalidSVG shows the error report. Anyway, in most systems you will have a tab above of the page with either a red or a green square - if a file tagged erroneously valid shows the red square, or if you want to see the warnings, you need to scroll up to see the report. IMHO this is rather seldom, and in most cases the first lines of the valid SVG code are of interest, because information about the tool can be found there. But I am thinking most people don't use the link at all. sarang사랑 18:18, 25 January 2015 (UTC)

Parameter ss=1 crashes validator[edit]

Example: File:Scallop Diagram2.svg (5.91MB) "sometimes" (= now) works only without "show source". –Be..anyone (talk) 23:18, 20 January 2015 (UTC)

I was not able to validate files ≳ 2M, I do not know yet how to avoid the timeout. But you are right, without any option I can validate even the scallop diagram (revalidation fails). Now I am thinking of expanding the template {{Image generation}} and all the SVG templates to pass an option inhibiting parameter. sarang사랑 18:18, 25 January 2015 (UTC)
Maybe +0, +1, etc. for "show me", and 0, 1, etc. for "no details". –Be..anyone (talk) 19:00, 25 January 2015 (UTC)

I've now removed the "opt" feature at one place completely (there was no way to revert it, it always existed) to get a version also working with huge SVGs, i.e., not crashing the validator. The docu and the code are now inconsitent, please fix that without any ss=1 default. –Be..anyone (talk) 12:58, 31 January 2015 (UTC)


There are about 35 languages, but the English version is the only one that formats everything well. Most language versions care for the highliting, but some like {{ca}} contain a wrong linefeed. I tried to update the {{farsi}} version, hopefully it is now better. Unfortunately I do not have the knowledge to update all languages; it is the same problem with {{InvalidSVG}}.
There had been an error since two months passing the option twice, it is now fixed. sarang사랑 18:18, 25 January 2015 (UTC)

The annoying source option[edit]

After the standard setting is now reestablished, ValidSVG id defaulted to "option=&ss=1#source".
When this causes problems with large files, it can be altered (to opt=&ss=1) or completely turned off individually:

Parameter name: at ValidSVG "option" or "opt"; at Inkscape etc. "vopt" or "vo" (becaue it's a validator parm like vs, vt, vw); at Igen "opt" or "o".
The simple Igen is recommended, there it can be switched off with the ">" sign comfortably.   sarang사랑 06:18, 5 February 2015 (UTC)

Quote from some lines above, "please fix that without any ss=1 default": we don't know which SVGs are big enough to break the validator, maybe it's a timeout depending on their server load. Please get rid of this default in {{igen}}.
Or let v (valid) imply >, I never used 0 after it did not work weeks ago. @Medium69: I vaguely recall "huge QI+VI SVG by Medium69" with lots of localized variants, all SHOULD NOT use ss=1. –Be..anyone (talk) 06:43, 5 February 2015 (UTC)

May I Symbol oppose vote.svg Oppose:

  1. If a file is tagged "Valid SVG", or "Invalid SVG because of ... errors", any link to W3C will show just that it is valid, or invalid because of ... errors.
  2. I am sure that most people won't use the provided link at all!  Or are there users not trusting the tag and checking it whether it's true?
  3. Mainly people wanting to know more about the code, e.g. which tool had been used, what caused the W3C-errors or, in some cases, what may be the reason for a rsvg bug, will use the link to the validator.
  4. When the show source option is switched off generally, everyone of the few users following the link need to revalidate if they want to see what's the facts (that does not concern me, I can access it directly; and everybody can update his own common/js whithout the ss option).
  5. When the ss option remains active, the few people following the link can get the above problem in the rare cases that a file is too large. But the prevalent majority of files won't cause that problem.

It is still possible to insert the "don't show source" parameter for single files - if somebody thinks there is any advantage in doing so, and that it will help other users.
I am really thinking how things can be made most useful for the large community of wikimedia users. In my best opinion it will be the best to leave the ss as the default option.
When it seems useful, I will VFC the files of Medium69; but I oppose the general removal of ss. -- sarang사랑 10:53, 6 February 2015 (UTC)