Commons talk:Tools

	SpBot archives all sections tagged with {{Section resolved\|1=~~~~}} after 2 days.

Coolest Tool Award 2022: Call for nominations

The fourth edition of the Coolest Tool Award welcomes your nominations! What is your favorite Wikimedia related software tool? Please submit your favorite tools by October 12, 2022! The awarded projects will be announced and showcased in a virtual ceremony in December. SSapaty (WMF) (talk) 12:05, 10 October 2022 (UTC)[reply]

Redesigning this page

This page is not looking very nice and it is hard to find the tool you are searching for. Additionally this page is very outdated. So I would propose to update this page. The design and structure I have in mind for the new design is the design of the tools page on Wikidata d:Wikidata:Tools. As the first step I would propose to redefine the categories for the tools. Tools can be added to multiple categories(Commons:Tools/category). To make this in an easy way ever tool should have a own subpage (Commons:Tools/toolname) that is then inserted into the category pages. I would stat with the following categories:

Uploading
Findung what to photograph
Categorization
Editing structured data
Finding files
Downloading and external reuse
Mass editing
Administration and patrolling
Statistics
Developing

GPSLeo (talk) 13:44, 1 January 2023 (UTC)[reply]

The tools should also be color coded to the different types "MediaWiki feature/extension", "Gadget", "User script", "Toolforge", "Other". And there should be a warning on outdated/unmaintained tools/currently broken tools. GPSLeo (talk) 13:49, 1 January 2023 (UTC)[reply]

many tools do have their own pages. all gadgets should have their own. external tools are like com:F2C com:v2c...

i wanted to clean up part of this page a long time ago but it's not a priority. RZuo (talk) 14:10, 1 January 2023 (UTC)[reply]

(edit conflict) Examples on how the short tool descriptions could look like:

Cat-a-lot

Gadget

Cat-a-lot is a JavaScript gadget that helps with moving multiple files between categories or adding categories to search results or files in galleries.

Activate the Gadget in your preferences

Documentation: Help:Gadget-Cat-a-lot

Categories: Categorization, Mass editing

Maintained

GLAMorgan

Toolforge

GLAMorgan shows where files of a specific category are used in Wikis in the selected month and how often these articles where viewed during this month.

glamtools.toolforge.org/glamorgan.html

Documentation: missing

Categories: Statistics

Broken

GPSLeo (talk) 14:23, 1 January 2023 (UTC)[reply]

While redesigning may make sense I'd

Oppose anything that moves tools into subpages which prevents people to have an everything-on-one page overview that can be glanced over or skipped through & searched using ctrl+F. More colors and categories/subsections may make sense, even subpages if their tool contents are fully transcluded to this page. Prototyperspective (talk) 18:25, 22 September 2024 (UTC)[reply]

Proposal: Improve Toolhub coverage of Commons tools by improving on-wiki tool documentation

TLDR: We want to help solve Commons contributors' difficulty finding the tools they need. To do this, we propose updating the tool page so that a bot can parse it and produce a toolinfo.jsonfile that Toolhub can read. We need your help in designing and applying the template. Please let us know if you have any ideas or would like to help.

Long Version
— Preceding unsigned comment added by Udehb-WMF (talk • contribs) 12:31, 1 March 2023 (UTC)[reply]

Toolhub is a community-managed catalog of software tools used in the Wikimedia movement. Technical volunteers can use Toolhub to document the tools that they create or maintain. All Wikimedians can use Toolhub to search for tools to help with their workflows and to create lists of useful tools to share with others. You can read more about Toolhub in general on meta.

The Technical Engagement team is interested in talking with you about finding more ways for the Commons community to use Toolhub. We are interested in having more tools that are helpful for workflows on Commons listed in Toolhub, and for those tools to also be more discoverable to folks who are contributing to Commons. For example, this query for user scripts known to work on Commons has only one result and there should be more.

The proposed solution

