Template talk:Creator

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Info non-talk.svg Template:Creator has been protected indefinitely because it is a highly-used or visible template. Use {{Edit request}} on this page to request an edit.
Please test any changes in the template's /sandbox or /testcases subpages, or in a user subpage, and consider discussing changes at the talk page before implementing them.

Statistics (Please do not archive)[edit]

Date Number of Creator templates Number of Files using Creator template
6430 281k
7488 321k
8698 379k
10,285 452k
15,441 872k
24,783 1457k

Only says "birth" even if also death-info[edit]

The following:

 | Name              = Fortuné Méaulle
 | Birthdate         = 1844-04-11
 | Birthloc          = Angers
 | Deathyear         = 1901
 | Deathloc          = 

displays as:

Fortuné Méaulle (1844–1901) Link back to Creator infobox template


does not show any more, only death date--Oursana (talk) 21:56, 7 June 2017 (UTC)

I just tried Creator:Biagio Camagna and it has both dates. Can you give an example? --Jarekt (talk) 02:07, 8 June 2017 (UTC)

I see dates all right, but there appears to be formatting issues when there are more than one of them. See [[Creator:Anselmo Bucci ]], when data stored locally are removed.

{{#invoke: Wikidata|formatStatementsE|entity=Q569638|property=P569}}

works fine: and .

That said, It would make more sense to use "or" rather than "and":

{{#invoke: Wikidata|formatStatementsE|entity=Q569638|property=P569|conjtype=or}}

works fine: or .

It would be even better if dates were sorted chronologically and if "may 1887" was shown only once. 23 May 1887 or 21 May 1887.-> 21 or 23 May 1887.--Zolo (talk) 13:52, 10 June 2017 (UTC)

There are still many issues with the new template and with date handling. I keep track of some of them at Module talk:Creator/sandbox. I was thinking about writing a new module to interface Wikidata and Module:Complex date, just did not get around to do that yet. I will concentrate on merging simple creator templates with wikidata, before I look into more complicated data. --Jarekt (talk) 14:57, 10 June 2017 (UTC)
Creator:Rogier van der Weyden doesn't show the birthdate, I saw several examples like this.--Oursana (talk) 20:21, 10 June 2017 (UTC)
I see the birthday in Creator:Rogier van der Weyden. Maybe purging will help. --Jarekt (talk) 02:36, 11 June 2017 (UTC)
I have the ›and‹ issue with location (P276) too. Workaround: Change rank:normal to rank:preferred, so only one (preferred) entry will be displayed. –Plagiat (talk) 12:17, 11 June 2017 (UTC)
If the values are equal, it's quite a bad idea to manipulate them in Wikidata to circumvent the flaws of a template on Commons not combining them correctly I think. --Marsupium (talk) 17:05, 12 June 2017 (UTC)
Current handling of dates works for a single ISO date and maybe foe other cases, but not much else. I am planning to Write some Lua code combing wikidata and module:Complex date, but at the moment we are stuck with 90% solution. Unless there is a clear preference between 2 Wikidata versions I would not be changing preferences there to suit our needs. Until there is new code for handling dates I think we need just add challenging dates by "birthdate" and "deathdate" parameters. Also if someone knows Lua and wants to try writing Lua code combing wikidata and module:Complex date, please give it a shot. --Jarekt (talk) 19:13, 12 June 2017 (UTC)
Sorry, I still do not see the birthdate after creator's name in Creator:Rogier van der Weyden, nor in Creator:Claude Lorrain as in many others. These give 2 birthdates by year--Oursana (talk) 23:06, 30 June 2017 (UTC)
Pictogram voting keep.svg Fixed with help of parameter "Lifespan" (I ought to document it). I also hope to release better handling of dates by Creator templates soon. I just finish testing Module:Wikidata date I wrote for that purpose. --Jarekt (talk) 03:04, 1 July 2017 (UTC)
please check Creator:Antonello de Saliba--Oursana (talk) 22:04, 21 July 2017 (UTC)
@Oursana: This looks like an artefact of the limited support for complex dates in the current integration with Wikidata outlined above. I've added a |Lifespan= parameter as a workaround for now. @Jarekt: Pinging on the off chance you're not already aware of this issue. --Xover (talk) 07:22, 22 July 2017 (UTC)
thank you--Oursana (talk) 16:40, 22 July 2017 (UTC)
I do not see any issues with Creator:Antonello de Saliba. What was the issue there. --Jarekt (talk) 18:56, 22 July 2017 (UTC)
Revision of Creator:Antonello_de_Saliba did not show the birthdate--Oursana (talk) 23:24, 22 July 2017 (UTC)
At the moment the lifespan years if not precisely known are not shown and you are right I see a problem since in the revision you have shown the local death date should have overwrote wikidata one. --Jarekt (talk) 02:47, 23 July 2017 (UTC)

Issue with nationality from Wikidata[edit]

cf. Creator:Sir James Prior.

If I remove |nationality= from the template, the Description field disappears from the rendered output. Also removing |occupation= does not affect anything (in case there's a dependency that both be either local or both be from Wikidata). One possible reason I can think of is that his nationality on Wikidata is set to the w:Kingdom of Ireland (and should probably be w:United Kingdom of Great Britain and Ireland). The local parameter here is "IE" (which I'm guessing is either w:Republic of Ireland or, possibly, w:Northern Ireland). In our description, all the historical nationalities (and quite possibly also the modern ones) should be aliases of a meta-nationality displayed as "Irish". --Xover (talk) 05:55, 20 June 2017 (UTC)

I will revisit handling of |nationality= and |occupation= that might help with this issue, but in the mean time if something does not show properly based on Wikidata, than fine-tune it using template parameters. Last week I was removing many redundant fields from Commons templates, which are the same on Commons and Wikidata, simplifying the templates and making them easier to manage but I suspect that most will still rely on some local parameters. --Jarekt (talk) 11:54, 20 June 2017 (UTC)
I've run across a lot of Creator templates for artists whose nationality is Flemish, Southern Netherlandish, or Northern Netherlandish. These can't currently be pulled from Wikidata because Module:Creator assumes modern nation states (Template:CountryAdjective) with a two-letter ISO code, rather than historic countries (Template:Nationality). I think this can be fixed by simply adding the historic nationalities' Q-codes onto Module:Creator/conf mapping to the country adjectives that Template:Nationality understands (it's a short list, you might just snarf it all for a quickfix). But I'm not sure that solution scales with the number of historic nations that might be relevant (England and Ireland alone probably amount to 10-15 country-level legal entities).
And this raises a related issue: Commons has (aiui) treated |Nationality= as interchangeably either "Country of citizenship" and "School of". This sort of duality won't work when pulled from Wikidata where those concepts will be distinct and orthogonal properties. For instance, I just ran across a painter whose country of citizenship is Germany but is from the Flemish school. I suspect this will require changes to the information model of T:Creator to resolve; I don't think can be handled by simple preference/fallback type logic. Not sure how to handle that, so just flagging it as something to look into. --Xover (talk) 19:35, 24 July 2017 (UTC)

Need help reconciling Creator templates and Wikiata[edit]

Current version of Creator template looks for different types of mismatches between data on Commons and data on Wikidata, see Category:Creator template maintenance. In case of mismatch one should compare Commons version and Wikidata version, verify that it is truly different, check the sources and references and correct information either on Commons or on Wikidata. At the moment I ahve a large number of cases where birthday or death day on commons is at day precision while on Wikidata it is at year precission. You can click Commons to Wikidata QuickStatements.svg to upload high precision dates to Wikidata but than one should evaluate references for each date and add references to day precision dates. If someone is interested I can provide more info. --Jarekt (talk) 03:42, 17 July 2017 (UTC)

@Jarekt: If I were to decide to try helping chip away at this backlog I would wish for some more information. For instance, I see that "quickstatements" link, but I don't know what it does nor what a "quickstatement" is in the context of Wikidata. And perhaps you could expand on the "evaluate references" bit? Commons will usually not have citations for such dates, and if the day-precision dates had been available on Wikipedia they would have already been on Wikidata (Referenced with "Imported from Wikipedia"). In other words, I see no particular pressing need to go digging for cites for these dates in the case when Commons has day-precision and Wikidata only year-precision dob/dod. --Xover (talk) 10:32, 17 July 2017 (UTC)
Xover, "quickstatements" is a tool that simplifies adding data to wikidata. I can create a spreadsheet of data and if I format it correctly and cut and paste to quickstatements I can add them batch at a time. I can also add data through URLs. {{Creator}} in some cases is able to construct URLs that prefill quickstatements. In this case {{Creator}} when it notices situation where Commons have day-precision date while Wikidata have year precision date than it creates url that allows sending day-precision date to Wikidata. At this point there are 2 dates on Wikidata. The way I was handling it was as follows:
  • If there were no references (other than imported from ... Wikipedia type) than I was just deleting the year dates. See this example
  • If there were references attached to year date than I would leave it be, but I would try to find a reference to support day precision date and than elevate its status to preferred, see for example d:Q92539. Sometimes it lead to total confusion where each reference had different date, like for d:Q2265356, where I mostly recorded all the dates in the literature and left it for others to figure out. Most of the items on Wikidata have a lot of qualifiers and some of them like RKDartists ID (P650) or Benezit ID (P2843) usually have dates with day precision.
Hope this helps and let me know if you have more questions. Thanks for considering helping. --Jarekt (talk) 12:36, 17 July 2017 (UTC)
It seems to me that adding dates before 1584 or 1582 via QuickStatements should be deactivated asap. I just used it for this edit. It has no calendar support and adds dates as Gregorian dates to Wikidata from Commons that are probably meant to be Julian dates on Commons. Am I mistaken somehow? --Marsupium (talk) 16:47, 10 August 2017 (UTC)

Work location from Wikidata[edit]

cf. eg. Creator:Théodore Baron. Pulling Workloc from Wikidata is limited to the last defined property. Should handle multiple locations, including the time periods specified there. (just dropping a note for Jarket's todo list ;D). --Xover (talk) 10:32, 18 July 2017 (UTC)

Work location is also something Module:Creator does not handle well. Ideally we could pull all the locations and the periods of residence, but that might become very long. To me this field on Commons often has too much information I never use. I find Work location mostly useful if places of birth and death are missing; otherwise I never look at it. But I agree that current approach of returning only (random) one from the list is wrong. At the moment my priorities were dates and places of birth and death. --Jarekt (talk) 15:57, 20 July 2017 (UTC)
I agree with your priorities. :) But I've not really seen any egregiously long list of work locations so far. Is it really a problem, or merely a dislike? Perhaps an approach could be to fetch them all but cap the number displayed to some generous but not excessive number? --Xover (talk) 13:40, 21 July 2017 (UTC)
I think it is more of a "merely a dislike" than "really a problem" but some creator pages have very long local lists of places and dates that must have taken a lot of work to research and assemble and I think make creator templates very long and unwieldy. I do not have example at the moment. I will try to fetch at least a list of all the places from Wikidata. --Jarekt (talk) 02:29, 23 July 2017 (UTC)
If the incidence is high enough to matter, perhaps a collapsible list could be used for display? --Xover (talk) 10:42, 24 July 2017 (UTC)
The whole creator template is collapsible. Collapsible list in collapsible template would be strange. Less developed Work locations might be my mild preference, but it is not much of a deal. --Jarekt (talk) 13:09, 24 July 2017 (UTC)

Alternative names from Wikidata[edit]

Alternative names from Wikidata seems to still be missing. (just dropping a note for Jarket's todo list ;D). --Xover (talk) 14:15, 18 July 2017 (UTC)

I was not sure how should I handle them and I did not want to repeat bad handling of alternative names by the Magnus' tool that was used in the past to cast Wikidata info to Creator template. The issue is that on Wikidata you have list of alternative names for each language. Magnus' tool gathered them all and added different spelling of the names in different languages and alphabets. That resulted in often a very long list of with Alternative names in every alphabet. I think that for example for Russian names an Russian, English and German spellings are all you need and for western European names we do not need variants in other alphabets. I could start pooling only alternative names in English, which will be better than nothing but will not work for names in other alphabets. --Jarekt (talk) 15:48, 20 July 2017 (UTC)
Isn't LangSwitch the established way of dealing with that on Commons? --Xover (talk) 13:42, 21 July 2017 (UTC)
Most names do not have different alternatives in different languages, but some do. We could run all the alternatives from all the provided languages through LangSwitch, buth than if there are 5 alternatives in english and 1 in french than french speaker will see only one. I now know how to access aliases so I will give it a shot. --Jarekt (talk) 02:23, 23 July 2017 (UTC)
That would be the case here too (absent Wikidata) if LangSwitch is used. And any existing LangSwitch alternate names locally can be moved to Wikidata. --Xover (talk) 10:40, 24 July 2017 (UTC)
I think it isn't a good idea to use the Wikidata aliases instead of the current local alternative names here on Commons. The aliases are often very messy, containting ASCII-normalized labels, aliases imported from ULAN by Multichill and similar messy data, they simply serve another purpose obiously. Some of the local values here could be replaced by evaluating birth name (P1477) and pseudonym (P742), e.g. the {{name|birth|Jeffrey Koons}} on Creator:Jeff Koons. For other uses we need a new property on Wikidata perhaps. Perhaps native label (P1705), name in kana (P1814), name in native language (P1559) have some value, too. (I haven't investigated how those are used.) --Marsupium (talk) 17:31, 26 July 2017 (UTC)

Quality of wikidata data[edit]

Just a general remark. The quality of data from wikidata is often bad, sometimes really bad. For starters, the dates are often very crude. Result: dates become distorted. Wikidata has to do better than this, otherwise there's no point using it. Vincent Steenberg (talk) 20:11, 18 July 2017 (UTC)

"The quality of data from wikidata is often bad" So fix it. (Note: seems to relate to this edit.) Andy Mabbett (talk) 12:14, 19 July 2017 (UTC)
Well, Wikidata is not to blame per se, but I’d agree that wide-spread removal of all local data can seem a bit hasty.
The approach that Jarekt is leading is very sensible to me: get bots to compare data, remove it locally when identical and flag it for human review otherwise. This makes a lot of sense. Jean-Fred (talk) 13:10, 19 July 2017 (UTC)
Right. Important context is that Vincent Steenberg's complaint does not appear to be with one of Jarekt's bot-assisted edits, but rather with one of my manual ones. I've not yet had time to unravel what it was specifically that was offensive in it (I suspect it's the date of birth/death vs. baptism/burial), but perhaps Vincent might be prevailed upon to make their complaint specific? (Vincent: on a personal note, I appreciate feedback; if you have a problem with my edits, please do let me know!) --Xover (talk) 17:40, 19 July 2017 (UTC)
Sorry, I got a bit frustrated after that edit on Creator:Simon Luttichuys. The thing is, only his baptism and funeral dates are known. For example his baptism took place on 6 March 1610. The RKD then concludes that he could have been born as early as February 1610. Fair enough, but a user on wikidata then took that date (fabruary 1610) and made it his birth date, refering even to the RKD record. That's not the way forward I think. Right now his birth date on wikidata is 1610. That's an improvement, but I think in these cases – and there are many of them – the baptism date/funeral date should be imported from wikidata rather than the factual date. Vincent Steenberg (talk) 20:20, 19 July 2017 (UTC)
@Vincent Steenberg: No worries. I'm prone to some measure of frustration myself in such circumstances (Shakespeare's birth vs. baptism and attempts to "fix" it are the bane of my existence!). :) In any case, thanks for the clarification. My edit there was clearly too aggressive and I should have checked it better. Mea culpa!
I do, however, have to disagree with you slightly on some things. The way Wikidata handles multiple, possibly conflicting, datum is to include all of them, but, where possible, to mark them as deprecated/normal/preferred. If a wrong, but cited, datum appears on an item, it shouldn't be removed but marked deprecated. And, in general, the information should reflect what the sources say, not what a Wikidata editor "knows" to be true. In other words, if Luttichuys's birth date is explicitly unknown, or is explicitly 1610 with year resolution, then that information should be added, cited, and set to preferred, rather than the bad date deleted. There are intricacies of course, like what to do with unsourced claims. but in broad strokes...
I would also question whether Commons really needs day-resolution dates for birth/baptism and death/burial, and thus also whether we need to care about baptism/burial dates (at year resolution, inferred birth/death dates are good enough). Wikipedia does, certainly, as will many other users of the data. But on Commons, I think, the year should suffice in practically every case. That's neither here nor there, of course, because in the task at hand we really do need to preserve whatever granularity of data is present on the Commons side.
And per Jarekt below, that probably means getting the handling of burial dates on Wikidata settled, and then adapting the code of the Creator template. In the mean time, please do let me know if you have concerns with any of my other edits! --Xover (talk) 13:30, 21 July 2017 (UTC)

