Wikimedia Meta-Wiki

Опитування побажань спільноти (2015)/Мультимедіа

< Community Wishlist Survey 2015
This page is a translated version of the page Community Wishlist Survey 2015/Multimedia and the translation is 100% complete.
Other languages:

Автоматична нумерація зображень

Яку саме проблему пропонується вирішити?

Іноді зображення (таблиці, рівняння тощо) не зовсім правильно описуються в тексті статі. (= а отже, на них не можна послатися...)
Іноді буває важко зрозуміти, який саме рисунок мається на увазі.

Які користувачі отримають вигоду?

Вигоду отримають читачі Вікіпедії, оскільки описуване зображення можна буде назвати чітко, без можливості помилки.
Редактори Вікіпедії матимуть простий у використанні інструмент для посилання на конкретне зображення в тексті.

Яким чином з цією проблемою справляються зараз?

Іноді редактори надають таким зображенням номери.
Це буває незручно, якщо в статті є багато зображень, і якщо є можливість, що нові зображення будуть додані всередину статті.

Які пропоновані рішення?

Кожне зображення, яке повинне отримати номер, позначається спеціальною міткою (тегом).
Тепер на таке зображення можна послатися, посилаючись на його мітку.
Це щось схоже на те, як працює нумерація приміток у Вікіпедії та нумерація зображень у latex.

--Boehm (talk) 23:39, 9 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  Endorsed See also phab:T7600. Helder 11:30, 10 November 2015 (UTC)[reply]
  Endorsed --Debenben (talk) 22:27, 10 November 2015 (UTC)[reply]
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)[reply]

Голосування

  1.   Support --MGChecker (talk) 19:26, 30 November 2015 (UTC)[reply]
  2.   Support --Purodha Blissenbach (talk) 14:44, 1 December 2015 (UTC)[reply]
  3.   Support -- Singhalawap (talk) 16:51, 1 December 2015 (UTC)[reply]
  4.   Support --Boehm (talk) 21:39, 1 December 2015 (UTC)[reply]
  5.   Support Helder 23:36, 1 December 2015 (UTC)[reply]
  6.   Support Stevie is the man! Talk • Work 23:43, 1 December 2015 (UTC)[reply]
  7.   Oppose I just can't see the point, or recognise the "problems". What happens when they are rearranged, or changed? Johnbod (talk) 04:13, 2 December 2015 (UTC)[reply]
    Remark: That is exactly the problem: "What happens when they are rearranged, or changed?" Now the numbers have to be rearranged manually. In the case in which there are many numbers to fix, a manual rearrangement is prune to errors. An automatic numbering would mitigate the problem. Such a feature is a standard when writing e.g. a book and is technically easy to implement with labels. Without such a helping tool long articles are hard to maintain. --Boehm (talk) 10:08, 2 December 2015 (UTC)[reply]
    But the vast majority of images aren't numbered, or referred to in the text. Presumably everyone adding an image would now have to number it, which is a vast amount of work for hardly any gain. I maintain plenty of long articles, with large numbers of images, without this being a problem. Even more unconvinced. Johnbod (talk) 20:48, 3 December 2015 (UTC)[reply]
    Ok, I think I get your and Gap9551's point now. Not a single picture will get a single number unless it is desired. Only in the case, when it is needed, then a picture is marked with a label and gets then automatically a number. Therefore the number of the picture only appears, when it is needed. And yes, there are cases where it will definitely help. Think e.g. of wikibook articles. In the scientific part of wikipedia, where I contribute, a picture is always described in the text. And the reference has to be unambiguously. In this cases it will help, and in the other cases nothing will be changed to the status quo. --Boehm (talk) 21:42, 3 December 2015 (UTC)[reply]
  8.   Support @Johnbod: That is exactly the point. Now it can happen that someone changes or moves a picture and references like "see diagram on the right" get confusing or wrong. With the automatic numbering, the wikitext similar to "see fig.~\ref{mylabel}" gets translated to something like "see fig. 5", thus always refers to the diagram or produces an error like "reference broken". The system suggested is basically the same as the system used for references.--Debenben (talk) 23:58, 2 December 2015 (UTC)[reply]
    See above. Johnbod (talk) 20:48, 3 December 2015 (UTC)[reply]
  9.   Support But maybe only number (all) pictures in articles where at least one picture is referred to. Gap9551 (talk) 00:36, 3 December 2015 (UTC)[reply]
  10.   Support - SantiLak (talk) 10:45, 4 December 2015 (UTC)[reply]
  11.   Support -- Sir Gawain (talk) 14:03, 6 December 2015 (UTC)[reply]
  12.   Oppose per Johnbod. A great deal of images included in articles aren't actually referred to in the text, and the overwhelming majority of images aren't numbered. I see no reason whatsoever to force numbering universally across all articles. I could potentially see a smaller scale tool to be used for individual articles when necessary, but there is no need to implement this across the whole project. Mz7 (talk) 05:41, 11 December 2015 (UTC)[reply]
    Remark: I have to apologies. My English is perhaps too poor to express what I mean. It was never my intention that all pictures should get numbers. Perhaps I didn't make that clear enough. Only the pictures, which are already numbered will get an automatic numbering, i.e. only pictures with an additionally added label. --Boehm (talk) 19:24, 11 December 2015 (UTC)[reply]
    @Boehm: My apologies for misunderstanding. Thank you for clarifying. Per my original comment, as long as this is done on a smaller scale and only on articles where numbering would genuinely be helpful, then this has my support. Mz7 (talk) 21:26, 11 December 2015 (UTC)[reply]
  13.   Support - Certainly not needed in many articles but an essential tool where image referencing is needed. SBaker43 (talk) 04:01, 14 December 2015 (UTC)[reply]
  14.   Support MediaWiki software is used not only for encyclopedic articles, but for wikibooks, wikiversity, etc. too. In books, courses and so on the requested feature would be useful. -- Juetho (talk) 09:49, 14 December 2015 (UTC)[reply]

