Template talk:Header

Archives: 2008

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)

Adding a way to categorize the author or title

Is there any way to add a category for the title and author. That way a person can just type in "category:Aesop's Fables" and see the list of fables? 69.120.130.231 15:35, 28 January 2009 (UTC)

Propose add "See also"

I would like to add reference for the style to add Anonymous authors, and was thinking to add a section at the bottom that referred onto {{Anon}}. Alternate suggestions welcomed. -- billinghurst (talk) 01:26, 31 March 2009 (UTC)

Suggest add |override_translator =

I would like to see the addition of |override_translator = akin to |override_author = so that the active hyperlink can be excluded in the translator field. Thanks. -- billinghurst (talk) 22:20, 16 April 2009 (UTC)

So would I. I went ahead and used the parameter for Visit of the Hon. Carl Schurz to Boston/Reception by German Citizens/Address by Professor Krauss. The provider of the translation in this case is the same as the author which was specified as override_author = St. Botolph Club. Bob Burkhardt (talk) 12:31, 4 May 2009 (UTC)

I just tried editing twice but the result would not show up. I may need an expert.--Jusjih (talk) 02:26, 24 June 2009 (UTC)

Year

I suggest that a year = section be added to allow for speedy categorization within the header by year. Geoff Plourde (talk) 20:05, 21 June 2009 (UTC)

Which year? Original publication? The edition we host? Year of translation? ... Eclecticology - the offended (talk) 05:41, 24 June 2009 (UTC)

This function has a head start. If you want to specify which year, enhanced function will be better but complex. Pending that, just write in the note for now.--Jusjih (talk) 18:35, 24 June 2009 (UTC)

That wasn't quite my question. If a year appears in the header, how are we supposed to know what it represents. Is it one of the possibilities that I mentioned, or even something else. Eclecticology - the offended (talk) 20:15, 24 June 2009 (UTC)

I would suggest the year of the work for which copyright will apply. So it becomes the [[Category:1921 works]]. If it is getting more complex then that, then that would be the guidance for Keep it Simple. -- billinghurst (talk) 07:50, 25 June 2009 (UTC)

The year doesn't necessarily appear in the header, it is for categorization purposes. Geoff Plourde (talk) 19:29, 26 June 2009 (UTC)

I did not mean adding the year to the header, rather a field that adds the page to Category:X works. Geoff Plourde (talk) 19:35, 26 June 2009 (UTC)

That sounds worse. Publishing details should continue to appear on the page itself, while the utility of such categories is marginal at best. Eclecticology - the offended (talk) 22:10, 26 June 2009 (UTC)

I don't object to the year being added to notes, but the "in the year" method is ugly. Geoff Plourde (talk) 19:34, 27 June 2009 (UTC)

class

Hi. How could I add a new class like "headertemplate" to my own wiki? I wanted to add this template to my wiki but I found out that I need the above css class. --80.71.122.147 11:35, 25 August 2009 (UTC)

Hello 80.71. The CSS classes for this template are defined at MediaWiki:Common.css. Just copy the code below to "MediaWiki:Common.css" on your wiki, and update your browser cache to see the changes.

table.headertemplate {
        width:100%;
        margin-bottom:5px;
        border:1px solid #ADA;
        background:#E4F2E4;
        text-align:center;
        font-size:0.9em;
}
.headertemplate .header_backlink,
.headertemplate .header_forelink {
        width:20%;
        font-size:0.9em;
        line-height:normal;
}
.header_notes {
        width:100%;
        margin-bottom:0.5em;
        background:#FAFAFF;
        border-bottom:1px solid #A88;
        font-size:0.9em;
}
.headertemplate .header_title { width: 60%; }
.headertemplate .header_backlink { text-align:left; }
.headertemplate .header_forelink { text-align:right; }

—Pathoschild 12:02:04, 25 August 2009 (UTC)

thanks --80.71.125.133 11:22, 26 August 2009 (UTC)

Correct the override_translator

Please correct the code with the code from http://en.wikisource.org/w/index.php?title=Template:Sandbox&oldid=1220547 You can see some of my testcases in http://en.wikisource.org/w/index.php?title=Wikisource:Sandbox&oldid=1220550 . It makes the override_translator works. Vinhtantran (talk) 11:22, 10 September 2009 (UTC)

Oops we missed this. Apologies.