"The quality of data from wikidata is often bad" might be true but as I am reconciling many of Commons/Wikidata conflicting dates, places and even genders - it is mostly Commons that is wrong (at least according to the online references available from Wikidata). One of the issues with wikidata is that as it aggregates information from many sources it also aggregates mistakes from many sources with no way to tell them apart. I have seen entries with 3 or 4 different dates each one with a different "reliable" source. About Vincent suggestion to import baptism date and funeral dates: the code's logic at the moment uses baptism date if birth date is completely missing, however that is probably rare as the birth date is set to the same year. At the moment I am not pulling funeral date as the discussion about how to save it continues here (please join the discussion). --Jarekt (talk) 15:37, 20 July 2017 (UTC)

As a first approximation, I'm thinking use the date with the highest resolution, or the birth/death date if resolution is the same. But since Wikidata has no way to indicate rank between two separate properties ("birth date" vs. "date of baptism"), perhaps it might even make sense to have a boolean flag on Creator to indicate editor preference for one or the other? As a safety valve for the possibility that there is some case where using a day-resolution birth date would be undesirable. --Xover (talk) 13:36, 21 July 2017 (UTC)
For instance, take a look at Creator:Sven Markelius. Both Birthloc and Deathloc would in most cases be given as "Stockholm" (analogous to "Greater London area"). The actual birth and death locations given on Wikidata are too specific for the use on Commons (but Wikipedia might want it that specific). A way to indicate desired granularity may be needed for most params, and for this example, relatively complicated code to walk the tree up to a relevant level (municipality, in this case). --Xover (talk) 13:50, 21 July 2017 (UTC)
Oh, and mustn't forget about floruit dates. --Xover (talk) 08:50, 22 July 2017 (UTC)
Ok I will try to use date of baptism if it is more precise than date of birth. Or maybe just show both dates in the same field. Anyway any information from wikidata can be overwritten with the local parameter (all except for name at the moment), so if place is too precise or date if wrong than just overwrite it. My bot is assisting me in removing redundant field, but the only way other fields should be changed is once someone look at them and decide that wikidata info is better than Commons. --Jarekt (talk) 02:13, 23 July 2017 (UTC)
Right, we can override data locally, but then we're no further in the goal of reducing local possibly-conflicting local data. I've been chipping away at one of the maint. categories, and it's a bit too high an incidence of the problems above and necessitating the use of local overrides. Some can be fixed by fixing the data on Wikidata, but for others we run into conflicting information models (lack of burial date on WD, just as a obvious example) or contextually specific display preferences (like specificity of locations). Some of this stuff will require significant code changes to resolve, and, as mentioned above, conflicting goals will require local overrides in a way that does not propagate duplicative data (e.g. a boolean param to prefer baptism/burial or floruit dates over birth/death). --Xover (talk) 10:35, 24 July 2017 (UTC)
I do not think we can ever have creator template that will always pick ideal display format based on available Wikidata data. Most new templates do not use a lot of customization with local parameters and stick with the default, which I guess is good enough and might improve. By the way, floruit dates would be going into "Workperiod" field not birth/death dates. Right? --Jarekt (talk) 13:20, 24 July 2017 (UTC)
No, I think floruit dates would usually be used in place of birth/death when the latter are unavailable or otherwise undesirable (disputed, too imprecise, etc.). So in parens after the name in the header, or to replace the birth/death date in the table proper. Speaking from a historicist perspective, the idea is that birth/death and floruit are there to help identify the specific individual in question. Thus also work period; i.e. "The artist that worked in watercolours and that painted bridges and windmills, that was active in Antwerpen between 1280 and 1322." But when we're into that level of detail on presentation, I'm probably not the best person to ask. I'm a dabbler on Commons, and deal much more with writers than visual artists, so the conventions in that field on this project may be different. --Xover (talk) 14:42, 24 July 2017 (UTC)
So the dates in the top row after the name usually come from birth/death dates (local or from wikidata) or in some cases birth/death year fields (used when date is uncertain but year is not), but if those were missing than people usually added them to the end of "Name" field. With the wikidata based templates "Name" field is no longer used and I am moving dates found at the end of "name" field to "Lifespan" field. If there are no birth/death dates or local "Lifespan" field than I place dates from "Workperiod" field in the top row with "Fl." in front of them (see here). However we never place Workperiod dates in birth/death date fields or properties. I hope this makes sense. --Jarekt (talk) 16:52, 24 July 2017 (UTC)

