This is an archive of past discussions about Template:Infobox. 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.
This edit request to Module:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
this is not an image
A caption
A caption
A caption
@Edokter and Redrose64: Is there a safe way to make these examples have the same spacing between the image and the caption? perhaps by using div instead of br for the caption? thank you. Frietjes (talk) 15:10, 2 May 2014 (UTC)
looks like that works, even in the case where the image field is abused to include non-images. thank you. can we sync the live module with the sandbox? Frietjes (talk) 16:26, 2 May 2014 (UTC)
This edit request to Module:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hi please could you this to image and image 1 and image 2 and image3
image1style
Image2style
image3style
So that it can change the background colour for the different images instead of having all the images having background colour. 5.66.153.135 (talk) 13:24, 2 June 2014 (UTC)
I've been working on adding medical translations to a number of smaller Wikis.
I'm not really sure what I've been doing wrong. Is there any simple way to add a large number of templates and modules to a wiki?
Examples of articles with non-working infobox templates:
The normal way of adding multiple pages is by using Special:Import to import an XML file generated with Special:Export. However, you generally need to be an admin to use Special:Import. See mw:Manual:Importing XML dumps for the manual entry. In your first example, the module Module:HtmlBuilder isn't present on the wiki, and the infobox module generates an error when it doesn't find it. You can fix that error by copying the HtmlBuilder module across. For your second example, the wiki is missing the custom CSS that is defined in MediaWiki:Common.css. For now, the fix is to add the relevant CSS to the wiki's MediaWiki:Common.css, but again, this requires admin privileges. In the future individual templates may be able to define their own CSS rules, which will make this kind of thing much simpler, but currently the only choices are inline styling versus Common.css. See mw:Help:Cascading style sheets for general information about CSS in MediaWiki. Hope this helps. — Mr. Stradivarius♪ talk ♪04:28, 17 June 2014 (UTC)
Thanks, that helps a whole lot. For the first one, as you say it present that script error. The problem is that I have imported ti:Module:HtmlBuilder, and I'm still getting the errors. Is there something else wrong? -- CFCF (talk · contribs · email) 07:46, 17 June 2014 (UTC)
@Czarkoff: What happens if someone uses two instances of the same infobox on one page? Or the ID matches a section heading? OTOH, why not use parameter names as IDs, for every param? So that if, say, |website= exists, we can (with confidence) link to [[example#website]]? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:32, 19 June 2014 (UTC)
As you may see from jquery.makeCollapsible, my particular problem would not be solved with your scheme for IDs. It is pretty easy to avoid ID collisions in infobox, but adding the checks to the module code will needlessly impact performance. FWIW setting IDs to parameter fields' names would increase the rate of ID collisions.
I never thought of several infoboxes on a page. This is a problem, and I'll work on solution. But I am pretty sure such solution does not belong to this template or lua module behind it.
When I add an image, it has left and right margins different (~2×2px more white) from other elements like header, label+data and datatable. What is the background for this, and can I undo/prevent that effect? Demo at User:DePiep/sandbox10 (this version). -DePiep (talk) 10:55, 12 July 2014 (UTC)
re you all: thx for checking. Will provide screenshot, but right now I have a slow browser - txt only. I promise a cache clean &tc. (For now, if this helps: the centered picture shows ~4px smaller that the headers. By "white" I meant to say bg-color, or transparent - usually white-ish). -DePiep (talk) 20:24, 12 July 2014 (UTC)
Wait a second: you are talking about margin with background color as elsewhere in infobox (simply difference in margins between image and other content) or padding around image that is of some different color? — Dmitrij D. Czarkoff (talk•track) 20:42, 12 July 2014 (UTC)
re czarkoff: yes. The picture is smaller than the (colored) header bar, the rest is bg/transparent/white. As said, browser/connection is slow so I cannot provide printscreen now. (Ff atop WP:XP; can't even open Safari). -DePiep (talk) 21:19, 12 July 2014 (UTC)
No it did not (did cache clean). And to be honest, this is not the route I'm looking for. I'm more interested in an explanation. Then a solution can follow. -DePiep (talk) 23:18, 12 July 2014 (UTC)
Explanation: the table which is infobox has "width:22em;" in its attribute "style", which is hardcoded in Module:Infobox. As your image is smaller then 22 em in width, it is padded with whitespace. Interestingly, when I set padding of the cell containing image to 0, the CSS values of table and this cell got into conflict, which was resolved by ignoring table width in WebKit and by ignoring padding in Firefox. — Dmitrij D. Czarkoff (talk•track) 23:56, 12 July 2014 (UTC)
How can I pass |all=yes to the automatically transcluded {{Italic title}} template? I thought |italic title=all might work, but it doesn't seem to. This is needed for titles containing parentheses, for instance The Afterman (Live Edition), which is otherwise incorrectly italicised. Cheers,—Ketil Trout (<><!) 21:31, 22 October 2014 (UTC)
Since Template:Infobox was Lua-ised, the previous limit of 99 data rows no longer applies. It was that limit which forced several of the more complicated infoboxes to use the "child" technique to gain 98 more rows. Perhaps those templates could be rewritten to use the significantly greater number of rows that are now permitted, so eliminating "child" usage. --Redrose64 (talk) 11:30, 30 September 2014 (UTC)
I met two infoboxes that apply style="padding-bottom:0.2em" for the infobox title: {{infobox book}}, {{infobox element}} (this last one uses <sub> texts, see gold). Both mention "almost touching the border-top of the infobox" as argument. If this is a bad thing that is occurring with regular font, shouldn't it be set in the core by default? Or, was this chosen in the infobox-design, and does it say: not true, not needed, you're mistaking? -DePiep (talk) 06:49, 31 October 2014 (UTC)
Inline styles should generally be avoided, unless there are some real layout problems. That said, the infobox table caption has no associated styling, so it may be worth looking into. But having seen these infoboxes, I see no immediate need to include the padding inline; "almost touching the info box" tells me this is just a case of "I don't like it, let me change it to suit my taste." I say they can be safely removed. In the mean time, I'll investigate if table captions should have some default padding, just as table cells. -- [[User:Edokter]] {{talk}}07:30, 31 October 2014 (UTC)
Protected edit request on 30 October 2014
This edit request to Template:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Can we implement a subtitle? Sometimes subheader would not be enough, especially when it should be a part of title. It would be useful in articles like Animal Farm, where book has a subtitle (which is also present as a subtitle on Wikidata):
Rather not, because we need a separate metadata for this, keeping this in the same entry has no sense from the technical point, besides not only books have subtitles. --Rezonansowy (talk | contribs) 22:58, 24 October 2014 (UTC)
If I'm correct, the question is to add a parameter (data element; full row) in the meta {{infobox}}. Possibly named |subtitle=. That would not require a delimiter. -DePiep (talk) 07:37, 25 October 2014 (UTC)
as pointed out, we already have |subheader= for putting a data row at the top, inside the box. there are ways to visually "fake" that this top header is outside the box using css, but it takes quite a bit of css. Frietjes (talk) 14:15, 25 October 2014 (UTC)
Could be useful in see Bagdad (splitting the local language data like that looks very bad to me). Of course, the meta {{infobox settlement}} could do this with |native_name=, (maybe by using <br/><span style="font-weight:normal;">{{{native_name}}}</span> in the title data), but that would introduce different infobox implementations (a diff between say {{infobox settlement}} and {{infobox country}}) for similar semantics 'subtitle'.
|subheading= is not (a) |subtitle=. Exactly the Baghdad example shows that the purpose and the semantic is different, and the effect is --consitently-- wrong. (That is, the local name should not be separated by |settlement_type=Capital city). Frietjes already pointed out that we should not need a <br/> to create a subtitle, even requiring css in editors input (not meta). -DePiep (talk) 15:20, 25 October 2014 (UTC)
Nobody has argued that |subheading=is a |subtitle=; but it is a suitable place to put a subtitle. Your "the local name should not be separated" assertion is just that, and merely an opinion. Note that native names are also not subtitles. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits19:01, 25 October 2014 (UTC)
You write: "but |subheading= is a suitable place to put a subtitle." - Not so, as in: the opposite is true. This way you are abusing their semantics, making them useless and resulting in an haphazard layout between infoboxes. Next, in "the local name should not be separated" you misquote me (any conclusion after that is idle). I wrote that it should not be separated by an unrelated subheader. And that would not be a personal opinion, but a sound requirement for a well designed metatemplate someone might want to create. -DePiep (talk) 20:00, 26 October 2014 (UTC)
"the local name should not be separated" was cut&paste from your post (emphasis added); a post in which the word "unrelated" does not appear. I may be idle [sic], but I'm not dishonest. Also, tone down your hyperbole. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits17:25, 27 October 2014 (UTC)
you probably want |subheaderstyle=font-style:italic; or |subheaderstyle=font-style:italic; font-weight:bold; there. Frietjes (talk) 14:17, 25 October 2014 (UTC)
First, the edit history does not look like this has been fleshed out, not even by one single editor: [1]. A 32,500 transc'd template should not be edited sandbox-wise. Also, this edit was not an outcome of this thread.
Then, the new |subtitle= is actually fed to the {infobox} parameter |subheader=, while setting the |subheaderstyle= with it. This blocks any development of {i'box book} wrt subheaders (you can use |subheader(n)= in infoboxes). All this confirms my earlier note that the semantics of subtitle and subheader(n) are not the same, and that the meta {infobox} shows that (good, consistently).
Now look how the subtitle of a book is presented in todays infobox: inside the box, separated by the border?! Quite devastating to note: this is not an answer to the original post here by Rezonansowy.
Further, this will only invite editors of individual book pages to construct an ad hoc subtitle (likely in |title=, using <br> and what not).
I will revert those recent changes (for being without consensus, and probably without being a solution at all), and add a new proposal to the sandbox of {{infobox book}}.
This blocks nothing, and AFAICT, you are not in a position to issue decrees as to what should be done wrt sandboxes (at least, not without citing policies). As for your use of "devastating", I suggest a sense of proportion may be useful. You might also like to read WP:DNRNC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits17:21, 27 October 2014 (UTC)
Topic 'subtitle' restart
Topic restart after deviation into different page.
For {{Infobox}} in general, I repeat the original post question for {{Infobox}}: "add |subtitle= to {{Infobox}}". It has specific semantics, see also d:Property:P392 (subtitle of a work). Using |subheader= has drawbacks that is might separate title and subtitle (with |above=, with infobox border, by style diversion). Also, given that a subtitle can exist for meta-infoboxes (that use this meta-meta), omission can lead to wrong usage of generic infobox setup, to CSS constructions, or even per-article solutions. -DePiep (talk) 06:36, 31 October 2014 (UTC)
Taking this lead from wikidata, "subtitle" can be applied to "works". This would make the next infoboxes, and more, candidate for using it: {{infobox book}} (32k transc's), {{infobox film}} (92k), {{infobox album}} (128k); together 250+k potential places. None of these has a |subtitle= parameter. It makes one wonder how a subtitle is presented today in there; sure it is a per article solution (omitting, into title, elsewhere in the infobox). I am leaving out more arbitrary "subtitles" like nicknames for buildings or institutes. -DePiep (talk) 08:44, 3 November 2014 (UTC)
Can someone make a style proposal for this parameter? I'd say 1. it uses titlestyle, and maybe 2. it is in small(er) font-size.-DePiep (talk) 08:44, 3 November 2014 (UTC)
I recall seeing a few difference infoboxes using css trick to make the title appear as if it were inside the infobox (User:RexxS may know where?). in any event, it might be useful to make this trick toggled by a parameter passed here, rather than having to remember to exact css. comments? Frietjes (talk) 18:35, 2 November 2014 (UTC)
probably something like editor A wants the title to be inside the box, and editor B objects to using |above= since it doesn't use the <caption>...</caption> for the table caption, so they compromise. perhaps there is something in the history of the templates I listed. not really sure. Frietjes (talk) 19:29, 3 November 2014 (UTC)
Probably a param that triggers a style. I never really got why the caption has always been unstyled. I guess it was an oversight. Even when unstyled, a (wikitable) caption should have the same metrics as all other cells. -- [[User:Edokter]] {{talk}}20:13, 3 November 2014 (UTC)
The second demo provided here shows, to me, no difference between title and above. The above text would need a serious different styling to be dissociated. -DePiep (talk)
Hi. I am afraid I strongly oppose both the CSS hack and the idea to bring the title in. Being one of the top viewed web sites, many Wikipedia apps are developed to serve Wikipedia contents for various devices and environment (software and hardware). Hacks can break things.
As for in or out issue, it is both a matter of optional style and a color of the bike shed issue. Wasting server performance and development efforts on it is unwarranted. I myself prefer the title to be within the borders but upon encountering such issues my philosophy is: Get used to it! You won't know the difference after a while.
I concur. Including the "I don't like the title being outside, but I'll live with it". (Probably the horses-infoboxes editor met the same point, and solved it differently). That's better than introducing two styles. (it's three already: Flemington Racecourse). So far, I disagree with this idea as it introduces style deviations by personal preference only. -DePiep (talk) 21:55, 3 November 2014 (UTC)
Can I make unbolded text in the LH label?
In science, we can use unbolded text in the lefthand label text. For example: in the
ammonia infobox (old wikitable style); constructed:
I note that the unbold text is small. That may be an undesired effect, especially when writing scientific symbols and detailed sup/sub scripts. -DePiep (talk) 23:03, 29 September 2014 (UTC)
If you don't want it to be small, just use <span></span> instead of <small></small>.--Dudemanfellabra (talk)
I notice that the background for a header is shorter than for a title, by about 3px each end. Is that supposed to be like that? As an aside, I have nested infoboxes with identical headerstyles, yet the inner box header background is a different colour. See Pacijan - the second Geography header has a different colour background. Have I blundered or what? Is it in fact possible to specify headerstyle by row? (Which would obviate the need for an inner box.) The documentation is a bit light on styles and class generally. --Unbuttered parsnip (talk) mytime= Thu 09:37, wikitime= 01:37, 20 November 2014 (UTC)
It's not a design aim to have mis-aligned headers; it's just the best we could do using tables. I plan to overhaul the CSS for infobox sometimes in the future. -- [[User:Edokter]] {{talk}}08:28, 20 November 2014 (UTC)
Rendering issue
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I've been following that VPT thread from the start. I see no clear indication of a solution which will not break other uses. Therefore, Not done: please establish a consensus for this alteration before using the {{edit protected}} template. --Redrose64 (talk) 22:43, 20 November 2014 (UTC)
The first few lines erroneously describe Hoffman as a " antisemite and a holocaust denier" and "conspiracy theorist"...these are subjective terms misapplied and are attributed
to Jewish Zionist/Orthodox publications and authors whose credibility is very limited. So it would be correct to say "some say Hoffman is antisemitic"etc....the attribution of 'antisemitism' is wholly by Jewish organizations which is not a credible, subjective source for quite obvious reasons. But then, Wikipedia isn't considered so either by reputable academics in all areas...is that how Wiki wants to be seen? As a partisan for Jewish extremism? IF so, then by all means, carry on...but I will say this: its not in Jewish or anyone elses interest to be seen as extremist, criminal partisans..
This edit request to Module:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
So this is for the module invoked by the template, not the template itself. The module's talk page redirects here though. It's also not the biggest deal...
If you're thinking of the page that is served to your browser, that doesn't get any of the module - it's parsed right through to HTML before being served. --Redrose64 (talk) 20:07, 12 January 2015 (UTC)
Yes, but the module is parsed on the servers, and converted to HTML there, so the use of tabs instead of spaces will not make any difference to the HTML that is served to the client browser. --Redrose64 (talk) 21:01, 12 January 2015 (UTC)
Protected edit request on 30 October 2014 (2)
This edit request to Module:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The change made by Mr. Stradivarius to upgrade to mw.html is great, but it broke a hack that has been used to get individual rowstyles by overloading the rowclass parameter. luckily, these hacks have been tracked since they use the {{rowstyle}} template. to fix the issue, please make this change. note that the sandbox also has cellspacing=3 removed, which answers the edit request above as well. thank you. Frietjes (talk) 16:14, 30 October 2014 (UTC)
@Frietjes: I notice that the rowstyle(n) parameter is not yet documented. Is it being used in any of the templates listed above yet? Have labelstyle(n) and datastyle(n) parameters been considered? — Martin (MSGJ · talk) 22:05, 21 January 2015 (UTC)
Whitespace on top
To my eye, this seems a bit odd. See the top of page samarium with its infobox. The whitespace diff above the lede text vs. above the infobox title do not seem to be the same. The top lines are invisible, but it looks as thought they are different. I'd expect the same top-line-of-whatever. -DePiep (talk) 22:46, 6 February 2015 (UTC)
DePiep, was caused by this change by User:Edokter. I believe the intent was to increase the spacing at the bottom of the title. if so, this could be addressed by changing the 'padding:0.2em' to 'padding-bottom:0.2em' in common.css. Frietjes (talk) 16:01, 7 February 2015 (UTC)
Not just the bottom; the intent was to make the table caption metric-compatible with all other table cells. I notice the infobox has a top margin which could be decreased or removed. -- [[User:Edokter]] {{talk}}16:27, 7 February 2015 (UTC)
That would be an "and also change margin-top", then? Since the box does not have a visible border-top, the title is in "open" article-body space. To the eye, it is outside of the box. Then text-handling design should have the lead in this (not infobox-rectangles), especially vertical whitespace in typography (still did not find the right Category:Typography word for this. Top-of-X-line?). -DePiep (talk) 21:06, 7 February 2015 (UTC)
Just relized not every infobox has a caption, and without a top-margin, the infobox will stick to amboxes. Since the the 0.2em added padding usually results in 1 or 2 pixels of space, is this really an issue? -- [[User:Edokter]] {{talk}}11:54, 9 February 2015 (UTC)
The issue is typographic: the eye sees the 'just 1 or 2px' step (stairs) that appears between LH lede and RH infobox title (eg. in the 'top of X line'). Of course we don't want glued boxes. DePiep (talk) 20:26, 10 February 2015 (UTC)
Protected edit request on 7 February 2015
This edit request to Module:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
either change
if args.child == 'yes' and args.title then
to
if args.child == 'yes' and mw.title.getCurrentTitle().namespace == 0 and args.title then
or change
root:wikitext('[[Category:Articles which use embedded infobox templates with the title parameter]]')
to
root:wikitext('[[Category:Pages which use embedded infobox templates with the title parameter]]')
in other words, either restrict the tracking to articles only, or change the name of the category to indicate its more than just articles. Frietjes (talk) 15:55, 7 February 2015 (UTC)
I wasted time following the instructions in the "Embedding" section only to discover later that Template:Infobox NRHP has its own "embed" field that does a much better job at what I was trying to do. How widespread is the "embed" field? Would it make sense to mention in the "Embedding" doc that some templates know how to embed themselves, and to check the embedded template doc first? Kendall-K1 (talk) 13:19, 21 March 2015 (UTC)
Protected edit request on 6 April 2015
This edit request to Template:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I've made some changes in the sandbox, so that the navbar is called directly from the module rather than via the template (as per the method used by Module:Navbox). See the diff for details. Does anyone have any comments? If not then I'll deploy the change to live. -- WOSlinker (talk) 11:59, 15 April 2015 (UTC)
Sounds like a very good idea. You also reminded me that I rewrote the module so that we didn't need the preprocessArgs hacks, so I merged your changes with mine in the sandbox. My changes are a lot more extensive than yours, though, so they could probably do with some review. I changed the args table so that when you index it, rather than getting the expanded argument straight away, you get a callback function. This means that we can wait until the very last minute to expand the argument; and in turn, that means that we can generate the rows by running a loop in which we run the row-generating code, find out whether we generated any content, and stop looping if we didn't. In practice there are sometimes gaps between numbered rows, so I set the module to stop looping when 10 sequential rows don't generate any content. (And I set it to 2 sequential rows for subheaders, and 3 for images.) — Mr. Stradivarius♪ talk ♪12:41, 15 April 2015 (UTC)
Hmm, good point. Let's shelve my changes for the moment, then. To get the loop right we'd need to expand the label parameters, but the whole point of delaying argument expansion is so that we don't expand label parameters when the data parameters don't contain any content. Perhaps we could differentiate between blank data parameters and missing data parameters, but that will require some more thought. Let's make the easier change first. — Mr. Stradivarius♪ talk ♪13:05, 15 April 2015 (UTC)
_talkpage_issue_illustration.png)
