Module talk:Creator

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

Undeployed edit from sandbox[edit]

Jarekt, while using the sandbox for this module, I noticed that you never deployed Special:Diff/252583558. Should that change have been deployed? —RP88 (talk) 20:46, 22 August 2017 (UTC)[reply]

Work period?[edit]

Jarekt, the display for work period is not currently internationalized. I was thinking about internalizing the display with something like:

args.workperiod = Complexdate._complex_date('-', '', data.P2031, '', '', '', data.P2032, '', '', lang, 1)

but that probably isn't adequate. In addition there should probably also be code that looks at the precession of the dates (is their an existing precision convention for 'circa' on wikidata?). Further complications include possibly parsing floruit (P1317) if it is present and possibly even pulling the start time/end times from work location (P937) (see Vincent van Gogh (Q5582)). Before I begin, do you have suggestions or thoughts? —RP88 (talk) 21:21, 22 August 2017 (UTC)[reply]

RP88, I am traveling at the moment with only occasional wifi connection, but I will be back on Friday. I am working on a rewrite of this module cleaning up a lot of code and will be adding new thing missing from the current version. I am wary of making too many changes to the code as the template is used on few million pages, so I let them accumulate. If you would like to work on floruit (P1317) (with and without start data end date quilifiers) or work location (P937), go ahead add it to the sandbox and I will merge it with the changes I am making right now offline. About the proposed internationalization of workperiod: I was thinking about it but it seems like simple yyyy-yyyy format was preferred in this field over an internationalized sentence. --Jarekt (talk) 02:12, 23 August 2017 (UTC)[reply]
Hey RP88, I'm afraid there isn't and – I think – can't be "an existing precision convention for 'circa' on wikidata". The data relies on external sources and the reason sourcing circumstances (P1480) and with it circa (Q5727902) were introduced is that the sources often don't give a precision. Best, --Marsupium (talk) 05:41, 24 August 2017 (UTC)[reply]

Arbitrary last value picked?[edit]

It looks like

				for _, statement in pairs( entity:getBestStatements( P )) do
					if (statement.mainsnak.snaktype == "value") then -- or if statement.mainsnak.datavalue then 
						local v = statement.mainsnak.datavalue.value
						if v['numeric-id'] then
							v = 'Q' .. tostring( v['numeric-id'] )
						end
						data[P] = v
					end
				end

