Template talk:Header

From Wikisource
Jump to: navigation, search


Archives: 2008; 2009; 2010; 2011

Year parameter[edit]

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-2Learned 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)

Microformat data[edit]

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. Inductiveloadtalk/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)

Yes check.svg 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[edit]

{{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.

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[edit]

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[edit]

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 Frenchbillinghurst 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?[edit]

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[edit]

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[edit]

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[edit]

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 ( TalkContribs ) … 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[edit]

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[edit]

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 ...[edit]

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[edit]

The following discussion is closed and will soon be archived: Yes check.svg 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)

Symbol support vote.svg Support Changes seem to work, and they improve upon existing functionality be moving to supported LUA. — billinghurst sDrewth 00:20, 19 September 2014 (UTC)
Symbol support vote.svg 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)

Pictogram voting comment.svg 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)

Add searchaux class to previous and next links[edit]

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[edit]

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:

<!--

   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:

<!--

   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[edit]

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[edit]

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[edit]

  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"[edit]

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)