Community Wishlist Survey 2017/Multimedia and Commons/Textual diffs for SVGs

Textual diffs for SVGs

  • Problem: Comparing different media versions is often difficult as the changes may not be noticeable. This stands for SVGs as well as other media formats; however, as SVG is a textual file format, its changes can be shown as textual diffs.
  • Who would benefit: Advanced users who understand the SVG source code.
  • Proposed solution: Use the existing diff used for wikitext changes also for SVG (and any other textual file format), provide a diff link in the first column of the file history like (current | diff) / (restore | diff).
  • More comments:
  • Phabricator tickets:
  • Proposer: Tacsipacsi (talk) 20:22, 6 November 2017 (UTC)[reply]

Discussion edit

 
Example SVG file used on 7.7M pages, which has 8 versions. When 9-th version is uploded it would be nice to compare source-codes to see what changed. --Jarekt (talk) 14:29, 16 November 2017 (UTC)[reply]

Do you have a specific example of an SVG file (on Wikimedia Commons etc) which got updated and when being able to view such a diff would have been helpful? --AKlapper (WMF) (talk) 21:30, 7 November 2017 (UTC)[reply]

It came into my mind just after the previous year’s survey, I don’t remember specific image which I had in my mind ten months ago… But maps like Kosovo relations.svg are good examples: this file’s changes are mainly properly noted (except if the change wasn’t the one stated in the upload comment), but some versions don’t have comment while they—I suppose—are mainly consist of toggling CSS classes, so it’s easily understandable from the textual diff. Also, textual files can be changed in such a way that they are really the same pixel by pixel, but the source code is different (from changing a comment to a major cleanup). —Tacsipacsi (talk) 22:07, 7 November 2017 (UTC)[reply]

This seems like a very limited and specific use case, that could easily be addressed with a gadget, that uses an online diff service or something to compare two files, without forcing an extra useless button upon people who won't need it. —TheDJ (talkcontribs) 10:46, 8 November 2017 (UTC)[reply]

At least the backend should be done—why would I need to use a third-party service when we have a working diff system? Also, MediaWiki already has many links which I should call bloatware at more visible places like the “beta” link in the personal toolbar (one can easily get there from the preferences; or why don’t we have separate links for all preferences tabs?). OK, make it opt-in, but do it in PHP—it’s not easier to do client side than the sandbox link, which is not even opt-out. Please do not mark it as nonsense or useless ab ovo, just vote against it in the voting phase. It may turn out than that nobody else would need this feature. —Tacsipacsi (talk) 22:15, 8 November 2017 (UTC)[reply]

I'd think a state-of-the-art visual compare tool would address a wider audience, although it wouldn't be completely equivalent. It would be more intuitive for non-nerds and it's often more important to get help spotting inconspicuous visual changes than calling attention to some purely technical rearrangement of internal data structures. I'm picturing something that shows two images on top of each other and a visibility seam between that you can grab and slide around like here, and maybe some compensation mechanism to disregard if content was just shifted around on the page.--Reseletti (talk) 15:59, 9 November 2017 (UTC)[reply]

Yes, a visual diff might be more important. It’s also better because it can work for all image types (but still not for other media types: videos, sound and multipage documents like PDF and DjVu). —Tacsipacsi (talk) 21:26, 9 November 2017 (UTC)[reply]
This makes sense for PNGs and GIFs because they are losslessly compressed, but JPEG quantization has real potential to make visual diffs a dog's breakfast. MER-C (talk) 03:51, 10 November 2017 (UTC)[reply]
The above example works also for JPEG, as it doesn’t compare the images by itself, rather makes the user easier to do so. —Tacsipacsi (talk) 14:31, 10 November 2017 (UTC)[reply]
Reseletti, Tacsipacsi, MER-C If you are enthusiastic about an option like that, please make sure to submit it as a SEPARATE proposal. —TheDJ (talkcontribs) 10:35, 13 November 2017 (UTC)[reply]
  • Expanding on this: general SVG uploading via text would be very good to have too. It is a format that should and could be changed very easily, but currently we are stuck with a system that doesn’t serve its needs well enough despite it gaining traction for the usage in all kinds of graphics. stjn[ru] 21:13, 11 November 2017 (UTC)[reply]
  • For years I was struck by how strange it is when people are trying to improve existing SVG files by tweaking their source-code and we have no good way of comparing before and after versions. --Jarekt (talk) 14:29, 16 November 2017 (UTC)[reply]

Voting edit