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 34,339,208 pages in total, of which only 4,656,439 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)