An edit has already been undertaken to {{header}} and you can see the results of the your test against this file at http://en.wikisource.org/w/index.php?title=Wikisource:Sandbox&oldid=1529995 billinghurst (talk) 12:16, 7 November 2009 (UTC)

{{Header}} and Scans

I would like to propose that we look to add (yet) another field to {{header}} that provides a direct link to the relevant image file Index: page. Tentatively call field | scan = though I could be convinced to call it a number of things.

I would propose that the field be

• non-mandatory

a) not all works have scans, b) I would envisage to use this more where a work is divided into sub-pages, and the Table of Contents is the more usual on the main page. Noting that normal transclusion processes show page links where transcluded directly

• show as the first component in the Notes display
• have a standard visual text "Link to scans"

or whatever we chose to call it

• that the information by the filename without the INDEX namespace rider

more flexible and akin to how we handle images

• possible pick up the status of the work, similar to the pictogram used (top of page) where pages are transcluded directly

Probably other things that others can add or vary. -- billinghurst (talk) 12:08, 7 November 2009 (UTC)

First thoughts are that this sounds like a great idea! If it were to pick up the status of the work (eg. validated) it would be most useful if it only considered the pages transcluded by the article itself. Suicidalhamster (talk) 19:59, 9 November 2009 (UTC)

Translator aesthetics

Hi. Would it be possible to make some minor changes to the formatting of the optional "translator" parameter?

Currently it appears on the same line after the author with a comma in between. Even the common is unaesthetic, for some reason an unneeded space appears after the author's name and before the comma.

But it would be preferable for the author to have his own line, and for the name of the translator to appear afterwards on the next line. Is this possible? Desirable? Dovi (talk) 19:32, 24 December 2009 (UTC)

The space before the comma seems to be due to the table formatting, and there is presumably a cellspacing or cellpadding within class=headertemplate.

The ideas around the formatting of the author and translator within {{header}} pre-dates me and I would presume it is about not making the table longer than necessary. It is not something with which I wish to play and doesn't upset as it is, that said I am not against the idea of a change being explored. billinghurst (talk) 22:35, 24 December 2009 (UTC)

The space is somewhere in the nested #if: statements. Still looking. billinghurst (talk) 23:00, 24 December 2009 (UTC)

space issue found and Done . It was actually removing two different spaces within #if: statements and placing it in another place. billinghurst (talk) 23:11, 24 December 2009 (UTC)

Interwiki Ru

Please correct Russian interwiki, it should point to ru:Template:Отексте. — Lozman (talk) 23:58, 23 February 2010 (UTC)

Done. You could have done it yourself; the interwikis are on Template:Header/doc, which is not protected. Hesperian 00:09, 24 February 2010 (UTC)

Bah [looking conflict]!, I wondered why it looked right to me. — billinghurst sDrewth 02:26, 24 February 2010 (UTC)

year fix

It needs a space to avoid, "In Flanders Fields (1921)by John McCrae" Cygnis insignis (talk) 23:47, 7 March 2010 (UTC)

Done — billinghurst sDrewth 06:42, 8 March 2010 (UTC)

link in footer

This doesn't appear to be working, they display correctly (red/blue) but are not clickable. cygnis insignis 11:25, 14 August 2010 (UTC)

The link now works in the footer, but when I click through to an adjacent subpage it doesn't; it shows unclickable links again. cygnis insignis 12:14, 17 August 2010 (UTC)

italicise title instead of author

Currently this yields

Early Voyages to Terra Australis by Richard Henry Major

As far as I can tell, the only reason the second line is italicised is to increase the visual distinction between it and the first line. But as there is a fairly strong real-world convention to italicise titles, and not authors, it seems to me that this is a bit backwards. I would like to change it to yield

Early Voyages to Terra Australis by Richard Henry Major

Thoughts? Hesperian 02:50, 30 July 2010 (UTC)

I'd agree with your reasoning about it having being done for the visual difference. That said, if we were going to look at a change, I think that it would be worthwhile taking the extra step back and to review headers from first principles and how we represent titles of works, versus titles of collections, and how we utilise individual works with collections. For instance: Index:Mandragora.djvu; Index:Essays in librarianship and bibliography.djvu and Index:Lectures on Modern History.djvu all by the same authors, then compare it to journals and the like, eg. Popular Science Monthly which are collections by different authors. The issues that I see are

