Module talk:Artwork/Archive

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

Suppress creator role=photographer (Q33231) in "photographer" field?

[edit]

Probably not high priority, but would be nice to suppress Module:Wikidata art's function p.get_creator()'s creator role=photographer (Q33231) in "photographer" field, example: File:Lunch atop a Skyscraper.jpg. Best, --Marsupium (talk) 10:32, 13 January 2022 (UTC)[reply]

Marsupium, ✓ Done Stripping:
--Jarekt (talk) 04:12, 22 January 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:15, 4 February 2022 (UTC)

coordinates of depicted place from Wikidata

[edit]

We need to update the module so that coordinates of depicted place (P9149) on the Wikidata item also triggers {{Object location}}. Example file File:Raising the Flag on Iwo Jima, larger.jpeg. Multichill (talk) 16:04, 16 January 2022 (UTC)[reply]

✓ Done --Jarekt (talk) 04:43, 22 January 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:16, 4 February 2022 (UTC)

line 1485: attempt to get length of field '?' (a nil value)

[edit]

File:Bundesarchiv Bild 146II-849, Rudolf Heß.jpg shows this error instead of summary. It looks like recent Jarekt changes introduced a problem. --Derbeth talk 08:10, 22 January 2022 (UTC)[reply]

Yes, and not only with that photo, also with a lot of more. I think because a problem was added with the latest changes. 81.40.135.122 11:06, 22 January 2022 (UTC)[reply]
Author parsing seems to have caused some problems. I removed that part. Test cases:
Null edit will flush out the error now.
@Jarekt: code is still active at Module:Artwork/sandbox. I might have a look at it this weekend. Multichill (talk) 11:36, 22 January 2022 (UTC)[reply]
Sorry about that and thanks for the revert. I fixed the issue. I will touch all the files in Category:Pages with script errors to flush all the error files. I probably should look through other files in that category, so it is easier to spot new issues. --Jarekt (talk) 02:08, 23 January 2022 (UTC)[reply]
@Jarekt: cleaning it out is nice yes. Otherwise I wouldn't have spotted the LUA error on File:Jean Siméon Chardin, Soap Bubbles, probably 1733-1734, NGA 994.jpg caused by empty Soap Bubbles (Q20177882) and this module trying to loop over a string. Multichill (talk) 10:44, 23 January 2022 (UTC)[reply]
@Multichill: That was actually bug in older code and I was planning to fix it with this solution. --Jarekt (talk) 03:41, 24 January 2022 (UTC)[reply]
I just patched it up to prevent it from going down in flames, feel free to improve on it. Wouldn't that give a table in a table? Multichill (talk) 17:51, 24 January 2022 (UTC)[reply]
Yes, I will revisit it. I was doing a bit of a deep dive into the code (I should have been writing more comments and documentation) and from what I can figure out object_type_id is always array of item IDs (output of getBestProperties function for wikidata based values). ObjectTypeID function converts object_type template field into an item ID but since it is always a single one, it was saved as a string. After the merge of template inputs with wikidata data the object_type_id's type is unpredictable. So a solution would be to keep it always as an array (aka dictionary in lua). --Jarekt (talk) 01:16, 25 January 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:16, 4 February 2022 (UTC)

ref RKD

[edit]

shows twice File:Claesz.,_Pieter_-_Still_Life_with_Musical_Instruments_-_1623.jpg--Oursana (talk) 19:51, 26 January 2022 (UTC)[reply]

@Oursana: It’s not the module’s fault, it was stored in Wikidata twice. I’ve removed one of them. —Tacsipacsi (talk) 18:11, 30 January 2022 (UTC)[reply]
Sorry and thanks

✓ Done--Oursana (talk) 18:16, 30 January 2022 (UTC)[reply]

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:17, 4 February 2022 (UTC)

HTML tables inside

[edit]
CodeRendering 
{{Artwork/sandbox Lua|permission = {| class="wikitable"
|-
! Header text !! Header text !! Header text
|-
| Example || Example || Example
|} }}

Template:Artwork/sandbox Lua 

{{Artwork/sandbox Lua|permission =  {{PD-art}} }}

Template:Artwork/sandbox Lua

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:47, 4 February 2022 (UTC)

Spin into Module:Infobox

[edit]

Maybe we should create Module:Infobox and spin much of this code there, so we can reuse it for other infoboxes. --Jarekt (talk) 02:28, 30 April 2016 (UTC)[reply]

Sounds reasonable, but perhaps we can wait until this page is fully functional, as it is easier to test when everything is on the same page (fpr instance through "Preview page with this template").
@Jarekt: I have created Module:Infobox/sandbox, so that Template:Artwork/sandbox Lua calls it, using parameters stored in Module:Artwork. It is the way things work in frwiki, and that works all right. It can stil be rather complex when the layout is unusual, and even more so when Wikidata data needs extensive reprocessing. Not sur there is much we can do about it though. -Zolo (talk) 14:36, 2 September 2016 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:49, 4 February 2022 (UTC)

Issue with wikitables

[edit]

@Jarekt and Multichill: As can be seen above there is an issue with the passing of arguments that contain Wikitables. It seems that they are not expanded before being passed as arguments to the module. The table's internal "|" are thus misinterpreted as marking a new template's parameter. Any idea what to do with that ?--Zolo (talk) 13:20, 2 May 2016 (UTC)[reply]

Zolo, 

{{Artwork|permission = {{(!}} class="wikitable"
{{!-}}
! Header text !! Header text !! Header text
{{!-}}
{{!}} Example {{!!}} Example {{!!}} Example
{{!)}} }}

gives

Permission
(Reusing this file)
Header text Header text Header text
Example Example Example

Is this what you are looking for? --Jarekt (talk) 17:22, 2 May 2016 (UTC)[reply]

I am looking for this output but even when the output is a wikitable usng "|". We should be able to use the module with current license templates without breaking anything. Zolo (talk) 19:49, 2 May 2016 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:49, 4 February 2022 (UTC)

Module Name

[edit]

Short note: I'd prefer to name the existing or at least future templates, modules etc. "object" rather than "artwork". Cheers, --Marsupium (talk) 11:33, 2 September 2016 (UTC)[reply]

I think that we should have the same name for the template and the module. The name "Artwork" after some discussion when the template was created, though I would still tend to mildly favor "object" as well. --Zolo (talk) 14:41, 2 September 2016 (UTC)[reply]
Ah, yes, it is definitely more important to have the same name for both! And sorry, I didn't know about the discussion. --Marsupium (talk) 11:35, 3 September 2016 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:51, 4 February 2022 (UTC)

Catalogue raisonné

[edit]

What about catalog code (P528) and Category:Multilingual tags: Catalogues raisonnés? It seems to me as a clear case of data that should be taken from WD, although unfortunately there is no strandartisation in these templates.--Jklamo (talk) 08:40, 7 June 2018 (UTC)[reply]

 Support Jklamo Where should it go? References? --Jarekt (talk) 15:16, 7 June 2018 (UTC)[reply]
Not sure. Sometimes it is in References, sometimes in Notes. I have no strong opinion.--Jklamo (talk) 16:12, 7 June 2018 (UTC)[reply]
"References" is the best place in my eyes. described at URL (P973) and described by source (P1343) should be displayed there as well! :-) --Marsupium (talk) 07:32, 13 June 2018 (UTC)[reply]
✓ Done see Module_talk:Wikidata_art/sandbox/testcases#Reference
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:52, 4 February 2022 (UTC)

Inscription

[edit]

What about inscription (P1684)? Again it seems to me as a good case that should be taken from WD.--Jklamo (talk) 08:00, 14 July 2018 (UTC)[reply]

