Template talk:MonumentID

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

unclear behaviour[edit]

@Mike Peel: File:Tram in Kärntner Ring, at twilight (Vienna, Austria).jpg uses this template and autocreates Category:Cultural heritage monuments in Austria with known IDs. This category is only valid, if generated by {{Denkmalgeschütztes Objekt Österreich}}, which means if there is a object-id as given by our data-provider Bundesdenkmalamt. Which is not the case here. I do not understand where the Category:Cultural heritage monuments in Austria with known IDs comes from and to what protected heritage monument this is related. best --Herzi Pinki (talk) 22:31, 26 March 2021 (UTC)[reply]

@Herzi Pinki: This template only uses Wikidata, so all the information it is using comes from Vienna Ring Road (Q46232), which it assumes is a monument (otherwise why would you use this template?). Thanks. Mike Peel (talk) 10:04, 27 March 2021 (UTC)[reply]
@Mike Peel: the problem is that Vienna Ring Road (Q46232) is not listed as a cultural heritage monument (only some buildings alongside are). It is neither marked with instance of (P31) = cultural property (Q2065736) (this is not the suitable criteria!), nor with heritage designation (P1435) = Denkmalgeschütztes Objekt (Q1188447), nor does it have some Cultural heritage database in Austria ObjektID (P2951). So for sure it is a problem caused by the uploader, I found it, because I'm running after quite a lot of such problems, which is tedious. Could you add some sanity checks regarding whether the image is in fact a monument in Wikidata, not just an arbitrary item in Wikidata, and an error message to the template? This is valuable not only for Austrian stuff, but for the rest of the world too. best --Herzi Pinki (talk) 18:40, 27 March 2021 (UTC)[reply]
@Herzi Pinki: In principle yes, but it depends on how widely this template is going to be used. So far I've been supporting it for Portugal and Brazil only. Thanks. Mike Peel (talk) 18:49, 27 March 2021 (UTC)[reply]
I will make my own. this template needs some doku anyhow. --Herzi Pinki (talk) 19:44, 27 March 2021 (UTC)[reply]

Missing spaces and (in certain cases) missing commas[edit]

{{MonumentIDPortugal|Q10368316}} produces this German text:
Kulturdenkmal
Santa Luzia Sanctuary,Areosa, Viana do Castelo, Distrikt Viana do Castelo, Portugal
Q10368316, SIPA-ID: 9019, DGPC-Id: 21900126 Wiki Loves Monuments ID: DGPC-21900126
{{MonumentIDPortugal|Q17125229}} produces this German text:
Kulturdenkmal
Capela de Nossa Senhora da Encarnação,Leiria, Leiria, Pousos, Barreira e Cortes, Leiria, Distrikt Leiria, Portugal
Q17125229, SIPA-ID: 1489, DGPC-Id: 73317 Wiki Loves Monuments ID: DGPC-73317

Template:MonumentIDPortugal is just a derivate of Template:MonumentID and on this template's description page, the same issues can be found:

  • Example 3: Here, in the template description.
Kulturdenkmal
Lovell-Teleskop,Goostrey, Cheshire East, Cheshire, North West England, England
Q555130, Listennummer der Organisation für Denkmalschutz in England: 1221685 BabelNet-Kennung: 03860635n
Mark II,Lower Withington, Cheshire East, Cheshire, North West England, England
Q3417035, Listennummer der Organisation für Denkmalschutz in England: 1443087

That is, in my opinion, there are two issues:

  1. In front of the first town name, regularly a space is missing. The first geographical name is separated from the monument name by a comma only, where there should be a comma and a space.
    In the above examples, those names, where spaces are missing, are: Areosa, Leiria, Goostrey, Lower Withington.
  2. In front of "Wiki Loves Monuments ID", "BabelNet-Kennung" (and similar optional IDs?), which are added after the official monument ID, there should also be a comma.

I believe this should be fixed in Template:MonumentID/line. However, that's beyond my competence. -- Martinus KE (talk) 09:35, 12 September 2021 (UTC)[reply]

