Module talk:InfoboxImage/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Tracking category for URLs in image field

Discussion: Template_talk:Infobox#URLs_in_image_field

There are probably thousands of URLs in the |image= field. Would it be possible to add a tracking category? They should be removed on a regular basis and tracking them would be a big help. -- GreenC 20:49, 19 July 2024 (UTC)

Just need to update lines 146, 149, 152, 155, 158 & 161 to return a category. What do you want to call the category? -- WOSlinker (talk) 21:33, 19 July 2024 (UTC)

Does infobox emit tracking categories anywhere else? Following CS1|2 naming, Category:CS1_errors:_archive-url, it might be Category:Infobox_errors:_image a holding cell for all errors related to this module. -- GreenC 23:31, 19 July 2024 (UTC)

It only emits Category:Pages using infoboxes with thumbnail images at the moment. -- WOSlinker (talk) 06:19, 20 July 2024 (UTC)

That's a standard error category format. I would suggest Category:Pages using infoboxes with URL in image field. — hike395 (talk) 12:03, 20 July 2024 (UTC)

Let's use the word "parameter" instead of "field", since that is the term here on Wikipedia, or just leave off the last word entirely: "Pages using infoboxes with URL in image". – Jonesey95 (talk) 13:52, 20 July 2024 (UTC)

Done: Special:Diff/1186186161/1236046032 for Category:Pages using infoboxes with URL in image parameter - I included "parameter" or it could be ambiguous, such as a URL displayed in the image, which might be a concern due to spam. -- GreenC 16:02, 22 July 2024 (UTC)

There are currently around 1.1k pages in the category. A bot can easily remove the usages. I wonder if a bot could also upload the image from the file and set it (if we want to use those images). Checking each page individually, seems tedious for something that no one cared to fix until now. Gonnym (talk) 13:34, 7 August 2024 (UTC)

Uploading images (automatically) is impossible due to copyright and descriptive issues. Simply deleting any URL found in the field is the correct action. The deletion is easy, the harder aspect is what the parameter names are to target. There are so many variations. -- GreenC 14:17, 7 August 2024 (UTC)

If it's a good-faith, but malformed, attempt to bring in an existing image hosted on Commons or English Wikipedia, such as

|image=https://en.wikipedia.org/wiki/File:Example.jpg

or

|image=https://upload.wikimedia.org/wikipedia/en/a/a9/Example.jpg

I think we should not delete the link outright, but fix it up as in

|image=Example.jpg

with preview before save to ensure that it's a suitable image for the context. --Redrose64 🌹 (talk) 20:52, 7 August 2024 (UTC)

Yeah good point could check. Do you know a way to determine what template parameter names the module is used in? We know of |image=, there are probably dozens of others. Need to know for parsing. -- GreenC 21:49, 7 August 2024 (UTC)

There are about 1,000 pages in the category right now. I expect that if you scanned for |image= and |logo=, you would get 90% of them, and then we could see what other parameters are being used. – Jonesey95 (talk) 22:23, 7 August 2024 (UTC)

We should remove a couple namespaces from the tracking category: User:, User talk:, and Talk: .. these can have legitimate use cases, as a temporary scratch/working space. I would do so as in here Special:Diff/1236998268/1237154439 but I don't know the correct text string for these namespaces. Anyone know? @Hike395, Gonnym, and WOSlinker: -- GreenC 15:56, 8 August 2024 (UTC)

Probably the names used here. I'm not sure about the impact changing this would have for other tracking if they want it or not. As an aside, it seems its still better to comment out usages in those namespaces as the URL link won't ever work anyways. Commenting it out makes it clear that such a thing isn't working. Gonnym (talk) 16:36, 8 August 2024 (UTC)

Given the minimal population of non-mainspace pages in the category, I would just wrap the categorization in {{main other}} and not worry about User and Talk and other pages. I don't know how to do that in a module though. – Jonesey95 (talk) 17:17, 8 August 2024 (UTC)

I don't see any edits made to the module, but pages with the issue are disappearing from the category. See Renato Valente. Gonnym (talk) 18:05, 8 August 2024 (UTC)

The category is empty: Category:Pages using infoboxes with URL in image parameter. I certainly fixed a lot/most, but some should still be there eg. Renato Valente or User talk:Sundaycomedian/sandbox. Something weird. -- GreenC 18:36, 8 August 2024 (UTC)

