Template talk:Header

Archives: 2008; 2009; 2010; 2011

Year parameter

It has been mentioned that there are some problems with the year parameter:

1. In some cases, the year parameter is not used but an equivalent category has been added. Is this,
   1. Ignorance of the year parameter?
   2. A conscious choice? If so, why?
2. Some pages use the header template but have no year and should not be categorised as undated.
3. Some works have the year in the title. Displaying the year after such a title looks bad.

I have added two parameters to solve some of this, noyear and override_year. I haven't documented them yet as I have noticed some other problems and I'm not sure if they will be staying. Currently the header fails to correctly categorise any work with a year prior to 1000 AD. If you look at On the Parts of Animals by Aristotle, for instance, the year is given as 350 BCE but the category is Category:Works of uncertain date. I recently added a subroutine to the {{author}} template to solve something similar with author pages. This is both an announcement of the problem and a request for feedback. How do we want the year to function, both in terms of display and categorisation? - AdamBMorgan (talk) 02:24, 11 August 2012 (UTC)

• 1-2 — Learned behavior. If you take the fact the parameter is relatively new compared to the age & previous usage of the header template itself coupled with the long-standing practice on most of our sister wikis to add such date specific categories manually, its no wonder folks aren't clued into using the parameter here properly never mind utilizing the parameter at all. I don't know if it was even wise to try to ween folks off of adding the category manually via a template parameter in the first place.

  Regardless, if the consensus is that the year parameter and the year parameter alone is the accepted method for date categorization over manual categorization in moving forward, then a script should be drawn up & run to make that a reality on all the currently existing main space pages (just like the doing away with all the instances of header2 by scripting did). -- George Orwell III (talk) 02:50, 11 August 2012 (UTC)

• Adam, there are some pages that have not been migrated to the newer format, and some that have been added that way after the fact.
• There are some that are translations or works published over a range of years, and there is still some dispute whether the year to use in the header is the year of the original publication, or the year of the translation of the publication. I gave up arguing.
• Correct about the year in title, take it out, and use the year parameter. It will still be in the page title and not be an issue. Adding more complexity to parameters does not seem to be the way to handle it. Note the Title field != Page title
• as GO3 says, it is an existing maintenance task — billinghurst sDrewth 14:15, 11 August 2012 (UTC)

Copied from Wikisource:Scriptorium#Migration_from_Category:yyyy_works_to_year_in_header--Mpaa (talk) 21:42, 4 September 2012 (UTC)

I have implemented something that will hopefully solve this problem. I've added some stuff to the header template. The parameter "noyear" will stop the year being displayed in the header and the parameter "noyearcat" will stop the header template attempting to categorise a work by year (replacing my previous addition of "no_year" for the same, which would have been confusing if it stayed). There is also "override_year" which will put any text in the year part of the header but will no categorise it; this is an older addition. I've also mostly copied my subroutine from the author template to categorise works by year (overcoming the 1000 AD problem, where works before this date were ignored, and adding more flexibility). I may have to add to this as I've already seen "Medieval" used in one work and the "YYYY-YYYY" format in a few others. Hopefully this will allow Mpaa to continue; users can still add works by year categories manually, of course, and they will probably be caught in future sweeps like Mpaa's current work. - AdamBMorgan (talk) 01:07, 3 September 2012 (UTC)

Hi Adam. I have copied here the description of your changes. I think that it would be good to make a hidden category for pages with noyearcat, as done with override_author, so that we can keep track of where it is used.--Mpaa (talk) 21:42, 4 September 2012 (UTC)

OK. In fact, it's probably a good idea to track all three new parameters: Category:Pages with noyearcat, Category:Pages with noyear, and Category:Pages with override year. - AdamBMorgan (talk) 23:49, 4 September 2012 (UTC)

I am obviously on stupid pills, however we haven't documented anything yet, so I will just point the crooked finger. Which parameter is meant to be used to have the work categorised in works by year, however, to blind the display of the year function?

 | year       = YYYY
 | noyear     = yes

I am struggling to find why we would want to stop any work from being categorised by year, I had presumed that the proposal was only about the display component. — billinghurst sDrewth 05:44, 18 November 2012 (UTC)

Good point. I'd rather keep the flexibilty for whatever the future may hold though. Maybe we just don't document that parameter for the time being? -- George Orwell III (talk) 07:57, 18 November 2012 (UTC)

Regarding Categorization by year, there has been some talks in the past. The rational is that many of these pages would clutter Category:YYYY works. I made a trial on Presidential addresses (e.g. Presidential Radio Address - 1 April 1995). They are put in a separate Category which is then put under (Category:1995_works). I then stopped moving on waiting for feedbacks. And here they are :-) --Mpaa (talk) 08:10, 18 November 2012 (UTC)

That's right - I recall the discussion now. The parameter is primarily for running series or annual compilations that are better served by custom grouping under the year in question as a sub-folder rather than being peppered throughout the list of titles individually. -- George Orwell III (talk) 08:28, 18 November 2012 (UTC)

