This is an archive of past discussions about Template:Navbar. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
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)
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 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]]
}}
This edit request to Module:Navbar has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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)
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}}(t • e • c)21:00, 23 May 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
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.
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)
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.--JohnBlackburnewordsdeeds14: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
, 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.--JohnBlackburnewordsdeeds15:43, 29 July 2014 (UTC)
mini v-t-e links: abbr instead of span for accessibility
This edit request to Module:Navbar has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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.
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)
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.
@Elvey: Ok, there's 1 extra click if you start on WP and are wanting a Commons template, but here it is:
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).
(same page, but on Commons now) Click the "Page information" link in the tools on the left sidebar.
Scroll down to "Page properties", and you can view and edit any of the templates.
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).
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. Resolute19:38, 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)
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
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|plainY}} 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
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.
@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
@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)
wrong divine temple academy page Protected edit request on 7 July 2016
This edit request to Module:Navbar has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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
This edit request to Module:Navbar has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please merge the sandbox version of the module to the main version. This modifies the collapsible navbar so that the title is contained in a div with padding to the left and right. This does not affect anything which is currently in use, although I will implement it in {{Navbar-collapsible}} pending a site CSS change which removes extraneous padding from the V · T · E links and the collapse button. Jc86035 (talk) Thanks, Jc86035 (talk) Use {{re|Jc86035}} to reply to me12:32, 13 March 2017 (UTC)
@MSGJ and Primefac: The aforementioned CSS change was implemented as a result of Module:Navbox getting its own header padding (discussed at Template talk:Navbox), and affects all templates using the navbox class (including {{Navbar-collapsible}}). AFAIK a span tag has padding to the left/right of the characters and not a rectangle containing the text, but I'm not entirely sure, though the div tag is used in {{Routemap}} and {{Navbox}} and it works fine. Jc86035 (talk) Use {{re|Jc86035}} to reply to me00:14, 14 March 2017 (UTC)
A span tag can have padding set all around, like this, although whether your browser displays any padding top & bottom is another matter. Firefox 52 doesn't. --Redrose64 🌹 (talk) 00:22, 14 March 2017 (UTC)
As I cannot see the difference (FF52 user) I cannot see the change, and thus I cannot comment on its necessity. It seems that both spans and divs are used (successfully) in various places, so unless there actually is a non-FF-display reason for the update it seems more like a cosmetic edit. In other words, I don't strictly oppose the change, but I'm not going to implement it.Primefac (talk) 12:41, 20 March 2017 (UTC)
@Primefac: The change from span to div doesn't really matter, I think, since the rendered output for both of them in this particular case is largely the same. The problem is that there is no padding since it was removed in MediaWiki:Common.css last week, and so the header text isn't aligned exactly in the centre (and moves around when the box is expanded and collapsed). Jc86035 (talk) Use {{re|Jc86035}} to reply to me10:54, 21 March 2017 (UTC)
@Primefac: Sorry, but can you merge the sandbox again? I forgot to remove styling making the V · T · E box 6em wide. Thanks, Jc86035 (talk) Use {{re|Jc86035}} to reply to me12:01, 21 March 2017 (UTC)
This edit request to Module:Navbar has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Could the contents of the sandbox be copied to the main template? This change fixes the formatting for the square brackets so that they render properly without HTML Tidy. Thanks, Jc86035 (talk) Use {{re|Jc86035}} to reply to me07:28, 13 May 2017 (UTC)
Currently, the title text of each link specifies "template". However, {{Navbar}} is explicitly designed to be usable with non-template pages, and in these cases the word "template" may not be appropriate. Therefore, the text should be generalized, at the very least by taking the namespace of the page passed to {{Navbar}} into consideration, and possibly also with a parameter allowing customization. 「ディノ奴千？！」? · ☎ Dinoguy100013:20, 5 September 2017 (UTC)
I can't point to anywhere on Wikipedia off-hand; this is more a concern for reusers on other wikis (though personally I have little doubt there are uses even here that would benefit). While certainly individual wikis could modify the module to their liking, that would require them to be aware of the current behavior and to have an editor on-hand capable of working with Lua, and every wiki would have to redo the work for themselves (or find another wiki that had already done the requisite work).
While it is certainly true that template/module maintainers on Wikipedia have no obligation to consider reusers on other wikis, this is a relatively simple and minor adjustment that I believe would have some benefit here as well. 「ディノ奴千？！」? · ☎ Dinoguy100022:27, 5 September 2017 (UTC)
Sorry to belabour this point, Dinoguy1000, but do you have evidence on other wikis that this is happening? Don't get me wrong, I understand your concerns, but there really is not much point in fixing something that isn't broken, as they say.
As a minor note, I do not see anywhere in the documentation (either on the template or the module) that it is explicitly designed to be usable with non-template pages; as far as any non-template-space usage is concerned, it's not prohibited but it's not exactly encouraged either. Primefac (talk) 12:15, 6 September 2017 (UTC)
Yes, I shouldn't have used the word "explicitly", really. I can't answer whether the past editors of this template/module ever made changes with the explicit purpose of supporting uses for non-template/module pages, but certainly it was originally designed solely for use with templates, and at some point was generalized (some time before the rename from Tnavbar in April 2009; it's worth noting that the move rationale does explicitly state that the rename is in response to the template being generalized to work with all namespaces). 「ディノ奴千？！」? · ☎ Dinoguy100011:09, 10 September 2017 (UTC)
Been digging through the lua module, and when it all comes down to it, there's a simple way to check this sort of thing. I just did this, which produces <<subpage changed, permaLink is Special:PermaLink/799897098>>
I never said it doesn't, only that, when originally created, it didn't. It was generalized at some time between its creation in 2006 and the rename from Tnavbar to Navbar in 2009 so that it would work with any namespace. 「ディノ奴千？！」? · ☎ Dinoguy100013:20, 13 September 2017 (UTC)
Okay, you've completely lost me. You asked that it work in all namespaces, but it does, and now you say that you know it does. What are you wanting? Primefac (talk) 13:44, 13 September 2017 (UTC)
The title text (the text that appears when you hover over one of the links - "View this template", "Discuss this template", "Edit this template") is specific to the Template namespace; it is this that I'm requesting be made to work with any namespace. I acknowledged in my original comment that the template overall already works with any namespace. 「ディノ奴千？！」? · ☎ Dinoguy100014:09, 20 September 2017 (UTC)
It could, but that would create all sorts of confusion. Here's an example:
I arbitrarily chose Angola. Two navbars at the bottom. You over over "e" for each and it says "edit this template". Let's assume we institute the above suggestion. Now we have two templates that each say "edit this page", implying that you're editing Angola instead of Template:Angola topics or Template:Countries of Africa.
This is why I started arguing semantics, because while I agree that "this template" is nonspecific should we happen to have a template being transcluded from somewhere other than the Template space, but again I would argue that a userspace template (or even a WikiProject template) is still a "template" in that it gets transcluded from one place to another, especially if it's using {{navbar}}. Primefac (talk) 19:45, 20 September 2017 (UTC)
No, I didn't mean that it should always be "page", nor that it should change depending on where it was transcluded to: but should change according to the namespace where the navbar is actually used. So for example in Angola, we have {{Angola topics}}; and this is hosted in Template: namespace, so the link's title attribute correctly uses the word "template". If, for some reason, the code which begins
{{Country topics
| country = Angola
| state = {{{state|{{{1|autocollapse}}}}}}
| adjective = Angolan
were not in template space, then it would be appropriate to show the word "page". What I am saying is that the line
:attr('title','View this template')
might be altered to something along the lines of
:attr('title','View this '+if(namespace(args.navbar)=10,'template','page'))
Or something. This Lua code is all unreadable; I can't track it through at all - and this module is quite small. RexxS, how the heck does the first positional parameter of Template:Navbar get converted into title.fullText for the "view" link? Let's not worry about the other two at this stage. --Redrose64 🌹 (talk) 20:55, 20 September 2017 (UTC)
local titleText = args[titleArg] or (':' .. mw.getCurrentFrame():getParent():getTitle())
The previous lines set titleArg to 1 or 2 depending on whether it's 'collapsible' and/or 'plain', so that either the first or second positional parameter (i.e. args[1] or args[2]) is used to set titleText (args[titleArg]).
If that parameter does not exist, then the or sets titleText to a colon plus the title of the page from which the template is called (':' .. mw.getCurrentFrame():getParent():getTitle())
Line 20 then creates a "title object" called 'title' representing the given title in the 'Template' namespace, and lines 22-24 throw an error if that is not a valid title.
Line 26 sets a variable 'talkpage': if the page can have a talk page, it is a string containing the title of the page, with the namespace and interwiki prefixes and the fragment; otherwise it is nil.
Lines 54 onwards create a <div>...</div>, within that is an <ul>...</ul> containing <li>...</li> - the first of which (on lines 57-66) uses title.fullText, which is the title of the page corresponding to the 'title' object created in line 20 (with the namespace and interwiki prefixes and the fragment per documemtation of .fullText).
The problem still becomes one of language, and being specific. Let's use your Country topics example - if it were not in the template space, and it said "edit this page", it would still have a dual meaning - edit the article you're looking at, or edit the page where this "template" is found? I can understand the concerns raised, but (to quote H:T) a template is a Wikipedia page created to be included in other pages. If something is actively being transcluded onto multiple pages, it's a template (especially if it's using {{navbar}}).
Now, if we come up with a way (in two words or less) to accurately describe "edit this X" that will inform the user that they will be editing a different page (regardless of namespace) then I'm happy to make that change to the module. At the moment, though, I'm just concerned that we're trying to delineate the spades from the shovels. Primefac (talk) 13:05, 21 September 2017 (UTC)
Perhaps we could use the wording "Edit this navbox"? I would assume that anyone competent enough to edit the particular instance of the navbox would be well enough informed to understand what the 'navbox' would be. --RexxS (talk) 20:41, 21 September 2017 (UTC)
Well, it's not my call, and I'm not trusted to edit this template or its module, but I'd simply enable another parameter that defaults to "template" when absent. Then use that in the hover-tip, something like:
tooltip=args.tooltipifnottooltipor#tooltip==0thentooltip="template"end...:attr('title','View this '..tooltip)etc.
Then anyone could modify the tooltip to "View/Discuss/Edit this navbox or sidebar or whatever" according to taste. It's not going to be moved away once it's placed on a page, so it doesn't really need to dynamically determine what it's being used in and a editor only needs to make that call once. --RexxS (talk) 22:22, 21 September 2017 (UTC)
So after a related TFD I realized that this template, {{v}}, and {{view}} all pretty much do the same things. It would be fairly straightforward to add in the h/m/w links to the navbar module, so does it really make sense to have three templates? Primefac (talk) 19:33, 17 February 2017 (UTC)
Why have you put this page under protection and why is everything hidden?
Is that to stop people from posting all the music that jamiroquai have stole
on those guys music list? — Preceding unsigned comment added by Amir 86302 (talk • contribs) 18:13, 26 March 2018 (UTC)
Amir 86302, I think you're posting in the wrong place. This page is protected because it is used on nearly 8 million pages, but it has nothing to do with music. Primefac (talk) 18:18, 26 March 2018 (UTC)
, i.e have a different order of view talk and edit etc; the way I've coded it always has the same order regardless of how it is inputed; it'd be more complicated to code it the other way, and it seems reasonable to have a consistent ordering
one can also mix mini and non-mini with {{v}} e.g {{v|edit|t|template = v/doc}} gives
If {{view}} is just redirected to the new version of {{navbar}}, then this breaks the cases of {{view|v/doc}}, i.e, the ones without |template= by giving
. There isn't really any way to fix that And anyhow, one'd have to have |plain=1 on each instance of {{view}} thus both {{v}} and {{view}} should probably just be convenience wrappers for {{navbar}} rather than redirected, as I've done on {{v/sandbox}} and {{view/sandbox}}. Either that or someone needs to fix the instances where |template= isn't given and add |plain= and |mini= as appropriate.
Primefac the explanation is above - you'd first need to add some parameters to all transclusions if one wanted to do that - as they are formatted differently - |plain= and |mini= would need to be set Galobtter (pingó mió) 13:31, 9 April 2018 (UTC)
The title says it all: Is it possible to create a navbox without the v-t-e part on the top left or can that not be done due to dependencies to the navbar and v templates?
If it is not possible, is there something similar you could recommend as some kind of infobox that spans over the top of a page? — Preceding unsigned comment added by Lithimlin (talk • contribs) 17:54, 17 April 2018 (UTC)
Lithimlin, if you are planning on using {{navbox}}, then yes, it will have the v-t-e. What sort of instance would you want a navbox without it (i.e. please give an example)? Having a navbox without the ability to easily find and edit it would be problematic. Primefac (talk) 17:56, 17 April 2018 (UTC)
As I said, I basically just want to make an infobox, that is not on the right side with a fixed width, but rather at the top of the page, spanning across it. Lithimlin (talk) 18:20, 17 April 2018 (UTC)
If you are using the {{navbox}} template, and you want the v-t-e links omitting, all you need to do is omit the |name= parameter - or leave it blank. No need for any |navbar=plain etc. --Redrose64 🌹 (talk) 18:46, 17 April 2018 (UTC)
No, I mean the |name= parameter. That has just one purpose: to set the v-t-e links. If that param is blank or absent, there are no links. --Redrose64 🌹 (talk) 19:35, 17 April 2018 (UTC)
I just tried it and not setting a {{{name}}} didn't change anything. However, if there's no {{{title}}}, there will also not be any v-t-e links. Lithimlin (talk) 19:38, 17 April 2018 (UTC)
I'm testing this in a wiki I'm helping to put together right now. I'm kind of misusing the {{navbox}} here, but it was the only thing I found so far that can be used as an {{infobox}} that spans across the top of a page instead of being on the top right of it.
Make tooltips optional so "sortable" doesn't break in sports tables?
Sports tables, like this one, can't be sortable. A comment in the Module:Sports_table says the problem is caused by Navbar and gives a link to this comment, which says "It's caused by {{navbar}} adding tooltips to the link text with <abbr title="Discuss this template">t</abbr> instead of just t. There is no current option to omit the tooltips but it could be requested at Template talk:Navbar."
So, to fix Module:Sports_table, could someone add that option to Navbar? Other solutions for Module:Sports_table would also be welcome. Thanks. Great floors (talk) 15:02, 29 July 2018 (UTC)
Request: Add template styles to existing stylesheet
Please add:
<templatestylessrc="Navbar/styles.css"/>
to this template. This will allow us to manage styles for mobile and desktop in one central place and remove them from MediaWiki:Mobile.css. Navbar's are not present on all pages so this would reduce the amount of CSS we ship to users. Jdlrobson (talk) 23:18, 30 October 2018 (UTC)
What is extensionTag doing? I have a rough idea of its function but without knowing much about templatestyles I would have thought that adding the wikitext shown above was what was wanted. Just curious, was there a reason no_globals was removed from the sandbox in April? Possibly because navbar was used with other modules that had globals? At any rate, the frame variable should be declared local. Johnuniq (talk) 06:41, 31 October 2018 (UTC)
Thanks for the catch on the local variable! (apparently I still haven't learnt my lesson from last time..). Reason I removed; wasn't sure if the final code I should have Module:No globals (this module is used in so many places that it could possible break something..), but should definitely test in sandbox to make sure there are no globals. Regarding extensionTag, It is the same thing as using {{#tag:templatestyles||src = "Navbar/styles.css"}} which would do basically the same as
OK, but I think you are saying there is no reason to use extensionTag. Just add the wikitext without the complexity/overhead of calling extensionTag. Johnuniq (talk) 08:39, 31 October 2018 (UTC)
Ah, now we're getting to my question. Why does the tag need to be preprocessed? I understand that preprocessing is needed if you want a template expanded but in my innocence I thought the plain wikitext of templatestyles would do. I don't have an idea of when/how it loads the required css. Why would preprocessing help with that? Perhaps I should go to WP:VPT. Johnuniq (talk) 09:03, 31 October 2018 (UTC)
Johnuniq if it isn't preprocessed it'll just show the bare text like <templatestyles src="Navbar/styles.css" /> ({{#invoke:Sandbox/Galobtter/preprocess|main}} gives <templatestyles src = 'Flowlist/styles.css'>)
This is because mw:Extension:Scribunto/Lua_reference_manual#Returning_text: "At this point in the page parse, templates have already been expanded, parser functions and extension tags have already been processed, and pre-save transforms (e.g. signature tilde expansion and the pipe trick) have already happened." So when Lua returns the text it won't have the regular processing be done on it, including processing tags; so it needs to be preprocessed. Galobtter (pingó mió) 09:09, 31 October 2018 (UTC)
When the templatestyles tag is preprocessed it'll be replaced with a strip marker and then later turned into the style html (which one example is like this:
Thanks for those details. That's pretty weird! We have something that looks like html (the templatestyles wikitext) but it gets expanded. I suppose I'll get used to it. Johnuniq (talk) 09:33, 31 October 2018 (UTC)
@Johnuniq: The HTML-like appearance of <templatestyles /> should not be unfamiliar: consider <ref name=something>...</ref> which is found in so many articles; this looks like HTML (but is not HTML), it's part of the cite.php extension to the MediaWiki software. Then there are <gallery>...</gallery>, <math>...</math>, <noinclude>...</noinclude>, <nowiki>...</nowiki>, <references /> and <syntaxhighlight>...</syntaxhighlight> (which is used above), all of which are either part of MediaWiki, or are coded as extensions to it. There are several others - I won't list them, there are at least twenty in all. --Redrose64 🌹 (talk) 12:10, 31 October 2018 (UTC)
True. I guess my mental model of when things happen is faulty. I was imagining that <ref> and friends would be handled in some final stage of rendering, but on reflection I have seen that a ref is a strip marker by the time a module gets its input. I suppose the rendering that I hadn't thought about is exactly the step which expands templates/modules and so is the last chance to expand other things like templatestyles. Thanks all. Johnuniq (talk) 23:58, 31 October 2018 (UTC)
Template/module for ptwiki
I'm trying to implement this template/module on ptwiki, but there is this bug where it works fine in most cases, except for "edit" and "Edit this template" when it's used with {{V}} and {{View}} (and I suppose the same for "hist" and "watch"). Instead of displaying text in Portuguese, it instead displays it in English. I was thinking someone could help me out. Here's the testcase page on ptwiki. —CaiusSPQR (talk) 17:58, 19 March 2019 (UTC)
You know those drop down templates found at the bottoms of articles, such as Template:Xiamen? Also know how there are three buttons at the top left on all of them that say "V", "T", and "E", for "view", "talk", and "edit"? I'm on Chrome on a Huawei phone, and none of the buttons work at all. Pressing them only brings up descriptions of the buttons, "edit this template", etc. I can still edit them of course, but it's kind of inconvenient. How do I fix this? Woshiyiweizhongguoren (🇨🇳) 11:17, 28 March 2019 (UTC) (Originally asked at the Teahouse and the Village Pump but later moved here)
