Template talk:Infobox software

open source / closed source

Add a row to describe if a software is open source or closed source, etc.

No, even though the licence might be proprietary, one still needs to know if the software is open or closed source. Jidanni (talk) 04:02, 4 May 2024 (UTC)

I think that is what |license= is for. If not, please provide an example article where that parameter is insufficient. – Jonesey95 (talk) 03:29, 5 May 2024 (UTC)

The documentation for |license= says: The software license under which the user is allowed to use the software. It is recommended to specify the specific license the software is released under by name, so "Open source" can be implied, but only indirectly — GhostInTheMachine ^{talk to me} 10:05, 18 August 2024 (UTC)

Auto Wikidata value for initial release

I suggest adding {{wikidata|property|edit|reference|P348|P548=Q56514665}} to {{released}} to make it look for the release marked as initial release on Wikidata. See Polkit for an example. The RedBurn (ϕ) 10:09, 9 May 2024 (UTC)
Note that an error is shown if the reference doesn't have a title, is there a way to hide that error?. The RedBurn (ϕ) 16:56, 9 May 2024 (UTC)

Claims pulled from Wikidata need to be sourced. You probably need to use Module:WikidataIB instead of {{Wikidata}}. Feel free to sync the sandbox with the live template and then make a proposed change. It looks like the article you linked has a citation for the release date, so it should work fine. – Jonesey95 (talk) 23:48, 10 May 2024 (UTC)

Thanks for the reply. Unfortunately, Module:WikidataIB can't display references, so it can't be used in infoboxes (even though it's made for that). And the main contributor (RexxS) doesn't want to add support for references.

Here's an example : {{#invoke:WikidataIB|getValueByQual|qid=Q528709|P348|qualID=P548|qvalue=Q56514665|fwd=ALL|osd=no}} shows 0.3  The RedBurn (ϕ) 16:04, 11 May 2024 (UTC)

I've accidentally went ahead and added my version of this to the sandbox, which also has something else... @Jonesey95 {{wikidata}} has the flag "sourced" which limits display to only sourced claims. Is that not enough? Aaron Liu (talk) 22:14, 12 May 2024 (UTC)

That might work. I am not familiar with the nuances of that parameter, but if it pulls only reliably sourced data, that should satisfy the RFC's requirements. – Jonesey95 (talk) 03:44, 13 May 2024 (UTC)

Unfortunately, there's still that problem of references without title showing an error instead of the reference URL. The RedBurn (ϕ) 11:01, 13 May 2024 (UTC)

Correction: I didn't realize that Module:Wikidata isn't the same as Module:Wd (so with Module:WikidataIB that makes three Wikidata modules!). The RedBurn (ϕ) 11:04, 13 May 2024 (UTC)

After verification, the same error is shown when no title is available. The RedBurn (ϕ) 11:11, 13 May 2024 (UTC)

I think we should encourage editors to add titles. Aaron Liu (talk) 15:57, 22 May 2024 (UTC)

It's supposed to happen eventually, but better not hold our breath, see https://phabricator.wikimedia.org/T199197 The RedBurn (ϕ) 17:48, 22 May 2024 (UTC)

Do we have to wait for titles? I feel like doing it now can encourage updating citations on WD. Aaron Liu (talk) 18:02, 22 May 2024 (UTC)

Now that @Janhrach has fixed the references without title error linked above in Module:Wd, it can be used for initial release.

Actually, for initial release ("released ="), for "latest release version" and for "latest release date". The reference should be shown for initial release, "latest release version", and {{start date and age| should be used for "latest release date", see Polkit.

For initial release, Polkit isn't a good example, as it doesn't show the date and doesn't use {{start date and age|. Note that, sometimes, only P571 exists (with just the date, not the version), fr:Modèle:Infobox Logiciel can use both to show as much information as is available, see fr:Polkit. The RedBurn (ϕ) 06:11, 11 June 2024 (UTC)

You might want to try and reincorporate the edits I made. That could make it faster. Aaron Liu (talk) 11:53, 11 June 2024 (UTC)

@The RedBurn: Just a little note: I haven't really fixed the module, I am still going to improve the error message. What I did is that I let Cite Web report the most trivial and common error. It is quite probable you will encounter the old error message when there are less trivial errors in a reference. In that case, feel free to contact me for help. Janhrach (talk) 12:57, 11 June 2024 (UTC)

"Template:Infobox software2" listed at Redirects for discussion

The redirect Template:Infobox software2 has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 May 11 § Template:Infobox software2 until a consensus is reached. Magioladitis (talk) 08:44, 11 May 2024 (UTC)

DOS Navigator

Citation in the infobox is generating a red error message. It is pulling a URL from WD and using a CS1|2 template without a |title=. It looks like the source of the problem is this template. -- GreenC 01:57, 29 June 2024 (UTC)

It needed a title added in the Wikidata entry. Very editor-unfriendly. – Jonesey95 (talk) 16:44, 29 June 2024 (UTC)

Edit request 4 July 2024 -- Pluralize from text

Description of suggested change: Please implement {{Pluralize from text}} for the following labels. Note that the label “Standards” is presumed to be more natural English for ambiguously plural content than “Standard”. The inverse is presumed of the other two labels.

Diffs:

−

| label2 = [[Programmer|Original author(s)]]

+

| label2 = [[Programmer|Original author]]{{Pluralize from text|{{{author|}}}|plural=s}}

−

| label3 = [[Programmer|Developer(s)]]

+

| label3 = [[Programmer|Developer]]{{Pluralize from text|{{{developer|}}}|plural=s}}

−

| label18 = [[Technical standard|Standard]](s)

+

| label18 = [[Technical standard|Standard]]{{Pluralize from text|{{{standard|}}}|likely=s|plural=s}}

Thank you! — HTGS (talk) 04:23, 4 July 2024 (UTC)

I like this idea, but the template is not without faults when interpreting company names. For example:

• Developer{{Pluralize from text|Machines, Inc.|plural=s}}

  → Developers

• Developer{{Pluralize from text|Doe and Doe LLC|plural=s}}

  → Developers

Therefore, the current proposal may not be ideal. IceWelder [✉] 08:50, 4 July 2024 (UTC)

My own attitude to this problem has been that it isn’t actually a problem. I personally find the wrong pluralization less annoying than the (s) ending, and the classic style used in print is still grammatically acceptable (eg, Developers: Doe and Doe LLC}). And, for these cases, there is always {{force singular}}, for which I am happy to write guidance into the documentation (and even go through and add the tag to articles). — HTGS (talk) 20:41, 4 July 2024 (UTC)

Hm, I'd rather have on stable version than one that can render in unexpected ways. Continuing below... IceWelder [✉] 16:21, 11 July 2024 (UTC)

(s) is fine for me. Alternatively we can add another parameter for the plural version, e.g. {{{authors}}}. SWinxy (talk) 23:12, 7 July 2024 (UTC)

I am also fine with plural parameters. — HTGS (talk) 22:28, 8 July 2024 (UTC)

Plural paramaters are fine on a technical level but a huge pain to maintain. If there is an overwhelming consensus, we can still implement it. Other than that, the easiest way to get rid of "(s)" constructs would be to make the parameters generically singular or generically plural, as some other templates have done. IceWelder [✉] 16:25, 11 July 2024 (UTC)

Disabling the request for now. Please re-enable, when there's consensus for which of the approaches is to be used. —⁠andrybak (talk) 11:26, 14 July 2024 (UTC)

"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)

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)

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)

@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)

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)

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)

@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)

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)

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)

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)

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)

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)

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)

@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)