Template talk:Infobox software/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Proposed update to handling of release versions

I've noticed that we require a lot of work from editors to get standard values from Wikidata. Editors need to either create multiple almost identical {{Wikidata}} calls such as in Trillian (software) or create calls that calls pre-created templates such as in Internet Explorer and Template:Latest stable software release/Internet Explorer for Mac OS X. A lot of times these templates get abandoned like Template:Latest preview software release/Trillian.

I've created a version at Module:Multiple releases/sandbox which only requires from an editor 1 value. |platforms= which is a comma separated list (for example |platforms=android,ios,macos) and it returns the relevant data. Here is an example for Trillian (software) (note that the QID of Trillian for |software= is detected automatically when on the page and the |version_type= is passed by this template)

Android6.6.0.13  / 25 July 2023 (25 July 2023)iOS6.6.12  / 5 June 2023 (5 June 2023)macOS6.5 Build 43  / 8 September 2023 (8 September 2023) Gonnym (talk) 19:07, 22 December 2021 (UTC)

References

Please ensure that only sourced information is fetched, per this RFC. It might be possible to make use of {{Wdib}} or its companion module to make that retrieval easier. – Jonesey95 (talk) 22:25, 22 December 2021 (UTC)

I've spent an hour looking at the doc of that template to try and figure out how to get the call to work but couldn't figure out (I used the same exact template usage from the article), so if you can give me the correct usage, I can modify it to work. Gonnym (talk) 01:25, 23 December 2021 (UTC)

I try to stay away from Wikidata and that template unless it is doing something it shouldn't be asked to do. Wikidata has been too opaque for me to decipher. – Jonesey95 (talk) 05:32, 23 December 2021 (UTC)

I've slightly adjusted the module so that only sourced information is fetched. I hope we can use the module in articles soon. —Dexxor (talk) 19:27, 15 January 2022 (UTC)

The testcases seem to pass. If there is no other issue, I'll do another pass to cleanup, doc, etc and we can add it to the template. Gonnym (talk) 21:14, 15 January 2022 (UTC)

I've added the code to the /sandbox version but haven't yet thoroughly tested it. Please play around with it on different pages and give any feedback. Gonnym (talk) 12:45, 19 January 2022 (UTC)

If this requires values in infoboxes then this should still be improved upon. After adding these wikidata-templates for a while now, and sometimes checking other languages, then fr.wiki and ru.wiki probably handles this the best from what I have seen. For example: fr:Trillian_(logiciel) and ru:Trillian. There is no need to enter anything into their infoboxes. They pick the versions and platforms from Wikidata automatically and uses that. So look at how they do it and get en.wiki to at least the same level. (de.wiki should also have a look.) 94.234.55.188 (talk) 08:42, 5 February 2022 (UTC)

It can be modified to pick all versions if that is what we want. I just copied the style already in-use which was that editors selected to show sometimes only a sub-list of the total amount of platforms, for whatever reasons. Gonnym (talk) 09:23, 5 February 2022 (UTC)

My 11 bits, some already implemented, but just for reference. If I am understanding this correctly, then make it automatic. Do not use a list. Articles will not pick up from Wikidata until "platforms" is added, and it will confuse editors with their unlisted entries. Pick the preferred stable release of each platform/operating system (since some uses that), and if to keep it simple then the preferred pre-release of each platform/os. To make it less simple then look for pre-release, alpha, beta, unstable, and others and grab a single one of each platform/os that is preferred, probably ideally the latest one, and maybe show that it is alpha, beta, or whatever. But some entries with "channels" will release alpha, beta, dev, nightly, etc, on the same day, and they even list alpha and beta instead of just one preview (see Messenger). And to make it even less simple, then there are LTS, and legacy, and so on, and that they should all be shown (see GnuPG). So to look for them and somehow show that they are LTS, legacy, whatever ... And then if there are multiple platforms and they each have LTS with different versions ... It can get out of hand. But in general and as a start then do the first simple way or the second less simple way. If a piece of software wants to list multiple releases then we can do so manually, as I have done. Nice to see that this is being worked upon! 94.234.55.188 (talk) 11:11, 5 February 2022 (UTC)

Thanks for that input! To be fair though, I don't completely agree that all of that should be present in the infobox. The infobox should summarize key information that most readers care about. 99% of our readers don't care what the nightly version is or even the alpha version. Having that info in inside the infobox is really giving it undue weight. We need to remember that the infobox isn't a replacement for a GitHub page (or their own website). Before I do a lot of pointless work, we should really decide design-wise, what types of release versions we want to show. Everything is not an option. Once that step is decided, it will be easier to code what we want it to be. Gonnym (talk) 11:35, 5 February 2022 (UTC)

