Talk:Phineas Gage

Odd citation style

Is there a reasoning behind the strange citation style of this article? Why are some references demarcated by their "difficulty" while the others are listed as usual? Besides this, surely the letter system does not work as well as a normal style, as you cannot click the citation in the References section to see where a source appears in the main body? Medarduss (talk) 23:18, 24 January 2023 (UTC)

All I know is this is EEng's child. – The Grid (talk) 23:46, 24 January 2023 (UTC)

I assume that defaults to "not going to be changed"? ~Styyx^Talk? 00:44, 25 January 2023 (UTC)

More accurately, it means "will be changed if the editors who actually care about the article reach a consensus that some other approach will better serve the reader's understanding, but won't be changed just because some drive-by editor thinks all articles should look the same." As to the original question:

• The For general readers section, the For younger readers section, and the For researchers and specialists section identify sources which will be particularly useful to readers in those groups who want to learn more about the article topic. The Other sources cited section lists sources which, well, will not be particularly useful to those who want to learn more.
• The {{ran}}/{{rma}} referencing system allows sources to be organized in logical, useful ways instead of the chaotic, random mish-mash seen in most articles.
• Where a source appears in the main body is trivially found simply by text-searching for e.g. [M].

Quite substantial discussions (found primarily in Talk:Phineas_Gage/Archive_2) led to the decision to do things the way they're done. Any other questions? EEng 09:03, 25 January 2023 (UTC)

[Solved] Bug Report: The ran callout links are inactive on mobile site.

I first encountered {{ran}} on this page and see more discussion of it here than on the template page.

The template which creates the manual superscript has a bug on the Minerva theme used by the mobile site. You can see it if you use these links:

1. https://en.wikipedia.org/wiki/Phineas_Gage?useskin=Vector2022
2. https://en.m.wikipedia.org/wiki/Phineas_Gage
3. https://en.wikipedia.org/wiki/Phineas_Gage?useskin=Minerva

In each link try clicking the superscript callout links. In the first link, the desktop site has a tooltip and a functional link to References. The second and third links show the bug.

