Commons:Village pump/Proposals/Archive/2015/11
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Expansion of the selection menu for Categories
It would be nice if the selection menu for the media would be complemented by the following points:
(This is in my view, especially in categories with a large number of entries make sense.)
- Sort by date
- Sort by Name
- Sorted by frequency of use
Next:
- All images
- Featured pictures
- qualtity images
- Valued images
- In this category and in...
- In this category but not in...
- German original of my proposal:
Erweiterung des Auswahlmenüs für Kategorien
Es wäre schön, wenn das Auswahlmenü für Medien um nachfolgende Punkte ergänzt würde:
(Dies ist aus meiner Sicht besonders bei Kategorien mit einer großen Zahl von Einträgen sinnvoll.)
- Sortiert nach Datum
- Sortiert nach Namen
- Sortiert nach Häufigkeit der Verwendung
Neben:
- Alle Bilder
- Exzellente Bilder
- Qualitätsbilder
- Wertvolle Bilder
- In dieser Kategorie und in...
- In dieser Kategorie, aber nicht in...
--Molgreen (talk) 06:18, 31 October 2015 (UTC)
- What's the benefit of sorting by frequency of use? Would this be a feature used by the casual visitor? -- Rillke(q?) 11:54, 31 October 2015 (UTC)
- Hi Rillke, Thank you for your feedback signal. In my view, the use of which is a clear indication of the quality of the image: content (statement) and photographically. (In my experience, more quality images are included in Wikipedia articles.)
- in German: Hallo Rillke, Danke für Deine Rückmeldung. Aus meiner Sicht ist die Verwendung ein deutlicher Hinweis auf die Qualität des Bildes: inhaltlich (Aussage) und fotografisch. (Nach meiner Erfahrung werden in Wikipedia-Artikeln eher hochwertigere Bilder eingebunden.) --Molgreen (talk) 12:22, 31 October 2015 (UTC)
- Obviously this is not my impression. Wikipedia articles are frequently written before good pictures are available. Also, images on a wiki project frequently illustrate a point, they don't have to be of superior quality. -- Rillke(q?) 12:56, 31 October 2015 (UTC)
- Hi Rillke, Thank you for your feedback signal. In my view, the use of which is a clear indication of the quality of the image: content (statement) and photographically. (In my experience, more quality images are included in Wikipedia articles.)
Hi Rillke Yes, embedded images are not basically good. They were selected by an author (for various reasons (image content, image statement, and so on)). This sets it apart from the mass of images.
- in German: Ja, eingebundene Bilder sind nicht grundsätzlich gut. Sie wurden von einem Autor ausgewählt (aus verschiedenen Gründen (Bildinhalt, Bildsaussage und so weiter)). Dies hebt sie von der Masse der Bilder ab.
Thank You and best regards --Molgreen (talk) 05:17, 1 November 2015 (UTC)
- In my experience, the most used images are often (not always of course) among the worst in quality, because they were once used in one Wikipedia article when nothing better was available, and then copied to other Wikipedias. Even if the "big" Wikipedias later changed the photo to a higher quality image (which is not always the case), the low quality images remain highly used in smaller Wikipedias which aren't updated very frequently. Of course, this fact can actually be a good reason for offering the option to sort by usage frequency: If the images that are most frequently used are of low quality, looking for their usage is a good place to start replacing them. — Julian H.✈ 11:26, 1 November 2015 (UTC)
- Note that the Global Usage Badges Gadget allows browsing of galleries for images that are in use, although it doesn’t do any sorting or filtering.—Odysseus1479 (talk) 22:54, 1 November 2015 (UTC)
- In my experience, the most used images are often (not always of course) among the worst in quality, because they were once used in one Wikipedia article when nothing better was available, and then copied to other Wikipedias. Even if the "big" Wikipedias later changed the photo to a higher quality image (which is not always the case), the low quality images remain highly used in smaller Wikipedias which aren't updated very frequently. Of course, this fact can actually be a good reason for offering the option to sort by usage frequency: If the images that are most frequently used are of low quality, looking for their usage is a good place to start replacing them. — Julian H.✈ 11:26, 1 November 2015 (UTC)
How can images be found without a category that I have even uploaded?
How can images be found without a category that I have even uploaded?
in German: Wie kann Bilder ohne Kategorie finden, die ich selbst hochgeladen habe?
Many greetings --Molgreen (talk) 15:28, 13 November 2015 (UTC)
- Google translate translation makes little sense can some german speaker look at the original? --Jarekt (talk) 15:41, 13 November 2015 (UTC)
- @Molgreen: You can find all your uploaded files at Special:AllMyUploads. That's Special:ListFiles/Molgreen if you are not logged in. The link to this page can always be found on the top right, next to the one for loggin out. Is this what you were looking for? — Julian H.✈ 15:49, 13 November 2015 (UTC)
- in some pictures I forgot to add a category. How can I find it
- in German: bei einigen bilder habe ich vergessen eine Kategorie hinzuzufügen. Wie kann ich sie finden. --Molgreen (talk) 16:13, 13 November 2015 (UTC)
- es sind mehr als 1.500 . . . https://commons.wikimedia.org/w/index.php?title=Special%3AListFiles&limit=500&user=Molgreen --Molgreen (talk) 16:17, 13 November 2015 (UTC)
- Ich denke ich verstehe das Problem, aber ich kenne keine direkte Lösung. Viele Nutzer hier wenden auf alle ihre Bilder eine Versteckte Kategorie an, wie z.B. Category:Photos by User:Molgreen. Dann könntest du das mittels Category intersection mit Category:All media needing categories as of 2015 ermitteln. Die Kategorie könntest du mit VisualFileChange.js automatisiert massenhaft anfügen (Modus "append any text"). — Julian H.✈ 21:28, 13 November 2015 (UTC)
- es sind mehr als 1.500 . . . https://commons.wikimedia.org/w/index.php?title=Special%3AListFiles&limit=500&user=Molgreen --Molgreen (talk) 16:17, 13 November 2015 (UTC)
(Und ob Sie einfacher auf Deutsch hier schreiben kann, dann schreiben Sie bitte auf Deutsch!) - Jmabel ! talk 22:06, 13 November 2015 (UTC)
- @Julian Herzog: , danke, genau das habe ich gesucht: die Category:Photos by User:Molgreen habe ich angeleget und Hidden gesetzt und mit dem coolen Tool VisualFileChange.js diese Kategorie allen meinen Bildern hinzugefügt. Mit Category intersection komme ich, ehrlich gesagt, leider nicht zurecht.
- Herzlichen Dank für Eure Mühe. Viele Grüße --Molgreen (talk) 06:09, 14 November 2015 (UTC)
- @Molgreen: In das Category intersection tool kannst zu zum Beispiel folgende Werte eintragen: Language: commons; Project: wikimedia; Root categories: All media needing categories as of 2015, Photos by User:Molgreen (Komma durch Zeilenumbruch ersetzen); Namespace: 6; Depth: 1. — Julian H.✈ 08:43, 14 November 2015 (UTC)
- Herzlichen Dank für Eure Mühe. Viele Grüße --Molgreen (talk) 06:09, 14 November 2015 (UTC)
Hallo Molgreen, so sieht das aus. Hat aber nur 2 Dateien gefunden:
Gruß, --Achim (talk) 08:57, 14 November 2015 (UTC)
@Achim55: , @Julian Herzog: , herzlichen Dank Euch beiden für Eure Unterstützung. Die Syntax hätte ich nicht hinbekommen. Die beiden Bilder verfügen jetzt über eine Kategorie. Der Abschnitt kann dann sehr gern archiviert werden. Schönes Wochenende. LG --Molgreen (talk) 17:45, 14 November 2015 (UTC)
Bot to inform users about broken templates
Hi all, over the last months i am cleaning files appearing in different maintenance categories such as category:Pages using Information template with incorrect parameter or category:Language templates with no text displayed. Often an editor causes the problems by changing the files. So my idea is to have a bot daily checking the changes in certain predefined maintenance categories. For each new file in these categories it checkes if there was only one editor working on this file within the last day. If so, a message on the user page is added asking the editor to review his changes. This would move some of the cleanup work from the cleaner to the responsible editor. --Arnd (talk) 15:18, 11 November 2015 (UTC)
- Support We could monitor new additions to
- category:Pages using Information template with incorrect parameter
- Category:Pages using Artwork template with incorrect parameter
- Category:Pages using Photograph template with incorrect parameter
- Category:Pages using Book template with incorrect parameter
- Category:Media using Location template with incorrect parameter
- category:Language templates with no text displayed
- Category:Pages using duplicate arguments in template calls
- Category:Media without a license: needs history check
- Category:Media with erroneous locations
- Category:Pages with malformed coordinate tags
- and probably many other automatically populated categories. I wonder if we should alert all users or only "experienced" ones, as those bot messages could be quite confusing and chances that new users will be able to fix the issues are slim. But than again that is how you learn. --Jarekt (talk) 16:41, 11 November 2015 (UTC)
- Support Makes sense. --Steinsplitter (talk) 17:24, 11 November 2015 (UTC)
- i would not make an exception for beginnners. It is more important to not blame the user but just give a polite hint with pointers to possible help. About false positives: It can happen that not a file change but a template change happened in the same time is the cause for being in this category. Should the bot also check all included templates for possible edits? Or is this so rarely that we can just ignore it and mention this possibility in the user message? --Arnd (talk) 09:41, 12 November 2015 (UTC)
- Arnd, If there is a lot of files affected than chances are that some template changed, otherwise it is most likely users fault especially if someone just edited the file. --Jarekt (talk) 15:39, 13 November 2015 (UTC)
- i would not make an exception for beginnners. It is more important to not blame the user but just give a polite hint with pointers to possible help. About false positives: It can happen that not a file change but a template change happened in the same time is the cause for being in this category. Should the bot also check all included templates for possible edits? Or is this so rarely that we can just ignore it and mention this possibility in the user message? --Arnd (talk) 09:41, 12 November 2015 (UTC)
Ok, so will prepare such a bot. If i am ready i will come back to discuss open details. --Arnd (talk) 12:18, 16 November 2015 (UTC)
Idea Portal for any Wikipedia user
translated with Google Translate:
The following links an implementation of a portal for ideas I like very much: simple, user-friendly and clear and with a voting option. I would like that very well for every Wikimedia user ... https://ideas.microfocus.com/mfi/novell-zcm
The German original of my proposal:
Der nachfolgende Link einer Umsetzung eines Portals für Ideen gefällt mir sehr gut: einfach, bedienerfreundlich und übersichtlich sowie mit einer Abstimmungs-Option. Das würde mir sehr gut für den jeden Wikimedia-Benutzer gefallen . . . https://ideas.microfocus.com/mfi/novell-zcm
Sorry, I forgot to sign --Molgreen (talk) 05:09, 21 November 2015 (UTC)
Declaring a map atlas for map sheets
We have been pondering about the best way to declare an atlas object for a collection of map files that belong to it. My proposal is that they are placed in a category that will then display all the sheets automatically, and more functionality can be made if necessary. This seems somewhat futureproof as opposed to using galleries. Are you aware of any conventions?
Here's an example of an index/atlas page. Not very beautiful, but can be developed further: Category:Senate_Atlas
Here is another ongoing upload. I apologise for the lack of conversation prior to starting this. Because I forgot to declare the atlas/index as a category, I would like to correct it with an additional proposal:
Can we extend the Map template to read a parameter denoting a set/atlas and based on that set the category accordingly? Here's the example: File:Rektangelmålinger_20B-3-nø_20B-3,_1812_-_2.jpg. Inside the template there is the parameter "set" which has the value [[:Category:Norwegian rectangular surveys]]. I propose we could extend the Map template so that it will set the category of the file to the value that is declared in that parameter. Can we do this?
I would like to also tell that we have been preparing a batch import of maps into the Wikimaps Warper based on a category like this.
--Susannaanas (talk) 10:10, 29 November 2015 (UTC)
- I tested this and it will work well with plain text values in the "set" field. However, I have created category links as the value of the field. Would it be easier to mass edit the values in the mass upload and remove the category link, and use the plain text value to construct the category links in the template - or - modify the template so that it would identify category links and strip them & reconstruct the link? Perhaps the latter would only help me and no-one else. --Susannaanas (talk) 13:39, 29 November 2015 (UTC)
Create Lua module for accessing Wikidata
I propose we create the basic Lua modules for accessing Wikidata and using values from there in metadata templates. The module in question is the Wikidata module such as https://en.wikipedia.org/wiki/Module:Wikidata.
My goal is to create a Wikidata-driven alternative to Artwork template with additional content formatting templates for dimensions, locations etc.
Please tell if you have previous work on this or would like to contribute. It would be great to get a skilled Lua/Wikidata developer to help out.
Best, Susannaanas (talk) 15:55, 20 November 2015 (UTC)
- Unless, as it seems, it has already been created. Will take a closer look. --Susannaanas (talk) 17:14, 20 November 2015 (UTC)
- This is definitely a good idea! Pinging @RexxS as someone that might be able to help here. Thanks. Mike Peel (talk) 18:47, 20 November 2015 (UTC)
- @Susannaanas: The problem is that the module won't work for Artwork templates on file pages, because Wikidata are refusing to enable the "arbitrary access" feature for Commons.
- Without the "arbitrary access" feature, the only information from wikidata that a page can access is information from a wikidata page that the Commons page is directly 1:1 sitelinked with.
- That immediately rules out all file pages, because (by policy) there are no Wikidata items for individual file pages.
- It could potentially be trialled on some gallery pages; and some category pages -- though the latter would be very unpredictable, because some Commons category pages are linked to wikidata category items (so could only pick up the very limited data stored about categories). It is only the limited number of category pages that are (against policy?) linked to wikidata main 'article-type' that could pick up full Wikidata info on the subject of the category.
- So for the time being, there is no chance to get Artwork, Creator, Institution, or Authority Control templates to generally draw information from Wikidata.
- To fix this, "arbitrary access" needs to be enabled. I don't really understand why this is a problem. Apparently, there is some issue with language labels. If I understand it correctly, if the label in language XX for an item on Wikidata is changed, the software assumes that such a change only needs to be notified to wiki-pages on the xx-language wiki. However, because Commons is multilingual, a page here that used the template that drew on Wikidata would need to be updated if a relevant label in any language got updated.
- Until that facility is coded into the system, they won't let Commons have arbitrary access.
- I'm not sure why it is such a big deal to implement, such that Lydia is talking about not enabling it until the middle of next year (and it's now already most of a year since the first wikis went arbitrary access). But apparently that is how it is. Jheald (talk) 21:38, 20 November 2015 (UTC)
- Ah, I thought all wikis had arbitrary access now. @Lydia Pintscher (WMDE): is there a timeline for enabling it here? I guess the phabricator tracking ticket is phab:T89594 - I'll also ping there. Thanks. Mike Peel (talk) 22:27, 20 November 2015 (UTC)
- Jep. See my answer there. I don't think it'll take us 6 month - I actually hope significantly less unless we find another huge monster... --Lydia Pintscher (WMDE) (talk) 09:57, 21 November 2015 (UTC)
- I think one can quite successfully start to experiment with artworks, since the Artwork template shows data from the artwork item itself. What you cannot show, can be filled in later. If we start with some simple additions of Wikidata elements and proceed gradually, we will all gain invaluable insight while doing so. When arbitrary access is ready for prime time, the tasks can be more complicated. --Susannaanas (talk) 13:16, 23 November 2015 (UTC)
- Can we have Module:Wikibase in Commons? What is the practice, if I want to experiment on my own with modules? --Susannaanas (talk) 15:28, 23 November 2015 (UTC)
- Susannaanas, The best practice would be to look at related modules at en-wiki or even wikidata, import best fitting one and modify if needed. The module can be tested at pages which might have wikidata managed interwiki links, like artwork/artist galleries linking to wikipadia articles, or categories linking to wikipedia categories. For such special cases we should be able to access wikidata properties and test new modules. --Jarekt (talk) 16:01, 23 November 2015 (UTC)
- @Susannaanas: The artwork template lives on a file page; and (by policy) a file page is not to be sitelinked to the wikidata item for the painting. Therefore, in general, an artwork template cannot draw from Wikidata without arbitrary access. Jheald (talk) 19:49, 23 November 2015 (UTC)
- Right, I did not think of that. I assumed they are linked, but that the linked ones are rare.. --Susannaanas (talk) 09:59, 24 November 2015 (UTC)
- @Susannaanas: The artwork template lives on a file page; and (by policy) a file page is not to be sitelinked to the wikidata item for the painting. Therefore, in general, an artwork template cannot draw from Wikidata without arbitrary access. Jheald (talk) 19:49, 23 November 2015 (UTC)
- Susannaanas, The best practice would be to look at related modules at en-wiki or even wikidata, import best fitting one and modify if needed. The module can be tested at pages which might have wikidata managed interwiki links, like artwork/artist galleries linking to wikipadia articles, or categories linking to wikipedia categories. For such special cases we should be able to access wikidata properties and test new modules. --Jarekt (talk) 16:01, 23 November 2015 (UTC)
- Jep. See my answer there. I don't think it'll take us 6 month - I actually hope significantly less unless we find another huge monster... --Lydia Pintscher (WMDE) (talk) 09:57, 21 November 2015 (UTC)
- Ah, I thought all wikis had arbitrary access now. @Lydia Pintscher (WMDE): is there a timeline for enabling it here? I guess the phabricator tracking ticket is phab:T89594 - I'll also ping there. Thanks. Mike Peel (talk) 22:27, 20 November 2015 (UTC)
- I'm not sure why it is such a big deal to implement, such that Lydia is talking about not enabling it until the middle of next year (and it's now already most of a year since the first wikis went arbitrary access). But apparently that is how it is. Jheald (talk) 21:38, 20 November 2015 (UTC)
- Creator and Institution templates should work, as there should be a 1:1 relationship with WD. We have this for Author pages on the French Wikisource, so I don't see why it couldn't work here. Regards, Yann (talk) 22:01, 21 December 2015 (UTC)
Add EXIF date
Hi all, there are many thousand images that have a {{Information}} template with an empty date parameter. However, several of them have a date in the EXIF metadata. After a test run made by ArndBot i saw that the majority of EXIF dates is plausible. However, RP88 found this case where the EXIF date is not correct since they do not belong to the first uploaded file but for a modified version. To minimized such cases i would suggest to check if the EXIF date is before the date of the first upload of the file. Furthermore, i would also suggest to use {{According to EXIF data}} to make clear where the date comes from. Before doing a full run, i ask for comments and maybe later for permission to do this task for all files. --Arnd (talk) 08:13, 25 November 2015 (UTC)
- Sounds super reasonable to me. --Felipe (talk) 19:12, 24 December 2015 (UTC)