A tool similar to FIST, but a one that works well, and integrated. Matanya (talk) 22:45, 19 May 2015 (UTC)
:+1. Relatedly, I wrote a tool to suggest images based on other wikis; much less ambitious than FIST, but it seems stable: GLAMify. Ijon (talk) 17:11, 21 May 2015 (UTC)
SVG is an important file format for graphics on Wikipedia and is used in thousands of science articles. And this also the underlying software libRSVG has many problems with rendering SVG even the article about force in german (de:Kraft) is affected.
The issue arises since libRSVG was programmed by the Gnome Project to render scalabe icons for their desktop environment. Graphics that contain text was not goal and activities around libRSVG are limited to maintenance today. Because of that important features required for usage inside Wikipedia are buggy or missing. Some bug reports and feature requests by our community are undone since nearly ten years. A test of my own showed that required work often takes only few days (see task T7792).
SVG is important to Wikipedia but without our intervention the underlying software stays error prone.
The file on the right is used by en:Gas tungsten arc welding and in many more languages and even translated. It provoked bug described by task T97758. Due to its long endurance on Wikipidia it has been shown to our readers many million times. (A workaround has been applied to render it correctly recently.)
Further...
To get an overview about the importance of a file format some statistic is useful. Based on database dumpdewiki-20150302-pages-articles.xml.bz2 of german language Wikipedia the following estimation can be done. (Only short evaluation about systematic errors has been done.)
SVG: 56k
PNG: 92k (similar scope as SVG)
JPG: 1104k (mostly pictures)
GIF: 10k (similar scope as SVG)
Results have been gained with Linux tool en:grep. To change to another file format adapt the following command line call.
date && grep -o -E "(gif|GIF)\|(thumb|mini)" ./dewiki-latest-pages-articles.xml | wc -w && date
(Only counts images that are embedded as thumb preview and not e. g. all the small flags in sport statistics.)
Which users would benefit?
Everybody who is researching scientific or technical information on Wikipedia of any language will benefit. SVG is the preferred file format for high quality science graphics.
It will increase participation because less errors in SVG rendering removes pitfalls for authors without experience in the limitations of libRSVG. As consequence less distraction is created and new authors keep contributing.
This also increases quality because less errors in SVG renderer switches focus from workarounds to content. SVG simplifies re-usage and translation of content and high quality graphics can be share across languages. Thus improving and promoting SVG pushes quality.
How is this problem being handled now?
The SVG renderer libRSVG is part of the Gnome Project. Although it is not in the focus of the Gnome community. The Maintainer of libRSVG is Federico Mena Quintero. He maintains libRSVG in his spare time.
And some examples...
The following discussion has been closed. Please do not modify it.
What are the proposed solutions? (if there are any ideas)
Fix around eight to ten bugs that are especially important for usage of SVG on Wikipedia. Fixing only a few simple bugs would reduce the pain greatly. I expect this to require four weeks of work for fixing bugs, test them and manage software release.
Menner (talk) 20:04, 9 November 2015 (UTC) I'll also support selecting bugs, mastering libRSVG code and software release.
:Endorsed Now almost every SVG is rendered with bugs. --Ilya (talk) 23:32, 9 November 2015 (UTC)
Endorsed --Yann (talk) 16:16, 10 November 2015 (UTC)
Endorsed It's outrageous that this has languished so long. SVG is supposed to be our gold standard for image quality, adaptability, and reuse. Yet we cripple our own implementation of it. Some of these bugs have been highlighted for getting on for ten years, and nobody has lifted a finger. Jheald (talk) 00:32, 11 November 2015 (UTC)
Endorsed again ↔ User: Perhelion 22:27, 11 November 2015 (UTC)
Discussion
What are the GNOME Bugzilla tickets for the problems you want fixed e.g. [1][2][3]? It shouldn't take too long to update the patches and turn them into pull requests to the Github repository.
@Ryan Kaldari (WMF): What version of librsvg is used by Wikimedia? MER-C (talk) 20:29, 9 November 2015 (UTC)
@MER-C:I haven't completed with my wishlist yet. Here is a list of bugs. Half of them is not a libRSVG problem some are corner cases. Most of the bug reports contain a link to a Gnome Bugs.
Yes it shouldn't take long to update patches. Creating patches also doesn't take long. I've made five easy patches in five days but thoroughly releasing also takes time... and on the long term it is WMFs responsability to maintain libRSVG.
In task T112421 it says libRSVG 2.40.2 is in use. libRSVG 2.40.11 is released currently but I don't know if its still compatibly with Ubuntu 12.10 LTE used by WMF.
Here's a bunch of tickets that will be closed when updating to the latest version. Community Tech can't help with system operations, unfortunately, and I don't think the WMF should be the maintainers of this software. See if you can ask for commit access -- I fear patches submitted by Community Tech will be swallowed by Bugzilla. MER-C (talk) 21:31, 9 November 2015 (UTC)
Federico is quite open to our interests although he's short on time. I haven't talked to him recently and he is difficult to grasp. He accepted two of my patches but then omitted the next three without comment. I don't have enough time to push them currently and I see WMF in the responsebility to go on. -- Menner (talk) 22:00, 9 November 2015 (UTC)
The table with examples is going off the side of the page (at least on my screen). This makes scrolling up and down the page awkward. Is it possible to move that to another page, and link to it? DannyH (WMF) (talk) 22:31, 9 November 2015 (UTC)
@Menner: These are probably not bugs that the Community Tech team could address directly. However, if it is identified as a high priority by the community, we could help investigate the problems and flag them to other teams (or outside developers). As MER-C mentioned, the Ops team is responsible for our SVG rendering on the production wikis, but maybe there are some solutions that haven't been considered yet. For example, perhaps the WMF could hire a contractor from the GNOME community to work on librsvg for Ops. (Also, I'm afraid you can't endorse your own proposal. Sorry if that's confusing.) Ryan Kaldari (WMF) (talk) 22:36, 9 November 2015 (UTC)
@Ryan Kaldari (WMF): Sorry, I have little time this week. I won't reply until saturday. Just for short I'm aware of your annotations and I'll explain later. -- Menner (talk) 07:33, 10 November 2015 (UTC)
@MER-C: GNOME does not accept pull requests via GitHub, as far as I know patches go into GNOME Bugzilla. --Malyacko (talk) 16:07, 10 November 2015 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
How often is SVG rendering a problem? Appears there is a work around here [4]Doc James (talk · contribs · email) 11:16, 27 May 2015 (UTC)
This is me working on librsvg. I've fixed five long term bugs in five days. SVG is everytime a problem when I draw a scientific graphic. Detailed analysis isn't done yet. Currently I'm trying to get some important fixes into latest gnome release before next freeze. Anything else would mean years of waiting. -- Menner aka 2A02:810D:1740:1554:D50D:D2D:256C:10D4 17:49, 27 May 2015 (UTC)
Endorsed +1 It is absolutely annoying, time and resource wasting for everyone is willing to share SVG. Take simply a look on Commons, many SVG have an flooded crappy file-history (and then sometimes unused and dead or replaced by pixel-graphics). ↔ User: Perhelion 13:24, 3 July 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Besides improving SVG rendering it would be useful to have a "SVG Help Button". Like the Media Viewer button it could be placed below SVG files on Commons media meta pages visible only for loged-in users. Because SVG itself as a non-WYSIWYG format has many pitfalls, it is important to give guidance to contributors.
Until end of 2015 I'll make a prototype with an idea of its look and feel based on user scripts.
Endorsed +1 Absolutely needed and simply to implement!! ↔ User: Perhelion 07:39, 3 July 2015 (UTC)
Sorry, my english is very poor, so I write in german:
Jeder Uploader von Bildern kann über die Dateiliste seine hochgeladenen Bilder ansehen. Bei jedem einzelnen Bild ist die Verwendung in den einzelnen Sprachversionen angegeben.
Im Laufe der Jahre habe ich viel über Bildbearbeitung gelernt und kann meine Bilder entsprechend verbessern. Es ist sehr zeitaufwändig, deshalb wünsche ich mir eine Erweiterung der Dateiliste um eingebunden (nur einen Hinweis, nicht wo das Foto eingebunden ist).
Translation: Uploaders of pictures can examine their uploads using Special:Listfiles. On each of the file description pages, its inclusion is recorded for each of the individual projects. During many years, I've learned a lot about image editing, allowing me to improve my pictures. This is quite time consuming, hence I would like to have an extension of Special:Listfiles that marks included images (just a hint, not the complete list where the photograph is used). --AFBorchert (talk) 07:29, 10 November 2015 (UTC)
* Endorsed As far as Google Translate said, he is talking about providing of number of imagelinks for each uploaded image. Sounds pretty easy and quite useful. --Edgars2007 (talk) 05:23, 10 November 2015 (UTC)
Endorsed Sounds reasonable. But do you know about GLAMorous, i.e. did you try this? --AFBorchert (talk) 07:29, 10 November 2015 (UTC)
Thanks AFBorchert for the link :) --Edgars2007 (talk) 07:56, 10 November 2015 (UTC)
Basically something like this. I think the improvement in usability compared to what we have now is quite obvious, at least for File: pages at Commons. Might be useful as an option in Wikipedia articles as well. --El Grafo (talk) 11:29, 21 September 2015 (UTC)
:The Community Tech team is focused on curation and moderation tools for editors. This (interesting) proposal is clearly out of scope for this team. Maybe it is a good candidate for #possible-tech-projects? I have commented in the task.--Qgil-WMF (talk) 11:49, 21 September 2015 (UTC)
Normal way of uploading files using Special:Upload lacks of machine-readable metadata field. (i.e. Template:Information must be manually added and most of user are unaware of this template)
Users are confused on choosing the licenses and hence numerous images are wrongly licensed (e.g. fairuse image tagged as GFDL). This is mostly due to the confusing and text-heavy UI when choosing the licenses.
Which users would benefit? (editors, admins, Commons users, Wikipedia users, etc.)
Those who care about having correct machine-readable metadata in the images.
How is this problem being handled now?
Many wikis have their file uploading feature disabled and were redirected to Commons instead.
But similar to the case on local wikis, by redirecting uploading process to Commons, I observed that the users still upload fair-use image to Commons since they are not aware about file licensing stuffs and their purpose is merely to upload image, i.e. they will choose whatever license options available to enable them upload their image for usage in the article.
In en.wiki, "FileUploadWizard" has been created to insert Template:Information to the image and hence there are machine-readable metadata.
But to the other wikis where JS developers are lacking, nothing can be done since the localization has been hard-coded in the JS codes. Moreover, the UI has not improved since it is heavily text-based (and as a result, looks like a Terms & Conditions page)
I'm not aware about other wikis, but in id.wiki, localization effort of "FileUploadWizard" has been started but stalled due to the large effort needed in improving the UI.
What are the proposed solutions? (if there are any ideas)
Enable commons:Special:UploadWizard in local wikis, enhancing its features to adapt with local wiki rules, including the fair-use licenses.
Indonesian Wikipedia community has proposed this, but nothing has been done yet since this Phabricator task was not supported by the developers there.
Djvu files are a very interesting open format for full book digitalization, but mediawiki uses them only as "proofreading tools". On the contrary, they could be an interesting output of wikisource work, working about thoroughly editing of text layer and fully using their metadata. Even when they are used simply as "proofreading tools", much work could be done using details of text layer mapping, since it contains interesting suggestions about formatting (text alignment and indentation, text size, paragraphs, blocks...) presently not used at all.
Here a list of ideas:
to shift to indirect mode of djvu structure (so allowing a faster access to individual pages with a djvu reader extension of browsers);
to add a set of API requests, as an interface to all read-only DjvuLibre routines;
to add some API too for editing text layer by djvuxmlparser;
to allow minor changes of djvu files (i.e. editing some words into text layer) without the need of re-uploading the whole djvu file (the history of text edits could be saved with something like reviews history).
Endorsed See also phab:T7600. Helder 11:30, 10 November 2015 (UTC)
Endorsed --Debenben (talk) 22:27, 10 November 2015 (UTC)
This is interesting. phab:T112991 is a 2016 Wikimedia Developer Summit proposal about refreshing our media styling support; this might also fit within that scope. Cscott (talk) 18:52, 11 November 2015 (UTC)
Endorsed Now almost every SVG is rendered with bugs. --Ilya (talk) 23:32, 9 November 2015 (UTC)