Вдосконалення процесу завантаження зображень

Яку проблему пропонується вирішити?
  • Звичайний метод завантаження зображень через Special:Upload не має поля для машиночитних метаданих (тобто Шаблон:Information треба додавати вручну, а більшість користувачів взагалі не знають про існування цього шаблону)
  • Користувачі заплутуються, вибираючи ліцензії, в результаті чого численні зображення публікуються під хибними ліцензіями (наприклад, зображення, що підпадає під добропорядне використання, публікується з ліцензією GFDL). Це спричинено переважно незрозумілим інтерфейсом завантажувача із надміром тексту під час вибору ліцензій.
Які користувачі отримають від цього вигоду? (редактори, адміни, користувачі Вікісховища, Вікіпедії тощо)

Ті, котрим небайдужа наявність машиночитних метаданих на сторінках файлів.

Яким чином з цією проблемою справляються зараз?
  • Чимало вікі вимкнули свою функцію завантаження файлів та натомість перенаправили її на Вікісховище.
    Однак, як і у випадку з локальними вікі, що перенаправляють процес завантаження на Вікісховище, я спостеріг, що користувачі продовжують вантажити зображення, що підпадають під добропорядне використання — цього разу вже на Вікісховище, оскільки їм нічого не відомо про нюанси ліцензування файлів, а їхньою метою є просто завантажити зображення, тобто вони виберуть будь-яку з пропонованих опцій ліцензування, лиш би система дозволила їм завантажите фото, яке вони хочуть, для використання у статті.
  • В en.wiki був створений «FileUploadWizard», який повинен вставляти Template:Information на сторінку файлу, а отже, такі сторінки вже після завантаження матимуть машиночитні метадані.
    Але в інших вікі, де відсутні розробники JS, нічого не можна зробити, оскільки локалізація завантажувача була глибоко вкорінена у JS-код. Крім того, інтерфейс завантажувача не покращився, оскільки він досі містить значні об'єми тексту (і, як наслідок, виглядає наче сторінка Умови використання)
  • Не знаю щодо інших вікі, але в id.wiki локалізацію «FileUploadWizard» таки розпочали, однак вона застопорилась через потребу значного вдосконалення інтерфейсу завантажувача.
