Template talk:Infobox artwork/Archive 2

Archive 1

Archive 2

Archive 3

Wikidata version

Hi all. At the request of @Pharos, I've started a Wikidata version of this template at {{Infobox artwork/wikidata}}. The idea is that you just need to include that small bit of code in the article, and everything else will be fetched from Wikidata. If you don't want values fetching from Wikidata, then you can still define them locally and they will be displayed in preference to any values from Wikidata.

The long-term goal is that we can merge the Wikidata version into this template, so Wikidata information is available by default. However, some more development, documentation and testing work needs to happen before then to make sure that all parameters are supported and working well. In particular, the code for the dimensions is very complex at the moment, so I'm hoping we can simplify this in the new version.

Please test it, and let me know if you find any bugs! It is fine to include the Wikidata template in articles now, as we can easily migrate things over once this is more complete. Thanks. Mike Peel (talk) 13:52, 28 June 2017 (UTC)

Congratulations! An example of the infobox in action is at Flowers in a Glass Vase. The full list of articles which use the new template can be found here - 18 at the time of my writing this, and hopefully more to come soon. Wittylama 20:48, 28 June 2017 (UTC)

Mike Peel - my initial feedback: I think it ought to indicate "collection" by default. Currently it ignores this parameter from Wikidata and only shows "owner" which is less useful in many circumstances. If we're showing a field called "Accession" (which actually should be "accession No." or equivalent) then we should be saying what institution that number comes from. Wittylama 21:03, 28 June 2017 (UTC)

@Wittylama: Thanks for the feedback! collection (P195) is now also shown. Thanks. Mike Peel (talk) 23:02, 28 June 2017 (UTC)

@Nikkimaria: is now edit-warring about this new template, without pointing out the problems so that they can be fixed. That's really not helpful. :-( Mike Peel (talk) 01:44, 29 June 2017 (UTC)

I've pointed out specific problems, and you've edit-warred them back in without fixing. It's really not helpful to do that. Further, |suppressfields= returns an unknown parameter error so can't be used to address issues on individual articles. Nikkimaria (talk) 01:47, 29 June 2017 (UTC)

To expand: in all cases but one (The_Fall_of_Icarus_(Picasso)), location and collection are wholly or partially identical. Subject is also useless in the majority of cases, with the possible exceptions of Saint_Cecilia_(Artemisia_Gentileschi) and Au_Lapin_Agile - in most cases it's a long list of random descriptive keywords. Automatic import of both subject and one of location/collection should be removed. Thank you for fixing the edit link at least. Nikkimaria (talk) 02:11, 29 June 2017 (UTC)

@Nikkimaria: This is new code, and unfortunately I can't guarantee that it will be bug-free right from the start, which is why test cases are needed to start with (and why sandboxes are needed once this is more widely used), and feedback on how the code is working in practice is really important. It also takes me a bit of time to debug errors and find solutions for them, which is much easier if I can see the issues live. Thank you for pointing out the errors, but please could you do so by posting them here rather than just reverting the edits?

I've now fixed the problem with the [edit on Wikidata] link - thank you for pointing out the problem. Unlike the other Wikidata templates, here I've been trying to support draft articles - which requires linking against a specific Wikidata ID rather than just reading the page's ID. I thought I'd implemented this in {{EditOnWikidata}}, but it wasn't correctly handling cases where no QID had been passed. It now does this correctly.

I was using collection (P195) for the location rather than location (P276). This was a mistake, and one I hadn't spotted when I implemented @Wittylama:'s request above. I have now fixed this. However, it seems that the same information is present for both properties in the current examples. I think this is a specific issue with Met wikidata information that isn't present for other museums, so hopefully @Pharos: can comment on this. I think that this is something that needs resolving on Wikidata - or if it can't be resolved there, then maybe we can check to see if the two properties are the same and only show one of them if that is the case.

Thank you for fixing the bug in the row numbers at [1]!

I'll look into the suppressfields error.

In general, I'm happy to fix bugs as they arise, please just let me know about them here. I'm hoping that there are a lot less subjective constraints here than there were at {{Infobox person/Wikidata}}, and that this is closer to {{Infobox telescope}} in terms of presenting factual information without arguing so much about whether a parameter should be shown or not. Thanks. Mike Peel (talk) 02:12, 29 June 2017 (UTC)

@Mike Peel: The location/collection issue is present in almost all cases, not simply on Met works. The subject problem is definitely a subjective constraint and per above should be removed. Nikkimaria (talk) 02:16, 29 June 2017 (UTC)

@Nikkimaria: OK, please give me time to work through this feedback. On the subject issue, I've just changed it to use main subject (P921) rather than depicts (P180) as that seems more appropriate. Thanks. Mike Peel (talk) 02:18, 29 June 2017 (UTC)

@Nikkimaria: On the subject, please look at Au Lapin Agile and Alexander Hamilton (Trumbull) - are these appropriate? Are there still articles where inappropriate subjects are being listed? Thanks. Mike Peel (talk) 02:23, 29 June 2017 (UTC)

Great, I think this is a much more fitting for the infobox.--Pharos (talk) 14:38, 29 June 2017 (UTC)

@Nikkimaria: On the collection vs. location issue, the collection should only be displayed now if it is different from the location. Please let me know if you spot any cases where this isn't working right. Thanks. Mike Peel (talk) 02:40, 29 June 2017 (UTC)

