Template talk:Infobox software

This is the talk page for discussing improvements to the Infobox software template.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Archives: 1, 2, 3, 4, 5, 6, 7, 8: 3 months

Computing: Software / Free and open-source software

	This template is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
	This template is supported by WikiProject Software.
	This template is supported by Free and open-source software.

Template:Infobox software is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.

Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

"Latest release" shows "preferred" not the "latest"

To my understanding the "Latest release" shows the value from Wikidata that is marked as "preferred" which is not always the latest/highest value (e.g. version number or date). This is missleading.

I tried some other variants but wasn't able to select/query the real latest version nummber or date. I always have to manually modify the preferred marker in the wikidata content.

Is there a more automatic way that always the real latest/highest value is selected? Christian Buhtz (talk) 08:29, 29 July 2024 (UTC)[reply]

At least in the case of Sympa, the latest release version and latest release date are used in en.Wikipedia with {{wikidata}} overrides to grab Wikidata values directly without using the code of the {{infobox software}} - and they point to version type (P548) = stable version (Q2804309) which is for a stable release rather than a generic release. I assume that this is the consensus among Sympa editors. I just confirmed (by experiment) that this requires manually selecting the latest stable release as preferred in Wikidata.

I guess your question is whether a routine to compare version strings could be used to automatically select the one with the "most recent" value, per the most widely used conventions. I wouldn't quite agree with "misleading", since Wikidata is still expected to be checked by humans, and in Wikipedia, it would look strange to say "preferred", since that's not the standard term.

My guess is that using the preferred Wikidata thing (is it a property?) is considered a lot more CPU efficient than redoing a version string comparison every time a request is made, especially since the comparison would scale as O(n log n) over strings, while searching for a preferred value is more efficient since only an O(n) search for a specific integer is required. Boud (talk) 12:41, 19 January 2025 (UTC)[reply]

Enable indicating major contributors, not just programmers

I'm working on an article for a software project that has several major contributors that I want to list in the infobox, and not all of them are developers. In this case, one of them is a project manager. This infobox only provides the option to indicate "author" or "developer", which both link to programmer. A lot of software projects involve more roles than just developers, including user experience designers, user researchers, product managers, and content strategists. I suggest renaming the "developer" attribute to "contributor". Dreamyshade (talk) 00:29, 22 August 2024 (UTC)[reply]

logo_scaling?

Uzume, why introduce "scaling" as new terminology in this edit when the word "upright" is already in common usage for this function in image rendering? Was this changed discussed anywhere? Are you following a standard used elsewhere? – Jonesey95 (talk) 14:24, 23 November 2024 (UTC)[reply]

@Jonesey95: It was described as a scaling factor. I am not concerned about the naming but for people unaware of |upright= it seemed more descriptive. —Uzume (talk) 14:28, 23 November 2024 (UTC)[reply]

I would prefer that we use standard language. You can see it in use at {{Infobox person}} and 600 other Template-space pages (compare to this search for _scaling, which links only to this template). Please use this de facto standard here as well. – Jonesey95 (talk) 14:42, 23 November 2024 (UTC)[reply]

Agreed, it should be |logo_upright=. Additionaly, I believe we should remove the archaic |logo_size= parameter, which always produces a fixed size that goes against user preferences. IceWelder [✉] 18:34, 23 November 2024 (UTC)[reply]

@IceWelder: We should probably add some tracking to see what is using those parameters and then either change them to use relative scaling factors (AKA upright) or change them to continue using fixed image sizing by means of complete image markup (for the very few cases where it might make sense to keep fixed sizing) thereby removing all uses of the parameters before we delete them from the template. —Uzume (talk) 07:27, 25 November 2024 (UTC)[reply]

It should be noted that the unfortunate naming of |upright= from the image markup syntax was derived from wanting to reduce the size of images in an upright or portrait page orientation (where their aspect ratios are substantially less than one) that were thought to be too large despite automatic image size scaling via the user thumbnail size preference (because that only limits width and not height). It was not named for general image scaling despite eventually (originally its existence or setting to the value yes just provided a fixed 0.75 scaling; this is still supported) introducing a generalized image size scaling factor (albeit still tied to the user thumbnail size preference which is also named a bit unfortunately as it also applies to frameless and not just "thumbnails"). —Uzume (talk) 18:58, 24 November 2024 (UTC)[reply]

Well just because something is well known under a poor name is not the best reason to continue using the poor name. I just saw this as a chance to promote a better name to help new prospective editors who might not understand the obtuse |upright= terminology. —Uzume (talk) 19:06, 24 November 2024 (UTC)[reply]

Clearly |logo size= and |screenshot size= are fairly easy to understand for the random article editor who might be creating/editing such an Infobox but we also know fixed sizing is problematic. Is the same random article editor going to easily understand |logo upright= and |screenshot upright=? Of course another alternative would be to generate the |upright= scaling factor from a different relative size value, for example using {{#expr:}} or similar to take a given value and divide it by the default user thumbnail size preference value of 220, or something like that (so that providing something like |logo relative size=220 would effectively yield |upright=1). Perhaps we could introduce a |relativesize= parameter to Module:InfoboxImage and then proceed to use that. —Uzume (talk) 19:27, 24 November 2024 (UTC)[reply]

Or we could use 100 as the divisor and thereby have users effectively provide relative sizes in percentages of the the user thumbnail size preference. That might be even easier to understand. It seems like there is some pertinent discussion at: Module talk:InfoboxImage § Help with improving default image sizes. —Uzume (talk) 19:34, 24 November 2024 (UTC)[reply]

A single template's talk page is not the place to right great wrongs, whether in programming or anything else. Whether we like it or not, "upright" is the standard Wikipedia parlance at this time for image scaling. A suboptimal standard is better than a mix of usages. If you want to try to change how image sizes work on Wikipedia, the talk page for MOS:UPRIGHT might be a good place to start. People there might direct you to a better forum. – Jonesey95 (talk) 21:45, 24 November 2024 (UTC)[reply]

That is true but then again everything typically starts small and we are encouraged to be bold. —Uzume (talk) 02:52, 25 November 2024 (UTC)[reply]

@GhostInTheMachine: Thank you for fixing all the articles that had errors introduced by the change in the parameter names. —Uzume (talk) 07:22, 25 November 2024 (UTC)[reply]

Template-protected edit request on 13 January 2025

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Fix the template so that logos display properly in dark mode, see for instance groff (software) Jay Cubby 02:30, 13 January 2025 (UTC)[reply]

What is your proposed solution? There currently is no standardized method to adjust dark logos for dark backgrounds. Some use skin-invert like so, others make the infobox display a white background. Whatever we end up doing, it should be done consistently across similarly affected templates (e.g. {{Infobox company}}). IceWelder [✉] 09:02, 13 January 2025 (UTC)[reply]

The current method is to manually tag each logo with skin-invert. InfiniteNexus (talk) 01:37, 31 January 2025 (UTC)[reply]

Several websites

Companies on rare occasions have more than one website. Is it possible to to add two using this infobox? If not, can a second website be added to the infobox? Artem S. Tashkinov (talk) 10:15, 24 February 2025 (UTC)[reply]

Template-protected edit request on 24 February 2025

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

I'd like to embed a child infobox inside of an {{Infobox software}} using |module= a la WP:IEmbed. Could someone apply the following change, which would allow me to do so?

DefaultFree (talk) 16:11, 24 February 2025 (UTC)[reply]

Done * Pppery * _{it has begun...} 21:56, 24 February 2025 (UTC)[reply]