Jump to content

Template talk:Navbar: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Transclusion count?: revert again?
Line 141: Line 141:


I'm getting tired of seeing this being changed to 3,000,000+ only to be reverted back to 800,000. [[Wikipedia:Database reports/Templates with the most transclusions]] (last updated June 22) explicitly shows Navbar as being transcluded onto almost 3.3 million pages, so why is it inaccurate? If it's because [[Special:MostLinkedTemplates]] shows the much lower figure of 800,000, I'd like to point out that it was last updated on September 16, 2008. <span style=white-space:nowrap>「[[User:Dinoguy1000|<span style=color:#00f>ダイノ<span style=color:#080>ガイ]][[Special:Contributions/Dinoguy1000|<span style=color:#F90>千?!]]」<sup>[[Help:JP|?]] · [[User talk:Dinoguy1000|<small style=font-weight:normal>Talk⇒Dinoguy1000]]</sup></span></span> 20:22, 30 June 2009 (UTC)
I'm getting tired of seeing this being changed to 3,000,000+ only to be reverted back to 800,000. [[Wikipedia:Database reports/Templates with the most transclusions]] (last updated June 22) explicitly shows Navbar as being transcluded onto almost 3.3 million pages, so why is it inaccurate? If it's because [[Special:MostLinkedTemplates]] shows the much lower figure of 800,000, I'd like to point out that it was last updated on September 16, 2008. <span style=white-space:nowrap>「[[User:Dinoguy1000|<span style=color:#00f>ダイノ<span style=color:#080>ガイ]][[Special:Contributions/Dinoguy1000|<span style=color:#F90>千?!]]」<sup>[[Help:JP|?]] · [[User talk:Dinoguy1000|<small style=font-weight:normal>Talk⇒Dinoguy1000]]</sup></span></span> 20:22, 30 June 2009 (UTC)
:Would you like to revert [[User:Edokter|Edokter]]'s last edit? -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 20:29, 30 June 2009 (UTC)

Revision as of 20:29, 30 June 2009

Add optional "namespace" param

In an effort to improve {{Navbox}}, I have added an optional "namespace" parameter in {{Tnavbar/sandbox}} and added a test case in {{Tnavbar/testcases}}. I would like to know if this is acceptable before I implement it in the actual template. עוד מישהו Od Mishehu 16:22, 26 October 2008 (UTC)[reply]

I can see no fault in the code, but what is the motivation behind this change? EdokterTalk 16:38, 26 October 2008 (UTC)[reply]
The code should normalize the namespace using {{ns:}}. It's called Tnavbar since its for templates, we have {{unavbar}} for User space templates and probably should create {{wnavbar}} for Wikipedia space templates. Other than that I can't see any other namespace that could using this template. Also {{navbar}} should be userfied. — Dispenser 18:05, 26 October 2008 (UTC)[reply]
The motivation behind this is so that I can perform a similar change to {{navbox}} where it uses this template, and then we will be able to delete pages which start with Template:User: - by making it {{navbox|namespace=user|...}}. עוד מישהו Od Mishehu 08:00, 27 October 2008 (UTC)[reply]
I had constructed a simpler template that didn't include the bloat of features of this template at {{Navbox/navbar}}. I also had purposed that navbar= parameter could be used to specify code so other template could be used. But nothing's come of it for some reason. — Dispenser 15:43, 28 October 2008 (UTC)[reply]

v • d • e (again)

I find it very perplexing that the expanded version shows view • talk • edit and that the other one shows v • d • e. The fact that talk and d are the same thing just doesn't make sense; please change d to t. ChrisDHDR 13:59, 15 November 2008 (UTC)[reply]

