Template talk:Header/2011

by Lewis Carroll

New Parameter

I think it would be beneficial to list a books illustrator in the header as an optional parameter; several texts I have been working on are largely illustrated. I've seen in some books "Illustrations by" or "Illustrated by" and others in the notes section, but there are inconsistencies. Can someone add this in? - Theornamentalist (talk) 13:54, 28 December 2010 (UTC)

There have been a few proposals along these lines, and several options are currently available. One is to use override_author=, another is to add a note, I only see a need at the top-level/title-page, unless it varies between sections, inconsistency in presenting this data is not much of a problem. Using the meta data will be useful, maybe this could be a good reason to implement something like it. I think it is more powerful to link the illustrator (as authors!) in the text, prefaces, captions, and title pages, so I gave up thinking how it could be wrangled into the header template. 14:49, 28 December 2010 (UTC)

I think something simple would work (here's an example). I like to link to the authors in the text too, but I feel like its unbalanced without both in the header, sometimes I feel the pictures are more enriching then the text, and I have wanted to make the illustrator the author, since I can only pick one to place in the header (excluding the notes). Let me know what you think, and please make any modifications you see fit. - Theornamentalist (talk) 15:21, 28 December 2010 (UTC)

Nice :-) I reckon that linking authors is the better investment, I see immediate benefits emerge from that, linking illustrators would have similar advantages. Think about how it would go with a complex and busy header, and check the sections above for some relevant discussion on layout and examples. cygnis insignis 15:56, 28 December 2010 (UTC)

I would like to see "Illustrated by:" in the header. •••Life of Riley (talk) 22:26, 15 January 2011 (UTC)

{{mind header}} should be subsumed

Template:Mind header exists independently of {{header}} and IMNSHO it modified and be subsidiary. — billinghurst sDrewth 12:31, 25 January 2011 (UTC)

I agree. It appears alongside the standard {{header}} as well. It's an eyesore and should be based off the header template. If I knew template syntax I'd do it myself, but I will have to be content with someone else integrating the two.—Zhaladshar ^(Talk) 14:49, 25 January 2011 (UTC)

Oppose. After skimming through some The American Journal of Sociology mainspace pages that apply the template, it seems harmless enough & truly aids in the navigation of the entire work. — George Orwell III (talk) 15:24, 25 January 2011 (UTC)

The larger problem, as I see it, is that we don't have a way to specify authors of chapters in the existing header template. Correct me if I'm wrong, but if we had a "section_author" parameter, it could essentially do the same thing as this template, without using a separate template. This issue appears constantly in all serial publications and anthologies. I see discussion several months ago regarding this; is this something we can implement? —Spangineer (háblame) 18:18, 2 February 2011 (UTC)

I feel we need to move away from this table based header for one based on divs like the French WikiSource seem to prefer anyway. With the current table based header, the only solution is keep squeezing additional lines in between headerprevious & headernext using line breaks to expand the table cell whereas using divs still allows for the use of tables (wrapped in a div) but allows for the interchangabilty of sections, subsections, authors, co-authors as needed without corrupting the basic layout for newbies. — George Orwell III (talk) 21:14, 2 February 2011 (UTC)

Have you toggled through the variable layouts and see how the mind header doesn't play the game? I would greatly encourage us to look to continue the development of header. To note that it is not the layout, nor the information, nor the display that was my concern here, it was . We have lots of other header template variations like {{DNB00}} that are subsumed yet still have navigation aids. Plus if we need more navigation aids, then let us continue that development. — billinghurst sDrewth 00:24, 3 February 2011 (UTC)

I have replaced the usage of Template:mind header; it wasn't using half of what we have in modern day header. Will cull next. — billinghurst sDrewth 10:27, 27 November 2016 (UTC)

Incorporate portal links into {{header}}'s sister links box

I'd like to propose that we put portal links directly underneath sister links in main space headers. For several examples, see User:Spangineer/Sandbox3.

Details are there, but the idea is to expand the functionality of {{Plain sister}} to allow for up to three portal links, which would display in the same <div> box that the sister links appear in. —Spangineer (háblame) 18:28, 2 February 2011 (UTC)

• Support - I like it. What do you think of putting the WS portals on top? It seems like internal should maintain visual priority. Also, I think the use of the WS logo is redundant. It looks nice, but maybe this is more appropriate. - Theornamentalist (talk) 19:40, 2 February 2011 (UTC)

  I'd be fine with putting WS on top. As for logo, I'd prefer the WS one, and not only because it looks nice: I think it helps emphasize that other material is available on WS. The sister projects are all named, so I see the icon serving as a way to specifically say that there is more related content on Wikisource itself. —Spangineer (háblame) 20:36, 2 February 2011 (UTC)