I also agree that listing every alpha, beta, nightly, dev, etc, is not necessary. But to list one for preview is fine for the general infobox to show a little more on how active it might be and for people to test. For simplicity it would grab "pre-release", but if editors in another language has a large page for a piece of software and they have rc, beta, alpha, dev, nightly, daily, hourly, whateverly, unstable, etc, all set to "preferred" on Wikidata then this would grab the one with the latest date and use that single one, maybe just rc and beta, maybe alpha, maybe unstable since I have seen entries using that. So maybe something like "if no single preferred pre-release then latest single preferred rc/beta/alpha?/unstable". However, I do think that LTS is worthwhile to consider listing, but it is fine if it is not included, as those pieces of software are usually big enough to have that manually added to their page. So in short, one stable for each platform/os, one preview for each platform/os. The details on which to grab into the single "preview" can be finetuned as time goes by, but the main thing I think is to keep it automatic without requiring any extra values into the infobox. 94.234.55.188 (talk) 12:34, 5 February 2022 (UTC)

When is it legit to state discontinued = yes?

When a software wasn't updated in years, but is still popular enough, stating discontinued = yes for it almost immediately drives its fans to bully and threaten those that added the statement.

Their main claim is that such a statement must be sourced. But unless the software officially states its discontinued state, which is very unlikely, no one will ever write about it. This requirement means that a software can release no update 10 years, but any attempt to state its discontinued state will be considered controversial.

Can you assist:

1. Defining a time frame for "discontinued"? Half a year? 1 year? 2 years? 10 years?
2. Defining is it enough that no official versions are released? Or can occasional repo updates, which mean nothing to end users, halt the discontinued state?

Thanks! Cardace (talk) 17:26, 14 January 2022 (UTC)

@Cardace: Strictly speaking, you can only set that value in the infobox if you have a statement in the body of the article, supported by a source, saying the software is discontinued. It need not be the developer of the software that makes this statement. But it can't just be you, a humble Wikipedia editor, deciding it. — jmcgnh^{(talk) (contribs)} 19:00, 14 January 2022 (UTC)

Is it thus acceptable most of the softwares out there, even if they weren't updated in 10 years, will forever be written in Wikipedia as active, since verifiable sources don't tend to write an article about how a certain software got discontinued? A software probably has to be used by millions for a verifiable source to actually write how it got discontinued. -Cardace (talk) 19:55, 15 January 2022 (UTC)

I have used plenty of ten-year-old software that was never formally discontinued. We report what reliable sources say; that's how Wikipedia is supposed to work. – Jonesey95 (talk) 20:15, 15 January 2022 (UTC)

A program can be fully operational yet still discontinued as in having no new official versions. But almost no one will ever write about it. -Cardace (talk) 16:22, 16 January 2022 (UTC)

Then we won't either. There is plenty of other sourced information that is waiting to be added to Wikipedia. – Jonesey95 (talk) 18:35, 16 January 2022 (UTC)

yes wikipedia tells the facts based reliable sources, not our opinion. Readers can decide for themselves whether a piece of software is discontinued based on the last release date parameter — Preceding unsigned comment added by Serprinss (talk • contribs) 04:47, 23 January 2022 (UTC)

"...forever be written in Wikipedia as active..."

No such thing happens. The |discontinued= parameter has only one impact: It changes the phrase "Latest release" into "Last release." Articles without this parameter are in an indeterminate state, i.e., there is no way to tell if they are discontinued or not.

"...drives its fans to bully and threaten those that added the statement."

Don't they always? If not for setting this parameter, for something else. Just keep cool, bear in mind what the parameter actually does, and step away. Waysidesc (talk) 18:28, 27 February 2022 (UTC)

Singular vs. plural entries

Hi,

this template doesn't seem to have made up its mind about how to deal with entries that can be "plural": e.g. why "Operating system" and "Platform" are not "Operating system(s)" and "Platform(s)"? Also, are we sure we want the "s" in parentheses? I think it's perfectly OK to have an entry named "Platforms" which just lists one supported platform. —Gennaro Prota^•Talk 10:40, 17 March 2022 (UTC)

Hmm... Yes. I can see that.

• Singular ones: "Initial release," "stable release," preview release," repository," "middleware," "engine," "operating system," "platform," "predecessor," "successor," "service name," "size," "type", "license," and "website."
• Hybrid ones: "Original author(s)," "Developer(s)," and "Standard(s)."
• Plural ones: "Other names" and "languages"

I think we shouldn't drastically change the infobox and just go all-singular. Waysidesc (talk) 23:56, 17 March 2022 (UTC)

website - suport for Wikidata archived url

See for example website in Netscape_Navigator. MarMi wiki (talk) 01:17, 19 March 2022 (UTC)