Inscription is already pulled from Wikidata. --Jarekt (talk) 19:12, 14 July 2018 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:53, 4 February 2022 (UTC)

New version with object and period upstream

[edit]

@Jarekt: I've saved a new version to the sandbox.

I've tested all changes. (Unfortunately, "continue only if the namespace is a Category or file" in function add_wikidata_maintenance_categories() makes that a bit inconvenient. I'll think about easing unit tests for that.)
I'm especially curious to see what will happen to Category:Artworks with Wikidata item: quick statements. So, I'll be happy if you can review the changes and let me know if something should be changed and merge them if not! Thanks a lot in advance! --Marsupium (talk) 13:08, 1 November 2018 (UTC)[reply]

PS: What do you think about renaming era variables to period following the Wikidata property label and {{Period}} and distinguishing them more from the meaning of era in {{Era}} and the date modules and templates? --Marsupium (talk) 13:33, 1 November 2018 (UTC)[reply]
Marsupium, finally have time to look at this more closely, but sorry for the delay. Your proposed changes, looked good and I released them with bunch of changes I had. Now Category:Artworks with Wikidata item: quick statements is filling up, mostly with files from Category:Media contributed by the Walters Art Museum. Thanks. --Jarekt (talk) 13:57, 16 November 2018 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:53, 4 February 2022 (UTC)

Edit request: Please fix heading level back from "==" to "===" for Template:Art Photo

[edit]

{{Edit request}} When migrating functionality from Template:Art Photo to this module. The level for the two headings has probably accidentally been changed from 3 to 2. Unintended result can be seen e.g. at File:Kaiserswerther Diakonie Denkmal Kronprinz IMG 0750.JPG. Please fix this by replacing the four appearances in function p.art_photo() of "==" with "===". Thanks in advance! --Marsupium (talk) 14:18, 30 November 2018 (UTC)[reply]

Marsupium ✓ Done. Thanks for spotting this. --Jarekt (talk) 15:49, 4 December 2018 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:55, 4 February 2022 (UTC)

coordiates -> coordinates

[edit]

Jarekt, should it be renamed? --Arnd (talk) 11:16, 4 April 2019 (UTC)[reply]

Ah, that is what is wrong. Thank you. --Jarekt (talk) 01:53, 5 April 2019 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:55, 4 February 2022 (UTC)

Font size of original_description_info

[edit]

The Bundesarchiv has sent me a request to change the font size of the field "original_description_info" from 86% to 100%. I.e. on image File:Bundesarchiv Bild 183-R98345, Berlin, Prof. Erich Kaufmann spricht.jpg the text "For documentary purposes the German Federal Archive often retained the original image captions, which may be erroneous, biased, obsolete or politically extreme" should be shown in 100 % to make the information about the field more prominent.

On line 161 I see font-size:86%%;. Is it safe to change it to 100% or does it have effect on other templates too? If yes, how can we achieve the request of the Bundesarchiv for {{BArch-image}} only? Raymond 08:38, 14 April 2019 (UTC)[reply]

Good to hear you're (still or again) in contact with the Bundesarchiv. Any plans to release more or higher resolution? The Dutch goverment has a strategy of more openness so CC0 and high resolution is slowly becoming the norm.
Looks like you only need to change {{BArch-image}} Raymond. That template shouldn't be used on other templates so I don't expect any problems. You should try it in {{BArch-image/Sandbox}}. That's always good practice for high usage templates. Multichill (talk) 13:15, 14 April 2019 (UTC)[reply]
@Multichill: How to change {{BArch-image}}? A 86% font size specification should be removed, but there’s no such rule in {{BArch-image}}, it’s in this module. I think the cleanest and most future-proof way to go is to move this style to a TemplateStyles style page (e.g. Template:Artwork/styles.css or Module:Artwork/styles.css), and create a TemplateStyles page for {{BArch-image}} (e.g. Template:BArch-image/styles.css), which overrides this rule for that specific template. This is not a very difficult or error-prone task, however it needs an amount of testing simply because of the high usage of this module. —Tacsipacsi (talk) 23:22, 14 April 2019 (UTC)[reply]
It has been a while since I worked on {{BArch-image}} we seem to have 4 types of descriptions/titles, each implemented differently:
  • short title -> Bundesarchiv's title displayed in {{Photograph}}'s |title=
  • archive title -> Bundesarchiv's description displayed in {{Photograph}}'s |other_fields_1= with {{Information field}} titled "Archive description"
  • original title -> Historical description displayed in {{Photograph}}'s |original description=
  • wiki description -> {{Photograph}}'s |description=
You can see how those fields are used below
short title
Photographer
Unknown author or not provided
Archive description
InfoField
Description provided by the archive when the original description is incomplete or wrong. You can help by reporting errors and typos at Commons:Bundesarchiv/Error reports.
archive title
Title
short title
Original caption
For documentary purposes the German Federal Archive often retained the original image captions, which may be erroneous, biased, obsolete or politically extreme.
original title
Description
Information added by Wikimedia users.
wiki description
institution QS:P195,Q685753
Accession number
[1]
Source
It is hard to easily grasp the difference between different descriptions, so each message had a small information bar above descriptions, which was at 86% font size so people do not confuse it with the actual description text. Also since original titles or captions were quite common with archival photographs we made |original description= a permanent part of {{Photograph}} template, used by other files. I think changing it to 100% makes it look like the actual description text and decreased readability of already confusing infobox. I consider Bundesarchiv a very valuable partner and would like to keep them happy if possible, but I am feel like in this case they are deceasing readability of their own descriptions. However, if consensus is to grant their wish, then the technical solution I would suggest would be to stop using {{Photograph}}'s |original description= field and add another {{Information field}} template to |other_fields_1= with original title. --Jarekt (talk) 13:07, 15 April 2019 (UTC)[reply]
I would share this response with them and hope they agree. Multichill (talk) 15:50, 15 April 2019 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:57, 4 February 2022 (UTC)

Ugly 1st century date

[edit]

{{Artwork |wikidata=Q1779135}} renders as:

Obelisk of Titus Sextius Africanus  wikidata:Q1779135 reasonator:Q1779135
Title
Obelisk of Titus Sextius Africanus
label QS:Lde,"Obelisk des Titus Sextius Africanus"
label QS:Len,"Obelisk of Titus Sextius Africanus"
label QS:Lfr,"obélisque de Munich"
label QS:Lit,"Obelisco di Monaco"
image of artwork listed in title parameter on this page
Object type obelisk Edit this at Wikidata
Date circa 50 AD
date QS:P,+0050-00-00T00:00:00Z/9,P1480,Q5727902
 Edit this at Wikidata
Medium rose granite Edit this at Wikidata
Dimensions height: 5.6 m (18.3 ft) Edit this at Wikidata
dimensions QS:P2048,+5.6U11573
institution QS:P195,Q464872
Accession number
Gl. WAF 39 (State Museum of Egyptian Art) Edit this at Wikidata
Other versions
  • image 
    image Edit this at Wikidata
  • image 
    image Edit this at Wikidata

with the date currently being "circa 0050". The leading zeros aren't nice, I don't know where they're from. Does anybody feel like investigating? Cheers, --Marsupium (talk) 12:23, 15 April 2019 (UTC)[reply]