The d stands for "discuss", which makes a better abbreviation then t. EdokterTalk 15:22, 15 November 2008 (UTC)[reply]
I know that, I just think that it would be better if the same letter were used for both versions of the template. ChrisDHDR 15:59, 15 November 2008 (UTC)[reply]
I agree with ChrisDHDR. The short form should be the same as the long form, so either "view • discuss • edit" and "v • d • e", or "view • talk • edit" and "v • t • e".
The middle link is to a "talk page", we rarely call them "discussion pages". And I find the longer form "view • discuss • edit" too long. So "view • talk • edit" is better. Thus I think the short form should be "v • t • e".
--David Göthberg (talk) 00:17, 17 November 2008 (UTC)[reply]
I think the original reason was that "t" rendered too small to click on (only 2 pixels wide). In any case, this change has a relatively big impact, so it needs broad consensus. I feel this is better discussed at the Village Pump. EdokterTalk 00:51, 17 November 2008 (UTC)[reply]
Well, I made a screen dumps of the examples on this template's doc page, and checked in my image editor: In all three of my browsers the "v" is 5px wide, the "d" and "e" are 4px wide, and the "t" is 3px wide. So yeah, the "t" is a bit thin, but I still think we should use a "t" since the "d" is confusing.
--David Göthberg (talk) 07:49, 17 November 2008 (UTC)[reply]
  • Here the tab at the very top of the page is labeled "discussion", whereas the page is named "Template talk...", so it looks like the mixed description extends into the wiki software itself. Perhaps if/when there's consensus to choose one or the other description there it can be applied here too. Sardanaphalus (talk) 09:08, 22 November 2008 (UTC)[reply]

The show/hide link generated by the collapsible tables code in MediaWiki:Common.js has been reduced from 6em to 3em in width. As a result, the title bars in navboxes are offset to the right, caused by this template. I'm not 100% sure what changes need to be made, though, which is why I didn't put an editprotected request here too. I'm also not really clear how the caching comes into play or how to circumvent it until it expires. Any comments? —Dinoguy1000 21:43, 17 November 2008 (UTC)[reply]

I've reverted the change in common.js for now. I agree that tnavbar and show/hide could take less space, but we need to find out by how much. The change was made too impulsive, as 3em is too narrow for tnavbar. EdokterTalk 22:44, 17 November 2008 (UTC)[reply]

noedit parameter

It makes no sense to have an edit link for fully-protected templates. I propose adding a noedit=1 parameter for added customization. Proposed code is in the sandbox and testcases are available here. Thoughts? --MZMcBride (talk) 18:53, 21 November 2008 (UTC)[reply]

Done. --MZMcBride (talk) 23:36, 22 November 2008 (UTC)[reply]

Bracket option request

As mentioned before Archive 1#Design improvements. Please consider adding brackets that looks exactly like the collapsible [show/hide] button so to distinguish between header text in slender template. The brackets can not be added manually because there're 1 space around the v-d-e by default (even with nodiv=1,) and header porperty will end up bolding the brackets so it looks abruptly. Thx -- Sameboat - 同舟 (talk) 14:17, 20 January 2009 (UTC)[reply]

Added the brackets=1 option to the sandbox. See the testcases page. EdokterTalk 23:50, 4 March 2009 (UTC)[reply]
Quite satisfying :) User:Sameboat/x3 -- Sameboat - 同舟 (talk) 00:59, 5 March 2009 (UTC)[reply]

New version is ready

The next version of this template is technically ready to go live. New 'features' include the implemetation of the noedit=1 and brackets=1 option, which should be self-explainatory. noedit hides the edit link (usefull for permanently protected templates) and brackets will show brackets around the links. See the testcases page for how that looks.

But before deploying, there is one thing that I want input on. I'd like to hear what you think about the font size. The current sandbox version has a slightly larger font, as can be seen in testcases. This would not be apprearent in navboxes, as that reduces the fontsize again. Would you prefer the larger size, or prefer the current size? Opinions welcome. EdokterTalk 21:56, 5 March 2009 (UTC)[reply]

I've got a question, but it's related to the testcases page as opposed to the proposed update - why are the live and sandbox versions shown in two separate sections? That just makes comparing their output that much more difficult. Why not show them side-by-side, as is done with, for example, Template:Nihongo/testcases? ダイノガイ?!」(Dinoguy1000) 22:06, 5 March 2009 (UTC)[reply]
WP:SOFIXIT :) The testcases page isn't protected. I'll do it when I get home. EdokterTalk 23:30, 5 March 2009 (UTC)[reply]
Yeah, I thought so, just wanted to make sure there wasn't some reason for it I wasn't aware of. =) --Dinoguy1000 as 66.116.12.126 (talk) 00:39, 6 March 2009 (UTC)[reply]
All done. EdokterTalk 00:52, 6 March 2009 (UTC)[reply]
Yep, I editconflicted with you (then ecided to discard my edit and tweak your version). =) --Dinoguy1000 as 66.116.12.126 (talk) 01:09, 6 March 2009 (UTC)[reply]
Would there be any objection to adding a history link, enabled via {{{history}}}, {{{histlink}}}, or similar? --Dinoguy1000 as 66.116.12.126 (talk) 01:09, 6 March 2009 (UTC)[reply]
The history link idea is a bit strange to me. But I see no harm to have this as an optioanl entry. -- Sameboat - 同舟 (talk) 01:57, 6 March 2009 (UTC)[reply]
Personally, I think we should stick with the three main links. Other templates (ie. {{v}}) do have more link options. Tnavbar should stay 'minimal' because it is used in over 600.000 pages. EdokterTalk 02:20, 6 March 2009 (UTC)[reply]
That's fine, just wondering about it. =) ダイノガイ?!」(Dinoguy1000) 18:00, 6 March 2009 (UTC)[reply]