It is not obvious what you are saying. If you are asking for Wikidata integration support, this template already has it. For example, look at Netscape Navigator article! Waysidesc (talk) 05:24, 19 March 2022 (UTC)

MarMi is saying that Netscape Navigator should use http://web.archive.org/web/20110724011710/http://archive.netscape.com:80/ instead of the dead http://archive.netscape.com/. The web.archive.org URL could be taken from the Wikidata item using this logic: “If the official website statement has both the archive URL and end time qualifiers, then return the value of archive URL, else return the value of official website.” Implementing this logic would make the template more complex and might have a small performance impact. I don't think that would be worth it considering there are very few articles that would benefit from this. I queried Wikidata and found only 166 software articles where the logic would return an archived URL. Of these articles only a small fraction would benefit from a change to this template since the websites in the infoboxes most often do not come from Wikidata.

For the case of Netscape, I would add |website=hide because the archived website has no valuable content except for “Netscape is dead”. Dexxor (talk) 08:00, 19 March 2022 (UTC)

website – show URL with preferred rank instead of the one with normal rank

See https://en.wikipedia.org/wiki/VisualBoyAdvance and https://www.wikidata.org/wiki/Q686258 I changed the rank of the URL to the current official website to preferred but the infobox still shows the one in normal rank which links to an outdated repository. --Pohli (talk) 09:39, 8 May 2022 (UTC)

Template-protected edit request on 19 July 2022

Please revert these last two edits immediately. This broke the infobox on many articles, placing hundreds of pages which use |logo_size= and |screenshot_size= (with the underscore) to be placed in Category:Pages using Infobox software with unknown parameters. InfiniteNexus (talk) 05:12, 19 July 2022 (UTC) InfiniteNexus (talk) 05:12, 19 July 2022 (UTC)

 Done – Jonesey95 (talk) 14:44, 19 July 2022 (UTC)

I was under the impression that the versions with and without underscore are interchangable. Guess this is not the case. I restored the correction with the replacement params. IceWelder [✉] 16:26, 19 July 2022 (UTC)

I don't know what changes are occurring on this template, but it's making an ugly mess on articles with massively oversized images. See: Microsoft_Excel, Microsoft Powerpoint for examples. --Escape Orbit ^(Talk) 17:20, 19 July 2022 (UTC)

I've just reverted today's edits to this template in order to fix the oversized image issue. I'm not sure what this edit request was trying to fix, but it's implementation had wider implications than just pages showing up in a maintenance category. I've got no issue with my revert being undone, as long as screenshots on pages like the ones mentioned in my edit summary and above don't fill the entire page again. stwalkerster (talk) 17:23, 19 July 2022 (UTC)

Please stop messing with this template. I made this edit request after I saw this monstrosity (I fixed the issue on that article by removing the underscores, but my point still stands). InfiniteNexus (talk) 17:26, 19 July 2022 (UTC)

IceWelder, please make changes in the sandbox, and copy test cases from the pages linked above to ensure that potential changes do not make those articles worse. – Jonesey95 (talk) 18:31, 19 July 2022 (UTC)

I reverted my changes for now. Don't have time to investigate right now. But FWIW, it appears that "this monstrosity" was already present in the previous version. Maybe we need a parameter for vertical vs. horizontal screenshots? IceWelder [✉] 10:05, 20 July 2022 (UTC)

I believe this is now fixed, thanks all. Regarding my "monstrosity" comment, I was referring to the logo, not the screenshot. The |logo_size= was set to 200px, but because that parameter was removed the image defaulted to whatever the default size is. Perhaps "monstrosity" wasn't the best word to use, because it actually made the logo super tiny. InfiniteNexus (talk) 17:09, 20 July 2022 (UTC)

On a related note, I noticed that Category:Pages using Infobox software with unknown parameters still contains a very large number of articles even after this fix. After taking a closer look, it appears that many of them include the non-existent parameter |status=. I seem to recall that this parameter used to exist, when and why was it removed? InfiniteNexus (talk) 17:14, 20 July 2022 (UTC)

Link to 2018 discussion; diff of removal. – Jonesey95 (talk) 19:27, 20 July 2022 (UTC)

I see. Interesting that no one has gone through that error category to remove all the |status= parameters after four years. InfiniteNexus (talk) 00:06, 21 July 2022 (UTC)

So the revert also included the change to the default image size. Could that be re-implemented? I really would like pages, like on Dream SMP, to have the image be the default size. SWinxy (talk) 20:55, 1 August 2022 (UTC)

Default logo size

Hi, it's me again. Can someone please figure out what the problem is at Google Keep that is causing the logo to appear massive? Per the template documentation, the default logo size is 64px, but this definitely isn't the case here. The screenshot size doesn't seem to affect the logo size either, so I'm at a loss as to why this is happening. Thanks! InfiniteNexus (talk) 05:25, 29 August 2022 (UTC)

