Template talk:Artwork/Archiv/2019

again problems with collection (P195), location (P276)

please see Portrait of Bernhart von Reesen (Q3937475), File:Albrecht Dürer - Portrait of Bernhard von Reesen - Google Art Project.jpg Oursana (talk) 12:55, 5 October 2018 (UTC)

@Oursana: Looks completely fine to me with both English and German interface, both Staatliche Kunstsammlungen Dresden (Q653002) and Gemäldegalerie Alte Meister (Q4890) are displayed in the "Current location" field of File:Albrecht Dürer - Portrait of Bernhard von Reesen - Google Art Project.jpg as they should. Would probably be useful if you point out what problem specifically you see. LG, --Marsupium (talk) 18:15, 6 October 2018 (UTC)

Thanks for your answer, IMHO Staatliche Kunstsammlungen Dresden (Q653002) shouldn't show up in the institution field, some time ago in similar cases Jarekt could take it away. I hope you agree with me, LGOursana (talk) 19:21, 6 October 2018 (UTC)

Problems with Uffizi, see File:Bonaventura Berlinghieri - Madonna and Child with Saints and Crucifixion - WGA1954.jpg--Oursana (talk) 02:52, 23 October 2018 (UTC)

I think it is just saying that the museum is Uffizi Gallery and the actual location is at the Uffizi Gallery house. Maybe separating Institution from current locations as it is proposed below would made this more clear. --Jarekt (talk) 17:45, 23 October 2018 (UTC)

I split the Collection and Location fields but I am not sure if the data from Wikidata is properly assigned to each field. --Jarekt (talk) 14:25, 16 November 2018 (UTC)--Jarekt (talk) 14:25, 16 November 2018 (UTC)

see File:Giotto di Bondone 034.jpg should be Cappella Scrovegni--Oursana (talk) 16:00, 21 January 2019 (UTC)

I'm not sure what happened on that page. This is the version before your edits and after you were done. Anyway, not a template problem and now cleaned up. Multichill (talk) 21:50, 21 January 2019 (UTC)

formatting problem for (very) long urls coming from Wikidata

Please see this file to see the problem: File:Gerard Dou - The Dropsical Woman - WGA06647.jpg. I think these urls should be collapsed somehow. The Japanese characters make me need to scroll right in order to view the file info with Qid/title. Jane023 (talk) 15:40, 19 January 2019 (UTC)

@Jarekt: Jane mentioned to me that the link http://www.louvre.fr/jp/oeuvre-notices/%E3%80%8A%E7%97%85%E6%B0%97%E3%81%AE%E5%A5%B3%E3%80%8B%E3%80%81%E4%BC%9D%E7%B5%B1%E7%9A%84%E9%80%9A%E7%A7%B0%E3%80%8A%E6%B0%B4%E8%85%AB%E3%81%AE%E5%A5%B3%E3%80%8B on File:Gerard Dou - The Dropsical Woman - WGA06647.jpg messes up the whole layout. It would probably be good to render that as https://www.louvre.fr/jp/oeuvre-notices/《病気の女》、伝統的通称《水腫の女》. Multichill (talk) 15:40, 19 January 2019 (UTC)

Exactly. Jane023 (talk) 16:00, 19 January 2019 (UTC)

I was experimenting with mw.text.decode function that suppose to fix that issue, but it does not seem to help. In other cases like that I usually add "title" qualifier to help format the displayed string, like in d:Q378034, but you are right the software should be able to convert such strings to proper characters. --Jarekt (talk) 05:12, 20 January 2019 (UTC)

Why don't we store the URLs in Wikidata in not encoded form? (I do that usually.) --Marsupium (talk) 14:41, 20 January 2019 (UTC)

@Jarekt: That’s for HTML encoding, like < and  . What you need is mw.uri.decode, although you should take care of special ASCII characters like spaces and brackets, which are also decoded by this function. —Tacsipacsi (talk) 21:25, 20 January 2019 (UTC)

Fixed thanks to Tacsipacsi suggestion. --Jarekt (talk) 03:45, 21 January 2019 (UTC)

@Jarekt: The special characters problem also applies to the unencoded URLs—AFAIK there is no restriction prohibiting these special characters in stored statement values. —Tacsipacsi (talk) 21:12, 21 January 2019 (UTC)

Technique

Wikidata has a fabrication method (P2079) property used for example in Weight for weighing gold dust (Q61752716). I think it would make sense to indlude it in the "medium" field (the parameter used to be called "technique"). -Zolo (talk) 13:28, 18 February 2019 (UTC)

Use of parameter "other_versions"

Calling out to @Perhelion: , @Mattes: , @Vincent Steenberg: , @Oursana: , @Urbandweller: , @Villy Fink Isaksen: .

Sorry to disturb you guys, but given the fact that you use the Artwork parameter "other versions", this may be of concern to you.

Recently one of my edits with "other versions" was deleted by another user with the explanation that "other versions" should be seen as other versions of the same photo, i.e. not another photo of the same artwork. I see the parameter as a tool for those of us interested in art history, to connect to other photos, but also to sketches and drawings leading to that particular artwork, to later interpretations by the same artist and to graphics derived from the artwork - which is a much broader view, and also a very useful and informative one.

The user was adamant that his way of seeing things was the only one - you can read the discussion here: https://commons.wikimedia.org/wiki/User_talk:Parsecboy#File:Carl_Neumann_-_Action_off_Jasmund_-_1864.png.

The user gave the kind advice to "ask on the template talk page", so therefore this call.

If you agree, please support the statement that Other versions include other photos or scans of of the same artwork as well as sketches and drawings leading to that particular artwork, to later interpretations by the same artist and to graphics derived from the artwork.