Historical place names[edit]

Another issue that may bite us in use of Wikidata... Present day Saint Petersburg has changed names several times. In 1914, the name was changed from Saint Petersburg to Petrograd; in 1924 to Leningrad; and in 1991 back to Saint Petersburg. For a birth or death date in 1954 say, it would arguably be correct to say that death location was Leningrad. Pulling this from Wikidata will result in Saint Petersburg (Leningrad is just an alias of Saint Petersburg there). Currently the only ways to handle this is to either accept the anachronistic name, or to override it locally with all the issues such local overrides carry with them. I can't really think of a good solution for this, so I'm just dropping it here for better minds than mine to chew on. --Xover (talk) 14:41, 21 July 2017 (UTC)

Saint Petersburg, Leningrad and several other spellings were always redirected to "Saint Petersburg" if used in creator template and the same way on Wikidata last time I checked there was only one item for them. The only exception is Tokyo and Edo which for some reason have separate items and in the past had separate internationalization templates on Commons. --Jarekt (talk) 02:40, 23 July 2017 (UTC)


I started a Mix'n'match project to use that tool to match some of creator templates in Category:Creator templates without Wikidata link with wikidata items. If anybody wants to try to work with this cool tool please give it a shoot. The manual for the tool can be found at meta:Mix'n'match. The tool will add Commons Creator page (P1472) properties to the matched items. --Jarekt (talk) 17:19, 26 July 2017 (UTC)

