User:LeoRomero/sandox: Difference between revisions
testing collapsible tables for 2015 Wishlist template |
(No difference)
|
Revision as of 17:12, 13 November 2015
I suggest that we use this template for submissions:
Template: Your 2015 Wishlist suggestion |
---|
What is the problem you want to solve? |
What is the problem you want to solve? |
Which users would benefit? (editors, admins, Commons users, Wikipedia users, etc.) |
How is this problem being handled now? |
What are the proposed solutions? (if there are any ideas) |
Your signature ~~~~ |
Endorsements: {{endorsement}}~~~ |
Multimedia/Files
suggested multimedia for article
suggested multimedia for article |
---|
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) |
Improve SVG rendering
Improve SVG rendering | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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.)
To get an overview about the importance of a file format some statistic is useful. Based on database dump dewiki-20150302-pages-articles.xml.bz2 of german language Wikipedia the following estimation can be done. (Only short evaluation about systematic errors has been done.)
Results have been gained with Linux tool en:grep. To change to another file format adapt the following command line call.
(Only counts images that are embedded as thumb preview and not e. g. all the small flags in sport statistics.) | |||||||||||||||||||||
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. | |||||||||||||||||||||
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.
| |||||||||||||||||||||
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)
| |||||||||||||||||||||
|
Improve SVG rendering (2)
Improve SVG rendering (2) |
---|
Placeholder. Details see here. --2A02:810D:1740:1554:1464:B61E:AF7D:42D 19:29, 26 May 2015 (UTC)
|
SVG Help Button
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.
--Menner (talk) 18:11, 29 June 2015 (UTC)
- Endorsed +1 Absolutely needed and simply to implement!! ↔ User: Perhelion 07:39, 3 July 2015 (UTC)
- By copying commons:User:Menner/common.js on can try out how this SVG button might look like --Menner (talk) 12:39, 8 August 2015 (UTC)
Use of pictures in wikipedia
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).
Gruss --Nightflyer (talk) 22:50, 9 November 2015 (UTC)
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)
New audio player with waveform display
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)
Enhance image uploading process
- What is the problem you want to solve?
- 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.
Kenrick95 (talk) 11:47, 10 November 2015 (UTC)
- EndorsedYes! Make UploadWizard compatible with local copyright tags. Ę-oиė >>> ™ 14:49, 10 November 2015 (UTC)
In addition to above, there are other issues:
- UploadWizard on Commons is broken, and needs to be fixed (most urgent task);
- Easy transfer of images between Wikipedias and Commons, and back (right now one needs to be admin locally to moved a file from Commons);
- Easier chunked uploads for large files (can be included if #1 above is fixed);
Better support for djvu files
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).
--Alex brollo (talk) 14:07, 10 November 2015 (UTC)
- Endorsed really really useful in wikisource context. --AlessioMela (talk) 14:12, 10 November 2015 (UTC)
- Endorsed --Yann (talk) 16:30, 10 November 2015 (UTC)
- EndorsedJayantanth (talk) 18:00, 11 November 2015 (UTC)
Automatic numbering of pictures
What is the problem you want to solve?
- Sometimes pictures (tabulars, equations, etc.) are not described properly in the text. (=cannot directly be refered to, therefore...)
- It is sometimes hard to figure out which picture is meant.
Which users would benefit?
- Reader of Wikipedia would benefit, because the picture which is described is named unambiguously.
- Editors of Wikipedia will have an easy to use tool to address a certain picture in the text.
How is this problem being addressed now?
- Sometimes the pictures are numbered by the editors.
- This is inconvenient, when there are a lot of pictures in one article, and more pictures are added somewhere in the middle of the article.
What are the proposed solutions?
- Each picture, which should get a number, is marked with a label-tag.
- One can now address the picture by addressing to the label-tag.
- This is similar to the references numbering in wikipedia and the picture numbering in latex.
--Boehm (talk) 23:39, 9 November 2015 (UTC)
- 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)