Hello, @Martinus KE: I fixed the problems you appointed, they were bugging me too! Cheers! EPorto (WMB) (talk) 04:23, 6 September 2022 (UTC)[reply]
Thanks a lot, EPorto (WMB)! -- Martinus KE (talk) 15:35, 23 September 2022 (UTC)[reply]

template creates category loop[edit]

this template and {{MonumentIDPortugal}} cause a category loop when used in the category itself. see [1] and Category:Palácio de São Lourenço. While autocat seems to be fine for images, is there a use case where it is useful for categories? Eventually subcategories? You always put the template to the corresponding category. Instead of adding |autocat=no to all category usages, it would be fine if you can check either for categories or for category with same name and do not autocat in these cases. best -- Herzi Pinki (talk) 06:52, 12 September 2022 (UTC)[reply]

@Herzi Pinki: This template should never be used in category space, since it only displays a subset of the information that {{Wikidata Infobox}} displays, so it should be entirely redundant with that template. Thanks. Mike Peel (talk) 19:01, 13 September 2022 (UTC)[reply]
Thanks, can you switch it to silent or to error when used in categories? best --Herzi Pinki (talk) 19:03, 13 September 2022 (UTC)[reply]
@Herzi Pinki: Good idea, done. Thanks. Mike Peel (talk) 19:25, 13 September 2022 (UTC)[reply]

autocat yes? no![edit]

@Mike Peel: Please stop editwarring to force autocat on the images with this template. This is very disruptive to the categorization and curation efforts. Nobody should be forced to manually set something in a template image by image to remove it from a category, that's just crazy. If you want to do a specific curadory on WLM uploaded images please add it to some hidden cat out of the regular category tree, and do it from there. Darwin Ahoy! 15:47, 6 August 2023 (UTC)[reply]

I second all what DarwIn. And i had that that stupid autovategorization makes that some subjects have almost 800 files in the main category when, wihtout this autocategorization, it only was some and so are much easier to categorize given that they will not stay in the main category and one can concentrate in the ones that need a deeper categorization. Tm (talk) 18:03, 6 August 2023 (UTC)[reply]
And also, Mike Peel, disable whatever is that is making the fact that files like File:Palácio Nacional da Pena por Rodrigo Tetsuo Argenton (68).jpg that use a template like "Art Photo" and this template still have that stupid autocat enabled, albeit that already have been properly categorized for more than a year. Otherwise i will remove this template from all 69 files that are cloaging Category:Palácio Nacional da Pena given the effects it has in overcategorizing. Tm (talk) 18:14, 6 August 2023 (UTC)[reply]
@DarwIn and Tm: I am OK with turning it off if need be, but there's a step to do first (as I said in the reverting edit summary). Can you make sure that no files are currently only using autocat, and add the categories to those manually? We also need to make sure that uploaded files (through WLM) will have the categories added, or have autocat turned on in those cases, @EPorto (WMB): is this something you can help with? Note that if there are cases this is currently annoying you with, then you can just add autocat=no as a parameter to the template in those files. Thanks. Mike Peel (talk) 18:39, 6 August 2023 (UTC)[reply]
@Mike Peel We who are categorizing and curating content here do not have any responsibility of ensuring that the specific content uploaded in the course of some contest is properly categorized. There are tracking and maintenance categories which can be created for that purpose, which can be worked by by the organizers of the contest without messing up with the category tree. Or simply leave them uncategorized, and eventually someone who is doing the uncategorized media cats will categorize them at some point. Forcing the content by default into the main category of the subject is really a no-no due to the mess it causes in that cat, and the burden forced upon whoever is trying to categorize that content. Only situation I envisage that happening is if the thing is smart enough to remove that cat as soon as it's categorized into a subcat, though that doesn't seem to be happening in this case. Darwin Ahoy! 20:33, 6 August 2023 (UTC)[reply]
@Mike Peel BTW, I don't think your attitude is correct, trying to force by editwar a very problematic change in a template you are developing, disrupting others activity here. Please stop doing that. Darwin Ahoy! 20:46, 6 August 2023 (UTC)[reply]
@DarwIn: You're trying to make a change in an established template, I've pointed out the issues that need to be sorted out before that happens in good faith, do not keep disrupting existing uses of the template by making the change prematurely. Mike Peel (talk) 20:58, 6 August 2023 (UTC)[reply]
@Mike Peel "Established" = you imposing that absurd and disruptive flag which turns every main category of a monument into a Spanish aubergue, messing it up and disrupting the work of who is trying to categorize that content. There's no way what you are doing here can be correct, please remove it ASAP. Darwin Ahoy! 21:07, 6 August 2023 (UTC)[reply]
@DarwIn: It's worked this way since 2019. Your messages here are becoming increasingly antagonistic and unhelpful, and missing the issues caused by the abrupt change, please take a step back. I've also raised this at COM:AN. Thanks. Mike Peel (talk) 21:13, 6 August 2023 (UTC)[reply]

 Comment As an example of the mess up this template is causing, I tried to refine the categorization of Category:Santuário Dom Bosco (Brasília), moving the interior photos into the proper category. However, a number of them get stuck into Category:Santuário Dom Bosco (Brasília), as they are using this template, which forces that category. I am being told that this is untouchable and I have to go image by image setting a flag, in order to keep the default setting which should never have been implemented in first case. I'm glad you raised this at COM:AN, so more people can see by themselves the messing up and disruption being caused by this. Darwin Ahoy! 21:32, 6 August 2023 (UTC)[reply]

