Module talk:Artwork

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day. For the archive overview, see Special:PrefixIndex/Module talk:Artwork. The latest archive is located at /Archive.

Feature request: support for sourcing circumstances (P1480): near (Q21818619) qualifiers for locations[edit]

We need support for sourcing circumstances (P1480): near (Q21818619) qualifiers for locations. An example is stela with orans between palm branches and crosses (Q63881508) location of discovery (P189): Edfu (Q239107), qualifier sourcing circumstances (P1480): near (Q21818619). Just dumping it here not to forget it. Cheers, --Marsupium (talk) 10:47, 17 May 2019 (UTC)[reply]

This could also apply to location of discovery (P189), location of creation (P1071) and place of publication (P291) used by the template. Any other modifiers of the "place" properties we should watch out for? --Jarekt (talk) 02:30, 8 June 2019 (UTC)[reply]
--Marsupium (talk) 18:08, 9 June 2019 (UTC)[reply]
Marsupium You are right location of discovery (P189) shows up twice. In the earlier stages of development I was doing a lot of combining different Wikidata properties to recreate existing Commons infobox field, however now I like to keep them more on 1:1 basis. The reason is that sometimes people use some of those fields in creative ways, and I prefer to do less interpreting and operating on the data and more of simply displaying it. For example someone might use place_of_creation for and office that produced some document, so it is more like an author substitute then object history. More fields each dealing with a single property, is less prone to some confusing results. --Jarekt (talk) 15:54, 10 June 2019 (UTC)[reply]

title[edit]

can't we use {{title|{{label|Q....}}}}as default--Oursana (talk) 09:20, 9 October 2019 (UTC)[reply]

I don’t think so. Labels are (not for all, but for many cases) different from titles. --Marsupium (talk) 01:46, 3 May 2024 (UTC)[reply]


Initial pages (books)[edit]

@Jarekt:

The gallery format "packed" works at:

but not on

How could it be fixed? Also can the display be suppressed on mobile view (I tried that with class="wdinfo_nomobile" borrowed from the Template:Wikidata Infobox) but it seems it's still present at:

Current change. --- Jura1 (talk) 05:52, 15 August 2020 (UTC)[reply]

@Jura1: I reorganized the code a bit so the "Initial pages" section is added using the same mechanism most other sections are added. I also added internationalization code to Module:I18n/artwork. Please add more translations if you can. Unfortunately, I lost the code related to mobile edits. However they did not seem to work any way. I wonder if there is a way to detect is a page is rendered from mobile platform or not. I will ask around. About the display on Spanish Wikisource, I do not know why it is broken, but w:es:Archivo:Mona_Lisa,_by_Leonardo_da_Vinci,_from_C2RMF_retouched.jpg or s:es:Archivo:Mona_Lisa,_by_Leonardo_da_Vinci,_from_C2RMF_retouched.jpg also have the same issue. --Jarekt (talk) 04:06, 17 August 2020 (UTC)[reply]
Great, thanks. The general problem of s:es: could be fixed separately. --- Jura1 (talk) 05:23, 17 August 2020 (UTC)[reply]
@Mike Peel: how can we add class="wdinfo_nomobile" here? I saw it worked on Template:Wikidata Infobox. Are there other elements that are required? --- Jura1 (talk) 05:23, 17 August 2020 (UTC)[reply]
@Jura1 and Jarekt: That css class is defined in Template:Wikidata Infobox/styles.css, which is only loaded when you use the infobox template. If this template also has templatestyles, then it's a simple class to copy over, or perhaps it should go in Mediawiki:Common.css if there's no equivalent there already. Thanks. Mike Peel (talk) 08:10, 17 August 2020 (UTC)[reply]
Thanks. Maybe we could add class="wdinfo_nomobile" to <tr> through function Build_html_row(param, args). --- Jura1 (talk) 09:39, 18 August 2020 (UTC)[reply]