Our first idea is to update this page so that a bot can parse the page and produce a toolinfo.json file that can be read by Toolhub. Templates can be used as a source of structured data for the bot. This is simpler than using Wikibase or another structured data store. We have previously built a tool which reads en:Template:User script table row records from en:WP:USLIST to produce a toolinfo.json file documenting the English Wikipedia's user scripts. It is possible to add to this tool once we have templates on Commons to read from.

We would like to try to make a generic "Template:Toolinfo" that can record any data that toolinfo.json supports. This template would use a Lua module to decide how to render itself based on the values of various parameters such as tool_type. This would also be a good opportunity to add some visual cues for type and known status as suggested previously by GPSLeo. We would like to work with folks here on Commons who typically document tools to design and apply the template.

Our questions to you

Does this sound like a good approach?
Would you like to help with anything?
Do you have different ideas to improve the documentation and discovery of tools you use with Commons?

Please share them here. Udehb-WMF (talk) 15:24, 31 January 2023 (UTC)[reply]

a catalog is good. i was just thinking of something similar: https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=729100298#Commons_Developer_Group？ . hopefully this makes it easier for users to learn how to use each individual tool. RZuo (talk) 16:49, 31 January 2023 (UTC)[reply]

I have heard that some folks are reading this proposal (and possibly Toolhub itself) as expecting only tool builders/maintainers to edit the information for their tools. This also came with the associated feedback that maintaining quality documentation takes a group. I wanted to clarify that I and the Toolhub team agree that collaboration is important in maintaining documentation.

Features have been added since the initial release of Toolhub which make collaborative editing of the majority of the fields in a toolinfo record possible. As of 2023-02-07 there are 19 fields which are community editable. Five of these fields (wikidata_quid, audiences, content_types, tasks, subject_domains) are only available in the "annotations" layer that the community maintains. The other 14 are duplicated from the core toolinfo standard and exposed as community editable fields only if the core toolinfo data does not include data for that field.

Toolhub does still have an "ownership" model where the initial creator of a record has more control than the community including the ability to edit 13 core toolinfo fields (name, title, description, url, authors, license, etc) which are currently denied to the general community. This proposal is to collaboratively maintain the core toolinfo data for Commons tools here on-wiki which would allow community editing of all of this source information. When this data is ultimately imported into Toolhub by its web crawler, it will be seen as owned by a single user within the Toolhub database and interface. That owner is relatively unimportant however as toolinfo records managed by the crawler cannot be edited via the Toolhub UI or API. Instead edits are expected in the origin data which will be picked up by a future run of the crawler. -- BDavis (WMF) (talk) 17:53, 7 February 2023 (UTC)[reply]

I know that this sounds like science fiction, but having external tools instead of internal will always be sub-optimal. Wouldn't it be harder but better to integrate this tools into Commons, instead of having an external and hard to discover catalog? Theklan (talk) 20:42, 25 February 2023 (UTC)[reply]

This project is a part of a longer journey. I am working to enable bi-directional interaction between the wikis and Toolhub in an attempt to get benefits from both local action and centralized data aggregation. First I worked to create Toolhub as a central repository of data. Now I am trying to work with wikis to find ways to get more data into that central repository. In the future I would like to work on experiments like Extension:Toolhub that would allow the wikis to fetch data from the central Toolhub repository for their local needs.

For the near term I think that focusing on projects like this proposal with the intent of getting more high quality data into the central catalog is most important. The concept of templates that are configured by toolinfo.json data that I use in my proof of concept would directly translate into templates that are populated with Toolhub API responses in the future. -- BDavis (WMF) (talk) 17:54, 28 February 2023 (UTC)[reply]

Proof of concept template implementation

I have prepared a proof of concept demonstration of how a template based system for this could work. I have done the work on a demonstration wiki hosted in Toolforge. Here is an explanation of what I have built:

Subpages of Commons tools/data use Template:Toolinfo to document tools using a template modeled on the toolinfo.json standard used by Toolhub. Each page has one structured data template describing a single tool.