• physical presentation (as you identified)
• author association with the individual work, or the collection (especially in shared works)
• is the title the collection or the individual work? Especially if the parts of the collection have been elsewhere
• there is also criteria built into Index: framework to identify the type of the work and to present it. ThomasV has part of the framework in place, though not implemented (which I believe he has done at frWS)

— billinghurst sDrewth 03:47, 30 July 2010 (UTC)

I think it possible to have italic for the title by using the section field, this PSM example gives the hierarchy of the 'sections'. Note also the previous and next fields at this example link the previous volume and the next article.

I think confusion is generated by the tendency to use the field title to show a meta-title, what is actually the name of a section of the actual source. The section field could show section links, volume, issue and the PSM title taken from page "The Industrial Type of Society". If the text had come from a Political Institutions, being Part V of the Principles of Sociology (The Concluding Portion of Vol. II) (London: Williams and Norgate, 1882) it displays any subpage structure in the section field, down to and including "CHAPTER XVIII.: the militant[!] type of society" if one followed this as a source. 'Militant' and Industrial' are part of a full citation, the half title for these sources is Principles of Sociology and Popular Science Monthly and that would be linked in italic (and bold) from title=.

• Title can autoformat if it only names the top level label, if we push the rest to section; this is flexible enough to accommodate 'collections' of same or different authors.

The type of source should be considered irrelevant, I think this consideration stems from the earlier practice of fragmenting works to pages with titles of sections and divorcing it from its actual source. The top level of a subpage structure give the details of the whole work, the section header includes info like its author and access to any subpage structure. Cygnis insignis (talk) 14:14, 30 July 2010 (UTC)

I was probably indirect in the mentioning of the ambiguity with the author of the work vs part of the work. For the DNB we use a modified header {{DNB00}} which puts the author details in a different location, and one that is slightly more obvious. — billinghurst sDrewth 14:32, 30 July 2010 (UTC)

The DNB is not subpaged, a side issue that pushes a user to a dab of a meta-title Blake, William, but where would the scheme fail for that example. It is considered to be a 'reference work', but that should not affect the header or subpage arrangement either. The fragmentation of that work is another issue that impacts on the rest of our catalogue.

Why is putting the author on its own line 'more obvious'? In the PSM example I modified the title of the section "The Industrial Type of Society" is followed with "... by Herbert Spencer". The DNB template style creates a new line for the author, it is 'less obvious' what Anne Gilchrist is the author of, though the title page and the text itself show the various authors - the article is by "A. G-t.", perhaps with changes by "the editors". Cygnis insignis (talk) 15:28, 30 July 2010 (UTC)

Add "see also" and "shortcut", and document code

I would like to be able to have an {{author}}-style way of linking to the relevant Wikipedia or Commons page from a work. Many of our works have Wikipedia article, and many have Commons categories or pages (if fact any with scans should have). I have made the modifications [here], and you can see the result [here]. I also commented all of the code so that you can now actually see what is happening :-O. If people could try to break this template to look for bugs, I would be grateful. Inductiveload—talk/contribs 03:52, 12 August 2010 (UTC)

This was a discussion that has taken place earlier in places (was in Scriptorium at one time and focused on aligning the format of {{wikipedia}}, {{commonscat}}, etc.), and from that evolved the less obtrusive {{plain sister}} and another (forgotten name) which can be used within the notes field, rather than looking to further complicate the header template. — billinghurst sDrewth 04:44, 12 August 2010 (UTC)

This was the aim of {{plain sister}} and its kin {{interwikidiscreet}}, to imitate and eventually merge the 'author-page style' sister links into the header. Including this in the author template is not problematic, other than the inclusion of non-existent links, why would it be here? Those templates are very close to this suggestion, producing very similar output in the notes field. It is frequently needed on a parent (title) page, perhaps on subpages as well, and because it is like the author template, it accords with a widely deployed navigational arrangement. I support inclusion and merging every other interwiki template into this. Cygnis insignis (talk) 05:11, 12 August 2010 (UTC)

Oh, I have never noticed those templates before. But I have seen a lot of people using the big and bulky {{wikipedia}} templates in the "notes" field. If we would incorporate {{plain sister}} into the header template, we should also incorporate it into the author template (replacing the links we have now) and the portal header template. This would outsource the parameter parsing to {{plain sister}}, meaning less code in header, author and portal template.

• I have added {{plain sister}} to {{portal header}} as an demonstration of what I envision for header and author. Inductiveload—talk/contribs 07:09, 12 August 2010 (UTC)