Edokter, why the insistence that "the talk page link should always be blue"?? Every other link on Wikipedia uses colour to distinguish between an extant and a nonexistent page; why should these links be any different? And using a hardcoded style certainly doesn't work: have you looked at it in CologneBlue or Simple? Why should we make such an effort, and actually make it look worse than before, simply to hide metadata that could actually be valuable? Happymelon 11:33, 7 March 2009 (UTC)[reply]

Check the archives of this talk page, and those on navbox too; consensus was to not draw attention to a non-existent talk page, so the link should stay blue. EdokterTalk 14:51, 7 March 2009 (UTC)[reply]
It's a monobook-centric viewpoint to equate "existing" and "blue". I can't see any extensive discussion (although I admit I haven't read all the navbox archives) only NedScott getting almost no reaction back in 2006. Unlike recolouring the whole text, which is an obvious and transparent abandonment of the redlink/bluelink standard, pretending that a nonexistent page does in fact exist is pure deception. If we don't want to draw attention to it, we should use an #ifexist: and only link to it if it exists. Happymelon 18:52, 9 March 2009 (UTC)[reply]
 #ifexist: is a very expensive hit which does impact performance in a way we do have to worry about; it would execute everytime a page containing Tnavbar is edited. As I recall, it causes a recursive database lookup, which is one of the reasons why the preprocessor statement limit was decreased from 100.000 to 2000 not too long ago, because #ifexist: was clogging the preprocessor. This is simply not an option.
Besides, while I agree in general that non-existent pages should be visible in normal links to article- and Wikipedia space, it is not that important for templates I beleive. And, when fontstyle is used, the distinction is gone as well. I also know it's monobook-specific, but it is the most used skin, and the default link color is not too far off from other skins' link color. EdokterTalk 23:31, 9 March 2009 (UTC)[reply]
I'm fully aware of the nature of #ifexist:, that's why I put the link in. The database lookup is not recursive; it's the same level of server load as the {{PAGESINCATEGORY:...}} function, a single-row lookup from the page table. It's certainly used far more gratuitously and liberally in other, equally-popular, templates. Five hundred thousand extra lookups is not going to bring down the 8th most active website, and even if it does, a dev will trout us for it and we'll go on as before. If a dev removes the function, obviously that's a whole different ballgame, but they haven't, and they haven't set any technical restrictions to prevent us using it, so we should use it if it is appropriate, as it is here (certainly more so than pretending that red is blue). Happymelon 08:58, 10 March 2009 (UTC)[reply]
I've advocated spliting the template into two. One ultra-minimal design for use with those tens of thousands of navboxes and this one packed with features that are rarely used. This would be a good balance between features and performance, with the upside that we could readily add features here without worrying much. — Dispenser 04:11, 10 March 2009 (UTC)[reply]
The new template removes the |miniv= and |viewplain= parameters (we will indicate in the doc that users should use {{view}} and {{v}} as replacements) which are unused, and the {{fontcolor}} param. The template has got a lot simpler, not more complicated, fortunately. Happymelon 08:58, 10 March 2009 (UTC)[reply]

Ok, I've deployed the new code, without the blue override for the 'd' link. If we get howls of protest then of course we'll need to user #ifexist:, replace the colour, or do something more clever; but let's see if there's actually an issue here before getting worked up over it. Happymelon 17:26, 14 March 2009 (UTC)[reply]

I got here from noticing a difference, is it possible that the v e d to become that bit smaller again? I think it looked better before. chandler · 17:59, 14 March 2009 (UTC)[reply]
I agree; I've changed it back to the old xx-small. Happymelon 20:10, 14 March 2009 (UTC)[reply]
Great. And on the "red link for d" disscussed above, just initial thoughts were "hmm that isn't how it used to look?", even though I can see both sides pro's and con's, that it might be bad to give the impression that the talk page exist, and at the same time a bit distracting and quite noticeable when you see the classing red link, I think everyone will get used to it in the long run. chandler · 20:31, 14 March 2009 (UTC)[reply]
What do you think about it being an unlinked black 'v' if the page didn't exist? Happymelon 20:38, 14 March 2009 (UTC)[reply]
Should probably be fine I guess, the only problem I can think of would be if the black v would "trick" you if you're not using {{PAGENAME}} and mistakenly write in the wrong name. chandler · 20:45, 14 March 2009 (UTC)[reply]
Argh, I meant the 'd' link. If the 'v' link comes up red, that should be ringing big alarm bells... :D Happymelon 21:28, 14 March 2009 (UTC)[reply]
Hehe, we'll personally I think I'd want a link if a 'd' is gonna be shown, red or blue, though that might be have to be done with #ifexist, rather no d than a d with no link on it imo. chandler · 21:54, 14 March 2009 (UTC)[reply]
Smaller? I intended to make them bigger (from xx-small to 85%). That only shows how inconsistent pre-defined CSS values are handled. What is youtr browser?
Aargh... fixed the bullet sizes (linked to font-size). Please try to get it right in one edit. We should all give the "Go" before going live. Stay sharp, people! EdokterTalk 00:12, 15 March 2009 (UTC)[reply]
The big bullet's don't fit imo, am I correct in that the small bullets were how it was before? chandler · 00:30, 15 March 2009 (UTC)[reply]
Partly. The original used big bullets, but slightly reduced in size (85%). In the sandbox, I replaced them with non-reduced bold mid-dots to compensate for the larger font. But those are too small with the original xx-small font that Happy-melon put back. EdokterTalk 00:40, 15 March 2009 (UTC)[reply]
[1] Isn't the middle one how the previous version was? That's at least how I remember it, and of those three, my favourite (the top is the current, the bottom is the first version of the new) chandler · 00:45, 15 March 2009 (UTC)[reply]
Or it seems to have been a bullet of 80% inside xx-small v d compared to v • d, and personally I like the former of these two. For me it's just better proportioned between the bullet and the letters. chandler · 00:51, 15 March 2009 (UTC)[reply]
Your browser shows some big bullets... to me (IE6) the current code shows as the bottom one, which is just right IMO. The middle one is just too small. What is your browser? EdokterTalk 01:07, 15 March 2009 (UTC)[reply]
Firefox, now the image doesn't show how my '' is shown, the middle one shows '·' is shown (which I firstly thought was the old one) chandler · 01:15, 15 March 2009 (UTC)[reply]
My Firefox also shows as the bottom one, just as IE. EdokterTalk 01:25, 15 March 2009 (UTC)[reply]
The bottom one in the picture is for me how this version look, while the top one is the current. "v d e" is how I would like it to look. chandler · 01:37, 15 March 2009 (UTC)[reply]
Now looking in IE, Opera, Chrome and Safari and doesn't look so much different, but in my Firefox the right one looks almost twice the size (forgot to mention, I don't use Arial, which I guess in the default font.) :S chandler · 01:41, 15 March 2009 (UTC)[reply]
(←)Ah, indeed. The default font is 'sans-serif', which usually defaults to Arial. We can't please everyone. This cahnge was about removing as much as unnecessary code as possible. EdokterTalk 02:32, 15 March 2009 (UTC)[reply]
What about adding <small>, it doesn't add that much extra code and hopefully looks pretty much the same in Arial , left is with small, right without chandler · 02:47, 15 March 2009 (UTC)[reply]
Hardly visible on my end, and <small> is just as unpredictable across browsers. EdokterTalk 19:09, 15 March 2009 (UTC)[reply]
Well that's the idea, that in Arial it will look the same, but for users who use a non-default font it will make it look like it did before these changes. chandler · 20:01, 15 March 2009 (UTC)[reply]
I mean the small middot is barely visible using the default font, nit that there is no difference. Even the bold middot barely shows up with xx-small. EdokterTalk 22:28, 15 March 2009 (UTC)[reply]
Yea I know but the old one was a <span style="font-size:xx-small"><span style="font-size:80%;">•</span></span>, so it wouldnt be the middot, chandler · 22:59, 15 March 2009 (UTC)[reply]
I don't really know what's going on above, but did we have a conclusion? The big dots look awful... Happymelon 11:12, 27 March 2009 (UTC)[reply]