The Toolinfo template on each data page is also used as a parameter to a Scribunto call which renders the structured data in a format very similar to a Toolhub detail page. This is intended to show how we could make the data pages valuable on-wiki for more than just feeding data to other templates and bots. Alternately the structured data could be rendered as highlight syntax highlighted JSON or as a table that looks like JsonContentHandler output.

The Commons tools/Cards page uses Template:Toolinfo/Card to render the data from Commons tools/data pages in a style similar to wikidata:Template:Tool2.

The Commons tools/Sections page uses Template:Toolinfo/Section to render the tools from Commons tools/data in a style inspired by a design proposal made by User:GPSLeo.

There are a number of things that would still need to be implemented to make this proof of concept work well here on Commons. There is work to be done with the Lua module to divide things up to make reuse easier and also to support localizing strings. The rendering templates could use more work to make sure that their CSS works well at various screen sizes. Accessible color combinations need to be chosen for colored labels used in the section template. I'm sure there are other things as well that will come up as folks discuss the implementation. I look forward to finding consensus on a direction to take and some folks who are interested in working to build a more functional and engaging collection of tools documentation.

--BDavis (WMF) (talk) 17:21, 28 February 2023 (UTC)[reply]

One thing I noted: the ./Cards subpage has a lot of color coding without any legend or explanation. I'm guessing it's the same as on the ./Sections subpage, but there is no way for me to figure that out from ./Cards. El Grafo (talk) 14:21, 7 March 2023 (UTC)[reply]

In ./Sections, I find it a bit difficult to figure out which set of [v t e] links belongs to which tool. The [activate] links look a bit lost too. Similar for ./Cards. I feel the urge to propose a box around each tool, but there must be a prettier solution. El Grafo (talk) 14:34, 7 March 2023 (UTC)[reply]

For the card view, I think that adding a visible border is actually a reasonable fix. I have updated the POC to do that using a Material Design style drop shadow.

I don't think a border treatment is ideal for sections, so we need to think up a better placement for the [v t e] links there instead.

I have tried to fix the [activate] links on sections by removing their default float:right. The css for sections already was setup to do this, but at some point I broke that by removing a wrapper div. I am open to better ideas for the install instructions in general if this is still confusing or distracting. -- BDavis (WMF) (talk) 00:48, 11 March 2023 (UTC)[reply]

That's more a shadow than a box - works well and looks good. Color coding has too many too similar colors to be of much use, though. Maybe consider grouping the finer grained classes of tools into more general groups like "things you can use on-wiki", "external online tools", "things you need to install on your device", "things you need coding skills for" and use color coding for that. Could still keep the current classes at ./Sections. [activate] links seem to have disappeared? El Grafo (talk) 08:19, 13 March 2023 (UTC)[reply]

Color coding has too many too similar colors to be of much use, though.

I personally feel like the colors work ok on the section view where color + icon + words are used. I think I understand that @El Grafo agrees on that.

The card view is more challenging as currently that is really trying to use only color to hint the type of each tool. Even with a legend I think that will remain challenging. It turns out that finding 10 accent colors that are accessible to folks with various color vision issues, have good contrast with black text, and are obviously distinct from from each other is not a trivial task. Folks can certainly iterate on this over time, but I think for the initial implementation I am going to give up on color coding and instead use the same edge color everywhere as wikidata:Template:Tool2 does.

[activate] links seem to have disappeared?

The change I made on the section view was to fix the css so that the [activate] label that toggles the collapsed instructions stays inline rather than floating to the right. They should still appear under the "by" line on user script and gadget records. -- BDavis (WMF) (talk) 22:33, 13 March 2023 (UTC)[reply]

Just a note that I haven't given up on this project, but I did fall into working on a number of other things in past month. -- BDavis (WMF) (talk) 15:40, 25 April 2023 (UTC)[reply]

VFC

Hi, In last August, I wrote a request for Adding the source in display preview. It would be very helpful to have the source shown in the display preview, i.e. to detect copyright violations.

There wasn't any reaction then. Yann (talk) 17:22, 31 January 2023 (UTC)[reply]