The issue was a bug with the boolean check. WOSlinker fixed it before I got to it. Gonnym (talk) 19:22, 8 August 2024 (UTC)

Ah ok cool. I processed what was remaining in the tracking category, it should be cleared out. Ahh, it's filling up with new pages.-- GreenC 19:26, 8 August 2024 (UTC)

Add |style for customising CSS style of the image

Useful for dark mode compatibility. It would allow setting |class=notheme |style=background-color: #f8f9fa; to add a white background to a image. Template:Infobox provides |imageclass= |imagestyle= but it also changes the class and style of the caption, which is not desired.

Example with ISBN:

Current best compromise:

Example 13-digit ISBN
Initialism	ISBN
Organisation	International ISBN Agency
Introduced	1970 (1970)
No. of digits	13 (formerly 10)
Check digit	Weighted sum
Example	ISBN 978-3-16-148410-0
Website	isbn-international.org

Desired:

Example 13-digit ISBN
Initialism	ISBN
Organisation	International ISBN Agency
Introduced	1970 (1970)
No. of digits	13 (formerly 10)
Check digit	Weighted sum
Example	ISBN 978-3-16-148410-0
Website	isbn-international.org

Susko3 (talk) 00:48, 26 November 2024 (UTC)

@Susko3: Why are you prototyping this here, and not at the appropriate sandbox and testcases pages? --Redrose64 🌹 (talk) 07:51, 26 November 2024 (UTC)

Also, style is not listed as an image parameter at Wikipedia:Extended image syntax. -- WOSlinker (talk) 08:10, 26 November 2024 (UTC)

Other size parameters cause upright to be ignored

With the current implementation of this module, the upright parameter is ignored if the maxsize or sizedefault parameters are defined. This appears to be because image syntax ignores upright if a size in pixels is defined. It means that if either of those parameters are used in an infobox template (see {{Infobox bridge}} for example), then it's not possible to use the upright parameter at all in articles, which is not the intended behavior.

I don't have the Lua skills to do so, but I think the module should be rewritten so that a pixel size is not passed if the upright parameter is used and the size parameter is not. Pi.1415926535 (talk) 03:27, 30 May 2025 (UTC)

I think there are two separate cases to consider:

1. Both |upright= and either |maxsize= or |sizedefault= are specified
2. Both |upright= and |size= are specified

In the first case, I think the current module behavior is likely incorrect -- the caller specified a size via |upright= and it's being handled as if no size was specified. The second case is less clear, because conflicting sizes are being provided. I'm reluctant to change the current behavior for the second case, because there may be unintended consequences to the 5M articles that use this module.

Of course, fixing the incorrect behavior also may have unintended consequences, also, so we should be careful. For example, the proposed behavior now allows people to set absurd values to |upright= and there is no check or limit.

I've modified the sandbox to fix the first issue, and updated the tests to exercise the new code. Pinging @WOSlinker to see if they have any comments on the change: other editors are also welcome to comment. — hike395 (talk) 09:17, 30 May 2025 (UTC)

Later: I added some logic to ensure that |upright= doesn't produce an image larger than |maxsize=, assuming the default user preference. This fixes one potential issue. Updated sandbox and testcases. I'm hoping some other templateeditor or admin takes a look at the diff. — hike395 (talk) 10:01, 30 May 2025 (UTC)

@Hike395: Thanks for looking into this! Just to clarify - will this still allow an image scaled with upright to be larger than maxsize if the user preference is set to a larger-than-default value? That seems important for accessibility reasons. Pi.1415926535 (talk) 16:09, 30 May 2025 (UTC)

Yes: if upright is specified, then maxsize will scale with the user's default image size. So if maxsize=300, and the user's preferred thumbnail size is set to 300px, then the output image will be limited to be less than 300*300/220 = 409px for that user. There's no way to avoid this. — hike395 (talk) 00:39, 31 May 2025 (UTC)

Great, that is the behavior I believe it should have. Pi.1415926535 (talk) 00:45, 31 May 2025 (UTC)

To the original observation the upright parameter is ignored if the maxsize or sizedefault parameters are defined. This appears to be because image syntax ignores upright if a size in pixels is defined: this is expected behaviour, and is documented at WP:PICSIZE, inside the "Implementation details" box (direct link), last paragraph. --Redrose64 🌹 (talk) 13:39, 31 May 2025 (UTC)

