Module talk:Author

Add work period start & end

@Billinghurst, @EncycloPetey: re the idea at User_talk:Billinghurst#Author:Kālidāsa to add work period (start) (P2031) and work period (end) (P2032) to the author header: shouldn't be too hard, but how should it look? I mean, if we just put the years then it will look just the same as birth/death and so might be confusing. Should it be "bef. <year>" and "aft. <year>" as seems slightly common in genealogical circles? Or something else? Sam Wilson 05:37, 4 April 2018 (UTC)

From my reading of the sources that Wikidata used, the range should look something like "fl. 4th or 5th century CE", but I do not know whether Wikidata is even able to handle such data. It was miscoded there when I first looked, and now Billinghurst has had a go. --EncycloPetey (talk) 14:32, 4 April 2018 (UTC)

floruit was my thoughts, and really for our grade of work in what we are trying to achieve, such would be sufficient. We need to help identify the right person for future additions, and to show that the works are out of copyright. Anything else is purely bonus. — billinghurst sDrewth 22:58, 4 April 2018 (UTC)

On a related note, I created Author:Bhavabhūti, a writer who flourished in the 8th century CE. But because WD has no dates for him (yet), he is automatically identified as a "living" author. I think that, in cases where neither the birth or date death is known, that this category should not be added automatically. --EncycloPetey (talk) 03:39, 5 April 2018 (UTC)

I am comfortable with that suggestion. The hidden categorisation is sufficient for us to manage these. — billinghurst sDrewth 23:13, 5 April 2018 (UTC)

Removing obvious and unnecessary categorisation

I think that we no longer need to add the category:Author pages connected to Wikidata to author pages, as it is obvious from header link, and the sidebar link of the presence. We truly only need to track those that need to be added. — billinghurst sDrewth 13:43, 6 April 2018 (UTC)

Override

I would like to know what is meant by the category Category:Pages with override author‎. I also would like to know whether that overridden values needs to be removed or not. Adithyak1997 (talk) 10:38, 5 April 2019 (UTC)