Marsupium, Those come from Module:DateI18n where there is parameter |trim_year= with default '100-999', meaning that for dates in 100-999 we will strip the leading zeros, but we will keep them for one and two digit years. The issue is that year "0050" is ugly but understandable, while year "19" could be misunderstood as 2019, especially in unlikely case when we have higher precision So "April 15, 19" is likely to be understood as today's date and not a days 2k years ago, and "circa 50" could be misunderstood for "circa 1950". We were switching for a while between trimmed and untrimmed formatting, before settling on this compromise, which affects relatively small number of files. --Jarekt (talk) 13:26, 15 April 2019 (UTC)[reply]
@Jarekt: What about “circa 50 AD”? I think this makes it obvious, I have never heard this format referring to the 20th-21st century; while it’s far less ugly than the zero-padded version. (Actually this is the way I almost always say first-century dates, as it disambiguates in two ways simultaneously: it not only says it’s not a modern date, but also explicitly declares it’s not BC.) —Tacsipacsi (talk) 13:14, 19 April 2019 (UTC)[reply]
Tacsipacsi, That would be the best solution and the one I will try to implement for dates coming from Wikidata. As for dates coming from Commons I would urge to change dates like "50" to {{other date|AD|50}}. --Jarekt (talk) 13:20, 19 April 2019 (UTC)[reply]
✓ Done @Marsupium: --Jarekt (talk) 03:59, 23 April 2019 (UTC)[reply]
Hey, sorry for not replying before: I thought it wasn't on purpose. I don't know, personally I think I'd interpret a "April 15, 19" without context as 0019-04-15 (CE), not 2019-04-15 and assume "April 15, 0019" to be a bug, but maybe it's me or it's less clear in languages other than German. I'm sorry this ended up in a heated discussion and caused work now. The new solution looks better, I don't mind too much about how it looks though tbh, just thought the "00" weren't intended. Thanks for your effort to improve it in whatever direction! Cheers, --Marsupium (talk) 16:40, 23 April 2019 (UTC)[reply]
So what? If it is from 50 CE, then “circa  0050” is nice. Don’t fix a working system. Incnis Mrsi (talk) 13:28, 19 April 2019 (UTC)[reply]
No, it is absolutely not. It is even worse than what the infobox does currently—your example not only writes it with leading zeros, what no human would do, it also makes the assumption “circa” is a prefix in all languages. It is not, not even in European languages. For example, Hungarian would say “50 körül”, never “körül 0050”, what the current output is. —Tacsipacsi (talk) 16:12, 22 April 2019 (UTC)[reply]
Tacsipacsi, I am not sure where you got “körül 0050” as "current output". {{Other date|ca|50|lang=hu}} gives "50 körül". --Jarekt (talk) 03:59, 23 April 2019 (UTC)[reply]
In the above comment, nowhere else. This is why I said it to be even worse than the infobox output was then (which was “0050 körül”, grammatically correct). —Tacsipacsi (talk) 11:23, 23 April 2019 (UTC)[reply]
Tacsipacsi I was just looking over this discussion and I am not sure about the final outcome. Is there still an issue here I should look at? --Jarekt (talk) 01:39, 13 May 2019 (UTC)[reply]
@Jarekt: I’m absolutely satisfied with the current output above. —Tacsipacsi (talk) 21:43, 14 May 2019 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:58, 4 February 2022 (UTC)

Date format

[edit]

Apparently using ISO format dates in |date= for {{Photograph}} is not automatically formatting them. If that could be checked on, I'd appreciate it! — Huntster (t @ c) 02:29, 25 May 2019 (UTC)[reply]

@Huntster: For me {{photograph |date=2019-06-07}} works giving:
Date 7 June 2019
Do you have an example where it doesn't work? --Marsupium (talk) 00:11, 7 June 2019 (UTC)[reply]
Marsupium, apparently the problem...fixed itself? No idea. What prompted this is because this edit was made specifically to fix the error at the time. Interesting. — Huntster (t @ c) 02:11, 7 June 2019 (UTC)[reply]
Hm, maybe. At least it seems to be solved then! --Marsupium (talk) 02:17, 7 June 2019 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:00, 4 February 2022 (UTC)

New fields

[edit]

Hi, Would it possible to add the fields

  • Title: P1476
  • Depicts: P180

Thanks, Yann (talk) 17:10, 29 May 2019 (UTC)[reply]

Artwork already uses title (P1476) and "depicted_people" based on depicts (P180) with instance of (P31) == human (Q5). --Jarekt (talk) 15:05, 10 June 2019 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:00, 4 February 2022 (UTC)

Support for "source" from SDC

[edit]

@Multichill: , you proposed at some point to add support for populating {{Artwork}} source field by values pulled from source of file (P7482), with examples:

That is ✓ Done now. I am still working on better title support. --Jarekt (talk) 04:32, 10 December 2019 (UTC)[reply]

@Jarekt: thanks, that looks really good! Multichill (talk) 18:21, 12 December 2019 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:07, 4 February 2022 (UTC)

Load labels of depicts (P180) by default?

[edit]

If the template loads the values of P180 statements from SDC, this might generate usage tracking on Wikidata? Jura1 (talk) 09:05, 13 December 2019 (UTC)[reply]

{{Artwork}} does look through depicts (P180) statements, looking for depicted people. Unfortunately since in order to find depicted people I need to load the whole entity this is expensive operation and we do have an upper limit how many depicts (P180) statements will be analyzed to prevent Lua errors. I am not sure how "usage tracking on Wikidata" would be helpful. I trust there is a use for it but not sure what yet ;) --Jarekt (talk) 15:04, 13 December 2019 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:08, 4 February 2022 (UTC)

Permission field label

[edit]

When using Template:Art Photo, label of the "artwork license" field is "Permission (Reusing this file)". Should't the "(Reusing this file)" only for "photo license" field? --Fukumoto (talk) 09:53, 30 March 2020 (UTC)[reply]

Template:Art Photo template allows you to clarify which license goes with which part of the work. Most of the time we have photographs of PD artwork, so "photo license" field is more restrictive. However sometimes it is the other way around, where we have CC-zero photographs of CC-BY artworks. So you need to consider both fields when determining reuse constraints. --Jarekt (talk) 12:22, 30 March 2020 (UTC)[reply]
Thank you for the answer. Alhough, I feel it's not very obvious. --Fukumoto (talk) 16:49, 30 March 2020 (UTC)[reply]

While we're at it, another question: permission parameter description in Template:Artwork/doc says the default is "blank field presented as: "See below."". But I don't see "See below." when the permission is empty. When will "See below." be presented? --Fukumoto (talk) 16:49, 30 March 2020 (UTC)[reply]

I do not know anything about "See below", and there is no time that code will show that message, so I updated the documentation. --Jarekt (talk) 19:12, 30 March 2020 (UTC)[reply]
Thank you! --Fukumoto (talk)
Template:Photograph/doc has same line. --Fukumoto (talk) 10:26, 31 March 2020 (UTC)[reply]
Fixed --Jarekt (talk) 12:03, 31 March 2020 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:09, 4 February 2022 (UTC)

Extending Module:Artwork to maps

[edit]

Hi @Jarekt: I wondered if you had thoughts on how best one might extend Module:Artwork to cover maps, to be able to replicate as closely as possible Template:Map ?

My situation is I am under pressure to get underway with a wikidata/commons upload of about 30,000 old maps and engravings. I know that to start with, in the time available, I am not going to be able to do initially any more than only very limited wikidata matching for relevant connected people and places, but with quite a lot (I expect) of subsequent refinement to follow. So I am really motivated to try to get to a more dynamic possibility for the maps information pages, so that they could automatically draw to a much greater extent from wikidata; and would automatically update themselves as wikidata values improve, rather than needing endless bot runs to try to keep the two in sync.