Ten years on, it seems that this page states "year = year of publication, adds work to the category for the year, see Category:Works by year." and yet that is not the case. At the very minimum, it seems that correcting the documentation would be in order. (I'll read the discussion above more closely before suggesting anything else.) -Pete (talk) 17:08, 21 October 2022 (UTC)

Microformat data

Firstly, can someone please explain the purpose of the section, set to display:none, headed "MICROFORMAT DATA"? It doesn't emit a w:microformat. Perhaps the documentation could be updated to explain it? {{Editprotected}}

Second, I have added proper w:hCard microformat markup, in the sandbox. This makes people's names machine-readable, with no visual change. Please will someone update the template. Pigsonthewing (talk) 11:42, 11 January 2013 (UTC)

Please check with User:Inductiveload about the microcode thing as he is probably the best person to address your concerns/changes. -- George Orwell III (talk) 19:52, 11 January 2013 (UTC)

The microformat is as specified at old.Wikisource:Microformat and is used for machine-readable data for use in generated eBooks. It is included in the header so that any content page is ready for being rolled into an ebook - this is more or less the limit of my involvement in the microformat data, other than interest. User:Tpt is the architect of the modern ebook system, and would be able to comment on modification to the system. Unfortunately, I don't have time to look at this or I would get into it myself. Inductiveload—talk/contribs 15:10, 14 January 2013 (UTC)

Thank you for the clarification. The term "microformat" has a specific meaning; can an alternative term be used, please? My edit request, above, remains current. Pigsonthewing (talk) 23:45, 16 January 2013 (UTC)

I have used the world "microformat" to call this set of html classes, created to allow machine (and the epub export tool in particular) to read metadata about Wikisource books easily, in order to explain shortly and easily to the community that this set have been created to follow the same objective and with the same basic patterns as the official microformats. So, yes, you have right, it's not a real microformat like hcard and the fact that it's only a set created to be used in Wikisource only should maybe be more explained. Feel free to update the page on oldwikisource.

@George Orwell III and Billinghurst : as the change of Pigsonthewing doesn't affect the hidden section containing microformat, there shouldn't be, I hope, any issue between the sandboxed version of the template and Wsexport. Tpt (talk) 21:11, 17 January 2013 (UTC)

Done copy and pasted from sandbox, diff looked fine. Thanks for the comments and assistance.

Postscript All assistance on getting our microformat components futureproofed is welcomed. As can been seen, generally speaking for most it is not our forté. — billinghurst sDrewth 07:25, 18 January 2013 (UTC)

Turned on internal "edition" parameter — seeking comment and looking to approval

{{plain sister}} has long had an "edition" parameter encoded into it, that was to replace the separately induced version of {{edition}}. The edition parameter, in either form, provides a prominent emblem through to the talk page of the article, the version that is included within the header parameter allows the emblem to be wrapped inside the same box as the interwiki links. Examples.

• Special:PermanentLink/2157323 old version with edition called by separate template
• Special:PermanentLink/4241618 old version with edition called by separate template, and wp link from within header template
• Special:PermanentLink/4241620 new version with edition and wp link called from within header template

I have turned it on to allow this to be viewed by the community, and to seek your opinion, and if opinion is favourable, then the approval of the community to deprecate the old template. [note: the old edition template is preferred means to note a source when a scan of a work is not provided.] — billinghurst sDrewth 10:49, 13 January 2013 (UTC)

Is there any community comment in favour or against the modification that I have put into place? Are people happy with the change to be implemented, and the flow-on components to take place (ie. {{edition}} to be deprecated and implementations to be merged), or is there other bits that the community would like to address. — billinghurst sDrewth 07:31, 18 January 2013 (UTC)

I like the use of this parameter rather than a separate template. It makes the header look neater where both are used. - AdamBMorgan (talk) 17:57, 18 January 2013 (UTC)

frWS moved header into Module

Phe says that Tpt migrated frWS's version of the Pages tag generated [Proofreadpage ]header template to the module: namespace. Can be seen at fr:Module:Header template. — billinghurst sDrewth 01:33, 24 March 2013 (UTC)

More translation info

Does anyone else think it a good idea to add information on the original language and the original language title to the header of translated works? We could use template:translations as an example. The result would look like:

De oratore (On Oratory)
by Marcus Tullius Cicero, translated by William Guthrie

--Jfhutson (talk) 02:06, 25 March 2013 (UTC)

To this time we have generally just put a Category like Category:Works originally in French — billinghurst sDrewth 07:39, 25 March 2013 (UTC)

I like this idea. Hesperian 07:42, 25 March 2013 (UTC)

Hmm; I'm not so sure now, per George below. It does seem to be giving the original rather too much prominence, considering it is a foreign-language work of no use to many readers. Plus there is that issue of a link clash on subpages. Hesperian 02:02, 26 March 2013 (UTC)

Confused. You are linking to the Latin Wikisource hosted base page where we usually find our base page link in your "translation". Is that on purpose? For base pages only? -- George Orwell III (talk) 01:19, 26 March 2013 (UTC)

The base page would be linked from "On Oratory," rather than "De oratore," but it doesn't matter to me whether the subpages link to the original language page. That might be overkill. However, I think linking to the original language of a work in the header for the base page (as is already done with template:translations) is helpful. --Jfhutson (talk) 02:27, 26 March 2013 (UTC)

I see the interwiki language link to the Latin version is not set so it does not appear in the left-hand menu(s). Is this why you feel this is needed? What happens to the practice of setting interwiki language links overall if this becomes a new practice? -- George Orwell III (talk) 03:09, 26 March 2013 (UTC)

The interwiki link would still be appropriate in addition, but the original source of the translation is not just another language version of the work, and it seems useful to point the reader to that original source. Honestly I could do without the link, as it might confuse some, but on balance I think it's a good idea. I'm more concerned with presenting the original language title in the header. If we do decide it's not appropriate to link the original source in the header, then the documentation at template:translations should be changed. --Jfhutson (talk) 03:34, 26 March 2013 (UTC)

Damn if you aren't confusing me more. Let's review to be sure we are all reading from the same "bible"....

To the best of my understanding, Template:Translations is the header used on pages that act like disambiguation pages do but applied for listing multiple works of similar title translated from one or more languages into English instead. It is used in the mainspace but not as a substitute or replacement of the normal Template:Header for specific works.

You probably should have started this discussion on Template:Translations talk page if that is the template you wanted to modify (which would be odd since its just for listing similar titles of works we have in English but have/are translations in/from other languages and your "title" link should already be listed in some way.

Now, are we any closer to figuring out what exactly you are proposing or not. -- George Orwell III (talk) 04:26, 26 March 2013 (UTC)

Jfhutson is saying that the header of a English-language translated work ought to include a link back to the foreign-language original. Jfhutson is saying that we include such a link on translations disambiguation pages via Template:Translations; that the way Template:Translations does it looks pretty good; that we could do it the same way in Template:Header; and that if we object to including such links in headers, then really we ought to remove those links from Template:Translations. Hesperian 04:38, 26 March 2013 (UTC)

Yes, that sounds right. Apparently I also need a translator. Basically it seems arbitrary to handle translation disambiguation page headers one way and translated work headers another. You get more information about the original language source if we happen to have multiple translations than if we have just one. --Jfhutson (talk) 19:50, 26 March 2013 (UTC)

This type of header will be needed in the new Translation: namespace rather than in mainspace. Once we've got the namespace sorted then we'll be looking to migrate works across, so I suggest work towards that header would be useful. Beeswaxcandle (talk) 02:53, 26 March 2013 (UTC)

I'd think information on the original source of a translation would be just as important for a published and transcribed translation as a wikisource one. --Jfhutson (talk) 03:34, 26 March 2013 (UTC)

Year parameters not working?

The documentation states that things like c/1999 is output as c. 1999 and 1999/? is output as 1999?. However, nether of these appear to be working. You can test this on any page but for convenience:

T0lk (talk) 22:27, 6 May 2013 (UTC)

I'll look into it. It should be doing the same thing the {{author}} template does. - AdamBMorgan (talk) 23:24, 6 May 2013 (UTC)

Layout options

Would it be awful to add the layout option inside of the header template? - Theornamentalist (talk) 03:24, 7 May 2013 (UTC)

Override editor doesn't seem to produce anything

I want to move the editor of Dictionary of Greek and Roman Biography and Mythology out of the Author field into the Editor field, but because he's one of several William Smiths, I need to use the override-editor field. But when I do I get nothing. Can someone have a look please? Beeswaxcandle (talk) 09:53, 23 June 2013 (UTC)

Look at it again... it seems to work just fine. Did you use the proper parameter/syntax?

| editor = | override_editor = [[Author:William Smith (1813-1893)|William Smith]]

I kept the Author override as well but set it to by Various Authors for completeness sake - you can blank the entire | Author = line if you wish; it won't affect the current editor portions at all. -- George Orwell III (talk) 21:14, 23 June 2013 (UTC)

Thanks George. I think I was using the proper parameter, but I now wonder if I used - instead of _. Anyway, it works correctly, so no further worries. Beeswaxcandle (talk) 23:20, 23 June 2013 (UTC)

Auto-Cat Bug with Year Parameter

The page Manfred,_a_dramatic_poem (1817) is triggering unexpected behaviour from this template for auto-cat by year. Can someone have a look to see how to fix the bug? Thanks - DutchTreat (talk) 09:50, 5 October 2013 (UTC)

This may have been a problem with a recent edit to this template, which is now fixed but which will take a while to worth through to all cached pages. I purged the cache (append ?action=purge to the URL) of the page you mention above, and the ugly misformed header returned to normal. Has it for you? — Sam Wilson ( Talk • Contribs ) … 10:03, 5 October 2013 (UTC)

Working fine for me, Sam. Thanks -- DutchTreat (talk) 11:06, 6 October 2013 (UTC)

Please add to Category:Exclude in print

Could you please add this template to Category:Exclude in print? This should get rid of the header from the PDF files as Book Creator looks for that category. I would also consider adding noPrint to the class of the div, so class="headerRaw.noPrint ws-noexport" to suppress it from printing if someone just happens to hit print on a page. The Haz _talk 05:28, 3 February 2014 (UTC)

Header for journal articles

I am working on importing scholarly articles, for which {{header}} does not seem to have been designed. Is there another template for such purposes? If not, should I try to start one or would it be better to incorporate the necessary parameters (e.g. journal name, DOI) here? Thanks for any pointers. -- Daniel Mietchen (talk) 21:14, 27 May 2014 (UTC)

@Mietchen: What specifically is not suitable about the template? fields? display? We wish for all header templates to utilise the components of it as a minimum though allow variations based upon it, eg. {{DNB00}} and other variations. So maybe think about what it is that you specifically require, and how it can leverage what currently exists, and what extra that you require, eg. DOI would be easy to add for your need. I would suggest that within your project space you look to design something, and seek feedback so we can hack at it to meet all our varied needs.

One thing to note with our template design is that it is a nested approach, such that something like {{plain sister}} is inhaled and used in a similar way across the other ns. Also we are now grappling with the best way to utilise Wikidata, so you may also consider what among your works, or the components of the work you would want in or out of WD. — billinghurst sDrewth 05:18, 30 May 2014 (UTC)

If you can make sense of this template coding ...

Can you update Template:Versions to use the override author as is used in here? I looked at the underlying code but it was beyond me .BirgitteSB 12:07, 6 June 2014 (UTC)

Change to Support More than 10 Categories

The following discussion is closed and will soon be archived:

Done

This change is currently made in the sandbox, using the underlying parserfunction #invoke:String which calls on Module:String's "replace" operation. Three replacements are made, nested inside one another, in order to handle any number of categories listed in the typical fashion with delimiter of " / " and using the limited pattern matching provided via Lua. You can see the exact text:

Categories
    -->{{#invoke:String|replace|{{#invoke:String|replace|{{#invoke:String|replace|{{{categories}}}|([%w%s-]-)%s?/%s?|[[Category:%1]]|plain=false}}|([%w%s-]-)$|[[Category:%1]]|plain=false}}|%[%[Category:%]%]||plain=false}}<!--

See Template:Header/sandbox/sample and Template:Header-wpoa/sandbox/example for use of the modified header. I would like to implement this into the Template:Header, which would be a convenience for any document with a listing of over 10 categories. Posting for any feedback. Mattsenate (talk) 10:48, 18 September 2014 (UTC)

 Support Changes seem to work, and they improve upon existing functionality be moving to supported LUA. — billinghurst sDrewth 00:20, 19 September 2014 (UTC)

 Support Looks good to me too. -- Daniel Mietchen (talk) 23:06, 27 September 2014 (UTC)

Cool, I made one minor improvement, adding an #if parser function to test if there are any categories used, which cleans up the test cases Template:Header/testcases very well. You can see the full diff from the sandbox here. If this doesn't pose any issue, then hopefully someone with admin privileges can make this change at next convenience. Here is the exact text again:

Categories
-->{{#if:{{{categories|}}}
    |{{#invoke:String|replace|{{#invoke:String|replace|{{#invoke:String|replace|{{{categories}}}|([%w%s-]-)%s?/%s?|[[Category:%1]]|plain=false}}|([%w%s-]-)$|[[Category:%1]]|plain=false}}|%[%[Category:%]%]||plain=false}}
}}<!--

-- Mattsenate (talk) 03:41, 29 September 2014 (UTC)

 Comment the sandbox had had other modifications within it that were not included within the update, just the components of Mattsenate regarding categories — billinghurst sDrewth 10:39, 21 October 2014 (UTC)

As discussed in detail at Wikisource:Scriptorium/Help#categories_link_in_header_broken the above code failes to accommodate several existing Category names: as such I would like to make a case for further replacing:

Categories
-->{{#if:{{{categories|}}}
    |{{#invoke:String|replace|{{#invoke:String|replace|{{#invoke:String|replace|{{{categories}}}|([%w%s-]-)%s?/%s?|[[Category:%1]]|plain=false}}|([%w%s-]-)$|[[Category:%1]]|plain=false}}|%[%[Category:%]%]||plain=false}}
}}<!--

with

Categories
   -->{{#if:{{{categories|}}}
|[[Category:{{#invoke:String|replace|{{{categories}}}|(%s)/(%s)|%1]][[Category:%2|plain=false}}]]}}<!--

AuFCL (talk) 20:53, 30 December 2014 (UTC)

@AuFCL, @Mattsenate, @Billinghurst, @Daniel Mietchen: Sorry to resurrect this, but there are still problems with categories like Category:Smith, Elder & Co. that are not working with the current slash-splitting logic. I think AuFCL's code above fixes this (and it's currently in the sandbox); shall I go ahead and add this? All the testcases pass, from what I see. Sam Wilson 06:59, 20 June 2017 (UTC)

Add searchaux class to previous and next links

The "searchaux" HTML class shall be added to div.gen_header_backlink and div.gen_header_forelink, thus almost removing it's content (i.e. back. and forw. article names) from MediaWiki search index. -- Vlsergey (talk) 05:24, 21 June 2015 (UTC)

Added by who? when?

Can you please clarify a bit and/or link to the original discussion/diff. Thanks. -- George Orwell III (talk) 07:13, 21 June 2015 (UTC)

@George Orwell III: Would you try to search, for example, 1911 Encyclopædia Britannica Music, you will have the following snippets:

• 1911 Encyclopædia Britannica, Volume 25 Spheres, Music of the Spheres of Influence→ See also Spheres, Music of the on Wikipedia; and our 1911 Encyclopædia
• officer) 1911 Encyclopædia Britannica, Volume 22 Recorder (music) Rector→ See also Recorder on Wikipedia; and our 1911 Encyclopædia Britannica disclaimer
• Encyclopædia Britannica, (11th ed.), 1911 “Rousseau, Jean Jacques” in Encyclopædia Britannica, (11th ed.), 1911 “Tallis, Thomas” in Encyclopædia Britannica, (11th

As you can see those snippets contain text (bolded by me) that is not relevant to articles themselves (i.e. this text is not part of article and not linked with it by any search-related sence). Such part of result text shall be excluded both from search snippets and index database. Special HTML class searchaux can help with that. See https://www.mediawiki.org/wiki/Help:CirrusSearch#Auxiliary_Text for technical details. -- Vlsergey (talk) 07:56, 21 June 2015 (UTC)

Ahhh.... I get it now & makes sense. Thanks. I added the class but I doubt it will take effect right away (caching). -- George Orwell III (talk) 08:22, 21 June 2015 (UTC)

Need to rejig to get WD link where only link

If the wikidata link is the only link in template, then it is failing to manifest due to the link being served from WD and not a hard parameter in the template. Either we just need to force wikidata on all occasions, or we need a better means to make something to be found by the template. Where there is other parameter data present, then it does appear due to that forcing the parameter. — billinghurst sDrewth 14:34, 17 July 2015 (UTC)

I think I follow you as to what you're observing but I'm pretty sure the "problem" lies with the semi-LUAization of the {{Plain sister}} template rather than anything to do with the Header template. Since that step was taken, the sidebar's Wikidata item has also re-enforced it's dominance regardless of the presence of Plain sister parameters or not (the same can be said about the presence of AC template params or the lack thereof). This makes the restoration of the once familiar yet technically crippled behavior a bit problematic to say the least.

The other "problem" with the current application of Plain sister and the current Header layout is that they fail miserably in mobile view. At some point we'll need to reconsider making Plain-sister a drop down, infobox-ish menu-list or a maybe a floating lightbox (e.g. something similar to the bubble you get for marking a revision patrolled).

Either way, I'm not sure how to proceed on @Billinghurst:'s point other than to bring @Tpt: in on the discussion. -- George Orwell III (talk) 23:56, 18 July 2015 (UTC)

The current logic of {{header}} is:

• If at least one sister-project parameter is filled in, show {{plain sister}};
• otherwise, show nothing.

It could be improved like this:

• If at least one sister-project parameter is filled in, show {{plain sister}};
• otherwise:
  • if the page is connected to Wikidata, show {{plain sister}};
  • otherwise, show nothing.

By the way, {{#invoke:Wikibase|id}} returns no entity if the page is not connected to Wikidata.--Erasmo Barresi (talk) 18:37, 25 July 2015 (UTC)

@Erasmo Barresi: as that as text? So are you suggesting that if it returns something other than "no entity" that we can display "plain sister" template, and then lead into the other test aspects? — billinghurst sDrewth 23:36, 25 July 2015 (UTC)

@Billinghurst: Right, as plain text. What do you mean by "the other test aspects"?--Erasmo Barresi (talk) 09:20, 26 July 2015 (UTC)

Test one is negative test for WD link, if no link, run through the plain sister components looking for other components, if WD link exists, display box, bring back WD sister links, and check for overrides of WD data, knowing that if there is a WD item, then it should be picking up the sister links, etc. — billinghurst sDrewth 11:46, 26 July 2015 (UTC)

I think the change can be made right now as it is completely uncontroversial.--Erasmo Barresi (talk) 14:39, 28 July 2015 (UTC)

Just tell me what exactly needs editing or changing and I'll do it. -- George Orwell III (talk) 18:42, 29 July 2015 (UTC)

@George Orwell III: Sorry for the delay, here's it, but please check it beforehand. Current code:

Current code

<!--

   Sister project links (only #if we need them)
   -->{{#if:<!--
	-->{{{disambiguation|}}}<!--
	-->{{{edition|}}}<!--
	-->{{{portal|}}}<!--
	-->{{{related_author|}}}<!--
	-->{{{wikipedia|}}}<!--
	-->{{{commons|}}}<!--
	-->{{{commonscat|}}}<!--
	-->{{{wikiquote|}}}<!--
	-->{{{wikinews|}}}<!--
	-->{{{wiktionary|}}}<!--
	-->{{{wikibooks|}}}<!--
	-->{{{wikilivres|}}}<!--
	-->{{{wikidata|}}}<!--
	-->{{{wikivoyage|}}}<!--
	-->{{{wikiversity|}}}<!--
	-->{{{wikispecies|}}}<!--
	-->{{{meta|}}}<!--

    -->|<!--

     -->{{Plain sister<!--
	-->| disambiguation = {{{disambiguation|}}}<!--
 	-->| edition = {{{edition|}}}<!--
	-->| portal = {{{portal|}}}<!--
	-->| related_author = {{{related_author|}}}<!--
	-->| wikipedia = {{{wikipedia|}}}<!--
	-->| commons = {{{commons|}}}<!--
	-->| commonscat = {{{commonscat|}}}<!--
	-->| wikiquote = {{{wikiquote|}}}<!--
	-->| wikinews = {{{wikinews|}}}<!--
	-->| wiktionary = {{{wiktionary|}}}<!--
	-->| wikibooks = {{{wikibooks|}}}<!--
	-->| wikilivres = {{{wikilivres|}}}<!--
	-->| wikidata = {{{wikidata|}}}<!--
	-->| wikivoyage = {{{wikivoyage|}}}<!--
	-->| wikiversity = {{{wikiversity|}}}<!--
	-->| wikispecies = {{{wikispecies|}}}<!--
	-->| meta = {{{meta|}}}<!--
     -->}}<!--
   end #if we need plain sister project links
   -->}}

New code:

New code

<!--

   check if page is connected to Wikidata (#ifeq)
   -->{{#ifeq:{{#invoke:Wikibase|id}}|no entity<!--

        if page is not connected to Wikidata, only show plain sister if at least one of its parameters is filled in
        -->|{{#if:<!--
        -->{{{disambiguation|}}}<!--
        -->{{{edition|}}}<!--
        -->{{{portal|}}}<!--
        -->{{{related_author|}}}<!--
        -->{{{wikipedia|}}}<!--
        -->{{{commons|}}}<!--
        -->{{{commonscat|}}}<!--
        -->{{{wikiquote|}}}<!--
        -->{{{wikinews|}}}<!--
        -->{{{wiktionary|}}}<!--
        -->{{{wikibooks|}}}<!--
        -->{{{wikilivres|}}}<!--
        -->{{{wikidata|}}}<!--
        -->{{{wikivoyage|}}}<!--
        -->{{{wikiversity|}}}<!--
        -->{{{wikispecies|}}}<!--
        -->{{{meta|}}}<!--

        -->|<!--

        -->{{Plain sister<!--
        -->| disambiguation = {{{disambiguation|}}}<!--
        -->| edition = {{{edition|}}}<!--
        -->| portal = {{{portal|}}}<!--
        -->| related_author = {{{related_author|}}}<!--
        -->| wikipedia = {{{wikipedia|}}}<!--
        -->| commons = {{{commons|}}}<!--
        -->| commonscat = {{{commonscat|}}}<!--
        -->| wikiquote = {{{wikiquote|}}}<!--
        -->| wikinews = {{{wikinews|}}}<!--
        -->| wiktionary = {{{wiktionary|}}}<!--
        -->| wikibooks = {{{wikibooks|}}}<!--
        -->| wikilivres = {{{wikilivres|}}}<!--
        -->| wikidata = {{{wikidata|}}}<!--
        -->| wikivoyage = {{{wikivoyage|}}}<!--
        -->| wikiversity = {{{wikiversity|}}}<!--
        -->| wikispecies = {{{wikispecies|}}}<!--
        -->| meta = {{{meta|}}}<!--
        -->}}<!--

        -->}}<!--

        if page is connected to Wikidata, always show plain sister
        -->|{{Plain sister<!--
        -->| disambiguation = {{{disambiguation|}}}<!--
        -->| edition = {{{edition|}}}<!--
        -->| portal = {{{portal|}}}<!--
        -->| related_author = {{{related_author|}}}<!--
        -->| wikipedia = {{{wikipedia|}}}<!--
        -->| commons = {{{commons|}}}<!--
        -->| commonscat = {{{commonscat|}}}<!--
        -->| wikiquote = {{{wikiquote|}}}<!--
        -->| wikinews = {{{wikinews|}}}<!--
        -->| wiktionary = {{{wiktionary|}}}<!--
        -->| wikibooks = {{{wikibooks|}}}<!--
        -->| wikilivres = {{{wikilivres|}}}<!--
        -->| wikidata = {{{wikidata|}}}<!--
        -->| wikivoyage = {{{wikivoyage|}}}<!--
        -->| wikiversity = {{{wikiversity|}}}<!--
        -->| wikispecies = {{{wikispecies|}}}<!--
        -->| meta = {{{meta|}}}<!--
        -->}}<!--

   end #ifeq
   -->}}

--Erasmo Barresi (talk) 10:41, 3 August 2015 (UTC)

OK, I swapped the new code into the template. @Billinghurst, @Erasmo Barresi: is it working like we hoped? -- George Orwell III (talk) 23:42, 4 August 2015 (UTC)

Seems to have done the trick. [1]. Though I will go back and do some testing when I can remember which were not showing for me. Thanks to you both for the work. — billinghurst sDrewth 00:23, 5 August 2015 (UTC)

Looks good, links showing where expected, and no links where not expected and other headers in play. Calling that a success. — billinghurst sDrewth 00:27, 5 August 2015 (UTC)

Sources

Where is the source parameter? Sources have some relevance here, no? And why is only the year provided? --Qualitatis (talk) 12:27, 8 August 2015 (UTC)

@Qualitatis: We are not the encyclopaedia, we leave that to Wikipedia, and as such the exact dates are not a requirement for us to record each author's work(s).

Where someone is renowned/notable, the encyclopaedia is sufficient and we link to the article at Wikipedia. We also link to Wikidata where the exact date is usually recorded. On the occasions where someone is not renowned, then we may record research for the author on the author's talk page. That said, the years of life are usually sufficient to identify each author, and to identify the copyright status of someone's work. — billinghurst sDrewth 13:30, 8 August 2015 (UTC)

Can we look to utilise template:TextQuality display methodology

In template:TextQuality we use some CSS to poke the old style display icon to the top right. Now with the ability to poke the work's status into Wikidata, we should now be able to perform the same magic through the header automatically. (Separately working on how we identify and update such statuses to WD from here). I know that WD has a component to add it to interlanguage links, however, I think that we should be looking to moving towards how can utilise those aspects. — billinghurst sDrewth 06:42, 25 August 2015 (UTC)

Beg to differ... the header template is doing more than it should be already - this can be done by wikidata or separate Lua scripting.

The real impediment to get something like that to work on the fly is the lack of 0, 25, 50, 75, 100% indicators in svg format that will render crisply from mobile phones to workstations. Commons has merged/deprecated all the individual efforts to do just that however - leaving us with a broken set of foundation images to build from as a result. -- George Orwell III (talk) 20:35, 25 August 2015 (UTC)

You tell me which images at Commons that we need retrieved, and I will organise their resurrection.

I have asked in the phabricator:T97014 card for instruction for the placement of the work's status, and featured text, and I will see what results. Thanks for the pointers. — billinghurst sDrewth 04:40, 26 August 2015 (UTC)

Parameter redux

1. Build list of all possible template parameters

• title
• publisher
• location
• year
• author
• override_author
• translator
• override_translator
• editor
• override_editor
• illustrator
• override_illustrator
• contributor
• override_contributor
• section
• sub_section
• previous
• next
• notes
• extra_notes

Preliminary list of all header template parameters (existing & suggested) not including derivatives for the DNB and the like. Add em' if you got 'em. -- George Orwell III (talk) 01:14, 26 August 2015 (UTC)

Anthologies may have one overall editor/translator and different author/original author for different pieces. Same for journals/magazines. Currently, showing this properly requires complicated process (as done by Hesperian in Proceedings of the Royal Society of London/Volume 60/On the Determination of the Wave-length of Electric Radiation by Diffraction Grating). When a collection of translations is published as the translator's work (e.g. A Sheaf Gleaned in French Fields), the translator's name needs to be shown as the main author, so there should be a section_author parameter for the different pieces. An anthology may also be published as the work of the overall original author with different translators for different pieces (e.g. Mashi and Other Stories) and there should be a simple way of reflecting this. Same process required for an anthology published under the name of the editor/compiler and different authors for different pieces, e.g. The Bengali Book of English Verse. Then there is the matter of foreword/preface/introduction by a different author, whose name needs to be shown in the header, but not as the main author. Within a work, there may be an isolated piece by a separate author and separate translator (e.g. Nil Durpan/Biographical Sketch) and justice needs to be done to that piece. All these ramblings come down to the parameters section_author and section_translator. Hrishikes (talk) 01:35, 26 August 2015 (UTC)

@Hrishikes: there is means at WD to appropriate record that data against appropriate records, though I think that it would be more complex than free coding it, plus less time consuming especially if the WD item(s) need to be created AND one is transcluding the work here. I can see the bail out "TOO HARD" button being pressed, so that probably has to stay as is until we have the better ability to push/pull the data to and from a work, and that seems a while away. — billinghurst sDrewth 04:54, 26 August 2015 (UTC)

Further fields to consider

• contributor_translator where a translator did the subpart
• contributor_foreword (though we may just be happy with contributor reuse)
• portal
• defaultsort
• year of original work (where the work is a published translation)

??? Any field in the Index: template?

There is no printer field in Index, of which I sometimes felt the need when publisher is not mentioned. Moreover, the year has to be exact, no "circa" option, but sometimes the year is not exactly known and even at IA, the year is given within square brackets or with a query mark. Here we don't have any such option. A note parameter should also be there; now I use the volumes field for the same. Hrishikes (talk) 05:39, 26 August 2015 (UTC)

@Hrishikes: The year field can take something like "1850s", in fact it can take any of the categories subsidiary to Category:Works by date I cannot say I have tried circa per the style used for authors, but do try c/1850 and see whether it works — billinghurst sDrewth 06:19, 26 August 2015 (UTC)

@Billinghurst: I have checked. Both 1850s and c/1850 are unacceptable. Hrishikes (talk) 06:46, 26 August 2015 (UTC)

Just in case someone else reads this and was confused (as I was!) Hrishikes is referring to the entry rules of the Index: page ("Year of publication" input field of type="number" and thus forms like "c/1850" may not normally be entered at the point of Index:-page edit.) However the {{header/year}} helper routines actively cater for "c", "c.", "circa" (but not interestingly "fl." or variants? Author-specific usage?) and the chain appears to be robust in presence of dates containing indications of uncertainty. AuFCL (talk) 23:00, 26 August 2015 (UTC)

As far as I'm concerned the "year" parameter should be tied to the "edition" in question be it the xth printing run in the original language of the author or the xth printing run in another language by a translator. In my view for example, things like the year of original work (where the work is a published translation) is not WD-to-edition relevant but remains "noteworthy" for proper attribution and/or academic purposes nevertheless. Tid-bits like that should be provided in the {{textinfo}} template at best or the Notes= field at worst (imho).

I acknowledge there is an issue with approximate date inputs but what, if anything, should be done about it needs further discussion. -- George Orwell III (talk) 01:17, 28 August 2015 (UTC).

Point on header template "load"

GOIII, I am presuming that we need a LUA developer to help reduce the "header" load, and for that we need to contribute to the required fields, and some case studies to use. Yes? I will think some more on it. — billinghurst sDrewth 04:54, 26 August 2015 (UTC)

In my vision the answer is ultimately, yes -- there will be some need to create one or more base LUA scripts that will handle some of what I view as the extraneous "...if ...then" expressions concerning overrides and categorization steps for example but, as Hrishikes points out, there will be some need to retain some ability within the header template to accommodate the more "complex" variants of author/translator/compiler information at the same time. The question of "focus" on the various namespace header templates, however, might be misplaced in that vision and partly why I felt simple parameter selection was the appropriate place to start discussing our options regardless. It very well might be "better" to rely on the Index: "template" to retain these parameters and matching input info primarily rather than the header template but the current Index: template itself is "inappropriately" built/applied based on some aspect of the PR extension via the MediaWiki namespace rather than called from the template namespace making it quite harder to manipulate compared to a "normal" template.

We should look into the possibilities and refinement of the Index: template as well -- imho, just not at this first simple stage where we revisit the current and suggested parameters inclusion or not and why. -- George Orwell III (talk) 01:00, 28 August 2015 (UTC)

If statements to exclude non-main ns

With the template we have numerous uses not in the main ns, some as maintenance, some as not. While perfection says that we should clean up the non-main ns use, practicality says maybe we can just ignore those works so we don't get hits inside categories like Category:Works with non-existent author pages. Any disagreement? — billinghurst sDrewth 15:16, 6 September 2015 (UTC)

Translator = not mentioned is giving warning template

Traditionally when using this template with Translator = not mentioned it was the one variation that was not meant to give the the warning template {{no translator info}}. However at this time it is not functioning that way, see Magnificat (Church of the Visitation). It would be great if someone could look at the #switch in the template and resolve the problem. Thanks. — billinghurst sDrewth 07:21, 25 December 2015 (UTC)

How about asking Beleg Tâl? Nothing whatsoever to do with {{header}} AuFCL (talk) 08:04, 25 December 2015 (UTC)

@Billinghurst: After dicking around for a half hour assuming this issue was actually verified like a proper trouble report vs. a knee-jerk reaction -- I find nothing wrong with the template. Please remove the damn banner from the source page itself Page:Church of the Visitation IMG 0650.JPG/1. :( -- George Orwell III (talk) 00:15, 29 December 2015 (UTC)

The header is now appearing at the bottom of pages instead of at the top.

The header is now appearing for me at the bottom of pages such as Embarrassments (New York: The Macmillan Company, 1897) and Embarrassments (New York: The Macmillan Company, 1897)/The Figure in the Carpet. Hesperian 13:29, 31 December 2015 (UTC)

Thanks for fixing that George. Hesperian 15:13, 31 December 2015 (UTC)

Yeah sorry for not touching back sooner - it took forever to cache thru some the attempted changes and (of course) I managed to step on a change without it being truly reflected yet and so on.

FYI... Rendering just got it "back" to where it was suppose to be just before I sent this so now I'm seeing what you're seeing. Sorry again for that. -- George Orwell III (talk) 15:23, 31 December 2015 (UTC)

Multiple authors?

How to handle when a work has two or more authors, for instance: Women's suffrage proclamation, Oregon 1912? -Pete (talk) 08:38, 5 January 2016 (UTC)

@Peteforsyth: Substitute override_author for author (you will need to explicitly make links if required.) An example of this is here. AuFCL (talk) 08:52, 5 January 2016 (UTC)

it basically becomes a free text field, so you need all the relevant preceding text and wikilinks. Note that this also works for override_translator and override_contributor — billinghurst sDrewth 05:38, 6 January 2016 (UTC)

Understood. I realize I've asked this before...I'm going to go tweak the docs page so hopefully I don't have to if I forget again! Thanks for the help. -Pete (talk) 05:41, 6 January 2016 (UTC)

Maintenance category for naval dictionary

{{editprotected}}

Please add this here. It should add relevant pages to Category:A Naval Biographical Dictionary. Jura1 (talk) 16:16, 1 May 2016 (UTC)

With respect it is an amazingly bad idea to abuse a common-purpose template like this.

In any case the same effect can be achieved (should there be a need) as the contents of this proposed category by use of a dynamic enquiry such as this. AuFCL (talk) 06:06, 2 May 2016 (UTC)

Not done—as advised above and elsewhere, this is too specific for this general template that is already very busy. Some similar works have their own version of the template that enables categorisation. See {{DNB00}} for an example. Beeswaxcandle (talk) 06:45, 2 May 2016 (UTC)

They are all subpages of a work so can be picked up via Special:PrefixIndex/A Naval Biographical Dictionary/, so we can pick them up easily that way, or if necessary, create a specific header template based on this template, as done at {{DNB00}}. What specifically are you trying to achieve @Jura1:? — billinghurst sDrewth 07:28, 2 May 2016 (UTC)

The tools at Wikidata don't work well with Whatlinkshere or PrefixIndex. It's needed just on a temporary basis. I'm trying to help GreyHead to add them to Wikidata. The code can be removed in a week or two. It wont affect any pages not related to the dictionary. Speaking of "abuse" sounds somewhat disproportionate. Jura1 (talk) 07:35, 2 May 2016 (UTC)

I have been trying to find a way of following up on Beeswaxcandle's suggestion of adding the Naval Biographical Dictionary entries to WikiData - preferably without editing 5000 entries manually. I just tried running PetScan using Special:PrefixIndex/A Naval Biographical Dictionary but got zero results. I have no WikiData experience and find the docs pretty technical so any practical assistance is welcome. GreyHead (talk) 08:35, 2 May 2016 (UTC)

I tested it yesterday and it worked until an admin here removed the category. It seems really odd that people around here ask volunteers to do manually what available MediaWiki functions can do automatically. Jura1 (talk) 08:43, 2 May 2016 (UTC)

I've started to add the Categories manually using both 'A Naval Biographical Dictionary' & 'Royal Navy officers'. That lets me give all the pages the first category and just the officers the second, Using the two in PetScan pulls over the list of officers (29 so far) successfully. GreyHead (talk) 09:29, 2 May 2016 (UTC)

If you plan to work on them at Wikidata, maybe you just want to restore my edit on Template:Larger. I would check/fix any problems that may occur. Once done, it can be removed. I don't think you should attempt to add the category manually. Jura1 (talk) 10:32, 2 May 2016 (UTC)

Your suggestion is an ugly hack, and it will (unnecessarily) propagate through tens to hundreds of thousands of pages, then need to be undone. I have generated a list of 5003 lines at User:Billinghurst/Naval biography Note that some will not be biographies and should be weeded out. We should get the tools that grab pages to be updated to work with prefixindex, or can be grabbed from a SQL query. @Charles Matthews: can you please poke Magnus to see if he can make appropriate updates for the WSes. — billinghurst sDrewth 11:08, 2 May 2016 (UTC)

It works. If you prefer to see the category directly on the pages, would you add it? For Wikidata it works even if all pages are in one category. Jura1 (talk) 11:15, 2 May 2016 (UTC)

Simpler category handling

I'd like to suggest a change to this template, to make it possible to have categories with ampersands and full stops in them. For example, this edit removed Costumes of the Canary Islands from Category:Smith, Elder & Co.‎.

Basically, the matching-pattern just needs to find all sequences of characters that end in slashes, and turn them (minus the final slash) into categories. This wouldn't work usually because it'd miss the last-defined category (because usually no one puts a slash after it), so we get around this by just adding a slash to the input string:

{{#invoke:String|replace|{{{categories}}}/|([^/]+)/*|[[Category:%1]]||plain=false}}

I've added test cases for categories, and haven't found any situations in which this doesn't work. Can you see what you think?

Thanks! —Sam Wilson 08:36, 25 July 2016 (UTC)

@Samwilson: Sounds reasonable (though I am still old fashioned and use the gadget to add them to the base). Can we also think about he we manage portals with a forward slash? Currently we cannot as the slash is also the separator. — billinghurst sDrewth 11:35, 17 December 2016 (UTC)

Done I've made this change. @AuFCL, @Mattsenate, @Billinghurst, @Daniel Mietchen: I had forgotten about this thread when I wrote the above just now. :-) Sam Wilson 07:11, 20 June 2017 (UTC)

Conversions to do

Following templates are headers templates that do not use this parent.

• Template:Potus-eo-phil. Also think that it could do with a rename as it is not really POTUS when it is for Philippines President.

— billinghurst sDrewth 23:08, 25 June 2017 (UTC)

Contributor and non-existent pages; code change required

In the template if the author field brings up a red link, then it categorises to Category:Works with non-existent author pages. As I have been moving articles to use the contributor field (more accurately represent) it would be useful if we could also apply that categorisation to that parameter as well. Adding to same category also seems the better way than creating another maintenance cat for no clear benefit. — billinghurst sDrewth 10:52, 6 January 2018 (UTC)

Italics within tags in section parameter causes misnested tags

Any page that uses italics within other tags inside the section header will cause a misnested tag linter error. This is throwing thousands of errors via templates like {{EBDHeader}} which use the section field like that. For example:

{{header
 | title      = Foobar
 | author     = 
 | translator = 
 | section    = <small>''foo''</small> 
 | previous   = 
 | next       = 
 | year       = 
 | notes      = 
 | categories = 
 | portal     = 
}}

This is because in the microformat section, this expands, via ''{{{section}}}'' to:

''<small>''foo''</small>''

leading to

<i><small></i>foo<i></small></i>''

Which is indeed horrible mismatched tags. I suggest to use explicit italic tags in the microformat section to avoid tripping the parser up with wiki-markup like this: <i>{{{section}}}</i>

This will also italicise all the section in the microformat, regardless of ''italics'' in the section parameter, rather than inverting them. The tags aren't removed, but that's how nested "i" tags are rendered.

It might also make sense to generally avoid (ab?)using the section field for TOC-type content in headers, since it's all within a SPAN anyway, and any block formatting would be technically wrong, plus it's semantically wrong and it's going to produce wierd microformat data, etc. But this is incidental to the issue at hand. Inductiveload—talk/contribs 21:06, 21 January 2018 (UTC)

Section title parameter?

Many pages have header section titles like this:

 | section    = PART IV. — MOTHER STORIES</br>
Days and Nights, Weeks and Months and Years, Time and the Weather, etc.

This is slightly problematic from a linter point of view (as section is a span parameter, and BR upsets it if there's a following line break). Easily fixed, but it feels natural to add the line break.

However, it's also less than ideal from a semantic point of view, as well as the practical point that there are many ways people format this (bold first line, colons, etc). Would it be better to have a separate parameter? Then you can specify like this:

 | parent_section    = PART IV. — MOTHER STORIES
 | section = Days and Nights, Weeks and Months and Years, Time and the Weather, etc.

I suppose you can either push the "parent" "up", as above, or the current page "down" to be a subsection:

 | section     = PART IV. — MOTHER STORIES
 | sub_section = Days and Nights, Weeks and Months and Years, Time and the Weather, etc.

That's just a matter of naming, really. Anyway, just a thought to standardise and improve data quality. Inductiveload—talk/contribs 17:34, 24 January 2018 (UTC)

Non-existing ... to one category?

@Beleg Tâl: With the new categorisation, do we need to differentiate to all those additional categories? They are all lacking author pages and resolved by adding an author page, the originating field itself isn't important, and they are all author: namespace pages. At the moment those categorisations are slow to update when we actually add the linked author page, to the point that I have wikisource traversing that category on a daily basis to shove the link check. I would prefer that the categorisation was all to the same page rather than seaparate. I don't see particular value in the multiple categories. — billinghurst sDrewth 02:57, 7 March 2018 (UTC)

I didn't want to change the existing categorization in case it broke anything, but I have no objection to merging the categories if you think that is preferable. —Beleg Tâl (talk) 16:12, 7 March 2018 (UTC)

Causing a major lint error

According to Wikisource:Scriptorium#Tech_News:_2018-19, it's important that we fix high priority lint errors. Looking at Special:LintErrors/html5-misnesting, there are 17,000 of this one high priority lint error, and at least some of them come down to this template. (The example I looked at was not clearly misusing the template.) There's a misnesting of HTML tags involving a span tag that might break stuff when going to HTML 5. I started to try and debug it, but there's a lot of scary code here.--Prosfilaes (talk) 07:04, 8 May 2018 (UTC)

So if I'm reading this right, linter errors seem to be errors in wikitext that could cause rendering problems. @Prosfilaes: what do you think needs to happen? Is there an easy way for less technical folks to pitch in? -Pete (talk) 07:12, 8 May 2018 (UTC)

And what are the consequences if we don't take care of this? trying to wrap my head around the level of urgency and scope of the problem. -Pete (talk) 07:14, 8 May 2018 (UTC)

I'm going to move this part of the discussion to the Scriptorium. As for this page, the header is apparently spitting out misclosed HTML tags, and that's a bug that should be fixed.--Prosfilaes (talk) 07:20, 8 May 2018 (UTC)

Follow "main subject" statement on Wikidata to get link to Wikipediaalso

Would it be desirable to get a Wikipedia link (if not set through the template) by following the item's "main subject" statement on Wikidata and using the link to enwiki on that statement's object as one of the sister projects link? Other links could also be found that way, of course (commons, quote, etc.).

The exact use case that prompted this question is the The Dictionary of Australasian Biography, where all entries have a Wikidata item and many have a wikipedia= link set in the template. Some don't have a Wikipedia link set in the template, but do have an article. They are linked to their subject on Wikidata by "main subject" statements, see e.g. the item for The Dictionary of Australasian Biography/White, John. Of course, the answer could be to manually update the wikipedia= argument of the template, but that's maybe not the best use of our time.

I realize that crawling main subject statements might not lead to the desired wikilinks on all pages that use the header template. That would happen e.g. when the item is linked to a couple of generic subjects. In this narrow case of biographical dictionaries though, we could create a version of {{header}} for use on DAB or other biographical dictionaries. The code could also check for a reciprocal statement "described by" to filter out some possible unwanted links. That would filter out the generic "main subjects" since those would in all likelihood not be linked in the other direction.

Hope that was clear! --Azertus (talk) 14:02, 25 September 2018 (UTC)

@Azertus: This is an idea worth pursuing, I think. More important, I'd say, in cases where the person or topic involved does not (and is not likely to have) an Author: page on Wikisource, such as Fern Hobbs or the Panama Canal. -Pete (talk) 18:45, 25 September 2018 (UTC)

@Peteforsyth: Where it relates to an author, we should preferably directly adding a visible wikilink OR, we should be using the related_author = parameter.

@Peteforsyth, @Azertus: Have to agree with you. I am going through and adding entries from Thom's Irish Who's Who, example Thom's Irish Who's Who/Carter, Thomas and d:Q71679548, and it all takes time and edits. It is ugly and not robust means to do it, too reliant on there not being changes due to disambiguation.

We have the applied means to link to enWP through template:plain sister/module:plain sister which is nested into this template. It will work on the process of 1) if manually linked use that path (priority/override) 2) if interwiki exists, then link that.

We will however, need to do this in planned way, a) set the code to pull the link as no. 3 in the priority process. b) Put in tracking to track i) the discrepancy between interwiki and main_subject parameter in WD, ii) the discrepancy between manual_link and main_subject targets. We can then consider whether we tidy, or leave. ALL the DNB biographies are set that way. — billinghurst sDrewth 11:18, 20 October 2019 (UTC)

@Mike Peel: ^^^ If I have asked this before my apologies (too many tasks, not enough focus). Which module and parameters am I pulling to do this magic? — billinghurst sDrewth 11:18, 20 October 2019 (UTC)

@Peteforsyth, @Azertus: This conversion belongs at Template talk:Plain sister as that is where we generate the interwiki links. I have started a conversation about automating links, though we need to step through how this works with manual links and interwiki links, error checking, etc. — billinghurst sDrewth 12:10, 29 October 2019 (UTC)

follows and followed by

It was almost too easy. To pull in the "Previous" from wikidata:

{{#invoke:Wikidata|getValue|P155|FETCH_WIKIDATA}}|{{#invoke:Wikidata|getValue|P18|FETCH_WIKIDATA}}

And the same for "Next" using P156 instead of P155.

I used it directly here: Suggestive programs for special day exercises/State Flower

Could this be added to the template? Sure there should be a conditional also, I could write it if it would expedite things...--RaboKarbakian (talk) 03:25, 21 November 2018 (UTC)

No. "Follows" and "followed by" on Wikidata aren't used the way that you're using them. The values are used for holders of office to indicate the previous or next person to hold that position. They are used for the next book that an author wrote, or the previous book. Because of this, adding code that pulls in that data will break hundreds if not thousands of Wikisource works.

Also, there is no reason whatsoever to make dynamic calls to static data. Inserting a use of "invoke" into the parameter of a header to navigate to the previous section of a work is overkill. A relative link would work just as well, and is preferred because the target should not be dynamic. The danger of linking this way is that any changes made on Wiidata (including vandalism) could break links here without the community hanging any idea that it's happened. --EncycloPetey (talk) 05:08, 21 November 2018 (UTC)

Why? What are you looking to achieve? Things can only be pulled from Wikidata once things have been added to wikidata, not without entries. If we are talking novels with chapters, then chapter 1, chapter 2, chapter 3, wouldn't be having items. For biographical works like Page:Thom's Irish who's who.djvu/66 it is easier to just build the list and apply them, rather than try and add inconsequential and irrelevant prev/next to a WD item. It would seem more relevant to grab the table of contents page, and parse that or the previous/next links. — billinghurst sDrewth 12:16, 29 October 2019 (UTC)

Tenuous year doesn't show correctly

Using "YYYY/?" in the name field doesn't show the result as expected (remove "/" in the output and put it in correct category). Any idea how to fix it? Vinhtantran (talk) 18:08, 20 December 2018 (UTC)

@Vinhtantran: We wouldn't use a tenuous year that way, I would more suggest that you use YYY0s and site it within a decade. You can add a qualifier to the notes if a certain year is required. — billinghurst sDrewth 02:24, 23 July 2019 (UTC)

I take that back, someone has manipulated the script so you can place c/YYYY and it will present c. YYYY and classify into category:YYY0s work. — billinghurst sDrewth 02:15, 24 July 2019 (UTC)

I have removed the help for tenuous year, we should just use Circa — billinghurst sDrewth 02:17, 24 July 2019 (UTC)

Needing "contributing_translator"

Parking here in case someone gets to it before me.

Where there is a contributor, we are also going to need to add a translator field at the subpage level see Italian Literature taken from The Edinburgh Magazine and Literary Miscellany October 1820 to June 1821/Alessandro Marchetti. I am suggesting "contributing translator" though would accept the slightly clumsy "contributor translator" if that better aligns with existing terms. — billinghurst sDrewth 02:23, 23 July 2019 (UTC)

{{edit protected}}

Placing a ping here for review of new sandbox entry for "contributing_translator" and the potential for "override_contributing_translator". See the testcases at the bottom. To note that rather than have section name/author/translator on the one line, I have split the line due to the length of text. Whilst we normally try to keep the depth of the header field to a minimum, it is my opinion that the section line was problematic in its length without the split. — billinghurst sDrewth 07:04, 13 August 2019 (UTC)

Why is this preferable to using override_contributor? Noting also that it can be more complex than simply author+translator; see for example Lyra Davidica/A Commemoration of God's Mercies —Beleg Tâl (talk) 12:20, 13 August 2019 (UTC)

override_contributor alone will not categorise to missing author page for any missing authors. For more complex examples, we can continue building the template to cover these cases. If no one mentions needs, then they won't be met. — billinghurst sDrewth 12:47, 13 August 2019 (UTC)

Gotcha, that's a good reason. Perhaps we could consider renaming this parameter, from "contributor" to "section_author", and then we can add "section_translator", "section_editor", "section_composer", "section_illustrator", and so forth? This would also benefit new users who frequently misunderstand the meaning of "contributor" in the header. —Beleg Tâl (talk) 14:08, 13 August 2019 (UTC)

Parameters' names is neither here not there, I am comfortable with your suggestion in this case, and will make that change to section_translator. "Contributor" was chosen as it was reverse-engineered from the biographical dictionaries and encyclopaedias. All of that said, the template is complex, and it probably needs to be pulled into components as it is an absolute beast to edit. — billinghurst sDrewth 23:03, 13 August 2019 (UTC)

special:diff/9538633 <- proof of concept — billinghurst sDrewth 23:10, 13 August 2019 (UTC)

@Beleg Tâl: comfortable with proposed change, confirming proof of concept — billinghurst sDrewth 12:23, 17 October 2019 (UTC)

yep works for me —Beleg Tâl (talk) 12:54, 17 October 2019 (UTC)

Action to be taken October 2019

 Comment The plan will be to

• adapt presentation formatting to split the line with long field of section authors
• add the new parameter section_translator
• add the new parameter override_section_translator

and to create synonyms

• section_author that pairs with contributor
• override_section_author that pairs with override_contributor

The basics of change have been tested, and synonyms will be sandbox'd and testcase'd prior to implementation.

At this point, as we add {{illustrator}} to the notes field, that can already be done at a section level, so nothing to do with the current header structure. With regard to section_editor, I am not certain of the use case, if we are at a subpage of a volume of a journal, I don't see an issue with it sitting at top level, though happy to have that as a separate conversation and think that we would need to look at some test cases. — billinghurst sDrewth 21:39, 17 October 2019 (UTC)

 Comment @Beleg Tâl:

• Done section_author / override_section_author / section_translator / override_section_translator
• Not done at this time; extension of editor, new concept composer, integrating illustrator as an individual parameter

— billinghurst sDrewth 12:21, 30 December 2019 (UTC)

space_comma when translator alone

We need to have a look to see if we can eliminate the vagrant space when we have a translator and no author for works. This can be the case where we have a translator of multiple works where they have various authors/contributors of the works that they have translated. We have Tales from Old Japanese Dramas as an example where fixes will take place. — billinghurst sDrewth 02:13, 24 July 2019 (UTC)

Agreed; also applied when there is an editor but no specified author —Beleg Tâl (talk) 12:21, 13 August 2019 (UTC)

Done —Beleg Tâl (talk) 14:14, 13 August 2019 (UTC)

display badges from Wikidata

Per the discussions here and here I would like to request adding the following code to the beginning of this template:
<!--Text status badge (via Wikidata)-->{{#invoke:edition|badge|category=1|indicator=1}}
...as has been implemented at Template:Header/sandbox. Examples of the output from the sandbox template can be seen at The Life of the Spider and The Riverside song book/The Open Window. Essentially, it just adds an indicator icon to the page to reflect the badge assigned in Wikidata, e.g. "validated", "proofread", etc. Kaldari (talk) 21:11, 26 November 2019 (UTC)

@Beleg Tâl: Care to do the honors? I believe I've addressed all the concerns and suggestions raised at the Scriptorium. Kaldari (talk) 21:13, 26 November 2019 (UTC)

@Billinghurst, @Samwilson: Anyone else available to make the edit? Kaldari (talk) 23:00, 2 December 2019 (UTC)

@Kaldari: Done —Sam Wilson 23:25, 2 December 2019 (UTC)

title & contributor: one line or two?

Moved from Scriptorium. Levana Taylor (talk) 04:08, 31 December 2019 (UTC)

Cosmetic problem with {{header}} change

There seems to be a formatting problem with the addition of "translator" to the header template. There is a large space between the title and author lines if there’s a translator. Levana Taylor (talk) 01:49, 31 December 2019 (UTC)

@Levana Taylor: examples help. — billinghurst sDrewth 02:15, 31 December 2019 (UTC)

It looks like this. Levana Taylor (talk) 02:29, 31 December 2019 (UTC)

(ec) You have <br /> in your header's section. Section is designed and expected to not have formatting. Header was designed to be vertically lean, and should continue to be, this change does lengthen header vertically, but it was needed due to the extra information causing wrapping in the wrong spot and as such pushing all that data down, rather than letting it wrap in part. If you have that a lot, then I can run a bot through pages where you have been using that formatting method.

Note that there is no requirement to make changes to your existing use of parameters, the purpose of the change is add the new parameter. You can see that discussion at template talk:header. — billinghurst sDrewth 02:42, 31 December 2019 (UTC)

I am not the first person to put the title and contributor on separate lines: the Once a Week subpages that existed before I started working on the magazine did it that way and I just followed! That suggests there will be pages done like that elsewhere too. See my suggestion below to at least consider changing to a two-line header Levana Taylor (talk) 02:50, 31 December 2019 (UTC)

Was just talking about the design of the header back when. The header setup was to not have additional formatting (probably all ancient history now), that people have gone outside of the style design with their preferred vision is not new. It is the conundrum of a standard, the style guide and PoV that you are not going to please all people. The issue is that independent action, especially continued independent action can be problematic. That people don't come back and talk about the style and any shortcomings is problematic. What is most problematic are those who totally ignore the existing conventions as they just know better. [I am not pointing fingers at anybody here, more reflecting on years of this conversation.] We either have a shared standard or we don't

In your particular case, may I suggest that as a temporary measure that where you have a section translator then don't put the break, and we can work out what to do with maintaining the standard. — billinghurst sDrewth 03:34, 31 December 2019 (UTC)

You’re right, there should be a shared standard. Once again, I’m handicapped by having come in late & having not realized that what I found in the Once a Week headers wasn't standard. Well, I will certainly go along with whatever the decision is (one line vs. two has got to be one of life’s most trivial dilemmas!) Just, the fact that you now realized that with the translator, two lines seemed advantageous after all, suggests that having another think about it might be worthwhile. Levana Taylor (talk) 03:44, 31 December 2019 (UTC)

Contributor & title on separate lines

Personally I would like the title and contributor to always be on separate lines. It’s not just that the contributor line gets long when there’s a translator, but there are some really long titles too, which could cause wrapping together with the contributor. See Once a Week (magazine)/Series 1/Volume 5/How I invested my legacy in the purchase of leasehold property, and what came of it and that’s not the only one of similar length. What do other people think?Levana Taylor (talk) 02:39, 31 December 2019 (UTC)

Where the existing setup of header is failing, it is great to identify those that fail so we can address those whilst not having other issues. Pages such as these also make great testcases. I would encourage any person who is seeing {{header}} being problematic in a systematic way to make a point at template talk:header so we can see what are the means of resolution. We also need to be look at both web and mobile views. Ideally we need some css whizbang wunderkind to help us review all the old (crap) formatting that we have in place. — billinghurst sDrewth 03:39, 31 December 2019 (UTC)

no wrapping of partial text "translated by Blah Name"

For some uses of the template with translator, there is a wrap of the part of the author name, or even all of the name away from the text "translated by". Seems to me that if any part of the phrase "translated by Blah Name" is too long for the first header line that we are better off wrapping the whole component, not just a part. — billinghurst sDrewth 04:23, 28 February 2020 (UTC)

I've no particular opinion, but an issue that might be relevant is the effect on narrow screens such as mobile e-readers. Unless we always force this component to be on a separate line, the obvious approach would be to make it white-space: nowrap (i.e. if wrapping is needed, all of it will be wrapped as one unit), but this would also prevent wrapping when necessary on screens too small horizontally to fit all of it. I don't know whether this would be an issue in practice though. --Xover (talk) 06:01, 28 February 2020 (UTC)

Replacement for two headers

Hi, on Social Security Act 2018/Version 56/Section 8, I have two headers, one to assist the user with navigating previous/next sections of the act, and one to assist the user with navigating previous/next versions of the section.

I've been asked to keep to one use of {{Header}} per page, and the suggestion was to discuss the creation of a derivative template to achieve this. Supertrinko (talk) 04:25, 1 September 2020 (UTC)

Not required. Just put two links in the previous/next fields and separate them with <br />. I know that this has been done before, I just can't remember where at the moment so as to offer an example. Beeswaxcandle (talk) 04:58, 1 September 2020 (UTC)

I'm happy to do that, figured separate templates would be cleaner, but I'll go for breaks! Doing two of them seems about right. Thanks! Supertrinko (talk) 06:48, 1 September 2020 (UTC)

If you can find an example however, that'd be fantastic. While it "works", I'm struggling to make it look good, any text wrapping causes the text to not be in line. I can add {{Rule}} between them, which works until any text needs to wrap, which makes the line appear broken. Appreciate any further advice you can give. Supertrinko (talk) 21:21, 1 September 2020 (UTC)

@Supertrinko: What are you actually doing there? The usual approach for a work that exists in multiple editions is to give each its own top-level mainspace page disambiguated by year. We don't use multiple subpages and multilevel navigation to host all editions at the same name. What are these "versions"? --Xover (talk) 21:33, 1 September 2020 (UTC)

@Xover:, In legislation, which is open to amendments and edits, each version isn't so much a new publication as it is just an update to the existing text. From a legal perspective, it's useful to be able to compare different versions to see what those amendments/edits are. I could definitely just leave it at having a {{versions}} page that links to the original and each amendment page, however, I thought it would be a better user experience to provide two navigation bars on the page, one to the next section, as is the case in any document here, but a higher level one to change between versions of the same text. It'd allow easier navigation of the legislation, and legislative history. Supertrinko (talk) 21:39, 1 September 2020 (UTC)

Format checking of a couple of parameters from module

@Inductiveload: with the migration of components of header to modules, is this the time to ask for checks on formatting in the parameters. We regularly have people looking to put their personal spin on the header parameter formatting which is somewhat out of scope, usually in Title and Section. Things that we see are bolding, unbolding, italics, breaks. I suppose I am just looking to get stuff categorised in a maintenance category for review at this time. I had avoided asking previously as the template was already to complex to further bulk it out. — billinghurst sDrewth 21:20, 18 February 2021 (UTC)

Format checking can already by done with the module. I have added some cases to the p.categories function to categorise into Category:Pages with illegal formatting in header fields. Feel free to fill your boots with other formatting no-nos in the illegal_formatting function. Inductiveload—talk/contribs 12:37, 19 February 2021 (UTC)

The "next" link is virtually invisible

I find it very difficult for a newcomer to see the "next" links provided in the headers. Maybe wrap around it with <span class="mw-ui-button mw-ui-progressive">A→</span> (A→) akin to w:en:Template:Clickable button to make it more visible & recognizable? Vis M (talk) 03:43, 8 July 2021 (UTC)

@Vis M: That's certainly a valid concern, but the problem is balancing that against other concerns. Just throwing mw-ui-button at it would make it clash with the rest of the site style, and would draw excessive focus from the content. And almost anything we do to more subtly emphasise those links would need to be accompanied with tweaks to the rest of our standard page elements.

I don't think the underlying problem is so much "visibility" as it is "concept": if you're coming to Wikisource from a different project (or without wiki experience) it's not in your mental model to look for those links, so you'd have trouble for anything more subtle than big blinking buttons. That is to say, I think the only real solution to the problem you describe is a complete visual overhaul of our standard page elements with an eye towards modern user interface design and the interaction model. Xover (talk) 07:18, 8 July 2021 (UTC)

override_year parameter fail

Somewhere along the lines of history, the parameter override_year has stopped working. I presume that it was in one of the conversions to the modules. It also indicates that maybe we need to update our Template:Header/testcases which seems incomplete. — billinghurst sDrewth 03:35, 19 August 2021 (UTC)

Extra spaces around year

When the "year" parameter is provided, two spaces on each side of the year are produced instead of only one—i.e., it displays as "Poems␣␣(1811)␣␣by William Cullen Bryant" rather than "Poems␣(1811)␣by William Cullen Bryant". This behavior is currently visible at, e.g., Poems (Bryant, 1821)/The Ages. I have summarized what I believe to be the cause of this at my userpage. I think the issue (at least, I assume it to be unintended) can be best and most easily resolved by going into {{header/year}} and removing the non-breaking spaces around the outputs there (although I notice that there might be knock-on effects in, e.g., {{translation header}}). Alternatively, a small edit of {{Header}} (removing two whitespaces) and another small edit of Module:Header (removing the whitespace before "by {author}") should fix the problem without breaking anything else.

Is this all accurate? I just want to get a more experienced user's opinion on the matter before fiddling with (and potentially breaking) things.

Also, why are years not displayed at all in Header/testcases, despite being in the parameter inputs? Shells-shells (talk) 06:53, 22 May 2022 (UTC)

@Shells-shells: I'm loath to go messing with fiddly details like this at the moment, because the {{header}} machinery is 1) extremely fiddly and prone to breaking in weird ways, and 2) in a transitional state between raw template code and being turned into a Lua module (case in point: Module:Header/year). In particular, the current state where each parameter gets a separate invocation from template code to Lua is suboptimal and will disappear when the transition is complete, and at that point we can create a more holistic treatment of this kind of formatting.

You probably don't get years in the output in the testcases because the output is switched based on namespace (I'm not entirely sure why ottomh). Xover (talk) 07:51, 22 May 2022 (UTC)

Sounds good! It's a thing of no importance, anyway.

Out of curiosity, what makes the current system suboptimal? Is site performance reduced when invoking a module multiple times rather than only once, for example? Shells-shells (talk) 00:59, 23 May 2022 (UTC)

@Shells-shells: I don't know that performance is a significant concern here. The problem is that the logic is split between template code and Lua code—these spaces being a case in point—and as such the logic is shaped and limited by this division rather than by the actual needs or a design. And a lot of the Lua code is replicating logic that was implemented as template code ten years ago, with the limitations that implies. And so long as we have multiple invocations we need the Lua code to keep being compatible with the old template logic and can't really modernize it or easily change it. And architecturally, having multiple invocations is inherently limiting because each invocation is isolated, so you can't, for example, add a maintenance category from different parts of the module and then format and output all of them in a common function at the end.

All of this can be worked around, of course, as we do currently, but the situation is suboptimal and fragile, and I would prefer to get the header system completely migrated to Lua and then cleaned up and modernized rather than try to further patch it piecemeal in its current state (excepting critical fixes etc. of course). Xover (talk) 06:21, 23 May 2022 (UTC)

Use of year = with yyyy/zzzz

Something not quite is happening with the categorisation when the year = yyyy/zzzz is used per Caladonia. I would think that it would not be picking up the error type categories. — billinghurst sDrewth 11:53, 27 September 2022 (UTC)

override author vs using a redirect

Using override author gives a header of three lines whilst a redirect as author name only gives two - see for example Men_without_Women/The_Killers.

Is there a reason for that ? I would have expected both to give the same outcome. -- Beardo (talk) 03:57, 24 February 2023 (UTC)

I have no idea why someone chose that, but after a lot of digging around and testing, I found these lines, in Module:Header/Attributions, in function construct_attributions,

if args['override-author'] or not args['section'] or #attributions > 1 then sep = '<br/>' end

Which basically says that, indeed, when there is an override author there is a <br/>.

I do not know who chose that, but it was apparently intentional. Alien333 (what I did and why I did it wrong) 13:12, 4 March 2024 (UTC)

(Lines 222-224, more specifically) Alien333 (what I did and why I did it wrong) 13:13, 4 March 2024 (UTC)

(I have tested and am now sure that it is that.)

It's been here since the beginning of that module.

There was a comment next to it mentioning something about avoiding "by by"'s but I don't really know what that is about (might be linked to prefix being set to "").

@CalendulaAsteraceae would probably be able to tell us more about it, since they made it. Alien333 (what I did and why I did it wrong) 13:40, 4 March 2024 (UTC)

There was also a break before override_author in the original template. Due to a lot of technical debt, override_author (unlike every other attribution parameter) does not use a prefix like "by" or "translated by", so the template (now the module) adds a break before that attribution field to make it more obviously distinct from the title. In the long run, I'm hoping to phase out the override_author parameter by adding better support for its various usecases. Features I've added recently:

• Disambiguating parentheses are hidden by default. For example, | author = Winston Churchill (1871-1947) will produce the link Winston Churchill.
• You can change the way an author displays by adding a -display parameter. For example, | author = Winston Leonard Spencer Churchill | author-display = Winston Churchill will produce the link Winston Churchill.
• You can stop the author field from linking with author-nolink. For example, | author = the [[Portal:Parliament of the United Kingdom|Parliament of the United Kingdom]] | author-nolink = true will produce the author display "the United States Congress".
• You can add multiple authors by adding 1, 2, etc. after the author parameter. For example, | author1 = Winston Churchill (1871-1947) | author2 = Winston Leonard Spencer Churchill | author2-display = Winston Churchill will display as "Winston Churchill and Winston Churchill".

—CalendulaAsteraceae (talk • contribs) 19:26, 4 March 2024 (UTC)

Unknown/not mentioned for section_translator

Currently, if |translator= is set to "unknown" or "not mentioned", then it doesn't wikilink to an author page, and adds it to the appropriate categories. But |section_translator= (and |contributor_translator=) doesn't have this functionality, and instead links to Author:Not mentioned or Author:Unknown (which has several articles linking there at the moment according to WhatLinksHere). Any chance the same functionality as |translator= can be added to |section_translator= ? --Yodin^T 17:17, 11 March 2023 (UTC)

@Yodin: Just wanted to let you know this functionality has been added! —CalendulaAsteraceae (talk • contribs) 19:43, 4 March 2024 (UTC)

Thanks for all your work on these templates, all the author1, author2, author_display, etc. etc. are a great improvement, as well as the above! Much appreciated! --Yodin^T 00:34, 5 March 2024 (UTC)

Add rel="next" to the next link

Same for the the previous link of course. The idea is to be standard compliant : https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel#next This would allow screen readers and other applications or extensions that depend on programmatic logic to be able to easily tell what the next/prev chapter is and act accordingly.

The work needed is pretty minor as it is just adding an attribute to the a element. My plan is to just add to the Lua Header model a p.next function very similar to the p.title function. I will do the work if someone with editing privilege approves the idea. Brolulu (talk) 10:58, 18 October 2023 (UTC)

@Brolulu: Done Added to Module:Header structure. —CalendulaAsteraceae (talk • contribs) 19:48, 4 March 2024 (UTC)

@CalendulaAsteraceae Thanks, but if I understood the change correctly, then there is a bug. The rel="next" needs to be on the <a> element created by the

wikitext call and not on the containing div. The standard doesn't support div elements.

Brolulu (talk) 21:47, 4 March 2024 (UTC)

Oops, thank you! Adding prev/next attributes to links will be harder to accomplish since links are added manually by users. —CalendulaAsteraceae (talk • contribs) 22:57, 4 March 2024 (UTC)

CalendulaAsteraceae wikidata has follows and followed by properties that would solve this. Property:P155 and Property:P156 --RaboKarbakian (talk) 13:12, 15 April 2024 (UTC)

I just saw this again! Getting previous/next links from Wikidata is definitely an interesting idea, but it wouldn't help with adding properties to links, as MW disables <a>...</a> tags. For example,

<a href="https://en.wikisource.org/wiki/Template:Header/doc">manual link</a>

displays as <a href="https://en.wikisource.org/wiki/Template:Header/doc">manual link</a> —CalendulaAsteraceae (talk • contribs) 09:01, 30 October 2024 (UTC)

lcc

It would be nice to link to the Library of Congress Classification grid if there is one at wikidata. Like the portals already do, maybe. Also, I have been encountering more numbers than we serve up here, so what about that? I would hate to have to look them up again.--RaboKarbakian (talk) 13:06, 15 April 2024 (UTC)

Property:P1149 --RaboKarbakian (talk) 13:12, 15 April 2024 (UTC)

P1149 is for the LoC Classification (shelf location / call number). It will not generate a link at Wikidata, and should not be listed here. We list the LoC Authority ID, which is the master heading for a work in their catalog. There are multiple properties available for the LoC, and the Authority File is the one that provides the most information, and a link. The Authority file information is placed on the work. There is a separate property at Wikidata under P1144, and that's the one that links to a bibliographic record for an edition; and each edition gets a unique ID with publication data. That gets linked to from Wikisource by using the {{authority control}} template at the bottom of the page. --EncycloPetey (talk) 17:06, 15 April 2024 (UTC)

I am encouraged to find the LCC number when I drop a book or article at a portal. So, science and history get classified via the Library of Congress Classification here, often. It is where they (the library of congress) would keep it, not if they have it. When sorting through a stack of mixed fiction and non-fiction, why not classify the kind of fiction it is?--RaboKarbakian (talk) 00:15, 16 April 2024 (UTC)

On Wikisource, we do that with categorization and portal listings, not with a shelf location in the LoC. Different copies of the same work get placed on different shelves by different librarians at the LoC. There is not a unique shelf location, for example, for all copies of the same translation of the same classical work. If it was bound as a single volume, it gets places in a different location than if it were part of a collected work. And if it's a side-by-side translation, it's placed in a different location than if it is just the translation, or just the original. If it's published as part of a series, it gets placed in yet a different location. As a result, the LoC shelf location is neither unique to a particular work of fiction, nor consistent. And someone seeing the classification would still need to go look it up in a table to determine what the classification meant, and it might not be illuminating. --EncycloPetey (talk) 00:33, 16 April 2024 (UTC)

Something like this: The Atlantic Monthly/Volume 109/Number 650/Contemporary Novel.--RaboKarbakian (talk) 10:47, 16 April 2024 (UTC)

But that's not where the Library of Congress puts that item. It's printed in The Atlantic Monthly, which is classified as LCC: AP2 .A8 (according to the LoC own website). So what you're wanting to do is to make up a number the LoC does not actually use, and then display that made-up number in page headers. Why not instead use Wikisource categories? --EncycloPetey (talk) 14:45, 16 April 2024 (UTC)

But that article is about literary criticism criticism. It is not about magazines. It is also not about science fiction either, which would be nice to know. It is a rant about dealing with people who have other ideas and it mentions quite a few "popular fiction" of the day. What did H. G. Wells like to read, also. That it is to be classified as a magazine is unacceptable.--RaboKarbakian (talk) 17:51, 16 April 2024 (UTC)

That's why we have Portals and Categories. Note that PN 80-90 is a range of locations; what you've given is not a shelf location, but a range of values for various works. No LoC Classification on an individual work would ever be structured like that. --EncycloPetey (talk) 21:08, 16 April 2024 (UTC)

Author data for dual authorship

When there are two authors, e.g. there, the span.ws-author metadata generated lists only the first one. — Alien333 (what I did & why I did it wrong) 19:29, 20 July 2024 (UTC)

Does this issue happen if you use "author1" for the first author? Or only when you use "author" (unnumbered) and "author2"? --EncycloPetey (talk) 20:01, 20 July 2024 (UTC)

I used "author" and "author2", that must be it. Thank you. — Alien333 (what I did & why I did it wrong) 07:18, 21 July 2024 (UTC)

Rewriting construct_microformat so it supports multiple authors is on my to-do list, but I haven't actually done it yet. —CalendulaAsteraceae (talk • contribs) 06:17, 24 July 2024 (UTC)

Updated. —CalendulaAsteraceae (talk • contribs) 09:04, 1 October 2024 (UTC)

Add "compiler" attribution

{{editprotected|Module:Header/attribution data}} @CalendulaAsteraceae: I want to support compiler (Q29514511); such credits are common with biographical dictionaries. Towards that end could we get something like:

{noun = 'compiler', prefix = 'compiled by'},

added to contrib_types in Module:Header/attribution data? As an interim I usually put such credits into "editor" fields (e.g., within Index namespace, etc.). Thank you, —Uzume (talk) 13:19, 5 September 2024 (UTC)

Is this something we actually need to distinguish? I've always just called them editors, and fail to see the distinction in bibliographic terms. Xover (talk) 18:13, 5 September 2024 (UTC)

@Xover: And we need to distinguish those many other types of attribution we already have? Some of the ones we already have seem considerably more obscure. —Uzume (talk) 21:56, 5 September 2024 (UTC).

I don't know about need, but in those cases I can mostly see the distinction between the roles. But what's the actual difference in the work of an editor and a compiler?

Note that I'm not immediately against adding this. I just can't see the need, and we probably ought to try to limit the number of variants at least somewhat. Xover (talk) 06:45, 6 September 2024 (UTC)

A compiler collects multiple items together, especially anthologies. A compiler might also edit the works so collected, but not necessarily. An editor oversees preparation for publication, checking correcting spelling, punctuation, and may add or omit material from the work, including whole paragraphs or chapters. An editor might also compile works; but not necessarily. There are multiple Japanese poetry anthologies of the Classical period that were compiled but not edited. --EncycloPetey (talk) 06:57, 6 September 2024 (UTC)

Sure, in terms of pure ontology I can see it. But it's a pretty fine hair to split, and in practical bibliographic terms the two circles overlap so much that the distinction, to me, becomes without difference. But I won't belabour the point. If others think it's worth supporting the distinction I am not opposed to it; just being the devil's advocate. Xover (talk) 14:43, 6 September 2024 (UTC)

This is about where I'm at too; since there hasn't been any further discussion, I've added the parameter. —CalendulaAsteraceae (talk • contribs) 09:04, 30 October 2024 (UTC)

Recursive translations

How do we want to handle works like Translation:Letter from the Timucua chiefs to the King of Spain - January 28, 1688 (Spanish version), which were first translated from one language, and then translated from the second language to a third? —CalendulaAsteraceae (talk • contribs) 05:24, 9 September 2024 (UTC)

IMO, the original is the one that is linked in the header field, with the intermediate language version linked in the Notes field. Beeswaxcandle (talk) 06:39, 9 September 2024 (UTC)

Override editor1 and 2

Would it be possible to unify the parameters override_editor1 and override_editor2 so that they work the same way as e.g. override_author? See e. g. my sandbox. -- Jan Kameníček (talk) 20:44, 29 October 2024 (UTC)

@Jan.Kamenicek: I've fixed the bug where override-editor1 and override-editor2 were getting parsed as just editor1 and editor2, and therefore linked inappropriately. However, the way that override- parameters work, you can only have one override-editor parameter. For the Czechoslovak Review use case, I recommend using -nolink parameters, which are a bit more flexible. —CalendulaAsteraceae (talk • contribs) 08:54, 30 October 2024 (UTC)