Issue with {{Tnavbar-header}}

Resolved

See here; it involves the color of the view-talk-edit links produced by the template. – TMF 01:14, 6 March 2009 (UTC)[reply]

Move?

With the navbar now able to take pages in any namespace, we can now merge {{tnavbar}} and {{navbar}}. I've currently done that by redirecting navbar here, but I wonder if it would be clearer to move this template to Template:Navbar and protect the redirect from Template:Tnavbar. Thoughts? Happymelon 11:15, 27 March 2009 (UTC)[reply]

Such a move would have my support, but what would you do with the current history and talkpage of {{navbar}}? ダイノガイ?!」(Dinoguy1000) 02:04, 28 March 2009 (UTC)[reply]
I'm in favor of the move with a history merge (or making the navbar history that of the existing tnavbar). --CapitalR (talk) 05:47, 28 March 2009 (UTC)[reply]
Not really needed in my view. The template name has propagated to virtually every other project. And who is going to repair the thousands of links? (Well, I guess a bot could...) EdokterTalk 15:45, 28 March 2009 (UTC)[reply]
What other projects are doing really shouldn't be controlling our own actions here, and I don't see why the links would need to be updated so urgently. Update the instances that are called from {{Navbox}} and company, and any others can be individually corrected by local editors over time. It's not like the {{tnavbar}} name is going to be reused by a different template. ダイノガイ?!」(Dinoguy1000) 17:38, 28 March 2009 (UTC)[reply]
The links wouldn't need to be fixed because they would never be broken; with a protected redirect at Template:Tnavbar there would be no need for a systematic replacement. Simply changing the link in {{navbox}} would tackle the vast majority of cases. Since the current version of {{tnavbar}} doesn't contain any material from the old {{navbar}}, I'd be inclined to simply delete the old history of that page; it's mostly me anyway :D. The talkpage can become an archive subpage. Just because it's not needed doesn't mean it shouldn't be done, Edokter; not every action has to be a solution to a problem. Happymelon 14:54, 2 April 2009 (UTC)[reply]
Well, I won't oppose it, I just think it's unnecessary. EdokterTalk 21:07, 2 April 2009 (UTC)[reply]

