Template talk:Commons category/Archive 2
This is an archive of past discussions about Template:Commons category. 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. |
Archive 1 | Archive 2 |
The next steps with this template and Wikidata
Hi all. I've been enthusiastically using this template a lot over many years to provide links from articles to Commons categories. However, the situation has changed now that we have Wikidata, I've recently been spending quite a bit of time to write and run bot code to improve the links between Commons categories and Wikidata, primarily through the sitelinks, but also with the P373 values. The bot tasks are described at User:Pi bot - of particular interest is that I've been fixing sitelinks to category redirects on commons (and echoing those changes in the P373 values). I'm not currently updating the links here, though, as I'm not sure what is best for the future of this template.
As I see it, the options for the next steps with this are (starting from the most controversial):
- Since we now have the Commons link in the left-hand sidebar, which uses the Wikidata interwiki links directly and is always present where such a link is available, we could scrap this template, and use a bot to migrate any local-only values to Wikidata. This means starting a deletion discussion for this template.
- We could switch to using Wikidata as the main source of the Commons link (ideally through the sitelink, but with fallback to P373 if needed). We could bot-remove local parameter values where they are the same as on Wikidata, and then sort through the remaining discrepancies with bot-assistance where possible (e.g. where we're currently links to category redirects) or manually otherwise. This means starting an RfC to implement this change.
- We could maintain the status-quo, and I could modify my bot codes to also update the links here to avoid redirects, although that's more complicated than maintaining them on Wikidata. We'd probably also need a code to check for deleted Commons categories (these are automatically handled by the commons sitelinks on Wikidata, although this still needs sorting out for the P373 values). This means a number of bot requests to get the newly-written scripts running.
What does everyone think - which option would be best? Personally, I'm torn between (1) and (2), both of which significantly simplify maintenance of the links in the future by using Wikidata, but I'm conscious that using Wikidata can be quite controversial here. Thanks. Mike Peel (talk) 23:56, 12 May 2018 (UTC)
- Pinging @WOSlinker, Redrose64, Fayenatic london, Rich Farmbrough, MSGJ, Nyttend, Keith D, and Pigsonthewing: as editors who have modified the template in 2015 or later. Thanks. Mike Peel (talk) 22:01, 14 May 2018 (UTC)
- I have to oppose the first option. Looking left makes sense for Wikipedia articles in other languages (sometimes there's a long list that's eye-catching, and that means that many people will naturally look there), but for other kinds of WMF projects, it doesn't; often we don't have anything (so people don't notice), and if we do have anything, it's generally one or two items. Conversely, this box is nice and obvious. Moreover, this box is the same style as other other-WMF-project boxes, e.g. {{Wikispecies}}, {{Wikinews}}, and {{Wikiversity}}; people familiar with our layout will expect links to other projects to appear in boxes like this, so getting rid of it in favor of a left-side link will be unhelpful. I'm not sure what to say on 2-versus-3, but please don't change the visual elements of this box unless there's consensus to get rid of boxes like this in general. Nyttend (talk) 22:09, 14 May 2018 (UTC)
- There are uses of this template several times in some articles pointing to different categories on commons. It is not a 1 to 1 relationship between article and commons category as a result the status quo should be maintained and we should NOT remove local links from the template nor should the template be deleted. Keith D (talk) 22:13, 14 May 2018 (UTC)
- I'm OK with not going for #1, although it means that arguments about the exact placement of the box will continue. @Keith D: How about removing local links where they are 1-to-1 (i.e., they are the only commons category on Wikidata), but leaving the other ones? Thanks. Mike Peel (talk) 22:21, 14 May 2018 (UTC)
- Personally I would keep the local link, if it appears in an article, and just flag-up when there is a difference between the values and allow it to be manually corrected if necessary. Keith D (talk) 22:28, 14 May 2018 (UTC)
- I'm OK with not going for #1, although it means that arguments about the exact placement of the box will continue. @Keith D: How about removing local links where they are 1-to-1 (i.e., they are the only commons category on Wikidata), but leaving the other ones? Thanks. Mike Peel (talk) 22:21, 14 May 2018 (UTC)
- There are uses of this template several times in some articles pointing to different categories on commons. It is not a 1 to 1 relationship between article and commons category as a result the status quo should be maintained and we should NOT remove local links from the template nor should the template be deleted. Keith D (talk) 22:13, 14 May 2018 (UTC)
- I have to oppose the first option. Looking left makes sense for Wikipedia articles in other languages (sometimes there's a long list that's eye-catching, and that means that many people will naturally look there), but for other kinds of WMF projects, it doesn't; often we don't have anything (so people don't notice), and if we do have anything, it's generally one or two items. Conversely, this box is nice and obvious. Moreover, this box is the same style as other other-WMF-project boxes, e.g. {{Wikispecies}}, {{Wikinews}}, and {{Wikiversity}}; people familiar with our layout will expect links to other projects to appear in boxes like this, so getting rid of it in favor of a left-side link will be unhelpful. I'm not sure what to say on 2-versus-3, but please don't change the visual elements of this box unless there's consensus to get rid of boxes like this in general. Nyttend (talk) 22:09, 14 May 2018 (UTC)
- The default assumption has been that the category has a matching name. This is time saving, but fails if the article is moved. For this reason I have been adding the article name to "empty" uses of the template. The Wikidata solution would seem better. All the best: Rich Farmbrough, 13:56, 16 May 2018 (UTC).
- The propositions seem to confuse two things: the placement of the template and its appearance, with the sourcing of the "correct" link on Commons. Although the second seems as if it will inevitably shift to Wikidata, that is no reason at all to discard the template, its recognisable value to readers (especially casual readers) and the ability to control its formatting and placement in a fairly straightforward manner.
- Secondly, reliance on Wikidata has its own issues. It removes editing control from en:WP to the shared Wikidata repository (and the arcane knowledge, "travel to a different wikiproject and edit property P373", rather than just inserting a template). What if other language wikiprojects decide to edit war further over the canonical source for populating wikidata, and which language project gets to control the version of things (We've just had the recent case of James Watt being a "mathematician" because of an unsourced throwaway comment on it:WP). Also would this now limit en:WP to just a single Commons link from articles? Andy Dingley (talk) 14:12, 16 May 2018 (UTC)
- @Andy Dingley: I was thinking that this would only apply to 1-to-1 links, for more complex cases we'd stick with the existing system of manually-defined names. Isn't this a case where we want to outsource the links and their maintenance to another project - namely, Commons? Ideally, we'd use the Commons sitelinks rather than P373, which we've been adding a lot on Wikidata to show the interwiki links on Commons (and power the infobox there), since that updates automatically when things are moved around (and there are bots that mirror updates into P373). Thanks. Mike Peel (talk) 14:59, 16 May 2018 (UTC)
- Why do we want to outsource anything? en:WP has standards for sourcing. Wikidata does not. The infoboxes appearing on Commons seem to swing between the pointlessly trite (understandable) and the downright inaccurate, because Wikidata has scraped up some unsourced / untrue snippet from the Elbonian WP and prioritised it as the main term to highlight in the box. The last thing we need is to have Wikidata content backwashing onto en:WP. Andy Dingley (talk) 16:48, 16 May 2018 (UTC)
- Um, how do we source commons category links? Mike Peel (talk) 17:13, 16 May 2018 (UTC)
- They're edited, on en:WP, by en:WP editors, subject to en:WP policies. It's a minor issue for mere Commons linkage, but it's going to be much bigger when it involves populating infoboxes. There is already endless edit-warring over pushing Commons category names in the English language into German grammar and idioms. Andy Dingley (talk) 23:19, 16 May 2018 (UTC)
- Um, how do we source commons category links? Mike Peel (talk) 17:13, 16 May 2018 (UTC)
- Why do we want to outsource anything? en:WP has standards for sourcing. Wikidata does not. The infoboxes appearing on Commons seem to swing between the pointlessly trite (understandable) and the downright inaccurate, because Wikidata has scraped up some unsourced / untrue snippet from the Elbonian WP and prioritised it as the main term to highlight in the box. The last thing we need is to have Wikidata content backwashing onto en:WP. Andy Dingley (talk) 16:48, 16 May 2018 (UTC)
- @Andy Dingley: I was thinking that this would only apply to 1-to-1 links, for more complex cases we'd stick with the existing system of manually-defined names. Isn't this a case where we want to outsource the links and their maintenance to another project - namely, Commons? Ideally, we'd use the Commons sitelinks rather than P373, which we've been adding a lot on Wikidata to show the interwiki links on Commons (and power the infobox there), since that updates automatically when things are moved around (and there are bots that mirror updates into P373). Thanks. Mike Peel (talk) 14:59, 16 May 2018 (UTC)
- As an example of the sort of rubbish that comes from Wikidata, have a look at c:Category:Jon Pertwee. This has a red error message Warning: Default sort key "Pertwee, Jon, John, Devon, Roland" overrides earlier default sort key "Pertwee, Jon". which is apparently due to d:Q467601#P735 having four given names, two of which are variant spellings of each other. --Redrose64 🌹 (talk) 10:43, 17 May 2018 (UTC)
- @Redrose64: The bot will automatically come back to that category to disable the defaultsort from the infobox for a manual check. But in this case, there's duplication between 'Jon' and 'John' that I agree shouldn't be there, the other two are his middle names as far as I can see? Also, this is somewhat off-topic... Thanks. Mike Peel (talk) 11:22, 17 May 2018 (UTC)
- this edit fixed this - I marked 'Jon' as his preferred name on Wikidata since that's the one he's most known by. Thanks. Mike Peel (talk) 11:28, 17 May 2018 (UTC)
- No, it's due to bad coding on this wiki. The data on Wikidata is correct and valid. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:32, 19 May 2018 (UTC)
- @Redrose64: The bot will automatically come back to that category to disable the defaultsort from the infobox for a manual check. But in this case, there's duplication between 'Jon' and 'John' that I agree shouldn't be there, the other two are his middle names as far as I can see? Also, this is somewhat off-topic... Thanks. Mike Peel (talk) 11:22, 17 May 2018 (UTC)
Placement of template
A discussion regarding the placement of this template is occuring at Talk:Main Street station (Toronto)#Placement of "Template:Commons category". The input of others would be appreciated. Magnolia677 (talk) 09:13, 15 June 2018 (UTC)
Suggestion to change the rules for displaying pages in Category:Commons category with page title different than on Wikidata
Hello!
Since quite some time I continue to link on wikidata all items listed in Category:Commons category template with no category set. Now I've started as well working on Category:Commons category with local link different than on Wikidata and I noticed that for a relevant number of items listed in this last category this is due to the fact that the Commons category put as parameter 1 in the Template:Commons category (respectivly the other templates with the same aim) has in the meantime been moved on Commons in order that this target category is now a redirect to another c ategory on Commons. From my perspective the easiest way to fix the fact that clicking on the Commons cat link generated by this template leads you to the redirect category on Commons, is to put the Commons category template without the parameter 1. This is due to the fact that in quite some cases (if not the vast majority) the Commons category link and/respectivly the P373 property have been defined on wikidata. (here are some examples for which I proceeeded like this: Category:People from Aberdeen, South Dakota, Category:16th-century Tibetan people, Category:1′E h2 locomotives).
Except that this will take some time to go through all the pages listed on Category:Commons category with local link different than on Wikidata to improve this, inoticed the following:
The Category:Commons category with page title different than on Wikidata is including 3 previously mentionned examples: Category:People from Aberdeen, South Dakota, Category:16th-century Tibetan people, Category:1′E h2 locomotives which include the template Commons category without a value for parameter1 (catname). I do not see any added value in having such articles and/or categories listed in this maintenance category. For this reason I suggest to not include in the Category:Commons category with page title different than on Wikidata. UNfortunately I do not have the technical knowledge to chage this myself. I wpould be grateful to get some feedback on this proposal.
Moreover I'm interested on whether someone is using the Category:Commons category with page title different than on Wikidata and in which way.
- Pinging @WOSlinker, Redrose64, Fayenatic london, Rich Farmbrough, MSGJ, Nyttend, Keith D, Pigsonthewing, and Mike Peel: as editors who have modified the template in 2015 or later.
Thanks. --Robby (talk) 18:32, 19 August 2018 (UTC)
- Comment The category is present when more than one Commons link is used on a page with different targets so just removing the parameter may not give what was intended by the link. So if the link is to a redirect then the link should be changed rather than removed. Keith D (talk) 18:41, 19 August 2018 (UTC)
RfC: Switch to using Wikidata for interwiki links to Wikimedia Commons
Please see Wikipedia:Village_pump_(proposals)/Archive_153#RfC:_Switch_to_using_Wikidata_for_interwiki_links_to_Wikimedia_Commons - and comment there! Thanks. Mike Peel (talk) 18:08, 25 August 2018 (UTC)
- This conversation ended and is not taking more comments. I updated the link to the conversation archive. Blue Rasberry (talk) 13:35, 11 November 2018 (UTC)
Please test a new version of this template
Hi all. As a first step following the RfC about switching to using Wikidata for interwiki links to Wikimedia Commons, I've rewritten this template at {{Commons category/sandbox}}. Significant things that I have changed are:
- Rather than using Commons category (P373), it uses sitelinks to Commons categories either from the connected Wikidata item or the topic's main category (P910) item (with thanks to @RexxS: for the Lua function). Sitelinks to galleries are ignored. This should minimise broken links or vandalism, as the commons category has to exist to be a sitelink, and the sitelink is automatically updated if a category is moved, or removed if it is deleted. If a sitelink isn't available, it falls back to using P373. If the category is manually defined, then it still always uses that - if not, and if there is no Wikidata link, then the pagename is used.
- I have defined a new set of tracking categories, so that we can temporarily have tracking categories that are specific to this template (and not from {{Commons category-inline}} etc.). They are redlinks for now, I'll create them before updating this template from the sandbox. These would be:
- Category:Commons category link is on Wikidata - we have a locally defined link, and it's the same as Wikidata
- Category:Commons category link is defined as the pagename - the locally defined link is the pagename, but it's not the same as on Wikidata, or it is not on Wikidata
- Category:Commons category link is locally defined - the locally defined link is not the pagename, and it's not the same as on Wikidata, or it is not on Wikidata
- Category:Commons category link from Wikidata - we are using Wikidata for the link
- Category:Commons category link is the pagename - we are using the pagename for the link, there is no link on Wikidata
Please test {{Commons category/sandbox}} and let me know if you spot any problems or if you have any other comments on the changes. I'd like to deploy this new version next week. If that goes OK, then the next step would be to investigate why pages are appearing in tracking categories #2, 3, 5 above, and for me to write some bot code that can start resolving some of those issues (either by adding the commons sitelinks on Wikidata, or finding cases that point to redirects), which would head to a bot request. Pages appearing in tracking categories #1 and #4 are already OK, and systematically moving them from #1 to #4 (so that they don't end up in #2 or #3 due to e.g. a category move on commons) would be the subject of a follow-up RfC.
Pinging those that participated in the RfC: @AGK, Robby, Rhododendrites, Alpha3031, AfroThundr3007730, Johnbod, Jo-Jo Eumerus, Fram, Izno, GermanJoe, Compassionate727, Keith D, Peter coxhead, Ammarpad, Killiondude, Rschen7754, Nihlus, Finnusertop, ARR8, Bidgee, Bluerasberry, GreenMeansGo, PBS, Alsee, Wikisaurus, and Nemo bis: - also, @Achim55: might be interested in this.
Thanks. Mike Peel (talk) 22:06, 10 November 2018 (UTC)
- I think I understand the intent here but there is a mix of a new proposal and documentation which is not updated here.
- Remind me - the intent of this proposal is to change {{Commons category}}, not make a new template, right? And the change is to seek to match a Wikidata category connections rather than manually sorting them out for the articles, right? That sounds great, and seems to me likely to greatly increase quality control for English and other languages and expand the scope of coverage for many languages of Wikipedias.
- I understand the 5 categories above. Help me understand - what is the default output of Commons category when nothing is filled in? Is that category #5, "Commons category link is the pagename", where the template goes from the article to Commons seeking an exact match of the Wikipedia article title as a Commons category?
- I see the possiblity of multiple steps here, and it is not obvious to me why any early steps need to put Wikidata content directly into Wikipedia mainspace. For example, a first step could be filling out these administrative categories to get some insight into when Wikipedia, Wikimedia Commons, and Wikidata have information which is in alignment.
- Can you explain category #4, "Commons category link from Wikidata"? Do we already do that in English Wikipedia, or is this a new function that is being proposed? So far as I know, there is not currently a way to call Commons categories from Wikidata to direct English Wikipedia.
- Something else - in this scheme, no Wikidata identifiers ever appear in English Wikipedia, right? The matching is in Wikidata, so Q items never appear in English Wikipedia. Is this correct?
- Thanks. Blue Rasberry (talk) 13:33, 11 November 2018 (UTC)
- @Bluerasberry: Yes, the idea is to update this template with the new version. This template already uses P373 to supply some values from Wikidata, the new code upgrades that to use the sitelinks. No Q codes will appear, the only content shown is the category title from the sitelink. The default if nothing is filled in and there is nothing on Wikidata is to use the pagename, which is category #5. If nothing is filled in but there is something on Wikidata then it's #4. The existing tracking categories we have are Category:Commons category with local link different than on Wikidata (roughly corresponding to #3 above, also partly #2), Category:Commons category with page title different than on Wikidata (roughly #2, also partly #3) and Category:Commons category without a link on Wikidata (roughly #5) (also Category:Commons category with local link same as on Wikidata and Category:Commons category with page title same as on Wikidata, but they were deleted, these correspond with #1 above). #4 happens already but isn't tracked. The new tracking categories hopefully improve the tracking of the existing commons category links, without changing the displayed links if local links are already defined, use the pagename, or if they already use Wikidata (it just changes to using the sitelink if available rather than P373 in that case). Hope that helps. Thanks. Mike Peel (talk) 13:58, 11 November 2018 (UTC)
- Yeah, I feel like this should be really intuitive but my brain is struggling somehow. Am I wrong saying that the end game here is to have a bot that mass adds these and syncs everything up on WP with WD, and then syncs everything on WD from WP? That would be great, because I've manually added probably ten thousand sister links across all projects, and I can think of many many things that are more rewarding and less tedious. That would be especially nice if we're creating a "template" (in the mundane sense, not the
{{}}
sense) that can be applied to other sister link templates, and standardize all the things. But I'm still a WD noob, so I'm probably missing many of the finer points. GMGtalk 14:12, 11 November 2018 (UTC)- @GreenMeansGo: broadly speaking, yes - it's to sync up the links between enwp + wikidata + commons, to fix cases where they are wrong, and to automatically keep them in sync in the future. Thanks. Mike Peel (talk) 15:09, 11 November 2018 (UTC)
@Mike Peel — Please put some tests/examples in Template:Commons category/testcases -- PBS (talk) 15:28, 11 November 2018 (UTC)
- @PBS: That's a bit difficult, as the template uses the page's sitelink, and categories are only shown when the template is used in articles and categories. But I've added a qid parameter to the template sandbox, and I've added a couple of examples of the wikidata code. I've also added a couple of live examples at South Pole Telescope and Lovell Telescope. Thanks. Mike Peel (talk) 15:50, 11 November 2018 (UTC)
- FYI, I'm going to make this live in the next few hours. Thanks. Mike Peel (talk) 20:04, 14 November 2018 (UTC)
- It's now live. Thanks. Mike Peel (talk) 20:21, 14 November 2018 (UTC)
It's been 12 days since I posted the new version, and it seems to be working OK. The current stats are:
- Commons category link from Wikidata (2,517 C, 92,905 P)
- Commons category link is defined as the pagename (1,981 C, 6,858 P)
- Commons category link is locally defined (3,286 C, 14,442 P)
- Commons category link is on Wikidata (111,163 C, 194,666 P)
- Commons category link is the pagename (12 C, 31 P)
I've also now made the same change to {{Commons category-inline}}. Thanks. Mike Peel (talk) 23:22, 26 November 2018 (UTC)
- I've just added Category:Commons category link is on Wikidata using P373 as a new tracking category for cases where Commons category (P373) is used rather than the commons sitelink. Thanks. Mike Peel (talk) 20:54, 4 December 2018 (UTC)
Maintenance bot proposal
I've just proposed Wikipedia:Bots/Requests for approval/Pi bot 4 to fix or remove commons category links that are missing, or are to category redirects or disambiguation categories. If you're interested, please comment there! Thanks. Mike Peel (talk) 20:26, 1 January 2019 (UTC)
Edit request 24 January 2019
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Template is currently broken – no idea what's wrong with it: hopefully a Template editor can figure it out... --IJBall (contribs • talk) 00:28, 24 January 2019 (UTC)
- Already done There was a vandal. Should be fixed now. Izno (talk) 02:50, 24 January 2019 (UTC)
Problematic template
This template [as well as other interwiki templates on en.wiki] is becoming highly problematic.
I noticed that en.wiki relies very little on data published on Wikidata and still has a lot of parametres on their interwiki templates that can be read on Wikidata.
This leads bots like @Pi bot: to import on Wikidata missing / false / broken / obsolete / improper interlinks from Commonscat parametres on en.wiki, see this last one. In my opinion parametres are no longer useful on Commonscat template and a bot should remove them. In the last week I had to fix a lot of errors on Wikidata that were made on the ground of wrong parametres on Commonscat (basically the parametre linked to a Commons category which is no longer in use or is redirected). -- SERGIO aka the Black Cat 09:07, 2 June 2019 (UTC)
- @Blackcat: You might be interested in Wikipedia:Village_pump_(proposals)#RfC:_Removing_locally-defined_links_to_Commons_categories_if_they_match_the_Wikidata_sitelinks. BTW, with your example, Pi bot will also sort out links to commons category redirects wherever it can, e.g. [1] - but it does that as a separate task from adding the sitelink. Thanks. Mike Peel (talk) 10:30, 2 June 2019 (UTC)
- Thanks @Mike Peel:. Of course I'm not blaming your bot, it does its work. I'm only pointing out the uselessness of using parametres in Commonscat whereas there's a link from 'data. -- SERGIO aka the Black Cat 11:19, 2 June 2019 (UTC)
Checking via code if a commons link exists
Is there are a way via code to check if a commons link exists, and if so display the template? The lead says that if that category name is misspelled or missing, the link will still appear "blue" even though the link will fail
, so hoping to find away around that. --Gonnym (talk) 07:30, 10 August 2019 (UTC)
- @Gonnym: I don't know if it's possible in mediawiki code, but Pi bot removes links to commons categories that don't exist, with the exception of categories that don't exist but still have images in them (for example, see Indian Institute of Technology Jodhpur / commons:Category:IIT Jodhpur). Thanks. Mike Peel (talk) 07:42, 10 August 2019 (UTC)
- According to Wikipedia:Bots/Requests for approval/Pi bot 4 it uses a tracking category to do that, so not applicable to my needs. Thanks though. --Gonnym (talk) 07:47, 10 August 2019 (UTC)
- Yes. Those tracking categories are added where the link doesn't match the sitelink on Wikidata, and the Wikidata sitelinks can only exist if the commons category actually exists. For cases where there is a commons category but this template isn't used, then you'll see the commons link in the left-hand bar. Thanks. Mike Peel (talk) 08:03, 10 August 2019 (UTC)
- According to Wikipedia:Bots/Requests for approval/Pi bot 4 it uses a tracking category to do that, so not applicable to my needs. Thanks though. --Gonnym (talk) 07:47, 10 August 2019 (UTC)
Cat1= and Cat2=
For a page with more than one category, suggest use cat1= and cat2= parameters (i.e. Joss_paper#See_also)-. --BoldLuis (talk) 22:10, 10 April 2020 (UTC)
- @BoldLuis: In that case, you only need to link to one commons category, commons:Category:Joss paper - that has the relevant part of ritual furnaces, commons:Category:Joss paper furnaces, as a subcategory. Thanks. Mike Peel (talk) 06:42, 11 April 2020 (UTC)
- OK, thanks. BoldLuis (talk) 01:29, 19 April 2020 (UTC)
Checking links
Hi all. I've prepared a new version of this template at {{Commons category/sandbox}} that adds a notice saying "Does not match Wikidata - please check", with a link to this thread for an explanation (although perhaps a link to a FAQ subpage might be better). The message is only shown to logged-in users. Over the last 1.5 years, myself and others (particularly @Robby) have been working through the mismatches between the Commons interwiki links on Wikidata and the locally defined links here, and we're now reaching the point where the causes of the mismatches are less obvious and need input from editors that are knowledgeable about the category/article topics, or need discussion. While the template already adds tracking categories for those cases (see subcats of Category:Commons category Wikidata tracking categories), those probably aren't obvious to editors, and adding this message would make it more obvious to editors while not distracting readers.
I've started writing a FAQ on how to resolve these at User:Mike Peel/Resolving commonscat discrepancies - feel free to expand or correct it. I'd like to make the new version live shortly, any comments/suggestions/objections? Thanks. Mike Peel (talk) 19:37, 24 April 2020 (UTC) Pinging people that commented in 'Please test a new version of this template' above, @Bluerasberry, GreenMeansGo, and PBS:. Thanks. Mike Peel (talk) 14:57, 25 April 2020 (UTC)
- Support - looks like a good idea. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:43, 24 April 2020 (UTC)
- Support - Indeed often Commons cat is added without checking whether a corresponding category on Commons exist and in this way at least the editors would see that there is an issue with the category on Commons. Robby (talk) 11:53, 25 April 2020 (UTC)
- Question I followed the links you shared and was unable to find a live example of the "Does not match Wikidata" problem you want to address. There is also no example given in this proposal. Can you either link to a live case? Or even better, since I think it is not possible to archive a live case, can you copy/paste enough text and the circumstances of a live case of "Does not match Wikidata" to demonstrate an occurrence of the sort to which this notice will send editor attention? Blue Rasberry (talk) 15:16, 25 April 2020 (UTC)
- @Bluerasberry: Good point, sorry. You can see it here. It only shows up in mainspace, and you have to use the sandbox version to see it. Thanks. Mike Peel (talk) 15:19, 25 April 2020 (UTC)
- @Mike Peel: Okay, I see the proposed template in use in the link you shared. I think all of this compares
- Category:Arthrodermataceae, the category in English Wikipedia,
- commons:Category:Arthrodermataceae, the category in Commons, and
- Category:Arthrodermataceae (Q9468276), the Wikidata item for what ought to be the cross-wiki Wikimedia category.
- I am looking at these three and do not see why your proposed template is saying "Does not match Wikidata". These all seem to match. What is the error in these categories which this proposed template seeks to reconcile? Blue Rasberry (talk) 15:39, 25 April 2020 (UTC)
- @Bluerasberry: In this case, the enwp sitelink is missing from Category:Arthrodermataceae (Q9468276) - an easy fix. It's just the case I was testing the code on, I didn't chose it for its difficulty in reconciling. Have a look through Category:Commons category link is locally defined for many other (better) examples. Thanks. Mike Peel (talk) 15:57, 25 April 2020 (UTC)
- @Mike Peel: Okay, I see the proposed template in use in the link you shared. I think all of this compares
- @Mike Peel: Okay, I see in that Wikidata item there is this list of languages which Wikidata has indexed for this Wikimedia category. Various languages are there, but not English Wikipedia. The way to correct this error is to add a link to Category:Arthrodermataceae at Category:Arthrodermataceae (Q9468276) in this box.
- Can you explain what this has to do with Commons? This looks like missing information in Wikidata which we fix with a link to English Wikipedia. How does the corresponding category in Wikimedia Commons help identify this problem? Am I describing all this correctly? Blue Rasberry (talk) 16:16, 25 April 2020 (UTC)
- @Bluerasberry: You're getting hung up on the example I gave to show how the template looks, as you say that one is easily fixed. Have a look at some other examples in that category - e.g., Category:Administrative divisions. Thanks. Mike Peel (talk) 16:23, 25 April 2020 (UTC)
- @Pigsonthewing, Robby, and Bluerasberry: This is now live. I updated the link to point to Template:Commons_category#Resolving_discrepancies for hints on how to resolve the discrepancies. Thanks. Mike Peel (talk) 17:07, 8 May 2020 (UTC)
- There needs to be a way to supresss the error message once you have checked and confirmed the category is correct. Kerry (talk) 12:46, 10 May 2020 (UTC)
- And it should not be displayed to users. It is an internal issue and should not be visible to any reader.Kerry (talk) 12:53, 10 May 2020 (UTC)
- It seems the presumption is that Wikidata is right (as there appears to be no corresponding error report on Wikidata) and Wikipedia is wrong. How about not presuming blame at Wikipedia and put a more neutral message that appears on both sites (and can be overriden after checking). Kerry (talk) 12:58, 10 May 2020 (UTC)
- It seems the "problem" in the article I am working on is that it has a Commons Category but the Wikidata entry does not. The only way I can fix it is to remove the commons category from the Wikipedia article! Kerry (talk) 13:14, 10 May 2020 (UTC)
- @Kerry Raymond: It is only displayed to logged-in users. Do you want to suggest a more neutral message? If you want to give examples, then I can give specific feedback on them, but if the Wikidata entry is missing the commons category then one way to resolve that would be to add the link to Wikidata (or wait a while and I'll probably add it the next time I run through the tracking categories looking for new links). Thanks. Mike Peel (talk) 13:26, 10 May 2020 (UTC)
- It seems the "problem" in the article I am working on is that it has a Commons Category but the Wikidata entry does not. The only way I can fix it is to remove the commons category from the Wikipedia article! Kerry (talk) 13:14, 10 May 2020 (UTC)
- It seems the presumption is that Wikidata is right (as there appears to be no corresponding error report on Wikidata) and Wikipedia is wrong. How about not presuming blame at Wikipedia and put a more neutral message that appears on both sites (and can be overriden after checking). Kerry (talk) 12:58, 10 May 2020 (UTC)
- And it should not be displayed to users. It is an internal issue and should not be visible to any reader.Kerry (talk) 12:53, 10 May 2020 (UTC)
- Why should any reader see it? It renders as if there is an error. It should only be visible in edit at most. The mismatch should be reported on both Wikipedia and Wikidata (by repeorting it only on Wikipedia, it is clearly indicating that the Wikipedia article is in error). The mismatch may be perfectly acceptable, as the scope of the Wikiepdia article may be different to the Wikifta concept so in that circumstance one might find one a sub-cat of the other. There should be no reporting of a problem if the Wikidata item has no value for commons category (suggests to me that this change in the template was not tested, as anyone who uploads a photo, adds a new commons category for it and puts that category in article will get the error). By all means say "please check", but there has to be a way to suppress the message, once you have checked and it is OK from the perspective of the Wikipedia article. I note this alignment of commons categories between Wikipedia and Wikidata was controversial in the RfC when you proposed on Village Pump to have a bot to change the Wikipedia articles to be the same as the Wikidata. Given that RfC failed, it seems to me inappropriate to then come here and request an edit of this template to try to achieve the same effect with this error message reported only on Wikipedia and which (despite checking) which can only be "resolved" by changing the Wikipedia article to match the Wikidata value (even if it is wrong or missing on Wikidata) without mentioning that such a change might be controversial and might benefit from another RfC. Kerry (talk) 13:58, 10 May 2020 (UTC)
- Please remove the error message. I came here because that message currently defaces All Hallows' School where a reasonable Commons category is used that is not reciprocated. I also noted that this message is shown in all articles that are the main subject of a category which in turn is linked to the Commons category. Picked from early in the alphabet is 1st Lok Sabha which uses Commons:Category:1st Lok Sabha members which is connected to Category:1st Lok Sabha members. That's a legitimate use of the template/category which is now spoiled by the red-letter message. What is an editor supposed to do? Remove the Commons category template from the Wikipedia articles? -- Michael Bednarek (talk) 10:01, 11 May 2020 (UTC)
- In this case the parameter for {{commons category}} was identical to the value in P373, so I have just removed the parameter from the article. But this is not an error, and should not be identified as such. If the parameters need removing then that is a job for a bot. There is no need to trouble editors with this. — Martin (MSGJ · talk) 13:00, 11 May 2020 (UTC)
- @Michael Bednarek: For 1st Lok Sabha, I personally think that the correct thing to do is to remove the commons link there, and add it to List of members of the 1st Lok Sabha, where it is appropriate. Ideally we'd probably have Commons:Category:1st Lok Sabha, which would then match the article. But it probably needs more input from the article writers - hence the message in the template to call attention to the discrepancy. Thanks. Mike Peel (talk) 17:40, 11 May 2020 (UTC)
- This is a general problem where a Commons category is (properly) connected to a Wikipedia category, which in turn has a main subject article which also (properly) uses this template to that category. I suggest the whole idea needs to be reconsidered.-- Michael Bednarek (talk) 04:15, 12 May 2020 (UTC)
- @Michael Bednarek: No, that's handled here - in general there are 'article', 'list', and 'category' items, and as long as they are linked between on Wikidata correctly (topic's main category (P910)/category's main topic (P301)/list related to category (P1753)/category related to list (P1754)) then this template follows them and uses the correct Commons category sitelink. Thanks. Mike Peel (talk) 06:52, 12 May 2020 (UTC)
- We can't expect editors who write an article on a subtopic to jump through the hoops you skilfully demonstrated just to show a related Commons category in that article. I think I'm not alone in doubting that Wikidata's strict relationship model is suitable for Wikipedia. -- Michael Bednarek (talk) 12:06, 12 May 2020 (UTC)
- @Michael Bednarek: No, that's handled here - in general there are 'article', 'list', and 'category' items, and as long as they are linked between on Wikidata correctly (topic's main category (P910)/category's main topic (P301)/list related to category (P1753)/category related to list (P1754)) then this template follows them and uses the correct Commons category sitelink. Thanks. Mike Peel (talk) 06:52, 12 May 2020 (UTC)
- This is a general problem where a Commons category is (properly) connected to a Wikipedia category, which in turn has a main subject article which also (properly) uses this template to that category. I suggest the whole idea needs to be reconsidered.-- Michael Bednarek (talk) 04:15, 12 May 2020 (UTC)
- Please remove the error message. I came here because that message currently defaces All Hallows' School where a reasonable Commons category is used that is not reciprocated. I also noted that this message is shown in all articles that are the main subject of a category which in turn is linked to the Commons category. Picked from early in the alphabet is 1st Lok Sabha which uses Commons:Category:1st Lok Sabha members which is connected to Category:1st Lok Sabha members. That's a legitimate use of the template/category which is now spoiled by the red-letter message. What is an editor supposed to do? Remove the Commons category template from the Wikipedia articles? -- Michael Bednarek (talk) 10:01, 11 May 2020 (UTC)
Edit request
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please remove the error messages by implementing the changes shown in the sandbox; diff. -- Michael Bednarek (talk) 11:08, 11 May 2020 (UTC)
- Not done for now: this was implemented after discussion above. Please allow a little more time for discussion before requesting this. There may be a straightforward way to resolve this. — Martin (MSGJ · talk) 12:07, 11 May 2020 (UTC)
- Actually there does indeed seem to be an issue. On All Hallows' School
I tried to fix by changing the value for Commons category (P373) but it did not remove the error message.Then I removed all parameters from the {{commons category}} template, and the error message is still there. The reason may be the conflict between the interwiki link and P373 on wikidata, but it does not seem right to deface the article, because there is nothing the article editor can do to fix this problem on the article itself. I have reverted for now pending further discussion. — Martin (MSGJ · talk) 12:20, 11 May 2020 (UTC)- @MSGJ and Michael Bednarek: In that case, this seems to have been the correct edit to do, to sitelink between the article and the category. That way Commons links back to the correct Wikipedia article. Commons category (P373) is not the right thing to change, the sitelink is. I liked your first response here, it would have been better to have discussed this further here first before reverting. I would have responded sooner except this was the first day I've been offline in months! Thanks. Mike Peel (talk) 17:36, 11 May 2020 (UTC)
- I'm sure, if resurrected, the message would now appear at All Hallows' School Buildings which uses this template to connect to the school's Commons category. In general, many articles that cover similar areas will show the same Commons category; there is no 1-to-1 relationship between Commons categories and Wikipedia articles, which is what the constraints of Wikidata suggest, but that's a problem there, not here. -- Michael Bednarek (talk) 04:15, 12 May 2020 (UTC)
- @Michael Bednarek: OK, that's solved by commons:Category:All Hallows' School Buildings. People keep saying 'there is no 1-to-1 relationship', but I have yet to see a good example of this (this wasn't one). Thanks. Mike Peel (talk) 06:48, 12 May 2020 (UTC)
- I'm sure, if resurrected, the message would now appear at All Hallows' School Buildings which uses this template to connect to the school's Commons category. In general, many articles that cover similar areas will show the same Commons category; there is no 1-to-1 relationship between Commons categories and Wikipedia articles, which is what the constraints of Wikidata suggest, but that's a problem there, not here. -- Michael Bednarek (talk) 04:15, 12 May 2020 (UTC)
- @MSGJ and Michael Bednarek: In that case, this seems to have been the correct edit to do, to sitelink between the article and the category. That way Commons links back to the correct Wikipedia article. Commons category (P373) is not the right thing to change, the sitelink is. I liked your first response here, it would have been better to have discussed this further here first before reverting. I would have responded sooner except this was the first day I've been offline in months! Thanks. Mike Peel (talk) 17:36, 11 May 2020 (UTC)
I'm not intending to get involved with this (was only responding to the edit request) but I will just make the following points:
- I tend to agree with Kerry above, that this warning should be directed at editors rather than readers. Readers can be logged in users, of course, so if the message could be displayed in the editing window or preview, that would be good.
- It is no good displaying an error unless it is clear what corrective action needs to be done. As an experienced template coder I am one of the more technical admins here, but I was not able to fix the issue at All Hallows' School! So the error message should be accompanied by a much clearer guideline. Template:Commons category#Resolving discrepancies is not sufficient for this.
- In general it is better not to trouble human editors with an issue that a bot could fix. If the fix is straightforward, then it's an ideal job for a bot.
Good luck with this — Martin (MSGJ · talk) 07:37, 12 May 2020 (UTC)
- @MSGJ: Thanks for the feedback. I see that you don't want to get involved, but here's some quick responses: 1) I can look into how to do this, but I worry that the decreased visibility will make it less likely for editors to help with these issues. 2) I'll try to improve the guidelines, but any help phrasing the questions is really useful. 3) Completely agree, I operate Pi bot to do that here and on Wikidata, and can always code up more tasks. Thanks. Mike Peel (talk) 07:50, 12 May 2020 (UTC)
- There is a method to show messages only in edit mode, and that, combined with a tracking category, would be appropriate in this case. -- Michael Bednarek (talk) 12:06, 12 May 2020 (UTC)
- @Michael Bednarek: I've been looking for that method, but can't find it. Could you point it out please, or preferably code it up in the sandbox? Otherwise I'd prefer to go back to having the warning displayed for logged in users. Thanks. Mike Peel (talk) 19:32, 29 May 2020 (UTC)
- That method (
{{#invoke:Preview warning|main|text to be displayed}}
) is used i.a. by {{IMDb title}}. There's also {{If preview}}. -- Michael Bednarek (talk) 02:25, 30 May 2020 (UTC)- @Michael Bednarek: Thanks! I've set up the IMDb-style code at {{Commons category/sandbox}}, are you happy for that to go live? Feel free to tweak the warning message if you want. Thanks. Mike Peel (talk) 08:51, 30 May 2020 (UTC)
- Because of the peculiarities of this template, it's of course impossible to test the sandbox version in this regard, but the code seems OK. While I'm not at all the final arbiter in this matter, I suppose we'll have to take a punt and see what happens. I still maintain that there are legitimate cases where a Commons category can be used on more than one article. The one-to-one stricture imposed by Wikidata is problematic, not only in this case (interlanguage links and Wikidata's artificial distinction between disambiguation pages and name lists are others) but that's another story. -- Michael Bednarek (talk) 10:01, 30 May 2020 (UTC)
- OK, let's give it a go and see how other editors react. If even a few join in with helping to check through the remaining ~27k potentially incorrect links, that would be worthwhile. Thanks. Mike Peel (talk) 11:56, 30 May 2020 (UTC)
- In my experience. almost all of the entries in Category:Commons category link is locally defined are correct and don't need changing. That category is applied to Puccini's Turandot because the Wikidata entry for Turandot (d:Q207990, description: "opera by Giacomo Puccini") is linked to Commons:Category:Turandot where Puccini's opera is buried 2 layers deep; no surprise that the Tosca article uses Commons:Category:Turandot (Puccini) which, thanks to Wikidata, is now an orphan. Unrelated: I don't understand why Natalka Poltavka (opera) is in 'Category:Commons category link is locally defined'. The article's template, Commons and Wikidata seem all to agree. -- Michael Bednarek (talk) 12:48, 30 May 2020 (UTC)
- commons:Category:Turandot seems to be about a fairy tale, do we have an article related to that? Then we can correct the sitelinks on Wikidata. commons:Category:Natalka Poltavka seems to contain media for the play (Natalka Poltavka, not Natalka Poltavka (opera)), there doesn't seem to be a category for the opera. Thanks. Mike Peel (talk) 12:58, 30 May 2020 (UTC)
- In my experience. almost all of the entries in Category:Commons category link is locally defined are correct and don't need changing. That category is applied to Puccini's Turandot because the Wikidata entry for Turandot (d:Q207990, description: "opera by Giacomo Puccini") is linked to Commons:Category:Turandot where Puccini's opera is buried 2 layers deep; no surprise that the Tosca article uses Commons:Category:Turandot (Puccini) which, thanks to Wikidata, is now an orphan. Unrelated: I don't understand why Natalka Poltavka (opera) is in 'Category:Commons category link is locally defined'. The article's template, Commons and Wikidata seem all to agree. -- Michael Bednarek (talk) 12:48, 30 May 2020 (UTC)
- OK, let's give it a go and see how other editors react. If even a few join in with helping to check through the remaining ~27k potentially incorrect links, that would be worthwhile. Thanks. Mike Peel (talk) 11:56, 30 May 2020 (UTC)
- Because of the peculiarities of this template, it's of course impossible to test the sandbox version in this regard, but the code seems OK. While I'm not at all the final arbiter in this matter, I suppose we'll have to take a punt and see what happens. I still maintain that there are legitimate cases where a Commons category can be used on more than one article. The one-to-one stricture imposed by Wikidata is problematic, not only in this case (interlanguage links and Wikidata's artificial distinction between disambiguation pages and name lists are others) but that's another story. -- Michael Bednarek (talk) 10:01, 30 May 2020 (UTC)
- @Michael Bednarek: Thanks! I've set up the IMDb-style code at {{Commons category/sandbox}}, are you happy for that to go live? Feel free to tweak the warning message if you want. Thanks. Mike Peel (talk) 08:51, 30 May 2020 (UTC)
- That method (
- @Michael Bednarek: I've been looking for that method, but can't find it. Could you point it out please, or preferably code it up in the sandbox? Otherwise I'd prefer to go back to having the warning displayed for logged in users. Thanks. Mike Peel (talk) 19:32, 29 May 2020 (UTC)
- There is a method to show messages only in edit mode, and that, combined with a tracking category, would be appropriate in this case. -- Michael Bednarek (talk) 12:06, 12 May 2020 (UTC)
- @MSGJ: Thanks for the feedback. I see that you don't want to get involved, but here's some quick responses: 1) I can look into how to do this, but I worry that the decreased visibility will make it less likely for editors to help with these issues. 2) I'll try to improve the guidelines, but any help phrasing the questions is really useful. 3) Completely agree, I operate Pi bot to do that here and on Wikidata, and can always code up more tasks. Thanks. Mike Peel (talk) 07:50, 12 May 2020 (UTC)
Undone
I just removed the "resolving discrepancies" section from the template doc[2]. I noticed Mike Peel removing commonscat templates from articles on my watchlst, and while in a number of cases the changes are real improvements, in other cases they are totally unnecessary (e.g. some new "rule" that there shouldn't be a commons cat link to a category, and another one to a subcategory) and make life for readers here only harder, not easier. The actual benefit of these edits for our readers is totally unclear. The only edit I actually reverted so far is this one, where the edit changed handy, direct links to two separate pages to a link to a parent page where editors still had to chose between the two subpages anyway. Forcing readers to make two clicks instead of one to get where they want is not helpful at all, and should not be mandated by template documentation, "maintenance" categories, or anything else, unless there is a very good reason to do this. I see no benefit in edits like this one, deliberately removing a commonscat which isn't a 100% match to the article but is of clear interest to the topic and its readers.
In general, such decisions should be made by the editors of the article, not by fiat from above for some "maintenance" reason without benefits. Fram (talk) 07:49, 15 June 2020 (UTC)
- @Fram: In general, I think it's better for both readers and editors if there is a single commons category per article (and if we don't have completely random ones like this that add no value to the article). I think having more made sense in the past, when commons categorisation wasn't so advanced, but now there are about as many commons categories as enwp articles I think there's a much better match between them - and where there isn't, that normally implies that either the articles here or the categories on Commons need improvement. I've been working through the more obvious cases, but they are becoming more complicated now. The message in the template, and the text in the category documentation, is an attempt to encourage editors of those articles to help out - I'm not sure why you wanted to make that more difficult by removing the text rather than improving it.
- With Blarenberghe, there seem to be more than two artists described by the article. I had a quick look on Commons, and added more to commons:Category:Van Blarenberghe family including another subcategory. Perhaps they can be easily sorted into the subcategories, but there are still others I didn't add to that category. Maybe you can help improve it? I still think a single link is better in that case. Thanks. Mike Peel (talk) 18:02, 15 June 2020 (UTC)
"In general, such decisions should be made by the editors of the article"
If someone has edited the article, even just once, and even if that edit involved adding, removing or changing the contents of a template, then they are one of "the editors of the article". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:45, 15 June 2020 (UTC)- If one has never edited an article before and only goes there to impose one's vision of how many commonscat templates there should be, then no, you are not "an editor of the article" as you are not interested in the actual article, just in some arbitrary standard. Slow edit warring over this with the actual editors of the article (the ones adding content), as has been done in some cases, is a definite no-go. If you want a rule that only one commonscat is allowed per article, then start an RfC to get real consensus for this, and then impose the consensus. Otherwise leave this well alone (fine where you are correcting errors, not when you are just going around as a busy-body changing e.g. the direct link to ships commons cats to parent cats with a "meaningless" name (for most readers, it's some ship database code) where people have to click through to the previous commonscat anyway to get the information they want. These edits are too often dogmatic instead of being helpful. Think from the position of the readers, not from the position of some extremely locally decided theorertical model. Fram (talk) 06:51, 16 June 2020 (UTC)
- Feel free to aquaint yourself with our policy, any time you like. As for "the position of the readers", on the example given Mike's edit was a considerable improvement. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 16 June 2020 (UTC)
- @Fram: To be clear, my interest is in improving the links from here to Commons. This is not a new interest. I think that the edits I'm making with commons categories are constructive, and I'm not trying to impose an arbitrary standard. Where I have removed multiple commons category links from a single article, I think that the single remaining link is more useful than the previous multiple links - it points to the best Commons category to start exploring the media for that topic. Ships are an interesting case, and it would be possible to modify this template to include the name category links as well, which I want to explore in the future. I don't think that holding an RfC right now would help, though, as there are existing cases where having multiple links may well be beneficial - I'm skipping over them for now and want to return to them, but I wouldn't want to jump to imposing a rule on them without looking at these cases in more detail.
- Given our past interactions, and your initial edit summary of "many of the article edits based upon this should not have been made and be reversed", this discussion is quite stressful for me. Comments like "one has never edited an article before and only goes there to impose one's vision", "impose the consensus", "leave this well alone", "just going around as a busy-body", "too often dogmatic instead of being helpful", "some extremely locally decided theorertical model" are not constructive. Thanks. Mike Peel (talk) 19:28, 16 June 2020 (UTC)
- I suggest that an idea that places almost 6000 articles in a maintenance category blatantly disregards widespread practice. Many concepts are treated to a different level of granularity across all Wikimedia projects. There's no reason that the English Wikipedia must follow whatever scheme is used at Wikidata/Commons. The links to Commons in the sidebar are one thing, usage of this template in "External links" is another – if it weren't, the template could be deleted, which has not found consensus so far. -- Michael Bednarek (talk) 02:42, 16 June 2020 (UTC)
- There are a several hundred thousand pages in maintenance categories for the citation templates at any given time. 6k is paltry. --Izno (talk) 05:34, 16 June 2020 (UTC)
- @Michael Bednarek and Izno: In terms of numbers, you can look at Category:Commons category Wikidata tracking categories. Category:Commons category link from Wikidata and Category:Commons category link is on Wikidata imply that the links are OK (although they can be wrong, they would have to be simultaneously wrong here, on Wikidata, and on Commons): these are 308,796 categories and 546,920 articles. Category:Commons category link is defined as the pagename, Category:Commons category link is the pagename, and Category:Commons category link is locally defined imply that either we have multiple links from here to Commons, or something is wrong here, on Wikidata, or on Commons: these are 6,133 categories and 21,009 articles. So that is 2% of links in categories and 3.8% of articles. Combining them, we have 855,716 links, of which 27,142 may be wrong, or 3.2%. For comparison, we now have around 3 million links between Wikidata and Commons. Thanks. Mike Peel (talk) 20:06, 16 June 2020 (UTC)
- There are a several hundred thousand pages in maintenance categories for the citation templates at any given time. 6k is paltry. --Izno (talk) 05:34, 16 June 2020 (UTC)
- If one has never edited an article before and only goes there to impose one's vision of how many commonscat templates there should be, then no, you are not "an editor of the article" as you are not interested in the actual article, just in some arbitrary standard. Slow edit warring over this with the actual editors of the article (the ones adding content), as has been done in some cases, is a definite no-go. If you want a rule that only one commonscat is allowed per article, then start an RfC to get real consensus for this, and then impose the consensus. Otherwise leave this well alone (fine where you are correcting errors, not when you are just going around as a busy-body changing e.g. the direct link to ships commons cats to parent cats with a "meaningless" name (for most readers, it's some ship database code) where people have to click through to the previous commonscat anyway to get the information they want. These edits are too often dogmatic instead of being helpful. Think from the position of the readers, not from the position of some extremely locally decided theorertical model. Fram (talk) 06:51, 16 June 2020 (UTC)
Wrong link to commons category generated
Our article Haworthiopsis limifolia is linked from the Wikidata item Haworthia limifolia (Q219500) (because the majority of other language wikipedias have not yet updated the scientific name). This Wikidata item has "Commons category: Haworthiopsis limifolia" which correctly links to commons:Category:Haworthiopsis limifolia. Yet if I put just {{Commons category}} in the article, it produces a wrong link to commons:Category:Haworthia limifolia. Surely this is an error? Peter coxhead (talk) 17:58, 11 June 2020 (UTC)
- @Peter coxhead: Haworthia limifolia (Q219500) links to commons:Haworthiopsis limifolia, not the category. commons:Category:Haworthiopsis limifolia is linked to Haworthiopsis limifolia (Q39865426). The simplest way to fix it would be to move the enwp sitelink to the other item, but it would be better to improve Wikidata's modelling here, if you can. Thanks. Mike Peel (talk) 18:14, 11 June 2020 (UTC)
- @Mike Peel: no, look at the Commons category property of Haworthia limifolia (Q219500) – the eighth statement – not the site link at the very bottom.
- I'm not quite sure what you mean by
it would be better to improve Wikidata's modelling here
. Wikidata's modelling of taxa and taxon names is well known to be wrong, but apparently not fixable. Peter coxhead (talk) 20:58, 11 June 2020 (UTC)- The template uses the sitelink to the Commons category, not Commons category (P373) (hopefully that property can be deleted soon). Why do you say that Wikidata is "not fixable"? Thanks. Mike Peel (talk) 21:10, 11 June 2020 (UTC)
- See User:Peter coxhead/Wikidata issues. There are two problems: insisting on 1:1 links, which they won't change; incorrect modelling of taxa and taxon names, which no-one knows how to fix, apparently. If you have an hour to spare, you could start reading here and here. Peter coxhead (talk) 21:22, 11 June 2020 (UTC)
- It would certainly be good not to have two places in Wikidata items where the Commons category can be linked, but while there are, why is one ignored? Peter coxhead (talk) 21:26, 11 June 2020 (UTC)
- OK, there are clearly people that know a lot more about taxons than I do, that have worried about this problem a lot. I'm not sure I can contribute much to the systematic discussions. In this case, I've tweaked Haworthia limifolia (Q219500) and Haworthiopsis limifolia (Q39865426), and linked between them using said to be the same as (P460), which I think is an improvement. With P373, it's no longer used here in favour of the sitelinks and locally-defined text. It's a catch-22 situation that people don't want to delete it as it is used; and people use it because it exists. See d:Wikidata:Properties_for_deletion#Property:P373. Thanks. Mike Peel (talk) 07:13, 12 June 2020 (UTC)
- But while P373 exists, and appears higher up on the page, as well as more clearly specifying Commons category, editors will use it at Wikidata – I know I have – with no way of knowing that the largest wikipedia is just ignoring it. At the least there should be a check for consistency; articles could be put into a hidden tracking category if there is inconsistency in the linked Wikidata item, as we do with articles using inconsistent taxonomy templates. Peter coxhead (talk) 08:45, 12 June 2020 (UTC)
- Something like those at Category:Commons category Wikidata tracking categories? Having just got rid of the P373 one, after quite a bit of work, I don't want to re-add it. Also, Pi bot will automatically it from P373 to the sitelink if it can, and for cases where it can't we have d:Wikidata:Database reports/Constraint violations/P373 and d:Wikidata:Database reports/Complex constraint violations/P373. Thanks. Mike Peel (talk) 08:58, 12 June 2020 (UTC)
- But while P373 exists, and appears higher up on the page, as well as more clearly specifying Commons category, editors will use it at Wikidata – I know I have – with no way of knowing that the largest wikipedia is just ignoring it. At the least there should be a check for consistency; articles could be put into a hidden tracking category if there is inconsistency in the linked Wikidata item, as we do with articles using inconsistent taxonomy templates. Peter coxhead (talk) 08:45, 12 June 2020 (UTC)
- OK, there are clearly people that know a lot more about taxons than I do, that have worried about this problem a lot. I'm not sure I can contribute much to the systematic discussions. In this case, I've tweaked Haworthia limifolia (Q219500) and Haworthiopsis limifolia (Q39865426), and linked between them using said to be the same as (P460), which I think is an improvement. With P373, it's no longer used here in favour of the sitelinks and locally-defined text. It's a catch-22 situation that people don't want to delete it as it is used; and people use it because it exists. See d:Wikidata:Properties_for_deletion#Property:P373. Thanks. Mike Peel (talk) 07:13, 12 June 2020 (UTC)
- The template uses the sitelink to the Commons category, not Commons category (P373) (hopefully that property can be deleted soon). Why do you say that Wikidata is "not fixable"? Thanks. Mike Peel (talk) 21:10, 11 June 2020 (UTC)
- @Mike Peel:
not Commons category (P373) (hopefully that property can be deleted soon)
- Sorry wait wut? Unless Commons abolishes galleries in main space, which sounds fair but I don't have a vote anyway, P373 is the way to go.
- @Peter coxhead: The reason there are two is IIRC performance. The sitelink is cheaper to obtain, and I think c:Template:Wikidata Infobox uses it through mw:Extension:Wikibase Client/Lua#mw.wikibase.getEntityIdForCurrentPage. P373 is more precise because the sitelink can be either a gallery or a category. I guess the alternative is to change Wikidata policy to disallow Commons galleries as sitelinks, allowing those only in P935 Commons gallery. (or preferably, have them burn in hell) Mike Peel vaguely hinted at this, but there turns out to be a discussion at d:Wikidata:Properties for deletion#Property:P373. - Alexis Jazz 19:49, 19 July 2020 (UTC)
- @Peter coxhead and Alexis Jazz: See my extensive comments on the deletion discussion for why P373 is bad and should be deleted. In particular, the sitelink is a two-way link (you can use it to link from here to Commons, and from Commons to here), the property only links in one direction (here to Commons). The gallery vs. category problem is long solved (even thought I agree with you that galleries should be abolished, we can work around them). Thanks. Mike Peel (talk) 18:10, 24 July 2020 (UTC)
- @Mike Peel: Yes, I was confused a bit and forgot to update my post above. But anyway, while P373 is bad, at least part of the opposition wants, I believe, what I proposed there: increasing flexibility. I'm not sure there is another satisfactory way to resolve the issue with d:Q144 (dog) and d:Q6830323 (Wikimedia category for dogs) where Q144 can't have the Commons category as a sitelink because Q6830323 is already using that. - Alexis Jazz 18:22, 24 July 2020 (UTC)
- @Alexis Jazz: ... and you can't move the commons category to dog (Q144) anyway because it's also in use at Category:Dogs, which is sitelinked from Category:Dogs (Q6830323). Even if the gallery/category issue on Commons goes away, you still have article/category to deal with here. Using topic's main category (P910)/category's main topic (P301) to move between category and topic items works, it just uses a bit more CPU time. Thanks. Mike Peel (talk) 18:37, 24 July 2020 (UTC)
- @Mike Peel: It's not actually used there, other than to show a warning in preview. But anyway, my suggestion would solve that. Q144 could have c:Category:Dogs with high priority and Q6830323 could have it with a lower priority, so Category:Dogs could use it as well as the Wikidata infobox on Commons and the article about dogs. I am confused though: how is it possible the sidebar on Dog links c:Category:Dogs and ignores the sitelink to c:Dogs? - Alexis Jazz 18:56, 24 July 2020 (UTC)
- @Alexis Jazz: Category:Dogs is working fine. Dog is only showing the error message because it erroneously links to commons:Category:Dogs in art. The sidebar sadly still uses P373, see phab:T232927 for the request to fix that. Thanks. Mike Peel (talk) 19:01, 24 July 2020 (UTC)
- @Mike Peel:
{{Commons cat|Dogs}}
- Is that your definition of "fine"? And if you remove the Commons category sitelink from Q6830323 so you could add it to Q144 and resolve phab:T232927, Category:Dogs will actually start to depend on the "Dogs" parameter above to continue working. (and start complaining in preview) Sorry for the confusion, I need coffee: if you change the parameter {{Commons cat}} has on Category:Dogs, it'll show an error in preview. That's what I wanted to say. - Alexis Jazz 19:15, 24 July 2020 (UTC)
- @Alexis Jazz: Try {{Commons category}} on its own at either of Dogs and Category:Dogs, it will work without an error message. It will just display the link to Commons and add Category:Commons category link from Wikidata. That's fine. Thanks. Mike Peel (talk) 19:21, 24 July 2020 (UTC)
- @Mike Peel: Of course it will! phab:T232927 hasn't been resolved yet! And if I understand your solution correctly of following P910/P1754: that may seem clean at first sight, but in the long run it's going to be messy and/or limited. Because you just created an exception. An exception that, for one thing, won't cover the French Smurfs, so your if then if then will probably get expanded at some point, which as you can imagine, will be lotsa fun. - Alexis Jazz 19:31, 24 July 2020 (UTC)
- @Alexis Jazz: This template already implements this solution. The sidebar code needs to catch up, but that is a separate issue that needs MediaWiki developer involvement (which is why I submitted the phab ticket). I haven't created an exception here - I don't think I've ever edited the items we're talking, let alone today. The / solution is live in around 630,000 items. Thanks. Mike Peel (talk) 19:45, 24 July 2020 (UTC)
- @Mike Peel: It is an exception. This isn't about what items you've edited. If you have a calendar that has 365 days in a year, but that doesn't quite work out so you add a leap day, but that still doesn't quite work out so you skip the leap day every 100 years, but that still doesn't quite work out so you unskip it every 400 years.. That's an exception, and it will work alright in our solar system with our calendar (for about 8000 years or whatever IIRC), but if anything changes it stops working. And Wikidata isn't as established as the solar system or Gregorian calendar. Worse than that, while the odd leap day rules basically solved the problem (at least back when the calendar was made), Wikidata still has identified problems that your approach won't solve. - Alexis Jazz 20:09, 24 July 2020 (UTC)
- @Alexis Jazz: Perhaps focus on those problems then, and give examples of them? Thanks. Mike Peel (talk) 20:18, 24 July 2020 (UTC)
- @Mike Peel: French Smurfs? - Alexis Jazz 20:19, 24 July 2020 (UTC)
- @Alexis Jazz: What French Smurf? Thanks. Mike Peel (talk) 20:24, 24 July 2020 (UTC)
- @Mike Peel: You replied to my comment that included the Schtroumpfs example. I assumed you had read it. - Alexis Jazz 20:32, 24 July 2020 (UTC)
- I missed it, but [3] works just fine. Thanks. Mike Peel (talk) 20:38, 24 July 2020 (UTC)
- @Mike Peel: You replied to my comment that included the Schtroumpfs example. I assumed you had read it. - Alexis Jazz 20:32, 24 July 2020 (UTC)
- @Alexis Jazz: What French Smurf? Thanks. Mike Peel (talk) 20:24, 24 July 2020 (UTC)
- @Mike Peel: French Smurfs? - Alexis Jazz 20:19, 24 July 2020 (UTC)
- @Alexis Jazz: Perhaps focus on those problems then, and give examples of them? Thanks. Mike Peel (talk) 20:18, 24 July 2020 (UTC)
- @Mike Peel: It is an exception. This isn't about what items you've edited. If you have a calendar that has 365 days in a year, but that doesn't quite work out so you add a leap day, but that still doesn't quite work out so you skip the leap day every 100 years, but that still doesn't quite work out so you unskip it every 400 years.. That's an exception, and it will work alright in our solar system with our calendar (for about 8000 years or whatever IIRC), but if anything changes it stops working. And Wikidata isn't as established as the solar system or Gregorian calendar. Worse than that, while the odd leap day rules basically solved the problem (at least back when the calendar was made), Wikidata still has identified problems that your approach won't solve. - Alexis Jazz 20:09, 24 July 2020 (UTC)
- @Alexis Jazz: This template already implements this solution. The sidebar code needs to catch up, but that is a separate issue that needs MediaWiki developer involvement (which is why I submitted the phab ticket). I haven't created an exception here - I don't think I've ever edited the items we're talking, let alone today. The / solution is live in around 630,000 items. Thanks. Mike Peel (talk) 19:45, 24 July 2020 (UTC)
- @Mike Peel:
- @Alexis Jazz: Category:Dogs is working fine. Dog is only showing the error message because it erroneously links to commons:Category:Dogs in art. The sidebar sadly still uses P373, see phab:T232927 for the request to fix that. Thanks. Mike Peel (talk) 19:01, 24 July 2020 (UTC)
- @Mike Peel: It's not actually used there, other than to show a warning in preview. But anyway, my suggestion would solve that. Q144 could have c:Category:Dogs with high priority and Q6830323 could have it with a lower priority, so Category:Dogs could use it as well as the Wikidata infobox on Commons and the article about dogs. I am confused though: how is it possible the sidebar on Dog links c:Category:Dogs and ignores the sitelink to c:Dogs? - Alexis Jazz 18:56, 24 July 2020 (UTC)
- @Alexis Jazz: ... and you can't move the commons category to dog (Q144) anyway because it's also in use at Category:Dogs, which is sitelinked from Category:Dogs (Q6830323). Even if the gallery/category issue on Commons goes away, you still have article/category to deal with here. Using topic's main category (P910)/category's main topic (P301) to move between category and topic items works, it just uses a bit more CPU time. Thanks. Mike Peel (talk) 18:37, 24 July 2020 (UTC)
- @Mike Peel: Yes, I was confused a bit and forgot to update my post above. But anyway, while P373 is bad, at least part of the opposition wants, I believe, what I proposed there: increasing flexibility. I'm not sure there is another satisfactory way to resolve the issue with d:Q144 (dog) and d:Q6830323 (Wikimedia category for dogs) where Q144 can't have the Commons category as a sitelink because Q6830323 is already using that. - Alexis Jazz 18:22, 24 July 2020 (UTC)
- @Peter coxhead and Alexis Jazz: See my extensive comments on the deletion discussion for why P373 is bad and should be deleted. In particular, the sitelink is a two-way link (you can use it to link from here to Commons, and from Commons to here), the property only links in one direction (here to Commons). The gallery vs. category problem is long solved (even thought I agree with you that galleries should be abolished, we can work around them). Thanks. Mike Peel (talk) 18:10, 24 July 2020 (UTC)
Template-protected edit request on 22 August 2020
{{edit template-protected}}
In Commons category does not match the Commons sitelink on Wikidata - please check …
(3 x), please replace the hyphens with dashes. Hildeoc (talk) 20:36, 22 August 2020 (UTC)
- @Hildeoc: Can you demo the change at Template:Commons category/sandbox please? Thanks. Mike Peel (talk) 20:40, 22 August 2020 (UTC)
- There you go.--Hildeoc (talk) 20:50, 22 August 2020 (UTC)
- @Hildeoc: Thank you, Done. Mike Peel (talk) 20:57, 22 August 2020 (UTC)
- There you go.--Hildeoc (talk) 20:50, 22 August 2020 (UTC)
Migrate some uses of this template to Template:Commons category?
Hi all, I've started a discussion at Wikipedia:Village_pump_(proposals)#Migrate_some_uses_of_Template:Commons_to_Template:Commons_category about bot-migrating uses of this template over to {{Commons category}}, please participate there if you're interested. (@Hike395 and Achim55: you might be particularly interested in this given past discussions.) Thanks. Mike Peel (talk) 18:20, 30 August 2020 (UTC)
Template-protected edit request on 2 October 2020
This edit request to Template:Commons category has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Template {{Commons category}} adds pages to some tracking categories, like Category:Commons category link is locally defined. This category is a subcategory of Category:Commons category Wikidata tracking categories, which is a container category, and thus it is categorized into Category:Container categories. The page Category:Container categories itself transcludes {{Commons category}}, which causes a category cycle (see also User:SDZeroBot/Category cycles). At the moment, this cycle is resolved by wrapping {{Commons category}} in {{Suppress categories}}, which is not ideal.
To resolve such cycles, category suppression support in the template {{Commons category}} is needed. Please apply Special:Diff/974406909/981451608 to introduce new parameter |nocat=
(see also WP:NOCAT). —andrybak (talk) 11:57, 2 October 2020 (UTC)
- Not done
There is an exception to this for maintenance purposes. For example, Category:Hidden categories is a direct subcategory of itself and of Category:Wikipedia extended-confirmed-protected pages and Category:Container categories, each of which is a direct subcategory of Category:Hidden categories.
* Pppery * it has begun... 15:15, 2 October 2020 (UTC)
What to do with category links to Commons?
I've started an RfC today at Wikipedia:Village_pump_(proposals)#RfC:_What_to_do_with_category_links_to_Commons? - please comment! Thanks. Mike Peel (talk) 19:54, 11 December 2020 (UTC)
Wikidata warnings not understanable
I got that wikidata warning when making https://wiki.riteme.site/w/index.php?title=Worm_cast&oldid=1005961395 but have no idea of what it meant. So maybe someone will figure it out for me. Jidanni (talk) 08:32, 10 February 2021 (UTC)
- @Jidanni: In that case it meant that the link to Commons wasn't on Wikidata yet (so the Commons category wasn't linking back to the article). I've added it, the warning should go away now. Thanks. Mike Peel (talk) 08:44, 10 February 2021 (UTC)
- Thanks. Was a real stumper! Jidanni (talk) 14:00, 10 February 2021 (UTC)
"Check the existence of the category on Commons"
The article states: "...Check the existence of the category on commons as well as the spelling of names carefully". It would be helpful if a link could be provided (or several?? -- I'm not sure) to go to the page on Commons where this can be checked. I'd do it myself, only I have found it very difficult to access Commons categories. SCHolar44 🇦🇺 💬 at 04:19, 15 February 2021 (UTC)
- There are 2 obvious way of checking: 1) add the template to an article, pointing to what you think might be a category, e.g. {{Commons category|Charles Robert Darwin}}; then in preview mode, click that link to check for its existence; 2) go to commons, C:, and search there using the search box. -- Michael Bednarek (talk) 05:08, 15 February 2021 (UTC)
--5.43.73.49 (talk) 08:09, 11 May 2021 (UTC) [e]