Property talk:P18

From Wikidata
Jump to navigation Jump to search


image of relevant illustration of the subject; if available, also use more specific properties (sample: coat of arms image, locator map, flag image, signature image, logo image, collage image)
Representsillustration (Q178659), image (Q478798)
Has qualitycurated Wikidata property (Q121928698)
Data typeCommons media file
DomainMost Items (note: this should be moved to the property statements)
Allowed values(?i).+\.(jpg|jpeg|jpe|png|svg|tif|tiff|gif|xcf|pdf|djvu|webp)|(?i)((?!\b(1x1|none|image is needed|no free image|defaul?t\b|comic image missing|Grey30 line|Image-request|no portrait|no (female|free|male) portrait|replace this image|upload free image|No-station-image|Taxoimagem|No free image|no image|Insert image here|falta imagen|no imagen disponible|sin foto\.|NGC 000\.|missing image text|irudi gabe eraikina|image manquante|Oeuvre d'art soumise au droit d'auteur\.jpg|Bâtiment droit d'auteur|USGS map|within Bulgaria|P vip|no pic)\b).)*(?i).+((?!\b(icon|pictogram)\b).)*(?i)((?!\b(collage|Коллаж)\b).)*(?i)((?!\b(map|карта|地図)\b).)*(?i)((?!\b(localisation|location|locator)\b).)*(?i)((?!\b(seal)\b).)*(?i)((?!\b(signature)\b).)*(?i)((?!\b(logo|лого)\b).)*(?i)^(?!gthumb\.).*(?i)((?!\b(diagram)\b).)*
Usage notesImages should be exemplary: representative, unambiguous, and high quality. Images for a single person or object should generally include only the focal subject. If relevant, also use more specific properties (e.g. coat of arms image, locator map, flag image, signature image, logo image, collage image)
ExampleDouglas Adams (Q42)Douglas adams portrait cropped.jpg
Parthenon (Q10288)The Parthenon in Athens.jpg
mountain bike (Q223705)Marin bike.jpg
Cymothoe sangaris (Q5199845)Afrique centrale - Cymothoe sangaris.jpg
San Francisco (Q62)San Francisco from the Marin Headlands in March 2019.jpg
Formatter URL$1
Embed URL$1
Robot and gadget jobsDeltaBot does the following jobs:
Tracking: sameCategory:Local image same as Wikidata (Q16742292)
Tracking: differencesCategory:Local image different from Wikidata (Q16742291)
Tracking: usageCategory:Pages using Wikidata property P18 (Q15907809)
Tracking: local no, WD yesCategory:No local image but image on Wikidata (Q16742293)
Tracking: local yes, WD noCategory:Local image but no image on Wikidata (Q16742294)
Tracking: local no, WD noCategory:No local image and no image on Wikidata (Q16742295)
See alsologo image (P154), coat of arms image (P94), seal image (P158), flag image (P41), plaque image (P1801), place name sign (P1766), monogram (P1543), image of grave (P1442), astronomic symbol image (P367), signature (P109), traffic sign (P14), collage image (P2716), sectional view (P2713), icon (P2910), media legend (P2096), nighttime view (P3451), panoramic view (P4291), photosphere image (P4640), document file on Wikimedia Commons (P996), winter view (P5252), image of interior (P5775), image of design plans (P3311), film poster (P3383), name (image) (P7407), code (image) (P7415), related image (P6802), view (P8517), twin town sign (P8667), aerial view (P8592), image of backside (P7417), page banner (P948), non-free artwork image URL (P6500), image with color chart (P10093), reference image (P10253), image set (P10696), locator map image (P242), detail map (P1621), relief location map (P1944), location map (P1943), item for this sense (P5137), model image (P11101), image of frontside (P7418), language of work or name (P407)
  • List of Wikipedia articles without an image where Wikidata has one
  • Same image used for several people
  • Items with no other statements
  • Most recently created items
  • Items with novalue claims
  • Items with unknown value claims
  • Usage history (total)
  • Database reports/Complex constraint violations/P18
  • Database reports/Constraint violations/P18
  • Map
  • Random list
  • Proposal discussionProposal discussion
    Current uses
    Main statement5,088,668>99.9% of uses
    Qualifier3,950<0.1% of uses
    Reference341<0.1% of uses
    [create Create a translatable help page (preferably in English) for this property to be included here]
    Format “(?i).+\.(jpg|jpeg|jpe|png|svg|tif|tiff|gif|xcf|pdf|djvu|webp)|: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Format “(?i)((?!\b(1x1|none|image is needed|no free image|defaul?t\b|comic image missing|Grey30 line|Image-request|no portrait|no (female|free|male) portrait|replace this image|upload free image|No-station-image|Taxoimagem|No free image|no image|Insert image here|falta imagen|no imagen disponible|sin foto\.|NGC 000\.|missing image text|irudi gabe eraikina|image manquante|Oeuvre d'art soumise au droit d'auteur\.jpg|Bâtiment droit d'auteur|USGS map|within Bulgaria|P vip|no pic)\b).)*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: MODX (Q74452), None (Q9512), Apache HTTP Server (Q11354), Lubuntu (Q39238), dpkg (Q305892)
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Format “(?i).+((?!\b(icon|pictogram)\b).)*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Format “(?i)((?!\b(collage|Коллаж)\b).)*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Qualifiers “point in time (P585), media legend (P2096), depicts (P180), quotation (P1683), language of work or name (P407), aspect ratio (W:H) (P2061), scale (P1752), location (P276), coordinate location (P625), located in the administrative territorial entity (P131), location of the point of view (P7108), coordinates of the point of view (P1259), author (P50), author name string (P2093), creator (P170), publisher (P123), published in (P1433), section, verse, paragraph, or clause (P958), object has role (P3831), subject has role (P2868), identity of object in context (P4626), identity of subject in context (P4649), identified in image by (P7380), object named as (P1932), statement is subject of (P805), statement supported by (P3680), statement disputed by (P1310), nature of statement (P5102), has quality (P1552), does not have quality (P6477), sex or gender (P21), age of subject at event (P3629), start time (P580), end time (P582), refine date (P4241), earliest date (P1319), latest start date (P8555), earliest end date (P8554), latest date (P1326), sourcing circumstances (P1480), determination method (P459), software version identifier (P348), copyright status (P6216), applies to jurisdiction (P1001), applies to part (P518), collection (P195), series ordinal (P1545), number of reviews/ratings (P7887), URL (P2699), archive URL (P1065), archive date (P2960), reason for deprecated rank (P2241), reason for preferred rank (P7452), non-free artwork image URL (P6500), copyright license (P275), start of covered period (P7103), end of covered period (P7104), depicted by (P1299), together with (P1706), typeface/font used (P2739), located in statistical territorial entity (P8138), end cause (P1534), applies to work (P10663), subject form (P5830), for color scheme (P8798), object sense (P5980), Mapillary ID (P1947), publication date (P577): this property should be used only with the listed qualifiers. (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#allowed qualifiers, SPARQL
    Format “(?i)((?!\b(map|карта|地図)\b).)*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: map pin (Q106390902), map pin (Q109717625)
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Format “(?i)((?!\b(localisation|location|locator)\b).)*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Format “(?i)((?!\b(seal)\b).)*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Q218091, Q5503136, Q2586715, Q17004810, Q336665, Q30263, Q27370, Q26913, Q466597, Q593039, Q4535, Q928785, Q215343, Q186663, Q7966, Q1475577, Q217189, Q47701711, Q214287, Q30087611, Q626023, Q203208, Q2548925, Q1195660, Q2442828, Q20967694, Q326239, Q1502014, Q832379, Q1051110, Q1403341, Q25587, Q302780, Q3179900, Q3159401, Q571449, Q92063131, Q313166, Q15138174
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Format “(?i)((?!\b(signature)\b).)*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Q155234, Q287218, Q27714177, Q105702434, Q1142562, Q220849, Q869548, Q80858984, Q741810, Q3960359, Q17019141, Q7512804, Q7512808, Q98000654, Q14338378, Q7512811, Q7512806, Q109621185, Q3483643, Q1224829, Q117084939
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Format “(?i)((?!\b(logo|лого)\b).)*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Format “(?i)^(?!gthumb\.).*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Link to Commons namespace “File”: this property should contain a well-formed link to an existing page on Wikimedia Commons. (Help)
    List of violations of this constraint: Database reports/Constraint violations/P18#Commons link, hourly updated report
    Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)
    List of violations of this constraint: Database reports/Constraint violations/P18#Scope, hourly updated report, SPARQL
    Allowed entity types are Wikibase item (Q29934200), Wikibase lexeme (Q51885771), Wikibase sense (Q54285715), Wikibase property (Q29934218): the property may only be used on a certain entity type (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#Entity types
    Format “(?i)((?!\b(diagram)\b).)*: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#Format, SPARQL
    Single best value: this property generally contains a single value. If there are several, one would have preferred rank (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P18#single best value, SPARQL
    Shared images within single item
    Multiple properties using same image as value (Help)
    Violations query: SELECT DISTINCT ?item WHERE { ?prop1 wikibase:propertyType wikibase:CommonsMedia; wikibase:directClaim ?wdt . ?item ?wdt ?value . ?prop2 wikibase:propertyType wikibase:CommonsMedia . FILTER(?prop1 != ?prop2) . ?prop2 wikibase:directClaim ?wdt2 . ?item ?wdt2 ?value } LIMIT 2500
    List of this constraint violations: Database reports/Complex constraint violations/P18#Shared images within single item
    Pattern ^((?i).+\.(webm|ogv))$ will be automatically replaced to \1 and moved to video (P10) property.
    Testing: TODO list
    Pattern ^((?i).+\.(ogg|wav|oga|mid|flac|opus|mp3))$ will be automatically replaced to \1 and moved to audio (P51) property.
    Testing: TODO list
    Pattern ^((?i).+Municipality Within Bulgaria\..+)$ will be automatically replaced to \1 and moved to locator map image (P242) property.
    Testing: TODO list
    This property is being used by:

    Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)


    How many images?[edit]

    How many images we should add to one item? I saw that some of the items contains many images, but I think that they should not contain many images. --Stryn (talk) 10:18, 18 February 2013 (UTC)Reply[reply]

    Example: Maria Sharapova (Q11666), 10 pictures. I thought Commons is a gallery... --Stryn (talk) 14:10, 28 May 2013 (UTC)Reply[reply]
    I believe that, when a Commons category (P373) is available, we should avoid adding image (P18), so a Lua module could automatically choose the best image by framing, size, background, etc. (maybe with priority to Featured Pictures). --Ricordisamoa 23:40, 6 June 2013 (UTC)Reply[reply]
    Currently Commons category (P373) has too many invalid values. — Ivan A. Krestinin (talk) 04:08, 7 June 2013 (UTC)Reply[reply]
    Please always have an image property, even if a Commons property exists. Theoretically you could get a random image from Commons, but no serious tool would ever do that, because you have 50% chances that the image is of bad quality, 10% chances that the image is misclassified, 0.1% that it is a dick pic. Add the cost of additional network requests, the hassle of developing it (many companies reusing Wikidata database dumps have zero experience with wiki software), and you understand that all items need one image, ready-to use. Syced (talk) 02:56, 29 August 2016 (UTC)Reply[reply]
    +1. And please don't import low quality pictures with wdfist while there are already better ones at Commons.--Kopiersperre (talk) 06:10, 29 August 2016 (UTC)Reply[reply]
    Now we have "single value" constraint, so we have about 1900 violations of that. We should decide it these cases are appropriate. --Infovarius (talk) 11:11, 17 January 2014 (UTC)Reply[reply]
    Currently the property is used in many ruwiki templates. Its fail if property contains multiple values. If we want to fix the templates then we need algorithm for the best image selection. The algorithm is not trivial, this is complex computer vision task. So I suggest to leave the constraint and clean up ambiguous images. — Ivan A. Krestinin (talk) 18:45, 17 January 2014 (UTC)Reply[reply]

    Stil is still not solved (as far as I know). My take on this is that you are fine to have more than one image for one item as long as:

    Any thoughts on this?
    --D-Kuru (talk) 10:59, 14 November 2020 (UTC)Reply[reply]

    more specific properties should be used when more description is required[edit]

    How about some consensus on which properties to use as qualifiers?


    • use point in time (P585) to indicate the date a photo was captured (can be sourced by bots on commons)
    • use depicts (P180) to indicate that the photo depicts another related item (such as a character featured in a book, where the book is the main subject)
    • use applies to part (P518) to indicate which part (item) of the subject is shown (e.g. applies to part (P518) = roof (Q83180) photo of the subject building's roof)
    • use instance of (P31) to indicate that the image is a painting, a panoramic photo, a photo, an aerial photo, collage, etc.
    • any others?

    depicts (P180) and applies to part (P518) seem to be similar, perhaps we should use depicts (P180) only? Danrok (talk) 17:11, 1 September 2013 (UTC)Reply[reply]

    Hi Danrok,
    I’ve just pictures on Rennes City Hall (Q532811) and Palace of the Parlement of Brittany (Q2351981). I didn’t read this page before so I used applies to part (P518) to indicate that the pictures represent façade (Q183061). I wasn’t sure what qualifiers to use so I came here.
    Now I’ve read this and I’m a bit puzzled. What is the difference beetwen depicts (P180) and applies to part (P518) ? You said « depicts another related item » but a picture never show the whole item (and if the picture depicted the whole item, the qualifier wouldn’t be needed ), it always a part of the item which can be understood as « another related item » (and which can be a Wikidata item itself).
    Cdlt, VIGNERON (talk) 16:25, 2 September 2014 (UTC)Reply[reply]


    Should all commons media items be an item in wikidata, so as to avoid making the same claims over and over for the same photo within each item where it is used? Danrok (talk) 17:14, 1 September 2013 (UTC)Reply[reply]

    It seems a good idea, I feel like we’re adding over and over the same claims to differents items. Cdlt, VIGNERON (talk) 16:25, 2 September 2014 (UTC)Reply[reply]

    How can we consume this in Infoboxes ?[edit]

    Given that the image might change at any point and that we also have a caption, is there a way to store the caption per language within the image ? Is there a per-article way to store it ? --Teolemon (talk) 10:53, 9 November 2013 (UTC)Reply[reply]

    Users of the data would be able to pull the caption(s) from directly from articles without too much work, if they need them. Also, it's possible that wikidata might support Commons images as data items in the future, see here; Wikidata:Development_plan#Wikimedia_Commons

    Property to use when indicating that an image is from a scholarly article[edit]

    I just tried to add a source for an image listed in Scorpaena grandicornis (Q2197411) but am not sure that part of (P361) was the appropriate choice, nor did I find guidelines. Pointers appreciated. --Daniel Mietchen (talk) 10:10, 18 January 2014 (UTC)Reply[reply]

    I'd suggest leaving it until some development for Commons has been done, see Wikidata:Development_plan#Wikimedia_Commons. Danrok (talk) 18:08, 30 January 2014 (UTC)Reply[reply]

    Language-specific caption[edit]

    In ru-wiki image in infobox can have an additional caption, that explains who created the image (author of painting, for example), where it was taken or stored, dates, etc. How can we store that infromation in wikidata? -- Vlsergey (talk) 08:54, 29 January 2014 (UTC)Reply[reply]

    Came here with the same question and the answer is media legend (P2096). --Lockal (talk) 07:36, 10 January 2017 (UTC)Reply[reply]

    Notes for botmasters[edit]

    Hi, I try to summarise common errors during this property import. There are some cases then image must not be imported:

    1. Image does not exists on Commons (the image can be local or deleted).
    2. Image is located in commons:Category:Image placeholders or its subcategory.
    3. Item contain some another property with this file. Current image properties list: video (P10), route map (P15), logo image (P154), taxon range map image (P181), seal image (P158), bathymetry image (P207), signature (P109), astronomic symbol image (P367), Sandbox-CommonsMediaFile (P368), pronunciation audio (P443), coat of arms image (P94), locator map image (P242), chemical structure (P117), flag image (P41), traffic sign (P14), orbit diagram (P491), audio (P51), Gene Atlas Image (P692), page banner (P948), spoken text audio (P989), audio recording of the subject's spoken voice (P990), document file on Wikimedia Commons (P996).
    4. Item has instance of (P31) = human (Q5) and file format is SVG. There are few exceptions: Zweeloo Woman scheme.svg, Vladimir Ivanov.svg, Veronica Lario.svg, Kumaranasan.svg, Arkadi Rozengoltz.svg, Robert Livingston Stevens.svg, Ritrat ad Rainer Werner Fassbinder SW.svg, Spartak 176.56.svg

    Please use these checks in your bots. And extend this list if you know some more cases. — Ivan A. Krestinin (talk) 11:32, 13 June 2014 (UTC)Reply[reply]

    Hi Ivan, I numbered your point to make it easier to refer to them. 1 shouldn't happen with, if you find an example with a pywikibot based bot I would like to see it. 2 shouldn't show up as an image in the extension. Do you have an example item with page? Does the page have that image as a property? The extension the bot relies on filters out small and placeholder images. For 3 the bot should be updated. I think 4 is caught by the same code as 2. Multichill (talk) 20:28, 15 June 2014 (UTC)Reply[reply]
    1. One bot made this mistake two days ago. Pywiki is not the only used framework on Wikidata. 2. [1]. — Ivan A. Krestinin (talk) 20:49, 15 June 2014 (UTC)Reply[reply]

    Images for people - new type : "grave"[edit]

    Considering the very important number of images of people's grave, I would suggest to add a type of image (for people), to indicate that the picture is representing the grave or tombstone, not the actual person (or portrait)... --Hsarrazin (talk) 21:05, 13 July 2014 (UTC)Reply[reply]

    Database or datahell?[edit]

    Some examples:

    Tainan 103 images including ,
    Malawi 60 images including ,
    Zakarpattia Oblast 43 images including ,

    Looks like P18 is on the way to unstructured image collection. Commons galleries and categories are structured more better. Are we need images with unspecified relation between item`s object? Are we need so many images per item? Suggestions: 1. Change description of the property from "any related image" to "image of the object". 2. Clean all images except one by bot (excluding images with qualifiers maybe). — Ivan A. Krestinin (talk) 10:17, 18 August 2014 (UTC)Reply[reply]

    @Ivan A. Krestinin: see Wikidata:Project_chat/Archive/2014/08#new "game"? problems with adding of multiple images (P18)Magnus already added a "warning" to the game where such additions come from (since then i didn't see newer edits like these, at least not more than 5 or 6 images).
    If you see something again, please revert (or otherwise reduce to 1 image) and notify the user who added the mess (like [2] or [3]). If you see newer edits like these (made after today), i think it would be helpful if you could leave a notice at the forum, so others are also aware of the problem. Holger1959 (talk) 10:33, 18 August 2014 (UTC)Reply[reply]
    It's not necessarily the game though; several of my tools use the WiDaR "bridge". Mass edits could also be from here. In the end, these tools give users great power, and with... --Magnus Manske (talk) 15:59, 18 August 2014 (UTC)Reply[reply] etc. progress[edit]

    The script by Multichill looks very nice, what's the progress in running it? Is it only run upon request for specific wikis?

    I'd like to import some more images where missing, especially as they can then be used for image addition campaigns like Taketa's on multiple wikis, to increase consistency. The first data source I'd like to use is the commons:Category:Images_from_Wiki_Loves_Monuments_in_Italy in conjunction with WMIT's monument database. WLM images are often too hard to add to articles, with current tools. --Nemo 08:54, 2 April 2015 (UTC)Reply[reply]

    User:Multichill's script only works if the images are already in WP. Importing images from commons:Category:Images_from_Wiki_Loves_Monuments_in_Italy could only work if the images have a template with the monument identifier. But in that case one need first to create an Italian monument identifier property. --Pasleim (talk) 08:29, 26 April 2015 (UTC)Reply[reply]

    Use of preferred rank in the instructions for image && a check for violations[edit]

    Would someone please consider how we can look to provide guidance on the use of "preferred" and "normal" rank for images. For infoboxes to work, we need to encourage that the best (personal opinion) image should be selected as the preferred image of an item, otherwise we get double choice and infoboxes fail.

    Similarly, would it be possible to put in place a compliance check to see that where there are multiple images that one is marked as preferred, and to note that we also only want one, so a reverse check for only one preferred is also required.  — billinghurst sDrewth 05:09, 5 January 2016 (UTC)Reply[reply]

    The discussion above seems to indicate that each item should have only one image. This makes sense, since Wikidata is not Commons. --Srittau (talk) 05:49, 5 January 2016 (UTC)Reply[reply]
    Infoboxes should attempt to select the one image (this can be done in LUA). Multiple images generally use qualifiers to define the year.
    --- Jura 06:24, 5 January 2016 (UTC)Reply[reply]

    Unique value constraint?[edit]

    There have been some discussion about it in the past here and on the Project chat. Should we add a unique value constraint on this property? I think this property would be most useful to provide one image that represents the subject best. This is basically the image that you would put on the top of a page or in a list like Special:Nearby. Having multiple images listed here is not only something that would be best left to Commons galleries (even if they are mostly defunct at the moment), it would also defeat the purpose of having one well-defined image for automatic display. --Srittau (talk) 12:14, 9 January 2016 (UTC)Reply[reply]

    What prevents you from selecting the first or preferred one?
    --- Jura 12:39, 9 January 2016 (UTC)Reply[reply]
    There is no "first" value. What is the use of duplicating Commons categories in this property? --Srittau (talk) 15:45, 9 January 2016 (UTC)Reply[reply]
    We are adding properties with Commons files as Commons can't supply images in a structured way. Do you have a sample of the problem you are trying to solve?
    --- Jura 16:29, 9 January 2016 (UTC)Reply[reply]
    The problem is that currently a renderer that wants to display an image has to pick one. There is no way to pick the same one consistenly, or the pick the most appropriate one, since there is no appropriate image. Commons does supply images in a more structured way than just adding lots of images to an item, which is what people are doing here. In the future, structured data on Commons will even improve on this. Which problem are you trying to solve by having multiple images on an item? --Srittau (talk) 16:27, 13 January 2016 (UTC)Reply[reply]
    @Jura1: Hi, where is the discussion regarding removing the unique value constraint (diff)? Surely we can add checks in Lua for qualifiers or other stuff, but in this way we are adding complexity to a property that was very easy to use before. Please re-add unique value constraint. --Rotpunkt (talk) 11:55, 29 January 2016 (UTC)Reply[reply]
    It's a misleading constraint. If you read the comment above, you will notice that new editors or editors that don't contribute in building the image database tend to think that it only allows for one image while it just required users to add qualifiers. If there is something broken in an infobox or elsewhere, it needs to be fixed there. Obviously, one shouldn't add as many images on self-portrait of Van Gogh. From the comments by Srittau, it appears that Commons will provide you what you are seeking, so you might want to check there instead.
    --- Jura 13:11, 29 January 2016 (UTC)Reply[reply]
    @Jura1: No, I disagree. (1) Where is the discussion about your unique value constraint removal (diff)? This property has the unique value constraint from 2013 and after two years you remove it, when all of us are used to have just 1 single image (2) looking for qualifiers is not the standard way users are used to with P18 (3) << Commons will provide you what you are seeking >> what does it mean? AFAIK now I have only P18 for infoboxes. --Rotpunkt (talk) 13:29, 29 January 2016 (UTC)Reply[reply]
    Please re-add unique constraint. 99% of the applications that use Wikidata data use only one image. Allowing more images is wasting contributor's time, and making the first image less representative. Syced (talk) 08:10, 18 April 2016 (UTC)Reply[reply]

    ✓ Done Restored the single(!) value constraint per this discussion. --Srittau (talk) 10:51, 19 April 2016 (UTC)Reply[reply]

    • @Syced: the constraint doesn't ensure that there is only one image and it shouldn't really have an impact on contributor's time. Would you have a diff where this actually made an impact on contributor's time?
      --- Jura 11:25, 19 April 2016 (UTC)Reply[reply]
    I don't have a diff, but I can easily imagine an overly enthusiastic contributor wasting their time finding several images showing different aspects of an item. Maybe I am overthinking this though so do as you want :-) Syced (talk) 01:17, 20 April 2016 (UTC)Reply[reply]

    I'm late to discussion. Multiple images are used as collages: Tainan City's cover.jpg or TE-Collage Ursus.png

    1. Some Wikidata items correspond to multiple (many) objects, therefore it is meaningful to use several items (up to 10) with subjective "proffered ranks".
    2. Another use of multiple images is to show how objects are different across the globe, but serve the same function or correspond to the same "Wikidata item".
      • For example, how could we describe the same or different models of cars without pictures? It would be overly wordy.
      • 1 image for "Knife" is more than enough, but if an item corresponds to extinct object, more Images would be helpful to identify object (or corresponding Wikidata item).
      • In second case images from P18 can be moved in has use (P366) section as qualifiers (or in other sections as qualifiers). d1g (talk) 15:02, 21 April 2017 (UTC)Reply[reply]
    • If multiple images are permitted, then we may as well add every image from the related Commons category. Presumably they all show slightly different aspects of the item, so they are useful. If such use of multiple images is not desired, put the single value constraint back (I support the latter). Ghouston (talk) 22:12, 5 August 2018 (UTC)Reply[reply]

    Single value vs. unique value[edit]

    I think you mix this up. One picture can be good enough to be the picture on different WD obejcts

    I restored the change from @Nvrandow:

    - Salgo60 (talk) 17:06, 24 August 2018 (UTC)Reply[reply]

    • I agree with Salgo60 and others. Unique value constraint isn't right for this property. Single value constraint is fine if we decide to restrict the depiction of each item to one picture. Deryck Chan (talk) 11:19, 27 August 2018 (UTC)Reply[reply]


    Is ist possible to save (and read) the orientation (portrait/landscape) of the image? Would be useful, because our module uses it for infoboxes. So i can change the size if necessary. -- DerFussi 12:20, 13 January 2016 (UTC)Reply[reply]

    @DerFussi: You have probably found a solution in the meantime, still, for other's reference as a similar question came up below: Take a look at mw:Extension:Scribunto/Lua reference manual#File metadata. --Marsupium (talk) 04:45, 3 November 2018 (UTC)Reply[reply]
    @Marsupium: Many thanks for the link. -- DerFussi 13:44, 24 August 2019 (UTC)Reply[reply]

    images of colletive items[edit]

    I had the doubt with d:Q3908225 but it is the same with every item of a "collective" concept such as "history of ...", "churches of ...", "list of airports of...". Some of these items are lists, some of thm aren't but still it is almost impossible to have a collective image for them.

    It is a strange thing because even a precise item (a person, a building, even a town) can have tons of possible images to describe it, but it is clear that in that case a selection is possible. For a town I try to use to biggest panoramic picture available, for example, but still I can have my own idea.

    For a vague or collective item it becomes instead weird to chose. You can solve it with a collage of picures if it available, I guess. In any case I have a feeling something is missing, that we should write some guideline. I don't want to say to newbies "just skip it"--Alexmar983 (talk) 17:45, 20 February 2016 (UTC)Reply[reply]

    How about not allowing image (P18) for instances of Wikimedia list article (Q13406463). Bridges of Pisa (Q3908225) should somehow link to bridge (Q12280), which has an image (P18). What do you think about this? Syced (talk) 10:57, 17 May 2017 (UTC)Reply[reply]

    Image quality[edit]

    Which quality images should have to be placed at P18? What about excluding images tagged at Commons with Low quality? And what about pictures showing not an individual, but a group of people?--Kopiersperre (talk) 19:41, 9 April 2016 (UTC)Reply[reply]

    A low quality image is acceptable is there is no better picture available, I would say. For instance an item about an event that happened a century ago. Syced (talk) 08:07, 18 April 2016 (UTC)Reply[reply]
    Same from my point of view. Low quality picture is still better than no picture. Also for picture of groups, it is still better than no picture. For group situations there is a nice template on Commons - c:Template:Crop for Wikidata. --Jklamo (talk) 11:08, 19 April 2016 (UTC)Reply[reply]
    • Low quality images aren't ideal, but if there is nothing else to add ..
      Personally I avoid group images unless it's fairly easy to determine who is the person (e.g. a female in a group of males). I'm not much into cropping ..
      --- Jura 11:27, 19 April 2016 (UTC)Reply[reply]

    Destroyed building: Is a picture of the current place nowadays OK?[edit]

    Many former buildings don't have a picture because they disappeared before any wikicommonist thought about taking a picture.

    In such cases, is it OK to put an image of whatever happens to be at that place nowadays?

    For instance, a castle used to stand here but now it is a lawn, or a hotel.

    Thanks! Syced (talk) 07:53, 19 April 2016 (UTC)Reply[reply]

    My opinion: Yes it is OK as it is better than nothing, but obviously any depiction of the real thing would be better, even if low quality. Syced (talk) 07:53, 19 April 2016 (UTC)Reply[reply]
    Personally, I don't like this, because this would give the impression that the depicted place is actually the building. On the other hand, I don't think it provides much information about the item. --Srittau (talk) 10:48, 19 April 2016 (UTC)Reply[reply]
    • Drawings should still be possible. I think we should avoid pictures of other buildings, maybe images of ruins or a lawn?
      --- Jura 11:31, 19 April 2016 (UTC)Reply[reply]
    • IMHO it's absolute bullshit to place the image of the successor for a demolished building. If any software uses data from P18, how should it determine whether the image is from the object or just from a related object?--Kopiersperre (talk) 15:01, 19 April 2016 (UTC)Reply[reply]
    • Successor building or bare lawn sounds unacceptable for me, but ruins or at least outlines in lawn sounds acceptable for me (unless we do not have better picture). --Jklamo (talk) 22:33, 19 April 2016 (UTC)Reply[reply]
    Understood, thanks for the insight! :-) Syced (talk) 01:18, 20 April 2016 (UTC)Reply[reply]


    I would like to open a question of plaque relevance as P18. I am sure that plaques like this are not relevant illustration and thus are not suitable to be added as P18, but what about plaques like that? These plaque images seems to be relevant to me and suitable to be added as P18. --Jklamo (talk) 18:50, 7 September 2016 (UTC)Reply[reply]

    There is plaque image (P1801) for both. The 2nd image, I'd add it also to P18 (unless there is some other available).
    --- Jura 19:01, 7 September 2016 (UTC)Reply[reply]

    Is there any way to link to an image on some Wikipedia?[edit]

    I was trying to add logo image (P154) to a few institutions but soon realized that most logos I could find on Wikipedia were not on Commons because of license issues. These images are on Wikipedia as fair uses - can't we link to them from Wikidata by the same token? Is there any way to do this? Thanks! − Pintoch (talk) 05:03, 29 November 2016 (UTC)Reply[reply]

    This property clearly says only Commons links are OK, so I am afraid it is not possible now :-/ Syced (talk) 08:33, 17 May 2017 (UTC)Reply[reply]
    A core of the idea of Wikidata is that our data get's reused. It's not easy to know whether fair-use applies to a given reuse of data and therefore we stay with the images from commons. ChristianKl (talk) 13:40, 19 May 2017 (UTC)Reply[reply]
    My guess: waiting for m:NonFreeWiki, which can provide a centralized non-free file repository. --Liuxinyu970226 (talk) 05:05, 6 September 2017 (UTC)Reply[reply]

    Add derivatives to the property?[edit]

    Is there a technical solution to add derivatives to the property? In Arabic wikipedia, we invoke a lot of infobox properties. Some times the problem is that there is a translated Arabic derivative of the picture (see example). The problem is that we lose that information when we invoke from Wikidata. The ideal situation would be to add a list of derivatives by language.--Helmoony (talk) 01:55, 8 August 2017 (UTC)Reply[reply]

    You can add a qualifier to specify the language. P18 isn't limited to English/enwiki
    --- Jura 06:14, 6 September 2017 (UTC)Reply[reply]

    Images on template items[edit]

    Currently this property is heavily used on items about templates, e.g. Template:Cheese-stub (Q5613054), despite the conficts-with constraint. Should we drop the constraint or remove the statements? --Pasleim (talk) 15:30, 31 August 2017 (UTC)Reply[reply]

    • Are they actually used or is this some failed import operation? The positive thing about it is that these images get excluded from wdfist suggestions.
      --- Jura 06:16, 6 September 2017 (UTC)Reply[reply]

    For montages please use collage image (P2716)[edit]

    Collages have their own property: collage image (P2716)

    Please add collages to this property, as image (P18) is often used in small sizes at which collages are totally unreadable.

    Similarly, if you write an infobox and prefer collages, please make the infobox call collage image (P2716) and only use image (P18) as a fallback if no collage is available.

    Archived discussion:

    Thanks! Syced (talk) 08:47, 16 September 2017 (UTC)Reply[reply]

    Request to blacklist placeholders[edit]

    • P vip.svg
    • Importez le logo individu-fr.svg

    Teolemon (talk) 11:19, 1 October 2017 (UTC)Reply[reply]

    I'm not an admin yet, unfortunately. Teolemon (talk) 12:15, 1 October 2017 (UTC)Reply[reply]

    @Ivan A. Krestinin: cat added for the first one, the second one is already in a subcat.
    @Teolemon: no need to be a admin to add a category.
    Cdlt, VIGNERON (talk) 18:27, 16 October 2017 (UTC)Reply[reply]

    Who decides which image is to be used?[edit]

    If only one image is to be used to represent a concept (I am interpreting the discussion at the top of this page to mean that is the case), who decides which image is best for the purpose, and what happens if someone disagrees and changes it? For example: If I choose an image to illustrate Scuba diving on English Wikipedia, and link to it as the image property, and someone from German Wikipedia decides that a different image is most suitable for German Wikipedia, can they change the image? If I decide that a different image is better, as it recently became available, and change the lead image on EN:WP, should I also change it on Wikidata? If an IP editor finds a better image on commons, can they decide to change it on WD?

    For the time being, it is not in any way regulated. Usually, if there is no image in an item somebody just adds an image. However, sometimes user aggressively push their own images and even edit-war over this.Pretty much the same as in Wikipedia, with the difference that here the vast majority of the items only have one image.--Ymblanter (talk) 16:24, 11 December 2017 (UTC)Reply[reply]
    I agree. It should be a bit like choosing image for the infobox in Wikipedia article: people should come to consensus on the talk page. Also, I hate arguing with people pushing their own images, as they often do not seem to be very objective and if you point out some shortcoming of the image then they get defensive. So if you think your photograph is the best to illustrate something and others think other (not their) photographs are better than I would urge people to recuse themselves from making that call. --Jarekt (talk) 13:15, 4 January 2018 (UTC)Reply[reply]

    Use in Book articles[edit]

    In case of book articles image (P18) seems to be often used to store PDF or DjVu files with the book itself. See With Fire and Sword (Q927292) or Mademoiselle Fifi (Q3275889). Shall we keep it in P18 or should we create some more specialized property?--Jarekt (talk) 13:33, 4 January 2018 (UTC)Reply[reply]

    Constraint required to set preferred image[edit]

    It would be really useful if we were able to indicate that where there are multiple images that one is to be set as preferred, and similarly to indicate where it is not set that it is reported. If the wikis are pulling one of the images back to display, then having a preferred/better/... image set would be useful.  — billinghurst sDrewth 07:32, 20 January 2018 (UTC)Reply[reply]

    Images as reference[edit]

    Currently there exists a "used for values only constraint" for this property. But (Commons) images can also be legitimate references for Wikimedia projects and therefore also for Wikidata items. I just created an item (Franz London (Q52157989)) for a mathematician of whom the exact dates of birth and death can maybe only be found on his gravestone (commons:File:Grabstein von Franz London, Bergfriedhof Kessenich.jpg). So what would be the right way to insert this as reference? The only other property that comes into question seems to be Wikimedia import URL (P4656). But the property description states that Wikimedia projects (e.g. Wikisource) can be actual references, so why shouldn't Commons images be as well?--Leit (talk) 14:58, 24 April 2018 (UTC)Reply[reply]

    Thanks. So I guess images of information boards and architectural dates (I haven't found a Wikidata item for both yet) could be used as reference the same way? However, I think images of an item object (e.g. a building) itself can at least on rare occasions be a reference. I think of sculptures that have been stolen or destroyed at an unknown point in time so a specific image of the object (and/or of the former location of it) is sometimes the only proof of the end time (P582) of the existence or physical location of the sculpture. Probably type of reference (P3865) could be applied in this case as well, simply with the value image (Q478798).--Leit (talk) 21:02, 24 April 2018 (UTC)Reply[reply]

    Allowed qualifiers constraint[edit]

    Ivan A. Krestinin has added an allowed qualifiers constraint property with the only allowed value as "point in time". I am also adding "media legend" as allowed qualifier, since I have used it hundreds of times. What else is valid? - PKM (talk) 01:45, 18 July 2018 (UTC)Reply[reply]

    I saw sex or gender (P21) (for animals). Matěj Suchánek (talk) 07:55, 18 July 2018 (UTC)Reply[reply]
    @PKM: I propose language of work or name (P407) to identify the language in schemes. See Least Concern (Q211005), where it exists some months ago. Amadalvarez (talk) 21:39, 21 July 2018 (UTC)Reply[reply]
    Just add required properties to the constraint. I added only one because had no information about others. — Ivan A. Krestinin (talk) 22:05, 21 July 2018 (UTC)Reply[reply]
    language of work or name (P407) and sex or gender (P21) both sound right. - PKM (talk) 22:17, 21 July 2018 (UTC)Reply[reply]
    Excuse me, @PKM:, it should be better Wikimedia language code (P424) instead of language of work or name (P407), because the code language is usefull to make software that have to select the image of local language (I'm thinking in infoboxes from WPs, for instance). Otherwise, we need a double get to get the WM code language (P424). Thanks, Amadalvarez (talk) 18:06, 22 July 2018 (UTC)Reply[reply]
    I would vote for language of work or name (P407). If we store this, two steps are needed to get the language code. But what if we store Wikimedia language code (P424), and then want to get other data, like language name or Wikipedia article? It can be achieved only using a SPARQL query, which is not available for on-wiki modules. It’s also easier for the user to type in a language name than a code, and they get instant feedback—if the language name is incorrect, the statement can’t be saved. (It’s less of a concern, but according to the latest constraint violation report, language of work or name (P407) is used on 65 items, while Wikimedia language code (P424) is only on 2.) —Tacsipacsi (talk) 18:22, 22 July 2018 (UTC)Reply[reply]
    No, language of work or name (P407) should be used. Infoboxes can also select this, either with double step or by item identifier. Wikimedia language code (P424) is "Wikimedia language code", mostly irrelevant to the world of languages. Matěj Suchánek (talk) 07:24, 23 July 2018 (UTC)Reply[reply]
    @Tacsipacsi, Matěj Suchánek, PKM: Longer, but not a problem to me handle language of work or name (P407). Thanks for your reasoning. Salut !, Amadalvarez (talk) 17:14, 25 July 2018 (UTC)Reply[reply]
    I added depicts (P180) - Salgo60 (talk) 08:27, 23 August 2018 (UTC)Reply[reply]
    Looking at violations will show all kinds of things that can be plausibly added [4]. E.g., creator (P170). copyright license (P275), length (P2043), sex or gender (P21). Basically anything that can describe an image or the thing depicted. Ghouston (talk) 09:44, 23 August 2018 (UTC)Reply[reply]

    Coat of arms format exclusion issue[edit]

    There is a format constraint (?i)((?!\barms of).)*, which exists to make sure that people choose coat of arms image (P94) over more generic image (P18). However, this approach has an issue: this format constraint incorrectly gives the warning in property image (P18) for coat of arms themselves. See, for example, royal coat of arms of the United Kingdom (Q165762), coat of arms of Russia (Q165508), coat of arms of Germany (Q133018). Perhaps, the items qualified as coat of arms (Q14659) or national coat of arms (Q645466) could be excluded from the format constraint report somehow. —⁠andrybak (talk) 09:09, 5 September 2018 (UTC)Reply[reply]

    I don't understand, coat of arms (Q14659) is already a exception to constraint (P2303), but the warning keeps popping up. Ivanbranco (talk) 09:26, 24 September 2022 (UTC)Reply[reply]

    Single-value constraint[edit]

    This property should have a single-value constraint. There's no good reason for having more than one image in an entity as galleries and categories of images on Commons are quite easy to link to from Wikidata. Whenever the image is re-used, such as for an infobox, the user will want a single image representative of the topic. Any application requiring multiple images will source them from Commons anyway, and Wikidata shouldn't be attempting to duplicate Commons. Once a Wikidata entity becomes a dumping ground for an unlimited number of images, there's no way for the re-user to know that they need specify a particular image by setting one of the images as preferred rank. Having a single-value constraint – even if not enforced – would make it far easier to find issues with multiple images having the same rank. --RexxS (talk) 23:04, 8 October 2018 (UTC)Reply[reply]

    • I sort of agree. Should it be possible to have multiple images distinguished by certain qualifiers, e.g., sex, since it's popular to have images of male and female birds? Or should somebody just be forced to pick one? If there are multiple images, how are users like infoboxes going to decide which one to display anyway? Ghouston (talk) 19:24, 31 October 2018 (UTC)Reply[reply]
    I totally agree. Just choose the most representative image. Allowing several images leads to galleries such as the one at input device (Q864114) where people waste time adding all sorts of devices. It is counter-productive. Syced (talk) 01:55, 5 August 2019 (UTC)Reply[reply]

    Aspect ratio[edit]

    I've added aspect ratio (W:H) (P2061) to the allowed qualifiers list. Seems like a logical addition, and it might be useful for applications and maybe for structured data on Commons as well. Husky (talk) 21:41, 30 October 2018 (UTC)Reply[reply]

    @Husky: I don’t think it useful: the aspect ratio of an image can be computed quite easily from the height and width of the image file, it doesn’t need to be stored. Can you give an example when it adds data to add it as a qualifier? (As far as I know, Commons structured data is always stored as statements, not qualifiers, so this constraint is not affected by it.) —Tacsipacsi (talk) 14:16, 31 October 2018 (UTC)Reply[reply]
    I agree with Tacsipacsi. It is easily ascertainable from height and width, you can get those:
    So no need for redundant aspect ratio (W:H) (P2061) perhaps? --Marsupium (talk) 04:45, 3 November 2018 (UTC)Reply[reply]

    Image on Wikimedia Commons[edit]

    Inspired by a tweet from user:DarTar [5], I would like to raise the suggestion that this property's primary label "Image" (and equivalent in other languages) is perhaps a bit misleading - since the subject of the property MUST be on Wikimedia Commons. This is a major and deliberate constraint on the scope of the property, but it is not clear by any of the current labels or aliases. Therefore, perhaps “image on Wikimedia Commons” is a more appropriate label, with "image" being an alias instead. For comparison, we have document file on Wikimedia Commons (P996) and also Commons compatible image available at URL (P4765).
    Sincerely, Wittylama (talk) 16:19, 7 February 2019 (UTC)Reply[reply]

    You make a very good point, I like your suggestion. Wikimedians might take it for granted and feel it is slightly redundant, but in the linked data world it is good to make it explicit, and it also helps newcomers. Ainali (talk) 16:28, 7 February 2019 (UTC)Reply[reply]
    I think property names should be short and simple, and since no other images are accessible to Wikidata that constraint seems logical. Information that some projects might have local files, not accessible by any other project, does not seem necessary in this property name. --Jarekt (talk) 20:00, 7 February 2019 (UTC)Reply[reply]
    Yes the constraint on the Property is logical - and should remain. I'm saying the title of the Property should match the expectation. The other two examples I gave are not "scanned file" or "image available at URL" but specifically identify that the property relates to what is on Commons. The title "image" is misleading in that it implies you can either upload your own file directly or that it allows you to link to any image-URL across the whole internet. Instead, the scope is ver specifically on Commons and should IMO be overt about that. Not the least because we're lacking a LOT of very well known images on Commons: for copyright reasons. This query for "works by Andy Warhol - with year, and optionally image" makes it look like we are really bad at collecting images. But in fact it's for copyright reasons that column is empty - not because we don't know how to find Warhol's works. Wittylama (talk) 22:34, 7 February 2019 (UTC)Reply[reply]
    • No need. The description can clarify this. --- Jura 09:10, 10 February 2019 (UTC)Reply[reply]
    Does it therefore follow that you would say that document file on Wikimedia Commons (P996) should be simply “scanned image” (or just “scan”) and that Commons compatible image available at URL (P4765) should be “image available at URL” - with the explanation of their scope to Commons in the description field being sufficient? I would argue that these three properties should be consistent in the way they’re labelled. Wittylama (talk) 12:58, 10 February 2019 (UTC)Reply[reply]


    • I think you are confusing things. P4765 says something about the licensing of the image. P18 and a few others have one of the datatypes that restricts values on Wikidata to files on Commons. P996 is a bit of an oddity, possibly done from a Wikisource POV. It's likely to renamed anyways. --- Jura 19:20, 10 February 2019 (UTC)Reply[reply]

    Having run into this myself multiple times (sometimes just an "oh I have to upload that to Commons", but also "oh only Commons files are allowed) I agree the name of the property should be changed to reflect Commons. Whether the image can be displayed on Wikidata from the property is irrelevant. Jane023 (talk) 13:08, 10 February 2019 (UTC)Reply[reply]

    gThumb constraint[edit]

    There is a problem with format/property constraint in following item "image": Q44316 click on the table to see its ! icon, PLEASE FIX IT, THANKS. Editor-1 (talk) 12:37, 9 February 2019 (UTC)Reply[reply]

    I see what you mean, but I don't understand the regular expression in the constraint. What does "(?i)" do? Ghouston (talk) 06:13, 11 February 2019 (UTC)Reply[reply]
    I am not familiar with regular expression, so can't help too much, but I think it is related to following part of the image title: "version 3.30 (2018-09)", it seems the image File:GNOME Shell with GNOME Clocks, Evince, gThumb and GNOME Files at version 3.30 (2018-09) in Dark theme.png breaks the defined regular expression. -- Editor-1 (talk) 09:46, 11 February 2019 (UTC)Reply[reply]
    @Editor-1, Ghouston: No it isn't the version number. It's "gThumb" which triggered the warning. My guess is that the writer of the regex wanted to prevent imports of image links which use a GThumb logo or screenshot as a placeholder image. I'm not sure how to proceed yet - my best hunch is that we should add an exception to this constraint where things that instances and/or subclasses of free software (Q341) should be exempt to the "gthumb" regex constraint, because it makes sense to illustrate a free software package with a gthumb screenshot. Deryck Chan (talk) 17:40, 11 February 2019 (UTC)Reply[reply]
    @Pasleim: You added the GThumb constraint. [6] What's the purpose? Deryck Chan (talk) 17:42, 11 February 2019 (UTC)Reply[reply]
    Gthumb.svg is used in some articles as placeholder which leads to wrong data import, e.g. [7], [8]. With the regex, this can be prevented. But feel free to change the regex if it causes other troubles. --Pasleim (talk) 19:51, 11 February 2019 (UTC)Reply[reply]
    Is only File:Gthumb.svg itself problematic (i.e. not files with similar names)? Then it can be moved to a new constraint specifically matching the whole value case-sensitively instead of this case-insensitive ((?i)) substring match. —Tacsipacsi (talk) 22:26, 11 February 2019 (UTC)Reply[reply]
    Thanks, (?i) sets a PCRE option for case-insensitive matching, it makes more sense now. What you suggest seems like the way to go. Ghouston (talk) 23:56, 11 February 2019 (UTC)Reply[reply]
    There are plenty of other icons in c:Category:No image icons, but nothing with a similar name, so it looks good. Ghouston (talk) 00:01, 12 February 2019 (UTC)Reply[reply]
    I had a go at changing it, but it looks like it should be done by somebody who understands PCRE syntax. Ghouston (talk) 00:17, 12 February 2019 (UTC)Reply[reply]
    ──────────────────────────────────────────────────────────────────────────────────────────────────── I've split the constraint into two. I removed the "gthumb" part from the long formatting string and made a separate one that specifically rejects filenames beginning with "gthumb", case insensitive.[9] Deryck Chan (talk) 11:38, 12 February 2019 (UTC)Reply[reply]
    • @Deryck Chan: "made a separate one that specifically rejects filenames beginning with "gthumb", case insensitive" what?! "gThumb" is the name of 1 famous free and open-source image viewer and organizer in Linux and it has its own article on many different wikis and also a category in Wikimedia Commons: w:en:gThumb & c:Category:GThumb -- there are many images that begins with "Gthumb" or "GThumb" which only 4 of them are taken by me and I still want to take more screen-shots for newer versions! |: -- Editor-1 (talk) 13:48, 12 February 2019 (UTC)Reply[reply]

    Images of animal, the sex gender and other issues[edit]

    Hi, I was looking this entry Q187943, and a notice the error warning saying that we shouldn't include a sex gender in photos entries, however I see a great value in adding this information when we have sexual dimorphism. So, what could be a solution for this issue? I don't see including a media legend as a solution, as this is not a machine readable solution.

    Another thing, to identify a animal we use parts of the animal, and to be a high educational value, we could start to show images of this parts, and their skeletons, if we have those, how we can implement that here?

    x0x0 Rodrigo Tetsuo Argenton (talk) 07:36, 25 March 2019 (UTC)Reply[reply]

    I believe skeleton worth its own property (and many "images" of fossils will fall into this property). I agree that sex qualifier is quite useful. --Infovarius (talk) 12:59, 26 March 2019 (UTC)Reply[reply]
    If you are going to include all varieties and all parts of the item, you are potentially going to need a lot of images. It's true that for some animals the males and females are quite different, but sometimes so are the adults and juveniles (and their eggs). Car models are sold with a range of colours. Hotels come in all kinds. Maybe you just have to settle for one image, and use a montage if there are more. Ghouston (talk) 01:06, 27 March 2019 (UTC)Reply[reply]
    If you want multiple images, you can also create a Commons gallery and link it from Wikidata. Ghouston (talk) 01:09, 27 March 2019 (UTC)Reply[reply]
    I was talking about animals.
    Yes it's true that it will increase the variety of images, however, all of them are educational relevant.
    I don't see why it's a problem better illustrate the entrance.
    It could increase a lot the educational potential, people and machines will easily find an example of the animal searched, and have a better panorama about it.
    Or we could maybe create an entrance as "female ostrich", "juvenile ostrich", "Greta oto larval fase", I do not like this idea however.
    Rodrigo Tetsuo Argenton (talk) 22:15, 29 March 2019 (UTC)Reply[reply]
    I think in some cases, you'll end up turning Wikidata items into a photo gallery plus a little data. Animals aren't the only things that vary in appearance. Even when we have items for individual animals, typically individual humans, they can vary a lot from one photo to another. On Commons there are categories like c:Category:Shirley Temple by year, and if multiple images are encouraged, then it may be reasonable to include one image from each year. Being able to pick a single image to represent something is useful, since infoboxes can generally only take a single image from P18. Obviously, a single image can't represent all facets of a given topic, but neither can 2 images, 10 images, or 100 images. Ghouston (talk) 02:31, 30 March 2019 (UTC)Reply[reply]

    ──────────────────────────────────────────────────────────────────────────────────────────────────── See this: [10] this is wiki made by Biologists to Biologists, they have a set of images to identify the animal, 12 photos, a lot of information. I can't see why you have trouble with that. Again, I'm not talking about people, cars... I'm talking about animals. Rodrigo Tetsuo Argenton (talk) 05:06, 31 March 2019 (UTC)Reply[reply]

    Infoboxes like that would give a justification for including multiple images. I'm not sure if P18 with qualifiers would be the best for that, or if new properties should be created. Ghouston (talk) 09:09, 31 March 2019 (UTC)Reply[reply]

    P18 is a single image that represents the item. If you want several images to represent the male/female/fetus/winter/summer variations to show in infoboxes, good, just create new properties, but do not hijack P18. I am developing an app that shows P18 as an illustration for each item, and I don't want to show a picture of a fetus because nobody will recognize the animal. Syced (talk) 03:24, 6 August 2019 (UTC)Reply[reply]

    Erroneous "Commons link should be well-formed" for filename containing Japanese characters