I did it, in the absence of any genuine dissent :D. Welcome to Template talk:Navbar! Happymelon 19:40, 19 April 2009 (UTC)[reply]

*looks around* Ooh, pretty new decor (not to mention, now the name makes sense *without* having to spend a couple seconds thinking about it)! =D ダイノガイ?!」(Dinoguy1000) 19:38, 21 April 2009 (UTC)[reply]


I imported some pages with templates to another wiki, but the Navbar v,d,e links show up as Template:PAGENAME: World Heritage Sites in Peru|v instead of just "v" for example. The PAGENAME magic word works fine otherwise, just displays like this in Navbox Navbars. Any ideas how to fix this or what might be missing? —Preceding unsigned comment added by 201.240.150.236 (talk) 19:51, 18 May 2009 (UTC)[reply]

Your wiki is not running a recent-enough version of MediaWiki to have the {{PAGENAME:pagetitle}} parser function; the wiki needs to be running r46662, or version 1.15, in order for this feature to work correctly. Happymelon 20:12, 18 May 2009 (UTC)[reply]

Transclusion count?

I'm getting tired of seeing this being changed to 3,000,000+ only to be reverted back to 800,000. Wikipedia:Database reports/Templates with the most transclusions (last updated June 22) explicitly shows Navbar as being transcluded onto almost 3.3 million pages, so why is it inaccurate? If it's because Special:MostLinkedTemplates shows the much lower figure of 800,000, I'd like to point out that it was last updated on September 16, 2008. ダイノガイ千?!? · Talk⇒Dinoguy1000 20:22, 30 June 2009 (UTC) [reply]

Would you like to revert Edokter's last edit? -- WOSlinker (talk) 20:29, 30 June 2009 (UTC)[reply]