Які пропоновані рішення? (якщо є хоч якісь ідеї)
  • Увімкнути commons:Special:UploadWizard у локальних вікі, вдосконаливши його функції для роботи з локальними правилами вікі, включаючи ліцензії добропорядного використання.
    Спільнота індонезійської Вікіпедії запропонувала це рішення, однак з того часу так нічого й не було зроблено, оскільки цей запит на Фабрикаторі не був підтриманий тамтешніми розробниками.

Kenrick95 (talk) 11:47, 10 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  EndorsedYes! Make UploadWizard compatible with local copyright tags.  Ę-oиė  >>>  ™ 14:49, 10 November 2015 (UTC)[reply]

In addition to above, there are other issues:

  1. UploadWizard on Commons is broken, and needs to be fixed (most urgent task);
  2. Easy transfer of images between Wikipedias and Commons, and back (right now one needs to be admin locally to moved a file from Commons);
  3. Easier chunked uploads for large files (can be included if #1 above is fixed);

Голосування

  1.   Support anything that can enhance this complicated process and make it easier in the non-en wikis. Stevie is the man! Talk • Work 23:47, 1 December 2015 (UTC)[reply]
  2.   Oppose I think it is better to just upload images to Commons, instead of uploading locally and relying on others to move it to Commons. --Jarekt (talk) 03:57, 2 December 2015 (UTC)[reply]
  3.   Comment: If the solution proposed above seems to be to integrate enwiki's FileUploadWizard to other wikis, then I oppose. In my opinion, the wizard is clunky, and is not user friendly to a point where it accommodates for every possible scenario. For example, on enwiki, there are several fair-use rationale templates that can be used for different situations, but usually requires that the uploader fill out several fields of information that they may either not know or not need if a more specific template was used. That, and the current state of the File Upload Wizard causes more work for editors who review file uploads (such as myself): for about 9/10 uploads through the wizard, I have to replace the fair-use template with a more specific template, which causes unnecessary burning of time for volunteers when the wizard should have placed the correct template itself. Steel1943 (talk) 21:40, 2 December 2015 (UTC)[reply]


Покращити розпізнавання файлів SVG

Яку проблему пропонується вирішити?
 
de:Kraft: Третє зображення має баг, описаний у завдання T7792

SVG — це важливий файловий формат для графічних зображень у Вікіпедії, і він використовується в тисячах статей на наукову тематику. І програмне забезпечення libRSVG, що лежить в основі розпізнавання таких файлів, має багато проблем зі зчитуванням SVG — навіть стаття про фізичне поняття сили в німецькій Вікіпедії (de:Kraft) постраждала від цієї проблеми.

Ця проблема виникає тому, що програму libRSVG розробляв Gnome Project для розпізнавання іконок із можливістю масштабування у їхньому стільничному середовищі. Графіка із вмістом тексту не була метою цього проекту, і станом на сьогодні, вся діяльність навколо libRSVG обмежена лише обслуговуванням програми. Через це важливі функції, необхідні для використання у Вікіпедії, містять багато багів, чи й узагалі відсутні. Деякі звіти про баги та запити на функції від нашої спільноти не виконуються протягом майже десяти років. Мій власний тест довів, що виправлення цієї проблеми часто займає лише декілька днів (див. завдання T7792).

Файли SVG важливі для Вікіпедії, однак без нашого втручання програмне забезпечення, що відповідає за їх розпізнавання, залишається схильним до помилок.

Інший значний приклад...
 
File:GTAW broken.svg: Містить баги вже цілих десять років!!!

Файл справа використовується у статті en:Gas tungsten arc welding і в багатьох інших мовних версіях, і є навіть перекладені його версії. Він став причиною багу, описаного у завдання T97758. Зважаючи на його тривалу присутність у Вікіпедії, наші читачі бачили його багато мільйонів разів. (Нещодавно було застосоване обхідне рішення для коректного розпізнавання цього зображення.)

Далі...

Аби отримати уявлення про важливість файлового формату, варто навести деяку статистику. На основі дампів бази даних dewiki-20150302-pages-articles.xml.bz2 німецькомовної Вікіпедії, можна навести такі оцінювальні дані. (Був виконаний лише короткий аналіз системних помилок.)

  • SVG: 56к
  • PNG: 92к (приблизно ті ж теми, що й SVG)
  • JPG: 1104к (переважно фотознімки та подібні зображення)
  • GIF: 10к (приблизно ті ж теми, що й SVG)

Результати отримано за допомогою Linux-інструмента grep. Аби змінити на інший файловий формат, відредагуйте поданий командний рядок. date && grep -o -E "(gif|GIF)\|(thumb|mini)" ./dewiki-latest-pages-articles.xml | wc -w && date (Враховуються лише зображення, включені в статті як мініатюри, а не, скажімо, усі дрібні прапорці у спортивній статистиці.)

Які користувачі отримають вигоду?

Кожен, хто досліджує наукову чи технічну інформацію у Вікіпедії будь-якою мовою, отримає вигоду. SVG — це файловий формат, якому віддають перевагу при потребі створення наукових графічних зображень високої якості.

Це посприяє підвищенню активності редакторів, оскільки менша кількість помилок при розпізнаванні SVG усуне пастки для авторів, які не знають про обмеження libRSVG. І як наслідок, стане менше тих речей, що даремно відволікають редакторів, а отже, нові автори продовжать робити свій внесок.

Це також посприяє підвищенню якості, оскільки менша кількість помилок при відображенні SVG змістить фокус із обхідних рішень на сам вміст. SVG спрощує повторне використання та переклад вмісту, тож високоякісна графіка може поширюватися усіма мовними версіями. Таким чином, покращення та поширення SVG підвищує якість.

Яким чином цю проблему вирішують зараз?

Програма для розпізнавання SVG-файлів, libRSVG, є частиною Gnome Project. Однак вона не вдосконалюється спільнотою Gnome, оскільки в стосунку до їхніх цілей вона працює цілком справно. Наглядом за libRSVG займається Фредеріко Мена Квінтеро (Federico Mena Quintero). Він обслуговує libRSVG у свій вільний час.

І деякі приклади...
The following discussion has been closed. Please do not modify it.
Баг завдання T65703

патч потребує оновлення

завдання T7792

патч потребує оновлення

завдання T65236

патч потребує перевірки

завдання T55899

патч потребує перевірки

завдання T43426
Погано   TODO Порожнє поле  
Добре  
Із обхідним рішенням
Перетворено за допомогою Inscape 		TODO  
Із обхідним рішенням 		 
Із обхідним рішенням
Які пропоновані рішення?

Виправте від восьми до десяти багів, які є особливо важливими для нормального використання SVG у Вікіпедії. Навіть виправлення лише декількох найпростіших багів значно послабить проблему. За моїми оцінками, треба буде чотири тижні роботи для виправлення багів, тестування та управління релізом програмного забезпечення. (У випадку, якщо виправлення коду libRSVG виходить за межі можливостей Технічної команди, корисним буде хоча б управління вже наявними патчами.)

-- Menner (talk) 20:04, 9 November 2015 (UTC) Я також підтримаю вибір багів, вдосконалення коду libRSVG та випуск програмного забезпечення.[reply]

Earlier discussion and endorsements

Opinions

Discussion

@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 завдання 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.
--Menner (talk) 21:03, 9 November 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
@Ryan Kaldari (WMF): How exactly the Tech Team will address this problem will be arbitrated after the vote. I'm a developer and already created some patches for libRSVG. The most important thing by the Tech Team would be to manage the existing patches being applied. I've already tried to fix some issues. This had limited success since two busy spare time developers living each on the other side of the earth won't team well.
Further I expect the vote to be a signal for WMF to keep an eye on libRSVG and feedback and reason for me to keep on.
-- Menner (talk) 18:59, 13 November 2015 (UTC)[reply]
@Menner: Sure, we would be happy to help however we can. Pushing on existing patches is certainly doable, and perhaps something we could help with regardless of the vote. Ryan Kaldari (WMF) (talk) 05:49, 17 November 2015 (UTC)[reply]

Голосування

  1.   Support --Tobias1984 (talk) 11:32, 30 November 2015 (UTC)[reply]
  2.   Support Goldzahn (talk) 12:40, 30 November 2015 (UTC)[reply]
  3.   Support Not sure how much Community Tech can do here - this is pretty specialised code we're talking about here, and Community Tech is a generalist team - but anything, even just nagging Operations to update librsvg, will be a help. This, that and the other (talk) 13:20, 30 November 2015 (UTC)[reply]
  4.   Support ↔ User: Perhelion 15:44, 30 November 2015 (UTC)[reply]
  5.   Support BethNaught (talk) 17:41, 30 November 2015 (UTC)[reply]
  6.   Support Patrick87 (talk) 18:08, 30 November 2015 (UTC)[reply]
  7.   Support --MGChecker (talk) 19:27, 30 November 2015 (UTC)[reply]
  8.   Support along with text-editing of SVG, as if it was an article! --YodinT 02:53, 1 December 2015 (UTC)[reply]
  9.   Support We should contribute back to FOSS projects we heavily rely on. --Ricordisamoa 06:43, 1 December 2015 (UTC)[reply]
  10.   Support --Arnd (talk) 14:54, 1 December 2015 (UTC)[reply]
  11.   Support tufor (talk) 15:54, 1 December 2015 (UTC)[reply]
  12.   Support Goombiis (talk) 16:30, 1 December 2015 (UTC)[reply]
  13.   Support Benedictus Levita (talk) 16:31, 1 December 2015 (UTC)[reply]
  14.   Support Ckoerner (talk) 17:10, 1 December 2015 (UTC)[reply]
  15.   Support Marlus Gancher (talk) 22:04, 1 December 2015 (UTC)[reply]
  16.   Support  Trizek from FR 22:12, 1 December 2015 (UTC)[reply]
  17.   Support Stevie is the man! Talk • Work 23:50, 1 December 2015 (UTC)[reply]
  18.   Support --Oriciu (talk) 00:45, 2 December 2015 (UTC)[reply]
  19.   Support RoodyAlien (talk) 02:59, 2 December 2015 (UTC)[reply]
  20.   Support Mule hollandaise (talk) 10:13, 2 December 2015 (UTC)[reply]
  21.   Support --β16 - (talk) 14:09, 2 December 2015 (UTC)[reply]
  22.   Support — NickK (talk) 15:25, 2 December 2015 (UTC)[reply]
  23.   Support--Manlleus (talk) 15:33, 2 December 2015 (UTC)[reply]
  24.   Support Pbm (talk) 12:16, 3 December 2015 (UTC)[reply]
  25.   Support — Bilorv (talk) 20:01, 3 December 2015 (UTC)[reply]
  26.   Support Graeme Bartlett (talk) 05:28, 4 December 2015 (UTC)[reply]
  27.   Support SantiLak (talk) 10:45, 4 December 2015 (UTC)[reply]
  28.   Support --Moroboshi (talk) 13:45, 4 December 2015 (UTC)[reply]
  29.   Support --OSeveno (talk) 16:05, 4 December 2015 (UTC) SVG is also very important for maps (thousands of files) and heraldry (tens of thousands of files)[reply]
  30.   Support Halibutt (talk) 22:45, 4 December 2015 (UTC)[reply]
  31.   Support -- Sir Gawain (talk) 14:04, 6 December 2015 (UTC)[reply]
  32.   Support \\ Martin Kraft (talk) 17:11, 7 December 2015 (UTC)[reply]
  33.   Support \\ ÅñŧóñŜûŝî (Ð) 04:31, 8 December 2015 (UTC)[reply]
  34.   Support --Waldir (talk) 15:30, 8 December 2015 (UTC)[reply]
  35.   Support – Valtlait (talk) 14:16, 11 December 2015 (UTC)[reply]
  36.   Support → «« Man77 »» [de] 18:06, 11 December 2015 (UTC)[reply]
  37.   Support --Pokéfan95 (talk) 04:51, 12 December 2015 (UTC)[reply]
  38.   Support --Stranger195 (talk • contribs) 07:18, 12 December 2015 (UTC)[reply]
  39.   Support --NaBUru38 (talk) 03:47, 13 December 2015 (UTC)[reply]
  40.   Support --‫·‏לערי ריינהארט‏·‏Th‏·‏T‏·‏email me‏·‏‬ 12:38, 13 December 2015 (UTC)[reply]
  41.   Support --ESM (talk) 16:28, 13 December 2015 (UTC)[reply]
  42.   Support --Harald321 (talk) 17:10, 13 December 2015 (UTC)[reply]
  43.   Support Alkamid (talk) 22:30, 13 December 2015 (UTC)[reply]
  44.   Support --Tgr (talk) 22:52, 13 December 2015 (UTC) (also thanks Menner for all your work on fixing libRSVG bugs!) --Tgr (talk) 22:52, 13 December 2015 (UTC)[reply]
  45.   Support I could not understand which problem is present in the example pictures, but in the past I created vetorial images using Inkspace and they got really messed on Wikimedia Commons.--MisterSanderson (talk) 01:18, 14 December 2015 (UTC)[reply]
  46.   Support -- Juetho (talk) 09:49, 14 December 2015 (UTC)[reply]

Пропоновані файли мультимедіа для статті

Інструмент, подібний до FIST, але такий, щоб працював добре та був інтегрований у вікі. Matanya (talk) 22:45, 19 May 2015 (UTC)[reply]

Earlier discussion and endorsements
  Endorsed 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)[reply]

