:: {{u|Pi.1415926535}}, {{u|Famartin}}, {{u|Magnolia677}} it would seem they would prefer to continue disregarding, and start an edit war. - [[User:TheLionHasSeen|TheLionHasSeen]] ([[User talk:TheLionHasSeen|talk]]) 16:33, 23 May 2023 (UTC)
:: {{u|Pi.1415926535}}, {{u|Famartin}}, {{u|Magnolia677}} it would seem they would prefer to continue disregarding, and start an edit war. - [[User:TheLionHasSeen|TheLionHasSeen]] ([[User talk:TheLionHasSeen|talk]]) 16:33, 23 May 2023 (UTC)
:::Let me sit this here: [[File:Blank space with all images to the right.jpg|right|thumb|Messed up formatting by placing every single image to the right, under two infoboxes which already take up space]]. - [[User:TheLionHasSeen|TheLionHasSeen]] ([[User talk:TheLionHasSeen|talk]]) 16:37, 23 May 2023 (UTC)
:::Let me sit this here: [[File:Blank space with all images to the right.jpg|right|thumb|Messed up formatting by placing every single image to the right, under two infoboxes which already take up space]]. - [[User:TheLionHasSeen|TheLionHasSeen]] ([[User talk:TheLionHasSeen|talk]]) 16:37, 23 May 2023 (UTC)
::::Let me further add, stop acting as if you have ownership of the article as well. - [[User:TheLionHasSeen|TheLionHasSeen]] ([[User talk:TheLionHasSeen|talk]]) 16:39, 23 May 2023 (UTC)
I noticed you deleted the gallery to this article. I'd suggest that some photos of his buildings be included somewhere in the article, either as a gallery or aligned with the text. Although Wikipedia discourages galleries, the "visual arts" are listed as an exception. ("Some subjects easily lend themselves to image-heavy articles for which image galleries are suitable, such as plants (e.g., Lily), fashion (e.g., Wedding dress), and the visual arts (e.g., Oil painting)." [1].)
Perhaps this is a situation where more images in the article are appropriate. I notice that for some architects, the photos of their work form a column at the right edge, which would be another approach. Canadian2006 (talk) 04:16, 19 January 2023 (UTC)[reply]
I have reverted your edits to Marysville, Washington, because they introduced several grammatical and factual errors. "Downtown" should not be capitalized for cities that do not have a significant enough core that warrants their own article; removing "City of" in front of Marysville leads to confusion between the city as a place vs. the city government as an entity; and highways within their own state do not need to be disambiguated, especially with a postal code. SounderBruce22:43, 2 January 2023 (UTC)[reply]
It is currently listed variously as downtown Marysville and Downtown Marysville. There should be consistency whichever one is used. Since you reverted my correction of that, please also ensure it is standardized throughout the article. Keystone18 (talk) 22:45, 2 January 2023 (UTC)[reply]
Image sizes
Hi Keystone18, is there a reason you have been adding |upright=1.1 on images (such as here)? Per MOS:IMAGES, image thumbnails should be the default size unless there is a compelling reason to do so. If you simply prefer larger images, you can change that on the "Appearance" tab under Special:Preferences. Cheers, Pi.1415926535 (talk) 23:36, 30 January 2023 (UTC)[reply]
Actually you do this all the time, in seemingly every article you edit. And its not necessary. MOS specifically states:
"Where a smaller or larger image is appropriate, use |upright=scaling factor, which expands or contracts the image by a factor relative to the user's base width. For example: upright=1.3 might be used for an image with fine detail (e.g. a map or diagram) to render it "30% larger than this user generally wants". (For a reader with the usual base width setting of 220px, this is 285px.) upright=0.6 might be used for an image with little detail (e.g. a simple drawing or flag) which can be adequately displayed "40% smaller than this user generally wants". (For a reader with the usual base width setting of 220px, this is 130px.) Short, wide images often call for upright of 1 or greater; tall, narrow images may look best with upright of 1 or less."
You, however, apply an upright 1.1 to virtually every photo in every article, which is absolutely not appropriate. Thus, you are actually ignoring MOS:IMGSIZE, not following it. Its rarely necessary to force a larger image in an article since simply clicking on an image will bring up a much larger version. Meanwhile, forcing larger images reduces space for text. Thus, I would strongly suggest you cease and desist with adding upright 1.1 to every image. Famartin (talk) 02:53, 28 April 2023 (UTC)[reply]
Maybe I should make myself more clear... upright images for no good reason in articles I've edited from this point forward will be rolledback. Famartin (talk) 02:55, 1 May 2023 (UTC)[reply]
DUDE... first, try engaging us, but I get it, you can't, because we've already proven you wrong. Give it up. You don't need to upright images in MOST cases. Lay off. I've been here far longer than you, I can keep this up. Famartin (talk) 19:37, 1 May 2023 (UTC)[reply]
First, I did engage you with a lengthy, multi-point post on your user page. Second, what is this? I cited the policy on images. In the cases you cite, 1.1 was and is both reasonable and warranted and probably the best image setting. Third, where is this policy you (wrongly) cite that "you don't need to upright images in MOST cases."? Direct me to that because MOS:UPRIGHT reads, and I quote: "upright=scaling factor is preferred whenever possible." And, finally, I'd again ask that you stop your combative interactions with me and others. Keystone18 (talk) 19:59, 2 May 2023 (UTC)[reply]
That is a misreading of the actual policy - the context is Except with very good reason, a fixed width in pixels (e.g. 17px) should not be specified. This ignores the user's base width setting, so upright = scaling factor is preferred whenever possible. It is not saying to always use "upright" - it is saying that it is the proper method when a non-default size is needed. That should be made clear by a later bullet point: Where a smaller or larger image is appropriate, use | upright =scaling factor... There is no reason to use non-default sizes for the vast majority of images - and you have failed to provide any policy-based justification to do so - and you have continued to do this despite at least three different users asking you to stop. Pi.1415926535 (talk) 20:11, 2 May 2023 (UTC)[reply]
I am not specifying a fixed width in pixels. Doesn't apply. Everything else in the policy is encouraging of the use of upright imaging, and in none of these cases was a non-default size needed. Keystone18 (talk) 20:34, 2 May 2023 (UTC)[reply]
Keystone18, may you also stop moving every single image to the right on articles, such as Pennsylvania? In a latest edit, you didn't even respond to the changes days ago, and moved everything back to the right. There's nothing wrong with images to left when it saves content from being pushed down into other sections of articles, and adding unnecessary white space. Is this being an issue here overall with you and images, to where something must be done? Pi.1415926535, Famartin, Magnolia677, any input on this as well; is there ever going to be a point of taking this to the administrators here? - TheLionHasSeen (talk) 14:39, 22 May 2023 (UTC)[reply]
The opening sentence from MOS:IMAGELOC: "Most images should be on the right side of the page, which is the default placement. Left-aligned images may disturb the layout of bulleted lists and similar structures that depend on visual uniformity, e.g. by pushing some items on such lists further inward. Hence, avoid left-aligned images near such structures." Keystone18 (talk) 16:31, 22 May 2023 (UTC)[reply]
Key word is 'most'. You placed ALL the imagery to the right; the imagery moved to the left by me does not push the bullet lists or similar structures neither on desktop nor mobile - TheLionHasSeen (talk) 18:23, 22 May 2023 (UTC)[reply]
Yes, meaning there needs to be a compelling reason not to place it on the right. Your placements are entirely arbitrary and, as a result, violate the guidance. Keystone18 (talk) 19:40, 22 May 2023 (UTC)[reply]
There are no sandwiched images in any of the examples you're mentioning to my knowledge. There is, on the Pennsylvania page, a gap at the top of the page visible on a cell but not on computers that persists regardless of image positioning. I've seen a similar gap on a cell on other major pages. And I'm not looking for confrontation with you. Your prior recommendation on upright imaging, I think, was a good one, and I've adopted it, primarily using regular imaging since our interaction and since evaluating it. It was a good suggestion, despite the fact that these policies are poorly written and open to varying interpretations. On this issue, I want what's best too but am not seeing how your proposal of moving any image to the left is resolving the sandwiched images. In fact, I'm not seeing any sandwiched images at all. Share those with me, if you can, and let's wormk together for the best conclusions. Keystone18 (talk) 00:06, 23 May 2023 (UTC)[reply]
You are not looking for confrontation, yet your contributions in reverting with poor summaries and arguments states otherwise. How long will it take before you are censured? - TheLionHasSeen (talk) 03:33, 23 May 2023 (UTC)[reply]
Let me sit this here: Messed up formatting by placing every single image to the right, under two infoboxes which already take up space. - TheLionHasSeen (talk) 16:37, 23 May 2023 (UTC)[reply]
I notice that you have undertaken a number of edits on this article. Perhaps you have some local knowledge, or know where to locate the same, that might provide an answer to a query I posted on the article's talk page almost two years ago under the heading 'Speakeasy Blues Club'. Thanks, - Derek R Bullamore (talk) 23:51, 19 February 2023 (UTC)[reply]
Disambiguation link notification for March 7
An automated process has detected that when you recently edited Blast furnace, you added a link pointing to the disambiguation page Newbridge.
Please don't remove non-breaking spaces between numbers and unit symbols, like you did in this edit to Rhine. Doing so is contrary to the general guidelines on use of units at MOS:UNITSYMBOLS; Use a non-breaking space ({{nbsp}} or ) between a number and a unit symbol, or use {{nowrap}}. Thank you. XAM2175(T)22:04, 18 May 2023 (UTC)[reply]