Looking at Template:Map, as manifested for example in information pages for maps like the stand-alone L'AMERIQUE MERIDIONALE (Guillaume de L'Isle, 1730) (Q56759865) (Commons file) or, from a wider atlas, Scotia Regnvm (Joan Blaeu, 1667) BL 114.h*.6 (3) (Q63873115) (Commons file) (see also this page for the fields being used - still work in progress), there are a couple of things that I can see that arise:

  • The fields in the map template are grouped, and presented in a different order to the Artwork fields. One way I thought to address this might be to run the data through the create_infobox method multiple times, with a different subset of fields each time, as is done eg for the art_photo entrypoint. However, even within a group the order doesn't quite match up -- for example, the Map template prefers to present the title and description first, before creators and other contributors; also, for example, it places credit line immediately after source.
  • The template would need to be able to draw in and sensibly display as-yet unmatched string values on Wikidata, typically represented as somevalue object named as (P1932) <value>
  • The object has role (P3831) qualifier would be used quite often, particularly for creators and contributors to identify their specific role -- eg cartographer, surveyor, engraver, etc. I am not sure the module can generally represent these at the moment.

Other things that would be nice

  • It would be nice to be able to suppress all of the "blue pencil" edit links. The GLAM in question has just spent 10 years in-depth recataloguing these images, so I would prefer not to give too much prominent encouragement to casual editing that would depart from the cataloguing. I would prefer just the single link at the top to link to editing the data on wikidata, not an edit link on each field. Perhaps a module option giving a kill-switch for these links would be possible?
  • Wherever possible, I think it would be nicer if wikilinks went primarily to Commons categories for eg people and places (as done for example on the two file-pages above), rather than wikipedia entries or wikidata items. I think this would do a little to encourage random browsers to stay within Commons and explore more than they do, which I think would be a good thing. Also it would encourage people to find the categories with other depictions or maps we have of the place or by the person, which otherwise they would be more likely to miss. Now that we have such good infoboxes on Commons categories, I think they are a good place to send people to.

I am prepared to try to do the hacking to make this work. But do you think it all ought to be reasonably straightforward? And/or are there particular bits of advice or thoughts you have, with any of the above? -- Jheald (talk) 15:40, 26 August 2020 (UTC)[reply]

@Jheald: , yes we were thinking about rewriting {{Map}} template using Lua to have similar capabilities as Artwork template. You can see phabricator:T252259 where some of those discussions happen it was spearheaded by User:Librarian lena and User:Susannaanas. We even started Module:Map which would share a lot of code with Module:Artwork. I could not contribute as much as I would like to as I have only limited time and between maintaining a portfolio of ~30 modules, trying to work on SDC data modeling and doing administrative work, I was not able to push it much further. Although it might be nice to complete some minimal functionality template which can be latter improved and expanded. About some of your "things that would be nice" list:
  • about "blue pencil" edit links, I see them as a hint of where the data is stored, as we do not want things to happen through some mysterious process. In the past, if you see something in the template you can click on edit and you can see the data with SDC and Wikidata, the actual location of the data could be a mistery to those not accustomed with it. those blue pencils are meand to demystify it for new users and serve as hint for advanced users if the data is stored locally or externally. Suppressing those links would create expectation that the data is stored locally and be a suprise if you on edit and not see it there. Also as a user I do not like when others customize infoboxes they create so some of the standard features I rely on are not working.
  • Also as a frequent user navigating the Commons interface When I click on a link for a person or a place, it is because I want to learn more about it. The best source of information to learn for me is in Wikipedia articles not Commons categories and in 99% of cases not Commons galleries. Most of the time, sending people to other page on Commons just creates need for them to find an interwiki link and click it and hope that it will connect to an article page and not wikipedia category. That is why in 2008 Template:Paris and other similar templates were created. Changing that behavior after 12 years would be hard.
--Jarekt (talk) 02:01, 27 August 2020 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:12, 4 February 2022 (UTC)

Could this template be made compatible with multi-language works?

[edit]