@Pi.1415926535 and Redrose64: Picking this back up. My sandbox edits do not contradict WP:PICSIZE. If a absolute size and an upright are both specified, then the absolute size is used. What I did was scale maxsize and sizedefault relative to the user preferred image size. Those two parameters are only defined in this module: WP:PICSIZE does not discuss them.

Is it ok to promote the sandbox to main? I see that since this edit, Pi.14 has removed maxsize and sizedefault from a number of infoboxes. It would be good to restore those, if I can promote sandbox to main. — hike395 (talk) 08:48, 5 August 2025 (UTC)

@Pi.1415926535 and Redrose64: Any comments or thoughts before I propose this as an edit? Pppery just fully protected this Module, so I can no longer edit it, so even a simple support/agree would be helpful. — hike395 (talk) 14:46, 12 August 2025 (UTC)

To be clear, my full protection was completely unrelated to this dispute, which I didn't even know existed; if you look at my edits at the time I adjusted the protection level of hundreds of templates. * Pppery * _{it has begun...} 17:35, 12 August 2025 (UTC)

If I'm understanding correctly what your edit does, I support it. I'm confused about your statement Pi.14 has removed maxsize and sizedefault from a number of infoboxes - to my knowledge, I haven't edited any infobox templates to remove these. Pi.1415926535 (talk) 05:12, 13 August 2025 (UTC)

@Pppery: apologies. I didn't mean to imply causation here -- I just wanted to point out that I can no longer edit the template directly.

@Pi.1415926535: more apologies. I recall seeing edits to infoboxes which removed maxsize and sizedefault, but now I cannot find them to check who did them. — hike395 (talk) 12:33, 13 August 2025 (UTC)

Edit request

Please copy Module:InfoboxImage/sandbox to Module:InfoboxImage

This is a change in handling the case where |upright= and either |maxsize= or |sizedefault= is specified. In this case, the sandbox version obeys |upright=, but if it exceeds maxsize/220, then it is set to maxsize/220. The current behavior is to ignore |upright= when either |maxsize= or |sizedefault= is specified, which is incorrect.

This edit does not change any behavior if |upright= is not specified. Also, if |size= and |upright= are both specified, the behavior remains unchanged: |size= is obeyed in that case.

Are you sure that this description is correct? On the testcases page, I am seeing the Mustela image with

upright=1.5|sizedefault=272|maxsize=300

. The live module renders the image at 1.5x my thumbnail size. The sandbox image is rendered at 272px. This seems to be the opposite of the description above, if I am reading it correctly. It also seems to be a fix that helps the module to match normal image rendering (px is preferred over upright). Is this what you want? – Jonesey95 (talk) 17:01, 15 August 2025 (UTC)

You may be interpreting the unit tests backward? Here are the results when main and sandbox are called with the case that you are highlighting:

{{subst:#invoke:InfoboxImage|InfoboxImage|image=Mustela erminea upright.jpg |upright=1|sizedefault=272|maxsize=300}} →

{{subst:#invoke:InfoboxImage/sandbox|InfoboxImage|image=Mustela erminea upright.jpg |upright=1|sizedefault=272|maxsize=300}} →

Here, the main module is generating a pic with size=272px, while the sandbox module is generating a pic with upright=1 (rendered at your preferred size). So the logic is correct.

The logic has not changed when both size and upright are specified. They are both emitted and MediaWiki prefers size over upright:

{{subst:#invoke:InfoboxImage|InfoboxImage|image=Mustela erminea upright.jpg |upright=1|size=200}} →

{{subst:#invoke:InfoboxImage/sandbox|InfoboxImage|image=Mustela erminea upright.jpg |upright=1|size=200}} →

— hike395 (talk) 17:18, 15 August 2025 (UTC)

Indeed, I do not understand what "Expected" and "Actual" refer to on that page. I'm used to seeing the live template followed by the sandbox, with appropriate headers to match. In that case, and based on the apparent consensus above, I have no objections. It looks like this change will require an administrator, which I am not. – Jonesey95 (talk) 17:25, 15 August 2025 (UTC)

@Redrose64: Do you object to this request? * Pppery * _{it has begun...} 19:48, 15 August 2025 (UTC)

I'm not a Lua expert, and have never claimed to be. --Redrose64 🌹 (talk) 22:18, 16 August 2025 (UTC)

 Done * Pppery * _{it has begun...} 04:35, 17 August 2025 (UTC)