This page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style
This page may fall under the contentious topics procedure and be given additional attention, as it may be closely associated to the article titles policy and capitalisation. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
This page is within the scope of WikiProject Templates, a group dedicated to improving the maintenance of Wikipedia's templates. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TemplatesWikipedia:WikiProject TemplatesTemplate:WikiProject TemplatesTemplates
This page is within the scope of WikiProject Infoboxes, a collaborative effort to improve the coverage of Infoboxes on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InfoboxesWikipedia:WikiProject InfoboxesTemplate:WikiProject InfoboxesInfoboxes
This page has archives. Sections older than 365 days may be auto-archived by Lowercase sigmabot III if there are more than 5.
Consistency among office holders
If a numbering is removed from an office holder's infobox. Should it be removed from that individuals' predecessors & successors' infoboxes? GoodDay (talk) 15:07, 12 October 2024 (UTC)[reply]
Or to put it another way, should you have added numbering to one office in one article[1], slow-editwarred to keep your insertion on the grounds of consistency[2][3], requested page protection to keep your addition[4] and then come here to seek a general ruling that reverting your addition requires comprehensive removal in other articles?
And are you proposing that in the name of Consistency among office holders we should number other offices in that article, and in articles about those holding other offices in that country, and in articles about vice-presidents in other countries? NebY (talk) 16:01, 12 October 2024 (UTC)[reply]
Numbering should only be added if "there is a well-established use of such numbering in reliable sources." Otherwise, don't add it. DrKay (talk) 17:16, 12 October 2024 (UTC)[reply]
@NebY: don't bite my head off, please. If the other editor isn't going to make the effort to delete the numbering from the related bios? Then neither will I. GoodDay (talk) 00:40, 13 October 2024 (UTC)[reply]
"end of the lead section of an article (in the mobile version)"
Is there a reason behind the current first sentence stating infoboxes appear at the "end of the lead section of an article (in the mobile version)"? Whenever I've looked at a mobile version infoboxes appear after the first paragraph, which could be in the middle or even towards the start of a lead section. CMD (talk) 17:31, 16 October 2024 (UTC)[reply]
Why does the 'coordinates' paramater yield duplicate coordinates?
At articles like Assassination of John F. Kennedy, the coordinates parameter causes coordinates to be presented at the top right of the page and also in the infobox. Why do we need it to appear twice? Also, are coordinates even useful? What percent of readers even know how to interpret them? If there is already a map feature, are coordinates even needed at all, let alone twice? ~ HAL333(VOTE!)16:19, 23 October 2024 (UTC)[reply]
It's not the coordinates parameter itself causing that, it's the actual {{coord}} template - if you changed |display=inline,title to have only one value it would display coordinates in only one place. As to whether it should be displayed at all, that's probably a question for a Village Pump rather than here. Nikkimaria (talk) 04:59, 24 October 2024 (UTC)[reply]
What is the optimal method for determining the maximum width of an image or group of images (such as a national flag and coat of arms together) within the infobox that sets the overall width of the infobox? SilverBullet X (talk) 16:34, 25 October 2024 (UTC)[reply]
On Donald Trump, there has been a discussion on applying MOS:INFOBOXPURPOSE in the discussion Parents, children, and spouses links in the infobox. After reading that the infobox's purpose is "allowing readers to identify key facts at a glance" we moved to exclude Relatives: Trump family and potentially Awards: Full list. After reading the talk page here however, it doesn't seem like this natural reading has consensus, and editors have repeatedly argued above that links to these pages constitute "key facts". I couldn't quite gauge the consensus as the page didn't appear to change in light of the discussion and the INFOBOXPURPOSE still naturally reads as having the opposite meaning. Can this language be clarified to better reflect what editors perhaps believe? Rollinginhisgrave (talk) 08:28, 12 November 2024 (UTC)[reply]
We should get together and get some sort of consensus about file spam in infoboxes like at cities New York city (17 files) is an accessibility nightmare and I'm not sure how anyone would think this amount of files for three paragraphs is reasonable. Moxy🍁 02:42, 26 November 2024 (UTC)[reply]
Perhaps I should be more clear..... files as in images. Scrolling nightmare of little mini images is deterrent for readers. I've seen many debates where those who love lots of teeny images in conflict with those who want an academic look and care about accessibility of content.Moxy🍁 03:12, 26 November 2024 (UTC)[reply]
I would see that they violate WP:COLLAGE: where overlapping or similar careful placement of component images is necessary to illustrate a point in an encyclopedic way [emphasis added]. Collages are otherwise discouraged. WP:LEADIMAGE uses the singular. MOS:INFOBOXPURPOSE tells un not to try to write the article in the infobox. Such collages are a photo essay and just another way of trying to write the article in the infobox. WP is not a picture encyclopedia. Moreover, squeezed two (and sometimes more) abreast, they are too small to be easily seen and poorly contrasting images just become a blur. We are told not to force the infobox size (eg make it larger) for accessibility reasons. Cations then bloat the infobox further. In short, they are a terrible idea and unfortunately, they are not peculiar to cities. I see them in a battle article. Any discussion to address this should be as broad as possible in scope. Cinderella157 (talk) 08:11, 26 November 2024 (UTC)[reply]
City infobox image bloat has been longstanding issue, and picture selections and arrangements are a common cause of dispute. However, it's reasonably entrenched, so any change would likely require very wide reaching RFC. CMD (talk) 09:01, 26 November 2024 (UTC)[reply]
Agree been around for some time...at the begining it was 2 or three only in major cities. Still mainly only in big cities (rare in small towns etc) but the bloat is up to 8 or 9 even 10 images let alone 3 or 4maps 2 or 3 symbols and a few flag icons is somthing in my view we need to get a hold of. Moxy🍁 16:49, 26 November 2024 (UTC)[reply]
I think we have many protocols and essays about this but they are simply ignored. Think we need to be more blunt here.
[emphasis added]
MOS:IMAGERELEVANCE ="However, not every article needs images, and too many can be distracting.
WP:GALLERY = "In articles that have several images, they are typically placed individually near the relevant text....A gallery is not a tool to shoehorn images into an article,
WP:NOTGALLERY ="If you are interested in presenting a picture, please provide an encyclopedic. context,
MOS:IMAGELEAD = :they should not only illustrate the topic specifically, but also be the type of image used for similar purposes in high-quality reference works, and therefore what our readers will expect to see ".
WP:UNDUE = "Undue weight can be given in several ways, including but not limited to the depth of detail, the quantity of text, prominence of placement, the juxtaposition of statements, and the use of imagery".....
,MOS:IBP = The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article..The less information that an infobox contains, the more effectively it serves its purpose,"
,MOS:LAYIM = "Try to harmonize the sizes of images on a given page in order to maintain visual coherence."
What, if anything, should be done when an infobox contains unsourced content that is not found in the article's text?
I interpreted "The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article. Barring the specific exceptions listed below, an article should remain complete with its infobox ignored." to mean that such content should be removed. However, after I removed a place of birth that was not mentioned in the accompanying article's text, an editor referred me to Wikipedia:Editing policy, which says, "Improve pages wherever you can, and do not worry about leaving them imperfect. Preserve the value that others add, even if they 'did it wrong' (try to fix it rather than remove it)."
Yup… the corollary to “anything not in the article text shouldn’t be in the infobox.” is: “anything in the infobox should be also mentioned in the article.” They should work in tandem. Blueboar (talk) 22:37, 3 December 2024 (UTC)[reply]
Unless it'd be too trivial for the ibx even if it was mentioned in the body, I'd keep it. Tag it if sourcing is the issue (WP:PRESERVE). It should ultimately be in the body, but there is no deadline. —Bagumba (talk) 07:43, 4 December 2024 (UTC)[reply]
Sure, but presumably the OP wasn't referring to contentious content, as the question seemed more focused on its being in an infobox. —Bagumba (talk) 16:07, 4 December 2024 (UTC)[reply]
Modern images of early medieval rulers in infobox or article
Hi, should be included in the infobox and article the 19th and first half of the 20th century depictions of sub-average quality of national romanticism (often anachronistically projecting late medieval/baroque attire), but not portraits/paintings nor sculptures of cultural value, about early medieval rulers, in this specific case, from Croatia, Serbia, Bosnia and Herzegovina and Montenegro? Recently a User:Cruz.croceuploaded on Wikimedia Commons a series of poorly known and poorly made depictions supposedly from 1940 edition of Danica calendar published by Croatian (Catholic) literary society of St. Geronimo without citing an author, and edited them into several English Wikipedia articles of Croatian early medieval rulers (including good article Tvrtko I of Bosnia from the 14th century, whose representation is obvious plagiarism of portraits of Croatian nobleman Petar Zrinski from the 17th century). In articles of some early Serbian rulers (Višeslav of Serbia, Zaharija of Serbia, Vlastimir) are included romanticized images by Kosta Mandrović (1885). As in the case of all of them, such poor depictions which are usually with attire not appropriate for the time period, don't bring any value for the article themselves and to the readers. They are mostly unknown to the general public as usually are not included in educational and scientific literature. They are products of bygone era. I don't think on Wikipedia should be promoted such outdated and poor depictions of old historical personalities. Does it exist some previous discussion or consensus about such topic? Miki Filigranski (talk) 13:30, 3 January 2025 (UTC) Note: WikiProject History, WikiProject Middle Ages, WikiProject Royalty and Nobility have been notified of this discussion. --Miki Filigranski (talk) 16:30, 3 January 2025 (UTC) Although the issue initially was about ex-Yugoslavian states, there's a need for a general consensus nevertheless a country, so the discussion expanded.--Miki Filigranski (talk) 22:52, 19 March 2025 (UTC)[reply]
Almost always there's no better image because there's no image in the first place. These are personalities who lived more than 1000 years ago. For some exist some archaeological iconography (coin, church mural etc.), a modern statue or painting which has cultural value because was created by a notable artist and has cultural-political context and can be found in reliable literature - but these images and authors are not such a case, their general value and notability is almost worthless. --Miki Filigranski (talk) 16:18, 3 January 2025 (UTC)[reply]
Contemporaneous images are generally preferred. If romantic images are used they should be clearly labeled as later fictional depictions. DrKay (talk) 13:56, 3 January 2025 (UTC)[reply]
Of course it is needed to have attribution and so on, but the question is, why they can/should be used at all? These images are poor fictional depictions of real historical personalities. These articles are part of scientific topics of historiography and other scientific disciplines. We are always citing reliable scientific sources (as per WP:SCIRS, as well Wikipedia:Scientific standards and Wikipedia:Editing scientific articles). Using images from some obscure, outdated, non-scientific and probably unreliable sources for visual representation of the subjects is basically violating the WP:RS. These depictions, not only worthless from artistic viewpoint, but from a scientific viewpoint are basically pseudoscientific. What's more, there's no pedagogical purpose and reasoning to include them in an encyclopedia.--Miki Filigranski (talk) 16:18, 3 January 2025 (UTC)[reply]
Yes, they should be used, until 1. A better image is found; or 2. You can show on the article's Talk page, citing WP:Reliable sources, that the image is a misidentification of another person or there is some other reason why it is not at least intended to be a depiction of the person shown. As noted above, if it is a fictional/romanticized representation, that should be in the caption or footnote, which should also note the anachronisms.We are not saying that this is scientific, we are saying that this is how the person has been portrayed. -- Ssilvers (talk) 17:29, 3 January 2025 (UTC)[reply]
I think "invented" images of historical people should only be used if RS do the same. We do not want someone inventing new faces for some 9th century bishops in 2025, but we can use invented faces from the 14th century that already have a long tradition in connection to their subject. —Kusma (talk) 17:56, 3 January 2025 (UTC)[reply]
per MOS:IMAGEREL "Images must be significant and relevant in the topic's context, not primarily decorative" (these are primarily and only decorative, don't have any other purpose) and "However, not every article needs images" (of course), and per MOS:IMAGEQUALITY "Poor-quality images—dark or blurry; showing the subject too small, hidden in clutter, or ambiguous; and so on—should not be used unless absolutely necessary. Think carefully about which images best illustrate the subject matter" (these images are absolutely unnecessary).--Miki Filigranski (talk) 18:05, 3 January 2025 (UTC)[reply]
The thing is, even fake images can become relevant, but usually only if there is some cultural context (say, NotableActor playing DeadKing in NotableFilm), not for any random image. Infobox and lead images should probably be held to a higher standard than general illustrations, though. —Kusma (talk) 19:07, 3 January 2025 (UTC)[reply]
This is not a "decorative" image, nor a "fake" one.
...but is obviously fake and misleading, based on a notable late 11th century font of another Croatian king living ca. 150 years after "Kralj Tomislav".
"Decorative" images are things like Dingbats or putting butterflies and flowers in an article (that isn't about those insects or plants) just because you like the way they look. A drawing of the article's subject, especially when it is not user-generated, is perfectly fine.
When the person lived a thousand years ago, then a drawing from a hundred years ago is okay, but you should address the age gap in the caption, e.g., "Drawing from early 20th century" or "Statue from early 20th century". WhatamIdoing (talk) 23:44, 18 March 2025 (UTC)[reply]
Yes, but not every drawing of article's subject is "perfectly fine". The drawing of "Kralj Tomislav, Danica, 1940" is completely not notable and not recognizable in Croatia, created by an unknown author. It is completely without any historial and cultural relevancy and value (aside being a poor image). It is also a "fake" image as the drawing of the early 10th century Tomislav, King of Croatia is based on a notable late 11th century baptismal font, most probably, of a Croatian king Demetrius Zvonimir (who received regalia; crown, scepter, sword and flag), certainly not of Tomislav for whom is not even know whether received regalia by a Pope nor how his crown looked like (certainly not as Crown of Zvonimir), actually "when, where, or by whom" was crowned. Such a depiction is visually misleading and confusing the public.--Miki Filigranski (talk) 22:44, 19 March 2025 (UTC)[reply]
@Shadow4ya: considering recent edits at Mutimir (where I removed 'own-work' of the original and replaced with the original whose author does have an article, but still don't see how is notable and relevant since the depiction is completely inappropriate for early medieval period), also your reverts at Constantine Bodin. Do you have any information whether these depictions of early Serbian and other rulers are publicly known outside Wikipedia, are used in school or academic literature? There's a need for clear consensus so your comment would be welcomed.--Miki Filigranski (talk) 20:42, 18 March 2025 (UTC)[reply]
@Borsoka, Gyalu22, OrionNimrod, and Ermenrich: as you are editors who extensively edited articles dealing with early medieval period (about the Huns and Hungarians), your commentary would be also welcomed (on the discussion at hand, and in general about the usage of romanticized images in infobox or body of the article as there's a need for a consensus with some specific criteria/statements of conclusion so as editors we can have a point of reference).--Miki Filigranski (talk) 20:58, 18 March 2025 (UTC)[reply]
Of course we do not have photography from people who lived 500, 1000, 2000... years ago. (Today we have thousands of photos about famous people, it is also hard to choose what is a best shot to represent them.) Usually the artworks (paintings, sculptures...) also not a contemporary works. However there are famous artworks about famous old people, and we can see those artworks all the time everywhere to represent those people.
If the work is contemporary, the quality can be very bad (like today also we have various quality of artworks for the same thing)
I think the contemporary quality is bad regarding King Wladislaw:
Contemporary work from 1438: King Wladislaw was 14 years old when he was depicted as old man with beard in his seal, this depiction is a bad quality
Painting from 1488: King Wladislaw was 20 years old when he died, he was depicted as old man, this image is bad quality
Better quality artwork 1876
Better quality artwork 1891
The contemporary representation of king Louis the Great looks ok:
c 1360
c 1360
1420
1488
John Hunyadi also has many famous representation, those are used everywhere all the time, but these one are not contemporary works:
1488
1600s
1903
1906
All artworks are contemporary from king Matthias Corvinus, in this case we have more choose:
Videos are very popular nowadays. I think it is always good to use many images in articles, like today academic history books also use a massive amount of images to help to visualise, represent, memorise things. I think the usage of images is depend on the situation, but we need choose good quality artworks, of course we do not need to put articles bad quality works just because the infobox is empty. OrionNimrod (talk) 10:56, 19 March 2025 (UTC)[reply]
Thanks for pinging me. I think this problem is less apparent with the Hungarian medieval rulers. The illustrations in contemporary or near-contemporary chronicles – Chronicon Pictum and Chronica Hungarorum – are well known and widely used in other portfolios too. Sometime in the past, this discussion took place on the Hungarian Wikipedia regarding Josef Kriehuber's 19th-century lithographs, and the decision there was that these illustrations should be avoided if possible (perhaps these images are still used only for 10th-century princes). I also believe that these romanticized illustrations should be avoided in infoboxes, but the same applies to Baroque paintings from a few hundred years after the person's life, unless they are distinctive and widely known, say, as the work of a famous artist. I wouldn't rule out displaying the images in the Legacy section (if any). --Norden1990 (talk) 11:03, 19 March 2025 (UTC)[reply]
I would generally think that we should not use Hungarian chronicles to illustrate the Hunnic rulers in their infoboxes. They usually look like generic medieval rulers rather than steppe peoples in those illustrations. This is misleading to our readers.--Ermenrich (talk) 15:01, 19 March 2025 (UTC)[reply]
What is |education= for? It appears we don't list K-12, and for higher education, we use |alma mater=. Is the field deprecated, or has legitimate usage? -- GreenC17:51, 1 February 2025 (UTC)[reply]
It seems the text size in infoboxes has been changed to small text or at least reduced sometime in the last 48 hours. Does anyone know who did this and/or where the discussion that resulted in the change occurred? The text size has definetly been reduced. Helper201 (talk) 15:01, 6 February 2025 (UTC)[reply]
Literally all infoboxes, or at the very least all political party and politician ones I've seen, as those are ones I usually focus on. The text in all I've seen has been reduced and there's nothing new that's been added to the infoxes I've viewed to change this, so it seems infobox-wide across Wikipedia. Helper201 (talk) 15:23, 6 February 2025 (UTC)[reply]
No, my system is exactly the same. It definetly wasn't like this when I last was on Wikipedia less than 48 hours ago. Where are such overarching decisions made to change the text size on all infoboxes? Helper201 (talk) 15:52, 6 February 2025 (UTC)[reply]
As far as I can tell, this is something specific to your system, as neither the template code nor the style code on the server has changed. If the code has not changed, then it is impossible for the display determined by said code to have changed. Remsense ‥ 论15:56, 6 February 2025 (UTC)[reply]
Can you identify that the infobox text is smaller than the main body text of articles, even if there was no changes in the last 48 hours? Maybe this happened earlier and I didn't notice it. I can't see anything that would display infobox text smaller than main body text on my system, as if it was a system issue the text would change uniformly across the page. Helper201 (talk) 16:01, 6 February 2025 (UTC)[reply]
I thought you meant they hadn't changed in the last 48 hours that I specified (as I assumed that's when you were looking), hence why I said if you could identify if the text sizes were different, outside any changes. Helper201 (talk) 16:07, 6 February 2025 (UTC)[reply]
Ok, thanks for the responses and apologies for any hassle. I noticed the links on the left-hand side on Wikidata i.e. Main page, Community portal, Project chat, Create a new Item, etc seem smaller too. I don't know if that indicates a wider system change that is not specific to infoboxes. Helper201 (talk) 17:08, 6 February 2025 (UTC)[reply]
I'm not seeing anything different, although we might be using different skins. Have you checked your browser view level? Once in awhile, I apparently click something weird and my browser view goes from 100% to some smaller % until I catch on and restore 100%. Schazjmd(talk)17:13, 6 February 2025 (UTC)[reply]
I'm curious, what is the opinion of placing a video in place of an image in the infobox? I don't see anything about using video in the infobox MOS, should it mention that? Hzh (talk) 00:08, 9 February 2025 (UTC)[reply]
Increasing infobox image size for aesthetic purposes
Hi folks, I (and a group of fellow editors, participants notified) are looking to see if we can get some clarity/consensus of exactly what circumstances the "image_upright" parameter should be used to modify the scaling of infobox images.
Before going any further, I'd encourage people to read the previous, relatively short, discussion here: Special:Permalink/1275559177
There are a chunk of articles (many related to Korean celebrities, maybe 100 or so) that have had their infobox image sizes expanded by 15% past the default size, whether it is functionally necessary or not. Example: Nayeon, Giselle (singer), Cha Eun-woo, etc.
A few days ago, many of these size increases were removed (example) (that is, the article's infobox image sizes were reset to the default scaling), but they were promptly reverted and the larger scaling reinstated. (example)
A discussion has ensued around when it is appropriate to modify the infobox image scaling:
My position is that infobox image scaling is standardized across the encyclopedia, and to expand the scaling for purely aesthetic purposes goes against the spirit of consistency that infobox templates are supposed to give. The image scaling parameters should only be used in event that there is a functional need to modify the image size, not an aesthetic one.
Other editor's positions seem to be that, because there is currently no guidance on the topic, and there is no rule stopping it, they see it as appropriate to increase the infobox image scaling arbitrarily across large swaths of articles because they believe it looks better aesthetically.
I'm hoping a discussion here at a a wider venue can help us come to a conclusion on this issue. Should infobox image sizes (particularly for biographies) be largely consistent across the project, or is it acceptable for certain chunks of biographical articles to have their infobox images be bigger than the rest, just because it might look a little better to certain people?RachelTensions (talk) 20:44, 13 February 2025 (UTC)[reply]
Reposting one of my comments from elsewhere:
In general I avoid setting image sizes in infoboxes due to not only the reasons given in that convo but also because it creates unnecessary space for minute fiddling and potential debate for each individual application. I agree such changes should be somehow set at a site-level instead. The most I'll do to get around this is crop images myself, otherwise I make sure to select images that fit well in the infoboxseefooddiet (talk) 20:50, 13 February 2025 (UTC)[reply]
My evaluation of the current state of things (i.e. the functional consensus) is that the image_upright parameter is used with a value <1 when an image is especially narrow and needs to be reduced in height, and with a value >1 (up to 1.35 per MOS:IMAGESIZE) when an image is in a landscape ratio and needs to be widened beyond the default. When an image is roughly 3:4 in ratio (the vast majority), it isn't typically used. I figure that the general heuristic that editors follow here is "maintain approximately the same area as a normal case", with the normal case being an image with a roughly 3:4 crop and the default width (say at Barack Obama). I totally oppose making images with a typical ibox crop wider than the default of 220px, as I think this simply makes them distractingly big compared to other page elements. Note that a typical 3:4 image (displayed in 220x293) being increased in width by 15% (to 250x333) represents a 29% increase in area. — Goszei (talk) 20:51, 13 February 2025 (UTC)[reply]
Removing image_upright from Template:Infobox person altogether as either way (increasing or decreasing) are partially and/or fully for aesthetic purposes. In which what is considered as "fine details" for increasing or "little details" for decreasing varies on individual's brain processing in turn their cognitive perception and also factoring in the differences in screen sizing hence no matter what, it's still for aesthetic reasons of being too big and/or too small. Removing the parameter avoids arbitrary 'monkey see, monkey do' adjustments and enforces consistency across any BLP articles. —Paper9oll(🔔 • 📝)21:03, 13 February 2025 (UTC)[reply]
The "fine details" argument here is strange. There's a relatively objective metric here: "is an extra non-crucial option being controlled?" The answer is yes. In general, I attempt to minimize these kinds of options. It has nothing to do with intelligence; it's relatively trivial to change the size. But as a principle, I minimize the amount of trivial extra decisions that need to be made on each article. seefooddiet (talk) 21:12, 13 February 2025 (UTC)[reply]
Btw, I took both details quote from the MOS:IMAGESIZE and I'm also clearly not focusing on increasing as if decreasing isn't aesthetic. Brain processing isn't referring to intelligence-end but the perception-end. Since it's stated that there is no beneficial and "relatively trivial to change the size" in increasing the sizing on BLP image then likewise, it's not beneficial in decreasing the sizing. Let default be hard-coded as 1 (220px) in the template which would "minimize the amount of trivial extra decisions that need to be made on each article" and any perception of too big and/or too small could be handled by the Special:Preferences itself. —Paper9oll(🔔 • 📝)21:17, 13 February 2025 (UTC)[reply]
I'd possibly be ok if default image was changed across the board, but would need to review potential impact. I'd rather not we expect people to adjust their special preferences for this. seefooddiet (talk) 21:51, 13 February 2025 (UTC)[reply]
Not sure, I can't think of other alternative that doesn't contains subjective interpretations and/or some form of aesthetic in its reasoning. —Paper9oll(🔔 • 📝)21:54, 13 February 2025 (UTC)[reply]
Removing the parameter would be throwing the baby out with the bathwater. As I say in my comment, when images have unusual aspect ratios, non-default scaling is useful. Perhaps the functional consensus could be formalized in language that says what to do when the image is (1) narrow, (2) landscape, or (3) roughly 3:4. — Goszei (talk) 21:41, 13 February 2025 (UTC)[reply]
How is "when the image is narrow, landscape, and roughly 3:4" framed as "functional" not aesthetic? Also what is the exact definition of "when the image is narrow, landscape, and roughly 3:4"? I'm not asking what is narrow, what is landscape, and what is 3:4. —Paper9oll(🔔 • 📝)21:47, 13 February 2025 (UTC)[reply]
The function of course is aesthetic, more specifically the function of making images an appropriate size compared to other page elements (not distracting from the text, not too small to see details, etc.). Many rules in the MoS are not strict laws, but rather rules of thumb. This seems like an appropriate case for one, and as always the ultimate decision on image size or anything else in a given article is fully subject to consensus. — Goszei (talk) 21:54, 13 February 2025 (UTC)[reply]
But what constitutes an "appropriate size" is inherently subjective. What one editor considers "not distracting" or "not too small" another might disagree with considering that it isn't a one size fits all solution. A rule-of-thumb based on such subjective criteria will inevitably lead to inconsistent application, which is precisely the problem we're trying to solve. —Paper9oll(🔔 • 📝)21:57, 13 February 2025 (UTC)[reply]
Everything about creating an encyclopedia is subjective, which is why we have discussions and reach consensus on which subjective way to organize an article is correct (i.e. most editors agree). Once that is done, and perhaps formalized in language in the MoS, the minority with the opposing and equally subjective opinion must follow it. — Goszei (talk) 22:08, 13 February 2025 (UTC)[reply]
I agree that consensus and guidelines are important, but they're only useful if the guidelines are clear and objective. The "narrow" and "3:4 crop" example demonstrates the problem: these terms are inherently subjective. How narrow is narrow? What is narrow and what isn't? What is 3:4 crop and what isn't? All-in-all, these are too subjective to be objective, the goal is to have a consensus and guidelines that wouldn't be such. —Paper9oll(🔔 • 📝)06:49, 14 February 2025 (UTC)[reply]
What one editor considers "not distracting" or "not too small" another might disagree with considering that it isn't a one size fits all solution. If you say that image size isn't a "one size fits all solution" then why is "image_upright=1.15" seemingly a one size fits all for you in biographical articles? Everything is 15%, it's never 0%, or 5%, or 7%, or 10%. It's always 15. RachelTensions (talk) 22:58, 13 February 2025 (UTC)[reply]
I clearly and purposely mentioned both ways hence I'm not exactly sure why on earth you kept on implying that I'm preferring to retain image_upright=1.15 or specifically "1.15". The number can be of any sizing. —Paper9oll(🔔 • 📝)06:23, 14 February 2025 (UTC)[reply]
I'm not exactly sure why on earth you kept on implying that I'm preferring to retain image_upright=1.15 Because you've reverted people's efforts to bring infobox scaling back to default size on multiple occasions. RachelTensions (talk) 16:20, 14 February 2025 (UTC)[reply]
That's previously and also you're seemingly accusing me as the only editor doing so simply based on the reverts when in fact such customization was already there prior since 2013 when I started editing hence like I stated above, "monkey see, monkey do" applies. Regardless, I clearly didn't stated preferring image_upright=1.15 nor any other sizing in this every discussion here on Wikipedia talk:Manual of Style/Infoboxes and on this section specifically, in fact I have been constantly on the line of removal hence constantly assuming as such is unproductive to this discussion. —Paper9oll(🔔 • 📝)16:39, 14 February 2025 (UTC)[reply]
Would personally support any language that would reduce the size of these info boxes..... thus giving our readers more accessibility to the prose. The reason we have upper limitations is for accessibility that should be lowered in my view.Moxy🍁21:25, 13 February 2025 (UTC)[reply]
MOS:INFOBOXSTYLE tells us A good guideline is not to add extraneous style formatting over that in a default infobox without good reason. The width of an infobox is a predetermined size. This should not be altered. However, it may be necessary to add two or more columns of information to the infobox (eg for military conflicts) and this may result in a reasonably necessary increase in width. If the infobox must be wider than standard, there is reasonable reason to increase the lead image proportionally. WP:IMGSIZELEAD tells us: The lead image in an infobox should not impinge on the default size of the infobox. Therefore, it should be no wider than upright=1.35. A good reason to maximise the image size would be the detail of the image. This may apply to a map but does not reasonably apply to a portrait. Asthetics are not a good reason to increase the image size. Just because we can do something does not mean we should. If we need to amend P&G then it would be to add the good reason qualification. Cinderella157 (talk) 04:05, 14 February 2025 (UTC)[reply]
In articles about art, the standard size is waaay too small, which accounts for much of the hostility towards boxes among many or most editors in this area. Johnbod (talk) 05:31, 14 February 2025 (UTC)[reply]
Arguably, most readers of WP access it from a mobile device. My understanding is that in a mobile device, the infobox is presented at the width of the device screen - which can be orientated to either portrait or landscape by the user. This is the key reason not to use px to force a particular size. Consequently, increasing the image size to the point that it makes the infobox "larger" will not change the viewing experience for the majority of readers that use modile devices. For those using PCs, the image can be double clicked (once to commons and twice to the actual file) to give a much larger image. This discussion: however, is about increases to the image that do not impinge on the size of the infobox. Increasing the image ratio to capture the detail of an art work the subject of the article is arguably a good reason to do so provided it does not impinge on the infobox size per the guidance. Cinderella157 (talk) 09:18, 14 February 2025 (UTC)[reply]
Guidelines for colors
Hello folks! Upon editing some school related articles, I've noticed some inconstancy on how people write the school colors in infoboxes. Certain ones choose to do it saying "color x" and "color y" (like this article), while others choose to use the format of "color x", "color y" (like this article), and some don't even list the color names. Is there a consensus on the formatting for this? Asking here, as this may apply to more than just school articles. Theadventurer64 (talk) 19:51, 10 March 2025 (UTC)[reply]
There's not really a reason to have rules for this—the MoS exists to best serve readers, but also in significant part to allow editors to avoid immaterial disputes. For choices where multiple options work fine and it's not likely to confuse readers, we try to leave things to the editor's discretion on an article-by-article basis. Often standards manifest below the guideline level simply due to factors like ease of formatting, but they're not at the level of guidelines all the same. Remsense ‥ 论20:11, 10 March 2025 (UTC)[reply]
Spouse inclusion
There is currently a debate between users at Emily Osment about the inclusion of her spouse. Some users are saying the spouse shouldn’t be added as he isn’t notable in his own right, while others believe he should be added.
In my own opinion I believe he should be added as most celebrities do have their non-notable spouse in their infoboxes. But I am unsure as to whether or not there is a rule surrounding spouses and couldn’t see anything to answer my question on any Infobox related pages. Does anyone know the actual answer? Any feedback is appreciated. CDRL102 (talk) 23:15, 15 March 2025 (UTC)[reply]
{{Infobox person}} does say not to to include parents, children, or other relatives unless independently notable. However this does not apply to spouses. Discussions don't take place effectively using edit summaries. Consider opening a discussion on the talk page of the article. StarryGrandma (talk) 00:09, 16 March 2025 (UTC)[reply]
is it ok to remove infoboxes because they are fetching from wikidata and or duplicative?
Recently, I have encountered several editors (@David Eppstein, @JayBeeEll) who I know to be otherwise good and productive editors, removing infoboxes, for example from James Cleland (statistician), which in many cases contain accurate information and images, particularly in David's case without replacing the accurate information, having the net effect of dis-improving the encyclopedia. Do we as a project deprecate such infoboxes? I understand it is a case by case thing for articles but what about these cases? In at least a handful of cases this is having a detrimental effect. Andre🚐21:40, 20 April 2025 (UTC)[reply]
Two thoughts:
If the reason for removing an infobox from an article is that the template pulls information from Wikidata, then that should be addressed at the template level, not in a single individual article. Template:Infobox person/Wikidata is in use at several thousand articles. Removing it from one, or a dozen, is kind of pointless. Even if you have an aggressive interpretation of our limits on using Wikidata, we don't have an absolute ban, and if you want to reduce the use of Template:Infobox person/Wikidata, then you should replace it with Template:Infobox person manually. If you're replacing it with the same information, someone might roll their eyes about how you choose to use your time, but I doubt that anyone will try to stop you.
There are thousands of articles in Category:Wikipedia articles with an infobox request. Rather than starting a time-consuming fight over one (or two, or ten) articles, fans of infoboxes should consider supplying them where they have been actively requested.
Sigh… Given the ongoing issues at Wikidata, I think the template DOES need to be changed … so it no longer pulls ANY data from Wikidata. And, yes, I do understand that I am effectively saying we need to deprecate a sister project.
Wikidata still far too many issues with regards to reliability, uncorrected vandalism, and outright incorrect information… I no longer trust it to generate ANYTHING for WP.
I do appreciate the efforts of our compatriots over at this sister project. Wikidata is a good idea… but it seems to have systemic flaws. The fans of the project unfortunately either can’t see these flaws, or are intentionally ignoring them. They need to take their heads out of the sand and get their house in order. We have discussed the problems ad infinitum and yet the problems persist. The time has come to force the issue. Deprecate their project until/unless they fix it. Blueboar (talk) 15:24, 22 April 2025 (UTC)[reply]
Blueboar, I'd be interested in hearing more about your experience with Wikidata. You don't seem to have made any edits there. Have you personally encountered serious, overlooked problems with an entry, or is your information based on examples provided by others?
I will 2nd WAID's request for further detail on how Wikidata has been inaccurate if it indeed has been, or how that has impacted enwiki or infoboxes non-hypothetically. I have found that it is accurate every time I look at it, with good data that helps me when writing articles. Also, infoboxes on Wikipedia are generally very accurate, so much so that there is now a Structured Data API that will return infobox information. Another thing that we are breaking by indiscriminately and with extreme prejudice removing autocompleted Wikidata infoboxes. I have found the Wikidata template to be effective, efficient, and with good usability a way to create infoboxes. If I have to write Wiki templates by hand I am less inclined to do it. I am not looking for a new gnome task at present, but I find it useful to just plop a free infobox, and I think we should lean in on targeted use of automation so long as we can be sure it is accurate. So far, I have not seen any inaccuracies. It is not like we are asking an LLM to summarize an article and make infoboxes. These Wikidata data snippets were created mostly by humans or by sanctioned bot usage in a standard way as we do on Commons, and benefit from the same auditability ie Mediawiki history log, as enwiki. Andre🚐17:35, 22 April 2025 (UTC)[reply]
Wikidata gets some vandalism. Some of it is dramatic, and some of it persists for a long time. OTOH, Wikipedia also gets vandalized, and Wikipedia:List of hoaxes on Wikipedia proves that some vandalism is both dramatic and may persist for years here, too.
That said, I can imagine a middle ground, in which the concern isn't really about initially fetching Wikidata's information, but about watching changes to it. A way to subst an infobox that was initially filled out by fetching data from Wikidata (the same way we fetch the contents of citation template through Wikipedia:ReFill and similar gadgets) might make these editors feel more comfortable about their ability to see changes to an infobox's contents through the familiar mechanism of checking diffs in your watchlist.
I have about 250 items on my Wikidata watchlist. In the last month, about a third of them have had any change. Almost all the changes are translations of the item's title. So far, I've found two instances of simple vandalism. WhatamIdoing (talk) 18:08, 22 April 2025 (UTC)[reply]
To be blunt… the reason I have not edited Wikidata is that I can’t figure out HOW to do so. I look at a Wikidata page and I see a chain of gobbledygook. I don’t know where on the page information is stored, so I can not figure out what I would need to fo to fix a problem. I don’t know the coding involved. Etc etc
So… since I am too baffled to affect the INPUT on WD, my interaction with Wikidata is limited to its OUTPUT… what it generates HERE on WP.
And that is where I see all the problems. When WD generates inaccurate information, I can not correct it… when I see obvious vandalism, I can not correct it… I don’t have the ability to do so. Blueboar (talk) 13:35, 23 April 2025 (UTC)[reply]
For small edits there's usually no coding involved, but you have to understand different P(roperty) meanings, which can be a stumbling block. Happily for vandalism the Wikidata history works like our article history, you can simply view the diff (where it's pretty clear what changed) and undo. Not to say we should rely on editors having to go edit things which don't end up on the en.wiki watchlist, but generally vandalism is easy to revert (once it's been found, which, a different problem). CMD (talk) 13:58, 23 April 2025 (UTC)[reply]
For me, all the P and Q stuff is more than a stumbling block. It’s a complete block. Thus all I can do is complain about what’s wrong and hope that someone will notice my complaint and fix it… at some point… but maybe not. That’s unacceptable. Wikipedia is supposed to be an encyclopedia that anyone (even me) can edit… but the more we pull things from Wikidata, that is becoming increasingly impossible. Blueboar (talk) 14:40, 23 April 2025 (UTC)[reply]
lol… I got confused by the first picture. So I would say, no, that doesn’t look like something I could do.
OK… maybe I could figure it out eventually… but I really don’t have any incentive to learn. I want to edit Wikipedia, not Wikidata. I already know how to edit and add a source to a Wikipedia article, so I have no incentive to figure out an additional multi-step process that adds it to a sister project.
Also, how does learning how to add a source from here to there (outbound) resolve the problem of flawed information being generated (inbound) from there to here? Blueboar (talk) 19:33, 23 April 2025 (UTC)[reply]
Because if you can learn how to change something (anything) in Wikidata, then you can learn how to change outdated and incorrect things in Wikidata.
Just an uncorroborated hunch, but I'd bet that vandalism is an exponentially larger issue here on enwiki than over there on wikidata. Vandals are usually attention seekers (whose satisfaction increases in proportion to the displeasure caused by their handiwork). Why would a potential trouble maker go muck about with a bunch of Ps and Qs (that nobody's going to see) when there are millions of lovely articles to defile right here? -- Cl3phact0 (talk) 15:37, 23 April 2025 (UTC)[reply]
Here, vandals have to vandalize one article at a time. But vandalism at WD can get automatically generated into hundreds of articles on WP at once. So you get bigger bang for your vandalism buck. Blueboar (talk) 19:40, 23 April 2025 (UTC)[reply]
I suppose there's a certain logic to that. Happily, for the most part, the vandals haven't figured out how to use wikidata (or, for that matter, that it might have a connection with what appears in enwiki articles). Maybe best to keep it mum. -- Cl3phact0 (talk) 19:46, 23 April 2025 (UTC)[reply]
@Blueboar: You mention that if WD generates inaccurate information, [you] can not correct it, which may be an issue for you on with Wikidata side, although from what I have observed, if a local parameter is used (in conjunction with a Wikidata generated infobox), then it is the local information that is displayed here on enwiki (regardless of what happens over on Wikidata), which gives you the final say on what is published here. -- Cl3phact0 (talk) 10:21, 25 April 2025 (UTC)[reply]
You somewhat lost me at the term “local parameter”… I assume you mean the text and citation that I would type into the infobox? Blueboar (talk) 11:31, 25 April 2025 (UTC)[reply]
Yes, exactly. The WD infoxboxes can have things added to them right here (locally), without your having to mess around in WD at all. These things take precedence over the things that would otherwise be "fetched" from WD. -- Cl3phact0 (talk) 11:43, 25 April 2025 (UTC)[reply]
For example, an editor didn't like that "Yale School of Medicine" was listed twice in the "Alma mater" field in our Francine M. Benes article's infobox. Adding "|alma_mater=" locally allowed them to control that particular part of the infobox (with the added benefit of also indicating a bug in our template that we need to fix). The wikitext looks like this (if that's of any use to you):
{{Infobox scientist/Wikidata|fetchwikidata=ALL|noicon=on|dateformat=mdy|alma_mater=[[Yale School of Medicine]]<br/>[[St. John's University (New York City)|St John's University]]}}
@Cl3phact0: I have personally encountered false information in Wikidata about a BLP that I was unable to correct (my edit to remove the false claim was reverted). The excuse I was given was that the datum was from some random national bibliographic database and that we needed to keep Wikidata in sync with that database. Instead I was told that we needed to use some arcane syntax to mark that claim as low-priority and hope the marking would be sufficient to prevent others from reading and using the false information it presented. Unfortunately this was long enough ago that I no longer remember enough specifics to find the same item again. —David Eppstein (talk) 07:44, 29 April 2025 (UTC)[reply]
I am by no means expert in the matter, only curious to learn more, and if possible, to use the tools to do good work here (where, I might add, I'm no expert either). Most of my experience on Wikidata has been uneventful, and I have found interesting ways to use it (mostly for the ultimate benefit of what I'm trying to contribute here). The few interactions I've had there have been civil and constructive. It seems that that is not your experience. In any case, I do believe it's a mistake to take a falsus in uno, falsus in omnibus approach to the whole project, as the potential upside is considerable. Also, in my view, the risk of ignoring Wikidata is the disimprovement of Wikipedia or worse (the LLMs are surely devouring it in equal measure to Wikipedia, which is what it is, so I won't go on about it). Cheers, Cl3phact0 (talk) 08:10, 29 April 2025 (UTC)[reply] PS: Again, there are a few recent examples of how we might potentially use Wikidata to achieve positive outcomes (mostly by working on the Wikipedia side on the divide) on the Talk page of the Wikidata version of Infobox person, if you're interested. -- Cl3phact0 (talk) 08:36, 29 April 2025 (UTC)[reply]
To the question in the headline: No. Wikipedia editors should be able to review any changes made to content in our articles; nothing should be automatically imported on an ongoing basis. When I review my watchlist, I want to see a notification every time there is a change to an article I am watching. -- Ssilvers (talk) 19:47, 23 April 2025 (UTC)[reply]
This sparks an intriguing proposition: Could updates to a Wikidata generated infobox field also trigger a watchlist change notification? -- Cl3phact0 (talk) 07:24, 24 April 2025 (UTC)[reply]
Well, theoretically going to Special:Preferences and checking "Show Wikidata edits in your watchlist" does this. However, it causes an overwhelming mess. To control this somewhat, go to the Recent changes tab (yes, not the watchlist tab), and select "Group changes by page in recent changes and watchlist". Report back if you find this useful. CMD (talk) 07:30, 24 April 2025 (UTC)[reply]
That's great, it already exists! Thank you. Perhaps these functions could be further refined in future in order to address any concerns that Wikidata sceptic editors may have. -- Cl3phact0 (talk) 07:58, 24 April 2025 (UTC)[reply]
The need for refinement is why people should report back. (Although I can't immediately find where they had most recently asked for feedback.) CMD (talk) 08:08, 24 April 2025 (UTC)[reply]
But if the change is made automatically, and you disagree with it, even if you correct it back in the infobox, it will automatically get changed again. This would force everyone to also monitor and edit Wikidata pages. -- Ssilvers (talk) 15:11, 24 April 2025 (UTC)[reply]
The forcing editors to monitor Wikidata pages is a known issue, but I'm not sure why you think things get automatically changed again after correction. A Wikidata edit takes effect in the same way a Wikipedia one does. CMD (talk) 16:10, 24 April 2025 (UTC)[reply]
Perhaps Ssilvers refers to individual facts that are being monitored by a bot (e.g., so you can't just vandalize the population of a country, because the bot will revert it back). In some cases, the correct answer is to have multiple facts in the Wikidata entry. For example, rather than edit warring with a bot over whether the population of ____ is 123,456,000, you can say "Fine, that's the population according to the the 2020 official government census, but 156,789,000 is the population according to 2025 UN estimates, and Wikidata is going to have both, not just the other one." Use the "priority" slider at Wikidata to determine which one will get picked up by the infobox. WhatamIdoing (talk) 18:55, 24 April 2025 (UTC)[reply]
Can a single Wikidata change affect infoboxes in more than one en.wiki article? That would complicate watchlisting. (Maybe I should know already but I took it off my watchlist long ago, deluged by stuff like "Language link added: viwikiquote:Lít" and "Created claim: Property:P13202: ivory-coast, #quickstatements; #temporary_batch_1745468333091".) NebY (talk) 19:18, 24 April 2025 (UTC)[reply]
Yes, I understand that's is possible. It is basically transcluded like a template, and just like you could put a single template on multiple pages, you could put a single Wikidata entry on multiple pages. However, while it's technically possible, it appears to be (very? extremely?) unusual for any Wikidata entry to affect more than one article at any Wikipedia. WhatamIdoing (talk) 20:32, 24 April 2025 (UTC)[reply]
The times I've turned on the wikidata watchlist I've certainly felt like it was showing me pages that were not the Qid of the en.wiki page watchlisted. CMD (talk) 01:39, 25 April 2025 (UTC)[reply]
Not true at all. When basic information on e.g. a person is changed, it is replicated in all languages that use the Wikidata infobox, plus their Commons category. This is one of the main reasons Wikidata is promoted actually, so you only have to change the information once and can change many language versions at the same time. Without this, Wikidata has even less arguments for its existence (beyond interlanguage links). E.g. last week the wife of Remco Evenepoel was correctly added: this is reflected on Catalan Wikipedia, Galego, Basque, Norwegian, Commons, ... Fram (talk) 11:28, 25 April 2025 (UTC)[reply]
Please read what I wrote again. The words "one article at any Wikipedia" means one article at the Catalan Wikipedia, one article at the Galego Wikipedia, one article at the Basque Wikipedia, etc.
What Blueboar was asking is whether one change at Wikidata could affect multiple articles at a single language's Wikipedia. That could be (e.g.) six articles at the Catalan Wikipedia, three articles at the Galego Wikipedia, four articles at the Basque Wikipedia, etc. While this is technically possible, it is unusual for one Wikidata entry to affect multiple articles at any particular Wikipedia. WhatamIdoing (talk) 19:05, 25 April 2025 (UTC)[reply]
"(or the "P" number, but almost nobody will see those edits here)." Not true. I just reactivated Wikidata changes in my watchlist to check, and the very first entry I get is "Created claim: Property:P13455: 24650, #quickstatements; #temporary_batch_1745575308416)". Second Wikidata entry, different article: "(Created claim: Property:P13455: 27112, #quickstatements; #temporary_batch_1745575308416)" and so on. Other entries have "(Removed claim: Property:P1629: Q50358336)", "(Created claim: Property:P1629: Q50358336)" and so on. I have more entries with a P number than with a Q number, and none with a Q number but without a P number. Fram (talk) 11:16, 25 April 2025 (UTC)[reply]
You got that first notification because you apparently have Jean-Laurent Cochet (corresponding to the "Q" number q:Q999960) on your watchlist, not because you have d:Property:P13455 (the "P" number) on your watchlist.
That edit summary means "Somebody added a new entry for a particular property ("Property:P13455", a French musicology authority control) with the relevant value (24650, which links to their database entry at https://dezede.org/individus/id/24650/ ) to the Wikidata "Q" number entry for the article on your watchlist".
You got that notification because of this edit to the "Q" number. You did not get a notification about any edits to any "P" number. The "P" number is mentioned in the edit summary, but you are not getting notifications about edits to the "P" number entry (d:Property:P13455) itself. WhatamIdoing (talk) 19:16, 25 April 2025 (UTC)[reply]
Comment: This thread appears to have forked into two (or more) themes: one, broadly speaking, concerns the use of information originating in Wikidata in our articles (I am particularly interested in the relationship between Wikipedia and Wikidata and how we might improve the links between the two, so it's great to hear thoughts and suggestions pertaining to this); another is the original question, which (in my reading) essentially asks: Is removal and/or replacement of Wikidata infobox templates without concensus acceptable practice, whether as a matter of personal preference or otherwise (as we have no policy prohibiting the use of these templates)? -- Cl3phact0 (talk) 10:09, 25 April 2025 (UTC)[reply]
Replacement certainly is acceptable, and the preferred outcome of many editors. Removal is more problematic, as we have some editors who think every article should have an infobox and its removal is some kind of wikicrime apparently, even if it has e.g. no information beyond what's already in the first line of the article, or if it only has an image and nothing else (as happens with Wikidata-based infoboxes, e.g. Robert Thelen – Fixed).
Issues with the Wikidata based infobox, apart from everything already stated above, may e.g. be:
Subbiah Arunachalam; the Wikidata infobox lists the academic career in random order, not in chronological (or even alphabetical) order (same happens with the employer list at Florence Bascom)
Claude Roy (poet): automatic image caption is in French, not in English – Fixed
Same article currently literally lists the awards: "Prix Guillaume Apollinaire (1995) (1983)". It doesn't list the more important Prix Goncourt, because that has no reliable source on Wikidata – Fixed
Ash Amin: a nearly empty infobox like this one is better replaced with a local one
Peter Birro: awards: "Ingmar Bergman Award (Agneta Fagerström-Olsson, 1997) ": this somehow should be interpreted as "he shared the award with Agneta Fagerström-Olsson", no idea how someone would get this from that infobox entry
Arlene Croce; according to the lead she was a dance critic, but according to the infobox she was "Art critic, taneční teoretici, film critic". – Fixed
Ward Chipman Jr.; different date format in article (mdy) and infobox (dmy) – Fixed
Charles Augustus Aiken: "position held: president". Er, president of what? It's correct, but meaningless. – Fixed
Joseph ha-Kohen is an historian and physician in our article, but a philologist in the infobox? The infobox should summarize the article, not introduce things not in the article while at the same time omitting the basics from the article – Fixed
Avishai Dekel: the "institutions" list the same entry twice: "Hebrew University of Jerusalem (1986–)" – Fixed
That's 11 problematic infoboxes from the first 28 articles I checked, not a good result (and I didn't even list all the ones with infobox lists in random order)... Fram (talk) 11:11, 25 April 2025 (UTC)[reply]
This is very helpful. Thank you. I suspect that some of these errors can be fixed on our side by improving the the way the templates are written. I have also posted a curtesy link to this discussion of the Talk page of w:Template:Infobox person/Wikidata, where there are at least a few editors have the skills to make these improvements (more help would be very welcome). In the meantime, I will continue to try and iron out any bugs that I can (I just added a caption to the Robert Thelen photo on the Wikidata side, which was pretty straightforward). Cheers, Cl3phact0 (talk) 11:31, 25 April 2025 (UTC)[reply]
PS:I will try to fix some of the above (both here and on the Wikidata side as well) when I have a moment. This means that some of the examples will no longer support the observations you have bullet pointed. For clarity, I'll add a Fixed icon to the items listed above as I do so. -- Cl3phact0 (talk) 12:26, 25 April 2025 (UTC)[reply]
I was able to resolve Ward Chipman Jr. and Charles Augustus Aiken issues by making small edits locally (qualifying the parameters with more specific instructions about what to display). The Robert Thelen problem was more on the Wikidata side but still pretty straightforward (although the article itself is still rather stubby), and Claude Roy just needed an English language caption added ("Media legend" in wikidata-speak). I'll chip away at your list bit by bit. Feel free to join in. -- Cl3phact0 (talk) 14:53, 25 April 2025 (UTC)[reply]
I refuse to edit Wikidata, and I am not really interested (for me) in removing individual issues instead of tackling the overall issue, which is the use of an infobox which takes uncontrolled, random data directly from a different site with different rules, just out of laziness really. If people want an infobox, they should fill on the way it should be, with the essential parts of the enwiki article, matching the enwiki text: not putting in one line of code and hoping that this will return correct, useful, and somewhat complete data formatted correctly. Fram (talk) 15:28, 25 April 2025 (UTC)[reply]
Noted. Obviously, I think that the Wikidata side is worth developing further, and it appears that you do not, so we are not aligned on this (nor, it appears, is there community-wide consensus about these infoboxes). Thanks again for the list above (I actually like fixing these sorts of things – believe it or not)! Cheers, Cl3phact0 (talk) 15:53, 25 April 2025 (UTC)[reply]
What would really help would be to make the Wikidata-based infoboxes cleanly subst-able with local versions of infobox templates. For example, {Infobox person/Wikidata} with three parameters filled in might turn into (for example) {infobox person|birth_date=1 April 1900|death_date=1 May 1978|birth_place=Timbuktu}. That would allow people to easily fix conditions like those listed above, rather than trying to figure out how to persuade Wikidata to output a list of workplaces in the right order, or to show a missing award. – Jonesey95 (talk) 16:33, 25 April 2025 (UTC)[reply]
I like this idea. Having it as an option would be a great timesaver for people who'd like a manual box but would also prefer not to have to fill in all the blanks themselves.
At Wikivoyage, where a limited amount of integration with Wikidata has been bog-standard normal for several years, I frequently fetch coordinates and official websites from Wikidata. It's faster than the alternatives, and then if I don't like the result (e.g., the official website comes back with /index.html on the end), I can easily change it. I would like to see something similar here. WhatamIdoing (talk) 19:22, 25 April 2025 (UTC)[reply]
Building on some of these ideas (and an earlier idea from a related discussion), I can imagine a tool that assists in generating a completed infobox. It would give the user the option to use local (i.e., inserted manually by the editor here in enwiki) or "fetched" Wikidata values. It would propose a Wikidata value for each relevant infobox field and allow the editor to accept or decline. This could even tap some of the other features evoked above and alert the editor when there is new Wikidata information available (which the editor could opt to use locally or not). -- Cl3phact0 (talk) 11:46, 26 April 2025 (UTC)[reply]
This seems like a good direction to go. Looking at the kind of data that's being imported here (name, occupation, date and place of birth and death), it's values that I would essentially expect never to change—and if they did, a manual revision of the article would probably be called for. So keeping the infobox permanently coupled to Wikidata is probably a net loss for en.Wikipedia; any changes to the data are more likely to be vandalism than an improvement, so en.Wikipedia is stuck with a higher-friction mechanism for noticing and reverting those changes. Choess (talk) 19:16, 26 April 2025 (UTC)[reply]
I tend to think that some kind of persistent coupling is actually a net gain (if we can manage in a relatively "low-friction" manner). Otherwise, we may end up in a world of "alternative facts" where the LLMs eat our lunch. -- Cl3phact0 (talk) 21:27, 26 April 2025 (UTC)[reply]
The Joseph ha-Kohen example is a good example of why Wikidata is useful and why the community should adopt and adjust their thinking toward these automatic infoboxes. Joseph ha-Kohen is primarily known as a historian. That information is in his Wikidata, but it has no references, so it is not imported to the infobox currently. I will fix that presently. However, regarding the information that he was a philologist. That is accurate and it has a reference. So the fix for that is not to remove that from the infobox, because it should be there, but add it to the article body. At any rate, the same reference, a Czech database[5] does say he is a physician, rabbi, and historian as well. The person who added that just did not update the reference. There are likely many other references for those facts too: so the preferred solution here is to fix the small errors rather than throwing out the baby with the bathwater. I recognize that infoboxes are not supposed to contain information that is not in the article, but in this case that is disimproving the ability of this article to provide useful information. Wiki articles are a work in progress. We should try to fix problems. Andre🚐21:34, 26 April 2025 (UTC)[reply]
In another example of Wikidata infobox replacement without discussion this edit replaces the previous infobox (edit summary ordinary infobox instead of using whatever gets stuck into Wikidata). The difference between the two is almost imperceptible to the reader, yet once more we lose the added functionality of the infobox version, again, apparently for no reason other than personal preference. -- Cl3phact0 (talk) 04:55, 4 May 2025 (UTC)[reply]
Perhaps the opportunity could be taken to remove Honorary doctorate from awards. That doesn't seem like an accurate characterization. CMD (talk) 06:07, 4 May 2025 (UTC)[reply]
I suppose that depends on what is meant by a well-known and significant award or honor in WP:ANYBIO, and how we interpret that in the context of the "Awards" infobox parameter. Our article about honorary degrees states that they are conferred as a way of honouring [...] contributions to a specific field or to society in general and that such degrees be listed [...] as an award. -- Cl3phact0 (talk) 08:08, 4 May 2025 (UTC)[reply]
Long discussion above. I’d like to add my voice to those who are concerned with the use of WikiData. I also think we should not be doing that for the reasons expressed above. Bondegezou (talk) 18:40, 20 August 2025 (UTC)[reply]
The stale discussion above was not conclusive as to what the problem is with wikidata or whether there is any consensus not to use it. It is in use on thousands of articles. Andre🚐18:47, 20 August 2025 (UTC)[reply]
Hi, should we omit |instrument=Vocals if the subject isn't primarily known for any other instrument, and we have already included "singer" in |occupation=? Thedarkknightli (talk) 18:00, 9 May 2025 (UTC)[reply]
Thedarkknightli, perhaps you need to give more context to your question. However, I would presume that this is a matter of duplicate information in particular instances for a particular infobox. Just because a parameter exists in an infobox, it does not mean that we should or must populate the parameter. INFOBOXPURPOSE advises that less is better. Saying vocalist and vocals in the infobox for a particular performer is redundant. I see there is no good reason to do this. Cinderella157 (talk) 09:57, 10 May 2025 (UTC)[reply]
Thedarkknightli is referring to {{Infobox person}} as main (where |occupation= comes from) and {{Infobox musical artist}} as embed (where |instrument= comes from). An occupation tells readers the roles someone performs (e.g. singer, songwriter, dancer), whereas an instrument tells readers the medium they use to perform those roles (e.g. vocals, guitar, piano). INFOBOXPURPOSE notes that "some infoboxes need to use more than a handful of fields" to summarize key facts effectively. Even if an artist's primary instrument is their voice, listing vocals under |instrument= gives readers immediate clarity—so it's not redundant but complementary. —Paper9oll(🔔 • 📝)10:05, 10 May 2025 (UTC)[reply]
No more feigned confusion—as if a singer didn't sing using their vocals. The |instrument= field has been in widespread use, including but not limited to FA-class BLP like Mariah Carey, Michael Jackson, Lorde, and Kylie Minogue—demonstrating de facto community consensus that it adds value. Suddenly declaring it "redundant" is a retroactive, overly rigid reading of MOS:INFOBOXPURPOSE and looks exactly like scope creep. MOS:INFOBOXPURPOSE explicitly allows extra fields when they convey distinct, at-a-glance facts—so it isn't redundant, it's complementary. (Apparently that needs saying.) —Paper9oll(🔔 • 📝)08:57, 11 May 2025 (UTC) ; edited for clarity 05:52, 15 May 2025 (UTC)[reply]
I'm going to step away now since we've clearly gone in circles. My stance remains unchanged: |occupation= and |instrument= serve distinct semantic functions in the template—one defines the role, the other the medium—and listing vocals is not redundant. —Paper9oll(🔔 • 📝)07:52, 12 May 2025 (UTC)[reply]
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
There is clear consensus that "yes", the infobox parameter should be omitted. This is supported by WP:INFOBOXPURPOSE, as it tends to condense the information provided. However, I'd note that there isn't much participation in the RfC, nor does it seem like there's much conflict on this. In other words, this RfC isn't going to do much that boldly making the change wouldn't. There definitely isn't enough participation to have any real impact on WP:IBP. TW18:20, 8 October 2025 (UTC)[reply]
Should we omit |instrument=Vocals if we include "singer" in |occupations=, and the subject is not primarily known for any other instrument (e.g. use
Yes. Per MOS:IBP, "information should be presented in a short format wherever possible, and should exclude unnecessary content". Per the same reasoning, if we are saying someone is a guitarist, we don't need to also specify that they play guitar, etc. Nikkimaria (talk) 23:48, 19 August 2025 (UTC)[reply]
Yes per MOS:IBP as stated above. I'm not seeing the controversy here; in fact, we're breaching WP:SNOW. Please utilize RfCs for contentious subjects, not as discussion boards: WP:RFCBEFORE. Regardless, thanks for bringing up the topic. This is an improvement to the MOS. Penguino35 (talk) 17:18, 27 August 2025 (UTC)[reply]
Thedarkknightli, not insufficient. In the case above with three editors in the discussion, this probably would have been more effective on the Dispute Resolution Notice Board (DRN[[6]]), but my apologies for implying you violated RFC:BEFORE. The advantage to utilizing DRN is that we can often come to consensus easier and use less collective WP editors' time. Penguino35 (talk) 20:48, 8 September 2025 (UTC)[reply]
I am concerned about taking this too far. For example, these seem fine to me:
|occupation=Musician |instrument=Guitar (for a person who mainly plays one instrument, but who might have other musical roles as well)
|occupation=Guitarist |instrument=Guitar, banjo, lute (for a person primarily notable for playing the guitar, but who also has significant roles on other instruments – you don't want to omit the main instrument merely because it's redundant, else people will think the person is somehow a guitarist who doesn't play the guitar)
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.
Cropping images
Has consensus been achieved that it is better to feature a cropped image of a topic's human face (possibly with their neck and a bit of torso) in infoboxes, as opposed to the original picture? Of course there are examples, such as when the featured person is shown within a group of several people, where it makes good sense, but there are other examples, where the original picture (and in some cases, even original work of art) shows the person with their body, with their clothing, within their environment etc., in my view often relevant stuff that gets lost in the cropping. (I believe a person does not just consist of a face). Anyway, since I've encountered a large number of such examples, can someone possibly link me to a discussion where this has been settled or discussed? ---Sluzzelintalk23:47, 11 May 2025 (UTC)[reply]
@Sluzzelin, I don't remember a recent discussion on this point. I've seen more discussions about the age of the subject (a recent photo for an older actor, or one from their younger days, because that's when they were most popular?) and color vs black and white.
The lead image provides visual identification, so the face is generally the most interesting part, and cropping can make the details easier to view. Full body shots drag into lower text, and MOS:SANDWICH becomes an issue if one wants to place another image right after the lead. Sometimes it's a balance when there is no ideal portrait, but perhaps a full-body action shot is deemed better than having it cropped. —Bagumba (talk) 05:03, 19 June 2025 (UTC)[reply]
I think Petra Kvitová (athlete holding a trophy she won) is a good example of a photo that isn't focused on just the person's face. I don't think there is a single rule that works in every case. WhatamIdoing (talk) 05:19, 19 June 2025 (UTC)[reply]
In this example the break ends up between "Jazz" and "Festival". It looks better with the forced break which keeps the wikilink intact. -- Cl3phact0 (talk) 20:49, 21 May 2025 (UTC)[reply]
Yes, in spite of being visually broken, the wikilink still works. One can click on either part and the result remains the same (i.e., being redirected to the Montreux Jazz Festival article), it just looks bad. From a graphic design UI perspective, it is cleaner not to break the wikilink into two parts if it can be avoided. I'm just not seeing how a non-breaking space solves this problem. -- Cl3phact0 (talk) 05:16, 22 May 2025 (UTC)[reply]
Sorry, but the link worked either way, whether the <br> was there or not. This is just an aesthetic choice - the caption looks more balanced when spread over the two lines in that way. Why is this wrong? 205.239.40.3 (talk) 09:11, 23 May 2025 (UTC)[reply]
The <br /> tag introduces manual line breaking that doesn't adapt to screen size or layout changes. Per MOS:NBSP, we prefer solutions like that preserve layout where needed without hardcoding breaks. ‑‑Neveselbert (talk·contribs·email) 23:37, 25 May 2025 (UTC)[reply]
I had assumed that the layout of the infobox was preserved so that there was no real distinction. I also thought that e <br /> tag had now been deprecated in favour of <br>. Perhaps there is a policy somewhere about infobox image captions which prevents them from being neatly centred over two lines instead of being randomly split depending on magnification size? 205.239.40.3 (talk) 13:27, 28 May 2025 (UTC)[reply]
So this may work for captions where there is a link. What about captions with no link? Is use of a break, to even up the caption over two lines, prohibited? 205.239.40.3 (talk) 07:48, 4 June 2025 (UTC)[reply]
You could also simply add the subject's forename if you're trying to show a two line caption. Hugh Laurie singing at the 2012 [[Montreux Jazz Festival]] achieves this on my display. Cheers, Cl3phact0 (talk) 09:18, 11 June 2025 (UTC)[reply]
Thank you, I have added that. Although I think captions are generally meant to be as brief as possible. I am still a bit surprised that breaks are prohibited in the caption field. 205.239.40.3 (talk) 12:17, 11 June 2025 (UTC)[reply]
Is there any logic in semantics or style to the choice between |title= vs |above= for the title of the article? (See example at right.)
@Hooman Mallahzadeh: I notice that you have been changing—or requested changing—|title= to |above= at multiple templates (including Infobox website, Infobox software, Infobox programming language, Infobox OS). Do you have a particular strategy here, or do you just believe all infoboxes should use above? I feel that when this change is done across the board we would benefit from some central discussion.
Currently MOS:INFOBOXNAME reads: The template should have a large, bold title line.
If we are going to change or set conventions, then we should make that clear at this MOS page.
To be straightforward, I am not opposed to the MOS preferring above (or title), but I would hate to see a large number of infoboxes changed by Hooman where they are able to be changed without resistance, until there are just a few holdouts that are left with title because editors at some infoboxes are sticklers, with the final results 18 months from now being an even less cohesive Wikipedia. — HTGS (talk)03:15, 26 June 2025 (UTC)[reply]
As first reason, Infoboxes should be packaged in a rectangle and placing title violates packaging for infoboxes.
My Second reason is that because after using "title", the "article name" (which is article title) is duplicated in "infobox title", this redundancy can be reduced by placing "article name" in "above" of infobox rectangle. We should not have two "same" titles in an article ("article title" duplicated in "infobox title"), therefore in infobox "title" should be changed to "above".
I mean "article title" and "infobox title" are both "title". When we use "above", then a variety of properties are used, and this boosts "feature range" of articles. Something like "Grammar range" (GRA) in IELTS which improves readability of article. Hooman Mallahzadeh (talk) 06:58, 27 June 2025 (UTC)[reply]
Can you explain “feature range”? I can’t find anything about it and I don’t understand what it is or why we would want to increase it. — HTGS (talk)20:22, 27 June 2025 (UTC)[reply]
Two same words that are repeated and both have the role (both "title")
or
Two same words that are repeated but have different roles (one "title" and the other "above")
I think the second one is more readable. But definitely, this idea needs some psychological test to be proved.
See, in IELTS the same idea exists:
We should use synonyms: We should not use the same word twice, because readability is affected.
Even if we want to repeat a sentence, it should be repeated by a different grammar to be more readable.
I think "repeat" and "redundancy" is a very bad factor in readability of text. "Repeat" should be avoided. One way to prevent repetition is using "different style", like our discussion here about "title" and "above". Hooman Mallahzadeh (talk) 04:19, 28 June 2025 (UTC)[reply]
Can you explain maybe with an example? If you’re talking about parameter names though, I don’t think that is important at all. The output for the reader is much more important. — HTGS (talk)07:28, 28 June 2025 (UTC)[reply]
No! it is not about parameter names. "above" is semantically different from "title". When we use "above" instead of "title" the repeated text has a different functionality.
Are you sure? I think "above" is semantically different from "title". If you have a different opinion, please consult original Infobox makers and make sure about that. Hooman Mallahzadeh (talk) 09:34, 28 June 2025 (UTC)[reply]
If the "article title" is exactly repeated in "infobox title" (which is not desirable), then use «above» argument, otherwise using «title» argument is accepted.
@HTGS Aside from the above discussion, I really propose that Wikipedia makes some decisions about what color and font should be used for
title
above
header
body
footer
of Infoboxes. I mean Wikipedia should make a "color and font style protocol" for different parts of Infoboxes, to make them more readable and meaningful. Maybe they should be set based on Wikidata information. Hooman Mallahzadeh (talk) 07:12, 27 June 2025 (UTC)[reply]
The distinction between a country and a regime may be clear for the French Republics, but it gets quite fuzzy elsewhere. It would be hard to have a prescriptive guideline on this. CMD (talk) 12:04, 30 June 2025 (UTC)[reply]
Simply saying "France" is usually good enough for a biographical infobox – we're providing a location, not trying to say who was in power when our subject was born or died. But there are so many edge cases (e.g. Daniel Gabriel Fahrenheit) that it might be hard to formulate and gain consensus on a MOS guideline, and its imposition might be painfully disruptive. NebY (talk) 16:15, 30 June 2025 (UTC)[reply]
Infobox on a mobile screen – 'Quick Facts'
I've recently been involved in some discussions about infoboxes. These discussions seem to become very heated at times.
I have become very supportive of the idea, because of the way an infobox is displayed on a mobile screen. And the majority of end users now seem to be accessing WP articles on mobile devices (around two thirds, I think). On a mobile device, the inclusion of an infobox means that the WP end-user does not need to scroll back and forth with their finger to find out the basic facts.
However, on a mobile screen, the infobox takes on a slightly different form. It is not really a 'box', with the text flowing around it as on a computer screen. In UX terms, it would probably be better described as a 'Dropdown Menu'. i.e. in practice, the infobox is invisible, and the end user taps on the words 'Quick Facts', and then the menu opens up below.
In other words, WP is putting the decision whether to access the IB in the hands of the end-user. Which is a good UX approach I think.
However, I suspect that many WP editors are performing their tasks on a desktop or laptop computer, and are not aware that the mobile version of the infobox works differently.
With the shift to mobiles, it's almost as if the term 'Infobox' itself is become obsolete, and something else would be more accurate, although I'm not suggesting it should be changed. To make things clearer, I am wondering whether this MoS article could perhaps emphasise the mobile device aspect a little more? merlinVtwelve (talk) 19:38, 25 July 2025 (UTC)[reply]
My experience doesn't match yours. When I open a wikipedia article on my phone, I see the first paragraph, then the infobox, then the remainder of the lead. There's no "Quick Facts" dropdown. I'm reading in a browser; are you using the app? Schazjmd(talk)20:00, 25 July 2025 (UTC)[reply]
Actually, yes, you're absolutely correct. I have realised that I am viewing in the WP app. In a mobile browser, it appears as an inline box, after the first paragraph, at least on Wolfgang Amadeus Mozart. I think the app is relatively under-utilised by WP end-users, so perhaps ignore my suggestion. merlinVtwelve (talk) 20:21, 25 July 2025 (UTC)[reply]
Flags and coats of arms
I come here following the closure of an RfC in Talk:Canada. It has been heavy dispute there whether or not to include the coats of arms of Canada on it.
I seek clear guidelines on whether the flags and coats of arms should appear on the infoboxes of articles about polities (countries, states of federal countries, regions, cities with defined local governance, etc.)
I invite you to read the aforementioned RfC, but the main points were
Support:
There is clear precedent, with articles such as United Kingdom and United States. Not including it would be an egregious case of inconsistency.
The coat of arms is an official symbol of the country and represents it. It is on par with a flag.
All blazon‐conformant interpretations are equally valid, andthe proposed coat of armsis of a high artistic quality.
Oppose:
Infoboxes are already at full capacity, it's just "infobox bloat", adding it (free or otherwise) does not provide an improvement to the infobox or article.
The Canadian Government holds Crown Copyright to the official digital render (per an NFCC discussion, that render must only be used on Coat of arms of Canada), not using the official render would misrepresent National official symbols.
The coat of arms has prohibited mark status (“Designs, logos or marks that are similar to, or that could be easily mistaken for, the official symbols are pursued by the Government of Canada as unauthorized use”). It's worth noting that the flag of Canada also has prohibited mark status.
I am asking for consensus to be established here on:
Whether the usage of flags and coats of arms is acceptable for infoboxes about the entities they represent, even if legal restrictions to the use of them apply (not copyright)
If an “official” rendering of the symbols are unavailable, if “unofficial” renderings (such as those used for coat of arms in United States and United Kingdom) are acceptable
Canada is an odd ball because of the Canadian Heraldic Authority. While both symbols are subject to restrictions on commercial use, the flag is more broadly protected by trademark law, while the Coat of Arms' protection is linked to its status as a heraldic emblem that prohibits mistaken relations ...Secretariat, Treasury Board of Canada (February 4, 2025). "Legal protection of the official symbols of the Government of Canada". Canada.ca. "The use of the Government of Canada's official symbols is restricted to the communications, operations and activities of the Government of Canada. The official symbols, shown below, including all of their design and colour variations, are protected against unauthorized use in Canada and abroad........Designs, logos or marks that are similar to, or that could be easily mistaken for, the official symbols are pursued by the Government of Canada as unauthorized use.Moxy🍁16:05, 30 July 2025 (UTC)[reply]
I have mentioned that argument here, and noted that the flag of Canada has the same protections. Many countries have similar protections for their national symbols which are not copyright, see WP:SOSUMI and {{insignia}}Coleisforeditor (talk) 16:09, 30 July 2025 (UTC)[reply]
That site is listing some prohibited marks that represent the government specifically. You can verify that the flag of Canada has the exact same classification at the Canadian Trademarks Database: flag and coat of arms.Eligibility for and protections with prohibited mark status is laid out in paragraph 9(1) of the Trademarks Act, it only prevents you from using it “in connection with a business”, e.g. as a business logo or to otherwise identify said business.Again, prohibited mark ≠ copyright. Protections like this exist in many countries and it is consensus that it does not mean an image is unfree, as explained in WP:SOSUMI. Coleisforeditor (talk) 16:41, 30 July 2025 (UTC)[reply]
As listed above the coat of arms is covered by two other copyrights. Respect for the rule of law is a Canadian value that us Canadians have been trying to uphold for two decades now. It's disheartening to say the least that other nations don't feel this way. Also very bad that we are misleading our readers about an official symbol.Moxy🍁20:59, 30 July 2025 (UTC)[reply]
As you can see, all three registered “copyrights” are actually prohibited marks. Respect for rule of law is too a Fundamental British Value. I have explained to you the restrictions, explained that it is not copyright and explained to you the precedent and consensus around this issue. Coleisforeditor (talk) 22:07, 30 July 2025 (UTC)[reply]
What you're showing us is that multiple parts of the arms are copyrighted individually..... not that we're are free to use them or mislead our readers with fake versions. Need experienced content editors involved here that understands Wikipedia's purpose. Moxy🍁22:13, 30 July 2025 (UTC)[reply]
Those are numerous representations of the same coat of arms.
Because there's a real version...... thus the user rendition is fake...we are now misleading our readers about an official symbol. This is the opposite of what Wikipedia's purpose is - that is to present factual information..... Not decorate articles with misleading images. Moxy🍁22:30, 30 July 2025 (UTC)[reply]
How come File:Coat of arms of Canada.svg is the “real one”? One branch of the Government using one render doesn't mean all other renders are “fake”, that's not how coat of arms work.
We should adhere to any copyright law for whatever country it applies to. And yes we've discussed the flag many times as well..... and came to the conclusion it's not misleading for our readers unlike the user generated version of the copyrighted arms symbol..... that if is so close to the copyrighted version should be deleted as a blatant copyright infringement. We have gotten many Canadian user renditions of the coat of arms deleted from Commons but they always come back - it's a pointless endeavor the most editors don't want to waste their time on anymore. As noted a few months ago we knew that an RFC would lead to this outcome.... that is Wikipedia being in the wrong and an FA article misrepresenting a national symbol. RFCs are not like they used to be.... now we just get votes saying it should be there - I like it - other pages have them. Well at the same time unable to address the copyright concerns raised by 50% of respondents. There's clearly no consensus here to use a misleading version.... or a version so close to the original that it's a copyright infringement.Moxy🍁22:48, 30 July 2025 (UTC)[reply]
Your accusation is inconsistent with copyright law.
A blazon cannot be copyrighted, it is a mere description of a coat of arms and is not creative enough to be copyrightable.
If I am to create a derivative work of a work in the public domain, it does not mean all other derivative works of that work are now infringing on my rights.
You keep pointing us to essay and information pages as if they are policies. So let's be more clear here. Coats of arms drawn by users based solely on the definition (blazon) without any reference to the original drawing (representation) are usually safe for upload. There is simply no way the renditions we have are not simple distortions of the original Threshold of originality#Canada. The blazon description doesn't describe exact positionings or formations as seen in these renditions. this would be an accurate representation of a blazon guessMoxy🍁23:07, 30 July 2025 (UTC)[reply]
I am not talking of them like policies, I'm mentioning them because they explain the point concisely. They are not rules, they are explanations.
Your example with the US flag is misguided. The exact positionings and formations for the US flag are described in Executive Order 10834, which is referenced by the United States Flag Code, an act of it's Congress.
I use the term blazon here broadly for the specification of the arms/flag, I apologise for any confusion.
The blazon is
Tierced in fesse the first and second divisions containing the quarterly coat following, namely, 1st, gules three lions passant guardant in pale Or, 2nd, Or a lion rampant within a double tressure flory-counter-flory gules, 3rd, azure a harp Or stringed argent, 4th, azure, three fleurs-de-lis Or, and the third division argent three maple leaves conjoined on one stem proper. And upon a royal helmet mantled argent doubled gules the crest, that is to say, on a wreath of the colours argent and gules a lion passant guardant Or imperially crowned proper and holding in the dexter paw a maple leaf gules. And for supporters on the dexter a lion rampant Or holding a lance argent, point Or, flying therefrom to the dexter the Union Flag, and on the sinister, a unicorn argent armed crined and unguled Or, gorged with a coronet composed of crosses-patée and fleurs-de-lis a chain affixed thereto reflexed of the last, and holding a like lance flying therefrom to the sinister a banner azure charged with three fleurs-de-lis Or; the whole ensigned with the Imperial Crown proper and below the shield upon a wreath composed of roses, thistles, shamrocks and lillies a scroll azure inscribed with the motto A mari usque ad mare.
Support (fwiw) - per nom and Coleisforeditor here (and b/c oppose reasons here seem unconvincing imo; user-generated heraldic stuff is everywhere on WP, just has to be accurate/obey heraldic rules afaik), but honestly I thought there was already consensus on this sort of use in these sorts of human geographic articles?, as per MOS:FLAG? - Asdfjrjjj (talk) 00:27, 17 August 2025 (UTC)[reply]
To editor Coleisforeditor: bit confused on prompt here, if you wouldn't mind clarifying? Prompt first says I seek clear guidelines on whether the flags and coats of arms should appear [added emphasis], but then says Whether the usage of flags and coats of arms is acceptable [added emphasis]. Should reads like encouragement to me (so closer to CREEP, contrary to consensus re micronations, both per Chipmunkdavis), in which case I vote oppose. Acceptable reads like licence to me (may or may not be used, MOS remains agnostic [ie no MOS change afaik]), in which case support vote remains :) - Asdfjrjjj (talk) 02:48, 17 August 2025 (UTC)[reply]
Oppose, there is no need for a rule on this, that would be WP:CREEP. I wager nobody has actually analysed all countries, states of federal countries, regions, cities with defined local governance, etc. to see if this sweeping claim is applicable to all. We have an existing consensus not to show flags in infoboxes for micronations. Regarding "The coat of arms...is on par with a flag", that may be correct for some countries in some legal senses, but it is certainly not true in a WP:DUE sense. On the international level, flags are what are attached to the front of ambassadorial cars, hoisted outside the United Nations, and included to caption children's maps of the world. On the subnational level, some polities don't even have flags. CMD (talk) 02:23, 17 August 2025 (UTC)[reply]
References in infoboxes
I disagree references are not needed in infoboxes when the content is repeated elsewhere because like anything else lacking sources, the infobox content is susceptible of being removed. I've experienced this and not everyone looks at the main body of an article for key facts that are summarized in infoboxes. If someone is only looking for a fact summarized in an infobox there is no need for them to look deeper into an article where the sources are. Volcanoguy18:07, 19 August 2025 (UTC)[reply]
Yes, people sometimes blank things because they're cited 'there' and not 'here'. But there's nothing special about infoboxes; people do this for uncited material in leads, the third time some fact is mentioned deep in the article, etc.
Finland at the time was the Grand Duchy of Finland. This was not just a regional name; it was the official designation for the autonomous state.
The guideline you cited, MOS:INFOBOXPURPOSE, emphasizes summarizing "key facts" and the "|birth_place=..., Finland, Russian Empire" is too misleading. Finland was not a province or region of Russian Empire.
I've noticed your repeated attempts to pursue this idea and insisting on adding "Russian Empire" as the birthplace for Finnish people born in the 19th century everywhere, and I must respectfully disagree with this idea.
I see that you're trying to claim that Finland didn't have its own separate identity during that period, but this isn't accurate. It's important to recognize that the Grand Duchy of Finland had its own distinct legal and administrative systems. Although it was an autonomous state of the Russian Empire, it maintained its own constitution, currency, and military, and, importantly, its own citizenship. You're repeatedly claiming that people born in Finland at that time had Russian citizenship, that's simply not true.
Adding the Russian Empire as a birthplace would be misleading and would shadow the fact that the Grand Duchy of Finland had its own separate identity, which is a crucial part of Finnish history.
Support the format "|birth_place=..., Grand Duchy of Finland, Russian Empire". There is no reason to omit Russian Empire here and using the long name for the Grand Duchy improves clarity and makes the target of the link clear (in the sense of WP:EASTEREGG).
The standard work discussing Finland's status within the Russian Empire is Jussila, Hentilä, Nevakivi (1999): From Grand Duchy to a Modern State: A Political History of Finland Since 1809. The concept of a "personal union" between Finland and the Russian state was an idea that was embraced by the Finnish elite starting from mid-19th century, and which caught wind in the late 19th century. It was never accepted by the Russian administration or the emperor. But even those promoting the idea of the personal union and a separate Finnish statehood did not dispute that Finland was a part of the Russian Empire, although they emphasized that it was not part of the Russian state. The inclusion of "Russian Empire" in the infobox is neutral with regard to that dispute, and does not take a side on whether Finland was a separate state of not. Jähmefyysikko (talk) 10:00, 17 September 2025 (UTC)[reply]
Subjects born in a city currently located in a different political entity
Maybe this issue has been discussed before, but is there a standard approach for handling cases where a person was born in a city that once belonged to a now-defunct political entity but is currently part of a different country? For example, is it appropriate to denote Erwin Nyc's birthplace as "Kattowitz (Katowice), German Empire (now Poland)"? Nehme149921:22, 10 September 2025 (UTC)[reply]
Quite appropriate… although there are several other ways we could phrase it. Local discussion and consensus can determine the best phrasing. Blueboar (talk) 22:32, 10 September 2025 (UTC)[reply]
I just came across this infobox on Seán MacEntee and I have to say it seems to be very unwieldy in terms of length. It's longer than the article, and the article is already fairly well developed and not at all a stub. To me this is a problem, but I don't see exactly where in the MOS guideline size or length of the infobox is discussed. This seems like a fairly significant oversight in our MOS guidelines for infoboxes.4meter4 (talk) 17:28, 15 September 2025 (UTC)[reply]
There shouldn't need to be a specific guideline on length as length is emergent from other properties. That box does not meet MOS:INFOBOXPURPOSE as it not only does not summarise the article, it has unique information. (Of course, it is possible that information should be in the infobox as it should be in the article, but at the moment it is not.) CMD (talk) 18:11, 15 September 2025 (UTC)[reply]
That’s a good point but I do think at some point the info box size should be considered. I don’t know anyone who would find a box of that size useful as it has become essentially a wall of text. Even if the prose of the article were to significantly expand in a commiserate way, I would find this box too detailed to be useful. The most pertinent continent is pushed way down to the bottom as well.4meter4 (talk) 18:18, 15 September 2025 (UTC)[reply]
Infobox officeholder is certainly not designed for such length. Why does "In office" need its own line for each entry, surely having the date under the title of the office is context enough? CMD (talk) 18:28, 15 September 2025 (UTC)[reply]
While you’re looking at Infobox officeholder, you might note that there is often an automatic line for “Incumbent” added that could probably be dropped in many cases. — HTGS (talk)04:45, 23 September 2025 (UTC)[reply]
Could we toughen up the language in the MOS? There are some ridiculously long infoboxes out there. In this particular case, could the less significant ministerial roles be omitted? Bondegezou (talk) 06:30, 16 September 2025 (UTC)[reply]
Where would you draw the line? I don’t hate the idea of a recommended upper limit on number of row, for example, but I would be hard pressed to find what that should be. — HTGS (talk)03:27, 23 September 2025 (UTC)[reply]
I don't think that "less is more" is always true. In particular, I think that {{chembox}} is fine, even though it is large and even though it usually contains information that IMO shouldn't be repeated redundantly in the article. We don't need articles to have sentences like "The boiling point of this metal is a 2391°C" or "This molecule was assigned the CAS number of 123456". Sometimes tables of information are the right form. WhatamIdoing (talk) 03:55, 23 September 2025 (UTC)[reply]
{{Chembox}} is an exceptional exception - thought INFOBOXPURPOSE touches on it by reference to ISO codes. It is data/information that is normally presented in tabulated format in sources, justifying the exceptional nature. Any other exception to "less is more" would, in my view, be rare but likely similar to chembox. Cinderella157 (talk) 10:13, 23 September 2025 (UTC)[reply]
I agree with @Chipmunkdavis that a maximum size is already emergent from the existing language around purpose, but also with @4meter4 that it would help in practice for us to have a recommended upper limit, since the overall principle of lead weight is much harder to grasp than "don't go beyond X length".
Measuring the length is part of the challenge, since there are factors beyond just number of lines that affect length (such as using a vertical image). Is there any way for us to easily measure the length of a given infobox? And, by extension, would it be possible to create a maintenance category for articles with very long infoboxes (similar to e.g. Category:Articles with long short description)? Figuring out that metric seems like a prerequisite for agreeing on where to set the limit. Sdkbtalk19:11, 30 September 2025 (UTC)[reply]
It’s probably just more practical to count rows and use them as a general guidance, acknowledging there are all sorts of outliers, and add something like “avoid adding more than two images/maps”. — HTGS (talk)21:04, 1 October 2025 (UTC)[reply]
I agree. A recommended number of maximum rows would probably be a good idea with a caveat that there are cases where more rows might be appropriate depending on context.4meter4 (talk) 22:14, 1 October 2025 (UTC)[reply]
Looking at Seán MacEntee, the individual items/rows aren't unreasonable or unusual. It's just that the facts happen to be (lots of different political offices, instead of a small number).
Maybe in such cases we should recommend a split infobox, so that (e.g.,) the lifelong information is in the lead but the long list of offices held is in a section about those positions?
I suspect a few of those roles could be removed. The infobox isn’t a CV, and should only really list the most important roles in depth. I would make specific suggestions, but the Irish system and names are quite foreign to me. Perhaps {{Infobox officeholder}} needs a line like “Other roles held”, or a way to display some roles in a more compact form, so that they just display the title and the term on a single line (eg: Minister for Social Welfare (1957–1961)), rather than all these “Preceded by”, “Succeeded by” that are just superfluous for minor roles. — HTGS (talk)01:21, 2 October 2025 (UTC)[reply]
The collapse option does not work on mobile devices. Per infoboxpurpose, the infobox is to summarise key information. Not all of these are key. We also have the option of using nav boxes at the bottom of the article for various positions rather than cluttering the infobox with an exhaustive list of detail - which is not what it is for. I might suggest: For a well developed article, we should avoid infoboxes that are substantially longer than the lead section and infoboxes that impinge upon the body of the article. Just because an infobox has a parameter, it does not mean that we should or must populate the parameter. The less information that an infobox contains, the more effectively it serves its purpose. The last sentence is existing text. To my mind substantially longer is > 1.5 while impinge upon the body of the article means it extends past the TOC. Cinderella157 (talk) 03:45, 4 October 2025 (UTC)[reply]
On the otherhand, rather than trying to formulate what is an infobox that is too long, perhaps we are better off trying to just fix those that are clearly too long and bloated - eg have a bot generated list of the biggest infoboxes by displayed lines. A bloated infobox is a bit like pornograpy: I know it when I see it. Cinderella157 (talk) 03:52, 4 October 2025 (UTC)[reply]
I think a bot-generated list of very-long infoboxes would be useful as a first step, whether we just use that as a to-do list of infoboxes to fix, or we use it to get a feel for what really is really too long. Unfortunately, I have no idea how to implement such a task. Perhaps a request could be made.
As for lead-to-infobox ratios, don’t we have to peg them to some pagewidth and font settings? Not to mention that this implies a well-edited lead of appropriate length. Hard to judge in many cases. — HTGS (talk)10:21, 4 October 2025 (UTC)[reply]
Yes, it would require a request. A degree of support from this discussion would go a long way in expediting the request IMO. Yes, there are variables in using a lead:infobox ratio but any attempt to quantify will have issues. I use vector legacy. Monobook uses a smaller font. My observation is that a well developed lead would be up to about 2/3 of a screen and an article with many section might have a TOC of one screen. Picking a few examples, Korean War verges on being a bit long. World War II is OK. Pacific War isn't too bad. World War I is OK. Battle of the Bulge is not good. Battle of Buna–Gona is OK. Napoleonic Wars is bad. In some cases it is the use of collages and their captions that bloat the infobox. Whether we should be using collages is another issue altogether. There are lots of infoboxes worse than the examples I looked at. Cinderella157 (talk) 03:05, 5 October 2025 (UTC)[reply]
It also depends - significantly - upon the user's setup, mainly in terms of available screen width. This in itself depends upon several factors, such as the monitor dimensions, the operating system, the browser, the skin and several other factors. Any or all of these can affect how much width there is available for prose between the left sidebar and the left edge of the infobox, although the physical length of the infobox itself will not change by much.
It might be felt that if the infobox finishes before the first heading, it won't be a problem. But consider the first example given above - Korean War - this is fine in my setup with a monitor 1280px wide, Windows 10, Firefox and Monobook, but if I switch to Vector 2022, the infobox now extends past the first paragraph of the "Names" section. --Redrose64 🌹 (talk) 09:50, 5 October 2025 (UTC)[reply]
Vector2022 is the default for desktop, and Minerva the default for mobile. We should be adjusting to these, as they will be what casual readers who are unaware they can customise their experience will encounter. As Vector2022 defaults to a fixed width, at least for desktops we can get a pretty standard calculation for the default experience in terms of length. CMD (talk) 10:30, 5 October 2025 (UTC)[reply]
Vector 2022 does not default to a fixed width. This is easily demonstrated; go to Korean War in Vector 2022, then resize your browser window. Drag the left or right edges around, and observe what happens to the text of the lead between the left sidebar and the infobox. --Redrose64 🌹 (talk) 11:10, 5 October 2025 (UTC)[reply]
Vector 2022 does has a default fixed width. The setting to disable it, which you may have done at some point, is at Special:Preferences under the appearance tab, where "Enable limited width mode: Enable limited width mode for improved reading experience" is selected by default. (Someone else might be able to tell you exactly how it is coded in, but at a quick look at the page the css class vector-feature-limited-width-content-enabled seems like it probably has something to do with it.) CMD (talk) 13:24, 5 October 2025 (UTC)[reply]
That setting isn't available for alteration when logged out, where all defaults are used; and the width still isn't fixed. Have you tried dragging the borders about? --Redrose64 🌹 (talk) 14:00, 5 October 2025 (UTC)[reply]
Yes, it is a default that applies to logged out users. Are you perhaps pulling in the screen to a very tight width with both sidebars still enabled? That will crunch the text up, but is not the intended format. Try disabling the sidebars and trying wide widths. CMD (talk) 01:04, 6 October 2025 (UTC)[reply]
I could peg the ratios proposed to infobox lines. A well developed lead would have four paras and a para of ten lines would be quite large. Hence, we could peg a long but not unreasonably long lead at a generous 50 lines. The TOCs for Korean War and Napoleonic Wars are quite long and come in at 45-50 lines. On that basis, >>100 would be bad, >100 would not be good, 75-100 would be marginal, 50-75 OK and ≤50 would be best. This would include any collapsed text. It is the most bloated boxes we should be most concerned about. Any box at >200 lines is way too big by half. Cinderella157 (talk) 00:40, 6 October 2025 (UTC)[reply]
How are you calculating line length? Napoleonic Wars has a lead of 53 lines plus 5 line breaks, including being constrained by the infobox, and the infobox still flows into most of the Overview section, and the three sidebars also in the lead then fill up the rest of the overview section. CMD (talk) 01:10, 6 October 2025 (UTC)[reply]
I was trying to put my ratio approach into terms of lines. I nominally allowed up to 50 lines for the lead and perhaps this was overly generous. A ten-line para in the lead (on general observation) is an exception and four such paras even more unusual. Of course, this is a function of my screen setup. The Napoleonic Wars has six paras. My actual count for the Napoleonic Wars is 30 lines including spaces. My understanding is that the number of lines in an infobox is not affected by the screen setup employed? I make the Napoleonic Wars infobox (less sidebars) 137 lines (± a couple). I see about 42 lines per screen on my setup. On my screen, the infobox and sidebars extend to the heading Start date and nomenclature Regardless of what we each see, I think we would both agree that it is excessively long and I would opine it is overly long by at lest half because it impinges upon the body of the article.
I switched to monobook. There is only a marginal change in the width of the infobox and the infobox now extends slightly past Start date and nomenclature. Vector (2022) squashes the text (smaller number of characters/line) so it only extends slightly past the start of the background section. Screen resolution and preferances are always going to be problematic. Cinderella157 (talk) 01:52, 7 October 2025 (UTC)[reply]
Sorry, I was counting lines in the lead not lines in the infobox. 137 for the infobox looks right. When using Vector2022 on a smaller laptop, hide the contents and tool bars to see the default size. (Bizarrely collapsing the contents bar for some reason shifts the entire thing right, but doesn't seem to change the width.) CMD (talk) 02:53, 7 October 2025 (UTC)[reply]
Infobox consolidation
What are peoples thoughts are moving infobox consolidation from an essay to this MOS? I assume that it would need a formal RFC but wanted to at least start an informal discussion and see if there are strong feelings one way or the other?
I guess my point is that right now it is just as essay and as such: essays have no official status and do not speak for the Wikipedia community. I have had at least one editor object to a TFD on the grounds that (I’m paraphrasing) infobox consolidation is just an essay, not actual policy. It would be nice to have it be actual policy to help prevent the creation of custom infoboxes that will be used on fewer than a half dozen pages (I would assume an exact number would be flushed out as part of an RFC). Thoughts? - Zackmann (Talk to me/What I been doing) 18:50, 29 September 2025 (UTC)[reply]
As a TFD closer I don't usually give the "it's not a policy" argument a ton of weight, but I don't particularly have an opinion on whether this particular essay should stay "just" an essay. Primefac (talk) 23:30, 29 September 2025 (UTC)[reply]
Hey, it’s a phone infobox! I’ve been working on those. It’s made especially hard when a page is set up for multiple varying models, and there’s a clear expectation that we cover a lot of “stats” in the infobox. I have been considering the idea of a stat-sheet box for articles like that. Happy for anyone to chime in with ideas! (Help!) — HTGS (talk)21:07, 1 October 2025 (UTC)[reply]
.PNG)
_-_Louis_the_Great_of_Hungary.jpg)
.jpg)
.jpg)
_-_The_Noun_Project.svg){kind=small}
.jpg)
_(cropped).jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.svg)
.svg){kind=link}