{{Edit request}} @Jarekt: (pinging you because you've made most of the recent edits and because you closed phabricator:T89600) Hello—if you look at File:Swahili tales.djvu, which corresponds to d:Q99526042, in Wikidata its property d:Property:P407 has two values, both with rank "Normal", so that the parser function call {{#property:P407|from=Q99526042}} produces "English, Swahili" (← should be "English, Swahili"); but the call to {{Book}} currently just gives

LanguageEnglish

As far as I can tell this is because P407 is handled as a single-value property in the Lua loop under the comment harvest Q-code properties which are than converted from Q-number to labels when it should be handled on its own like d:Property:P31 in the loop under the comment get object_type, which successfully displays multiple values as

Object typereference work / сollection of fairy tales

Could this module be updated so that it shows multiple language values too? Cheers, ▸∮truthious ᛔandersnatch◂ 10:49, 22 September 2020 (UTC)[reply]

✓ Done Thank you! Jarekt (talk) 20:25, 9 October 2020 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:13, 4 February 2022 (UTC)

Is there a table detailing the mapping from Wikidata properties to the "Artwork" template fields ?

[edit]

Hello !

I prepare an upload of images from the BIU Santé collections depicting different places and buildings linked to health care systems.

Part of the metadata will be stored in Wikidata and part will be upoaded directly in Commons.

In order to help me defining how to split these metadata between Wikidata and Commons, could you tell me if there's a way to obtain a table detailing the mapping from Wikidata properties to the "Artwork" template fields ?

Thanks for your answer,

BIU Santé - Olivier Ghuzel (talk) 16:33, 6 November 2020 (UTC)[reply]

Hello BIU Santé - Olivier Ghuzel, the "Default" column at Template:Artwork#Template parameters tells which values are fetched from Wikidata. There is some help on modelling the data at Wikidata at d:Wikidata:WikiProject Visual arts/Item structure. I hope that helps! If you have specific questions not addressed at those places maybe we can improve the documentation. All the best, --Marsupium (talk) 11:38, 25 November 2020 (UTC)[reply]
@BIU Santé - Olivier Ghuzel: , in many cases a single field in Artwork might draw information from several Wikidata properties, and each of them might have several dozen supported qualifier combinations. If you provide me a list of matadata you have available I can help you figure out how to map it. --Jarekt (talk) 19:18, 25 November 2020 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:14, 4 February 2022 (UTC)

Widespread (?) Lua errors

[edit]

I'm seeing a lot of new Lua errors coming from this module. One example: File:File-Mountain Lion kitten crossing road west of Seven Mile Bridge;-Jim Peaco;-February 16, 2004;-Catalog 18072d;-Original B66G3798 (c647cabf-c426-4ee9-81e8-763109c63042).jpg. Pinging @Jarekt: as last change. – BMacZero (🗩) 02:46, 11 January 2021 (UTC)[reply]

@BMacZero: I think I fix the issue, and I am monitoring Category:Pages with script errors. --Jarekt (talk) 02:48, 11 January 2021 (UTC)[reply]
@Jarekt: Thanks, that does appear to fix the ones I was looking at. – BMacZero (🗩) 02:50, 11 January 2021 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:30, 4 February 2022 (UTC)

Wrong left align for 2 creator boxes

[edit]

See the creator table cell created for Second Copy of the Madonna on the Aa (Q106685883):

Heinrich Lienenkamp  (fl. 1965) wikidata:Q106689158
 
Description sculptor
Work period 1965 Edit this at Wikidata
Authority file
After Johann Wilhelm Gröninger  (–1724) wikidata:Q1696572
 
Alternative names
Johann Wilhelm Grunninger; Johann Wilhelm Gruninger; Johann Wilhelm Gruniger
Description sculptor
Date of birth/death between 1675 and 1677
date QS:P,+1675-00-00T00:00:00Z/8,P1319,+1675-00-00T00:00:00Z/9,P1326,+1677-00-00T00:00:00Z/9
 Edit this at Wikidata		 between 12 July 1724 and 9 December 1724
date QS:P,+1724-00-00T00:00:00Z/9,P1319,+1724-07-12T00:00:00Z/11,P1326,+1724-12-09T00:00:00Z/11
 Edit this at Wikidata
Location of birth/death Münster Billerbeck
Authority file
 Edit this at Wikidata

Thanks for any help with fixing this! --Marsupium (talk) 12:46, 3 May 2021 (UTC)[reply]

Fixed with this edit. --Marsupium (talk) 09:33, 12 May 2021 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:14, 4 February 2022 (UTC)

Anonymous change

[edit]

{{Edit request}} Multichill just closed d:Wikidata:Requests for comment/Cleaning up the ontology of anonymous and updated the visual arts item structure (painting specific version). Can an admin please update the module here for this change? ᴀlbanɢeller (talk) 18:00, 31 May 2021 (UTC)[reply]

Pinging @Jarekt: per User talk:Jarekt#Anonymous change. ᴀlbanɢeller (talk) 18:04, 31 May 2021 (UTC)[reply]
I'm sure Jarek will update the template when he has time for it. {{Edit request}} should only be used when it's clear what needs to be changed. For example when you updated Module:Artwork/sandbox and you just need an admin to deploy it here. Multichill (talk) 18:21, 31 May 2021 (UTC)[reply]
ᴀlbanɢeller, Can you give an example of a page where current code is not working right and describe what it should be changed to? --Jarekt (talk) 19:49, 1 June 2021 (UTC)[reply]
@Jarekt: see Duke of Devonshire (after Hudson). It should display Creator:Thomas Hudson with |after automatically, but instead displays {{Unknown author}}. ᴀlbanɢeller (talk) 19:57, 1 June 2021 (UTC)[reply]
@Neveselbert (mobile) and Multichill: , Thank you. Your example was very useful. I added it to my unit tests. If there are more new patterns I should handle please check them, by adding to unittests. --Jarekt (talk) 11:59, 2 June 2021 (UTC)[reply]
Moved here from User talk:Jarekt
Multichill, For many years now author = anonymous (Q4233718) is rendered as {{label|Q4233718}} and author="unknown value" as {{Unknown|author}}. To me both of those renderings seem equivalent, and I rather keep it as is, but if you think I should change something that would be easy. --Jarekt (talk) 19:34, 1 June 2021 (UTC)[reply]
I think the best logic would be for creator (P170):
Multichill (talk) 17:16, 3 June 2021 (UTC)[reply]
Should be ✓ Done now.--Jarekt (talk) 02:06, 4 June 2021 (UTC)[reply]
@Jarekt: thanks! That looks good at File:Anonymous - St Jerome in the Wilderness - NM 22 - Nationalmuseum.jpg and File:Anonymous - Portrait of Laura Dianti (dead 1573) and a Young Page - NM 202 - Nationalmuseum.jpg. Multichill (talk) 19:27, 4 June 2021 (UTC)[reply]
@Jarekt and Multichill: I'm not sure if either of you has this issue, but to me, the automatic {{Creator}} template appears to include extra padding than the {{Institution}} template generated further down. Thanks for the help anyway, much appreciated. ᴀlbanɢeller (talk) 21:55, 4 June 2021 (UTC)[reply]
ᴀlbanɢeller, I did "fix" padding around Creator template at the same time, Maybe it is not working right in all browsers. Which file and which browser are you using? --Jarekt (talk) 02:18, 5 June 2021 (UTC)[reply]
Hi Jarekt, I noticed this on Anonymous - St Jerome in the Wilderness - NM 22 - Nationalmuseum.jpg. I'm using Safari (in desktop mode) on an iPad. ᴀlbanɢeller (talk) 02:23, 5 June 2021 (UTC)[reply]
@Jarekt: I've also noticed, on 4th Duke of Devonshire after Hudson.jpg for instance, that once the Creator template is expanded, the Artwork template stretches to fit and widens the entire page. (This doesn't occur with the other file I mentioned above.) ᴀlbanɢeller (talk) 01:34, 6 June 2021 (UTC)[reply]
ᴀlbanɢeller, I checked both files in Firefox, chrome and safari, and they all seep to look fine. --Jarekt (talk) 02:57, 6 June 2021 (UTC)[reply]
@Jarekt: I'm using a 1024-width display, so if you reduce the browser width you should probably see what I'm referring to. ᴀlbanɢeller (talk) 13:15, 6 June 2021 (UTC)[reply]
ᴀlbanɢeller, I can not reproduce this issue: I tried 3 different browsers, I tried it on my phone, I made browsers very narrow, and it still seem to look fine. At this point I would wait and see if others report the same issue. You can take a screenshoot showing the issue and upload it somewhere, but even with it I might not be able to reproduce it. --Jarekt (talk) 22:19, 9 June 2021 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:04, 4 February 2022 (UTC)

Additional "Source" field displayed by Template:Art Photo

[edit]

An additional "Source" field is displayed in the "Object" section generated from structured data (SDC). If the "Photograph" section's "Source" field is generated from structured data as well the same data is displayed twice, for example at File:Toy & Gay & Bronce - I (8384529507).jpg. Thanks for any help with this! --Marsupium (talk) 07:24, 2 September 2021 (UTC)[reply]

Marsupium yes 2 source fields are bad. I will look into it. Sorry I did not noticed this note earlier. Feel free to ping me for faster response in the future. --Jarekt (talk) 02:50, 9 January 2022 (UTC)[reply]
Fixed --Jarekt (talk) 04:32, 9 January 2022 (UTC)[reply]
Looks good! Thank you! --Marsupium (talk) 18:19, 10 January 2022 (UTC)[reply]

Similar problem returns for Template:Object photo

[edit]

… e.g. on File:Portrait de madame de Verninac by David Louvre RF1942-16 n1.jpg the object box has a source field which says a source is lacking. Jarekt, Multichill, could one of you have a look? Thank you, --Marsupium (talk) 18:36, 10 January 2022 (UTC)[reply]

Marsupium, I think Multichill accidentally undid my fix when he was fixing different issue. I put it back now. --Jarekt (talk) 00:16, 11 January 2022 (UTC)[reply]
Jarekt, File:The Chaldean Account of Genesis (1876) - illustration - page after 306.png has still 2 source fields. File:Portrait de madame de Verninac by David Louvre RF1942-16 n1.jpg as well. Best, --Marsupium (talk) 12:07, 12 January 2022 (UTC)[reply]
Thanks for this. That is a different issue. For historical reasons, We do have 2 different source fields: "source" and "source_", and there seem to be a confusion if one is set from wikitext and the other from SDC. I will look into it. --Jarekt (talk) 13:00, 12 January 2022 (UTC)[reply]
Fixed --Jarekt (talk) 03:09, 13 January 2022 (UTC)[reply]
Jarekt, thanks a lot for working on this! Sorry for bothering you again, but problem persists for File:Portrait de madame de Verninac by David Louvre RF1942-16 n1.jpg. Thanks in advance! --Marsupium (talk) 08:42, 13 January 2022 (UTC)[reply]
Marsupium I don't think I actually fixed the original issue you mentioned. I can not think of a simple solution to it. The best solution would be to stop using Template:Object photo and replace it with {{Art photo}}. --Jarekt (talk) 19:21, 17 January 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:03, 4 February 2022 (UTC)

Suppress creator role=photographer (Q33231) in "photographer" field?

[edit]

Probably not high priority, but would be nice to suppress Module:Wikidata art's function p.get_creator()'s creator role=photographer (Q33231) in "photographer" field, example: File:Lunch atop a Skyscraper.jpg. Best, --Marsupium (talk) 10:32, 13 January 2022 (UTC)[reply]

Marsupium, ✓ Done Stripping:
--Jarekt (talk) 04:12, 22 January 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:15, 4 February 2022 (UTC)

coordinates of depicted place from Wikidata

[edit]