I like the way it was merged into the portal template. I'd love to see it merged as well into the header template, since I think both alternatives (plain sister and the clunky {{wikipedia}} templates) are too cumbersome.—Zhaladshar ^(Talk) 13:41, 12 August 2010 (UTC)

While I am ambivalent(ish) about merge or not as I don't find it a burden to add, and it gives me a little flexibility on positioning, and possibility of alternates. On a thought along a similar line, we should be looking to extract common css codes and the colours of each these different header templates into common.css and simplifying the editing, and the call of the like colours as needed. — billinghurst sDrewth 14:18, 12 August 2010 (UTC)

• {{plain sister}} also merged into my sandbox's version. See here, and result here. Remember that the box disappears if you don't use it, so if you really need alternative placement, you can do it as you do now. However, a unified approach would be better wherever possible, in my opinion. Inductiveload—talk/contribs 14:57, 12 August 2010 (UTC)

• The unified CSS code is now in place, and applies to all header templates ({{header}}, {{author}}, {{process header}}, {{portal header}}). See Mediawiki_talk:Common.css for a list of the new classes. Inductiveload—talk/contribs 04:35, 13 August 2010 (UTC)

Just to clarify what I'm hoping is going to happen: When I create an Author page the template has fields to wikipedia, commons and quote. I find this very convenient for checking and creating content elsewhere, and as a reader I know exactly where to click on the page as I browse around.

• These first two should appear, and be left, as parameters in the header template whena page is created.
• Perhaps the commons link should default to commonscat.
• The set of links should be extendable, to include other sisters. Maybe this is neater in a separate template?
• The output might need better labels and/or icons, or a left aligned sentence, but they will become as familiar to users as I think they are on the author pages.

Apologies if this has already been addressed above. I used the model someone created for 'plain sister' to tout the desired outcome, I hope it becomes redundant and is eventually deleted. cygnis insignis 12:44, 17 August 2010 (UTC)

That is the plan. Except that I am planning to use {{plain sister}} directly, so that the parameter parsing is outsourced away from the header template. See {{Portal header}} for what I plan to do. I prefer {{plain sister}} to {{interwikidiscreet}} because it has more uses, so it will be easier to delete {{interwikidiscreet}}. Also "interwiki" may mean inter-language, but "sister" means the other projects. Inductiveload—talk/contribs 14:54, 17 August 2010 (UTC)

OK, if there are no objections, I am going to change to the version here. Changes are:

• Improved code readability (comments and spacing)
• Add fields for sister wikis, using {{plain sister}}
• Add field for {{shortcut}} (for works like EB1911, Colliers, etc). This adds a tracking category to make it easy to check for abuse.

Any objections, thoughts or comments? Inductiveload—talk/contribs 13:44, 18 August 2010 (UTC)

Sounds okay to me. We should make specific note on {{plain sister}} that it is embedded into these templates, or maybe better some generic text and create a link to which templates transclude it, and ensure that there is a suitable level of protection for that template. Should we also add some clear documentation to this template that explicitly states which templates are transcluded? — billinghurst sDrewth 07:58, 19 August 2010 (UTC)

Probably a good idea. I'll have to update the documentation anyway. Plain sister could also use a makeover. Inductiveload—talk/contribs 13:35, 19 August 2010 (UTC)

The template has been updated. Docs for this and {{plain sister}} have been changed. Inductiveload—talk/contribs 13:54, 23 August 2010 (UTC)

modification

I needed a wrapper for my scripts, so I added a new div with the "headertemplate" id. The "headertemplate" id was already used for the table, and I boldly removed it, because it is apparently not used by any script. (only the class is used) If I was wrong and you need to revert me, please let me know, so that I’ll use another id. ThomasV (talk) 17:01, 27 August 2010 (UTC)

Don't know if it matters -- the only way to keep {{Potus-eo}} from producing an error bang was to add id="headertemplate" to it. George Orwell III (talk) 17:06, 27 August 2010 (UTC)

Suggested to modify to add subsection author

It has been suggested that the template Header should be modified to allow the addition of a parameter to show the contributor of a part of a work where the contributor of the relevant piece of text is not the author of the entire work. Examples of such cases are journal articles (eg. PSM), biographical dictionaries (eg. DNB) and works where an editor has undertaken an introduction to works of another author. To do this we would need to decide upon—