Your help is appreciated (and your friends') - or you might risk having your own "other versions" removed by some zealous user.

Cheers --Rsteen (talk) 18:28, 20 July 2019 (UTC)

@Rsteen: you don't need a straw poll to confirm that Parsecboy was wrong here. That other_versions field always had broad usage. That's why the documentation describes the field as "Links to files with very similar content or derivative files". It's actually quite common to put a version with frame or a related drawing in the other versions. See for example File:Vincent van Gogh - The Bedroom - Google Art Project.jpg. I restored your edit. Multichill (talk) 20:45, 22 July 2019 (UTC)

Can you explain the reasoning here? I can only fathom two possibilities: you are either asserting that two different pieces of artwork, by different artists, and in different mediums, are "different versions" of the same image (a patently absurd argument if I ever heard one) or the field "other versions" actually means "similar or related images", in which case the field needs to be renamed, because no one with a passable understanding of English would interpret "other versions" that way (and that's what categories are for). Parsecboy (talk) 21:22, 22 July 2019 (UTC)

 Comment I have used this parameter in both ways, I don't see why we need to define anything. Regards, Yann (talk) 04:00, 23 July 2019 (UTC)

 Comment I agree with Yann and Multichill. Parameter Other versions is the same in all the infoboxes, and we were using it for over 15 years, and just because someone is reverting your edits @Rsteen: , we do not have to rethink how we use this parameter. See documentation of {{Information}} or {{Artwork}} for how to use it. --Jarekt (talk) 02:27, 24 July 2019 (UTC)

Can you explain how two different works in two different mediums by two different artists are different versions of the same image? Yes, the painting and woodcut are surely based on the same sketch by the Danish naval officer who was present, but that only means that these two images are derivatives of that work, not of each other. Parsecboy (talk) 09:15, 25 July 2019 (UTC)

it is also used for pendants. In art historical literature for centuries is always talk about different versions by the same or different artists without any master version. Obviously the wiki commons majority gets it right. “other versions” doesn't state "same image", but same subject; rkd uses “Physical connection". I do not see a need of willful misunderstanding--Oursana (talk) 14:44, 25 July 2019 (UTC)

I also see no need for an increased restriction, if the field is not overused. The requirements are not strict (linear). Granted I use the field more than less. If the image has no very specific category and no more comparable versions exists, the conditions can seen relaxed anyway. -- User: Perhelion 09:56, 28 July 2019 (UTC)

Support:

1. --Rsteen (talk) 18:28, 20 July 2019 (UTC)
2. --Villy Fink Isaksen (talk) 19:09, 20 July 2019 (UTC)
3. --Pixel8tor (talk) 19:36, 22 July 2019 (UTC)
4. --Oursana (talk) 14:44, 25 July 2019 (UTC)
5. --Urbandweller (talk) 01:16, 3 August 2019 (UTC)

Title missing?

@Jarekt: We're playing around a bit with File:0029 Frederick Coburn 1896.jpg. In this edit I removed most fields that are redundant with Wikidata. I noticed the title is no longer showing but the data is available at d:Q62113917#P1476. Can you have a look why it's not showing? Multichill (talk) 17:32, 19 November 2019 (UTC)

Multichill, The current algorithm (lines 744-76) does the following: for properties title (P1476), official name (P1448), and native label (P1705) I search for strings in user's language (or language on my fallback path (including English) and stop once I find one. The titles either are in single native language or have multiple translations. I guess if there is a single title than I should just take it. Ideally I should use {{Title}} (or Lua equivalent) as it is used at here. perhaps If I can find a title (P1476), official name (P1448), or native label (P1705) with a single value than I take it as the main title and provide translations from labels and if I find multi value properties than I would use {{LangSwitch}} approach as I do now. Trick would be what to do with whole bunch of titles in all sorts of languages but English in title (P1476). Not sure what would be the best approach then. --Jarekt (talk) 03:04, 20 November 2019 (UTC)

I think the best approach will be to create Module:Title and rewrite {{Title}} to use it and than add support for access to wikidata through wikidata parameter, or from digital representation of (P6243). I will start working on that. --Jarekt (talk) 14:37, 22 November 2019 (UTC)

Option to suppress title line at the top

We should have an option to suppress the title line at the top. The information which is added there automatically from parameter values within the tmemplate (or from Wikidata) is not always appropriate. Plus it is redundant and not necessary, since the information is also available elsewhere in the template. --Robert.Allen (talk) 19:12, 21 December 2019 (UTC)

That is the place where we have a place for Wikidata, wikisource, etc icons and brief version of author and title, as oppose to longer {{Creator}} template and {{Title}} template used. I and probably many others, rely of that information for quick look at the most relevant info. Adding such option would require to store the same info (like wikidata icon) in other places and will just create reason for edit wars between editors who prefer alternative looks. --Jarekt (talk) 21:09, 22 December 2019 (UTC)

Okay, thanks for the reply. I will see if I can work around it somehow for the few instances where there is a problem. --Robert.Allen (talk) 21:25, 22 December 2019 (UTC)

If there is a problem and top line does not look right, drop me a note and I will try to fix the code. --Jarekt (talk) 22:03, 22 December 2019 (UTC)

Jarekt, an example that does not look right: File:Gauguin 1887 Prairie martiniquaise.jpg. It concatenates the title in original language and the title in user language without any separation. --V.Riullop (talk) 09:10, 23 December 2019 (UTC)

V.Riullop, That one (and similar ones) should be fixed. --Jarekt (talk) 14:42, 23 December 2019 (UTC)