We need to update the module so that coordinates of depicted place (P9149) on the Wikidata item also triggers {{Object location}}. Example file File:Raising the Flag on Iwo Jima, larger.jpeg. Multichill (talk) 16:04, 16 January 2022 (UTC)[reply]

✓ Done --Jarekt (talk) 04:43, 22 January 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:16, 4 February 2022 (UTC)

line 1485: attempt to get length of field '?' (a nil value)

[edit]

File:Bundesarchiv Bild 146II-849, Rudolf Heß.jpg shows this error instead of summary. It looks like recent Jarekt changes introduced a problem. --Derbeth talk 08:10, 22 January 2022 (UTC)[reply]

Yes, and not only with that photo, also with a lot of more. I think because a problem was added with the latest changes. 81.40.135.122 11:06, 22 January 2022 (UTC)[reply]
Author parsing seems to have caused some problems. I removed that part. Test cases:
Null edit will flush out the error now.
@Jarekt: code is still active at Module:Artwork/sandbox. I might have a look at it this weekend. Multichill (talk) 11:36, 22 January 2022 (UTC)[reply]
Sorry about that and thanks for the revert. I fixed the issue. I will touch all the files in Category:Pages with script errors to flush all the error files. I probably should look through other files in that category, so it is easier to spot new issues. --Jarekt (talk) 02:08, 23 January 2022 (UTC)[reply]
@Jarekt: cleaning it out is nice yes. Otherwise I wouldn't have spotted the LUA error on File:Jean Siméon Chardin, Soap Bubbles, probably 1733-1734, NGA 994.jpg caused by empty Soap Bubbles (Q20177882) and this module trying to loop over a string. Multichill (talk) 10:44, 23 January 2022 (UTC)[reply]
@Multichill: That was actually bug in older code and I was planning to fix it with this solution. --Jarekt (talk) 03:41, 24 January 2022 (UTC)[reply]
I just patched it up to prevent it from going down in flames, feel free to improve on it. Wouldn't that give a table in a table? Multichill (talk) 17:51, 24 January 2022 (UTC)[reply]
Yes, I will revisit it. I was doing a bit of a deep dive into the code (I should have been writing more comments and documentation) and from what I can figure out object_type_id is always array of item IDs (output of getBestProperties function for wikidata based values). ObjectTypeID function converts object_type template field into an item ID but since it is always a single one, it was saved as a string. After the merge of template inputs with wikidata data the object_type_id's type is unpredictable. So a solution would be to keep it always as an array (aka dictionary in lua). --Jarekt (talk) 01:16, 25 January 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:16, 4 February 2022 (UTC)

ref RKD

[edit]

shows twice File:Claesz.,_Pieter_-_Still_Life_with_Musical_Instruments_-_1623.jpg--Oursana (talk) 19:51, 26 January 2022 (UTC)[reply]

@Oursana: It’s not the module’s fault, it was stored in Wikidata twice. I’ve removed one of them. —Tacsipacsi (talk) 18:11, 30 January 2022 (UTC)[reply]
Sorry and thanks

✓ Done--Oursana (talk) 18:16, 30 January 2022 (UTC)[reply]

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:17, 4 February 2022 (UTC)

Ugly output without title

[edit]

See for example File:BASA-359K-1-195-13-Gusla Choir in Budapest, 1933.jpg—there’s no title, but the Wikidata-related icons appear in parentheses. I don’t know how to solve this issue, but the current version doesn’t look right. —Tacsipacsi (talk) 23:21, 23 March 2021 (UTC)[reply]

