Template talk:Header/2008

Please do not post any new comments on this page. This is a discussion archive first created in 2008, although the comments contained were likely posted before and after this date. See current discussion.

Translator

Would it be possible, without causing too much trouble, to revise this template to include an optional place to enter the name of the person who translated the work into English? This data is important enough for a formal place in the template, rather than being relegated to "notes." It is especially important for texts that have been translated into English more than once. Dovi 10:09, 18 May 2006 (UTC)

P.S. Maybe also a place to enter the date of the translation. Dovi 10:52, 18 May 2006 (UTC)

I think that such information should be part of the notes, which are much more pleasant to read and user-friendly than a dry table of data. For example, compare the following list with the sentence:

Field	Data
Edition	1st
Translator	Bob
Date	2006

"This first edition is taken from Bob's 2006 translation."

I think that's entirely within the realm of editorial notes. // [admin] Pathoschild (^talk/_map) 14:34, 18 May 2006 (UTC)

The thing is that the header is not a dry table, but rather serves as a title page. My suggestion is that we allow for the following possiblity:

Critique of Pure Reason

by Immanuel Kant

translated by J. M. D. Meiklejohn (1855)

This will make it immediately clear to the user that this is a translation, and which translation is being used. Dovi 15:26, 18 May 2006 (UTC)

I second this as it will also prompt editors to add the translator. This info can be very hard to track down if the original editor does not include it when they have the source in hand.--BirgitteSB 15:46, 18 May 2006 (UTC)

