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.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
No, overlinking and rarely useful. However, it would be helpful for you to clarify whether this RfC is intended to apply to only that particular infobox, in which case suggest holding this RfC at its talk page instead, or whether it is meant to cover all infoboxes. Nikkimaria (talk) 11:47, 22 April 2019 (UTC)
No. This should be left to our usual guidance at MOS:OVERLINK, in particular the three bullet points beneath The names of subjects with which most readers will be at least somewhat familiar: which indicate that major examples of geographic features, locations, languages, nationalities, ethnicities and religions should not be linked. There may be exceptions for little-known languages or places that most readers are unlikely to be familiar with. It is a mistake to ask a question like this as an RfC when we already have good guidance that is far more nuanced. I suggest it should be withdrawn. --RexxS (talk) 14:05, 22 April 2019 (UTC)
NoWP:OVERLINK is our guidance here. If the nation is commonly known, such as Germany or the United States, there's no reason to link it. Similarly German and English do not need to be linked either. @Izno:, this is about this and the editor's 72-hour block for edit warring for ignoring the guideline and misapplying WP:BRD. Walter Görlitz (talk) 14:15, 22 April 2019 (UTC)
Ah. Well, I'm going to boldy de-list this RFC. An RFC is not appropriate in this situation at this time. Discussion should be on Talk:Jersey Beat and/or the talk page of the "Brigitte" article about whether to apply the guideline as appropriate. --Izno (talk) 14:22, 22 April 2019 (UTC)
I tend to agree. An RfC should only be started after a discussion on the subject and that has not happened here or on the talk pages of the articles. Discussion could create a local consensus to override the guideline, but the exception would be likely to change quickly if that discussion were not made sufficiently public. Walter Görlitz (talk) 15:08, 22 April 2019 (UTC)
Doesn't the WP:CONLOCAL policy make it clear that "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale"? Consensus at the level of an article doesn't seem to me anything like strong enough to provide exceptions to a guideline that's as been as thoroughly debated as MOS:OVERLINK. --RexxS (talk) 15:53, 22 April 2019 (UTC)
I think the part I've heard argued before is to invoke "unless they can convince the broader community that such action is right" and make great efforts to make a compelling argument that they are actually right. I cannot see that being the case with linking either nation or language in these two infoboxes, or almost any other. It would be virtually impossible to make such a case with this. Walter Görlitz (talk) 16:55, 22 April 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Sub-header style documentation
The documentation for the template shows the subheaderstyle parameter in the syntax but makes no mention in the parameters list of how its used. Because of this, it is unclear if this one parameter sets the style for all sub-header cells or if you can modify the style for each individual cell, such as with subheaderstyle2 and subheaderstyle3. My current understanding is that subheaderstyle(n) can be used to modify the style for individual sub-header cells, but if there are no sunheaderstyle(n)'s, subheaderstyle is used by default for all sub-header cells. Shouldn't the documentation mention this? Rektroth00:01, 16 May 2019 (UTC)
Pre-RfC Question: Religion in infoboxes
This is an informal discussion to help me decide if an RfC is needed on this question.
In 2015 an RfC[1] decided "yes" on the question In infoboxes on articles about non-religious nations, religion should not be listed in the infobox, and the religion parameter should be removed.
If you read the entire RfC the main issue was (and continues to be) multiple editors on multiple pages that absolutely insist that the infobox of their favorite page must contain "religion=none", "religion=atheist," "religion=none official," "religion=secular state" despite the fact that there is no such religion as "none" or "atheism".
As the closing summary says, "The policy basis for this is that, to quote from JzG below, 'assuming that every country must have a religion, and that any country that does not have a religion must have a religion parameter saying it has none' is not neutral, as it begs the question. Therefore, the religion parameter is only to be included in this infobox if that nation's government has an official, definite state religion."
There is an ongoing RfC[2] at Talk:Australia about an infobox entry that lists the religious demographics of the nation. Australia has no official official, definite state religion, and so technically the current infobox (as well as the infobox for United States goes against the RfC decision, but I don't think the RfC really covers this usage.
So my main question is whether we should have entries in infoboxes with a long list of religions, ethnic groups, etc., or whether such information should stay in the body of the article. Do I need to post an RfC on this?
Related issue: Infoboxes are getting bigger and bigger. See United Kingdom as a good example. Editors keep wanting to add more information to them, to the point where they rival the article in size and detail. Are we going too far?: The usual argument for inclusion is something along the line of "this is so important that it MUST be in the infobox for those who can't be bothered to actually read the article. --Guy Macon (talk) 23:48, 29 June 2019 (UTC)
I would oppose the inclusion of any sort of religion field for a geographical location except perhaps in such cases where there was a state-sanctioned religion. DonIago (talk) 17:15, 1 July 2019 (UTC)
Count me for opposing inclusion. This idea that all bits of info (trivial and otherwise) should be jammed into the infobox and the resulting bloat is, at best, misguided. Reading the article should be encouraged. The UK article that Guy Macon linked to is (apologies for the WP:POV wording) appalling. Demonym, date format, internet TLD etc are IMO the definition of WP:INDISCRIMINATE information. The inclusion of "driving side" is hard to fathom as the info is of no use to a reader. WP:NOTTRAVEL applies to that item. In fact in its current form these infoboxes hit almost everything in Wikipedia:What Wikipedia is not#Wikipedia is not a manual, guidebook, textbook, or scientific journal. Pruning items would be a benefit over adding more fields. MarnetteD|Talk17:49, 1 July 2019 (UTC)
Clearly there will be strong opposition from those who think that the infobox should pretty much duplicate the article, so I think I need to post an RfC. So, what should the exact wording of the RfC question be? Would "Unless there is a good reason to do otherwise, an infobox should contain no more than [10? 15? 20?] entries, and single entries that consist of lists of items should be avoided. Most information should be in the body of the article, not the infobox." be too bold? --Guy Macon (talk) 22:23, 1 July 2019 (UTC)
I think that would be too bold, Guy, although you'd be right in general. It isn't a good idea to become prescriptive about things like number of entries; rather we should be descriptive of best practice. Most of the time, it's going to be best to keep the number of entries down to just key facts, but exceptions are valid – just take a look at the Featured Article Helium: I count 43 entries in the infobox, so who is going to tell the folks who steward that article which 23/28/33 entries are going to be removed? My inclination would be to try to get consensus for a form of words that encouraged trimming infoboxes to an agreed core of valuable information on a topic-by-topic basis. You'll probably want to survey a range of infoboxes, and solicit input from WikiProjects on the scope of the RfC. --RexxS (talk) 00:33, 2 July 2019 (UTC)
The Helium infobox contains far too many entries, many of which are not found anywhere in the article. It should have a template for physical properties instead of cramming an entire article into an infobox.
"When considering any aspect of infobox design, keep in mind the purpose of an infobox: to summarize (and not supplant) key facts that appear in the article The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance." --MOS:INFOBOXPURPOSE
That being said, I clearly am not going to be able to change that, so let me go back to the original issue. Below is my second attempt with a much narrower scope: --Guy Macon (talk) 03:43, 2 July 2019 (UTC)
Proposed RfC question:
In all infoboxes in all articles, without exception, non-religions may not be listed in the " religion = " parameter.
Comment (this is probably too much for an RfC, but I want everyone reading to understand what I am talking about): This would forbid the following:
Religion = Atheist/Atheism
Religion = Agnostic/Agnosticism
Religion = Nontheist/Nontheism
Religion = Nonbeliever/Nonbelief/Nonreligious
Religion = Nonbeliever/Nonbelief
Religion = Antireligionist/Antireligionism
Religion = Antireligion/Irreligionist
Religion = Irreligionism/Irreligion
Religion = Ignosticist/Ignosticism
Religion = Apatheist/Apatheism
Religion = No apparent religion/No known religion/Unknown
Religion = N/A or NA
Religion = Raised [religion X] (in cases where the person currently has no religion)
Religion = Former [religion X] (in cases where the person currently has no religion)
Religion = Secularist/Secularism/Secular
Religion = Nondenominational ("Nondenominational Christian" is a religion and thus would be allowed)
Religion = Nonsectarian
Religion = Nonpracticing [religion X]
Religion = Nonreligious [religion X]
Religion = [religion X] Atheist/Atheism (in particular, Jewish Atheism is not a religion. "Jewish" can refer to a religion, a nationality, an ethnicity, or a culture.)
Reason: Atheism is not a religion. Atheism is the lack of any religion. Bald is not a hair color. Bald is the lack of any hair color. Off is not a TV channel. Off is the lack of any TV channel. Barefoot is not a shoe. Barefoot is the lack of any shoe. Silence is not a sound. Silence is the lack of any sound. Never is not a date. Never is the lack of a date. Clear is not a color. Clear is the lack of a color. Not collecting stamps is not a hobby. Not collecting stamps is the lack of a hobby. --Guy Macon (talk) 03:43, 2 July 2019 (UTC)
Hi, Guy, I've only just found this section and need to go get ready for work. In the back of my mind, I was thinking of a different question for RFC at say Template talk:Infobox Country, along the lines of "does demographic information (such as Ethnic Groups and Religions) belong in country infoboxes". (Was also plannng to summarize/comment on the religion discussions at the Australia RFC.) I hope to return later with some more considered input. (Might need to refactor this post to a different location in the thread after I read the section more closely.) —Pelagic (talk) 21:33, 11 July 2019 (UTC)
Guy, I'm going to disagree with your expended explanation. While Bald is not a hair color, it does answer the question "What type of hair does person A have". So if the infobox field did have a "Hair", one could legitimately understand it as that. So in a similar situation, the religion field is not a "Pick a religion from the list" but also a "What religious beliefs do this person have?" with an answer of "He doesn't, he is an Atheist" a valid answer. As the infobox, like you've said above, should summarize and be short, having a "Religion: Atheist" is valid in my opinion. All that being said, I'd much prefer infoboxes without parameters that can cause edit-wars.
Ok, found the issue. The documentation at Template:Italic title wasn't as clear as I thought. For italics to work in the parenthesis you need to pass both |string= and |all=yes. Got the code to work, now I'll test it out and see that everything that used to work still works. --Gonnym (talk) 20:27, 23 May 2019 (UTC)
Nice work. I hope I helped. My trick in solving these problems is the same as the one that Joe Moore uses in the David Mamet film Heist:
D.A. Freccia: You're a pretty smart fella. Joe Moore: Ah, not that smart. D.A. Freccia: If you're not that smart, how'd you figure it out? Joe Moore: I tried to imagine a fella smarter than myself. Then I tried to think, "what would he do?"
I couldn't get Special:ExpandTemplates to show me how it processed the Italic title template, but creating the sandbox user-space did help minimize noise. And that's a great quote!
I've tested all combinations in my user-space and everything seems to be working. Would love if someone could verify that nothing breaks. I've documented the code, but to sum it up:
The previous parameter |italic title=, accepts, as before, an empty string (|italic title=), |italic title=force or |italic title=yes to italicize a title, it now also accepts |italic title=no to not italicize it and |italic title=all to italicize a complete name including parenthesis (whether disambiguation or part of the title).
A new parameter |italic_string= which can be any part of the page's title. When the part in the parenthesis is the part that you want to italicize then |italic title=all is also needed. --Gonnym (talk) 21:19, 23 May 2019 (UTC)
I've noticed that some infoboxes end up becoming too wide if a long url is included as the website name. Could a default max-width and wrap be introduced (I guess with a manual override option for if it's really necessary). T.Shafee(Evo&Evo)talk06:27, 12 July 2019 (UTC)
Template-protected edit request on 4 December 2019
This edit request to Template:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Change
the other puts as a caption it on top of the table. You can use both of them together if you like, or just one or the other, or even neither (though this is not recommended):
To
the other puts it as a caption on top of the table. You can use them both together, or just one or the other, or neither (though this is not recommended):
Template-protected edit request 2 on 4 December 2019
This edit request to Template:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Change
will be added to the bottom of the infobox, pointing to the named page. You may use the value Infobox; however this is rarely what you want, because it will send users clicking these links in an infobox in an article to the template code rather than the data in the infobox that they probably want to change.
To
will be added to the bottom of the infobox pointing to the named page. You may use the value Infobox; however, this is rarely what you want because it will send users clicking these links in an infobox to the template code rather than the data in the infobox they probably want to change.
I managed to decode this. The suggestion is that Module:Infobox should be edited to replace the indents using spaces with indents using tabs, per style over the last couple of years. At least, it should be consistent. I agree with that but would not bother editing the module for such a style change. Johnuniq (talk) 22:41, 8 December 2019 (UTC)
I agree with John. There should be consistency, but the server load produced by an update that is effectively cosmetic would be disproportionate, considering the number of transclusions. Perhaps we can remember the job for the next time an essential update is made and sort out the tabs at the same time? --RexxS (talk) 01:01, 9 December 2019 (UTC)
Forcing italics
Would it be possible for | italic_title = force (or a new value of | italic_title = all) to add {{italic title|all=yes}} to the corresponding article so you don't have to manually add it below the infobox (example)? – Srdjan m (talk) 00:55, 13 January 2020 (UTC)
I'm pretty sure I fixed the bug that was previously in my code, but didn't want to sync it as it again got no code review. --Gonnym (talk) 06:28, 13 January 2020 (UTC)
I've created three sandbox pages to allow testing of titles:
Trying the five different example parameters in each one while creating the pages seemed to give me the expected results, so I'm happy that the italic title code in Template:Infobox/sandbox is working well enough. If anybody else has any edge cases, or wants to run the tests, that would be helpful to confirm the code. When we agree to sync the main from the sandbox, can we also incorporate the request above and standardise on tabs for indents? I think Johnuniq has a script that cleans up these modules quite well. --RexxS (talk) 16:30, 13 January 2020 (UTC)
The sandbox module code looks good to me; I tested it a bit. If I understand correctly, the edit request would be to replace the contents of Module:Infobox with the contents of Module:Infobox/sandbox. The implementing editor should leave Template:Infobox untouched. – Jonesey95 (talk) 18:40, 13 January 2020 (UTC)
I did a tiny edit to the sandbox to fix whitespace and checked that all other whitespace is good. I haven't quite understood what this is all about yet but it appears that an existing parameter (italic title) is having a new parameter (italic_string) to modify its behavior. Can't we do something about the inconsistency in that one parameter has a space and the other an underscore? My initial feeling would be to remove the space name from the documentation, replacing it with italic_title, and get the module to alias the space name to the underscore name. Johnuniq (talk) 01:41, 14 January 2020 (UTC)
@Johnuniq: I think the main aim of the work that Gonnym did was to implement the full capabilities of Module:Italic title by loading (via the require function) its code into Infobox/sandbox, rather than expanding the template {{Italic title}}. At the same time, I assume that the idea was to move toward the style of using underscores in parameter names as this is now our preferred style. I'm sure we still need to keep |italic title= as an alias for |italic_title= for the foreseeable future. The standalone template {{Italic title}} allows part of the title to be italicised by passing a string, and that functionality is duplicated in Infobox/sandbox using the additional |italic_string= parameter. See the test pages for examples. --RexxS (talk) 03:17, 14 January 2020 (UTC)
@RexxS: I've had a chance to look at the code now and it is ready to go, and I've got a better understanding of the parameters, thanks. Presumably Template:Infobox/doc#Italic titles will be updated with the new parameter. Why not also use "italic_title" with underscore instead of space, in the documentation? The module would need a tweak to handle the parameter name however it's given. It's pretty awful to document one parameter with a space and another with an underscore. Johnuniq (talk) 03:45, 14 January 2020 (UTC)
It's pretty strange, I agree. The only positive of |italic title= is that it has the same name as the template that it calls, so people will probably try to use it that way. I think that we should document |italic_title= as the canonical parameter name, but support both forms. – Jonesey95 (talk) 04:01, 14 January 2020 (UTC)
I'd be in favor of deprecating |italic title= in favor of |italic_title=- that is, keeping for now the support for the space version, adding support for the underscore and replacing the space version with the underscore one in the /doc. Added commented out code to the sandbox that add this. If it's something we want, we just need to replace two lines with the two commented out ones. --Gonnym (talk) 05:11, 14 January 2020 (UTC)
As the test pages have been deleted as CSD-G2, I'll put their contents here to show what I've tested so far:
{{infobox/sandbox|italic title=yes}}
This is part of a small set of pages used for testing code that affects titles:
* [[Title sandbox]]
* [[Title (sandbox)]]
* [[Title, sandbox]]
For the {{tl|italic title}} and {{tl|infobox}} templates, the parameter values to test are:
* <code><nowiki>|italic title=yes</nowiki></code>
* <code><nowiki>|italic title=force</nowiki></code>
* <code><nowiki>|italic title=all</nowiki></code>
* <code><nowiki>italic title=all |italic_string=Title</nowiki></code>
* <code><nowiki>italic title=all |italic_string=sandbox</nowiki></code>
You can actually test by creating a page and previewing each test without saving. Oddly, the preview only shows the italicised title when creating a new page, not when amending an existing one. Cheers --RexxS (talk) 16:49, 14 January 2020 (UTC)
I tested by previewing on an existing page without trouble. For example, insert the following at Dohuk (disambiguation) and preview:
Thanks, John. I was clearly mistaken as that now works for me. I'm puzzled about what I was doing wrong to think it wasn't working before. Cheers --RexxS (talk) 00:55, 15 January 2020 (UTC)
Yes, examples would be helpful. Right now, there are only three articles on the Lint Error page linked above, and I don't think any of them would have their Lint errors fixed by this change. It seems more likely that we would end up with stripped tags. – Jonesey95 (talk) 12:57, 11 March 2020 (UTC)
Sorry, I don't have examples here! I've checked bnwiki and that was affected by the Module. That is why I am requesting you to change here too. Thanks! Warm Regards, ZI Jony(Talk)19:04, 11 March 2020 (UTC)
This morning, I noticed a display error in the article for H. M. Hoover in which a double space in the Infobox template rendered in my (Chrome) mobile browser. I "corrected" the local instance by deleting the second space in this edit. Returning to the old version of the page in my (Firefox) desktop browser, I see that this problem is not browser-specific. I suspect that all manner of spacing conventions exist across the spectrum of infobox template use, so either this was an odd corner case, a recently introduced bug, or my first time noticing an widespread problem. Apologies in advance if this issue is already documented; I'm a little short on time, but I thought it better to mention it than let it go. My appreciation to whomever can diagnose or troubleshoot or dispel my ignorance. Cheers —jameslucas▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄22:53, 23 March 2020 (UTC)
(edit conflict) @JamesLucas: Confirmed, using a Unicode code converter in the Opera browser. At the old version, the line in question is revealed to be
| death_place =  [[Locust Grove, Orange County, Virginia|Locust Grove, Virginia]], United States
Some infoboxes (e.g. {{Infobox historic site}}), but not all of them, are wrapped in <includeonly> tag. I don't know what the reason behind this is. Are there any technical advantages? Thank you. Ahmadtalk00:10, 9 May 2020 (UTC)
@Ahmad252: It just stops the raw output of the template without parameters being shown on the template page itself. If you look at Template:Infobox person, for example, you'll see at the top right of the page the small almost content-less infobox titled "Infobox person". That wouldn't occur if the template were enclosed in <includeonly>...</includeonly>. Some templates would look much more of a mess than that, so the tags are generally used on them. Cheers --RexxS (talk) 00:44, 9 May 2020 (UTC)
Thank you. So, if I'm not mistaken, it should only be used on those templates with one or more non-optional |data= inputs ({{{1}}}; not {{{1|}}}). Ahmadtalk04:45, 9 May 2020 (UTC)
I don't think it really falls into any sort of "only" dichotomy; if an infobox is designed to show the entire thing pre-documentation, then it makes more sense to have it shown, but if (as in most cases) only a header or two shows up, there's not much point in showing it (but it also doesn't take up a lot of real estate, so it's not a huge deal). I certainly wouldn't go around putting <noinclude> tags around every infobox with AWB or a bot or anything, as it would be a waste of time and effort. Primefac (talk) 19:26, 9 May 2020 (UTC)
Added tracking
I have added tracking for ignored data cells with Category:Pages which use infobox templates with ignored data cells which happens when there is say |header2=foo and |data2=bar. in this case, only |header2=foo shows and |data2=bar is silently ignored. we can either (a) continue to silently ignore this issue, (b) add a tracking category but otherwise silently ignore, (c) issue a visible warning, or (d) show both with the header over the data (which is what {{sidebar}} does). once we know how widespread this issue is, we can safely make changes to the visible output. let me know if this tracking broke something. Frietjes (talk) 14:41, 13 May 2020 (UTC)
Good idea. On a related note, there has to be a better system other than this awful numbering system. Adding a new field at the top of the list requires an unnecessary huge amount of work. --Gonnym (talk) 15:28, 13 May 2020 (UTC)
Gonnym, not sure how to make that work without having an individual module call for each row. I believe there are several people using User:Frietjes/infoboxgap.js which provides two buttons in your toolbox: "Infobox gap" which creates a numbering gap and "Infobox renumber" which removes gaps. it, currently, works best if there is only one infobox on the page, but shouldn't do anything too crazy if there isn't. Frietjes (talk) 15:54, 13 May 2020 (UTC)
@Frietjes: When I previewed the article, everything was fine. But when I saved it, the artist and the music video header disappeared. Your edit to the module was made at 19:13, at the same minute as I pressed "save". It's no coincidence, I'm sure. --Moscow Connection (talk) 19:47, 13 May 2020 (UTC)
Hello. I'm not sure if this is an easy fix or a change that would be controversial, but is it possible to tweak the code in such a way that the label also ignores values that are non-text/does not have a value displaying? I've hit an obstacle at Module talk:WikidataIB#Feature request (the comment from User:RexxS today, 13th), and wondering if it is something that can be fixed here. Any help or guidance is welcomed. Thanks, Rehman12:51, 13 May 2020 (UTC)
I'm not that versed with this module to say exactly. But in essence, I want the category to be applied to the article (inside or outside doesn't really matter, as long as the article is categorised), but the label to be suppressed since the data cell would anyway look blank. Does this make sense? Rehman14:49, 13 May 2020 (UTC)
Rehman, okay. this would require using string parsing on all the data input rows, which could be intense, but we are already string processing all the data and header rows for the "fix child boxes" feature. I will see if anyone has any objections before working on it further. Frietjes (talk) 15:02, 13 May 2020 (UTC)
@Rehman and Frietjes: I hope that the following might do the trick:
fork,numinipairs(rownums)do-- blank label if data value is just a categorylocallvallocaldval=args['data'..tostring(num)]ifdvalanddval:gsub('%[%[Category:[^]]*]]',''):match('%S')thenlval=args['label'..tostring(num)]endaddRow({header=args['header'..tostring(num)],label=lval,data=dval,datastyle=args.datastyle,class=args['class'..tostring(num)],rowclass=args['rowclass'..tostring(num)],rowstyle=args['rowstyle'..tostring(num)],rowcellstyle=args['rowcellstyle'..tostring(num)],dataid=args['dataid'..tostring(num)],labelid=args['labelid'..tostring(num)],headerid=args['headerid'..tostring(num)],rowid=args['rowid'..tostring(num)]})end
Currently in Module:Infobox/sandbox. Checks if the data value is nothing more than a category; if so removes the label. It leaves a blank row in the infobox, but it has almost no height. This page is in the category as you can check at the bottom of the page. --RexxS (talk) 17:28, 13 May 2020 (UTC)
RexxS, another method would be to append display:none to the rowcellstyle (or set it to equal display:none), which would effectively eliminate the gap between the rows. this is what we do in the fixChildBoxes function at the top of the module code. Frietjes (talk) 18:39, 13 May 2020 (UTC)
Thanks for that, Frietjes. I saw that en passant, but wasn't certain whether display:none would suppress the placing of the page in the tracking category, so I went for the straightforward hack. A quick test now shows me that display:none still allows the categorisation to happen, so that's a good solution. Cheers --RexxS (talk) 19:06, 13 May 2020 (UTC)
This is because display:none is actioned by the client, long after the cat has been processed by the parser. --Redrose64 🌹 (talk) 19:10, 13 May 2020 (UTC)
great, now implemented. in the worst case, that the client doesn't correctly act on the display:none, you will just get what we had before (an empty data cell). Frietjes (talk) 19:15, 13 May 2020 (UTC)
Thanks, Redrose64, I should have realised that. Nice work, Frietjes; that will make Rehman happy. It's a valuable step forward in improving the workflow for allowing infobox templates to draw information from Wikidata. It now allows a template coder to create a Wikidata-aware infobox that doesn't display any Wikidata by default, but just puts the article into a tracking category of choice. The contents of the category can then be checked one article at a time and Wikidata-enabled for that article only after checking ("opt-in"). Once everyone is happy with the checking, these tracking categories can be removed at the template level. Cheers --RexxS (talk) 19:44, 13 May 2020 (UTC)
Lua error in Module:Infobox at line 338: attempt to index upvalue 'origArgs' (a nil value).
Backtrace:
Module:Infobox:338: in function "preprocessSingleArg"
Module:Infobox:406: in function "parseDataParameters"
Module:Infobox:461: ?
(tail call): ?
mw.lua:518: ?
[C]: ?
I don’t know how this module works, so I don’t want to make guesses what’s wrong with it, but something certainly is. —Tacsipacsi (talk) 22:45, 16 May 2020 (UTC)
I'm designing an infobox and I'd like to have a parameter that allows it to be aligned to the left of the page. Is there any way to do this within {{Infobox}}, or do I have to wrap {{Infobox}} in {{Align}} (which feels rather clunky)? {{u|Sdkb}}talk07:31, 17 August 2020 (UTC)
Frietjes and WOSlinker, thanks both. To clarify, I'm designing the infobox itself ({{US college admissions}}) and trying to code a |float= parameter, not implementing an existing infobox. I should be able to figure out how to go off of what you provided above, but if there are other infoboxes that allow custom aligning, it might be helpful to see an example. {{u|Sdkb}}talk22:49, 28 August 2020 (UTC)
You'll want to set your param |float= so that in your infobox you have bodystyle = float:{{{float|right}}}; which will allow you to set a float of left but will default right. Primefac (talk) 22:52, 28 August 2020 (UTC)
Primefac, I ended up going with | bodystyle = float:{{{float|right}}}; clear:{{{float|right}}}; {{#ifeq:{{{float}}}|left|margin:0.5em 1em 0.5em 0;}}. It works, but it seems like a very hacky way to do it. I did find {{Float style}}, but it looks almost unused and tries to force top/bottom margins of zero, so if some other infoboxes have found a more elegant solution, I'm not aware of it. {{u|Sdkb}}talk03:25, 29 August 2020 (UTC)
I believe the point is to have it optionally float left based on a parameter. I'm not really sure why someone would want to have an infobox float left anyway, but I've stopped wondering about the ideas that happen in other editors' heads, as they do have reasons of some sort. Primefac (talk) 12:46, 29 August 2020 (UTC)
Setting the parameter as |float=floatright would enable |bodyclass={{{float|}}}}}, which would set multiple css styles in one go. Optionally, using TemplateStyles would allow any arbitrary combination of css styles to be defined and then called with a single parameter value. --RexxS (talk) 18:01, 29 August 2020 (UTC)
@Redrose64 and Sdkb: No, I meant you pass the name of the class you want through the |float=, like this: |float=floatleft or |float=myfloatclass or whatever class name you want. If there's an already-defined one that does the job you want, you use that. If not, you make an entry in the template's templatestyles.css to define myfloatclass or whatever, and pass tha name through the parameter. Then if your infobox template has |bodyclass={{{float|}}}}}, it will use the class you picked. It's pointless to use an inflexible value for |float= like "right" because you have to test for it and then supply the name of the class you want, when you can simply pass the name of the class as the parameter value. --RexxS (talk) 00:57, 30 August 2020 (UTC)
What's happened to all the infoboxes?
I've just been browsing the site in the past 30 minutes, and all the infoboxes have suddenly changed - they all seem to be aligned left now, and are looking very strange. Does anyone know what's up? Thank you! LeoC12 (talk) 14:41, 9 September 2020 (UTC)
Raymie, looks like this was tried in the sandbox but never added to the main code, and the next time the sandbox was synced, the test was broken. the discussion was here, and I didn't see any objections to the proposed code. there was just not enough energy to push it through. Frietjes (talk) 00:33, 12 September 2020 (UTC)
@Frietjes: Thanks for the reply. Is it possible to add the latter feature (individual header styles)? Was hoping to define a style for one specific header to be used when embedding other infoboxes in a project I'm working on. Since it seems to be from 2013 it's OK if the code has changed too much since then to implement. Raymie (t • c) 01:40, 12 September 2020 (UTC)
Raymie, there is a more generic parameter called |rowcellstyleX= which allows you to style the cells in a particular row. see the example posted here. Frietjes (talk) 13:13, 14 September 2020 (UTC)
Thanks for letting me know about rowcellstyle. That should be able to handle what I was intending: a custom header to accompany embeds. Raymie (t • c) 15:45, 14 September 2020 (UTC)