@DarwIn: You can batch change the template parameter using something like Help:VisualFileChange.js. Let's take a time out and see what others say before going further? Thanks. Mike Peel (talk) 21:40, 6 August 2023 (UTC)[reply]
It's a total nonsense having templates forcing categories in the main tree, and even more nonsense telling people they have to do whatever procedure in order to circumvent a bad implementation that should never be there to boot. I've seen that issue being raised several times at the Village Pump, and the indication was always that it was bad implementation, and to remove that from the template forcing the category, or remove the template entirely from the file. Why are you forcing these categories there, in first place? What's the point? Have you read COM:OVERCAT? Darwin Ahoy! 21:47, 6 August 2023 (UTC)[reply]
I have a better solution, simple use Help:VisualFileChange.js to simply remove the template is a getting in the way from a proper categorization, if the template continues to have the same problem. Tm (talk) 22:05, 6 August 2023 (UTC)[reply]

If a template is doing any categorization by default, it should be into hidden categories. - Jmabel ! talk 22:07, 6 August 2023 (UTC)[reply]

@DarwIn and Tm: Right, fine. I think I can write a bot script to manually add the categories that autocat would have added, and you could then remove any unnecessary ones manually? I'll then scrap the autocat code completely. Would that be acceptable? Mike Peel (talk) 07:50, 7 August 2023 (UTC)[reply]
@Mike Peel: can you do that in a way that doesn't just hard-add all the Overcats? - Jmabel ! talk 14:52, 7 August 2023 (UTC)[reply]
@Jmabel: I quickly coded it up and am running through now, it doesn't look as bad as I expected but there are lost categories (see my contributions today). I'm checking if it's in a subcat or (non-hidden) parent cat before adding it back to the main category - which isn't perfect, but works as triage. Mike Peel (talk) 14:56, 7 August 2023 (UTC)[reply]
@Mike Peel It's not perfect, but as long as the hardcoded categories disappear, and overcat is minimized by checking the parent categories, IMO it's kind of acceptable, though it will destroy categorization work already done. But in the future just leave the images in the Wiki Loves maintenance cats, don't try to add categories automatically, unless you are sure it will not cause redundancy and overcat. Darwin Ahoy! 17:47, 7 August 2023 (UTC)[reply]
@Jmabel, DarwIn, and Tm: The script seems to be running well, see edits at [2]. I'm running through the rest with User:Pi bot now, it will take a day or so to complete. Thanks. Mike Peel (talk) 20:59, 7 August 2023 (UTC)[reply]

@Jmabel, DarwIn, and Tm: Autocat has now been removed from the template. Please let me know if you spot any further issues. Thanks. Mike Peel (talk) 13:49, 13 August 2023 (UTC)[reply]

@Mike Peel Seems to be OK now, thank you for your understanding and for the quick fix. Darwin Ahoy! 20:18, 13 August 2023 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Template_talk:MonumentID&oldid=792808506"