@Nikkimaria: The suppressfields parameter should now be working without errors. The error was in the parameter checking code (I hadn't added it as a named parameter yet), not in the functionality. Please let me know if it still shows errors. Thanks. Mike Peel (talk) 02:47, 29 June 2017 (UTC)

I struggled a bit to get the dimension working with https://www.wikidata.org/wiki/Q23939644. Not sure if I'm missing something. Another thing I noticed is that Oil on canvas, listed as an example for medium redirects to Oil painting. That's a bit weird; oil paint is a material, but Oil painting is not. Lastly, I think it would be nice to also have the described at URL property (P973) listed as website. Mduvekot (talk) 01:56, 29 June 2017 (UTC)

@Mduvekot: Thanks for the feedback! With the dimensions, I think the problem here is that I have only enabled support for metric units at the moment, I will add support for imperial units soon. With the material, in cases like Au Lapin Agile it now links to oil paint, although in older versions (where the link was locally defined) it linked to oil painting. I don't know which is the best solution here, but it's possible to link to either of these on Wikidata and hence link to them here. With the URL, it might be better to use official website (P856) here, as there can be many URLs with descriptions but a more limited number of official URLs. Thanks. Mike Peel (talk) 02:33, 29 June 2017 (UTC)

@Mduvekot: I've now implemented support for inches (but not feet/metres/other units yet). I've changed the Wikidata values for My Shanty, Lake George to link to oil paint and canvas. I've changed the infobox there so it is mostly fetched from Wikidata, except for the subject (as per the discussion with Nikkimaria above about what this should contain) and the URL (as per my comment just above). Please have a look and see if it is working as expected, and please give feedback on the subject and URL issues! Thanks. Mike Peel (talk) 03:09, 29 June 2017 (UTC)

Wikidata version: location vs collection

First of all, thanks for this - I love it! Now addressing some of these concerns, starting with location vs collection: this is particularly sticky and gets interpreted differently (some people feel temporary exhibition locations belong under location, but I feel that is wrong and am on the fence about long-term loans). I would say stick to collection, since that is where the accession number comes from. For multi-site collections (National collections of Sweden, etc) then location might be some castle. Maybe you can try to check for whether location is a castle? Jane (talk) 06:21, 29 June 2017 (UTC)

@Jane023: Thanks for the feedback! I've changed the logic so that collection is shown, and then we show location if it is different from collection (rather than the other way around). Identifying specific types of locations would be very tricky to do. Thanks. Mike Peel (talk) 17:32, 29 June 2017 (UTC)

@Mike Peel: Rest_on_the_Flight_into_Egypt_(David,_Royal_Museum_of_Fine_Arts_Antwerp) now appears to be broken. Nikkimaria (talk) 00:34, 30 June 2017 (UTC)

@Nikkimaria: Thanks, I'm looking into it. I think it's a bug in the dimensions code that I've just been working on that is causing the next line to not display its key. Thanks. Mike Peel (talk) 00:40, 30 June 2017 (UTC)

@Nikkimaria: fixed. It was a stray start of a comment. Thanks again for pointing it out! Mike Peel (talk) 00:46, 30 June 2017 (UTC)

The Last Supper (Leonardo da Vinci) is also broken. Nikkimaria (talk) 12:56, 1 July 2017 (UTC)

@Nikkimaria: Assuming the issue was the 'Coordinates' label not showing, this is now fixed. The label is set to display=none in the main version of the infobox, apparently so that the coordinates look like part of the location field, which is now not always shown. Thanks. Mike Peel (talk) 13:25, 1 July 2017 (UTC)

How might one suppress the coordinates? Nikkimaria (talk) 19:29, 1 July 2017 (UTC)

I've modified the code so you can now set coords= and that will suppress them. Thanks. Mike Peel (talk) 22:27, 1 July 2017 (UTC)

Please use suppressfields=coords. Thanks. Mike Peel (talk) 00:23, 2 July 2017 (UTC)

I've changed the code today to use {{Wikidata location}}, which will also fetch the city/country of the artwork if appropriate (e.g. at The Tree of Knowledge (mural)). I'm not sure what to do with the logic checking code here now, though - it is useful to display the rest of the location even if P276 is the same. So for now I've changed it so that the collection is hidden if it's the same as P276 (sorry @Jane023). I'll have a think about whether there's a better way to do this, but suggestions would be welcome! Thanks. Mike Peel (talk) 21:11, 20 July 2017 (UTC)

@Mike Peel: How can location be suppressed? Nikkimaria (talk) 01:38, 21 July 2017 (UTC)

@Nikkimaria: Sorry, I'd forgotten to pass through suppressfields. suppressfields=location should now work. Thanks. Mike Peel (talk) 11:51, 21 July 2017 (UTC)

Wikidata version: authority control

Would love to see all authority control numbers linked and for large museums this would also negate the need for the collection problem above, since they often have their own property with their own link. Jane (talk) 06:21, 29 June 2017 (UTC)

@Jane023: I've included two authority control properties at the moment, namely The Met object ID (P3634) and RKDimages ID (P350). I'm happy to add more - is there a list of applicable properties that I can use? I'm not sure how to get the URLs for the IDs at the moment (I've had to hard-code the URLs for the current two), but once that's figured out then it should be straightforward to scale this up to cover more properties. Thanks. Mike Peel (talk) 17:34, 29 June 2017 (UTC)

Hmm I am also not sure about the whole list, but once you get the properties, then you can grab the prefix url from P1630 which is the "formatter url". For paintings located in the UK, the Art UK artwork ID is helpful (P1679) and for paintings located in France, the joconde ID is helpful (P347) and for paintings located in Germany, the bildindex is helpful (P2092). Other countries with such IDs are Denmark, Finland, and Belgium. Certain large museums have their own ID codes but I don't have a list. Maybe Multichill knows. Thanks for the RKDimages! Works great. Jane (talk) 20:11, 29 June 2017 (UTC)

Thanks @Jane023: After a bit of work, I've now created {{Wikidata ID}} that can fetch multiple IDs at once and return them as a line-separated list. It works, but it uses a number of expensive queries - hopefully someone can come along and Lua-ise it to make it more efficient. The code in the template is {{Wikidata ID|P347|P350|P1679|P2092|P3634|qid={{{qid|}}}}} - it should support all of the properties you've mentioned. If you come across others, then they're easy to add. Any suggestions that @Multichill or anyone else has would be welcome! Thanks. Mike Peel (talk) 21:50, 29 June 2017 (UTC)

@Jane023: It looks like displaying IDs can be a bit messy, e.g. see the Art UK ID at Self-Portrait Wearing a White Feathered Bonnet. I've implemented an option to not show the ID (and another to comma-separate rather than line-separate), in this case the difference is:

RKDimages ID: 36144
Art UK artwork ID: self-portrait-wearing-a-white-feathered-bonnet-99342

to:

RKDimages
Art UK artwork

or:

RKDimages, Art UK artwork

What do you (or others reading this) think? Thanks. Mike Peel (talk) 23:33, 1 July 2017 (UTC)

Yes agreed. This is how the person authority control template works too. Jane (talk) 06:35, 2 July 2017 (UTC)

Wikidata version: dates

We have some pretty largish problems with date fields for artworks still, so maybe including date can be an option (when you know the work is definitely dated) Jane (talk) 06:21, 29 June 2017 (UTC)

Mike has made dates and other fields optional now. Ideally, explicit date ranges (e.g. 1450-1500) should be possible also when they are included on Wikidata, as is the case for a number of Met artworks. Though they can already be represented by decade or century in a number of cases.--Pharos (talk) 15:02, 29 June 2017 (UTC)