1. a parameter name, my personal preference would be contributor, though others may have alternate preferences, or we may be able to align two names to the parameter;
2. the display location of the field, and it has been suggested that it be after the section name, possibly on a new line
3. it would automatically wikilink to the Author pages (unless people can think of reasons not to); and there would be a need for an override function (no link required, or to allow for multiple authors)

The parameter would be optional. — billinghurst sDrewth 11:52, 1 November 2010 (UTC)

Try this out for size: User:Inductiveload/Sandbox. You can see example usage at User:inductiveload/Sandbox2. It adds an "editor" field, and a "sec_author" field. I've made it so it uses the same "dirty-link" capturing as the author and translator fields, and it supports overrides for both. All new parameters are optional, no change is made if they are not used. Inductiveload—talk/contribs 18:48, 7 December 2010 (UTC)

I think that a relevant test is something like a DNB article or a PSM article where we can look at set-out clarity and the header width versus depth, and to see whether it adds value to clarify sub-authors, or works where we have overarching editors and different authors. Also would like to see it where we have an introduction by a separate contributor than the author.

One of the other considerations is how well will it work with the preload tools especially where they pre-populate fields from other pages in a work. — billinghurst sDrewth 23:55, 7 December 2010 (UTC)

Take another look at User:inductiveload/Sandbox2. I've added a DNB-style entry, and some of the preceding entires are the kind you'd expect for a separate author of a preface or introduction. Inductiveload—talk/contribs 05:35, 8 December 2010 (UTC)

I get translator name split for With author, editor and section author and With author and overridden editor, [17" monitor] so I am not sure that the long lines work or give clarity, though they do give a shallower header bar. I would also like to see how it would look with the sec_author being a new line under the section name, that is the presentation style for DNB00 and PSM. — billinghurst sDrewth 10:53, 9 December 2010 (UTC)

The split line is caused by the central "title" cell (as opposed to "forelink" and "backlink" cells) of the header box not being long enough to take the full line. I've adjusted the template so that if there is no forelink and no backlink, the title cell takes up the whole width, to avoid a short, split line if there is lateral space. However, if a fore or backlink exist, the table space is constrained by the classes .gen_header_backlink and .gen_header_forelink which both have width: 20%;.

I've added a line break before the section author too.

If you want to change the parameter name from "sec_author" to something else, that's fine. However, I don't think "contributor" is ideal for situations where the editor just gathered up works and put them together, as it kind of implies that the author wrote the article for this use. This is just semantics, and I'm not very attached to "sec_author" other than the fact that it is the same length as "translator", so it will prevent a ragged line of equals signs in the template.Inductiveload—talk/contribs 12:42, 9 December 2010 (UTC)

This one With author, editor and section author needs fixing as we get a wrap on William/wrap/Wordsworth followed by single word lines. — billinghurst sDrewth 04:16, 18 December 2010 (UTC)

┌───────────────────────┘

Here is an example of a section author, and section translators, and an alteration The University Hymn Book/God reveals his presence. When we are keeping works as sub-parts of the compilation, works like this continue to highlight that we need to either amend header or to give fuller guidance on how to manage. My opinion on this rendition is that I would think that how we could make it happen is have section author as proposed, then we utilise the Notes display field in either a structured or instructive means. My preference is for optional structured parameters.

Structured could be to have a leading controlled area within the (managed by an #if: statement) that enables us to put in supplementary subsection information, section_translator, section_illustrator and they are free text and can be wikilinked as required.

Right, let's get this discussion going again! I think free-text for all new parameters a good idea, as otherwise we end up with even more ways to do it wrong, and the template's dirty-link handling code is getting out of hand already. To be honest, I think that the author field should be free text, (we have 26,300+ works in Category:Pages with override author), but that is a discussion for another time. I propose adding the following, optional, fields: "editor", "illustrator", "translator". All fields (including "author" too) will have an optional section variant for when the subpage's data differs from the main work. Inductiveload—talk/contribs 19:06, 1 August 2011 (UTC)

Wrapping "plain sister" components?

Is it worth wrapping the components of {{plain sister}} that are embedded in the header into #if statements so that they don't call the template unless necessary? — billinghurst sDrewth 14:32, 21 December 2010 (UTC)

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)

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)

Alice's Adventures in Wonderland by Lewis Carroll

{{[[Template:User:Theornamentalist/Sandbox3

User:Theornamentalist/Sandbox3 ]]}}

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)