The documentation was wrong. I have updated it. See #Changing default logo size above. – Jonesey95 (talk) 13:00, 29 August 2022 (UTC)

In addition, the size parameter was used without a value, so a nil value was used instead of our default. [1] IceWelder [✉] 13:40, 29 August 2022 (UTC)

An empty parameter should not result in a nil value. Can this be fixed/altered? InfiniteNexus (talk) 20:38, 30 August 2022 (UTC)

Yes, by using an if statement to test for the parameter. – Jonesey95 (talk) 13:36, 31 August 2022 (UTC)

This has been [sandboxed] and the first three [test cases] show the usage results. So if there are other iboxes with the empty |logo size= or |logo_size= parameter, the sandbox code would fix them. Feel free to improve the code where possible. P.I. Ellsworth , ed. ^put'r there 12:04, 30 September 2022 (UTC)

Changing default logo size

Hi, logos nearly always should be selected as PageImage of an article about software. So in my opinion, the default size of logo should be set to equal of bigger than 121px to automatically set that image as PageImage of article. So please change

| image      = {{#if:{{{screenshot|}}}
  | {{#invoke:InfoboxImage | InfoboxImage | image={{{logo|}}} | title={{{logo caption|}}} | size={{{logo size|{{{logo_size|}}}}}} | sizedefault=300x64px | maxsize=300x64px | alt={{{logo alt|{{{logo_alt|}}}}}} }}
  | {{#invoke:InfoboxImage | InfoboxImage | image={{{logo|}}} | title={{{logo caption|}}} | size={{{logo size|{{{logo_size|}}}}}} | alt={{{logo alt|{{{logo_alt|}}}}}} }}
}}
| caption    = {{{logo caption|}}}

to

| image      = {{#if:{{{screenshot|}}}
  | {{#invoke:InfoboxImage | InfoboxImage | image={{{logo|}}} | title={{{logo caption|}}} | size={{{logo size|{{{logo_size|}}}}}} | sizedefault=121px | maxsize=300x64px | alt={{{logo alt|{{{logo_alt|}}}}}} }}
  | {{#invoke:InfoboxImage | InfoboxImage | image={{{logo|}}} | title={{{logo caption|}}} | size={{{logo size|{{{logo_size|}}}}}} | alt={{{logo alt|{{{logo_alt|}}}}}} }}
}}
| caption    = {{{logo caption|}}}

To by default and automatically set the logo of a software as the PageImage of its article in Wikipedia. Thanks, Hooman Mallahzadeh (talk) 08:23, 25 June 2022 (UTC)

 Sandboxed – and can be compared on the testcases page. Suggest we let other editors compare and opine for awhile, then if all is well, the edit can be made to the live template. P.I. Ellsworth , ed. ^put'r there 11:35, 25 June 2022 (UTC)

@Paine Ellsworth: The "if" phrase above was redundant, additionally the "maxsize" argument prevents selection of logo as PageImage of article, so the correct code would be:

| image      = {{#invoke:InfoboxImage | InfoboxImage | image={{{logo|}}} | title={{{logo caption|}}} | size={{{logo size|{{{logo_size|121px}}}}}} | alt={{{logo alt|{{{logo_alt|}}}}}} }}


| caption    = {{{logo caption|}}}

this code applies default size without any maxsize. Please apply that for a couple of days, for testing . Thanks, Hooman Mallahzadeh (talk) 13:08, 27 June 2022 (UTC)

P.I. Ellsworth , ed. ^put'r there 13:24, 27 June 2022 (UTC)

To editor Hooman Mallahzadeh: and  done. P.I. Ellsworth , ed. ^put'r there 14:41, 1 July 2022 (UTC)

@Paine Ellsworth Hi, default logo size is now 110px, by this code:

| image      = {{#invoke:InfoboxImage | InfoboxImage | image={{{logo|}}} | title={{{logo caption|}}} | size={{{logo size|{{{logo_size|110px}}}}}} | alt={{{logo alt|{{{logo_alt|}}}}}} }}

This is not enough for setting it as PageImage of article, (e.g., see PageImage of Microsoft Word article), so please change it to 120px and also do not forget to place a comment above that, like this:

<!-- set default logo size to 120px to set that as PageImage of article by default -->
| image      = {{#invoke:InfoboxImage | InfoboxImage | image={{{logo|}}} | title={{{logo caption|}}} | size={{{logo size|{{{logo_size|120px}}}}}} | alt={{{logo alt|{{{logo_alt|}}}}}} }}

Thanks, Hooman Mallahzadeh (talk) 13:52, 28 September 2022 (UTC)

 Not done for now: Looking at all the discussion back and forth on this page in regard to these changes, this is actually a controversial edit, so you'll need to discuss first with other editors. Please open a new section here and start a discussion. A new edit request may be opened only when there is agreement among editors for the proposed default logo_size change. It might help if you read the discussions here and build the sandbox and testcases page to show that yours is a good idea across all of the sample articles' infoboxes. P.I. Ellsworth , ed. ^put'r there 17:00, 28 September 2022 (UTC)

@Goszei Please read the above discussion, this is the reason why "default logo size" should be at least 120px. Thanks, Hooman Mallahzadeh (talk) 13:57, 28 September 2022 (UTC)

I feel like this logic is flawed. There should not be a fixed size and the logo should scale appropriately with the user's setting. The best option would be to replicate {{Infobox company}}'s image code. IceWelder [✉] 17:35, 28 September 2022 (UTC)

I have undone my change, apologies for not reading talk before. — Goszei (talk) 22:33, 28 September 2022 (UTC)

• @Hooman Mallahzadeh, Paine Ellsworth, Goszei, InfiniteNexus, and Jonesey95: I have set up a new sandboxed version that avoids all hardcoded sizes and fixes faulty overrides when |logo_size= is left empty. The latter resolves the issue formerly seen at Google Keep, as reported by InfiniteNexus. Instead of hardcoded pixel counts, the images are scaled from the thumbnail size set in the user preferences (for 99.9% of readers, this would be 300px 220px). The same behaviour is found in most major templates. For now, I tweaked these |upright= parameters so they replicate the existing sizes as accurately as possible. I hope we can quickly make this the live version of the template. Afterwards, we can still make additional adjustments, such as setting the logo's |upright=1 when no screenshot is present (a possible resolution for @SWinxy's problem reported below). Regards, IceWelder [✉] 17:14, 1 October 2022 (UTC)

  Yes, that totally address my concerns. You have my support for pushing out the sandboxed version. Thanks! InfiniteNexus (talk) 18:12, 1 October 2022 (UTC)

  Thank you. |upright= is much better than fixed pixel sizes, per MOS and common sense. – Jonesey95 (talk) 19:16, 1 October 2022 (UTC)

  It looks like this change is not ready to be deployed yet. See Template:Infobox software/testcases for some unpleasant image sizing in the sandbox. – Jonesey95 (talk) 05:35, 2 October 2022 (UTC)

  Which one are you referring to? InfiniteNexus (talk) 05:38, 2 October 2022 (UTC)

  Please clarify. I set up the current sandbox precisely so all sizes stay the same, spare for cases where setting |logo size= or |logo_size= with a blank value would incorrectly override the template's size setting (in the testcases, those are the first two and the very last). IceWelder [✉] 08:27, 2 October 2022 (UTC)

  The Google Wallet home screen, already quite large in the live template, is absurdly large in the sandbox, about 415 by 900 pixels. My thumbnail preference is set to 300px. – Jonesey95 (talk) 13:36, 2 October 2022 (UTC)

  They look the exact same to me, including when I am not logged in. Screenshot here. Does anyone else have this issue? IceWelder [✉] 13:48, 2 October 2022 (UTC)

  I actually just noticed that the default thumb size is 220px, not 300px; that was a typo in my original message. IceWelder [✉] 13:49, 2 October 2022 (UTC)

  I also see this. Chrome is telling me that the image is being displayed at 462x1000px for the Google Wallet using the sandbox. GIMP's screenshot is also too large, at 540x330px. SWinxy (talk) 18:34, 2 October 2022 (UTC)

  Do you also have thumbnail size set to 300px instead of the default 220px? Do the screenshots look better when you set |upright=1 for them? IceWelder [✉] 18:51, 2 October 2022 (UTC)

  I actually have the thumbnail size set to 400px (I don't actually remember setting it to that value, but I guess that's OK since I have large monitors). Setting upright doesn't appear to change anything. SWinxy (talk) 19:36, 2 October 2022 (UTC)

  Changing upright must have an impact. I just changed it to 1 in the sandbox. Please check again. IceWelder [✉] 07:37, 3 October 2022 (UTC)

  All of the testcases now look the same as or better than the live template (for me). – Jonesey95 (talk) 13:11, 3 October 2022 (UTC)

  Yes please. SWinxy (talk) 19:24, 1 October 2022 (UTC)

• Seeing no further opposition, I have pushed the sandbox to the main template. IceWelder [✉] 15:15, 5 October 2022 (UTC)

Publisher or distributer

It is common, at least in the past, for software to be written by one company or author, and distributed by another. It's also common for that distributer to change. I cannot see a good way to do this using this template, as there is no entry for distributer or publisher.

The example of the template use does have a |publisher= entry, but it does not actually do anything.

Is there a suggested way to do this with the current template? In either case, I would recommend making the publisher tag work, as it would be used in many of my articles. 108.168.93.43 (talk) 17:11, 14 November 2022 (UTC)

Hmm, publisher is working in another article... perhaps one tag is overriding another? 108.168.93.43 (talk) 18:39, 14 November 2022 (UTC)

The documentation explains that publishers go in |author=: Name of the original author(s) or publisher(s) of the software. There is no |publisher= parameter. – Jonesey95 (talk) 23:49, 14 November 2022 (UTC)

1) the author may not be the publisher. MindWrite was published by three different companies over time although it always had the same author. If we put the developer name in developer, which makes sense, then putting the distributer in author... wait, what?

2) if we're not supposed to use publisher, why do I see |publisher=GNOME Project in the example usage?

108.168.93.43 (talk) 15:47, 15 November 2022 (UTC)

Re item 2: that publisher parameter is inside a citation template, which supports |publisher=. – Jonesey95 (talk) 19:23, 15 November 2022 (UTC)

Proposal to add an optional field for documentation

Would be nice to be able to add a documentation URI to this infobox. Many software projects now offer quite sophisticated readthedocs.io or similar dox. This particular wikipedia page uses a custom template with such a field — see for instance the PyPSA framework, to give an idea of what this suggestion might look like in practice. RobbieIanMorrison (talk) 21:32, 12 March 2023 (UTC)

Proposal to Add an optional field for Digital Object Identifiers (DOI)

Hello all,

open source software projects are using infrastructures such as the Zenodo Open Access archive to ensure long term preservation of the versioned project codebase. This already applies for over 19 open geospatial software projects. This process results in the minting of a concept DOI to reference the whole software project and also 1..n version DOI for particular software releases. DOI are good practice to scientifically reference digital objects. To inform the readers whether DOI references are available for a particular software, I suggest to add an optional field to this template, to make this information explicit and easy to find/use for the community. PIXEL2021 (talk) 15:32, 5 March 2023 (UTC)

TIL that software can have DOIs. I don't have a problem with adding it, e.g. 10.5281/zenodo.5865317. It might be a good idea to also put DOIs in Wikidata items, too! SWinxy (talk) 03:14, 6 March 2023 (UTC)

@SWinxy: Having DOI for software in Wikidata items would be excellent, too. PIXEL2021 (talk) 07:09, 6 March 2023 (UTC)

There's nothing preventing a DOI to be added, as seen here. This template pulls other Wikidata things, so why not DOI as well? SWinxy (talk) 14:59, 6 March 2023 (UTC)

@SWinxy: So the Wikidata content for those software projects which already have DOI needs to be extended for their DOI (like you demonstrated for GeoServer), and once an update of this template has been agreed upon and published, these DOI will be displayed to the readars, correct ? PIXEL2021 (talk) 18:04, 6 March 2023 (UTC)

DOI metadata has been added to Wikidata entries for:

GDAL: 10.5281/zenodo.5884351

GeoTools: 10.5281/zenodo.5854653

GMT: 10.5281/zenodo.3407865

GRASS GIS: 10.5281/zenodo.5176030

gvSIG: 10.5281/zenodo.5849091

Mapbender:10.5281/zenodo.5887014

MapServer: 10.5281/zenodo.5842012

OSGeoLive: 10.5281/zenodo.5884641

PostGIS: 10.5281/zenodo.5879631

PROJ: 10.5281/zenodo.5884394

QGIS: 10.5281/zenodo.5869837

rasdaman: 10.5281/zenodo.1040170 PIXEL2021 (talk) 18:37, 6 March 2023 (UTC)

A comment: The OP attempted to add a DOI parameter to the sandbox and the testcases page. I have tidied it up to make it work properly. I have no opinion on whether it should be added or not. – Jonesey95 (talk) 17:09, 9 March 2023 (UTC)

Thanks Jonesey. I now realize that {{doi}} appends doi: to the beginning of the link, making there a double doi. Not a fan of that. The template doesn't allow for removing the DOI link, which makes sense as there are zero other use cases for doing so. SWinxy (talk) 17:58, 9 March 2023 (UTC)

Fixed, FWIW. – Jonesey95 (talk) 18:16, 9 March 2023 (UTC)

I'm an idiot. I didn't see that `|nolink=` was a parameter for {{doi}}. 🤦 SWinxy (talk) 18:46, 9 March 2023 (UTC)

Not at all. I just added it to meet this need. It may be useful in other situations as well. – Jonesey95 (talk) 21:55, 9 March 2023 (UTC)

• What is the advtange of including DOIs to the general reader, as opposed to any other identifier? I don't see this being super useful for 99+% of the readership, and it feels more like bloat in an already pretty large template. IceWelder [✉] 15:29, 8 March 2023 (UTC)

  For source code, Software Heritage identifiers, shortened SWHID, would be an infinitely better option to the use of DOIs, in my view. See here for some background. RobbieIanMorrison (talk) 21:42, 12 March 2023 (UTC)

Is the loading of release versions from Wikidata really a good idea?

I have not read everything in the archive, but I think the idea from over 15 years ago to "outsource" release version informations had the intent to avoid blowing up the history of articles. Therefore, subpages like this have been created. Later, the "Wikidata Method" was introduced.

After this problem, I am skeptical about this procedure: In the beginning of the problem there was the following warning at the page:

Error: first parameter cannot be parsed as a date or time.

At the end, the solution was to fix a couple of Wikidata entries. But the "Wikidata Method" made it very tedious to find the reason for the problem. In contrast, article histories with many entries don't disturb me.

But maybe there are further aspects, I would appreciate comments. Kallichore (talk) 22:14, 15 November 2022 (UTC)

Hey @Kallichore, I actually know why the template went haywire, in fact I posted a similar topic to help desk about ten days before your comment here. See the now archived topic. Aaron Liu (talk) 18:41, 5 January 2023 (UTC)

@Aaron Liu: Thanks for your edits regarding Signal (software). I also found out that the Github-wiki-bot played a role. Do you know if the general problem is fixed now and if there are further cases? --Kallichore (talk) 00:27, 6 January 2023 (UTC)

I don't know, but I don't think the bot has been fixed. I don't know other cases but I do know that Category:Wikidata tracking categories exists. Aaron Liu (talk) 03:44, 6 January 2023 (UTC)

I also found out that the bot doesn't even bother to specify if the release is a pre-release, see the wikidata entry for Flatpak. Aaron Liu (talk) 00:39, 12 January 2023 (UTC)

It appears that there are currently 14 articles with this error message. – Jonesey95 (talk) 15:15, 12 January 2023 (UTC)

Thank you! Aaron Liu (talk) 15:18, 12 January 2023 (UTC)

I have created Category:Pages using Infobox software with version errors to track the errors of this type that are caused by the template. It may be possible that the category pulls in articles that are not showing error messages directly but have something else wrong with one of their version or date parameter values. Please report problems with error detection in a separate thread on this page. – Jonesey95 (talk) 15:50, 12 January 2023 (UTC)

Hello @Kallichore, @Aaron Liu,@Jonesey95

using WikiData has several advantages. Not blowing up the history of articles is only one reason.

By using WikiData, the workload is shared between language-versions of Wikipedia. Since about 1/3 of all edits are made in en.wikipedia.org the work is divided to one third. (meta:List of Wikipedias by edits per article. The sum for all edits is 3 255 000 000, for English its 1 128 370 688.)

Have in mind our declining active user base.

In many language editions of Wikipedia (Spanish, Portuguese, German example, French, ...) most content of the software infobox is pulled from WikiData.

Pulling info from WikiData is suggested very often, e.g.: 1, 2, 3, 4, 5.

I know using WikiData is a big change in the way of working, but i think its worth the effort.

--Alex42 (talk) 12:43, 12 January 2023 (UTC)

I'm not against the use of WikiData at all, I'm actually for it. However, the problem with Github-Wiki-Bot needs to be FIXED and the issue I submitted to the GitHub repo hasn't been responded to yet, so I think unless we can invent a bot that automatically fixes Github-Wiki-Bot's entries we should probably avoid using wikidata for releases rn unless there is only one type of release(e.g. only stable, only this platform group, no other release methods available). Aaron Liu (talk) 12:51, 12 January 2023 (UTC)

IMHO, we should just remove versions altogether. After all, this is an encyclopedia, not a version lookup directory. Even with major programs, it is rare that secondary sources would ever touch on new stable versions, much lass preview versions, and even much less on convoluted versioning systems like WhatsApp or Google Chrome have. When an update is covered beyond WP:NOTCHANGELOG, it can still be added to the prose. Not having to deal with Wikidata shenanigans, scarcely watched template subpages, and unsourced version information in general could save everyone a lot of headaches. IceWelder [✉] 15:37, 12 January 2023 (UTC)

I am thinking the same here. Looking at LSR and LPR and their cats Latest stable software release templates and Latest preview software release templates, you will see the frequency of edits specific to the version numbers. (in which it was separated from the infobox) – The Grid (talk) 17:56, 24 January 2023 (UTC)

It is my impression that there is little progress in fixing the problem on wikidata. A quick solution for the article space is to remove the stable release field for the problematic cases, like here for this problem from today. Is there opposition to this "quick solution" until there is a better solution? --Kallichore (talk) 20:35, 18 April 2023 (UTC)

Usually just adding the stable release qualifier is good enough. Plus, wikidata is supposed to be separate from wikipedia. We shouldn't remove data from wikidata just for wikipedia. Aaron Liu (talk) 23:32, 18 April 2023 (UTC)

I think that "adding the stable release qualifier" is difficult, what else explains many months without progress? My "quick solution" proposal is not to remove anything from wikidata, but to change the infoboxes in the articles like this. --Kallichore (talk) 18:43, 19 April 2023 (UTC)

I mean adding the stable release qualifier to the template selection. For really small problems like these just that is enough. However usually the problem comes from having multiple latest releases from different platforms. Aaron Liu (talk) 20:33, 19 April 2023 (UTC)

I am sorry, I don't understand what you mean with "adding the stable release qualifier to the template selection". I think difflinks would help me. --Kallichore (talk) 21:27, 19 April 2023 (UTC)

I have removed now all fields with the ""first parameter cannot be parsed as a date or time" that I could find with the search function. I welcome the implementation of a better solution. --Kallichore (talk) 18:55, 21 April 2023 (UTC)

FAQ is horribly outdated

Can the FAQ now be deleted entirely now that pretty much all points are supported? Aaron Liu (talk) 16:07, 22 May 2023 (UTC)

As of May 2016 💀 sure SWinxy (talk) 16:21, 22 May 2023 (UTC)

I’ve went ahead and removed the template as well as tagged it with G6. Aaron Liu (talk) 16:25, 22 May 2023 (UTC)

documentation field requested

Many software projects these days offer dedicated web‑based documentation. Therefore a documentation field would make sense, over and above the current project website field. RobbieIanMorrison (talk) 13:39, 19 June 2023 (UTC)

Fork template for Infobox computer model

I would like to create a "fork" of this for a Template:Infobox computer model.

This would be for computer models, like AI models (e.g. AlphaFold, etc.).

I don't have a lot of experience with templates, any thought on how this could best be done. Does this template have a lot of bagage that I should not copy over? Bquast (talk) 16:53, 20 June 2023 (UTC)

Why? AlphaFold describes it as software, so why not use this infobox? What differences are needed? – Jonesey95 (talk) 19:58, 20 June 2023 (UTC)

Well the reason is that a model is not like software at all. It its basic form a model is just a set of parameters with one or more equations. I agree that often models are operationalized, and often still refered to as the same name, e.g. using a Jupyter Notebook, to make predictions using the model. But it remains a very different thing.

One example would be "architecture" (e.g. linear model, logistic, feed-forward neural network, etc.) another would be how many parameters does it contain. etc. Bquast (talk) 19:33, 21 June 2023 (UTC)

To your point @Jonesey95, AlphaFold doesn't use any infobox template, probably because there isn't one with a good fit ATM Bquast (talk) 15:13, 22 June 2023 (UTC)

That appears to be because nobody has added one. The word "software" or "program" appears half a dozen times in the article, indicating that this infobox is likely to be suitable. Many similar articles in Category:Deep learning software applications use this infobox with no trouble. – Jonesey95 (talk) 15:20, 22 June 2023 (UTC)

Okay, this doesn't seem productive. A computer model is for many reasons (some listed above), different from a computer program. Yes there are programmes that use computer models, just like there are programs that use computer images. A computer program is not the same as a computer image. Maybe AlfaFold is an example of a program that uses a model, so a poor example by me. Bquast (talk) 16:21, 22 June 2023 (UTC)

Adding more links

I'm curious why there's some links missing from this template, for example "latest version" has a hyperlink to software lifecycle article, but "initial version" doesn't have any. The programming language one could also have a link to a programming article. Elfguy (talk) 03:50, 29 June 2023 (UTC)

The template could instead make a heading and linking to Software release cycle instead of linking two of the three labels. SWinxy (talk) 12:36, 3 July 2023 (UTC)

Discontinuation date field

Should a "discontinuation date" field be added? It can be used on deprecated messaging services. Elominius (talk | contributions) 21:53, 8 October 2023 (UTC)

We have |discontinued=, which changes "Stable release" to "Final release" as shown in this test case. Does that meet your request? – Jonesey95 (talk) 17:19, 9 October 2023 (UTC)

"Final" release could be misinterpreted as "last release so far" by some readers, whereas a "deprecated" field would unambiguously clarify that the software is deprecated. Also, the release date of the final version before deprecation is not the same date as the deprecation of the service. A messaging service might be phased out by being supported for months after the final version was published. Elominius (talk | contributions) 13:13, 14 October 2023 (UTC)

That distinction seems like something best done in the body of the article, in the few cases where it may be needed. – Jonesey95 (talk) 14:05, 14 October 2023 (UTC)

"Final" is strictly defined as being the very last, not the latest. IceWelder [✉] 18:07, 14 October 2023 (UTC)