@Adithyak1997: Without checking, I would guess that this refers to instances of {{Header}} that uses |override_author=. The parameter is used, for example, when a different displayed author name is desired (i.e. a piped link). These should not be removed. So far as I know, this module ((Module:Author) does not add that category. --Xover (talk) 11:21, 5 April 2019 (UTC)

Armoring against bad data on Wikidata

I just ran into a big honking red Lua error message on Author:Herod the Great. It turned out that somebody had changed Herod the Great (Q51672) such that its date of death (P570) had a sourcing circumstances (P1480) qualifier with no assigned value. That makes constructions like qualifier.datavalue.value.id blow up (qualifier.datavalue is nil), which breaks the code in:

	-- Extract circa (P1480 = sourcing circumstances, Q5727902 = circa)
	if statement.qualifiers ~= nil and statement.qualifiers.P1480 ~= nil then
		for _,qualifier in pairs(statement.qualifiers.P1480) do
			if qualifier.datavalue.value.id == 'Q5727902' then
				addCategory( 'Authors with approximate ' .. type .. ' dates' )
				year = 'c. ' .. year
			end
		end
	end

The fix should be something like:

	-- Extract circa (P1480 = sourcing circumstances, Q5727902 = circa)
	if statement.qualifiers ~= nil and statement.qualifiers.P1480 ~= nil then
		for _,qualifier in pairs(statement.qualifiers.P1480) do
			if qualifier.datavalue ~= nil and qualifier.datavalue.value.id == 'Q5727902' then
				addCategory( 'Authors with approximate ' .. type .. ' dates' )
				year = 'c. ' .. year
			end
		end
	end

@Samwilson: As this module is your baby I'll leave the specifics to you. --Xover (talk) 08:17, 20 October 2019 (UTC)

@Xover: Fixed, thanks! Sam Wilson 09:14, 20 October 2019 (UTC)

Propose to migrate "Category:Authors with missing death dates" to "Category:Authors without death dates"

Our Category:Authors with missing death dates lists living and dead people where there is no death date at WD. I would say that we should be calling them "without" as living people are not missing death dates. The issue that I have is that people then want to go and poke something into that field whether it is a helpful addition or not. That people poke "not known" as they don't know it or cannot find it readily is not particularly helpful either. Encyclopaedias have managed for decades to live with years of life missing, so we should be able to do so.

I propose that we make the change in our categorisation. — billinghurst sDrewth 04:17, 2 May 2021 (UTC)

@Billinghurst:  Support —Beleg Tâl (talk) 17:49, 28 September 2021 (UTC)

Floruit ++

I notice that the dates function does not support Wikidata properties d:P2031 "work period (start)" and d:P2032 "work period (end)". These essentially function like d:P1317 "floruit" but can be used if a single date doesn't make sense (for example J. C. Gorham fl. 1896-1905, the most precise value that d:P1317 can handle is 2. millennum). Can we update this module to support these statements? —Beleg Tâl (talk) 17:48, 28 September 2021 (UTC)

Ditto for the qualifiers d:P580 "start time" and d:P582 "end time" when used as qualifiers to a d:P1317 "floruit" statement —Beleg Tâl (talk) 17:50, 28 September 2021 (UTC)

@Samwilson: you are probably the best person to handle this, if it's not too much bother. Otherwise, I'll try to do the updates myself when I have time to puzzle it out. —Beleg Tâl (talk) 17:52, 28 September 2021 (UTC)

@Beleg Tâl: I have been finding it easier to more broadly indicate decades where someone is active. For our sort of work where we are showing it as a life period indicator, don't find the start/end components particular helpful. — billinghurst sDrewth 07:41, 3 January 2023 (UTC)

I agree with @Beleg Tâl on this; the current format works fine for authors with works in one decade, but in practice it doesn't display well at the moment when they've produced works over several decades (e.g. Author:Marie Pabke). Also not sure if floruit (P1317) is intended to be used this way (i.e. to make author pages here look clear at a glance); the description says "Can have multiple values if the subject has produced works in multiple years", so I guess decade precision isn't intended to be used that way (might be unhelpful for other uses of this data)? "fl. first year–last year" does seem clearer to me, as well as more precise. Please can this be looked at again? --Yodin^T 00:02, 13 March 2024 (UTC)

Binary categorisation based on presence of a property

Grouping the following together. We need the ability to categorise based solely on the presence of a property. I can see that this could be an ongoing possibility, so having that sort of section would be useful where we set up the targets for the property, rather than for the item. @Inductiveload, @Xover: — billinghurst sDrewth 06:04, 26 April 2023 (UTC)

Category:Botanists with author abbreviation

We have the above category, which we could automate based on the Y/ES presence of stated in (P248) and ignore the item populated (captured in the authority control, so nothing is needed in the data file, or if we do then we need a change of logic. — billinghurst sDrewth 07:39, 3 January 2023 (UTC)

Hmm. Not sure I follow. What does stated in (P248) have to do with author abbreviation? Without looking at the code my guess is that adding a cat based on the binary presence of a property should be fairly straightforward, but I'd want to be sure I understood the intended logic before diving in. Could you give a couple examples, including local pages (presumably Author: pages) where this should kick in? Xover (talk) 06:23, 27 April 2023 (UTC)

Ugh I mean botanist author abbreviation (P428) damn typoing and common used properties. We apply that categorisation in Template:Authority control, which is probably not the place from which we should categorise botanists for abbreviations, when we have a more regular place. [Understand why we did at the time, however, having categorisation occur in less and logical places should be a goal] — billinghurst sDrewth 11:12, 30 April 2023 (UTC)

Just so the coders know what it means for someone to have such an abbreviation: Any person, botanist or not, who has published, or co-authored a paper, establishing an officially recognized scientific name of a species, variety, family, etc. of any plant or group of plants, is assigned an official abbreviation to use in conjunction with reference citations for that scientific name. So not everyone with one of these abbreviations was necessarily a botanist. For example, in a case where a fossil was originally though to be a marine animal, but was later decided to be an alga, a zoologist or geologist may have a botanical abbreviation assigned to them. Or an entomologist who happens to co-author a plant species name as part of a team. Mycologists also get "botanical" abbreviations because names of fungi are governed by the same code, even though mycologists no longer consider themselves to be botanists. "Botanists with author abbreviation" is thus not an accurate name for the category. They are authors, in any field, who have been assigned an abbreviation for having their name attached to a "botanical" name. --EncycloPetey (talk) 03:24, 1 May 2023 (UTC)

Suggestion: Y/N use of pseudonym P742

Hi. I would like for us to be able to check whether the author has any use of pseudonym (P742). If there is any use of that property then we can trigger categorisation, and I haven't thought of a specific category name. — billinghurst sDrewth 05:58, 26 April 2023 (UTC)

Category:Authors with works published under a pseudonym perhaps? --EncycloPetey (talk) 22:41, 26 April 2023 (UTC)

Less concerned about the name at this point, and more interested in the logic. Guessing that a data file will do the naming, and future naming. — billinghurst sDrewth 23:22, 26 April 2023 (UTC)

Do we expect multiple and / or many of these? If it's pseudonym (P742) and one or two others then we just hard-code it and do it all in-module. If there are potentially lots of them then a /data approach is probably the best. Xover (talk) 06:30, 27 April 2023 (UTC)

I wasn't fussing whether someone had one pseudonym or multiple pseudonyms. I didn't see that it made a difference in my example.

The reason why I was mentioning a data file was once the logic is determined it could then be more readily applied (iteratively) in a data file for further binary options. This was rather than having to whack code in the module, the parent module being more critical and finicky, compared to a data file that doesn't really allow false code, and is more readily problem-solved. — billinghurst sDrewth 11:38, 27 April 2023 (UTC)

No, I mean: is it just pseudonym (P742) and a small number of similar properties (like nickname (P1449) etc.) that we currently envision triggering a category, or is the number of such properties essentially endless like professions, occupations, nationalities, and so forth? Rigging this to be configuration-based means more complex code and adds overhead, so if we don't actually need the mechanism to be that general and flexible it's usually better to just hard-code it.

Incidentally, /data isn't really a "configuration file" in a technical sense: it's executable Lua code. You can put literally any valid Lua code in there and it will get executed. No real difference with the main Module: there. The only thing that's different is the method we use to load and execute the /data subpage: the Scribunto extension makes sure "modules" (i.e. /data) loaded using that function are deduplicated and shared among multiple invocations on the same wikipage (which never really happens for Module:Author on Author: pages). Since it's a separate file it's easier to have non-programmers edit it safely, but that's just a matter of design and discipline not an inherent property. Xover (talk) 13:26, 27 April 2023 (UTC)

I understand that Module is LUA space, however, what we have there is a data file, and less places to put data, less ability to break things are all winners. With regard to "other properties", I hadn't gone into any deep thinking mode. Pseudonyms appears to be people highlight or seem to want to know about authors. We have numerous of these types of categorisation of binaries though on presence or on absence: image y/n; viaf data y/n, botanist abbreviation y, etc. — billinghurst sDrewth 11:20, 30 April 2023 (UTC)

We probably also wish to consider writer's writing under alternate legitimate names, be they be prior to marriage, post marriage, under a title (eg. Lord Muckety), etc. though these may be more as manual additions as less reliable to capture in WD. — billinghurst sDrewth 01:28, 1 May 2023 (UTC)

"strict" variable localization

I made a series of edits to remove all use of global variables except those added by preloaded libraries (i.e., those introduced by base Lua and Scribunto libraries). A key part of this in the introduction of require('strict') at the top of the module (replacing the former Module:No globals (Q16748603)). This protects against the introduction bugs that are extremely hard to debug later. —Uzume (talk) 18:35, 31 January 2023 (UTC)

already done — billinghurst sDrewth 11:16, 10 July 2023 (UTC)

stop adding categories for deprecated items

The module seems to pick up any added item and categorising irrespective of whether the item has been deprecated at Wikidata. Could we please only add categoristion for items that are preferred or normal, and not deprecated at WD.

Example: Author:Charles Augustus Maude Fennell where it is automatically picking up the Q145. [Yes, I know that we also have that categorisation too, however, that is by our manual operations, rather than through the item and the /data page.]

There are numbers of others, so please only take this as an example rather than the extent of the issue. Thanks. — billinghurst sDrewth 03:30, 6 August 2023 (UTC)

@Billinghurst: Done Xover (talk) 13:12, 6 August 2023 (UTC)

Thanks Xover. I note that in your tidy up that the properties now appear in the same list twice. Is that expected to mean that any new properties are to be added twice? Not possible to just have the one place? — billinghurst sDrewth 23:12, 6 August 2023 (UTC)

@Billinghurst: The old code was just left in place, but not used. I've now removed it so you'll only see the properties in one place now.

PS. I considered making which properties to look up controllable via Module:Author/data configuration to obviate the need for editing Module:Author itself when we want new properties. But it seems it's mostly you doing that work and you seem comfortable making the changes there so I've left that for later. We don't seem to be adding new properties at any great rate so we should be fine for a while. Xover (talk) 05:34, 7 August 2023 (UTC)