Occupation/natinnality description in Hebrew[edit]

The description in English is Nationality and then occupation. But in hebrew it should be the other way round. First occupation and than nationality. Can work also: "occupation1, occupation2, and occupation3 nationality". I fixed it what evryting was in template. But now with "module", I dont know how to change it. -- Geagea (talk) 07:31, 7 August 2017 (UTC)

Page wrongly categorized in Category:Creator templates with Wikidata link: mismatching birthdate[edit]

I have fixed quite a few pages from Category:Creator templates with Wikidata link: mismatching birthdate, that a good way to find minor errors in our data. However, I don't get why Creator:Carlo Donelli is categorized there. Info seem to match Wikidata (there is also a second more precise date in Wikidata, but it has a lower rank and thus should not be retrieved). --Zolo (talk) 07:52, 21 August 2017 (UTC)

Creator:Francis Bourgeois has the same problem. I don't know what it going on, but I notice that when I set my language to French two birth dates are displayed, with slightly different spelling (just one date shown in English). --Zolo (talk) 08:04, 21 August 2017 (UTC)
I edited the items three and four days ago. I think the category changes just lag behind, so do the creator pages up to letter G in Category:Creator templates with Wikidata link: quick statements. Purging doesn't help. I'd also like to know why it takes so long …--Marsupium (talk) 12:14, 21 August 2017 (UTC)
The way to purge the pages one has to do an null edit to the page (save without changes). One can also run pywikibot touch.py script. I was keeping many of the categories up to date by such means, but I am traveling at the moment and did not have a chance. I will try this weekend to touch them. --Jarekt (talk) 03:31, 23 August 2017 (UTC)
I looked at Creator:Carlo Donelli and Creator:Francis Bourgeois and the Category:Creator templates with Wikidata link: mismatching birthdate is not right. I will look into it. In the mean time if you confirm that the dates are the same on Commons and Wikidata than just remove commons version and the category will disappear. --Jarekt (talk) 03:38, 23 August 2017 (UTC)

Showing the occupation data from Wikidata even if no country of citizenship present[edit]

I've been adding a bunch of people to Wikidata per Category:Creator templates without Wikidata link. When the occupation and country of citizenship are listed there, it pulls nicely in (as "German photographer" or "Romanian painter" or whatever) but when there is only an occupation, nothing pulls in automatically. Is there a reason for this choice? To me, having occupation only ("painter" or "photographer") is more useful in the Creator template than having nothing. Sweet kate (talk) 22:27, 30 August 2017 (UTC)

Sweet kate, You are right. It is something that should be fixed. --Jarekt (talk) 11:41, 31 August 2017 (UTC)