Dates from Wikidata (specifically, inception (P571)) are displayed unless you locally override them (e.g., {{Infobox artwork/wikidata|year=}} - unfortunately the suppressfields parameter doesn't work for this at the moment, see User_talk:RexxS#WikidataIB_oddity). Ideally we would get them right on Wikidata! Thanks. Mike Peel (talk) 17:46, 29 June 2017 (UTC)

Also, if you use sourcing circumstances (P1480) = circa (Q5727902) for the year on Wikidata, then {{circa}} is now displayed. For an example, see Equestrian Portrait of the Count-Duke of Olivares. Thanks to Nikkimaria for demonstrating how to display circa dates in the infobox. Thanks. Mike Peel (talk) 18:11, 29 June 2017 (UTC)

@Mike Peel: Could you work on updating the documentation, particularly with regards to what the parameter names are, how to suppress, etc? I removed the template here because I couldn't work out how to suppress one, as the labels from the code didn't seem to work. Nikkimaria (talk) 01:12, 30 June 2017 (UTC)

@Nikkimaria: Will do (but not today as I'm going offline now). Which parameter couldn't you suppress? In general, it would be useful if you can comment here about parameters that you think need suppressing, explaining why, so I can see if there is a general solution that will avoid the same problems occurring in the future. Thanks. Mike Peel (talk) 01:17, 30 June 2017 (UTC)

This version has an identical header and subheader. Nikkimaria (talk) 01:23, 30 June 2017 (UTC)

@Nikkimaria: It looks like the article name was added to Wikidata and merged into the entry for the painting. It's not quite a duplicate (since one has "An" at the start), so I'm not sure how to automatically check for this. I've removed the alias from Wikidata and added back the template. I'm updating the documentation in another tab at the moment - I'll save the edit later today. Thanks. Mike Peel (talk) 23:54, 30 June 2017 (UTC)

How might one suppress the subheading? Nikkimaria (talk) 19:29, 1 July 2017 (UTC)

I've modified it so it can be suppressed by setting other_title_1= for now. I'm hoping to add it to suppressfields in the longer term, but that won't work yet. Thanks. Mike Peel (talk) 22:09, 1 July 2017 (UTC)

Please use suppressfields=other_title_1. Thanks. Mike Peel (talk) 00:23, 2 July 2017 (UTC)

Wikidata version: ownership

Though provenance data is really important, I think the stuff listed under ownership is not really infobox-ready. I think we still need to think about things like how to model art provenance on Wikidata. In general it would be nice to override or turn fields on/off. I feel the same way about "depicts" and even the accession number in some cases. Jane (talk) 07:09, 29 June 2017 (UTC)

Perhaps ownership could be like collection/location, only listed if it is different from the others. I think Mike has enabled suppressfields now, and replaced "depicts" too.--Pharos (talk) 14:27, 29 June 2017 (UTC)

Ownership is now only shown if it is not the same as collection. It can also be suppressed using suppressfields=owner (although there is a bug that the reference is still shown - I need to find a way to fix that.) Can you elaborate on the other issues with this parameter, please? Thanks. Mike Peel (talk) 17:49, 29 June 2017 (UTC)

Yeah as long as you can override or suppress then fine. Ownership problems are e.g. that start/end dates don't line up the way you would do this in chronological order if you were listing them by hand. The accession numbers may also pile up in weird order when there is more than one collection but you just want to show the one for the location. Jane (talk) 20:14, 29 June 2017 (UTC)

Please point out any good examples that you come across of the problems here, and we can see if there are ways to sort them out. Thanks. Mike Peel (talk) 21:56, 29 June 2017 (UTC)

OK here's one that I switched out anyway because the provenance is described in the article. Useful for reference maybe? Lucretia (Rembrandt, 1664) Jane (talk) 10:32, 1 July 2017 (UTC)

Monograph catalogs

For some well-known painters, there is a "definitive" catalog, or sometimes 2 or 3 of these. Some painters have their works completely catalogued on Wikidata. Rembrandt for example has a fairly recent "definitive" catalog that is complete on Wikidata. Portrait of Catharina Hooghsaet has the catalog number in the artwork template, but if you look at Wikidata, the item is in several other catalogs too. We may need a property "preferred artist catalog" or something to handle this, but maybe a work around is to include "/catalog=Q nr." ? Jane (talk) 06:30, 1 July 2017 (UTC)

Difficult cases?

Stolen art...

Can anyone suggest some difficult cases to test the wikidata version against? The more we can test this now, the fewer problems we'll have when we merge this in to the main version (which I'm hoping we can do reasonably soon). Thanks. Mike Peel (talk) 00:35, 30 June 2017 (UTC)

I'd think that one way would be to look at any of the painting articles currently listed as Featured quality. Many of them have quite small infoboxes, so they may not be technically difficulty, but they are ones where the information has been most closely scrutinised for its appearance. So, if you're able to get feature-parity with the present look, that would be something. I would suggest not trying to add new infoboxes where there currently isn't any - since some art-article writers particularly don't like infoboxes at all.

Otherwise - Three Beauties of the Present Day might be a good one (to stress-test how to specify information in other languages); Campbell's Soup Cans is a good one to test complex location/collection/ownership and dimension properties; Four Freedoms (Norman Rockwell) is a multi-image infobox. How's that? Wittylama 13:57, 30 June 2017 (UTC)

Take a look at this one in preview mode after switching the template: River Landscape with Ferry. Jane (talk) 14:20, 30 June 2017 (UTC)

Thanks for the suggestions! I'll look through them. On FAs, I added the template to Annunciation (Memling), but @Nikkimaria: reverted it without explanation, I'd be interested to know why without getting into an edit war here. Thanks. Mike Peel (talk) 23:46, 30 June 2017 (UTC)

See Wittylama's comment. Nikkimaria (talk) 02:52, 1 July 2017 (UTC)

Here's an interesting one: The Storm on the Sea of Galilee. Do try it out in preview mode (collection: Unknown value doesn't show up well I think). Due to the major theft, which is mentioned in the current static infobox: does it make sense to do something with P793 (significant event)? Spinster (talk) 18:40, 1 July 2017 (UTC)

I always record thefts, destructions and other not so nice events with P793 (significant event). Multichill (talk) 10:54, 2 July 2017 (UTC)

@Mike Peel: good job Mike! For paintings we record things that change over time on Wikidata: Collection, location and owner (and other things). On Wikipedia we only want to show the current collection, location and owner. Sometimes these are the same, but sometimes a painting is in multiple collections (for example a long term loan) or even owned by multiple organizations, for example Portrait of Oopjen Coppit. Location is either Rijksmuseum or Louvre, it's in both collections and it's owned by France and the Netherlands. The list of loans in the Rijksmuseum contains more fun edge cases like these. If some fields are the same (for example location==collections==owner), it doesn't make sense to show it multiple times so you'll need a decision tree here. Multichill (talk) 10:54, 2 July 2017 (UTC)