It was also suggested to add support for {{Wrong license}} into MediaWiki:Gadget-QuickDelete.js and MediaWiki:Gadget-VisualFileChange.js. Yann (talk) 17:28, 31 January 2023 (UTC)[reply]

@Yann, can you help me understand how your feature request for VisualFileChange.js is a sub topic of improving documentation of Commons tools on-wiki and in Toolhub? I am not yet understanding the connection. -- BDavis (WMF) (talk) 17:40, 31 January 2023 (UTC)[reply]

Well, it is not a request to improve the documentation, but some of the tools. Yann (talk) 18:03, 31 January 2023 (UTC)[reply]

Would you object to moving it from an H3 under our proposal to its own H2 so that it is clear that you are asking for help with a separate issue? -- BDavis (WMF) (talk) 18:29, 31 January 2023 (UTC)[reply]

OK, fine.

Done Yann (talk) 19:10, 31 January 2023 (UTC)[reply]

Wiki 2 Wiki tool or bot?

Is there a Wiki 2 Wiki tool or bot to transfer images from en-wiki to cy-wiki, similar to Flickr2Commons? All images are on fair use licences (around 10,000 images in the Category:Films, mostly posters). Thanks for any pointers. BOT-Twm Crys (talk) 09:59, 10 November 2023 (UTC)[reply]

Coolest Tool Award 2024: Call for nominations!

The fifth edition of the Coolest Tool Award is here again! 🛠️ Nominate your favorite tools and celebrate the incredible developers behind them. Nominate here. The top tools will be announced at Wikimania 2024. SSapaty (WMF) (talk) 04:21, 19 April 2024 (UTC)[reply]

Tool for checking if an image is already uploaded

Is there a tool for checking if an image is already present on Commons, such as Google Images? This would be very helpful and prevent duplicates. --Wickey (talk) 14:20, 21 September 2024 (UTC)[reply]

Since recently there is https://imagehash.toolforge.org/ (see phab:T167947). What is needed is a check for previous uploads of the same file during upload (e.g. in the Upload Wizard) like present in much smaller media sites. This really is overdue and would be very useful. This may also improve file titles among other things. If a new issue or proposal is created, please link it here. Prototyperspective (talk) 14:34, 21 September 2024 (UTC)[reply]

Thanks. Integration in the Upload Wizard was just my thought. Imagehash Search should be mentioned on this project page and included in the Participate section of the sidebar as well.--Wickey (talk) 15:16, 22 September 2024 (UTC)[reply]

Well there is a check whether the exact same file has been uploaded before in the Upload Wizard. Should I have said that earlier. Secondly, that imagehash tool that I think is also supposed to show similar images never worked in my tests so if I search by uploading an image I recently uploaded it shows 0 results. I asked about similarity detection here. The Upload Wizard afaik doesn't prevent reuploads if the file is only slightly different or exactly the same but a different filetype. Please clarify if your question is solved. Also I don't know what you mean with including it in the Participate section. I don't think it should be mentioned here because it's not a scalable user-friendly method but more something to develop further and then integrate e.g. into the Upload Wizard or sth similar and because it largely doesn't seem to work at this point(?) Prototyperspective (talk) 18:22, 22 September 2024 (UTC)[reply]

I hinted on the sidebar left on every page (vector skin). My question is not really solved. I had in mind the mentioned Google Images search. If I upload an image from my pc, Google will search for exactly the same images. What you have in mind is something like TinEye. Wickey (talk) 09:36, 23 September 2024 (UTC)[reply]

See the talk page of this proposal: Search Wikipedia with image or sketch search and this proposal is also relevant. Currently, the best way to check whether an image is already uploaded or to find the link to these is to upload it in the UploadWizard – there is not really any difference to searching for an exact image match in another way but maybe info should be added somewhere that the Upload also checks for exact file matches. It does search for exact matches like TinEye (imo it should also show very similar ones so you can decide if these are actually the same or maybe interlink them). Prototyperspective (talk) 09:44, 23 September 2024 (UTC)[reply]