no tl artwork and no Wikidata item--Oursana (talk) 04:33, 17 April 2021 (UTC)[reply]
@Oursana and Tacsipacsi: Sorry for slow response. This image does not have author, title or wikidata item, so there is not much to show in the bar on the top. Wikidata-related icons are there to help finding or adding wikidata items for this image. I add them to the title bar. I agree that in this file it doesn’t look right, but I am not sure what would be a better layout. --Jarekt alt (talk) 18:26, 4 February 2022 (UTC)[reply]
Could we remove the icons? Though trying it from time to time I can't remember a single case for which one of the searches linked from the first two icons has brought useful results.
If just tried the third icon against manual item creation with d:Special:NewItem and adding it as digital representation of (P6243). It has saved me around 20 seconds. I think we should count the actual usage of that icon. (That should be possible by adding a custom edit comment, cf. d:Help:QuickStatements#Comments.) Showing this icon to myriads of users who don't have a clue what it's for is only justified if it's used a lot I'd say.
Do you know the location of the original discussion where this feature was announced? I don't recall where it was … Thanks in advance, --Marsupium (talk) 00:58, 5 February 2022 (UTC)[reply]
@Jarekt: Actually, I think simply not putting them within parentheses would already help a lot—but in this case also hiding the buttons, a random photograph isn’t likely to have a Wikidata item anyway. —Tacsipacsi (talk) 01:03, 6 February 2022 (UTC)[reply]
@Marsupium and Tacsipacsi: No more Wikidata-related icons in an otherwise empty top row. Files with so little info are probably not good candidates to adding items to Wikidata anyway. --Jarekt (talk) 04:39, 6 February 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt (talk) 04:39, 6 February 2022 (UTC)

Showing image with frame (P7420) in "Other versions"

[edit]

… if it is different from the current file and |other versions= is not set. What do you think about it? Thanks for any comments, --Marsupium (talk) 07:28, 3 September 2021 (UTC)[reply]

I like the idea. We actually could have more images in the |other versions= section: any image in image (P18) or {{|P7420}} that is not the current image. --Jarekt (talk) 02:43, 9 January 2022 (UTC)[reply]
Yeah, I could imagine to have more automatic other versions, e.g. also nighttime view (P3451) (mainly used/useful for outdoor objects probably). I'm not sure about image (P18) since its value is already shown in all boxes created by this module by default, no!? --Marsupium (talk) 18:33, 10 January 2022 (UTC)[reply]

I started experimenting with it and {{#invoke:Wikidata art/sandbox|debug|wikidata=Q2546309|field=other_versions}} will create "

  • image 
    image Edit this at Wikidata
  • image 
    image Edit this at Wikidata
  • image with frame 
    image with frame Edit this at Wikidata

" unfortunately I am writing "<gallery>" but I am getting "&lt;gallery&gt;". I am not sure how to fix it yet. --Jarekt (talk) 01:18, 11 January 2022 (UTC)[reply]

@Jarekt: You need to use frame:extensionTag for certain XML tags, such as <pre>, <nowiki>, <gallery> and <ref>. I've updated the sandbox with code that I think does what you want. —RP88 (talk) 03:01, 11 January 2022 (UTC)[reply]
Thanks, For everything else I am writing pure HTML but I guess "<gallery>" is something else. --Jarekt (talk) 11:20, 11 January 2022 (UTC)[reply]
✓ Done --Jarekt (talk) 12:15, 11 January 2022 (UTC)[reply]
Jarekt, thank you! How about adding captions to the files from the Wikidata property labels? That should be an accessibility improvement. Probably "packed-hover" gallery mode is the best for this. I've changed the code of Module:Wikidata art/sandbox to add it so the result can already be seen in the example above. Thanks for taking a look! --Marsupium (talk) 13:48, 11 January 2022 (UTC)[reply]
Good idea, I deployed it. Thanks --Jarekt (talk) 03:56, 12 January 2022 (UTC)[reply]
Jarekt, thanks for all the work! Follow-up:
  1. I've added editAtWikidata icon to the captions. If you like it any other way feel free to change it.
  2. If there is just an image form image (P18) it looks stupid and is a waste of space since it is already above to the left (apart from cases like books?). E.g. File:Wooden mask-ETHAM K001651-P8190667-white.jpg. I guess in those cases the auto-other-versions should be dropped.
Best, --Marsupium (talk) 21:43, 13 January 2022 (UTC)[reply]
Marsupium, I agree about single image from image (P18). I altered the code and now you have to have at least 2 files for this gallery to appear. --Jarekt (talk) 04:23, 6 February 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt (talk) 04:28, 6 February 2022 (UTC)

Artist issue

[edit]

Artist is not showing at File:Belt MET 09.21.18.jpg. --Jarekt (talk) 12:19, 16 May 2018 (UTC)[reply]

The issue is not with the template. --Jarekt alt (talk) 15:48, 14 February 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 15:48, 14 February 2022 (UTC)

Attempt to index local 'list' (a nil value)

[edit]

on many Bundesarchiv images (e.g. File:1941. Bundesarchiv Bild 169-0120, Russland, Donetsk, Bahnhof.jpg). Seems that Module:I18n/artwork defines inaccurate_description (with lower case i), but this module wants to read Inaccurate_description in line 164 (with upper case I). One of them should change its mind. —Tacsipacsi (talk) 15:33, 7 April 2019 (UTC)[reply]

No longer an issue. --Jarekt alt (talk) 17:41, 14 February 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:41, 14 February 2022 (UTC)

Fetch "place of creation" from location of final assembly (P1071)?

[edit]

We could fetch "place of creation" from location of creation (P1071) I think. --Marsupium (talk) 01:04, 7 June 2019 (UTC)[reply]

Sounds good. I am adding it to the /sandbox version. --Jarekt (talk) 02:19, 8 June 2019 (UTC)[reply]
✓ Done --Jarekt alt (talk) 17:43, 14 February 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:43, 14 February 2022 (UTC)

fetch publisher for wikidata

[edit]

I noticed that publisher (P123) can't be fetch from Wikidata like other properties. --Escudero (talk) 10:30, 8 July 2019 (UTC)[reply]

Escudero, yes publisher fetching was broken. I fix it in Module:Artwork/sandbox and will roll out with next set of changes. Thanks. --Jarekt (talk) 12:03, 8 July 2019 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:44, 14 February 2022 (UTC)

title (P1476)

[edit]

In the absence of the title in the template, I think it could be interesting to display this. Jura1 (talk) 09:46, 11 November 2019 (UTC)[reply]

I am working on rewrite of {{Title}} in Lua. Afterwards I will integrate it with {{Artwork}}. --Jarekt (talk) 23:27, 7 December 2019 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:46, 14 February 2022 (UTC)

Qualifier for attributions

[edit]

This module adds "attributed to" to creator based on the walue of the sourcing circumstances (P1480). I've just noticed that d:Wikidata:WikiProject Visual arts/Item structure recommends using nature of statement (P5102) instead, and I think it makes sense. Though P1480 seems to be the most widely used of the two at the moment, this module should probably support both qualifiers. _Zolo (talk) 14:35, 21 April 2020 (UTC)[reply]

✓ Done, Zolo, I checked the code and both are supported. --Jarekt alt (talk) 18:01, 14 February 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 18:01, 14 February 2022 (UTC)

Coordinates from SDoC?

[edit]

Currently the template tries to find the coordinates from coordinate location (P625). However, this works only if there is wikidata item which is related to the file and it would be helpful if the template would also load cordinates from Structured data on commons if they are defined there. --Zache (talk) 15:08, 10 July 2020 (UTC)[reply]

Problem with that approach is that currently that is done by adding {{Object location}} to your file and if I add coordinates to the {{Artwork}} than some files might have two. Also artwork location is a object level property, instead of image level property so a more natural place to keep it would be on Wikidata. I would prefer not to encourage people to keep it in each individual file. --Jarekt (talk) 15:43, 10 July 2020 (UTC)[reply]
Ah, i see the problem. In any case this module is used for {{Photograph}} too where there is no wikidata item for the topic of the individual photo and most likely never will be. (or least there will not be in the context of the location accuracy). In any case. if I would like to it currently it would be by adding {{Location}} without parameters to infobox template and coordinates of the point of view (P1259) SDC for camera coordinates? (example) --Zache (talk) 11:26, 11 July 2020 (UTC)[reply]
Correct --Jarekt alt (talk) 17:58, 14 February 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:58, 14 February 2022 (UTC)

Close gap between Template:Art Photo and Template:Information

[edit]

@Jarekt: Are there already any plans for this module to retrieve SDC for the source/photo information – especially of Template:Art Photo – like Template:Information does? Thank you, --Marsupium (talk) 14:17, 9 October 2020 (UTC)[reply]

Yes it is on my to do list. Module:Artwork did not changed much since Module:Information was written. I was planning to use Module:Information for the lower infobox in Template:Art Photo. Unfortunately current Template:Art Photo allows a lot of almost never used parameters like 'photo_title', 'photo_description', 'photo_medium', 'photo_dimensions', 'photo_institution', 'photo_department', 'photo_accession_number', and 'photo_inscriptions' and I would need to retire them. So before I can go forward on this I need to check how many files will be affected. --Jarekt (talk) 19:46, 9 October 2020 (UTC)[reply]
@Jarekt: Thanks for your reply, good to hear! Why is there a need to retire them? Can't Module:Artwork use the Module:Information functions and assemble a table from parameters of both? Values could even get moved to SDC. But indeed they are barely used at the moment:
Parameter Uses
photo title 3
photo medium 1
photo dimensions 1
photo institution 1
photo department 1
photo accession number 1
photo inscriptions 0
Cheers, --Marsupium (talk) 11:57, 10 October 2020 (UTC)[reply]
Good use of search feature my Category:Pages using "Art photo" template with rare parameters added by the template did not returned anything yet. Those parameters were added because I was using {{Artwork}} and {{Photographer}}, but if I replace {{Photographer}} with {{Information}} than I prefer to fill {{Information}} only with templates usually supported by it. Also If that feature is not used than it is better to remove it to make the whole thing less confusing. --Jarekt (talk) 21:56, 10 October 2020 (UTC)[reply]
Sure, I see. --Marsupium (talk) 09:14, 11 October 2020 (UTC)[reply]

✓ Done current version of Module:Artwork uses {{Information}} instead of {{Photographer}} when creating second infobox of Template:Art Photo. --Jarekt alt (talk) 17:55, 14 February 2022 (UTC)[reply]

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:55, 14 February 2022 (UTC)

File types and Wikidata destination properties

[edit]

@Jarekt: Continuing my revert edit summary: The matrix (copying from Wikidata constraints) looks like this:

Most cases can probably be fixed at Wikidata automatically with d:Template:Autofix, so not so dramatical, but it is not set up for all cases and perhaps it's nicer to send the links to the right property in the first place. Implementation should be fairly easy. I'm not sure if I could do it soon. So it's here for who ever feels to take care of it! --Marsupium (talk) 13:23, 1 November 2018 (UTC)[reply]

I mostly follow the above rules. I have a lot of pages with incorrect suggestion in Category:Artworks with Wikidata item: quick statements and since I was just adding about 600 P18's yesterday some .stl files must snicked in. I made changes to Artwork/sandbox to address the incorrect suggestions by recognizing 3D model (P4896) along with 3 other image properties so if they are present Module is not trying to add them. I do not build QS links to add 3D model (P4896), video (P10) or document file on Wikimedia Commons (P996) at the moment but that is a good idea. --Jarekt (talk) 13:55, 1 November 2018 (UTC)[reply]
Yes, I mean the property should be selected by the file extension. Currently files get included in the P18 QuickStatements commands regardless of file type or file extension which causes constraint violations at Wikidata. --Marsupium (talk) 14:08, 1 November 2018 (UTC)[reply]
I have a partial fix as 3D model (P4896) can be read now. Still have to implement proper writing. --Jarekt (talk) 16:04, 15 November 2018 (UTC)[reply]
Marsupium, it took some time but I thin the code in the sandbox will place images (either passed as "image" parameter or based on file using the template) to the correct Wikidata property. Just need to find some files to test it on. --Jarekt alt (talk) 17:40, 14 February 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 15:23, 2 March 2022 (UTC)

Fetch more than one value from Wikidata for place of publication (P291) and other properties

[edit]

place of publication (P291) is yet another example of a property for which the 'one' in getProperty(entity, prop, 'one') isn't a good choice my 2ct :-) … I noticed it in Template:Gray's Anatomy where the local value can't get removed for that reason. Cheers, --Marsupium (talk) 15:45, 2 September 2019 (UTC)[reply]

✓ Done Marsupium, I just checked and this suggestion was implemented already. So I will be closing this request. --Jarekt alt (talk) 17:33, 3 March 2022 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt alt (talk) 17:33, 3 March 2022 (UTC)

Processing of creator templates with option set via QuickStatements code

[edit]

@Jarekt: I've half-fixed a problem where a QuickStatements code part of a creator template with option set is treated as a QID. So a creator like {{Creator:Meister Theoderich von Prag|circle of}} ends up as "Q4233718,P1776,Q446631" as the header creator:

Circle of Theodoric of Prague: foo
Author
Circle of Theodoric of Prague  (fl. 1359–1368)  wikidata:Q446631
 
Alternative names
Čeština: Dittrich, Dětřich, Jetřich, Dětřich Pražský, Zelo
Deutsch: Magister Theodoricus
Description Bohemian painter
Date of birth/death before 1328
date QS:P,+1328-00-00T00:00:00Z/7,P1326,+1328-00-00T00:00:00Z/9
 Edit this at Wikidata		 before 11 March 1381
date QS:P,+1381-03-11T00:00:00Z/7,P1326,+1381-03-11T00:00:00Z/11
 Edit this at Wikidata
Location of birth/death Italy Prague
Work period 1359 - 1365
Work location
Prague, Karlštejn Castle
Authority file
creator QS:P170,Q4233718,P1776,Q446631
Title
foo

Changing the regex pattern doesn't solve the whole problem since the creators with option set still aren't processed. I guess that will require some more work. I just wanted to let you know about the fix and leave a note here for a possible todo for anyone volunteering :-) Cheers, --Marsupium (talk) 21:33, 8 September 2019 (UTC)[reply]

Marsupium, I was not aware of this issue (or I forgot about it?). Was this discussed before? I will see if I can figure it out. --Jarekt (talk) 02:34, 9 September 2019 (UTC)[reply]
Jarekt, I wasn't aware of the issue, either. I've stumbled upon it only yesterday and I don't think it was discussed before. This prevents that the Wikidata IDs are displayed where affected. But then no creator is displayed in the header and the creator still cannot be evaluated for the setting of maintenance categories. Best, --Marsupium (talk) 05:39, 9 September 2019 (UTC)[reply]
Marsupium, I think I got it fixed {{Artwork/sandbox |title=foo |author={{Creator:Meister Theoderich von Prag|circle of}}}} gives
Circle of Theodoric of Prague: foo
Author
Circle of Theodoric of Prague  (fl. 1359–1368)  wikidata:Q446631
 
Alternative names
Čeština: Dittrich, Dětřich, Jetřich, Dětřich Pražský, Zelo
Deutsch: Magister Theodoricus
Description Bohemian painter
Date of birth/death before 1328
date QS:P,+1328-00-00T00:00:00Z/7,P1326,+1328-00-00T00:00:00Z/9
 Edit this at Wikidata		 before 11 March 1381
date QS:P,+1381-03-11T00:00:00Z/7,P1326,+1381-03-11T00:00:00Z/11
 Edit this at Wikidata
Location of birth/death Italy Prague
Work period 1359 - 1365
Work location
Prague, Karlštejn Castle
Authority file
creator QS:P170,Q4233718,P1776,Q446631
Title
foo

--Jarekt (talk) 14:29, 9 September 2019 (UTC)[reply]


Jarekt, thanks a lot for your fix! Two more things:
  • Currently, {{Artwork/sandbox |title=foo |author={{Creator:Meister Theoderich von Prag|Circle of}}}} with uppercase "Circle of" gives:
Circle of Theodoric of Prague: foo
Author
Circle of Theodoric of Prague  (fl. 1359–1368)  wikidata:Q446631
 
Alternative names
Čeština: Dittrich, Dětřich, Jetřich, Dětřich Pražský, Zelo
Deutsch: Magister Theodoricus
Description Bohemian painter
Date of birth/death before 1328
date QS:P,+1328-00-00T00:00:00Z/7,P1326,+1328-00-00T00:00:00Z/9
 Edit this at Wikidata		 before 11 March 1381
date QS:P,+1381-03-11T00:00:00Z/7,P1326,+1381-03-11T00:00:00Z/11
 Edit this at Wikidata
Location of birth/death Italy Prague
Work period 1359 - 1365
Work location
Prague, Karlštejn Castle
Authority file
creator QS:P170,Q4233718,P1776,Q446631
Title
foo
To fix this Module:Creator, line 1048 should be replaced by
			QS = string.format('P170,Q4233718,%s,%s', qual[mw.ustring.lower(args.option)] or 'P?', args.wikidata)
I haven't changed this in Module:Creator/sandbox because it has some differences that seem to hide the variable a1 from the block it is used in.
  • setting redundant doesn't work for those creators, so Module:Wikidata art's function p.get_creator() should be adapted changing the last if clause: 
    	if #IDs==1 and not IDs[1].option then
		Res.id = IDs[1].itemID
	end
    to something like 
    	if #IDs==1 then
		local qualifierQS = ''
		if IDs[1].option then
			qualifierQS = ',' .. VARIABLETHATHOLDSTHEPROPERTY .. ',' .. qualifierQS
		end
		Res.id = IDs[1].itemID .. qualifierQS
	end
    and saving "VARIABLETHATHOLDSTHEPROPERTY" in the code before. If you like to look into it, I'll be happy. I can try later as well. Cheers, --Marsupium (talk) 13:47, 10 September 2019 (UTC)[reply]

Marsupium, this one was fixed, broken and fixed again. I will close it. --Jarekt (talk) 03:43, 7 March 2022 (UTC)[reply]

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jarekt (talk) 03:44, 7 March 2022 (UTC)

Filter out additional item of collection or exhibition (Q18593264)?

[edit]

(Moved here from Template talk:I18n/objects since functionality is implemented in this module.)

I think it could make sense to filter out item of collection or exhibition (Q18593264) if it's not the single item like on File:Bellbeaker culture - beaker - Musée Unterlinden inv. no. Ap.222.jpg. What do you think @Jarekt and Zolo? --Marsupium (talk) 11:12, 12 February 2024 (UTC)[reply]

@Marsupium: , Items with instance of (P31)=item of collection or exhibition (Q18593264) make little sense and are a constraint violation for proper used of P31. The way to fix those is to remove the statement on Wikidata, see d:Talk:Q18593264. We can also not show it in {{Artwork}}, but I am not sure if it is worth complicating the code over this (hopefully) edge case. --Jarekt (talk) 13:08, 12 February 2024 (UTC)[reply]
Hello and thanks for the reply! I actually found the constraint and d:Talk:Q18593264 only after writing this. I agree that it should be enough do deal with them on Wikidata. Thanks again! --Marsupium (talk) 19:50, 12 February 2024 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --Marsupium (talk) 19:50, 12 February 2024 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Module_talk:Artwork/Archive&oldid=851537386"