@Multichill: Thanks for the feedback. At the moment the only way the code can distinguish between an important value to show and one that shouldn't be shown is by the preferred/normal ranks on Wikidata - do you think that would work here, or would some sort of system that looks for the value with the latest date be needed? (Which would be something I'd ask @RexxS if he can figure out. ;-) ) Thanks. Mike Peel (talk) 13:44, 2 July 2017 (UTC)

With multiple valid values that doesn't work. I usually look for claims that don't have an end date. Multichill (talk) 14:43, 2 July 2017 (UTC)

Infobox replacement

We are likely to get into conflicts with community members when replacing classic infoboxes with this template, so it may help to share some experiences. One I ran into recently was the argument that " it's never an improvement to use [Wikidata-generated infoboxes] to replace a manually written infobox". [2] It may help to make an FAQ to explain to folks why this new infobox method has its benefits. -- Fuzheado | Talk 08:02, 1 July 2017 (UTC)

Well I would agree (see the examples I posted). I have been replacing my own work and the work done by others on "super stubs" of less than 700 bytes. Jane (talk) 13:41, 1 July 2017 (UTC)

@Fuzheado: I've written a bit of a FAQ at User:Mike Peel/Wikidata-driven infoboxes - it still needs work, but it might be helpful here. I don't expect that we'll convince everyone, but we're adding functionality here that can be turned on/off as needed, so if people insist on keeping manually written infoboxes/lines in some articles then we can support that while using Wikidata information elsewhere. Thanks. Mike Peel (talk) 13:50, 1 July 2017 (UTC)

Materials (medium): The wikidata infobox just lists materials like Oil paint, canvas, but the old infoboxes used sentance like Oil on canvas. Is it possible to have that in the Wikidata too. Christian75 (talk) 21:39, 2 July 2017 (UTC)

And about locations (or collection as it says now). I find it less informative that e.g. My Shanty, Lake George says The Phillips Collection and not "The Phillips Collection, Washington, D.C." as it did before. With the new way you have to click on the wikilink to find the artworks location. Christian75 (talk) 22:26, 2 July 2017 (UTC)

Dimensions: I find it more easy to read "20 in × 27 1/8 in (50.8 cm × 68.8975 cm)" than 20 in (51 cm) × 27.125 in (68.90 cm) because I'm only interested in one part of the line, so I skip quickly if I see "in", but the new way I have to read it all. If anybody agree, it should not be diffucult to change. Christian75 (talk) 22:26, 2 July 2017 (UTC)

@Christian75: I agree it shouldn't be difficult to change, but the dimensions code is currently a mess (see lines 63 through 134 in the non-wikidata version!). I will implement a better version, but it will take me a short time. In general, I'm busy for the next few days, but I'll work through your points (and others) when I can. Thanks. Mike Peel (talk) 09:51, 3 July 2017 (UTC)

References

Citations don't seem to work properly when they're something other than reference URLs. See for example this version - on Wikidata there is a link to the full bibliographic details of the source, but here you can't really tell what the source is. Nikkimaria (talk) 01:41, 7 July 2017 (UTC)

That's because the reference is a link to a book rather than reference info in the entry. I'm hoping that {{Cite Q}} can provide better references here (e.g. Keith Christiansen; Elizabeth Cropper; Alessandro Zuccari; et al. (2001). "Orazio and Artemisia Gentileschi". New York City. Metropolitan Museum of Art. JSTOR 1358795. Wikidata Q29017598.) - but I haven't figured out how to include that in the infobox code yet. Thanks. Mike Peel (talk) 10:53, 7 July 2017 (UTC)

@Nikkimaria: Thanks to @Thayts: the full references are now shown in these cases. :-) Thanks. Mike Peel (talk) 21:01, 8 July 2017 (UTC)

That's definitely an improvement, thanks Thayts. Could we also amend the formatting? Obviously we can't account for every citation style, but I don't think any italicize location, for example. Nikkimaria (talk) 21:26, 8 July 2017 (UTC)

@Nikkimaria: Can you ask that at Template talk:Cite Q please? I'm not involved in the development of that code. Thanks. Mike Peel (talk) 21:29, 8 July 2017 (UTC)

Series

A number of artwork articles are not about an individual artwork, but about a series or other group of artworks. A good example is Sunflowers (Van Gogh series). A point of failure in this case is multiple images values, which breaks the infobox. Perhaps also if the article is about a series, one could use series (P179) to list the constituent works, or if something is a constituent work, to list the "mother" series.--Pharos (talk) 19:45, 11 July 2017 (UTC)

@Pharos: part of the series (P179) can be used to indicate that a work is part of a series, but not for the other way around - a different property should be used to list works that are part of the series in the entry about the series. For telescopes at observatories I've been using has part(s) (P527) and part of (P361), but I'm not sure if those would be appropriate here. Thoughts? Thanks. Mike Peel (talk) 00:41, 12 July 2017 (UTC)

Type

I"d suggest a field for the basic type of artwork, e.g. painting, sculpture, drawing, print, photograph, vase, etc, where applicable. This would be based on instance of (P31), although I think it might be good to abstract to a higher level and check (for example) whether something is in a subclass of sculpture.--Pharos (talk) 19:53, 11 July 2017 (UTC)

Links to "Anonymous" disambiguation page

A number of articles that use the Wikidata version of the template appear in Special:WhatLinksHere/Anonymous, even if (in some cases) the work in question is not anonymous and the word "anonymous" doesn't appear anywhere in the article or in the associated Wikidata entry (for example, Time Suspended in Space (South Africa). There are also some anonymous works in the list, but these should not be linking to the Anonymous disambiguation page. Can anyone identify the cause of this anomaly? --R'n'B (call me Russ) 14:45, 18 August 2017 (UTC)

R'n'B, it is definitely coming from wikidata. in the example you cited, the wikidata entry was changed here. it's possible that it just took a couple days for the "what links here" to update. as for the others that are using anonymous in the wikidata, I would imagine this is a more general problem with pulling information from wikidata, so perhaps, either VPT or Module talk:Wikidata can help? Frietjes (talk) 17:06, 18 August 2017 (UTC)

@R'n'B and Frietjes: I've added a check for anonymous artists with this edit, I think that should avoid some of these links. Others may appear if other anonymous is used for other properties on Wikidata, though. Thanks. Mike Peel (talk) 23:09, 18 August 2017 (UTC)

Mike Peel, would it be a good idea to use anonymous work in the corresponding wikidata entries? that would also avoid linking to the dab? Frietjes (talk) 13:43, 19 August 2017 (UTC)