Голосування

  1.   Oppose I'm comfortable with keeping this as an external tool, like other tools that make suggestions. I'm not sure what integration buys us. Stevie is the man! Talk • Work 23:55, 1 December 2015 (UTC)[reply]


Використання зображень у Вікіпедії

Вибачте, моя англійська дуже погана, тому я напишу німецькою:

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)[reply]

Переклад: Завантажувачі зображень можуть оцінити свої завантаження через Special:Listfiles. На кожній сторінці опису файлу, його включення вказується для кожного з окремих проектів. Протягом багатьох років я навчався редагуванню зображень, яке давало змогу вдосконалювати мої знімки. Це забирає досить багато часу, а тому я б хотів мати розширення на Special:Listfiles, яке б позначало включені зображення (просто підказка, а не повний список сторінок, що використовують це фото). --AFBorchert (talk) 07:29, 10 November 2015 (UTC)[reply]

Earlier discussion and endorsements

Голосування

  1.   Support Yes, it would be useful to quickly find which of your own image uploads are most used across Wikimedia projects so that you could focus on improving their processing and captions. —Pengo (talk) 14:17, 2 December 2015 (UTC)[reply]
  2.   Support--Manlleus (talk) 15:33, 2 December 2015 (UTC)[reply]
  3.   Support —Beleg Tâl (talk) 17:06, 2 December 2015 (UTC)[reply]
  4.   Support per Pengo. Stevie is the man! Talk • Work 18:46, 2 December 2015 (UTC)[reply]
  5.   Support per Pengo - SantiLak (talk) 10:45, 4 December 2015 (UTC)[reply]
  6.   Support Halibutt (talk) 22:46, 4 December 2015 (UTC)[reply]
  7.   Support // Martin Kraft (talk) 17:13, 7 December 2015 (UTC)[reply]
  8.   Support --Edgars2007 (talk) 09:10, 12 December 2015 (UTC)[reply]
  9.   Support This "ListFiles" page can be far more impoved, but this proposal is good too. --MisterSanderson (talk) 01:20, 14 December 2015 (UTC)[reply]
  10.   Support -- Juetho (talk) 09:49, 14 December 2015 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2015/Multimedia/uk&oldid=26711820"