@Kaldari: , Jura1 proposed to display initial pages of PDF/DjVu books in the {{Book}} template so we can more easily find the title page. However he was trying not to show that field in case someone used mobile connection. I noticed you are on the mobile team, any advice you can share? Is there a way to detect if the user is using mobile connection from Lua? Or is there some HTML marking we should use? --Jarekt (talk) 04:13, 17 August 2020 (UTC)[reply]

Entry point for illustration-type images[edit]

Would it make sense to have a function illustration to capture metadata from a book (or other publication) illustration? For example illustrations might have:, using File:The Chaldean Account of Genesis (1876) - illustration - page after 306.png as an example:

  • The "containing" work: File:The Chaldean Account of Genesis (1876).djvu, which could be a Wikidata edition
  • An original caption: "Oannes, from Nimroud statue".
  • A "modern" caption like "illustration from The Chaldean Account of Genesis: line drawing of a statue of Oannes"
  • The author of the image (may or may not be the author of the book)
  • There may be a separate engraver, lithographer or other involved person
  • The physical page the image comes from (in this case "after 306": the actual page is not numbered)
  • A higher resolution source file if used (in this case: https://archive.org/details/chaldeanaccounto00smit)
  • Perhaps additional descriptive information like the size, the image "type": line drawing, tipped-in map, etc
  • The license of the image, which is sometimes not the same as the parent work

So you could have a template something like: 

{{illustration
 | parent           = File:The Chaldean Account of Genesis (1876).djvu
 | page             = after 306
 | description      = Line drawing of a statue of Oannes from ''The Chaldean Account of Genesis''
 | original_caption = Oannes, from Nimroud statue
 | author           = Not stated <!-- is there a template for this, or just {{unknown}}, or blank, or what? -->
 | engraver         = Not stated
 | source           = https://archive.org/details/chaldeanaccounto00smit
 | license          = {{PD-US-expired}}
}}

If there was such a template, it could be used by https://ws-image-uploader.toolforge.org/ instead of stuffing it all untidily into {{Information}}. Inductiveload (talk) 15:14, 19 August 2021 (UTC)[reply]

Or maybe there's an existing way to cleanly represent such information already? Inductiveload (talk) 09:41, 11 January 2022 (UTC)[reply]
To leave a reply at least: I think work on this is strongly needed. I don't know a way "to cleanly represent" some data for illustrations (and all kinds of prints). I'm not sure about the best solution though. But maybe some of the data you mention above justifies special treatment by this module and could be addressed with new fields in Template:Artwork. Needs more thought I think. Marsupium (talk) 10:04, 11 January 2022 (UTC)[reply]
Inductiveload, I also agree that that is needed. I run into similar issue with File:Stroop Report - Warsaw Ghetto Uprising 06b.jpg and other Stroop Report photographs. I have seen some creative solutions but no widely used infobox. It would not be hard to have a template to do wikitext only infobox for the illustration with either {[tl|Book}} template on the bottom or using book citation, like with Module:Cite Wikidata (see examples). --Jarekt (talk) 02:42, 12 January 2022 (UTC)[reply]
Inductiveload, some more comment: I think some of the things you are asking for are already supported (I've adapted File:The Chaldean Account of Genesis (1876) - illustration - page after 306.png a bit):
  • An original caption: "Oannes, from Nimroud statue".
Use |original description=.
  • A "modern" caption like "illustration from The Chaldean Account of Genesis: line drawing of a statue of Oannes"
Use |description=.
  • The author of the image (may or may not be the author of the book)
Put in |artist=.
  • There may be a separate engraver, lithographer or other involved person
Put in |artist=.
  • The physical page the image comes from (in this case "after 306": the actual page is not numbered)
No support for this yet afaik
Use |other versions=?
  • Perhaps additional descriptive information like the size, …
Use |dimensions=.
… the image "type": line drawing, tipped-in map, etc
Use |object type=.
  • The license of the image, which is sometimes not the same as the parent work
Put a license template in the license section of the file description page. (I don't see why the license for the parent work should be on the page for an image from it at all.)
Best, --Marsupium (talk) 08:28, 12 January 2022 (UTC)[reply]
@Marsupium thanks for the replay. In general, sure, that's why I'm asking, as it seems this template is "almost there", but I don't have enough domain knowledge of it to be sure, and it would be nice to be sure before I start baking it into tooling. Mostly what it's missing is the standardized way to refer to the "parent" work (i.e. the book) and the location within it, without having to construct and duplicate some non-standardized wikitext for every image in the book (which will lead to bit rot). Ideally, the book edition (not work!) would have a Wikidata ID and we can just use that as the pointer to the parent.
The higher resolution source files is probably just the {{{source}}}. I called it out separately to remind that very often (in fact, it's usually dead wrong to do otherwise), the image should be extracted from some higher-resolution source, as opposed to being cropped from the PDF or DJVU, which is usually compressed to death (s:en:H:EXTRACT for some examples). Likewise for the license, that's just a reminder that image license is not always the license of the parent work—currently, with a mishmash of templates being used, I suspect that distinction is not always made accurately.
With respect to artist, the {{{artist}}} field makes sense, though it seem like it would be good to be able to be more specific when pulling data from structured data (may look something like Commons:Structured_data/Modeling/Illustrations). I do not know enough about this template to know if that would be better captured by separate fields, or a generic artist field and some kind of qualification inside that. Inductiveload (talk) 08:50, 12 January 2022 (UTC)[reply]
Something similar would be really useful for academic research papers, many of which have compatible licenses. Each paper is uniquely identified by a DOI number, and the images are generally numbered "Figure 1, Figure 2...". I've uploaded a lot of these and it would be great to be able to index them easily to the work (for all I know there's a method I haven't been using). Since I usually upload all the images from a single paper at once, copy-to-all would make it fairly simple. It might be possible to automatically, retroactively insert such metadata by scanning for DOIs, as done in Citoid (and originally Zotero, from which I think Citoid took the algorithms) and the word "figure" or "Fig." followed by a number. HLHJ (talk) 18:51, 15 January 2022 (UTC)[reply]

New field ~"Location within parent work"?[edit]

Jarekt, I think most of the data in the example code above in #Entry point for illustration-type images is already modeled more or less well. But the "page" information is not. I've also run into this before. Often "page" isn't the adequate reference, sometimes it is something like "column", "folio" etc. What do you think about a new "Location within parent work" (needs better wording) field? (Like {{Map}}'s |volume= and |page=.) Example use case: File:The Chaldean Account of Genesis (1876) - illustration - page after 306.png. Best, --Marsupium (talk) 08:31/08:45, 12 January 2022 (UTC)[reply]

To be completely general, you may also need "series" and "issue" to accurately place images in, say, periodicals (which probably outnumber images in books!). As you say, you may need sub-page resolution like column (P3903), but also it may make sense to be able to capture "logical" location (as opposed to physical) like section, verse, paragraph, or clause (P958).
Though I guess the "right" answer may be to defer the entire complex bibliographic hierarchy like work/series/volume/issue/article to Wikidata, and simply refer to the finest-grained "unit" on Wikidata (probably the article itself, or the issue if the illustration isn't part of a specific article), with just the "page/folio/column/paragraph" properties being needed to further refine that. Inductiveload (talk) 09:04, 12 January 2022 (UTC)[reply]
Longer-term it might be nice to merge the {{Map}} template into this one, to improve its functionality and reduce code duplication. Adding some of the structure that can {{Map}} can present as a possibility here could be a great step forward towards that. Jheald (talk) 10:57, 12 January 2022 (UTC)[reply]
Jheald, Module:Artwork already supports over 50 different fields supporting several templates with mostly overlapping needs. {{Map}} would introduce few dozen extra fields which are not used by other templates. Module:Artwork+Module:Wikidata art are already at 2700 lines of code and I am afraid that is getting hard to manage. What I might do is to break off chunks of Module:Artwork and put them in other modules which can be then called by Module:Map and possibly others in order to reduce code repetition. Would that be useful for Module:Map? --Jarekt (talk) 02:37, 13 January 2022 (UTC)[reply]
That could very well be useful -- and it sounds like some modularisation could be useful for its own sake, anyway.
I hope to be looking at {{Map}} in more detail once again in the next few weeks, so may come back with some specifics then. Common module sharing could be very useful. Jheald (talk) 17:15, 14 January 2022 (UTC)[reply]
WRT using section, verse, paragraph, or clause (P958), also note that that it is overloaded to also be the figure reference (e.g. "Fig. 1", "Plate IIV", etc), since there is no dedicated property for that so that may confuse things too. Inductiveload (talk) 11:32, 12 January 2022 (UTC)[reply]
@Marsupium, Inductiveload, and Jheald: , Maybe the best way would be to add template {{Ilustration}} to {{Artwork}}, {{Photograph}}, {{Art photo}}, and {{Book}} that depend on Module:Artwork. While designing it I think we should be able to add all the information to the either SDC, Wikidata or both. In case of illustrations in books I think the book info should be in the Wikidata, while information about individual image in the SDC. For illustrations in a newspaper/periodical the periodical should be identified by the wikidata item and the volume, issue, publication date etc. could be either in the SDC or in Wikidata (for example if we have and item for an article in a periodical). The template would be able to use all the fields available to other templates and we might need to add extra field support, like section, verse, paragraph, or clause (P958) which can be shown in "Location within parent work" field. --Jarekt (talk) 02:37, 13 January 2022 (UTC)[reply]
Jarekt,  Support for all of that, especially the concept of data distribution between WD and SDC!
Just one consideration: Unless using {{Illustration}} instead of {{Artwork}} changes something, e.g. the overall layout, it might not be necessary to introduce a new template (and do all the replacements). Any new field should also be offered by flagship {{Artwork}} in my eyes. --Marsupium (talk) 08:04, 13 January 2022 (UTC)[reply]
I was thinking about using {{Illustration}} instead of {{Artwork}} so that we can document it properly. Also some of the SDC properties like volume, issue, publication date etc. might only make sense in case of illustration from periodical. The same code, when applied to other files might generate incorrect output. If we use generic {{Artwork}}, we could require SDC to have instance of (P31) == "illustration from periodical" or something for that code to be activated. And I agree that any field we add should be available to other templates, as it is now. For example {{Artwork|date=xx|publication_date=xx}}, works. --Jarekt (talk) 04:24, 15 January 2022 (UTC)[reply]
Agree, sounds like a good plan!
Another thought that came later to my mind: I think it would be good to also support getting data from a dedicated Wikidata item for an illustration, an example would be File:Shahnameh3-1.jpg/Qaran unhorses Barman (Q64690773). Best, --Marsupium (talk) 07:37, 15 January 2022 (UTC)[reply]

Bug: Invalid Wikidata Q-ID leads to script error[edit]

{{Artwork |wikidata=Q112040533^+ Q112040533}} gives: The ID "Q112040533^+ Q112040533" is unknown to the system. Please use a valid entity ID Real life example: Special:Permalink/656409299. The module should let this invalid input fail gracefully and not use it and maybe sort the file into a maintenance category, e.g. Category:Artworks with wrong Wikidata item could become overloaded with those issues. Thanks in advance for any input on this, --Marsupium (talk) 23:06, 19 May 2022 (UTC)[reply]

@Marsupium: , the incorrect content of "wikidata" field is quite rare and it would go into Category:Category:Pages with script errors, which I check regularly for issues. We could catch it more gracefully, but I see it so rarely that it did not seem very important. Category:Artworks with wrong Wikidata item was actually meant for something different, like actual items which based on instance of (P31) are likely wrong. --Jarekt (talk) 13:59, 27 June 2022 (UTC)[reply]
Okay, I see, I still think graceful failing would be cleaner, but maybe regarding the rareness it's not worth the effort. Thanks for the reply! --Marsupium (talk) 08:32, 28 June 2022 (UTC)[reply]

Filling other versions based on different from and based on[edit]

@Jarekt: I mixed up some paintings at File:Bartolomé Esteban Perez Murillo - Adoration of the Shepherds - WGA16387.jpg. I updated The Adoration of the Shepherds (Q106497109) and Adoration of the Shepherds (Q21725144) with different from (P1889) and based on (P144) to make clear these paintings are different. Can you use these statements to fill the other_versions field? You might be able to use different from (Q66087861) and based on (Q30171963) for the captions. Multichill (talk) 10:14, 26 June 2022 (UTC)[reply]

@Multichill: Sounds like a good idea. --Jarekt (talk) 13:53, 27 June 2022 (UTC)[reply]
@Jarekt: not sure if you had a look at it, but I noticed that other version is filled at File:Haarlem, Grote Kerk.jpg based on d:Q1545193#P18. We should probably add other relevant properties like image of interior (P5775) & aerial view (P8592) to the mix too. Multichill (talk) 19:37, 16 July 2022 (UTC)[reply]
Multichill, The code for this is at Module:Wikidata_art line 980-1002. So far I was using:
I added image of interior (P5775) & aerial view (P8592). --Jarekt (talk) 02:15, 18 July 2022 (UTC)[reply]
@Jarekt: Thanks for adding and thanks for the list Will have a look around if we have more relevant properties that should be added to this list.
I guess that the different from (P1889) and based on (P144) are a bit more work to add? Multichill (talk) 18:38, 18 July 2022 (UTC)[reply]
@Multichill: , We can do different from (P1889) and based on (P144). They shouldn't be too hard. --Jarekt (talk) 01:27, 19 July 2022 (UTC)[reply]
I added
See Module_talk:Wikidata_art/testcases#Other_Versions_Test --Jarekt (talk) 03:14, 19 July 2022 (UTC)[reply]
@Jarekt: nice, but it doesn't seem to work on File:Bartolomé Esteban Perez Murillo - Adoration of the Shepherds - WGA16387.jpg? That file uses The Adoration of the Shepherds (Q106497109) and when I test with that I just get an empty result. Multichill (talk) 15:57, 19 July 2022 (UTC)[reply]
@Multichill: , The Adoration of the Shepherds (Q106497109) is different from (P1889) Adoration of the Shepherds (Q21725144), but Q21725144 does not have an image. That why it does not show up. --Jarekt (talk) 01:09, 20 July 2022 (UTC)[reply]
@Jarekt: doh! Some idiot removed it. Multichill (talk) 21:17, 20 July 2022 (UTC)[reply]
An example for a value of schematic
@Jarekt and Multichill: Hello, what do you think about adding schematic (P5555) as well? An example would be The Annunciation of the Death of the Virgin (Q116444864) with File:Composition Seconde Annonciation - Heures d'Étienne Chevalier.jpg as a value. Best, --Marsupium (talk) 18:09, 31 January 2023 (UTC)[reply]
✓ Done --Jarekt (talk) 05:01, 1 February 2023 (UTC)[reply]
Looks great! Thanks! --Marsupium (talk) 08:09, 1 February 2023 (UTC)[reply]

require('strict')[edit]

{{Edit protected}} As per the new lua feature mentioned at m:Tech/News/2022/42, could require('Module:No globals') be replaced with require('strict') -- WOSlinker (talk) 17:26, 25 October 2022 (UTC)[reply]

✓ Done. Jonesey95 (talk) 04:43, 26 October 2022 (UTC)[reply]

Generalisation of this module for (many types of) creative works: pros, cons, approaches[edit]

I have recently asked @Jarekt to extend the {{Artwork}} template with quite a lot of fields that are relevant for films. See my question on his talk page here. This raises the question: does it make sense to move to a situation where this module, and the {{Artwork}} template in general, are generally applicable to many types of creative works (not just paintings and sculptures / museum objects)? Or would we prefer to have multiple modules and templates for various kinds of works?

I'm thinking of

  • Books and other written works
  • Films
  • Musical works
  • Buildings (with architects etc)
  • ...

From my point of view as an end user, and having worked on building a batch upload tool for Commons (OpenRefine): I like the idea to generalize the {{Artwork}} template because it will make usage of SDC-driven batch upload tools a lot easier. It will allow uploaders to use very simple SDC-driven Wikitext in a lot of use cases. In general, having just one template (or very very few) for many 'creative work' use cases will especially be beneficial to newcomers to Wikimedia Commons. Finding and building a template that is suitable to your needs is not easy. There may be other arguments pro/con.

Thoughts? Spinster (talk) 07:14, 4 November 2022 (UTC)[reply]

Let me just clarify the current state Module:Artwork curently supports {{Artwork}}, {{Art photo}}, {{Book}}, and {{Photograph}} templates. Also more generic sounding {{Object}} template redirects to {{Artwork}}, for files like File:Babbages Analytical Engine, 1834-1871. (9660574685).jpg which does no depict Artwork, but a museum object. The templates {{Artwork}}, {{Book}}, and {{Photograph}} are like alternative skins of Module:Artwork with 99% the same source-code with only some small differences from before module days, and they share all the fields. As a result of this field sharing if you go to any file and replace {{Artwork}} with {{Book}} or {{Photograph}}, that will have very little impact, other then changes in maintenance categories. Another result of field sharing is that if you have an object like archival document that is best described by properties related to museum objects (collection (P195) / inventory number (P217)) and printed matter (publication date (P577) , language of work or name (P407)), than they are both available when pulling info from wikidata or from local template fields. The issue is that documentation of the templates is not keeping up with the templates themselves and {{Artwork}} with {{Book}} or {{Photograph}} are not listing all the fields available but not related to artworks, books or photographs. Full list of the fields can be found in the source-code at Module:Artwork/core.
So going back to Spinster's proposal:
  • "Books and other written works" are already using Module:Artwork,
  • Films: we can add a few additional fields related to films. Do we want to create {{Film}} access template or just use {{Artwork}}?
  • Buildings: we already have available "architect" field. Someone could create {{Building}} access template listing most relevant fields.
  • {{Musical work}} template does not share many fields with Module:Artwork, but we could make it look like {{Art photo}} with 2 infoboxes: one for the file and one for the performed piece.
--Jarekt (talk) 13:19, 4 November 2022 (UTC)[reply]

It seems that the object type field doesn't support wikidata-items[edit]

It seems that the object type field doesn't support wikidata-items in the form of Q-numbers, leading me to use text instead. Can you confirm this observation? I think this would be a great feature to add. Kim Bach (talk) 23:42, 13 January 2023 (UTC)[reply]

If I recall correctly, there is indeed no support for bare Q-IDs. The best way to give something with an item on Wikidata as the object type is to create an item on Wikidata for the object and add the object type as the value of instance of (P31). --Marsupium (talk) 12:03, 16 January 2023 (UTC)[reply]
Thank you, very good suggestions.
I'm only using object types that already have a Q-item, I'll have to double check that they are all instances of P31.
So I'll use something like:
painting, instead of {{en|painting}}
I've noticed that you made changes to one of my articles, I'll use that as a guideline. It will add a new layer of mapping in the code for User:WLKBot, but I'll start working on implementing that, should be straight forward, since I have the Q-numbers available for the mapping I made.
Another thing regarding the User:WLKBot code I had a long discussion on best practices on formatting, I notice that you suggest not using whitespace after the pipe symbol, there was some disagreement during the review process, I'll use your convention, since that makes it 2/3 suggesting that.
Regarding the title, I've already changed the code to use only one title, the National Gallery of Denmark (SMK) informed me that they normally use the first title returned by theie API.
It looked like not all Q-items are supported by the Artwork-template, but are hardcoded in the template, is this observation correct?
I've also noticed that the use of unsupported Q-items for object type adds the article to a category. Is this sufficient? Will the community eventually pick up on this, or can I do something? Kim Bach (talk) 09:21, 17 January 2023 (UTC)[reply]
You're talking about this edit I think.
For the whitespace: On Template:Artwork#Usage it's also like this, without whitespace after the "|".
For the title: "Titus Levius & Lucius Florus, Von Ankunfft und Ursprung dess Römischen Reichs, Straßburg 1574" is obviously not a simple translation of "Romerne indtager Satricum", that's why I've put it under "part of" where I think it fits better
For the object types: All supported values can be found at Module:I18n/objects/data. Pages with unsupported object types are added to Category:Unsupported object. It has a large backlog and I don't think there is a high chance that people take care of those cases anytime soon. So if you don't want to create Wikidata items for the artworks you upload files for, I think the best approach would be to add missing object types that you need to Module:I18n/objects/data. Best, --Marsupium (talk) 11:31, 20 January 2023 (UTC)[reply]
Thank you, I'll take a look at if "part of" is a valid approach. Regarding the object type, I might be able to maintain what looks like a mapping table. I'll give it a shot, I do have the values. Kim Bach (talk) 14:02, 31 January 2023 (UTC)[reply]
I've drafted a version of the object type data table, where I've added the object types I was missing, you can find it here User:Kim_Bach/sandbox/object_type_data.
Since this table is used a lot I'd much appreciate it if you could review it, and maybe help me release it to production. Kim Bach (talk) 17:12, 4 February 2023 (UTC)[reply]

Feature Suggestion[edit]

A recommendation was made by User:EugeneZelenko to add support of wikidata item (Q.....) for "publisher" and "city" parameter, like how you can use Q....... on "author" parameter. The recommendation was made here. However, I do not have the knowledge to editing this module. --Bebiezaza (talk) 11:58, 18 January 2023 (UTC)[reply]

@Bebiezaza: I sort of like that too, however, I wish there was a way to specify multiple values with this nomenclature/syntax. It is not unusual to have multiple authors, etc. Currently my only workaround has been to make Creator templates and substitute them (but that is sort of painful when the party does not even have a category here yet). —Uzume (talk) 18:34, 10 April 2024 (UTC)[reply]
You can use on-the-fly creator templates. Something like {{creator|wikidata=Q12345}}. Does this help? Best, --Marsupium (talk) 16:33, 15 April 2024 (UTC)[reply]

Feature request: Use depicted part (P5961) qualifiers[edit]

It would be nice to display the value of a depicted part (P5961) qualifier of a used depicts (P180) statement in the "Depicted part" field, for example for File:Aspendos - Copy of a silver coin (stater) - c. 380-325 BCE - Archaeological Museum of the University of Münster Inv. MG 46.jpg. Best, --Marsupium (talk) 11:19, 20 January 2023 (UTC)[reply]

Medium / technique[edit]

@Jarekt: I was wondering why user:Trzęsacz added art of painting (Q11629) as a material, see d:User_talk:Trzęsacz#Art_of_painting_is_not_a_material. The medium field here translates to technique in other languages. Translating "oil on canvas" directly to another language gives slightly weird results. It shouldn't be <material> on <material>, but <activity> on <material>. Is that something you can implement in the template logic here? Multichill (talk) 17:50, 5 March 2023 (UTC)[reply]

@Multichill: , The original field for {{Artwork}} was "technique" which only latter was changed to "Medium" while "technique" is still an alias field name. The code behind that field is still {{Technique}} and Module:Technique, so on Commons those 2 terms are used interchangeably. On Wikidata the naming is much more clear made from material (P186) is not ambiguous in English or in Polish (hopefully it is not ambiguous in other languages). Adding actions like "painting" to "material" field makes no sense with English or Polish interface. Template {{Technique}} and Module:Technique got very complicated in last few years and I no longer keep track of what is going on there, but the template allows things like {{technique|painting |on=canvas}} ("painting on canvas"). I do not full understand of what you are proposing on Commons. Can you explain again? --Jarekt (talk) 04:58, 6 March 2023 (UTC)[reply]
@Jarekt: no updating of made from material (P186). That data is quite clean and I don't want to mess it up. Just want to display <activity> on <surface>. So instead of paint on canvas I guess it would be painting on canvas. How to get from the material paint to the activity painting is the tricky part. Also how this will work out in other languages. Multichill (talk) 20:41, 6 March 2023 (UTC)[reply]
Sorry for not really noticing this section until right now. I guess I’m the one having worked most on Wikidata – Commons data matching templating in recent years. I think the answer to the original question is fabrication method (P2079) which should already get picked up by Module:Technique and thus this module automatically. If it doesn’t work in an appropriate way for any example cases you might have please let me know! Thanks in advance, --Marsupium (talk) 01:38, 3 May 2024 (UTC)[reply]

I need help with review and approval of changes to Module:I18n/objects/data[edit]

{{Edit request|ans=yes}} What I'm requesting here is not a direct request to change the Artwork module, but the related object type mapping table. I've also opened a discussion here I need help with review and approval of suggested changes to Module:I18n/objects/data

I still need help with review, and approval, of my suggested changes to the mapping table as drafted here User:Kim_Bach/sandbox/object_type_data.

What I've done is merging the existing table with the missing object type data table with the object types missing, I've also sorted the table.

Until the changes are implemented, I can't release WLKBot. Kim Bach (talk) 07:48, 8 March 2023 (UTC)[reply]

✓ conversation at target talk page. Seems to have been handled at the appropriate talk page.  — billinghurst sDrewth 08:27, 1 April 2024 (UTC)[reply]

That is correct, WLKBot is in production, thank you for picking up on this Kim Bach (talk) 08:55, 6 April 2024 (UTC)[reply]

Feature request: Add more properties to QuickStatement[edit]

@Jarekt: If it isn't too much trouble: Book items created with QuickStatement should have title (P1476) and subtitle (P1680) from parameters "Title" and "Subtitle" when parsed from the {{Book}} template, similar to what we do with the label. It would need to be in the format {{lang|1=Title}} because those properties need a lang code. Thanks in advance! Ignacio Rodríguez (talk) 16:29, 7 March 2024 (UTC)[reply]

Also language of work or name (P407) with info from the "Language" parameter Ignacio Rodríguez (talk) 17:40, 7 March 2024 (UTC)[reply]
Ignacio Rodríguez, good idea. I will look into it. --Jarekt (talk) 04:46, 10 March 2024 (UTC)[reply]
Ignacio Rodríguez, I looked into the logic of the current code Module:Artwork lines 288-325 and I think it supports the title (P1476) QS statements but only from {{Title}} template which specifies what is the primary language, like {{title|lang=...|1=...}}. {{Title}} template with language fields ("en", "es", etc) or templates like {{En}}, {{Es}}, will be converted to QS to add item labels, if missing. I think I encountered files with title field with a few dozen translations of the title and wanted to make sure we have title in the proper language. At the moment I do not support subtitle. --Jarekt (talk) 01:05, 12 March 2024 (UTC)[reply]
@Jarekt Thank you, you are very kind. What about language of work or name (P407). I've seen the parameter |Language= taking {{Language}} so there's no ambiguity Ignacio Rodríguez (talk) 01:29, 12 March 2024 (UTC)[reply]
Ignacio Rodríguez The proper input to the {{Book}}'s |Language= field is iso code not {{Language}} template. It is documented and has been like that for over a decade. I will see if I can make QS work with {{Language}} template, but another way would be to just fix the files misusing it. --Jarekt (talk) 02:16, 12 March 2024 (UTC)[reply]

change paramater tag of institution[edit]

Module:Artwork/core code line 224 

{field='institution'          , id='fileinfotpl_art_gallery'               , tag='Q2668072',                              demo=art+photo,      wrapper='%s'},

@Jarekt: Referring to the description of the wikidata, collection (P195) is a more suitable tag than collection (Q2668072). I speak Korean as my native language, and I request this work for proper internationalization in the Template. Thank you for maintaining the code.--이강철 (WMKR) (talk) 10:13, 30 April 2024 (UTC)[reply]

✓ Done 이강철 (WMKR) Thanks for helping. In languages I speak both tags were fine. Please let me know if other spots in any templates of modules could be improved for Korean speakers. Examples: Module:I18n/complex date, Data:DateI18n.tab, Module:I18n/institution, etc. --Jarekt (talk) 13:21, 30 April 2024 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Module_talk:Artwork&oldid=873258367"