Module talk:InfoboxImage

UPDATE PROFILE IMAGE

Please change the profile photo to the following image https://commons.wikimedia.org/wiki/File:Walter_Masterson.jpg Wikispiraling (talk) 23:54, 24 November 2025 (UTC)

@Wikispiraling: This page is for discussions concerning use and development of the module Module:InfoboxImage. I can only assume that you are intending to ask for the image you have mentioned to be put in the article Walter Masterson; if so the request belongs in the talk page of whatever article that is, not here. JBW (talk) 00:04, 25 November 2025 (UTC)

Discussion at Template talk:MergedMap

 You are invited to join the discussion at Template talk:MergedMap. -- Joy (talk) 12:48, 27 November 2025 (UTC)

Captions

Is there a reliable way to get captions from wikidata? I don't think this module deals with captions at all, which is surprising. We have an issue on Template:Infobox martial artist where the caption is not always matching the image. This module was using the preferred image but Module:Wikidata was taking the caption from a different image — Martin (MSGJ · talk) 09:23, 6 January 2026 (UTC)

That infobox is checking the image and caption params independently.

{{if empty|{{{image|}}}|{{#invoke:Wikidata|claim|P18}}}}
{{if empty|{{{caption|}}}|{{#invoke:Wikidata|getImageLegend|FETCH_WIKIDATA}}}}

Maybe needs to check both params are empty before using any wikidata values?

{{#ifeq:{{{image|}}}{{{caption|}}}||{{#invoke:Wikidata|claim|P18}}|{{{image|}}}}}
{{#ifeq:{{{image|}}}{{{caption|}}}||{{#invoke:Wikidata|getImageLegend|FETCH_WIKIDATA}}|{{{caption|}}}}}

WOSlinker (talk) 10:04, 6 January 2026 (UTC)

Protected edit request on 26 March 2026

Please remove the images.it is misleading it's not real.thanks Abidthegreat (talk) 07:28, 26 March 2026 (UTC)

This is the wrong place for this request. I would suggest that you start a conversation at Talk:Malik ibn Anas. -MPGuy2824 (talk) 10:58, 26 March 2026 (UTC)

Proposal: Performance optimization, data restructuring, and bug fixes for InfoboxImage

I would like to propose a comprehensive update to Module:InfoboxImage and its data submodule Module:InfoboxImage/data. The goal is to improve performance (especially on long articles with multiple infoboxes), fix a silent bug regarding alt text validation, and structure the data layer according to Lua best practices in MediaWiki.

I have prepared and tested the updated code in the local sandboxes. Here is a breakdown of the key improvements:

1. Core Module Optimization (Module:InfoboxImage/sandbox)

• File Namespace Caching (Performance): The current production code queries and rebuilds the file namespace aliases table via `mw.site.namespaces[6]` twice on every single invocation (once inside `IsPlaceholder` and again in the main function body). On long pages or transclusions, this creates unnecessary overhead. The proposed version builds this namespace cache list exactly once at the top-level scope during the initial module load.
• Redundant Code & Asserts Cleanup: Removed several `assert(image ~= nil)` checks right after `mw.ustring.gsub`. In the Scribunto environment, these standard string operations never return `nil` when provided with valid string inputs, meaning these assertions were purely redundant and polluting the code logic.
• Namespace Stripping Helper: Unified the file prefix stripping logic into a streamlined internal helper function `stripNamespace`, reducing code duplication between functions.

2. Bug Fix: Proper Alt Text Keyword Filtering

• In the current live module, the validation that prevents reserved keywords (like `thumbnail`, `thumb`, `center`, etc.) from being used as description text is executed on line 164 (`alt = nil`).
• However, the variable `alt` has already been appended to the `result` string on line 147. This means the keyword-filtering mechanism was completely bypassed and **silently failing**.
• The sandbox version corrects this by evaluating and filtering the `alt` string before it is appended to the final output link structure.

3. Data Layer Refactoring (Module:InfoboxImage/data/sandbox)

• Native O(1) Hash Table Lookup: The current live `/data` module stores placeholders as a sequential array list and runs a `for` loop at runtime to reconstruct a key-value hash map. This completely negates the performance caching benefits of `mw.loadData`. The new version stores the data directly as a lookup table (`["Filename.svg"] = true`), allowing instantaneous $O(1)$ lookups natively without execution loops.
• De-duplication: Removed several duplicate filenames present in the legacy list (e.g., `CarersLogo.gif`, `Diagram Needed.svg`, `No male portrait.svg`, etc.).
• Decoupled Tracking Categories: The main module now fully relies on the tracking categories strings directly passed by `mw.loadData`, decoupling infrastructure names from the logical parser engine.

Testing

The sandboxes have been cross-verified against multiple test cases (bare filenames, fully formatted `File:...` links, raw URLs, templates, and strip markers). The output markup is identical to the current production version, but executes with significantly less processing overhead.

Please let me know if there are any objections or feedback before I submit an official Edit Request. Thanks!

GKNishimoto (talk) 13:39, 4 June 2026 (UTC)

Feedback

A couple of things to note:

• mw.loadData already caches the data load once per module load (see ), so there's no need for the new code at sandbox lines 23-26.
• Remember that Lua parsing/interpreting time is significant. Thus when you have a long list of data (as in Module:InfoboxImage/data), it's innately O(n), because the parser has to touch every element anyway.

Because of these, my preference is to perform mw.loadData locally within each function. This performs lazy evaluation of loadData -- it's not loaded until its needed. For this module, the lazy load occurs 100% of the time, so it isn't critical at this time. But if someone changes the code in the future, lazy loading could be helpful. If you always load the module at lines 23-26, then you'll always incur the Lua parsing overhead for the data.

The conversion of Module:InfoboxImage/data to use a hash table directly is nice, although won't help performance. Because the time is dominated by Lua parsing, the conversion of the list to a hash (which only happens once one module load) will not be noticable.

Also: please don't remove comments from the code. They're helpful for future developers.

— hike395 (talk) 15:08, 4 June 2026 (UTC)

Thank you for the excellent feedback, hike395. You make a very sharp point regarding the Scribunto environment mechanics and the overhead of Lua parsing time versus execution loops. I have fully updated the sandboxes to incorporate your suggestions, balancing the structural improvements with the engine's best practices:

• Lazy Loading Implemented: I removed the module-level eager loading of the data submodule. The call to mw.loadData('Module:InfoboxImage/data/sandbox') has been moved locally inside trackingCat and i.IsPlaceholder. This ensures that the data layer is only processed when actually needed, preventing unnecessary overhead if the module's scope changes in the future.
• Comments and Assertions Restored: All documentation comments and essential logical descriptions have been added back to ensure readability and maintainability for future developers.
• Hash Table & Bug Fix Retained: The data submodule structure remains as a direct lookup hash table (which, as you noted, provides a cleaner and more native design even if parsing time dominates), and the critical fix for the bypassed alt-text validation keyword filter is intact.

The Module:InfoboxImage/sandbox and Module:InfoboxImage/data/sandbox are now fully aligned with both performance optimization and proper lazy-evaluation architecture. If there are no further objections, I will proceed with the official Edit Request. Thanks again for the review! --GKNishimoto (talk) 16:57, 4 June 2026 (UTC)

Original size

Hello. How can I display a logo in an infobox with its original dimensions? For example this: File:2027 FIBA Women's AmeriCup logo.webp
This is a quite small logo, so I don't want to upscale it to the default 250px. I tried something: |size=x270px but that's completely wrong...
Thank you for your ideas. Maiō T. (talk) 21:42, 15 June 2026 (UTC)

@Maiō T.: It depends upon the specific infobox. Which article is it? --Redrose64 🌹 (talk) 22:35, 15 June 2026 (UTC)

@Redrose64: It's 2027 FIBA Women's AmeriCup.

It would be great if a parameter like this could be used: |size=auto or something similar... Maiō T. (talk) 09:30, 16 June 2026 (UTC)

@Maiō T.: For {{Infobox international basketball competition}}, the |size= parameter (which is an alias for |image_size=) must be an integer; values containing units, such as |size=x270px, are ignored. Since the native size of File:2027 FIBA Women's AmeriCup logo.webp is 177 × 270 pixels, and you want it 270px high, simply set |size=177. --Redrose64 🌹 (talk) 12:09, 16 June 2026 (UTC) --Redrose64 🌹 (talk) 12:09, 16 June 2026 (UTC)

Okay. But that's a little inconvenient. It might be a good idea to add the following line to the module: if nativesize<250 then infoboxsize=nativesize otherwise infoboxsize=250 or something (translated into module language). Maiō T. (talk) 17:35, 16 June 2026 (UTC)

How is |size=177 more inconvenient than |size=x270px? --Redrose64 🌹 (talk) 21:33, 16 June 2026 (UTC)

Sorry, I expressed myself a little imprecisely. 😉 |size=177 is inconvenient, because I have to find this exact non-round number on the page of that specific image. Actually, |size=x270px was inconvenient too. My idea is to not write the size number at all. Maiō T. (talk) 22:10, 16 June 2026 (UTC)

@Redrose64: Wow!!! I tried using a completely crazy parameter |size=orig, and it works! The logo is displayed in its native size... Did you personally make any changes to the module? Maiō T. (talk) 19:12, 12 July 2026 (UTC)

No, I didn't because I don't accept that any change is necessary. By altering |size=x270px to |size=orig, all you have done is exchange one invalid value for another. As I noted above, this parameter is documented as accepting an integer and nothing else is valid. Why did you not simply set |size=177 as you were advised? --Redrose64 🌹 (talk) 19:19, 12 July 2026 (UTC)

@Redrose64: Sorry, but it's not a very good idea to write a different ugly non-round number in every infobox. Now it's almost perfect. I simply enter an invalid parameter value and the result will be a nice, unblurred logo in its original size. By the way, this wasn't possible a few days ago; when I entered an invalid value back then, the logo was displayed with the default width of 250px. Someone must have made some kind of change to the module... Maiō T. (talk) 08:32, 13 July 2026 (UTC)

Module:InfoboxImage has not been altered in the last nine months. Of the various templates and modules used by Template:Infobox international basketball competition, only two have been edited since you first opened this thread:

• Module:Check for unknown parameters (history) - changes for pushpin maps
• Template:Infobox international basketball competition (history) - display the word "City" as "Cities" when appropriate

Neither of these changes can possibly have affected the display of the image. Please note, you should not depend upon undocumented behaviour of invalid parameter values, these might change at any time. --Redrose64 🌹 (talk) 17:25, 13 July 2026 (UTC)

Standard WP image syntax will not enlarge an image if it has a caption (see WP:PICSIZE). The code at {{Infobox international basketball competition}} had some silly defaults that did nothing except break this feature. I fixed the Infobox code and added a caption at 2027 FIBA Women's AmeriCup, and behold: the image now displays at its original size. — hike395 (talk) 01:32, 14 July 2026 (UTC)

Wow Hike, this is cool !!! I tried removing the "caption" parameter and it still works perfectly... Thank you very much. I think this topic could be closed. Maiō T. (talk) 11:22, 14 July 2026 (UTC)

Hike, could you add the "upright" option to the following template as well? - Template:Infobox tournament season - Thanks. Maiō T. (talk) 20:28, 14 July 2026 (UTC)

 Done — hike395 (talk) 01:43, 15 July 2026 (UTC)