loops over the statements for one property of the Wikidata item and each time saves the QID of the value in v. So only the last value will show up here. Is that correct? For instance Creator:Abdülhamid Han only shows Topkapı Palace (Q170495) as birthloc which is the last value for place of birth (P19) of Abdul Hamid II (Q134817#P19). Probably the ranks for the values should be that way that getBestStatements only gives one value there. The three values violate the single-value constraint (Q19474404) of place of birth (P19) and make Abdul Hamid II (Q134817) show up on Wikidata:Database reports/Constraint violations/P19.
It seems that is simply hidden here. The order of the values on Wikidata is arbitrary, it hasn't any meaning, there is no cause to take the last one. All values should be displayed here so that an editors at Commons can stroll over to Wikidata and manually pick the best value by setting the ranks.
BTW: We could use category for value not in Wikidata (P3713) and property usage tracking category (P2875) on the categories in Category:Creator template maintenance like at d:Property:P19#P3713 to promote the data that could be received from Commons. --Marsupium (talk) 19:42, 12 September 2017 (UTC)[reply]

Marsupium , Yes at the moment we assume a single value for many properties and if multiple properties are present on Wikidata with the same rank than, only a single (random one) is shown. I was dealing with that by querying the Wikidata database and fixing constraint violations, but you are right that we could display multiple values. I am fine with using category for value not in Wikidata (P3713) and property usage tracking category (P2875) to track some of the categories in Category:Creator template maintenance, although I am confused about how to do it with linking to pag3s on Commons: I could add Category:Creator templates with Wikidata link: redundant image as a sitelink to Category:Local image same as Wikidata , but what to do when Category:Institution templates with Wikidata link: redundant image is created? Maybe Category:Creator templates with Wikidata link: redundant image should be a subcategory of local Category:Local image same as Wikidata. --Jarekt (talk) 20:34, 20 November 2017 (UTC)[reply]

Use correct rowspan[edit]

Now if there are fewer than 9 data rows, the bottom border of the image cell is missing (at least in Firefox). Since it’s written in Lua, I’m sure it can be modified to give the image cell a rowspan equal to the number of the actually shown rows. —Tacsipacsi (talk) 13:26, 20 November 2017 (UTC)[reply]

✓ Done --Jarekt (talk) 00:31, 29 January 2018 (UTC)[reply]

Homecat[edit]

For creator ABC, I expect a category to be automatically added, using ABCs P373, but it does not want to (because of namespace is not 100, which is "portal"?). Can anyone explain why? Ketil3 (talk) 10:12, 18 December 2017 (UTC)[reply]

I am sorry I do not understand the question. Can you give an example of a page, what it shows and what you expect it should show? --Jarekt (talk) 21:19, 18 December 2017 (UTC)[reply]
I added Creator:Helge Skappel to several images on commons (such as [1]), correctly linked to Wikidata (where the P373 is Commons homecat). For each of these images, I expect there to be a Category:Helge Skappel added automatically (using P373), but it is not added. The Lua program (creator) does say "args.homecat = args.homecat or data.P373".Ketil3 (talk) 04:50, 19 December 2017 (UTC)[reply]
Creator templates never add categories to files. In the early days of creator template it was common to add a category to pages like Creator:Helge Skappel, but that caused a lot of issues when people were trying to subcategorize content of an artist directory and could not remove existing categories. It took a lot of labor to fix that and we try to keep file categorization independent of templates since. --Jarekt (talk) 12:44, 19 December 2017 (UTC)[reply]
OK, no problem. But, I was confused by the Lua code, thinking the P373 and "homecat" parameter had any significance. Thanks for explaining. Ketil3 (talk) 13:55, 19 December 2017 (UTC)[reply]
The significance of "homecat" parameter was to add category to the creator template itself, but without adding it to the files that use it. It seemed like "homecat" parameter was easier to explain than to ask people to add <noinclude>[[Category:homecat]]</noinclude> to each creator template. We opted for simplicity to encourage uniformity. --Jarekt (talk) 17:21, 19 December 2017 (UTC)[reply]

Fix for the sortkey bug[edit]

{{Edit request}} Please, apply this change to the module. It was tested on Václav Bělohradský (patolog) who now goes under «B(Latin-2 letters)», not under «(» as previously.

More information: template talk: Wikidata person. Regards, Incnis Mrsi (talk) 11:23, 26 December 2017 (UTC)[reply]

✓ Done Awesome! Thank you! Steinsplitter (talk) 11:36, 26 December 2017 (UTC)[reply]

Local sortkeys shouldn't be removed[edit]

Please take sortkey out of "redundant if commons creator template and wikidata have those fields, without checking values". If they differ the calculated sortkeys will mostly be inferior to the local ones and should not be categorized in Category:Creator templates with Wikidata link: redundant sortkey which says "Please remove sortkey field from Creator template." --Marsupium (talk) 11:10, 28 January 2018 (UTC)[reply]

Marsupium i think it is Fixed now and you are right that was wrong. Now sortkey is redundant if local copy is identical to wikidata derived. --Jarekt (talk) 04:55, 29 January 2018 (UTC)[reply]
Great, thank you! Will probably still take some time for the category to shrink again … :) --Marsupium (talk) 19:42, 29 January 2018 (UTC)[reply]

No birth year shown when there are multiple birth days in Wikidata[edit]

Creator:Jean Gilletta has two birth dates in Wikidata: 1856-05-01 and 1856-05-07. Since both are 1856, he has certainly born in that year. However, the header doesn’t show any birth year. I’m sure it’s because the module doesn’t know which one to show—but it doesn’t matter as they are the same. —Tacsipacsi (talk) 09:51, 11 May 2018 (UTC)[reply]

I thought that should have worked. I will need to debug it. --Jarekt (talk) 11:48, 11 May 2018 (UTC)[reply]
Fixed --Jarekt (talk) 13:10, 11 May 2018 (UTC)[reply]

Links should link to Commons[edit]

In the great {{wikidata infobox}} wiki-links are linked to Commons categories (or articles) based on Wikidata data, but this template links to Wikipedia articles, which is also fine, but bit inconsistent. Is there a particular reason to have links to Wikipedia here? Cheers, Yarl 💭  07:33, 26 September 2018 (UTC)[reply]

Using sitelinks rather than P373[edit]

@Jarekt: Would it be possible to modify this template to use the Commons sitelinks instead of Commons category (P373), please? The Lua code to do that already exists in Module:WikidataIB's "getCommonslink" function, so that could either be copied here or called directly from this module. For context, see d:Wikidata:Properties_for_deletion#Property:P373. Thanks. Mike Peel (talk) 10:42, 28 September 2019 (UTC)[reply]

Mike Peel, I am working on it at Module:Creator/sandbox. Fetching category name is easy from either one or the other (of topic's main category (P910)) sitelink. However copying from commons to wikidata is tricky. I can copy to a sitelink, but at the moment it would overwrite gallery name , if it is stored there. --Jarekt (talk) 04:07, 29 September 2019 (UTC)[reply]
@Jarekt: Did this get resolved? If not, Module:WikidataIB has code that can fetch the sitelinks while following the properties as appropriate, perhaps code from there could be reused? Thanks. Mike Peel (talk) 18:08, 30 October 2021 (UTC)[reply]
Mike, sorry it took 3 years, but I added code to look for sitelinks if Commons category (P373) is missing. I tested it using Creator:Aleksander Semkowicz --Jarekt (talk) 01:37, 2 November 2021 (UTC)[reply]
@Jarekt: That's great, thanks! Mike Peel (talk) 07:57, 2 November 2021 (UTC)[reply]

Format[edit]

Sometimes (esp. when used in the authors field) it would be nice when an option could suppress the linefeed easily, so to generate e.g.

derivative work by
Ludwig van Beethoven  (1770–1827)  wikidata:Q255 s:en:Author:Ludwig van Beethoven q:en:Ludwig van Beethoven
 
Ludwig van Beethoven
Description German- composer
Date of birth/death 17 December 1770 (baptised)  Edit this at Wikidata
Location of birth/death Bonn Vienna
Work period 1782 Edit this at Wikidata–1827 Edit this at Wikidata
Work location
Authority file
creator QS:P170,Q255

instead of the standard linefeeded

derivative work by

creator QS:P170,Q255

-- sarang사랑 09:38, 22 February 2020 (UTC)[reply]

sarang, I think that would be a nice thing to have, but there are 2 issues:
  1. I do not know how to do that in HTML
  2. It would be tricky to document that, since {{Creator}} template is used by other templates stored in Category namespace, and the only communication channel from lets say a file calling Creator:Ludwig van Beethoven to {{Creator}} template is "option" parameter which is already used for other things like the info to "collapse" the template you used earlier, or to indicate that it is Ludwig van Beethoven and workshop. We can separate commands by '/' but adding more commands like that makes thinks hard to document and explain.
--Jarekt (talk) 15:52, 24 February 2020 (UTC)[reply]

References field.[edit]

Why was this specified as a SPAN?

In some instances what is being supplied is clearly a list: such as in Creator:Jean-Baptiste Bullet de Chamblain? ShakespeareFan00 (talk) 09:20, 18 April 2020 (UTC)[reply]

ShakespeareFan00, I have no idea. I do not know much about proper HTML, so as long as it looks good I am happy. rapping references in SPAN was probably someone's request a decade ago and nobody ever questioned it. It is line 191 in the code, You are welcome to clone the code in /sandbox and test it on a few pages with references, if it does not cause any issues than we can remove it. --Jarekt (talk) 16:11, 18 April 2020 (UTC)[reply]
Okay, so where is the documented specification for this particular Module (as opposed to the actual source code)? ShakespeareFan00 (talk) 17:02, 18 April 2020 (UTC)[reply]
@Jarekt: I note the sandbox has had some other updates made since you mirrored the live version, such that when I did a quick test, I got a Lua error from the sandbox version even without my planned modification. I am reticent to make changes if the sandbox version isn't functional at present. ShakespeareFan00 (talk) 17:57, 18 April 2020 (UTC)[reply]

Description parameter should override description generated from Wikidata, not add to it[edit]

It's strange to have two separate descriptions. Generally, I only use the description parameter if the description generated from Wikidata is inappropriate, so it would be nice if it overrode the Wikidata description rather than just adding a 2nd description to the output. Kaldari (talk) 02:49, 5 September 2020 (UTC)[reply]

Replace minimum static 100px with consistent measurement[edit]

{{Edit request}} Please modify lines 137 and 138 to include the (symmetrical) code:

Creator
		cell3 = ''
	else                         -- 3 cell row
		cell2 = string.format('<td style="width:50%%; %s" id="%s">\n%s</td>', args.style1, param1.id, field1 or '')
		cell3 = string.format('<td style="width:50%%; %s" id="%s">\n%s</td>', args.style1, param2.id, field2 or '')
	end
	return string.format('<tr valign="top">\n%s%s%s</tr>\n', cell1, cell2, cell3)

Thanks, ᴀlbanɢeller (talk) 07:19, 17 June 2021 (UTC)[reply]

ᴀlbanɢeller, Thank you for all the work you did, but I am looking at examples in Module_talk:Creator/sandbox/testcases#wikidata_based and the results of this change make the creator template much larger than necessary. For example:
{{Creator/sandbox |Wikidata = Q30079822}} (with the change) gives
Alexey Savelyev  (1883–1923)  wikidata:Q30079822
 
Alternative names
Alexey Ivanovich Savelyev; Aleksey Ivanovich Saveliev; Aleksey Saveliev
Description Russian-Soviet photographer
Date of birth/death 1883 Edit this at Wikidata 1923 Edit this at Wikidata
Location of birth/death Russian Empire Moscow
Authority file
creator QS:P170,Q30079822
{{Creator |Wikidata = Q30079822}} (without the change) gives
Alexey Savelyev  (1883–1923)  wikidata:Q30079822
 
Alternative names
Alexey Ivanovich Savelyev; Aleksey Ivanovich Saveliev; Aleksey Saveliev
Description Russian-Soviet photographer
Date of birth/death 1883 Edit this at Wikidata 1923 Edit this at Wikidata
Location of birth/death Russian Empire Moscow
Authority file
creator QS:P170,Q30079822

In most cases we do not want to make this template bigger than necessary and we do want the field names (on the left) to fit in a single line for most cases. Are there some other way you can fix the issue you re fixing without exploding the size of the template? By the way the minimum was there so if the column is empty than it will still be visible. --Jarekt (talk) 01:01, 19 June 2021 (UTC)[reply]

@Jarekt: I think bringing down the minimum to 87.5px would work OK. ᴀlbanɢeller (talk) 02:49, 19 June 2021 (UTC)[reply]
ᴀlbanɢeller, Is there significance to ".5" part? can we round it?--Jarekt (talk) 02:55, 19 June 2021 (UTC)[reply]
Creator
	cell1 = string.format('<td style="%s">%s</td>\n', args.style2, tag)
	if param1.id==param2.id then -- 2 cell row
		cell2 = string.format('<td colspan="2" style="width:1px;%s" id="%s">'.. param1.wrapper ..'</td>', args.style1, param1.id, field1 or '')
		cell3 = ''
	else                         -- 3 cell row
		cell2 = string.format('<td style="width:30%%; %s" id="%s">\n%s</td>', args.style1, param1.id, field1 or '')
		cell3 = string.format('<td style="width:30%%; %s" id="%s">\n%s</td>', args.style1, param2.id, field2 or '')
	end
	return string.format('<tr valign="top">\n%s%s%s</tr>\n', cell1, cell2, cell3)
@Jarekt: this should work to keep the "3 cell row" at the same width. (I had to fill in the width for the "2 cell row" to prevent the whole thing from exploding.) ᴀlbanɢeller (talk) 05:28, 19 June 2021 (UTC)[reply]
ᴀlbanɢeller, looking at Module_talk:Creator/sandbox/testcases#wikidata_based, most templates look better with the old code than with the new proposed code. The issue is mainly that the field names are split into 2 lines with the new code - an issue we did not have before. --Jarekt (talk) 00:53, 20 June 2021 (UTC)[reply]
Jarekt, I'm only seeing the field names being split into 2 lines with the old code, so I'm not sure exactly what you mean? ᴀlbanɢeller (talk) 00:55, 20 June 2021 (UTC)[reply]
The new code doesn't split the field names, but the old one does. This can be seen and compared with the old code directly below in those testcases. ᴀlbanɢeller (talk) 01:07, 20 June 2021 (UTC)[reply]
✓ Done You are right, but it is strange as I do not think that was happening in the past. Anyway, Thank you for your work. Jarekt (talk) 01:15, 20 June 2021 (UTC)[reply]
Thanks Jarekt. Although, having look at the testcases a bit more closely, I think it would be best to avoid percentages altogether and use em widths to save unnecessary space. In light of this, can you possibly look at implementing this change when you're able? ᴀlbanɢeller (talk) 03:37, 20 June 2021 (UTC)[reply]
✓ Done --Jarekt (talk) 03:09, 21 June 2021 (UTC)[reply]

Wikimedia Commons Module creator uses a wrong regex for property Property:P1053[edit]

Unresolved problem, see https://phabricator.wikimedia.org/T286015. Geert Van Pamel (talk) 11:35, 2 July 2021 (UTC)[reply]

Fixed See [2] --Jarekt (talk) 23:58, 1 November 2021 (UTC)[reply]

Hyphen-minus preceding occupation[edit]

Why is there a hyphen-minus "-" preceding the occupation? Please see original question https://commons.wikimedia.org/w/index.php?title=Creator_talk:Rabindranath_Tagore&oldid=620150284 and the effect at Creator:Rabindranath Tagore.   — Jeff G. please ping or talk to me 11:49, 9 April 2022 (UTC)[reply]

Files from Family/Personal archives[edit]

Best way to state a file comes from the "family/personal archive of" a person? Can we add a new value to qual1 variable? emijrp (talk) 19:25, 24 December 2022 (UTC)[reply]

Layout bugs if birth *or* death info, but not both[edit]

Compare these three:

Born Died  
 
Date of birth/death 2020 2022
Location of birth/death here there
Only Born  
 
Date of birth 2020
Location of birth here
Only Died  
 
Date of birth/death 2022
Location of birth/death there
Mixtures  
 
Date of birth 2022
Location of birth/death there

If someone has both birth and death info, those are included in adjacent cells in a row. If there is only birth or only death, there are visible empty cells for the missing info. It makes sense to have a blank cell if there is a location but not date for such a thing (it's obvious what's missing). But if both are missing, the blank cells look like a mistake and the row-titles are inconsistent as well. And there is an independent tow-title bug in that it says "birth/death" even if there is only death info (compare with only saying "birth" if there is only birth info). DMacks (talk) 01:50, 21 June 2023 (UTC)[reply]

DMacks, getting rid of empty cells would be hard, as we would have to change fundamental layout of the template. I think that in the past they were rescaled to a zero width, but I guess that is no longer happening. However I do agree about inconsistent row-titles. The row titles come from translatewiki (translatewiki:Special:Translations/MediaWiki:wm-license-creator-date-of-birth and translatewiki:Special:Translations/MediaWiki:wm-license-creator-date-of-birth-and-death) and if there existed translatewiki:Special:Translations/MediaWiki:wm-license-creator-date-of-death (and similar one for the place of death) I could fix that issue. Unfortunatelly, I never learned how to set it up. Does anyone know how to create a page on translatewiki and pull the translations to Commons? --Jarekt (talk) 22:33, 30 June 2023 (UTC)[reply]
Hi there, I've signed up at translatewiki:User:Marsupium planning to ask around there, but apparently the account isn't approved and I cannot even edit my own talk page. Is there anyone here around who could help with the problem you've outlined above, Jarekt? --Marsupium (talk) 17:20, 29 January 2024 (UTC)[reply]

Space after decade[edit]

@Jarekt: Hi Jarek, do you think you could look into removing the extra space when decades are inputted in the Work period parameter? Please see the Creator template at Christian Lambiotte for one example. Thanks, ᴀlbanɢeller (talk) 17:49, 22 June 2023 (UTC)[reply]

ᴀlbanɢeller should be done now.--Jarekt (talk) 21:25, 30 June 2023 (UTC)[reply]
 Thank you. ᴀlbanɢeller (talk) 23:24, 30 June 2023 (UTC)[reply]

Properties used for "workperiod"[edit]

For filling "workperiod", currently floruit (P1317) seems to be favored over work period (start) (P2031)/work period (end) (P2032). I think it should be the other way round. An example wood be Creator:Hendrik Kobell where currently the value is set on Commons. --Marsupium (talk) 15:22, 13 January 2024 (UTC), 15:23, 13 January 2024 (UTC)[reply]

editAtWikidata not working for birthloc and deathloc[edit]

Module:Creator#L-535:

			dy = getLabel(d1, args0.lang) .. core.editAtWikidata(args0.wikidata, prop, args0.lang)

doesn't seem to have the desired result of adding editAtWikidata icons to the displayed values for birthloc and deathloc. See for example Creator:Charles-Antoine Bridan. (Leaving this as a note here for the next time me or someone else feels like fixing it.) Best, --Marsupium (talk) 16:45, 29 January 2024 (UTC)[reply]

Month precision date with higher WD precision categorized as mismatch[edit]

See deathdate of Special:Permalink/872334789. Problem is this is not detected in Module:Creator#L-505. --Marsupium (talk) 16:27, 29 April 2024 (UTC)[reply]