• Comment - Do we really need to write out and link what the box is for after the icon but before the related links (i.e. sister projects, related portals)?

  Seems like a waste of space when the icon itself could handle that (hover your mouse pointer over the icon & click on it here to see the alternative I'm thinking of). — George Orwell III (talk) 21:01, 2 February 2011 (UTC)

  I'm not opposed to alt text, but it doesn't work for me in that example: I see "Special:Sitematrix." —Spangineer (háblame) 21:38, 2 February 2011 (UTC)

  Odd - I used the same syntax as always

  [[File:Wikimedia-logo.svg|17px|alt=Sister Projects|link=Special:sitematrix]] and the alt text has always worked here. — George Orwell III (talk) 21:56, 2 February 2011 (UTC)

  It could just be me... not sure; I have popups that sometimes seem to conflict with alt text. —Spangineer (háblame) 22:52, 2 February 2011 (UTC)

  Let's make sure it's not the order of parameters or the lack of plain links before I give up on saving space and invoking that silly blue Notes bar for nothing. — George Orwell III (talk) 00:11, 3 February 2011 (UTC)

  This is a point I wanted to make for some time too, not that I have a solution, but virtually all the works I have done here use plain sister, but have no notes. This creates the large blue space that only hosts the sister links, and soon to be portals. - Theornamentalist (talk) 00:25, 3 February 2011 (UTC)

  You mean a blue notes feld that only expands or contracts based on the actual text content & not the amount of goofy-quick-link being boxes added? See this prior sandbox for what I think you are driving towards. — George Orwell III (talk) 06:13, 3 February 2011 (UTC)

  I would agree with Spangineer that getting portal ns link into something like plain sister would be useful, and I agree with Theornamentalist that Portal link should have priority, though believe that the WS icon is preferable. NOTING that I would also state that we should be looking to include {{similar}} which has a similar problem of location and linking for disambiguation. Do remember that plain sister template fits into {{disambiguation}} so that needs to be part of the consideration … which them prompts having more emphasis on "what links here" "search for term" and this starts to make all the header components bloody big. That then says to me do we take a step back, and look at the use of the page real estate, and can manage the left hand side far better and look to incorporate "layout options." — billinghurst sDrewth 09:36, 3 February 2011 (UTC)

  I don't believe we can efficiently achieve all those "goals", leave the door open for future additions/modifications, keep the post-expand include size, the template argument size and the expensive parser function count low across the board for the principle uses of such a header template and still manage not to have it look like garbage at the end of the day without splitting off the 'green navigation/authorship/title' portion from the 'blue notes' portion once and for all. Let's have {{header}} call {{notes}} when needed rather than having "notes" around all the time just to call all these other existing and/or possible templates on top of providing the "field" for plain-text-blurbs it was originally thought to handle only to begin with. — George Orwell III (talk) 15:04, 3 February 2011 (UTC)

I've reworked my version of {{plain sister}} so that WS portal links appear on top. See User:Spangineer/Sandbox3 for the results.

Alt-text is still not working for me (the last two examples didn't work either) but I'm not convinced the labels are necessary anyway; I'd be happy to remove them.

Is there any objection to editing {{Plain sister}} directly? Or should a different template be created and used by {{header}} instead? —Spangineer (háblame) 20:29, 3 February 2011 (UTC)

Download bar

I was working on this sometime ago, I know Wikisource pdf's aren't working with our index pages (for now) but I was thinking to add this within the box. Oh, and it is only for appearance now, not really functional. How do you feel about this? as well as hosting plain text (.txt) files on Wikisource? - Theornamentalist (talk) 21:05, 2 February 2011 (UTC)

I could see this being useful, if at some point we had all those file formats. Personally I'm not particularly interested in adding txt files and pdfs and such, but if other people do, then this template would be a nice way to organize them once they are present. —Spangineer (háblame) 21:38, 2 February 2011 (UTC)

To piggy back on Spangineer's proposal, I've put together this download bar which fits within the box as does his. I would like to stress that his proposal is better standalone at this point, because I have seen many different ways of linking to portals and the like and there needs to be consistency; in fact; I would not mind using something similar in the case of a series of works. This is in regards to our current featured text, which is under the veil of a single published work (by our organization standards). I'm wondering if this once plain simple nav system could be turned into the main way for linking works. A quick thought that the "main" page of a work typically does not have anything to occupy the top left corner. Placement of a large "plain sister" box, with rows:

1. Serial works, sequels
2. Wikisource portals
3. Downloading formats
4. Sister sites

in the top left corner would fill up the typically blank space, and remove the occurrence of plain sister in the notes, with no notes; essentially tightening up the whole thing. Regarding somethings on the download bar; I think the downloadable pdf/djvu is great to have; sometimes looking at the original is preferable especially with illustration heavy works. The plain text (.txt) are not supported for upload, but I think they should be. A capability we lack is to download the formats for various e-readers, which can be done for some easily with text files (like here). The web page can be saved as offline content for reading and of course printed as well. I understand this is redundant to somethings that occur in the side bar, but I feel like it is more noticeable here. - Theornamentalist (talk) 03:29, 3 February 2011 (UTC)

Here at the top left is an example of all four together, We would have to increase the left side percentage from 20% of whatever it is in the header template. The enlarged header coincides with my belief that more information should be included in the header template; ie publisher, location, illustrator, editor. - Theornamentalist (talk) 05:21, 3 February 2011 (UTC)

The options that you present should be something that we want to present, though to me it seems to be part of a different package as you later stated including EPUB, printing, (?kindle) and other formats that the system can generate. however, then I think that this should only be done when we can deliver it in an automated capacity. Again I think that it is part of a more global rethink on how we manage the various parts and looking at our real estate. — billinghurst sDrewth 09:51, 3 February 2011 (UTC)

Rather than portal1= portal2=, try #titleparts

In Commons:Template:Creator for the occupation field, there is utilised Occupation = Occupation1/Occupation2/... and pulled it apart with #titleparts. That seems a little neater than having multiple portal parameters. Worth a go IMNSHO. — billinghurst sDrewth 07:56, 15 February 2011 (UTC)

Good idea. I'll do some testing with this and implement it once it's stable in my userspace. —Spangineer (háblame) 15:12, 15 February 2011 (UTC)

Done. —Spangineer (háblame) 15:52, 15 February 2011 (UTC)

Noice! Israel-United States Memorandum of 1975 — billinghurst sDrewth

Related_author ???

His cousin Jim? His mistress? Or partner in crime. I do not readily see where and how we are going to use it. Looking forward to the enlightenment. — billinghurst sDrewth 06:15, 19 February 2011 (UTC)

I don't understand this parameter addition either; I am proposing to change the appearance (below) and have not included it. - Theornamentalist (talk) 22:20, 19 February 2011 (UTC)

Who exactly is going to assign "relevance" to any particular author in relation to any given work or body of work - the contributing WS user/editor or the original author somehow? — George Orwell III (talk) 09:57, 20 February 2011 (UTC)

In my mind, the same kind of person who decides that a book about the Dacian Wars should have a link to Portal:Dacian Wars. Inductiveload—talk/contribs 16:23, 20 February 2011 (UTC)

I added this parameter to plain sister based on a request from billinghurst, which was seconded by GO3, and a mock-up went down well in IRC. An example of the kind of use I was thinking of is at Charles Dickens (Chesterton). I think it is useful for works about a person, as the link to the person often gets lost in the text of a page, relegated to the same status as any other link. In fact, in this case, there is no text to link to unless you add the "notes = This text is about Charles Dickens" to the header (good luck trying to get consistency there, at least this way we have the same amount of/potential for consistency as we do with portal linking). If you can link to the portal for an article's topic, should you not be able link to the author for an article's topic? Inductiveload—talk/contribs 16:23, 20 February 2011 (UTC)

Seconded by me? Fairly sure I would be against any such usurping of standard Wiki practice of inline inter-, sister- or red-linking within the content itself with such a subjective parameter. (I can't find exactly where this started - not on anybody's talk page afaik - where did I say I was for incorporating this into header?) — George Orwell III (talk) 16:35, 20 February 2011 (UTC)

Whoops, my bad. I read "Maybe in this case the primary focus should be getting the reader to the appropriate the Author: page first & foremost" as saying this kind of link would be useful. I forgot you didn't like using the plain sister box. Disregard that clause of my statement. You didn't say you wanted it in header, but if it's in plain sister, surely it should be accessible from any template using plain sister. Inductiveload—talk/contribs 16:55, 20 February 2011 (UTC)

Ah this was over on plain-sister & sorry for not being super clear there. I thought the linked example of Alfred Tennyson made it clear enough how not to loose an author link in all that clutter called content :-| — George Orwell III (talk) 17:13, 20 February 2011 (UTC)

Yes, it is helpful if the name is in the title. But it isn't always:

• Charles Dickens (Chesterton): no text to link
• Catholic Encyclopedia (1913)/St. Mary Frances of the Five Wounds of Jesus: no headword to link (I personally very much dislike putting a link in the title parameter of header).
• Monro, Robert (d.1680?) (DNB00): if the headword is split, which part to link?
• Masefield: great if you know Masefield is someone's name, and not, say, a village in Suffolk.

In all the above cases, I think an explicit author link is a lot clearer than hoping a user (who as likely as not is not familiar with Wiki-style linking) spots the link in the text. All WS users can easily pick out these links, but that is not everyone by a long way.

Also, when these links are more widely used, then we have added a useful item of metadata to all biographical works.

I know the parameter name isn't ideal, and I've asked for alternatives (if we change it, it will be easier now). Inductiveload—talk/contribs 17:42, 20 February 2011 (UTC)

Is biographee too specific a term? It looks like a misspelling of biography but it is a valid word meaning the subject of a biography, as opposed to a biographer. It works for the examples quoted here but it might not be flexible enough for general use. (Unless you want it to be inflexible to regulate the use of the link.) - AdamBMorgan (talk) 13:24, 10 March 2011 (UTC)

• I agree with the change, though I see the concern over the ambiguity of the current label, wikilinks are not at all obvious and the gross and disgusting sister links are only bested in uggliness by their inconsistent sizing on some other projects. I love wiki-links but they are not at all obvious to a newbie, especially one who may be at our project for the unimaginable - reading; they are particularly hard to find in the header. Although I don't care much for the ugliness created by the big info boxes on de.ws, they at least put the information out front where it belongs. We should at least have the same information available about the work that one can find on a reasonably complete {{book}} on Commons. Preferably a lot more. And we shouldn't hide it on the talk page either.--Doug.^{(talk • contribs)} 17:54, 20 February 2011 (UTC)
  • Though the idea suggested here for another place altogether for metadata is even better I think.--Doug.^{(talk • contribs)} 18:31, 20 February 2011 (UTC)
• I removed the instruction on "related author" (and related portal). If an author's name appears in the text it can be linked in context. CYGNIS INSIGNIS 02:34, 19 August 2011 (UTC)

Doug reverted your edit. You reverted Doug, and I have returned it to the status quo of the past four or so months. Highly used links, especially the entry to the portal namespace. Both are optional in their use. — billinghurst sDrewth 23:33, 19 August 2011 (UTC)

That is a bogus rationalisation, the status quo for many years was not having them. Using the impetus of thousand of 'process edits' while content contributors are simply getting on with is a foul approach, the same strategem appears at the other place—'it is too late, "we" [a couple of vociferous proponents] already decided and there is no going back—on other matters it has been pointed out that it is unreasonable to bring that form of edit-warring here (and COI in a contentious area undermines Billinghurst's position as both a gnome and adjudicator). The suggestion that it is "optional" does not negate the concerns raised on 'relatedness', "parameter =" quickly becomes compulsory. Portals are a proposal, under development, see en.wp for their unproblematic existence linking to content, yet controversial inclusion within it. Adding it to template documentation sucks, especially when it leads to scope creep. There is no consensus, there is not even a quorum. CYGNIS INSIGNIS 00:45, 20 August 2011 (UTC)

And note: I was prompted to remove it because "Doug" referred to the documentation in a discussion on their talk page. The scope of this site is very simple, the opportunites for extended debates on everything else ought to be almost none. Yet another icon or template parameter puts the user's notion idea before the text, similarly, adding what one thinks to published author's text, or circumventing "no user's content" makes it one's OWN. This relatedness adds noise, complexity, and opportunities for disagreement, which also ought to be almost none. I expect this will be bombed with sophistry on why this sort of thing is okay, or fabulous, and feel I must note that this will once again be from users who invest their time in talk pages and process. It seems that proofreading is infra dig for admins, it is drudgery for some plebs to be lorded over; if they do, it is merely to give examples for some proposed novelty. Anyone investing in this discussion should take a step back, asking themselves "why am I here?", read about volunteerism and selflessness, because to those who make unobjectionable contribs it is infuriating to be taken away from what they are interested in, held to ransom by those who seem to have no interest in the thankless task of chipping away at the 1.5 million books that could be added and linked. CYGNIS INSIGNIS 01:27, 20 August 2011 (UTC)

On Novelty, the Wherefore and the Why:

That which has been is that which will be,
And that which has been done is that which will be done.
So there is nothing new under the sun.
—Ecclesiastes 1:9

I noted earlier the lines, "Our little systems have their day; They have their day and cease to be." Not all "systems" are bad, of course, just because they "cease to be"—and not all novelty is bad just because it's not really new! But if I had to choose, it would be in favor of proofreading over process (of course, without process,—and even some novelty, there would be no proofreading here!)... Every now and then I ask myself whether all this data entry will be for naught one day (you know,—when all the power grids fail, and when we are once again left to our own mere mortal devices), and whether my time might be better spent doing something else... But I remind myself that even when Wikisource ceases to be (and it will someday), the truths and myths and magic that this sister's pages contain will never cease to be, for they are eternal! Proofreading—like reading—offers us glimpses of the eternal. The process (which is still necessary) is a means to an end—the end being that which is eternal.

For man doth build on an eternal scale,
And his ideals are framed of hope deferred...

—from "Sonnets Written in the Autumn of 1914" by George Edward Woodberry.

Those involved in the process only are missing out (in my opinion), however, if they don't avail themselves on occasion of the "menial" job of proofreading for the sake of proofreading... I had a dream two nights ago about how my daughter was to give me a message from someone I did not and never would know, but who wanted to exchange letters with me. They were to be merely "academic" in content, however, for this person had a significant other named Violet in whom they were "very much devoted"... Not having ever given (to my knowledge) conscious thought about the name Violet, what a surprise for me to have read—two days later—about one whose eyes "were bluer than the violets in spring," whose sad eyes "looked like violets in a snow wreath," and "like violets were her heavy eyelids, and underneath her sleeping eyes a violet shadow lay." And who should she be loved by and gazed upon than by One meant to "keep [his] visage hidden; [for] if [one] once shouldst see [his] face," thee must he forsake, for "the high gods link Love with Faith." The dream really did come before the reading, but how much more rewarding the reading for the dream, and vice versa! What does all this have to do with Related_author ??? you ask? Absolutely nothing, so I apologize :) Londonjackbooks (talk) 04:58, 20 August 2011 (UTC)

Returned the documentation to the previous status quo, while discussion continues.

To the commentary about portals. We used to have topic matter within Wikisource: namespace, and now it is within Portal: namespace, that was a community decision, though with some dissent or disagreement, however, it occurred. We have {{indexes}} with its instructions that exists from 2008, and that was the previous means prior to the introduction of the portal parameter within {{plain sister}}. To the remainder of the false argument that is more an attack at people … <shrug> that becomes your approach regularly, and I refuse to play. There are minimalists and there are maximalists, and there is space in between and I feel that we will end up in the space in between. — billinghurst sDrewth 06:37, 20 August 2011 (UTC)

It is a classic political strategy, insist on more than is reasonable to expect, then say any opposition is hostile and uncompromising. I'll repeat, this document was referred to as if it was policy, for one user to change another's contribution. The portal ns was a proposal for a catalogue to en.ws works, based on similar catalogues at real libraries, in the real world, not an opportunity to advertise user generated content. If readers want to navigate to content in that way they are welcome. However, in many recent WS:PD discussions the conception in billinghurst's mind is that it can be a sandbox, a dumping ground for content that belongs at other sisters, if anywhere. Sure to win the hearts of the tendentious, en.wp fugitives, but not good for the integrity of the site. "Parameter = " is seductive, 'I don't know how to contribute, have no interest in old texts, so I will race around providing the x in the equation: something equals' whatever I can glean by glancing at the text. There is no constraint, no guidance, and no policy. Who decides when it goes awry? The admins, whose qualifications are adding some categories and making chat on IRC. Who decides when admins disagree? The next rank up, checkuser. What good is imagining one has authority if one is unable to demonstrate that: things that create discord, like subjectivity, serve that kind of authoritarian structure very well. I'm undoing it until the guidance or policy is up, agreeable, and proven to work: this never happens, because the hoped for dynamic is that new users will ingratiate themselves to someone who imagine this is their castle. CYGNIS INSIGNIS 10:58, 20 August 2011 (UTC)

• And back again to the way it's been since February. Cyg, there's no such thing as a quorum for consensus. You have a habit of showing up weeks or months after a change was made and simply reverting it saying there was no consensus for the change. I've run into this with you before on a template that I wasn't even clear that you disagreed with substance of the change. The change was made in February to replace the old clunky, ugly system of sister boxes, the same sort of junk they insultingly throw at the bottom of an article on en.wp and call it a sister link. Ours were at the top and were butt ugly and intruded into the white space. *That* is why this came up on my talk page. There is no obligation to use them. The point was so that an article wouldn't have a template box that says "Wikisource has works by or about Author:Matthew Arnold on an article entitled Matthew Arnold (Coates, 1909); which was a "no duh!" kind of template. "related_author" was the language User:Inductiveload came up with and he asked for better alternatives and no one could come up with one. I agree, it's not ideal, but linking the name "Mathew Arnold" in the text or in the header doesn't tell you the same information, unless you click on it. The current link at least tells you that the subject of this work is also himself an author, whose works we actually have - or at least we have an author page. This should remain until we have decided to do something different. Otherwise, we could all just go around removing everything that everyone else did because you don't have consensus for any of that, it never having been discussed at all. The principle of "silence equals consensus" is a valid principle. Consensus can change but you are now the proponent of change and must establish the new consensus; else we should stay where we have been for the past six months.--Doug.^{(talk • contribs)} 13:27, 20 August 2011 (UTC)

And so the sophistry begins again. The consensus was formed on IRC, and turned out to be nothing of the sort "Seconded by me?". You are offering to document the guidelines? What else would a link on a person be, to anyone actually reading the text, if not an author. Consensus can change? it should first be formed. This is link cruft and has no use at this site.

Your contribs, Doug, are an excellent of a talk page ghoul scouting around for an argument, but if you make proper and unobjectionable contributions from another account then I apologise. The first interaction I remember having with you was where you opened several discussions on template talks saying lets change this yesterday, you had done bugger all, and still haven't as far I can see. Anyone can bomb a talk page with discussion until there is no more replies, then claim "silence=consensus". That a few people, with a similar disinterest in content, get together on an unwatched page, change the whole scope of the site. You reverted me because you referred to in in a discussion on your talk. At every point, when I express my views, you have harried me with personalised rejoinders and bury what are succinct and pertinent comments. I'm interested in the integrity of the site, your interest is honing your debating skills by tangling with others in an adversarial fashion. You like this redundant extension of the header, at least for the purpose of argument, you have a conflict of interest in restoring it, the first I heard about any documentation was the other day. At some point I have to stop stamping out these potential bushfires and get back to why I log in. Why do you log into this site? have a serious think about that before worrying about links being 'buried amongst all that grey morass of text'. The pages here are not for creating waves for surfers, it is text people might want to stop and read. CYGNIS INSIGNIS 15:02, 20 August 2011 (UTC)

• Returning to the original question of the utility of "Related author" within {{Plain sister}} and therefore here. I can see that in a few cases (per some of those quoted above - I don't agree with the Masefield one) it is a useful field. The field name is not great, however that doesn't matter in the template provided the documentation of how to use is clear. I suggest that the words "Related author" do not need to appear in the Plain sister box, but just the author's name is needed.
  I am more concerned that the documentation of the fields in {{Header}} does not state which fields are optional and which are mandatory but can be empty. I've got caught a couple of times when fixing up header errors from new contributors with the message "Don't leave out mandatory fields." I tried to fix them and in the end I've had to copy a new blank header from here and fill it in. If I don't remember which are mandatory and which are optional, how can I expect a new contributor to know?
  With respect to the Portal issue. This feels like the arguments on WP about categories vs navboxes vs lists. Portals are just a way to navigate WS. e.g. What other works do we have about Nepal? What else did Laura Lee Hope write? What are the differences between this version of the Constitution of South Africa and the one before? What do we have on the Napoleonic wars? The first question is best served by the category, but the portal could also be used; the second from the author link; the third from {{versions}} and the fourth from the portal (but the categories could be used). Beeswaxcandle (talk) 01:35, 21 August 2011 (UTC)

Splitting hairs here … only one field is mandatory to have data, and that would be the title, all the others can be left empty. For construction processes re required, the top displayed set on the documentation is pretty much that list and comes through from the gadget preload, though  section / translator / year  can all be omitted without complication. — billinghurst sDrewth 12:49, 21 August 2011 (UTC)

A few changes to plain sister

With the addition of "related author" and seeing the enlarged notes area, I thought to make a horizontal, or single row plain sister. With this, I think the addition of a series type column (tentatively using series, prequel and sequel, and what appears, alternatively to what I've made could be the word "sequel" instead of "Through the Looking Glass) and a disambiguation column would be nice. I've also removed the box as it seemed unnecessary and changed the portal image, since there are multiple in-site links, using the WS logo for only portals seemed odd. - Theornamentalist (talk) 22:31, 19 February 2011 (UTC)

Far too 'busy' for my taste but I can honestly say your Portal icon makes far more visual sense than the current one being used. — George Orwell III (talk) 00:00, 20 February 2011 (UTC)

I am with George Orwell III about it being busy, too many icons. I presume the reason that the WS icon is used is to show that it is a local link, so taking that thought further, the mention of Portals and related authors all belong behind the WS icon, so I have played and have this.

I am a little concerned that you are trying to over-engineer {{header}}. It is designed to work for all of our works, and things like OTHER and SEQUEL are so very specific to few works. The NOTES field can adequately handle those components for the few works that require it, and where it doesn't fit within PREVIOUS/NEXT usage. I do think that we need to do more around getting rid of {{similar}} — billinghurst sDrewth 01:52, 20 February 2011 (UTC)

I don't think that "related authors" is needed. I actually don't understand how this would be consistently used. Regarding the "other" and "sequel", yes they are not used in every work, but I think using something like this could help with formatting; I've seen many different ways to link to serial works; in the "next" field, in the notes section, in the "previous" field, above the header. I think that it is common enough to use in plain sister; whether or not in the format I've presented. I suppose the icons may be excessive, and I would not be against removing or simplifying the setup. In the least, I think we should change related authors to serial works. - Theornamentalist (talk) 04:58, 20 February 2011 (UTC)

To be clear - I wasn't opposed to the general idea of adding what was being offered up, just that the provided example's layout wasn't very mindful of the existing layouts already in place nor did it display somewhat "consistently" under the various basic browser font settings here. — George Orwell III (talk) 10:14, 20 February 2011 (UTC)

Shortcut parameter and move it to Template:plain sister

We haven't put shortcut and its output into our examples, and we should do it. Actually, to me it now makes sense to move "shortcut" to Template:Plain sister with our other add-ons rather than to host it directly within header. At that time, we need to look at the positioning of shortcut with respect to the other bits, and its size, as it now looks big, fat and ugly. Billinghurst (talk) 05:15, 10 March 2011 (UTC)

See a mockup at User:Spangineer/Sandbox3. —Spangineer (háblame) 14:01, 10 March 2011 (UTC)

Template:edition

To keep pumping this up, if one looks at Naya Kashmir, I would say that {{edition}} is another parameter that should be considered for inclusion within plain sister. Billinghurst (talk) 05:05, 11 March 2011 (UTC)

Agree with Billinghurst; currently I think it looks pretty bad when plain sister etc. are in the notes field with {{edition}}. Think it should go first above portal. I also think we need to discuss what satisfies the need for using the template. I've clicked on it before to find useless rambling, or formatting issues. The discussion page currently hosts both, I think that needs to be reexamined. A stellar case for usefulness with edition is in the works of LondonJackBooks, (see Stops of Various Quills (1895)) although one could argue that it may belong at en.wp. But these are separate issues; I still advocate merging of {{edition}} into the plain sister tables. - Theornamentalist (talk) 12:47, 6 June 2011 (UTC)

In keeping with the circular iconography, how about using this image?

Information about this edition.
related portals: Poetry.
sister sites: Wikipedia article, Commons category.

-Theornamentalist (talk) 23:24, 6 June 2011 (UTC)

I'm happy for {{shortcut}}, {{edition}} and {{similar}} to be incorporated into {{plain sister}}. My only reservation is that the template is not especially "plain" anymore and full implementation could leave a lot of whitespace in the header (well, blue-greenspace). This could solved by dropping it below the header but that starts to blur the header/body separation. Alternatively, the elements could go in series, rather than parallel as at present, and the background changed from transparent to the namespace-appropriate header colour. - AdamBMorgan (talk) 11:56, 7 June 2011 (UTC)

For example, and this is very rough, as follows. - AdamBMorgan (talk) 12:20, 7 June 2011 (UTC)

• I like it horizontal, takes up less space too. I think we need to review icons though, so that were not using several wikisource ones. I like the header color idea, but I wonder, maybe we should have three areas prior to content (as opposed to two right now); this would be one for the header and navigation, one for the growing list of links and such here, and one for the classic notes field, in that order from the top. - Theornamentalist (talk) 11:52, 8 June 2011 (UTC)

For the vast bulk of our works, horizontal would be plainly overkill, so maybe there is the call for an option for a presentation form that displays this in horizontal format. We would need to go through sandbox options to see how it looked, and that it works well. The displayed version is too busy and probably a touch daunting to the newcomer. — billinghurst sDrewth 03:54, 13 June 2011 (UTC)

I wonder if we can make it look neat, like a small horizontal insert between the notes field and the content. I could imagine it being pretty descent looking, and I suspect we may just be used to how it is currently and are comfortable with it working 90% of the time. - Theornamentalist (talk) 05:44, 13 June 2011 (UTC)

Sister output

Currently, we have all sister site outputs as "Wikipedia article, Commons gallery, Commons category, quotes, news, definition, textbook, course, taxonomy, meta." I feel like the odd ones out are "Wikipedia article, Commons gallery and Commons category," which are wiki-specific. I think that changing this to something like "encyclopedia," or "encyclopedic article' or something, and then "media gallery," and "media category" are more consistent with "quotes, news, definition, textbook, course, taxonomy, meta." Are there any objections to changing it? - Theornamentalist (talk) 22:40, 11 June 2011 (UTC)

Yes, and maybe the discussion could be framed around an open question, and one that has a reasonable time associated with it. This was certainly not an urgent request. Wikipedia and Commons are keywords, give useful specificity and of value to the brand. It looked butt ugly IMNSHO, and I have undone it. — billinghurst sDrewth 02:11, 13 June 2011 (UTC)

I apologize; it seemed no one took any interest nor seemed to care, and although admittedly hasty, I saw no disapproval. I don't see how it appeared butt ugly, ha, they were just IMO a minor change in words in order to have consistency among sister sites. If we veer in this direction with using the sister site titles, then we to advertise the wiki-brand evenly; this means using Wikiquote instead of quotes, Wikispecies taxonomy instead of taxonomy, etc. Otherwise, the branding is unnecessarily uneven. Although Wikipedia is the most obvious choice for branding, I certainly use Wiktionary as a resource more than Commons; I would hope that that brand gets light too, and not just Wikipedia and Commons. - Theornamentalist (talk) 05:35, 13 June 2011 (UTC)

How about either of these?

sister projects: Wikipedia article, Commons gallery, Commons category, Wikiquote page, Wikinews articles, Wiktionary definition, Wikibooks textbook, Wikiversity course, Wikispecies taxonomy, Meta-wiki page.
or
sister projects: encyclopedic article, media gallery, media category, quotes, news, definition, textbook, course, taxonomy, meta.
- Theornamentalist (talk) 15:03, 15 June 2011 (UTC)

I understand that this is not an urgent issue, but it seems very straightforward to me. Commons and wikipedia as a brand should not be the only sister sites mentioned by name. We should either turn all of them into "brand" names, or none. Regarding the revert Billinghurst, ha, I am really straining to see how using "encylopedic" in place of "Wikipedia" and "media" in place of "Commons" has made it butt ugly. Is it the loss of the capitol letter? - Theornamentalist (talk) 14:45, 20 June 2011 (UTC)

Content Navigation

I feel like I may have brought this up before; I think we should have a section underneath the "section" parameter for navigation. Currently I am doing this in the "section" parameter if possible. I prefer to offer navigation within the header, leaving the content section untouched for various reasons. Since we can give the reader convenience with this being a webpage, I feel like it should be done. It has certainly helped me before when returning to a section I was reading. In the past, this has been done with the TOC native to wikimedia (see Nature (book), but as we move away from that formatting style, I would hate to lose the option for the reader. Some examples I can give are sections within a single page (see Nature, Addresses and Lectures/Nature) and on multiple pages (see The Swiss Family Robinson, In Words of One Syllable). I find this preferable to {{AuxTOC}}, as it is less obtrusive on the content, but I understand that there are some instances where using it is beneficial either because of the number of sections or actual name of sections being long themselves (see Mrs. Caudle's curtain lectures/The curtain lectures). However, rather than continuing the way I have, which is misusing the "section" parameter, I think we need to create a new parameter for navigation. - Theornamentalist (talk) 22:03, 19 June 2011 (UTC)

While I mostly agree with your premise and recognize the need for more flexibility as well, trying to do something like that, plus all the other variations-on-a-theme that go along with it under this currently table-based green header is pointless. We'd need to grand-father in the current template in its basic form (i.e. leave your plain sister at home) and start moving to an all div based header that looks much like the current one but allows for far more flexibility for swapping in and out such customizations as needed and that the community can live with. Go take a peek at the German and French WS sites for some good examples of what can be done by just mimicking the the current first three lines of our header and anything under that can be 1, 3 or 5 column single-row tables nested and/or wrapped in a div tree. I see they've even moved into scrolling & pop-down menus in some cases.

If one doesn't appreciate the need for these kind of improvements - I'm sure there are ways to give you the current header layout without too much trouble (again - I may be assuming too much on that point though). -- George Orwell III (talk) 22:37, 19 June 2011 (UTC).

I understand; there's actually quite a lot I like about fr.ws, including their columned text, but that's another discussion. At this point, I guess we can put this on "the list" for discussion if/when a header change comes. I am willing to help with that when it comes time. - Theornamentalist (talk) 23:45, 19 June 2011 (UTC)

What is wrong with putting it (a Toc or whatever) into the Notes field where it is a long page? We regularly do that in in longer index pages. For many other types of pages it has seemed less necessary and of less value. Generally we have broken works down to subpages (chapter/part/entry) partly as a way to address this issue. Otherwise there probably isn't a universal solution and not one that is easily coded into this template. With regard to use of NOTES parameter while it is notes, it also covers miscellaneous bits like ToCs. I have seen others put it at the top of the pages (usually as a template) outside of the header section, and that can be okay but not my preference. — billinghurst sDrewth 02:10, 20 June 2011 (UTC)

Example of use of a ToC Chronicle of the Grey friars of London/Index — billinghurst sDrewth 02:13, 20 June 2011 (UTC)

Personal preference I guess; I use the notes field for commentary if there is something to note of the publication or edition, which is very rare. I think to me it looks neater centered in the header, is all. - Theornamentalist (talk) 03:47, 20 June 2011 (UTC)

'What's wrong with navigation from the notes field?' Nothing I guess if you treat anything and everything that isn't a "standard parameter" as supplemental or secondary rather than critical or essential in properly & efficiently accessing or absorbing certain types of works by potential readers. I call them potential because we don't have any real traffic that we can confidently speak of to base any of our (re)designs on to be fair & balanced about it. And my point wasn't about trying to code anything and everything into the current template - just the ability to rationally organize and/or swap in or out these alternative OR essential means of navigation.

The current HTML table design is just not "friendly enough" to keep accommodating this thing or that option cleanly or consistently much longer. The more the works that have received the "sister" treatment, for lack of a better term that is, the more obvious its becoming that the light-blue notes field is more of an eyesore than any benefit when there are no real notes found along side of the sister bullet points to speak of. You might be right about how the current practice is just fine considering the amount and type of traffic that's taking place on en.WS but I suspect that notion isn't going last forever let alone much longer and this "miscellaneous item creep" we're talking about by relegating it once again to the notes field (plus all that's been added there already over the past couple of months) is just evidence that its (over)usage is already stretching the limits of what it was originally intended for. -- George Orwell III (talk) 12:03, 20 June 2011 (UTC)

I am not going to disagree that Notes gets to be a bit of a 'glad bag' nor that a better solution (whichever/whenever/whatever) will be fantastic. That said miscellaneous bits have to go somewhere, and I much prefer that the standard standard bits appearing in the green, and the occasional/miscellaneous in notes. Having them as parameters of header allows that redesign to occur more easily, and the "sisterhood" of the property links is at least an order of magnitude better than the hotch-potch of the previous {{wikipedia}} {{commons}} ... links that we had previously.— billinghurst sDrewth 14:21, 20 June 2011 (UTC)

I wholeheartedly agree that the current solution is better than the white-page intrusions we had before with those older templates. But that just brings us back to point at hand - do we really want to repeat the same placement "policy" as the one being phased out by suggesting things like static TOCs wind up in the page white-space as well? or do we want to push the "problem" down the road once again by dropping things like that off in the notes field for now? Its become a lose-lose situation imho. -- George Orwell III (talk) 22:19, 20 June 2011 (UTC)

Category: Subpages

I'm trying to use this template on my own wiki, and I'm getting "Category: Subpages" on my subpages. I'm not quite sure what I'm doing -- or not doing -- that's causing this? Tamblyne (talk) 00:10, 7 October 2011 (UTC)

That is the default & automatic behavior for this template when it is applied on a sub-page. This was setup primarily for various tracking and/or maintenance purposes here on en.WS. -- George Orwell III (talk) 00:35, 7 October 2011 (UTC)

Thanks! Can you tell me how to override it? I don't see that behavior on any of the pages here that I'm looking at, but I can't figure out how they're preventing it. Tamblyne (talk) 01:04, 7 October 2011 (UTC)

Well before actually altering the template's code on your Wiki, is it possible you have enabled some setting your preferences similar to Show Hidden Categories there but not enabled the setting under your account here? That's probably why you see it there but not here...

Anyway you'd need to hide (or remove) the section prefixed by Subpages in the code to turn off this auto-categorization. The easiest is to take the current code

Subpages -->{{#ifeq:{{BASEPAGENAME}}|{{PAGENAME}}||{{#switch:1
 |{{#ifexist:{{#rel2abs:../}}|1}}
 |{{#ifexist:{{#rel2abs:../../}}|1}}
 |{{#ifexist:{{#rel2abs:../../../}}|1}} = [[Category:{{#if:{{NAMESPACE}}|{{NAMESPACE}} subpages|Subpages}}]]
}}}}<!--

and move the existing hidden-text closing tag ( --> ) after Subpages to the end of the section in question as such...

Subpages     {{#ifeq:{{BASEPAGENAME}}|{{PAGENAME}}||{{#switch:1
 |{{#ifexist:{{#rel2abs:../}}|1}}
 |{{#ifexist:{{#rel2abs:../../}}|1}}
 |{{#ifexist:{{#rel2abs:../../../}}|1}} = [[Category:{{#if:{{NAMESPACE}}|{{NAMESPACE}} subpages|Subpages}}]]
}}}}--><!--

George Orwell III (talk) 01:42, 7 October 2011 (UTC)

I'll look for that setting first. Thank you very much for the help! Tamblyne (talk) 01:52, 7 October 2011 (UTC)

Page protection detection and Template:Locked

I'm about to try, for a second time, to add code to the header to detect page protection and call {{locked}} as appropriate. This seems to be the simplest and most direct way to implement page protection icons in the main namespace without requiring the manual use of the locked template every time. The first time, wasn't limited to the main namespace, so the multiple headers in this templates documentation caused multiple padlock icons. I know that there will also be a problem in the short term with those pages to do have the locked template added manually (they will have two icons); I'll remove those template when and if this works. I can't see any reason for this not to work but I'm afraid that it's not the sort of thing I can test in a sandbox. - AdamBMorgan (talk) 23:56, 4 November 2011 (UTC)