On the second link, the mobile site callouts for {{ran}} do nothing when clicked. The superscript callouts created by {{r}} and {{refn}} on this page will cause a popup with the reference. The popup is the expected behavior. The links from < ref >, {{efn}}, and {{sfn}} all create popups. The {{citeref}} template is slightly different and works on mobile the same way that it works on the desktop site (visible in the Notes section on: https://en.m.wikipedia.org/wiki/Computer_mouse ); the superscript works as an in-page anchor link with {{citeref}}.

In the third link, the mobile skin (Minerva) is used on the desktop site. The tooltip still works, but something in Minerva breaks the link regardless of the desktop or mobile version.

I hope that this helps and that it is not a strange place to post a bug report. Rjjiii (talk) 02:27, 6 February 2023 (UTC)

This is above my pay grade. I suggest you post this at WP:VPT. EEng 04:04, 6 February 2023 (UTC)

Thanks for pointing me in the right direction! Rjjiii (talk) 04:25, 6 February 2023 (UTC)

Just updating this thread. The rma/ran references now function on mobile. To implement a workaround, I needed to add "CITEREF" to the handwritten links on this article's references. As an unplanned bonus, those links now create the popup reference on desktop themes/browsers.Rjjiii (talk) 00:21, 24 May 2023 (UTC)

A belated thanks for taking care of this. EEng 01:22, 3 September 2024 (UTC)

MOS:SANDWICH

A recent edit to resolve MOS:SANDWICH issues[6] causes confusing placement on widescreen monitors. For example, it pushes the "Distinguished Arrivals" newspaper clipping (about a living Gage) down into the section where his skull is exhumed. And so in fixing one MOS issue, it causes a new one (MOS:SECTIONLOC). Wikipedia:Image use policy says, "The relevant aspect of the image should be clear and central." Sandwich concerns probably have to be waved on image-heavy articles like this to ensure the relevance of the image is clear to the reader. Rjjⁱⁱⁱ (talk) 16:07, 24 August 2024 (UTC)

Rjjiii, you took the words right out of my mouth. ActivelyDisinterested: re your edit summary here [7], I wrote SANDWICH so I don't need to "see" it, and the article's had this exact same layout for at least 5 years, and very much the same layout for 10 years, and you're the first person to claim there's an actual problem. If you'll specifify at what platform, resolution, and zoom level you're seeing the issue, and describe it more precisely, then maybe we can solve it. But the current layout it looks fine on laptops (with two different browsers), on WP's mobile simulator, on my own tiny-screen Iphone, and on a friend's Android just now. We're not going to mess that all up because you preceive the text column as narrow on one particular configuration you haven't specified. EEng 19:35, 2 September 2024 (UTC) P.S. I appreciate your fixes to the cite formats!

Not really, as I said spacing Eth images out would likely be the best option. But I'm not invested enough to stand in the way if you want to go another route. -- LCU ActivelyDisinterested «@» °∆t° 21:33, 2 September 2024 (UTC)

Spacing the images out seems likely the best option until you actually read the article and see why the images are where they are, at which point you realize that blindly spacing everything out in obeisance to a cookie-cutter guideline meant to be applied with common sense solves a trivial problem seen by, apparently, one person in ten years, but introduces a serious problem for everyone else. Unfortunately there's no route to go in if you won't tell us what you're seeing, on what platform. EEng 01:32, 3 September 2024 (UTC)

the article's had this exact same layout for at least 5 years, and very much the same layout for 10 years, and you're the first person to claim there's an actual problem

I think that the sandwich has become thinner recently despite no changes to the article, with the deployment of Vector 2022, and then the deployment of increased font size on it very recently. For example, here are two screenshots taken on a 1920x1080 screen, which is still the most common desktop resolution according to [8], as a logged-out user with all default settings (I tried to find the most sandwiched parts of the article):

• Phineas Gage#New England and New York (1849–1852): https://phabricator.wikimedia.org/F57439065
• Phineas Gage#Portraits: https://phabricator.wikimedia.org/F57439085

I agree that just moving all images to the right side is not a good solution, for the reasons you said. Perhaps you might come up with a better one, though. I would consider moving some of the wider images to galleries, or making the images and pull quotes centered, instead of having them float around text. Matma Rex talk 22:13, 3 September 2024 (UTC)

In my opinion, MOS:SANDWICH should be understood as a guideline but not a policy, because that's what it is. For this particular page, there are a lot of images, but they all serve good encyclopedic purposes. And they don't really lend themselves to being grouped into galleries. (Perhaps, there might be a few places where Template:Multiple image could be used to good effect.) But I don't think this is an urgent problem. --Tryptofish (talk) 22:24, 3 September 2024 (UTC)

• (Sorry, I missed these later posts until now.) Matma Rex, I appreciate the screenshots; leave it to the geniuses at WMF to throw away 30% of the screen real estate on some stupid buttons. The density of images is greatest in the accident/treatment/injuries section, and the challenge there is it's tough for readers to understand the circumstances of the accident, and the mechanics of Gage's injury, without these images at hand -- if they're somewhere else I fear the reader is lost. Nonetheless I mocked up a gallery for the early sections, but it came out awful [9]. I just don't see how to do it without some images being too big or small, and far from the relevant text.
  Tryptofish, I'd be interested to hear your thoughts about how {multiple images} could be used. EEng 03:01, 14 September 2024 (UTC)

I haven't gotten to the point of having specific place(s) on the page where I would recommend it, but the general idea is that sandwiching can often be eliminated by combining related images together, instead of having them stand-off opposite one another on the page. (You can see a sample of how I did that, at Sissinghurst Castle Garden#Roses.) If there are places on this page, where you feel that it makes sense, thematically to group any images together (and only if it makes sense), and if they are creating sandwiched text, then that would be where to look. --Tryptofish (talk) 23:43, 14 September 2024 (UTC)

Dimensions

Hello eeng, I think the edit I did on this page was perfectly reasonable for readers who live outside the USA. The number I corrected was the diameter of the “tamping iron”not the hole. It’s normal to have a whole number which is the reason the Wikipedia MOS has centimetres for height instead of metres or millimetres, which is also the norm worldwide, so 32 mm instead of 3.2 cm would be normal outside the USA. The point of the tamping iron in the article is in millimetres. 6.0 kg suggests a very accurate conversion, You would not say I weight 200.0 lbs if it were converted the other way around, It’s a superfluous zero. Avi8tor (talk) 10:25, 14 September 2024 (UTC)

Your edit was indeed "reasonable", but I don't think it best serves the reader's understanding:

• The number I corrected was the diameter of the “tamping iron, not the hole – No, you changed the units for both the diameter of the tamping iron and the diameter of the blast hole from cm to mm; and the distance to town from km to m. You also reduced the converted precision of the weight of the tamping iron from 6.0kg to 6kg.[10].
• It’s normal to have a whole number which is the reason the Wikipedia MOS has centimetres for height – No, MOS uses centimeters for height because that appears to be the common practice in English-speaking countries where SI is used for heights. If those countries used meters for height, we'd use meters for height; whole numbers versus decimals has nothing to do with it.
• 6.0 kg suggests a very accurate conversion ... It’s a superfluous zero – No it's not. The original value is given to the nearest 1/4 lb, which is just slightly more than 0.1kg. Thus converting to 6.0kg is appropriate.
• With regard to the diameters, the 1-3/4 inch figure for the blast hole is a rough generality, and reporting 44.5mm (as you have it) is ridiculous overprecision, and even 44mm implies an innapropriately high precision, which 4.5cm does not. As for the 1-1/4 inch figure, while 32mm and 3.2cm are technically identical, the mm version carries (again) a sense of innapropriately higher precision than does 3.2cm, and it's best that both diameters use the same units.
  As to the point being in mm, the precision of the reported value of 1/4 inch is uncertain, so on reflection, converting to 0.5cm (instead of 6mm) seems more appropriate, and consistent with the use of cm for all the other stuff.
• Finally, converting the 3/4 mile journey to 1200m is absolutely false precision -- 1.2km is obviously what's appropriate.

I've edited the article to change the 6mm to 0.5cm. EEng 18:26, 14 September 2024 (UTC)

People who live in a metric world (as 95% of the planet do) would not talk about 0,5 cm, they would talk about 5 mm, one is no more accurate than the other. The centimetre is pretty common in the US as the equivalent to the inch, but not with the rest of the planet deal with only metric units and not conversions. Your interpretation serves a US audience, mine serves the reader who uses only SI. From my house to my village is 1,1 km on my vehicle odometer, but if I talked to someone I would say 1100 metres. Height is given in centimetres because it's a whole number, stated as height in passports worldwide. If I published your weight as 200.0 lbs (I've got no idea of your weight, it's a random choice), you would wonder why the decimal? Avi8tor (talk) 19:34, 14 September 2024 (UTC)

I cannot find the reference in the article to the blast hole, but do see it in the changes to the article. I did change it to millimetres, however in the convert template was round=0.5 which gave it the same (unneeded) accuracy in millimetres as centimetres. I should have removed the round=0.5, placed there by a previous editor. Avi8tor (talk) 19:58, 14 September 2024 (UTC)

Ctrl-F blast hole and you'll find it.

For the rest: I'm sorry, but these are just your claims about what's collquially done in your personal experience, and anyway articles aren't colloquial. Giving a distance as 1100m certainly suggests a precision not implied by 1.1km, and unjustified in the case under discussion. Your comments about personal height and weight are irrelevant because we're not talking about people's heights and weights. You're also confusing accuracy with precision. EEng 20:09, 14 September 2024 (UTC)

True these are from personal experience from my life in countries that use SI, but your replies are your opinion. Avi8tor (talk) 14:03, 15 September 2024 (UTC)

If you don't understand that 1100m implies greater precision than does 1.1km, then I'm afraid there's no purpose in continuing this conversation. EEng 20:56, 15 September 2024 (UTC)