I think that would work, but it probably needs input from others (the wikiproject & wikidata project chat perhaps). Thanks. Mike Peel (talk) 14:13, 19 August 2017 (UTC)

Mike Peel, I believe there were a total of about 5 articles? would it be possible to track them? after your change, we can't find them with the whatlinkshere. Frietjes (talk) 14:37, 19 August 2017 (UTC)

@Frietjes: In principle there are around 20,000, based on looking for paintings with anonymous creators - try running this at http://query.wikidata.org/

SELECT ?painting ?paintingLabel WHERE {
 SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
 ?painting wdt:P31 wd:Q3305213.
 ?painting wdt:P170 wd:Q4233718.
}

Of course, not all of those have articles yet. ;-) Thanks. Mike Peel (talk) 15:54, 19 August 2017 (UTC)

Todo

(not sure it is the proper way to do it, but I feel we need one easy-to-read list.)

Not directly importable, but in case parts of it can be reused fr:Module:Matériau uses P518 qualifiers to render strings like "oil on canvas" or "timber frame, steel and glass cladding". --Zolo (talk) 12:15, 24 August 2017 (UTC)

Template-protected edit request on 28 August 2017

add 'collection' to the parameters allowed in the 'Check for unknown parameters' section. Near the end

change 'city | completion_date' to ' city | collection | completion_date' Ahwiv (talk) 19:13, 28 August 2017 (UTC)

 Done Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:36, 28 August 2017 (UTC)

Wikidata objections

Some objections raised to the Wikidata implementation at Wikipedia talk:WikiProject Arts#Migrating art infoboxes to wikidata:

Extended content

