Template talk:Navbar

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Tnavbar)
Jump to: navigation, search

6.900.000[edit]

Wow, the counter says: seven million pages! That's about two en.WPs. -DePiep (talk) 23:50, 26 January 2012 (UTC)

It's 7 million transclusions, not pages. Edokter (talk) — 11:40, 27 January 2012 (UTC)
Plus, we have 40,061,511 pages in total, of which only 5,226,504 are articles. Edokter (talk) — 11:42, 27 January 2012 (UTC)
Right, could/should have thought of that myself. -DePiep (talk) 12:54, 27 January 2012 (UTC)
Actually it is pages. See Wikipedia talk:Database reports/Templates transcluded on the most pages. Rich Farmbrough, 20:12, 11 March 2012 (UTC).

v - d - e / V - T- E[edit]

I have been made aware of this recent change to V - T - E though I notice that on some pages all navboxes have the old v - d - e setup (and this doesn't seem to be a navbox-by-navbox issue, because when I was viewing a particular navbox on its own it read V - T - E, and then when I went to one of the pages it linked to, it read v - d - e at the bottom of that page). What could be the reason for this?
RedSoxFan274 (leave a message~contribs) 05:42, 25 February 2012 (UTC)

Caching. You can force a refresh of the navbox by purging the article. Edokter (talk) — 10:08, 25 February 2012 (UTC)
So, capitals for the "view", "talk" and "edit" links, but "hide" is still lowercase? Looks great... - Dudesleeper talk 17:08, 25 February 2012 (UTC)
Template:Navbar does not create "hide" links. --Redrose64 (talk) 19:37, 25 February 2012 (UTC)
I'm not fond of it either, but it has been decided. Edokter (talk) — 19:46, 25 February 2012 (UTC)
It's the wrong decision. Beyond My Ken (talk) 06:03, 27 February 2012 (UTC)
Manifestly. Caps makes them too important, and is clunky. I suppose because the vector skin uses title case, but consensus here and talk:navbox is for lower case. Rich Farmbrough, 20:09, 11 March 2012 (UTC).

On mobile devices[edit]

On my iPhone at least, when viewing a template with "v t e" links, it displays as a vertical three-member list, i.e.:

  • v
  • t
  • e

Guessing this is a bug, would be better if they were each on the same line. LukeSurl t c 16:47, 27 February 2012 (UTC)

  • Same problem happens on Android. --CapitalR (talk) 17:05, 27 February 2012 (UTC)
    • the problem appears to be that the "hlist" class is not in the style sheets loaded on the mobile site. to see the issue check this page for example, which shows a template loaded from the mobile site. Frietjes (talk) 17:28, 27 February 2012 (UTC)
Is it necessary to have all these links on mobile devices? I thought that you couldn't edit from a mobile, so if that's true, the "e" link, at least, is redundant. --Redrose64 (talk) 17:57, 27 February 2012 (UTC)
I agree -- I don't think they're necessary on the mobile edition. --CapitalR (talk) 18:17, 27 February 2012 (UTC)
It appears as though the MobileFrontend extension uses a hardcoded css file? There is a bug at Bugzilla: 34325 that seems relevant. -- WOSlinker (talk) 18:40, 27 February 2012 (UTC)
There's more bugs in MobileFrontend as well. If CSS class="noprint" is specified against a html tag then the item is not shown on the mobile site but if other classes as well as noprint are specified, for example class="noprint plainlinks", then it is shown on the mobile site. -- WOSlinker (talk) 19:05, 27 February 2012 (UTC)

Use outside of navigation[edit]

I love to use this template outside of a navigation template. Wikitables and infoboxes! example 1, infobox 2. Can I get a baptising (Edokter?) that this usage in, say class="wikitable", is supported and Template:Navbar/doc confirming? -DePiep (talk) 22:56, 9 March 2012 (UTC)

Navbar is pretty self contained and can be used in any block elements such as table headers or divs. Feel free to add any compatible use in the documentation. Edokter (talk) — 11:57, 24 March 2012 (UTC)

V • T • E •[edit]

Why does edit have dot after it in the header? There's nothing after it, so the dot is pointless. Kaldari (talk) 04:16, 24 March 2012 (UTC)

This seems to be caused by the same thing that's breaking the mobile display above. Why are we doing a weird unordered list CSS hack rather than just separating the letters with bullet characters? Kaldari (talk) 04:33, 24 March 2012 (UTC)
Would anyone object if I changed it back to normal bullet separators? Kaldari (talk) 04:38, 24 March 2012 (UTC)
Yes. We're trying to move away from bullet seperators all across the board because they present accessability issues on non-visual displays like screen readers. Since the v-t-e links are essentially a list of links, they should remain as a list construct. Edokter (talk) — 11:54, 24 March 2012 (UTC)
You do realize over 7% of our traffic comes from Mobile Safari? Less than 0.1% of our readers are using screen readers. Breaking the template for 7% of people in order to improve it for less than 0.1% doesn't make sense. Kaldari (talk) 20:42, 24 March 2012 (UTC)
It really should be hidden for mobile viewing. The current mobile system tries to hide stuff that has class="noprint" but there's a bug that means that it doesn't hide it if the class is also combined with other classes in the same tag, so as a workaround, could add that as a separate extra div as I've done in the sandbox. Is it worth adding an extra div? -- WOSlinker (talk) 20:50, 24 March 2012 (UTC)
That sounds like a good workaround in the meantime. I would support it. Kaldari (talk) 20:58, 24 March 2012 (UTC)

Getting rid of the V T E links[edit]

Since the V T E links are such a problem, I propose that we get rid of them entirely. They serve no purpose to the reader other than to be mysterious letters in the corner of the box. We don't include edit links in other templates like infoboxes, so why do we have them in navboxes? They're just visual clutter for the reader. Kaldari (talk) 20:53, 24 March 2012 (UTC)

I further propose that when we remove the V T E links, we create a simple gadget that adds the links back for people who want them. This is how it should have been implemented in the first place. Kaldari (talk) 20:57, 24 March 2012 (UTC)
Probably better to propose this at Wikipedia:Village pump (proposals) rather than here though as it's a big change which needs more coverage than it can get by being discussed here. -- WOSlinker (talk) 21:00, 24 March 2012 (UTC)
Good point. I'll bring it up on the Village Pump instead. Consider this thread closed. Kaldari (talk) 21:01, 24 March 2012 (UTC)
I've started a discussion at the Village Pump. Kaldari (talk) 21:22, 24 March 2012 (UTC)
The discussion seems to be archived here: Only show the V • T • E links in navboxes to editors 50.53.15.51 (talk) 17:17, 8 May 2012 (UTC)

Allow changing the mouseover text[edit]

Currently, the mouseover text for the links always reads "[View/Discuss/Edit] this template", regardless of whether "template" is really appropriate for the content in question. Could we add a new parameter (the best name I can come up with is "type" but maybe someone else has a better suggestion) to allow changing "template" to a more appropriate term for these usages? ディノ千?!? · ☎ Dinoguy1000 01:58, 31 July 2012 (UTC)

Edit request on 5 September 2012[edit]


14.195.153.42 (talk) 13:28, 5 September 2012 (UTC)

Not done: please be more specific about what needs to be changed. --Redrose64 (talk) 14:07, 5 September 2012 (UTC)

Code to specify the edit target[edit]

I need to add the following code in the edit portion:

--><li class="nv-edit">[{{fullurl:{{{edit|{{transclude|{{{1}}}}}}}}|action=edit}} <span title="Edit this template" <!--

This is done to separate the template from transcluded text. See Wikipedia:WikiProject Puerto Rico/Requested articles for an example. The template is hosted at Wikipedia:WikiProject Puerto Rico/Requested articles which is used by Template:WikiProject Puerto Rico but we don't want to allow users to edit the template (because in addition to the list of articles, the page also includes the code for the navbar and for the warning info). We want them to edit the list of articles and the lists of articles alone. We don't want them to see or have access to the navbar code, the warning code, or any other text that is not the list of articles. When users click 'view' or 'talk' it takes them to the proper talk page, but the edit button takes them to the transcluded text.

Adding that code allows for such feature.

The code has already been tested at Template:Navbar with targeted edit. —Ahnoneemoos (talk) 06:03, 21 November 2012 (UTC)

Not done for now: The proposed edit would create a rather confusing situation where the VTE links point to different templates. I would suggest you solve your little problem, just by using {{navbar|Wikipedia:WikiProject Puerto Rico/lists/requested articles}}. In any case, this template is highly visible so any changes should be discussed first; so I have deactivated the request for now. — Martin (MSGJ · talk) 06:35, 21 November 2012 (UTC)
No problem, you can still use the feature by using Template:Navbar with targeted edit which is not as visible as this template. —Ahnoneemoos (talk) 06:41, 21 November 2012 (UTC)
It is not generally a good idea to keep separate copies of templates with obscure features. We should probably either add your proposed edit here or not at all. Saying the equivalent of "Well I'm going to keep my own copy of this template anyway" when I suggest you discuss this change does not seem to be in line with the collaborative spirit of the project. — Martin (MSGJ · talk) 06:50, 21 November 2012 (UTC)
That's, like, your opinion, man. The template is not obscure, it's necessary. Keeping it actually goes in line with Wikipedia's goal since Wikipedia is not a paper encyclopedia and, therefore, there's no limit on the number of templates that can be created, based on other templates or not. Rather than reverting and redirecting my edits I suggest you let them be for the time being since they are not being used as much as this template is. While I appreciate your suggestion, I prefer not to deal in absolute choices that follow the law of excluded middle. You see, there is another option: keeping a separate template, which is what I suggest. —Ahnoneemoos (talk) 07:09, 21 November 2012 (UTC)

Proposal to add an "H"[edit]

I am proposing that an "H" for History is added to the navbar. Pressing the link would lead to the template's history. JC · Xbox · Talk · Contributions 06:51, 26 November 2012 (UTC)

Support with caveats. Great idea but the argument should be optional. —Ahnoneemoos (talk) 17:41, 26 November 2012 (UTC)
Unsure. I like the spirit of the suggestion, but wonder if implementing it would be stepping too close to (or into) "navbar bloat"..? CsDix (talk) 21:50, 5 December 2012 (UTC)

Missing space after the "V" when template in "mini" mode?[edit]

Hello. Is it just me / my browser/s / something else, or am I seeing no space between the "V" and subsequent dot in the "mini" version of this template? If so, I guess an &nbsp; placed judiciously in the template's code would fix this wrinkle, but that feels like a fudge. If there is something amiss, would it be found in the code for the "nv-view" class (wherever that might be)..? CsDix (talk) 21:48, 5 December 2012 (UTC)

there has been some recent activity in MediaWiki:Common.css, which may have caused the problem. Frietjes (talk) 21:54, 5 December 2012 (UTC)

Lua[edit]

Can we use Module:Navbar for this template now? --DixonD (talk) 07:42, 4 April 2013 (UTC)

Link to pagename[edit]

There might be a glaringly obvious answer to this, but why do we have to input the name of the template in {{navbox}} to generate the VTE links? Why can't this be automatically generated from PAGENAME? I can't imagine a circumstance where this couldn't be done and we could save thousands of redundant lines of template code this way. SFB 11:32, 13 July 2013 (UTC)

PAGENAME would point to the article when transcluded, not to the template. Edokter (talk) — 12:20, 13 July 2013 (UTC)
That said, if you are creating or editing a navbox, you can enter
|name={{subst:PAGENAME}}
and that will work until the navbox gets moved to a different name, at which point a further edit is required, as here. --Redrose64 (talk) 13:07, 13 July 2013 (UTC)
seems like this could be solved with lua. in shell scripting we have ${0}. Frietjes (talk) 16:45, 13 July 2013 (UTC)

If redirect[edit]

a very useful thing to have would be a '#ifredirect', so we could tell if the name being passed is a redirect, and correct it. Frietjes (talk) 16:45, 13 July 2013 (UTC)
just found Module:Redirect. we should use this to detect (or correct) the problem when a redirect is used for the edit link. Frietjes (talk) 16:50, 13 July 2013 (UTC)
I'm not clear on how that could help - Module:Redirect takes a link as a parameter (e.g. WP:AFC) and expands the proper target (Wikipedia:Articles for creation). If you give it a link to the article page you're viewing, in which the navbox is embedded, it's helpless. That said, there might be some other Lua method that can be used... the problem is, it's pretty hard. Templates get transcluded in, then interpreted. The same is true of Lua scripts or they wouldn't work when called by templates. I can think of an "outrageous hack" method - a Lua script that reads in the originating page source code and modifies it - but that is absolutely not going to fly for something like this. Wnt (talk) 17:46, 13 July 2013 (UTC)
seems to work, see below
or if we just want to check if something is a redirect
  • Template:Navigation box is a redirect
  • Template:Navbox is not a redirect
I am missing something? Frietjes (talk) 19:12, 13 July 2013 (UTC)
You still have to put the template name in, so what's the benefit? Edokter (talk) — 19:53, 13 July 2013 (UTC)
Seems like the benefit would be to use this to track cases where a redirect is passed as the template name. These are a problem since the edit links will take you to the redirect page and not to the template. Seems like a significant benefit if we can find and fix these. Can you create a lightweight module that just detects if a link is a redirect? The LUA documentation seems to indicate this is possible with a single function (see the title objects section where they mention isRedirect)? Thanks! Plastikspork ―Œ(talk) 01:28, 14 July 2013 (UTC)
I just found Module:Page, which includes isRedirect. We could use something like
{{#if:{{#invoke:Page|isRedirect|page={{transclude|{{{1}}}}}}}
|[[Category:Navbar using a redirected edit link]]
}}
to find the problem cases that Frietjes mentioned. Plastikspork ―Œ(talk) 01:41, 14 July 2013 (UTC)
thanks for pointing me to Module:Page, that is a much cheaper solution. Frietjes (talk) 14:29, 14 July 2013 (UTC)
a common problem. it would be great if we could detect this problem here. Frietjes (talk) 15:24, 24 August 2013 (UTC)

url shown in print version[edit]

It uses

{{navbar-collapsible | [[Periodic table]] | Template:Periodic table}}

When in "Printable version" (from article or userspace, today), the url for the "E" option is visible in the titlebar, bracketed:

V-T-E (//en.wikipedia.org/w/index.php?title=Periodic_table&action=edit)

It is actually printed too. Preventable? -DePiep (talk) 13:55, 3 December 2013 (UTC)

Seems like class="noprint" does absolutely nothing. I'll put navbar in MediaWiki:Print.css. Edokter (talk) — 17:00, 3 December 2013 (UTC)

Protected edit request on 6 May 2014[edit]

Please make these changes. This avoids polluting _G and clobbering the builtin error(). Jackmcbarn (talk) 20:31, 6 May 2014 (UTC)

Done! Plastikspork ―Œ(talk) 03:40, 7 May 2014 (UTC)

Protected edit request on 23 May 2014[edit]

Please make these changes. This allows autodetection of the template name in some circumstances, calls Module:Arguments instead of using a crude reimplementation of it, and exports the _navbar function, to allow other modules to avoid an unnecessary argument parse when calling this module. Jackmcbarn (talk) 17:03, 23 May 2014 (UTC)

I've made code cleanup in these four edits. Latest version now. See editsummaries: rm trailing whitespace, rm space from tab('span '); rm spaces from xyz( argX ) into xyz(argX); replace 4-space indent with \t (tab). I did not touch ";" end of statements, though it looks being done inconsistently. -DePiep (talk) 17:43, 23 May 2014 (UTC)
@Jackmcbarn: -DePiep (talk) 17:48, 23 May 2014 (UTC)
@DePiep: LGTM. Jackmcbarn (talk) 17:51, 23 May 2014 (UTC)
Padlock-pink-open.svg Not done: The page's protection level and/or your user rights have changed since this request was placed. You should now be able to edit the page yourself. If you still seem to be unable to, please reopen the request with further details. — {{U|Technical 13}} (tec) 21:00, 23 May 2014 (UTC)

Lua 2[edit]

Can we use Module:Navbar for this template now? --78.84.136.244 (talk) 11:46, 6 July 2014 (UTC)

Any particular reason why? -- [[User:Edokter]] {{talk}} 16:48, 6 July 2014 (UTC)
There's some work that I want to get done with some of its callers first, then we can. Jackmcbarn (talk) 17:39, 6 July 2014 (UTC)
@Edokter: It's better to keep the code all in one place. Otherwise there's the danger that the module and the template will grow far apart enough that we will be effectively be maintaining two different templates. — Mr. Stradivarius ♪ talk ♪ 05:05, 8 July 2014 (UTC)

Noprint effects[edit]

The {navbar} does not show in print, of course. By what mechanism is that achieved?

I have this situation:

<span class="noprint">{{navbar|SomePage}} [[Help:Using colours|Some more nonprintable help]]</span>

When nested this way, the explicit link (the Help) does show up in print. Somehow the {navbar} nullifies the outer span class.

Of course I'll solve it by putting the {navbar} outside the span tags, but I find it interesting. -DePiep (talk) 11:31, 12 July 2014 (UTC)

Number 1 rule of HTMLTidy: Thou shalt not embed a block element inside an inline element. If you do, Tidy will just kick everything out of the inline element, and anything contained within will no longer be subject to any CSS or classes associated with that inline element. -- [[User:Edokter]] {{talk}} 11:42, 12 July 2014 (UTC)
Aha. btw, it happened in an {infobox}, and I found |belowclass=noprint cleans my |below={navbar} + whatever stuff best. -DePiep (talk) 17:11, 12 July 2014 (UTC)

Spurious line break with bracket+mini+float[edit]

Both these put the last bracket on its own line,

{{navbar|Template Name|brackets=1|mini=1|style=float:left}}

and

{{navbar|Template Name|brackets=1|mini=1|style=float:right}}

e.g.

Noticed on Template:BS-map which is used on many railway related pages.--JohnBlackburnewordsdeeds 23:41, 28 July 2014 (UTC)

@JohnBlackburne: I've never noticed this, and I visit a lot of pages with RDTs. I can't reproduce it either: please give examples of pages where it happens. --Redrose64 (talk) 07:35, 29 July 2014 (UTC)
It's visible in the two templates on this page, South Yorkshire Railway, which is where I first noticed it. The templates are Template:SYR Barnsley to Doncaster and Template:SYR Blackburn Valley Line. The problem's visible in Template:BS-map which is where the options for the template are set. I then checked a couple more members of Category:Templates for railway lines of the United Kingdom and they also had the problem.--JohnBlackburnewordsdeeds 12:57, 29 July 2014 (UTC)
Looks fine to me, in both MonoBook and Vector skins, in Firefox. Which skin and browser are you using? --Redrose64 (talk) 13:03, 29 July 2014 (UTC)
Like Redrose, I cannot reproduce this in any browser (Chrome, Firefox, Opera and IE). Try clearing your cache, that will probably fix it. -- [[User:Edokter]] {{talk}} 13:05, 29 July 2014 (UTC)

I'm using Safari on Mac OS X, the latest versions of both. I've tried clearing the cache, and also viewing with a different skin (?useskin=modern or ?useskin=monobook). Firefox looks OK; it's also different in another way, the letters V, T and E are slightly but noticeably smaller in Safari. Looking at the examples at Template:Navbar/doc in Safari not Firefox the V T E look like small caps, smaller that the other capital letters.--JohnBlackburnewordsdeeds 14:33, 29 July 2014 (UTC)

No problem for me in Safari under Windows XP in Vector; but in MonoBook, the letters "v-t-e" are very tiny. Yes, these are styled as small caps: it's because of the CSS rule
.navbar.mini li span { font-variant: small-caps; }
--Redrose64 (talk) 15:16, 29 July 2014 (UTC)
It's also using this
.navbar {display: inline; font-size: 88%; font-weight: normal}
, inherited from the <div class="plainlinks hlist navbar mini"> that contains the whole thing. Don't know if it's related but it's the only other visual difference between Safari and Firefox and there shouldn't be any.--JohnBlackburnewordsdeeds 15:43, 29 July 2014 (UTC)

mini v-t-e links: abbr instead of span for accessibility[edit]

The v-t-e links currently use <span title="..."> to expand the abbreviations as tooltips, but this is inaccessible to various assistive technologies. (See title attribute accessibility problems discussed in this blog post, and this blog post.) Screen readers, in particular, ignore the title attributes and read them as nonsense letters: "Link, vee, link, tee, link, ee."

Replacing the tags with <abbr title="..."> will tell screen readers that these letters are abbreviations, and that their title attributes have a special meaning, their expansions. (See the HTML5 spec for abbr.) Screen readers with abbreviation expansion, such as JAWS, will offer much better output: "Link, view this template, link, discuss this template, link, edit this template."

Possible implementation: at lines 61, 71, and 83, replace :tag('span') with :tag(args.mini and 'abbr' or 'span')

This change should be made concurrent with a change to MediaWiki:Common.css, though. At line 323, there is a .navbar.mini li span rule to make v-t-e small-caps, so that selector should be changed from span to abbr. It might also be appropriate to add cursor: inherit; to the same rule, to reset the cursor: help; style set by MediaWiki's shared.css. Matt Fitzpatrick (talk) 09:20, 11 October 2015 (UTC)

There is merit, but needs testing in the sandbox (aside: only use edit protected for code that is ready, not to invite comments). Also, the dotted underline would need to be reset. -- [[User:Edokter]] {{talk}} 13:08, 11 October 2015 (UTC)

I tested offline on a test wiki, but you're right, better safe than sorry! Here are some live test pages and sandboxes to make sure there aren't any problems.

Also, yeah, a border-bottom:0 none; reset will help. Matt Fitzpatrick (talk) 01:18, 12 October 2015 (UTC)


OK, reopening request, since sandbox testing gave the same results as my offline tests, and nobody's mentioned any problems.

In Module:Navbar, at lines 61, 71, and 83, please replace :tag('span') with :tag(args.mini and 'abbr' or 'span').

In MediaWiki:Common.css, at line 323, please replace

.navbar.mini li span {
  font-variant: small-caps;
}

with

.navbar.mini li abbr[title] {
  font-variant: small-caps;
  border-bottom: none;
  text-decoration: none;
  cursor: inherit;
}

Matt Fitzpatrick (talk) 14:07, 18 October 2015 (UTC)

I've left a note at MediaWiki talk:Common.css letting the editors there know about this request. Also, I'm guessing that Edokter will want to take a look at this before we carry it out. — Mr. Stradivarius ♪ talk ♪ 14:27, 18 October 2015 (UTC)
I'll have a look. I simplified the CSS, as the selector doesn't need to be that specific (navbox is hidden in print anyway). -- [[User:Edokter]] {{talk}} 16:24, 18 October 2015 (UTC)
Looks good. I plugged Edokter's CSS into my offline test wiki and it works great. Matt Fitzpatrick (talk) 22:19, 18 October 2015 (UTC)
Yes check.svg Implemented — Martin (MSGJ · talk) 12:19, 20 October 2015 (UTC)

Wider support for V • T • E links[edit]

This template supports V • T • E links and several variations thereof, and strong consensus in favor of the V • T • E links feature has been confirmed. I propose that the functionality be copied/moved so that it's more available. I propose this functionality be supported by (but not the default on) all the Message box meta-templates. Ditto for the equivalents on commons - e.g. when visiting File:Nsa-ant-genesis.jpg, the PD-USGov template's talk page should be a link away, not hard to find.( Relevant: {{imbox}} Wikipedia:Manual_of_Style/Article_message_boxes--Elvey(tc) 08:06, 23 January 2016 (UTC)

I strongly oppose. There is reasonable consensus for having them on templates which contain actual content. I strongly disagree with it being beneficial to add them to templates which do not contain content. Message boxes are not, in general, something which people should be actively encouraged to edit on a regular basis, they should mostly remain constant after the wording is properly established. In the case of Commons copyright tags, do we really want people who have possibly a limited understanding of how templates work to start asking questions about copyright on the tag's talk page, etc. I see it as adding unnecessary chaos and confusion, with essentially no worthwhile benefit. Templates containing content absolutely do need to be open and accessible to the majority of users, so that all of the content is accessible for editing. Templates containing no content are mostly things best left to more experienced editors, who can already find the template very easily if and when they need to. By default, MediaWiki has all templates used on a page just 2 clicks away to either view or edit, and 3 for talk, they are not really hard to find. In this case, "keep it simple" means not providing unnecessary edit links on things which don't really need them. If there are content templates which don't have them, I do support their addition to that limited case, where it is reasonable to do so. Murph9000 (talk) 08:43, 23 January 2016 (UTC)
I agree that we don't want 'em on all the Message box meta-templates, and we don't want 'em to be the default for all the Message box meta-templates. (OP clarified.) But I do think we do want the option to add 'em with a navbar=on parameter. Often the tag's talk page has add'l info.
User:Murph9000:How do you get from File:Nsa-ant-genesis.jpg to COMMONS:Template_talk:PD-USGov with just 3 clicks? It takes me ~9 clicks and a multi-button mouse. I guess by "templates which contain actual content", you mean ones not like infoboxes. Seems like we're largely in agreement. --Elvey(tc) 16:44, 23 January 2016 (UTC)
@Elvey: Ok, there's 1 extra click if you start on WP and are wanting a Commons template, but here it is:
  1. From File:Nsa-ant-genesis.jpg click "View on Commons" in the content actions at the top of the page content (where edit / view source would normally be).
  2. (same page, but on Commons now) Click the "Page information" link in the tools on the left sidebar.
  3. Scroll down to "Page properties", and you can view and edit any of the templates.
  4. From either view or edit, you can now click talk.
It is normally just 3 clicks from page to any transcluded page on MediaWiki, Commons adds an extra click if you don't start there. You can also do it by editing the page (on Commons, if it's hosted there) and using "Templates used on this page" at the bottom of the action=edit page, same number of clicks. I have no idea how you are making it so complicated / difficult (9 clicks).
If there are demonstrable real use cases (that are not either complete outliers or better solved another way) where there's a good case for inexperienced editors and non-editors needing to be on a template message page, I might rethink my position. Frankly, I'm just not seeing what those cases are right now, only great potential for people ending up in places that are not particularly useful or necessary for them (and may well be confusing or end up with talk being left unanswered and in completely the wrong place, plus an inevitable increase in good faith but disruptive edits to the wrong place in the case of unprotected templates). I see essentially no benefit for the people who do need to get there, as it is already extremely easy. It's not that I want to completely hide the templates from the inexperienced, more that I think MediaWiki can be confusing enough for them without making it too easy to end up in very much the wrong place (such an neck deep in complex template source, or their questions not getting answered due to being on an obscure talk page rather than one of the general support pages).
Murph9000 (talk) 17:31, 23 January 2016 (UTC)
I think much of the many arguments in favor of the V • T • E links feature made by User:CapitalR, User:Resolute, User:Nigel Ish, User:Hellknowz, User:Yoenit, User:Snowolf & User:Nyttend apply more widely, however User:Redrose64 is right, they're not generally useful for infoboxes. --Elvey(tc) 16:44, 23 January 2016 (UTC)
Are you suggesting adding these links to {{cleanup}}, {{wikify}}, {{unreferenced}}, etc? If so, I disagree: I agree with Murph9000 that content-providing templates should have them, but these are project maintenance templates that should be template-protected to prevent edits without consensus. If you know how to find the talk page to see whether there's consensus, you know how to edit the template without these links, and edits will be quite rare anyway, so adding the links would save almost no time, but it would greatly increase the number of people trying-and-failing to edit them. Nyttend (talk) 16:56, 23 January 2016 (UTC)
  • I will echo Murph9000's viewpoint. VTE links on content-based templates are useful. They are far less useful on maintenance templates. In the provided example of "sometimes the talk page has more information", I would say the solution there is to link to the talk page inside the template's text blurb. Resolute 19:38, 23 January 2016 (UTC)
  • Oppose Users seem to find their way to pages like Template talk:Citation needed, Template talk:Db-meta, Template talk:Edit fully-protected, Template talk:Reflist or Template talk:Rfd often enough. There's no need to make it easier for them to use something other than the article's own talk page to post their misplaced explanations. --Redrose64 (talk) 21:43, 23 January 2016 (UTC)
  • Strong support if the use in messageboxes and other administrative templates and such is wrapped a CSS class that is hidden by default at Mediawiki:Common.css, which can be made visible in user CSS by registered users who know what they are doing. This would be a major time-saver for experienced template-editors. I also support the links being added, without being hidden, to infoboxes (where it is not common yet), navboxes (where it's already common), and other mainspace, content-filled templates. It's pushing the boundaries (in a negative sense, of erecting barrier to entry) at "the encyclopedia that anyone can edit" to keep stuffing more and more content into templates that only experienced editors even understand the existence of.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:43, 4 February 2016 (UTC)
    Please give examples of templates where you think that the addition of navbar links would be beneficial. --Redrose64 (talk) 22:25, 4 February 2016 (UTC)
    Well, there are hidden navbars on most project talk page banners and all stub templates. With 10 people using personal CSS to show the stub links and 6 for the project banners (with one of those people being Redrose64). So, overall, not a lot of people are finding those useful. -- WOSlinker (talk) 23:47, 4 February 2016 (UTC)
    I asked for examples where "the addition of navbar links would be beneficial", and you give two - both of which (provided that the registered user has installed a CSS rule) already have them. I'm confused: are you suggesting that these should have the links visible to all users - or that they should be removed from all users? --Redrose64 (talk) 10:16, 5 February 2016 (UTC)
    I suppose I'm giving examples of where they have been added but the benefit is minimal. Personally, I'm not bothered either way but just wanted to mention these in the discussion so that everyone can see what has already been done. -- WOSlinker (talk) 16:07, 5 February 2016 (UTC)

Additional features[edit]

It would be nice to have the following:

  • Additional items (added as a group with |full=y (several of these are found on other templates, e.g. {{To-do}})
    • History [H]
    • Watchlist [W] – toggle watched/unwatched
    • Purge [P] or Refresh [R] ("purge" may sound alarming to people unfamiliar with MediaWiki's technical detail; this is why "Refresh" is used at {{to-do}})
    • Perma-link [L] – call up current version as a history page
  • Ability to add/suppress each item case-by-case, with |talk=y, |talk=n, in a way that overrides |full=y (in particular because many of the things that use this template do not have, should not have, and in some cases cannot have talk pages)
  • Auto-suppression of display of the item in question when already on that page (e.g. if on a page with this template, show T - E, but not V; if on a talk page with this template, show V - E but not T.

The full version could exist as a wrapper at, say, {{Navlinks}} that aliases {{Navbar|full=y|plainGreen tickY}} and passes other parameters (including a |plain=n, if someone wants to turn on the usually unused verbiage).
 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:35, 4 February 2016 (UTC)

Have a look at {{v}}. As for the other links you suggest; they have nothing to do with navigation and are all personal tools. Those should not be splattered around (in article space). -- [[User:Edokter]] {{talk}} 18:11, 5 February 2016 (UTC)


Case v-t-e[edit]

Wikipedia has always used a down style - notably the tabs "article" "talk" "edit" - which v-t-e emulates, and the show/hide on the RHS of the navbar are lower-case.

It would be nice if v-t-e could revert to its former lower case glory.

All the best: Rich Farmbrough, 00:18, 21 February 2016 (UTC).

@Rich Farmbrough: It is, technically - it's styled as font-variant: small-caps;, which makes the links look like capital letters: v t e. If you drag your mouse over a navbar like , copy and paste to somewhere else, they come out as "v t e".
BTW shall we be seeing you in Oxford later today? --Redrose64 (talk) 00:26, 21 February 2016 (UTC)
The resason small caps are used is because the lower case letters are too narrow to click on. -- [[User:Edokter]] {{talk}} 19:59, 21 February 2016 (UTC)

So perhaps instead of:

We could use:

Or:

if it's only the "t" we are worried about (per the original discussion).

All the best: Rich Farmbrough, 17:44, 22 February 2016 (UTC).

Mainly the 't', which is only 3 pixels wide. The thinsp's don't help. -- [[User:Edokter]] {{talk}} 21:08, 22 February 2016 (UTC)
They help me. The active area is larger, the underline is larger.
Does this version not work for you either? All the best: Rich Farmbrough, 16:40, 10 March 2016 (UTC).

Module:Navbar causing problems on cy-wiki[edit]

Can someone tell me what's the problem on w:cy:Pencampwriaeth y Chwe Gwlad 2016's infobox (apart from the rugby!)? Thanks! Llywelyn2000 (talk) 07:20, 12 March 2016 (UTC)

@Llywelyn2000: At cy:Nodyn:Infobox Six Nations Championship, try altering |name= to |title=, or just remove that parameter. In an infobox, the |name= parameter is used to create navbar links (these show as v-t-e or view-talk-edit on English Wikipedia), they're rarely useful in an infobox except where a fully-populated infobox is on a separate page from the article, like at the bottom of {{Infobox hydrogen}}. --Redrose64 (talk) 15:44, 12 March 2016 (UTC)
Wild Welsh and wicked! Well done my red, red rose! Diolch! Llywelyn2000 (talk) 06:27, 13 March 2016 (UTC)

wrong divine temple academy page Protected edit request on 7 July 2016[edit]

That your post is wrong divine temple academy is in nepal why do u erease that please make it free from editing Ashish lc (talk) 10:12, 7 July 2016 (UTC)That your post is wrong divind temple academy is in nepal why do u erease that please make it free from editing

Red information icon with gradient background.svg Not done for now: Sorry I don't know what you are asking — Martin (MSGJ · talk) 12:21, 7 July 2016 (UTC)