{{#if {{{translator|}}} |translated by [[Author:{{{translator|}}}|{{{translator|}}}]] {{#if {{{translationyear|}}} |({{{translationyear|}}})}} }} would do the job without botching anything else, I believe. As it seems the idea's agreed to, could an admin add it? PoptartKing 02:47, 30 May 2006 (UTC)

I'm torn on this topic. Obviously there should be translator information (for both copyright status determination and proper documentation of a work). But in many cases, I don't think the translator is so important as to deserve a slot right under the author and deserve his own parameter. Sometimes the translator really does matter, as there are very famous translations of works. But most of the time, the translator is not a popular person, the translation is nothing spectacular, so relegating that information to the notes parameter is enough. I would rather not add much verticality to the {{header}} template by adding a new parameter, but just keep such information in the notes section.—Zhaladshar ^(Talk) 15:55, 6 June 2006 (UTC)

Yes, but isn't that exactly the point? When the translator is important, there is easy option to feature that. When not, it can be left blank, and mentioned in the notes. Dovi 16:32, 6 June 2006 (UTC)

Test

Untitled by [[Author:|unknown]] {{#if |translated by [[Author:|]] {{#if |()}} }}

—unsigned comment by Dovi (talk) 18:29, 30 May 2006.

The correct code for the test above is {{#if:{{{translator|}}}|({{{translator|}}}}}. However, if need be the translator can be specified using the author overrides; see the following code and example.

{{header
 | title    = Exempli
 | author   = |override_author= by [[User:Pathoschild|]]<br />translated by [[User:Slavepersona|]]
 | section  =
 | previous =
 | next     =
 | notes    = [...]
}}

Exempli by Pathoschild translated by Slavepersona

Exempli is a lorem-ipsumesque, if inexistant, work written in 2006 by Pathoschild and translated under his pseudonym Slavepersona that same year.

// [admin] Pathoschild (^talk/_map) 05:02, 7 June 2006 (UTC)

Thanks, that override business should do the job in any case. Dovi 18:20, 8 June 2006 (UTC)

Optional bibliographic information

I feel that storing the information about the text on it's discussion page is a misuse of the system... As that page is reserved for "behind-the-scenes" editorial discussion— something that users who want the bibliographic information shouldn't be shown or bothered with. I propose adding an optional appendage to the header (or even a separate template at the foot of the document) which can give concise information regarding the text being read. Such as: original publication, publication Wikisource text is based off, text quality/progress, notes, etc. A rough sketch of what I had in mind can be found on my development page on Wikipedia. – Quoth 14:08, 7 June 2006 (UTC)

I strongly disagree. In order to consider putting this on the header you have already specified it would be "concise". Any information that is important or espscially notable can be added to the notes (and I believe this is already happening). The more detailed information should not be on the text page, but still available. The talk page seems the perfect solution to me. What sot of editorial disscusion is being pushed off the talk page by this system? There is simply not the amount of editorial disscusion necessary when dealing with static texts (hopefully locked from editing) that there is in a place like Wikipedia. You are not the only person to feel this way. But I have never understood what sort of talk page use is not being implemented by having Template:Textinfo on the page?--BirgitteSB 14:28, 7 June 2006 (UTC)

It's not that anything is being "pushed off the talk page", rather, that we're encouraging users to leave the main article space, and enter somewhere which could very well have a lot of uninteresting/unuseful (to the reader) information. Having this in the/a template also helps to standardise and so encourage the inclusion of this data for a text, which I feel is as important as citing and referencing sources in a Wikipedia article. A work can be revised and edited continuously throughout an author's life (and unfortunately beyond), so knowing what version of a text I'm reading can be very important. I'd also like to note that I intend for every field to be optional, and as shown, the information can be (and I daresay, by default) readily hidden from view with the [show]/[hide] link in the corner — taking up no more space than the current Notes field would. – Quoth 17:09, 7 June 2006 (UTC)

That's exactly what the 'notes' parameter is intended for: concise editorial notes on the text. // [admin] Pathoschild (^talk/_map) 23:09, 7 June 2006 (UTC)

Very well, so I should include all the above information I mentioned into the notes field? And no-one thinks that the ability to automatically hide this information is advantageous? I've modified the concept for clarifications sake if you want to have another look, but the layout could obviously be discussed further, if this isn't a complete write-off. – Quoth 04:10, 8 June 2006 (UTC)

Link to up-level

It is feasible to have link not just to Next and Previous, but to up-level as well.

The icon - a small up-arrow character with the word "Up" (which could be altered by a customer)may be located next to SECTION place, so extra room would not be a point, Sure, the parameter should be ignored when not used explicitly --HenryS 17:05, 1 August 2006 (UTC)

The top level is traditionally linked through the title parameter, and intermediate levels are usually linked in the sections parameter. For example, see this usage on United States Code/Title 1/Chapter 1:

{{header
 | title    = [[../../|United States Code]]
 | author   = | override_author=the United States Government
 | section  = ([[../|Title 1]], Chapter 1. Rules of Construction)
 | previous = ←[[../|Title 1. General provisions]]
 | next     = [[../Chapter 2|Chapter 2. Acts and Resolutions]]→
 | notes    = From the ...
}}

←Title 1. General provisions

United States Code (Title 1, Chapter 1. Rules of Construction) by the United States Government

Chapter 2. Acts and Resolutions→

From the U.S. Code Online via GPO Access, laws in effect as of January 7, 2003.

Adding a new parameter isn't necessary, as the above example shows. // [admin] Pathoschild (^talk/_map) 01:29, 2 August 2006 (UTC)

What if there are two authors?

E.g. The Masque at Kenilworth - Is there any way to attach it to both Chorley and Sullivan's page? For that matter, it might be useful to link the G&S operas to Sullivan's page too. Adam Cuerden 00:02, 2 September 2006 (UTC)

Yes, there is. In the "author=" parameter, place the following code: | override_author=. After the "=" sign, place the actual links to the different author pages (not just the name of the author as you would normally do). So, do [[Author:AUTHOR 1 NAME|AUTHOR 1 NAME]] and [[Author:AUTHOR 2 NAME|AUTHOR 2 NAME|]].—Zhaladshar ^(Talk) 00:12, 2 September 2006 (UTC)

Newspapers

In the case of Newspapers how should I fill out the header. Specifically, is name of the paper to be listed author? That doesn't seem right, because sometimes the articles actually list an author. Name of publication is way too important to not be included. Important metadata is Article; Date; Name of Paper; page and/or section. the newpaper articles are very inconsistant. Could we have a name of publication bit for Periodicals--Metal.lunchbox 01:28, 6 December 2006 (UTC)

I would suggest (based on government works) that:

1. if there is a byline, this should be listed as Author
2. if there is no byline, the name of the periodical should be given as override_author and other publications details should be included as Notes

Another option is to allow bibliographical pages for periodicals in Author:space, but I seem to be in a minority in supporting the idea of Author:pages for non-individual authors :( Physchim62 14:37, 7 December 2006 (UTC)

I agree with (1) and (2). That sounds like a good way of going about handling these pages, and is consistent with how we've handled other pages in the past, too (such as, overriding the name of the organization on historical/government documents).—Zhaladshar ^(Talk) 15:16, 7 December 2006 (UTC)

I used no_author instead of override_author because override makes it say "by The New York Times" which I think is silly. how is this The New York Times/Inauguration of the President of the Southern Confederacy. I'm so particular about it because its a lot of work to change all the pages and I'd like to upload alot more. That one is just a model for convention. --Metal.lunchbox 23:01, 7 December 2006 (UTC)

I'd advise against using the noauthor parameter for that purpose. That parameter no longer exists in the new header format that will be implemented in the near future, being replaced by ParserFunctions. Since each article is an individual piece that does not depend on the New York Times, I'd suggest treating it as we do collections. The author field should be left blank unless the author of the piece is known (the newspaper is not the author).

—{admin} Pathoschild 04:23, 8 December 2006 (UTC)

I think that will work. Thank you. --Metal.lunchbox 18:28, 8 December 2006 (UTC)

Interwikis

Here is a list of interwiki-links to header-templates in other wikisource:

[[ca:Plantilla:Encapçalament]]
[[cs:Šablona:NavigacePaP]]
[[de:Skabelon:Header]]
[[da:Vorlage:Textdaten]]
[[el:Πρότυπο:Τίτλος]]
[[en:Template:Header]]
[[es:Plantilla:Encabezado]]
[[et:Mall:Päis]]
[[fa:الگو:سرصفحه]]
[[fi:Malline:Otsikko]]
[[hr:Predložak:Niz]]
[[hu:Sablon:Fej]]
[[la:Formula:Titulus2]]
[[no:Mal:Topp]]
[[pt:Predefinição:Navegar]]
[[ro:Format:Titlu]]
[[ru:Шаблон:Заголовок]]
[[sl:Predloga:Naslov]]
[[sv:Mall:Titel]]
[[uk:Шаблон:Заголовок]]
[[zh:Template:Header]] 

—unsigned comment by 82.212.68.183 (talk) 2006-12-12T06:20:39.

Done --Benn Newman ^(AMDG) 12:53, 12 December 2006 (UTC)

Can you please add link to polish version: pl:Szablon:Nagłówek Niki K 09:04, 23 September 2007 (UTC)

Done. —{admin} Pathoschild 13:24:16, 23 September 2007 (UTC)

header2

If this template is called "header", then why do the examples on this page use "header2" instead? —Psychonaut 15:01, 25 January 2007 (UTC)

There is a new header format forthcoming (see "Tweak standarised header", Scriptorium, October 2006). Because some of the changes require correcting usage, header2 was created for the transition. Eventually Pathosbot will convert all pages using {{header}} to the new format, and header2 will be merged into header. For the sake of simplicity and getting editors used to the simplified syntax, the examples recommend the new format. —{admin} Pathoschild 22:50, 25 January 2007 (UTC)

The New York Times?

What's that thing down there doing? 68.39.174.238 14:04, 1 September 2007 (UTC)

The footer is created automatically on pages using {{header}}; I've fixed the script so it only does that in the main namespace. —{admin} Pathoschild 13:25:13, 23 September 2007 (UTC)

Header vs. Header2; span class for permanent link

I don't understand the difference between Header and Header2. Could someone explain it for me? Also, for header 2, I think <span class="plainlinks"> (example link) should be used in the note above header 2. It would be slightly less obtrusive then. Psychless 01:54, 30 September 2007 (UTC)

There is a new header format forthcoming (see "Tweak standarised header", Scriptorium, October 2006). Because some of the changes require correcting usage, header2 was created for the transition. Pathosbot is converting pages using {{header}} to the new format; this is a complex task, because many of the pages predate normalization, which makes bot-parsing more difficult. Eventually header2 will be merged into header. In the meantime, the examples recommend the improved format.

I've added the plainlinks class. —{admin} Pathoschild 02:17:50, 30 September 2007 (UTC)

This still doesn't explain why we need the "permanent link" comment above the header. Eclecticology 08:20, 2 October 2007 (UTC)

See "Soft redirects" (Scriptorium, August 2007). —{admin} Pathoschild 14:35:33, 02 October 2007 (UTC)

It all reads like a solution in search of a problem. What you say there is that if people are unwilling to learn how to fuck around with style sheets, too bad. The necessity of protecting every broken link is overblown. While I recognize that a work in progress may undergo several changes in sub-page structure until it becomes stable, it should be enough to limit permanent redirects to the front page of a work. Links which are broken could then default back to the least significant unbroken level, which should include a directory of its own immediate sub-pages. Eclecticology 17:47, 2 October 2007 (UTC)

That's a great idea. When cascading redirects are implemented in MediaWiki, we can simply take the note out of the header. —{admin} Pathoschild 17:56:01, 02 October 2007 (UTC)

Why is this link there? Surely exactly the same link is present on the left hand side, and the very nature of a wiki implies that things move. That is why redirects were created. In my (not so) humble opinion, it just adds distraction to the page. Conrad.Irwin 23:19, 17 October 2007 (UTC)

Header2 footer

I'm using header2 on one of my texts I'm adding. Some of the pages are very short and it would look ridiculous to have a footer. Apparently there's a way to not have the footer, but no documentation exists on how to do this, or at least no documentation I can find. Could someone please answer my question? Thanks, Psychless 21:39, 14 October 2007 (UTC)

I don't know the answer but here are two example pages: E.S. Dargan on Secession has a footer, and Appeal of June 18 does not. The only difference I could see in the invocation was that the latter has a parm for "previous =" while the former is a standalone speech with no section, prev or next parms. I tried viewing the source but I was unable to spot the exact trick. Hope that helps. ++Lar: t/c 12:43, 15 October 2007 (UTC)

There's currently no way to override the footer. There was some discussion a while back to automatically disable it based on the page size, but that's difficult to judge accurately; a floated navigation table beside a four-line poem can be as big as a thirty-line poem without. Another idea would be a template which forces the script to not display the footer, like {{script|footer=hide}}. —{admin} Pathoschild 13:23:20, 15 October 2007 (UTC)

So was I correct in my surmise that it somehow is caused by logic not to be present when there are no nav (next/prev/section) parms given?) ++Lar: t/c 13:36, 15 October 2007 (UTC)

Yep. —{admin} Pathoschild 04:37:22, 16 October 2007 (UTC)

Well, I can live with it for now, but I think it would be useful to come up with a solution to this. Psychless 01:57, 16 October 2007 (UTC)

This template is used in a lot of pages so presumably we don't want to do changes willy nilly. What of an optional parm that would: if present and set one way, suppress the footer, even if it normally would be there because prev/next were supplied; or if present and set another way, would require the footer, even if it normally would not be there because pref/next were not supplied; or and if absent, the current behaviour would remain, so that the vast majority of pages would not need changes to how they invoked the template? I'd propose the specific changes but I'm not sure I'm up to it as I wasn't able to tell exactly where the footer was coming from in the first place. ++Lar: t/c 13:55, 22 October 2007 (UTC)

Well, there used to be a parameter called "nofooter" that has since been removed which would suppress the footer if the parameter were given a value. I think restoring this parameter would be the best solution, because some pages just do not look good with a footer on the bottom (i.e., the really short pages) and sometimes have prev/next values which would cause it to appear. I think having the footer on by default and letting the editor choose when to use it and when not to would be the better idea.—Zhaladshar ^(Talk) 17:17, 22 October 2007 (UTC)

I've prepared a new version of displayFooter() that supports {{script|footer=hide}} and {{script|footer=show}}. You can see it in action by clicking the links below. If it doesn't do what is expected, try clearing your browser cache (CTRL+R in Firefox).

E.S. Dargan on Secession	with footer	forcefully hide footer
Appeal of June 18	no footer	forcefully show footer

Usage is simple:

• {{script|footer=hide}} hides the footer (even if normally shown);
• {{script|footer=show}} shows the footer (even if normally hidden).

Reasons to use a new template:

• {{header}} should only be used for meta-data;
• the script may later be changed so that it doesn't use the header;
• {{script}} can also be used for other scripts and bots (so we don't have script overrides set in several different places).

Other changes to the script include namespacing using an object literal, which makes it easier to avoid name conflicts when multiple scripts by different users and personal JavaScript files are used simultaneously. Turning it on by default would be very easy with the new script as well. —{admin} Pathoschild 20:57:09, 22 October 2007 (UTC)

Very clever. Would using this always result in the big black warning at the top? That might confuse some. Also, it would change the behaviour only for those that were .js capable, right? I wonder if the additional optional parameter might not be a simpler fix though? ++Lar: t/c 13:53, 23 October 2007 (UTC)

The black warning is there because the script is loaded dynamically, since it's not in the site JavaScript; the black box won't appear when the script is implemented. Users who aren't JavaScript-compatible will never see the footer at all, since it's entirely generated by JavaScript.

Using {{header}} for this will actually make usage more complex later. Imagine we add a second script later to generate something else, but it has nothing to do with the header. Do we have one script override in {{header}}, and another in {{script}}? Do we have two overrides in {{header}}, even though the new script has nothing to do with the header (and might even be used on pages without a header)? {{script}} is also easier to understand for new editors, because it's obviously a hidden template that has something to do with scripts. This is less obvious when used in {{header}}.

For the same reasons, it's a good idea to standardize {{script}} for all scripts, ranging from footer overrides to bot archival instructions. It is easier to see and refer to one template than have script overrides in many places. —{admin} Pathoschild 23:36:14, 23 October 2007 (UTC)

Ah. I did not realise that the footer is coming from js that is being executed... I thought you'd discovered some magic 'div' or something that got it to appear below the content (without thinking too deeply about just how hard that would actually be) ... your "Yep", above, was perhaps a bit too terse of an answer. :) Yes, in that case, I agree, this script control does not belong in the header templates. ++Lar: t/c 20:58, 24 October 2007 (UTC)

{{script}} appear to be counter-intuitive. Appeal of June 18, with wikicode of {{script|footer=show}} doesnt have a footer, yet E.S. Dargan on Secession, with {{script|footer=hide}} does have a footer. John Vandenberg 17:41, 14 November 2007 (UTC)

I applied Template:Header2 to The Civilization of China and its sub-pages. The footer only appears on the sub-pages, which are much longer than the main page. I guess that the footer can only appear on the pages larger than specific bytes, probably 3,000 bytes (Religions of Ancient China, 2,851 bytes, does not have footer; E.S. Dargan on Secession, 3,369 bytes, has footer). Am I right? --Neo-Jay 16:56, 16 November 2007 (UTC)

I use Classic skin, so I don't get the footers at all; however, your observation probably has more to do with whether there is anything in the "previous" and "next" parameters. As I understand it, if both of those parameters are blank there will be no footer. Eclecticology 22:45, 16 November 2007 (UTC)

Well, you are right. The appearance of footer has nothing to do with the page's length. A long page without previous and next does not have footer and a short page with previous and next has footer. Why should it be designed like that? It makes no sense. I think the length of page should be able to determine the appearance of footer.--Neo-Jay 01:52, 17 November 2007 (UTC)

Implementing the footer based on the length of the page is a bit tricker, but it can be done and does make sense. John Vandenberg 02:24, 17 November 2007 (UTC)

If the footer's function is just providing shortcut links to previous and next chapters, then it makes sense to base the implementation of the footer only on the existence of the previous and/or next. For a long page without previous and next chapters, the readers do not need a footer as the shortcut to read the next chapter . But if the the functions of the footer also include providing shortcut link to the top of the page, then the length of the page should also be considered. And for a very short page, even if it has previous and next chapters, the footer seems unnecessary. --Neo-Jay 05:04, 17 November 2007 (UTC)

I'd like to bring up this topic again. The {{script}} template does not work, so we're still stuck with unnecessary footers. In my opinion, no page should have a footer if the footers can't be removed from the short pages. Scrolling to the top of a page is not difficult. Short pages look very cluttered when they have a footer. I wouldn't mind scrolling once in a while if it meant our shorter pages weren't as cluttered. Psychless 22:21, 6 February 2008 (UTC)

header inclusion update

There are between 35,000 and 40,000 pages that still include "header" instead of "header2". John Vandenberg 08:24, 9 November 2007 (UTC)

Live stats: Special:Mostlinkedtemplates. John Vandenberg 20:00, 9 November 2007 (UTC)

Your point is? Eclecticology 08:25, 10 November 2007 (UTC)

We have a long running project to replace header with header2. We are about half way there. I'm working on ways to speed this up, as I dont like have two templates for the same task. As we have fairly complex regex's doing the conversion/standardisation, we cant make any radical changes to the template, which is interferring with out ability to record more meta data in the header. John Vandenberg 08:36, 10 November 2007 (UTC)

I find nothing wrong with having both active. Header2 still has that ugly permanent link statement on top of the header box. The Wikipedia page on regex's is virtually incomprehensible. Why would all this meta data need to be recorded in the header? Dividing it into several templates would be a valid alternative. As things stand there are a number of data points that could be shown, and this project is still small enough that many of these possibilities are made more difficult by maintaining a strict header format. Standardisation looks nice, but I don't see it as essential. Eclecticology 09:50, 10 November 2007 (UTC)

I dont like the permanent link statement at the top of header2 either, but that is less important than completing the removal of all use of the "header" template which is being done so that bots can readily parse the headers. Meta data helps us keep control over this enormous resource. I have no problem with additional header templates; I've recently fixed {{EB1911}} so that all EB1911 pages can use it, include the third level deep pages (see the history of 1911_Encyclopædia_Britannica/United_States/Geography). Specialised header templates are fine; duplicated templates like header/header2 are not.

The plan for merging header/header2 is at least 12 months old. Unless there is a proper discussion on going in a different direction, the plan rolls on.

I am sure that we can end up with a lovely "header2" that meets all needs, and that includes finding a way to have a "permanent link" that doesnt visually offend us. Personally, I would rather not deal with that right now; it is where it is and does its job, and once this header/header2 merge is complete, it's open season. John Vandenberg 10:28, 10 November 2007 (UTC)

I just noticed that the author parameter doesn't work in EB1911 template. Many of the articles have identified authors indicated by initials at the end of the article, with a table at the beginning of each volume to identify the initials. It seems that these authors should have the same credits as authors on other articles.

Sometimes it just seems as though more attention is given to the interests of bots than of humans. A "sequencing" template could be separated from the header to deal with the previous and next entries in a series. The current header does tend to conflate previous but equal level articles, and higher level parent articles. Eclecticology 19:38, 10 November 2007 (UTC)

I have raised the EB1911s issue at WT:EB1911#author in header and WT:EB1911#navigating sub sections.

This project to merge the templates isnt being done primarily for the benefit of the bots - if anything it is for the benefit of the bot operators. It isnt fun having to manually approve 2,000 bot operation because of all the irregularities. Standardising the templates removes the complexity in parsing them, which allows the humans to run the bots in a more automated fashion. Sadly, bots need to do enormous amounts of work here because we have so few hands on desk - we need more people involved in the project, especially people who are capable of maintaining one area of the project (i.e. someone to look after all the legal documents; another to look after the encyclopedia page). Also, we also suffer from having under-developed bots, because we don't have a big community of bot writers for wikisource.

That said, there are other benefits of the merge. Currently, many old pages have strange unicode characters in the value of previous/next params. Those need to be stripped out - header2 has those strange unicode characters in the template, meaning that the value is simple for contributors to fill in. By keep the data and presentation separate we gain flexibility :- we can change the presentation easily, add more fields, or change a set of pages from the standard header template to a custom template. John Vandenberg 03:04, 12 November 2007 (UTC)

Thanks for raising the issue at EB11. I have other concerns about creating wikilinks in those articles, but that is best saved for another place.

My apologies if I am sometimes obtuse in my representation of the Luddite faction. I do consider simplicity and comprehensibility as essential, and it is far too easy for bots and templates to wander into realms that require a degree in computer science. The header templates are relatively short, but they still contain many elements that take a great deal of effort to trace, such as the "Class" parameters. Making templates small, understandable and useful will as much as anything else draw more people into using and developing them. I readily admit that I often feel disinclined to bother with headers. For something like the 1001 Nights, composed of multiple-level nested tales, the headers just don't do justice to the situation.

The participation shortage, has wider effects than just on technical development. Vision too easily gets trapped in the details; I am sure that our vision needs to be much bigger than an accumulation of cut-and-pastes from Gutenberg. Policy suffers too when only a very small number participate in a decision; I'm inclined to fear that the ad hoc participants in a decision are not a statistically significant sampling of Wikisourcerors at large. The way these technical issues often play out is about as exciting as watching someone else play a video game. Eclecticology 10:03, 12 November 2007 (UTC)

I agree with you about small templates, and having specific templates for different situations. We already have several different classes defined, such as EB1911, and the court decisions are starting to move that way too (see Eldred v. Ashcroft and the others here). The historical problem of "header" is one we need to get beyond so we can become too imaginative. I would like to see a specific header template for patents, and maybe even obits. The header on sub-pages can also be improved by having per-book navigational templates. The list goes on.

Decisions are made by those who turn up and do the work. Sadly most of our contributors only use Wikisource as an extension of their Wikipedia activities. Curators are a rarer breed. John Vandenberg 11:45, 12 November 2007 (UTC)

I can't be sure if you misspoke with "so we can become too imaginative". :-) With "class" I was referring to the term as it is used in templates. At the risk of having extreme views on this it would be nice if whenever one encounters its use in a template one could more easily find out what it does.

I have no problem with the special templates that have been designed for court cases; nevertheless, these are additional to the headers. We don't really differ on varying the headers for special circumstances. The concern for me here is that of making the header do too much. This is why I suggested splitting up the header and restricting that template name to the bare essentials that identify the work. (Of course, "essentials" would still need to be defined.) What I call "sequencing" could be a separate template that covers the work's relation to it's immediate parent work and sibling works. The header would not be harmed by completely removing the "Notes" parameter, which is pretty well a free-for-all environment anyway.

The decision dilemma is a serious one. You are absolutely right in saying that they are made by those who turn up, and I admit that this treatment of headers came up when I was on extended wikileave from the project, or I might have raised other points that probably never came up. Things need to move on, but I worry about tiny unanimities that take a lot of work to put the project into cul-de-sacs which will require as much work to get it out. Eclecticology 19:27, 12 November 2007 (UTC)

If I remember correctly, I think Pathoschild finally was able to write a regex script that could with very little mistakes convert header to header2. I might try to see if I can find that script. He was trying to have Pathosbot do the conversion, but every time he tried, the bot died. If we can get another bot to do the same task, we could easily convert the headers to header2 and finally get the changes made to header and convert everything back from header2 to header. The only human effort needed really is to make sure that the 30,000+ pages were converted correctly from header to header2, so that we can be sure nothing was broken or messed up.—Zhaladshar ^(Talk) 18:25, 10 November 2007 (UTC)

I have altered the "header" template to place into Pages with arrow in "previous" param any pages that use the old header template in a way that is incompatible with the new header. I'm hoping that when the database catches up, it tells us that there is a smaller set of pages that need to be fixed. Once those have been fixed, another set of pages need to be grouped into Pages with parentheses in "section" param and fixed, and then the two templates are effectively identical in calling conventions. Once that is done we can use change "header" to call "header2", and then subst all of the transclusions of "header" to result in nicely laid out calls to "header2". Does that make sense? John Vandenberg 13:00, 11 November 2007 (UTC)

I don't follow the last thing you said. Had would subst'ing all of the "headers" result in calls to "header2"? And, anyway, I think it should be the other way around: we change all the "header2"s to be "header" again. Header2 was only a temporary template for the entire revamp of the header. It's not meant to continue once header's been updated.

Also, I have another potential update to header we might want to consider. I can't remember any discussion of this, so I'll mention it here. Why not add another parameter related to the publication date? That way, we can add metadata to the page and indicate which version we are actually displaying. This way, we might be able to automatically do some categorizing, similar to how we have the author template automatically categorize. It would take a major load off of the contributor(s) who want to make sure as many applicable categories are put onto a page.—Zhaladshar ^(Talk) 17:28, 11 November 2007 (UTC)

The missing step is {{header-layout}}, used to convert between header and header2. I have done a few by hand[1][2][3][4][5], and two times using m:replace.py.[6][7] The command I used is:

 python replace.py -page:"pagename" -regex '{{[H|h]eader' '{{subst:header-layout' '←' '' '→' '' \
                                           'section *= *\(([^)]*)\)' 'section = \1' \
                                           'section *= *<br>(.*)' 'section = \1'

It makes very little use of regex'es, and if we download the list of pages in that category, we could chop the list into a few smaller lists so that a few bot operators can each process a chunk.

The last two lines are to clean up a few of the old usages of "section" that wont work in header2, because header2 wraps the section in round brackets. I'll be running it mostly attended for the first two runs in order to catch any other strange happenings.

The biggest problem with this approach is that it leaves override_author = {{{override_author|}}} in the output. I'm not seeing that as a great problem, as a bot can go over all of those and remove it.

Once we have fixed as many of these differences, we can move "header2" to "header". There will no doubt still be a few "section" values that cause presentation issues, but they will probably need to be found and fixed by hand anyway.

Adding a year param to header2 makes sense; we probably need to discuss it a little to find an optimal approach, especially the presentation which is a bugbear already. John Vandenberg 01:56, 12 November 2007 (UTC)

I have fixed the problem of it leaving pieces of syntax behind, and started running a header conversion task. John Vandenberg 15:28, 12 November 2007 (UTC)

There are between 7,000 and 7,200 pages in Category:Pages with arrow in previous param. John Vandenberg 14:47, 11 November 2007 (UTC)

Proposed inclusion within the source of this template for the sake of clarifying the use if it when glancing at the template

"<noinclude> <pre>

{{header

| title =

| author =

| section =

| previous =

| next =

| notes =

}}

</pre> </noinclude>" --Remi 03:13, 12 November 2007 (UTC)

I dont (yet) understand why; the documentation on "{{header}}" shows that already, although you do need to scroll down a little to see it. John Vandenberg 04:09, 12 November 2007 (UTC)

override_author

The documentation says that using "override_author" in "header2" will add "by " (as the "header" template did), however this isnt the case, and the cleanup being done by Pathosbot manually added the "by"[8]. Either the documentation or the template needs to be fixed. John Vandenberg 13:48, 12 November 2007 (UTC)

I vote for fixing the template, even though it will add one more layer of stuff to clean up.—Zhaladshar ^(Talk) 14:57, 12 November 2007 (UTC)

What I see as the problem with "override author" is that it is completely counterintuitive. Unless someone knows about it ahead of time it is unlikely to be imagined by a contributor. While the majority of pages are still likely to have an author in the most traditional sense, the minority which deviates from that in not insignificant. Furthermore, these deviations themselves have much variety. While I can see the benefit in ease to automatically enclosing a name in "[[Author: ]]", it strikes me as much easier if the contributors just added in the namespace themselves. Eclecticology 19:52, 12 November 2007 (UTC)

While it is more work, I would also prefer to "fix" it in the template. Perhaps it is possible to solve it in the same way the new "translator" parameter, which automatically works out whether it should be wikilinked. Do we want to set up a (temporary?) category for all works which use this "override_author" param? The header/header2 templates can automatically fill the category so that we can make a more informed decision. John Vandenberg 21:46, 12 November 2007 (UTC)

I see now that Eclecticology proposed at Wikisource:Scriptorium#Bad syntax in headers that the "author" param handles normal wikilinks. I have seen a number of newbies try to use the author param in that way, so it makes sense to smartly handle it where possible. The translator param uses a simple rule: if it begins with a "[", its a link of some sort, and therefore shouldnt be subjected to any template voodoo. As this is a simple rule, bots can learn the rule as well. John Vandenberg 23:46, 12 November 2007 (UTC)

Pages that use the override_author are now placed into Category:Pages with override author (the database has yet to fill the category) as a temporary way to investigate why this field is needed, in order to make an informed decision about whether "by" is always appropriate. John Vandenberg 10:33, 14 November 2007 (UTC)

Example usage

In the examples section, there's a 'Single Translator' example for "Jean de La Fontaine / Tables". This should be "Jean de la Fontaine / Fables".

Also, the Normal Usage example for Thus Spake Zarathustra is incorrect, as this concerns a translation of Also Sprach Zarathustra and should therefor have a translator in the template. How about using an english work for this example instead? Personally I'd recommend using Alice's Adventures in Wonderland/Chapter 3 for this, as it has a Previous/Next link, and is not translated.

212.64.16.131

Template:Header/doc has been updated to use Alice's Adventures in Wonderland as the example, and replaced Tables => Fables. I've not updated the capitalisation for Author:Jean de La Fontaine, because it matches "w:Jean de La Fontaine". Thanks for pointing out these errors. John Vandenberg 00:24, 25 November 2007 (UTC)

Date param

Shouldn't there be (optional?) parameters for the date of the work (and translation, if applicable)? Superm401 13:03, 26 November 2007 (UTC)

That has been proposed at Wikisource:Scriptorium#more header suggestions. Jump in and give your point of view. John Vandenberg 13:18, 26 November 2007 (UTC)

More on Translators

I would like to suggest that we move the translator's name to the line below the author and the title. As you can see on Shah Nameh/Kaiúmers, this line can get pretty cluttered when there are long names involved. --Samael775 23:36, 30 January 2008 (UTC)

Size of Header Text

I wish to suggest increasing the size of header text, at least a little. Currently, on a page containing prose with headings the header hides a bit-- the top left of the page below the header bar dominates the middle of the page above. Making this text larger would help readers see the header text. And honestly, the headers are a little bit hard for me to read-- are they the same size as body text right now? --Mkoyle 13:54, 22 February 2008 (UTC)

I just looked at the text in a header2 header and the text is currently smaller than normal body text. Since sans-serif fonts are harder to read than serif fonts, a larger sans font would be better-- and it might be good to change the text to a serif font. --edited Mkoyle 13:59, 22 February 2008 (UTC)

Syntax help

I am trying to understand—and then adapt—this template, but it is, shall we say...cryptic. I am right now in the first section, where it checks to see if a parameter is blank. However, I don't understand the part listed as "blank!" (no quotes) in the beginning, as in:

{{#ifexpr:(0{{#ifeq:{{{title|blank!}}}|blank!|1}}{{#ifeq:{{{author|blank!}}}|blank!|1}}{{#ifeq:{{{section|blank!}}}|blank!|1}}
{{#ifeq:{{{previous|blank!}}}|blank!|1}}
{{#ifeq:{{{next|blank!}}}|blank!|1}}
{{#ifeq:{{{notes|blank!}}}|blank!|1}})>0|
<div style="text-align:center; border:1px solid #CCC; font-size:0.9em;">'''template error: please do not remove empty parameters 
(see the [[WS:STYLE#Templates|style guide]] and [[template talk:header#documentation|template documentation]]).'''</div>
[[Category:Headers missing parameters]]}}

I understand the #ifeq construct, and that "blank!" is being assigned as the default if title has no value, but my question is: what is "blank!" ??? It looks like if the value is assigned, the #if test will be blank, so it is building a string, hopefully which will eventually be blank. The idea is that all variables must be present. But what is "blank!" and where is it defined, documented, or both?

Thanks! IsaacsF 21:41, 27 March 2008 (UTC)

Hello. There's a subtle distinction to make: that code does not check whether a parameter is blank, it checks whether it is defined. For example, "title" is not defined when calling "{{header}}", but it is defined (but blank) when calling "{{header|title=}}".

The code detects this by assigning a default value of "blank!" (which is a literal string) to each parameter being checked, then comparing the real value to the default value. The real value should only match the default value if it is undefined, or if the template is actually passed that value like "{{header|title=blank!}}". For this purpose, we could replace "blank!" with anything; we're using "blank!" because it is relevant to its purpose, and very unlikely to be used accidentally.

We do this because we want the most important parameters to be used, even if they're blank. This makes it very easy to use the template simply by copying and pasting it from one page to the next, without needing to refer to the documentation. If you don't want that, you can remove it entirely. —{admin} Pathoschild 22:43:22, 27 March 2008 (UTC)

Thanks so much for your explanation. It didn't occur to me that "blank!" was a literal string, but of course it makes sense. Wasn't it Sherlock Holmes who was credited with "remove all else and whatever is left, no matter how simple, is the answer?"

As it turns out, I had another huge problem - I didn't realize that ParserFunctions is an extension and therefore had to be installed. So as I tried to simplify and build block by block to see what's going on...the answer was that nothing was going on. I've passed that hurdle, and your answer is another very helpful step.

Thanks again. IsaacsF 05:29, 28 March 2008 (UTC)

You're welcome. —{admin} Pathoschild 18:59:42, 28 March 2008 (UTC)

More on translations

{{editprotected}}

Is it possible to provide an |override_ command for the translator, exactly as with the author? This would help for unconventional translations. - Mtmelendez 14:52, 31 March 2008 (UTC)

Could you give an example of what is desired? John Vandenberg ^(chat) 05:10, 1 April 2008 (UTC)

I don't have a specific case, but Unknown translators comes to mind. Or how about a government entity which produced the translation work, with no attribution to an individual or group? - Mtmelendez 13:15, 1 April 2008 (UTC)

I think most of those situations can be handled.

• Unknown: translator = ? (yes, this is a pain, but we want to know who the translator is! ), or translator = <!-- blank -->, or translator = name given by historians (e.g. Author:Pearl Poet)
• Government entity: translator = Government entity, or translator = person in charge. (e.g. Portal:United States Department of State)

So, lets put this off until we have situation where more parameters are needed. John Vandenberg ^(chat) 21:22, 1 April 2008 (UTC)

Subpages

We really need to make it so the "title" is auto-linked ("War and Peace" is automatically "War and Peace") since there is no way for somebody stumbling across Chapter 21 of a book to click to the index other than through hoping that they can click through 20 "Previous" chapters. Sherurcij ^{Collaboration of the Week: William Lyon Mackenzie King} 00:54, 27 April 2008 (UTC)

That wouldn't work very reliably. For example, the header at "The Princess (Tennyson)/Canto I" would link to "The Princess" instead of "The Princess (Tennyson)". Auto-linking to the top page might work better, but this requires some expensive coding if it is to work reliably (To avoid linking to "The 1" on "The 1/2-baked apple/Chapter I").

This would also require yet another clumsy hack to check whether it's already linked (linking is suggested by the template documentation, and done on most standard pages). —{admin} Pathoschild 23:44:44, 27 April 2008 (UTC)

Green background and spacing

Hi, I was translating this for ang.wikibooks, and was wondering how you got the green background, and the 'act x' to show on the right. Thanks! --JJohnson 22:33, 29 April 2008 (UTC)

The style & layout of this template are defined in MediaWiki:Common.css, which is a w:Cascading Style Sheets that only admins can edit. --John Vandenberg ^(chat) 00:37, 30 April 2008 (UTC)

Interwiki

Please add ar:????:?????? --Fjmustak 21:02, 6 June 2008 (UTC)

It is already there. John Vandenberg ^(chat) 05:10, 7 June 2008 (UTC)

Date

Is there a way to include a date? Perhaps as a parameter? See John Adams' Fourth State of the Union Address. —Markles 19:23, 4 December 2008 (UTC)

I think we should have a way of identifying a specific version or revision of a work. For example, the copy of The Jewel of Seven Stars by Bram Stoker currently on Wikisource is labeled "(1903)", but is really the 1912 revised edition. Ideally we will eventually have both versions, and they should be differentiated in some standardized way that would be reflected in the header template. Could we add a version= field? Or should we just change the title of the work to include the date, as in "The Jewel of Seven Stars (1903)" and "The Jewel of Seven Stars (1903 revised 1912)" or "The Jewel of Seven Stars (1912 edition)"? Thanks! GCL (talk) 03:48, 27 December 2008 (UTC)

This is a great ideal, but we are still far away from being able to handle this. Putting something in a header won't be enough as long as people believe there will be no significant difference between a 1903 original and its 1912 reprint (or revision}. Adding the edition year to the title is fine when we have more than one version, but until contributors learn to properly source these works, we can't do much more than put comments in the notes to the header. I have already proofread several works on the basis of early magazine publication, and find myself in a quandary when our existing version is from an otherwise unsourced Project Gutenberg text. Eclecticology (talk) 08:05, 27 December 2008 (UTC)