Many articles have had their infoboxes supplanted by links to Wikidata. This is a very ill-considered move. They look terrible (with little symbols and and unfamiliar links), subject their content to the vagaries and preferences of the individual editors of another project with its own arcane purposes, and have not been approved or even discussed here, which should have been done before any such wholesale changes were started. They should be reverted. Kablammo (talk) 02:58, 8 September 2017 (UTC) Discussion about this has been taking place at Template talk:Infobox artwork (also see the talk page archive). The formatting can be changed if needed, just post a suggestion for how to do so on the infobox talk page and we can see what the consensus is. Wikidata is another *Wikimedia* project, same as Wikimedia Commons but for data rather than media. Thanks. Mike Peel (talk) 10:49, 8 September 2017 (UTC) Mike, that is useful background, but I believe that members and other editors interested in this project-- the arts-- should decide whether to implement this change. In general, the subject of infoboxes is controversial, with many editors opposing them-- particularly in the arts-- on grounds argued elsewhere. But if an infobox is used, can we really say that the one currently used on The Hay Wain is superior to the one it replaced? (See the former infobox on the prior version of the article.) Is it important to have those tiny pencils? Should the beginning of an article prominently feature the accession number? or identifiers? And the "Preceding by" field is particularly fraught, and an invitation to original research and factual disputes. (Would anyone care to do a succession field for The Burghers of Calais or The Gates of Hell?) Kablammo (talk) 15:40, 8 September 2017 (UTC) @Kablammo: Please do have a look at the discussions I linked to. The request to develop the wikidata version came from editors working on these types of articles, and I then worked on developing the infobox based on the code I've been using in other cases (e.g. {{Infobox telescope}}). The code is currently mostly working, but a few more things need doing with it (in particular, the dimensions code can be better), and I'm hoping it can then be merged in with the main version of the template (it is only separate at the moment to make sure it all works right first). I've been rolling it out across some articles to see how well it copes with different situations and different amounts of Wikidata information, to make sure it at least reproduces the local versions. It might be best to keep the discussion all in one place, so perhaps we could move this to Template talk:Infobox artwork and the other people I've been working with can join in this discussion (or we can ping them here if you'd prefer). I always appreciate constructive feedback, though, so thanks for your comments about this so far. Thanks. Mike Peel (talk) 16:20, 8 September 2017 (UTC)

Cross-posting my reply, to pick up discussion here: (The Hay Wain version with Wikidata infobox was under discussion) I agree that the pencil icons and repeated footnotes are excessive ("[edit on Wikidata]" is sufficient, as would be a separate section for group footnotes, as done in other infoboxes) but that can easily be discussed on the infobox's talk page. As for letting Wikidata handle the infobox parameters, I say good riddance—a massive waste of time in my watchlist. czar 17:37, 8 September 2017 (UTC)

Oil paint, canvas

Just to note that if "oil paint" and "canvas" are both used in the material values on Wikidata, they should now be automatically replaced with Oil on canvas. Please let me know if you spot any issues with this. Thanks. Mike Peel (talk) 20:28, 8 September 2017 (UTC)

That's great, maybe we should do the same for Watercolor on canvas, and possibly other subclasses of paint.--Pharos (talk) 13:44, 12 September 2017 (UTC)

Doing it value by value seems like an andelss job (tempera on oak panel, ink and colors on paper...). I think the better solution is to make use qualifiers. Painting support like canvas or panel are usually marked with "applies to part: painting surface" (P518 Q861259). A more general use of P518 qualifiers might also be useful (like in the "Matériau" row of fr:Statue de la Liberté. It might make it harder to have just one link like in Watercolor on canvas but I have to admit I don't really see why clicking on "canvas" should lead us to a page on watercolor painting. --Zolo (talk) 11:17, 15 September 2017 (UTC)

I am looking at

medium: Material used by the artist or designer to create the work of art. Examples: "Oil on canvas", "Bronze sculpture", "Ceramic tile"

and am thinking, "in an article about a statue" the medium field should just say, "bronze" or "limestone" or terra cotta" and not include the word "sculpture" in the medium field. We don't recommend saying "Oil painting of canvas" so why with sculpture? Einar ask Carptrash (talk) 19:04, 15 September 2017 (UTC)

Other titles

Hi! Is it a good idea to use Wikidata aliases for this? Isn't it better to use d:Property:P1476? It seems that lots of items have this property. --Papuass (talk) 15:06, 18 September 2017 (UTC)

Redundant references

Looking at The Horse Fair (which is our Metropolitan Museum of Art Weekly Challenge!), I notice that two identical infobox-generated citations are given, with the only difference being the "retrieved" date. Maybe we could find a way to combine these into one reference on Wikipedia, and just list the different dates separated by commas, after the reference url.--Pharos (talk) 18:17, 22 September 2017 (UTC)

@Pharos: This isn't easy to do in the code (since the references are fetched in different parts of the code that don't know about each other). The best thing to do is to tidy up the references on Wikidata instead, which is a bit laborous but gives the desired result. Thanks, Mike Peel (talk) 21:25, 22 September 2017 (UTC)

@Mike Peel: Thanks, Mike! For fixing, and for clearing me up on the technical issues.--Pharos (talk) 15:37, 25 September 2017 (UTC)

Secondary title

Suppressing the secondary title apparently also suppresses the title, as seen in this is; can this be fixed? It should be possible to suppress one without affecting the other. Nikkimaria (talk) 18:53, 2 November 2017 (UTC)

@Nikkimaria: This is odd. It looks like {{#invoke:WikidataIB|checkBlacklist|name=title|suppressfields=other_title_1}} triggers the blacklist when it shouldn't. @RexxS: is there a way of fixing the blacklist code here, or should we change to using something other than "other_title_1" here? Thanks. Mike Peel (talk) 21:36, 3 November 2017 (UTC)

@Mike Peel and Nikkimaria:The code is working as expected . If you have a blacklist with the characters "title" in it, then a field called title will be suppressed. I wrote it that way so that it could cope with all varieties of alternative spelling in field names. If it only works with an exact match, then you'd have to blacklist "this field", "this-field", "this_field", and "thisfield", etc. for every conceivable permutation, rather than just blacklisting "field" as you can now. The downside is that infobox designers have to be a bit more picky about the words they use to name different fields, sorry. In your case, you could use e.g. |name=fulltitle when invoking WikidataIB in the infobox design (without changing the actual parameter name of title in all other places); and then you could use |suppressfields=fulltitle in an article. You'd just have to include a note to that effect in the infobox documentation. If you can think of a better scheme, I'd be happy to consider how to implement it (although I won't be implementing any more changes to Module:WikidataIB while it remains unsynchronised from the development work). --RexxS (talk) 22:03, 3 November 2017 (UTC)

Having said that, I couldn't resist making a demo of how we could implement exact matching, if that was what was preferable. It's at Module:Sandbox/RexxS/Blacklist and some test cases are at Module talk:Sandbox/RexxS/Blacklist. --RexxS (talk) 23:02, 3 November 2017 (UTC)

Thanks RexxS. Either way works, I think, so I'd say this is up to @Nikkimaria as the main user of the suppressfields feature. I don't think there's any significant technical/logistical barriers in either way: I'm happy to write a bit of pywikibot code that goes around and checks for current cases of |suppressfield=title that could be changed to |suppressfields=fulltitle if that would help. Thanks. Mike Peel (talk) 05:35, 4 November 2017 (UTC)

Well, if the hope is to eventually use this more widely, it shouldn't be designed for me personally! But the argument against exact matching makes sense. What about changing the name of the secondary title parameter to altname or similar? Nikkimaria (talk) 15:37, 4 November 2017 (UTC)

That could be confused with alt tags for images. How about othername1? Thanks. Mike Peel (talk) 11:15, 5 November 2017 (UTC)

Multiple websites?

Adam and Eve (Dürer) is behaving strangely (when I insert WD template). Also suppress is not working for website URL. Tried fixing, but did not succeed. - Adam-Papuass (talk) 21:20, 3 November 2017 (UTC)

@Papuass: I think the problem is caused by multiple URLs on Wikidata, which are all equally ranked. At the moment, there are two solutions: either set a preferred URL on Wikidata, or set "| website=example.com" that should locally override it (it seems to work for me?). There is a solution in the works to retrieve a max of 1 URL from Wikidata, and I'll have a think about whether there's a good way to properly format multiple URLS from Wikidata (suggestions welcome!). Dimensions are also tricky in this case, with two panels, so I'd suggest locally overriding that one too (just keep the dimensions= line). Thanks. Mike Peel (talk) 21:32, 3 November 2017 (UTC)

Yes, this is complex case (that is diptych) ar there are 2 viable websites to show — one link for Adam, one for Eve. Right now I just made override with empty website. --Papuass (talk) 21:37, 3 November 2017 (UTC)

Better markup would be:

| website=
{{Plainlist|
* [https://www.museodelprado.es/en/the-collection/online-gallery/on-line-gallery/obra/adam/ Adam]
* [https://www.museodelprado.es/en/the-collection/online-gallery/on-line-gallery/obra/eve/ Eve]
}}

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:28, 7 November 2017 (UTC)

Template-protected edit request on 14 February 2018

Add parameter: italic other_title_1 = no

Currently we have: italic title=no

Thanks! – Lionel^(talk) 09:35, 14 February 2018 (UTC) – Lionel^(talk) 09:35, 14 February 2018 (UTC)

@Lionelt:  Done. --Ahecht (TALK
PAGE) 22:07, 14 February 2018 (UTC)

Automatic linking of artist name harmful

As discussed at Talk:Donald Trump baby balloon#Matt Bonner link in infobox, the automatic linking of the artist name caused a link to the wrong article. This needs to be disabled. Can someone please attend to that, and do we then need a bot to add a standard wiki-link link to affected pages? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:13, 13 July 2018 (UTC)

Anonymous works and Wikidata

@Mike Peel: Portrait of an Unknown Gentleman now shows "anonymous" in the Wikidata bases infobox. Would be nice to have some logic to have some logic to extract the qualifier from d:Q3937668 and show "workshop of Hans Holbein" in the infobox. Multichill (talk) 10:59, 11 August 2018 (UTC)

Switching to onlysourced=yes by default in the Wikidata version

@Nikkimaria has been changing inclusions of {{Infobox artwork/wikidata}} to only show information from Wikidata that has a reference. To be honest, I can't disagree with this - if we can't reference the information that we're showing, then we shouldn't be showing it. So I've changed the default here to onlysourced=yes. This will remove information from infoboxes - please add references to continue showing this information. Thanks. Mike Peel (talk) 23:09, 7 December 2017 (UTC)

Hi Mike, thanks, but I think this has broken the image formatting? Also, not sure it is currently possible to cite aliases on Wikidata... Nikkimaria (talk) 23:28, 7 December 2017 (UTC)

@Mike Peel: This doesn't appear to be working correctly. For example, on Judith_and_her_Maidservant_(Gentileschi,_Cannes), the date is unsourced on Wikidata but is still displayed here, even when onlysourced is set explicitly. Also, suppressfields doesn't appear to be working either. Nikkimaria (talk) 00:54, 12 July 2018 (UTC)

@Mike Peel: are you still working on this or did the locals bully you too much and you moved on? That's what I'm doing. Multichill (talk) 19:27, 11 August 2018 (UTC)

I'm working on other things at the moment. I'll circle back to this infobox when I can (or if anything comes up that needs urgently fixing). Thanks. Mike Peel (talk) 19:35, 11 August 2018 (UTC)

Edit request

@Frietjes, Ahecht, and Fram: (Relatively) recent editors of this template: The title of the template is italicized, and I'm afraid that I do not have the requisite permission to fix it, nor the knowledge of the markup code to do so if I did. Would someone please be so kind as to fix this? —DocWatson42 (talk) 03:38, 12 March 2019 (UTC)

DocWatson42, this is caused by the examples on the documentation page. the only way to fix it without changing the examples is to add a {{DISPLAYTITLE:{{FULLPAGENAME}}}} at the bottom of the page, which gives a warning since the displaytitle is being changed multiple times. I suppressed the warning by wrapping it in a parserfunction. Frietjes (talk) 13:35, 12 March 2019 (UTC)

@Frietjes: Thank you ^_^ —DocWatson42 (talk) 15:20, 12 March 2019 (UTC)

Category:Infobox artwork without image?

Would it be possible to create a tracking category called Category:Infobox artwork without image? An image is obviously vital for visual art, and it's almost always possible to upload one (if it isn't free, it almost invariably meets WP:NFC). For more information about infobox tracking categories, see Category:Infoboxes needing cleanup – Finnusertop (talk ⋅ contribs) 10:28, 19 August 2019 (UTC)

"An image is obviously vital for visual art" I couldn't agree with you more. Sounds like a good idea to me. Bus stop (talk) 19:58, 29 August 2019 (UTC)

Bug: Two images for an artwork messes up infobox

If there are two images (P180) for an artwork, this template smashes the two image file names together and it appears as a non-working redlink in the infobox. If you set one image to "preferred" rank above the other(s) then it works out OK. Example is The Oxbow and the diff at Wikidata that made it work [3]. -- Fuzheado | Talk 20:34, 25 January 2020 (UTC)

Maplink-compliant

Is this template Maplink-compliant? See Talk:Discovery_Bridge_(Columbus,_Ohio) for context. @Ɱ: FYI! ---Another Believer _(Talk) 21:25, 10 February 2020 (UTC)

@Evad37: - "default is hospital"? Can we make it 'monument'? ɱ (talk) 23:53, 16 April 2020 (UTC)

Sorry, I did a copy-paste from Infobox hospital and didn't clean up enough. - Evad37 [talk] 23:56, 16 April 2020 (UTC)

Template-protected edit request on 8 May 2020

Please add "mapframe-marker" to the "#invoke:Check for unknown parameters" section of the template, so that editors do not receive "Warning: Page using Template:Infobox artwork with unknown parameter "mapframe-marker" (this message is shown only in preview)." when editing with this template. Phuzion (talk) 00:05, 8 May 2020 (UTC)

 Done – Jonesey95 (talk) 02:49, 8 May 2020 (UTC)

Mobile

I want to say about artworks are mobiles. Which parameter? Type seems perfect, but was deprecated. --Gerda Arendt (talk) 20:47, 6 June 2020 (UTC)

Autolink artist

This was previously discussed in 2014 and although most editors agreed, nothing's been done about it. It is inappropriate to autolink to the artist. It isn't hard to enter a name in this field and then link it. It is always inappropriate for a name to link to a disambiguation page. @Frietjes: could you please nuke this function? Schwede66 23:55, 18 June 2020 (UTC)

User:Schwede66, what is the plan for the ca. 1500 pages in Category:Pages using infobox artwork with autolinked artist field? should we have a bot make this edit first, which would preserve the appearance, but make it obvious how to fix incorrect linking? Frietjes (talk) 00:00, 19 June 2020 (UTC)

That would be appropriate, Frietjes. Yes. Here's a suggested edit summary:

As per [[Template talk:Infobox artwork|this discussion]], auto-linking for this field will be turned off shortly and this edit is in preparation. Please confirm that the correct article has been targeted and if not, please change the link or unlink the name if the target article does not exist.

Schwede66 00:09, 19 June 2020 (UTC)

User:Schwede66, okay, I made a script that checks to see if the text is linked anywhere else in the article and only links if that is the case. in the cases where it doesn't find the linked text, I am fixing them by hand (using the nowiki hack where necessary). we can clean up any that are using the nowiki hack in a second pass (should be less than 100). Frietjes (talk) 00:52, 19 June 2020 (UTC)

Crikey, you are brilliant! Let me know if I can lend a hand with something. Schwede66 00:59, 19 June 2020 (UTC)

Thank you! I'm glad to see autolinking removed. I've always hated this feature, and often had to go back and add "nowiki" to prevent linking to the wrong person. ---Another Believer _(Talk) 14:29, 19 June 2020 (UTC)

User:Schwede66, all fixed. I kept the tracking in Category:Pages using infobox artwork with unlinked artist field just in case there are any that get rolled back. Frietjes (talk) 19:36, 19 June 2020 (UTC)

Legend! Thank you. Schwede66 19:47, 19 June 2020 (UTC)

• So is the idea that people who happen to be watching the article affected should manually reinsert the wikilink that has been removed if it was a good link? --Andreas Philopater (talk) 21:43, 19 June 2020 (UTC)

Frietjes has done a bot run and most links should be fixed already. If there's something left to attend to, please do so. Schwede66 21:58, 19 June 2020 (UTC)

Improved mapping for major artworks and installations

Could support for the pushpin_map parameter be added to Template:Infobox artwork, similar to that which already exists for Template:Infobox museum? For an example of its use, see the infobox at Museum of Science, Boston.

This feature would be very useful for indicating the geographical location of large public artworks and sculptural installations, such as the Tarot Garden, Cloud Gate, Sean Collier Memorial, Fearless Girl, Kendall Band, and The Sphere.

Or is the infobox map format used in Museum of Science and Industry (Chicago) preferable for some reason? Are there any tutorials or Wikipedia editorial guidelines for using one map format or another within infoboxes? Reify-tech (talk) 22:44, 18 July 2020 (UTC)

@Reify-tech: Hi and thanks for the question, sorry for answering so late. Pushpin maps do seem TO BE possible already, please read the template documentation for instructions on how you can do that. Though yup you can use the format used in the Museum of Science and Industry article. I and many others prefer that style (called maplink or mapframe maps), as you can zoom in and out to see much more detail, and creating the maps is simpler and easier, and they will update automatically. There are guidelines on how to create those maps on this template's documentation as well, but you can find out more at this link. Feel free to ask any more questions, and I'll do my best to help. ɱ (talk) 03:37, 8 October 2020 (UTC)

Thank you for responding to my inquiry. I am not expert on Wikipedia mapping capabilities, but will try to follow your links as I have time. I appreciate the pointers to more info about what is possible, and will ask more questions if and as I have them. Reify-tech (talk) 15:46, 9 October 2020 (UTC)

Proposal to add "former location" or "former coordinates" for statues etc that have been moved/removed

As the header says, shall we add an attribute to the infobox for "former location" or "former coordinates"? This would be useful for the many confederate statues etc that have been moved/removed recently. In research on one of the Columbus statues at a recent AfD, I discovered that it had actually been moved a couple of times, so this is an attribute that would possibly apply to many public artworks. Consider something like Richard Serra's Tilted Arc, perhaps one of the most famous public artworks ever removed.

I guess this is a proposal, so please indicate if you

• oppose, or
• prefer "former location", or
• prefer "former coordinates" or
• some other atrribute.

ThatMontrealIP (talk) 01:21, 3 July 2020 (UTC)

N.B. while googling former public artworks, I came across Split Pavillion and made a page for it. A perfect candidate for the a new former location attribute. ThatMontrealIP (talk) 03:18, 3 July 2020 (UTC)

• Prefer former coordinates. Thanks for bringing this up, it's an important factor that Wikipedia likely wasn't built with before such widespread removal of notable monuments. Definitely important to keep the coordinates on the Wikipedia articles in this way. ɱ (talk) 01:28, 3 July 2020 (UTC)
• Definitely support. My off-the-cuff solution is to add a single new parameter, "former_location" or something like that, as a yes/no. If yes, it simply changes "Location" to read "Former location". That way, there's no need to modify the mapframe support. Pi.1415926535 (talk) 03:53, 3 July 2020 (UTC)
• Support This certainly isn’t a new problem. Of the articles that I have written about artworks, three of them are not in their original location, with two of them in their third location by now. The new parameters should thus allow for more than one former location. Schwede66 15:02, 3 July 2020 (UTC)
• Support Relocation of major artworks has been happening for a long time, including Egyptian obelisks and large Renaissance sculptures which have famously been seized and taken as war booty, sometimes later returned and sometimes not. Whatever mechanism we use to indicate physical location should accommodate multiple successive relocations, optionally with the dates of occurrence (if known). It should also be possible to indicate "Location unknown", such as with the legendary Amber Room, whose original installation in Saint Petersburg (Russia) was well-known, but which mysteriously disappeared during World War II, although a reconstructed reproduction was completed in 2003. There are many other examples of lost artworks, including ones stolen during the Isabella Stewart Gardner Museum theft. I prefer "former location" as easier to understand, whereas "former coordinates" may sound very technical and somewhat intimidating to the average reader. Reify-tech (talk) 15:46, 9 October 2020 (UTC)

In case anybody thinks that lost artworks are rare occurrence, there is an extensive Wikipedia article on "Lost artworks", and its bibliography doesn't yet mention two recent books I have which were published about the topic. Reify-tech (talk) 15:57, 9 October 2020 (UTC)

Can anyone close this now, or are there any more who wish to comment? ɱ (talk) 03:37, 8 October 2020 (UTC)

Coordinates of photographs

Is it appropriate to give an article about a photographic artwork the coordinates of where that photo was taken? (eg. Station Squabble, which appears to have the coordinates of Charing Cross tube station.) The documentation says the coordinate field is "only for the exact coordinates (when known) of the artwork's own location", but that could charitably be read either way. --Lord Belbury (talk) 15:41, 9 March 2021 (UTC)

Metric vs. imperial dimensions first

I'm writing a page for an artwork in the United States (Draft:Archimedean Excogitation), so I'd like to list the imperial dimensions first. I'm not sure if there's any way to do this, though, and the code is more than a little scary, so I don't want to mess with it. Help? {{u|Sdkb}} ^talk 09:38, 5 March 2021 (UTC)

Frietjes, I ran across this in The Peace Child of Hiroshima. It has the imperial dimension first in the prose (as expected for U.S.), but metric first in infobox. It would seem that the template, if given imperial, would display imperial first. The way it works may be influenced by also supporting both both imperial and metric (not just one with auto conversion to the other). There would need to be a new parameter to say which one to output first, or it could just stay with metric first in that case since this is probably so uncommon it's not worth worrying about. But for the common case, can you see how difficult it is to output the given measurement system first. MB 02:32, 5 May 2021 (UTC)

@MB and Sdkb: unfortunately the code for dimensions is a complete nightmare. the last time this came up (this thread) I suggested that you could just use |dimensions= with the same {{convert}} as the prose (easier to keep consistent with cut-and-paste from the prose). Frietjes (talk) 16:00, 5 May 2021 (UTC)

Frietjes, yeah, I figured that might be the case. It'd be good to Luaify the template, perhaps. Regarding triggering, there could be a parameter, and/or it could cue off templates like {{Use American English}}. {{u|Sdkb}} ^talk 17:37, 5 May 2021 (UTC)

@Sdkb: I would think the obvious thing to do would be to show imperial first if imperial are specified and metric first if metric are specified. Frietjes (talk) 17:50, 5 May 2021 (UTC)

@Frietjes: Facepalm Right you are. {{u|Sdkb}} ^talk 18:09, 5 May 2021 (UTC)

@Frietjes: An edge case where that might work poorly is where the canonical units are imperial, but the imperial units are "non-numeric" because they use fancy fractions via {{frac}}, so metric is specified manually. {{Nihiltres |talk |edits}} 05:02, 19 May 2021 (UTC)

@Sdkb: As the author of the original mess (woo, ten-year-old edits that predate Lua!), I'll take another look at Lua-fying it … I've bounced off the task at least twice because Module:Convert is awful to use externally. The logic of the original mess is actually fairly straightforward if decomposed … it's just massively redundant, which means it's all but unreadable. For the record, this pseudocode should largely summarize the logic:

for each unit-system in {metric, imperial} do
  for each dimension in {height, width, length} do
    if unit-system dimension provided, then display that dimension (handling special ftin case)
    else if opposite unit-system is numeric, then display conversion (handling special ftin case)
    else if opposite unit-system dimension present, then show an error placeholder
    else display nothing (this dimension isn't present)
    --
    if this dimension and any next dimension is present, then add a spaced times symbol
  display the unit for the unit-system
handle diameter similarly to single-dimension logic of HWL
if "dimensions" param is present, then display its content
if "dimensions_ref" param is present, then display its content

The redundancy comes from "unrolling" the loops (since wikitext lacks loops) and duplicating a lot of stuff across the if/elseif structure (because wikitext is largely stateless, so "state" is held by branching and copying). {{Nihiltres |talk |edits}} 05:02, 19 May 2021 (UTC)