This template is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software 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.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware
I propose we rename this label "Languages" or "Languages supported". I don't think this particular field is that suitable for the infobox, but it should not be marketing jargon, even if we want to avoid the confusion between computer and human languages. I think "Languages" is fine, but if anyone's feeling particular, we could easily use "Human languages supported". — HTGS (talk)04:36, 18 March 2025 (UTC)[reply]
(I say "I propose", but really I'm only looking for objections. If you see a problem with this idea, please say so, or I will just change it.) — HTGS (talk)04:37, 18 March 2025 (UTC)[reply]
Oppose Like you said, "language" in a software infobox implies a programming language; at the same time, "human language" sounds awkward and unnecessarily wordy. The current use of "available in" is consistent with other infoboxes such as {{Infobox software}} and {{Infobox website}}. InfiniteNexus (talk) 21:46, 3 April 2025 (UTC)[reply]
I’m a little surprised by both responses. The phrase “available in” is far more ambiguous than “language”. Worth remembering that both of these labels are in some sense meaningless without the parameter content, but the label doesn’t display without the content anyway. — HTGS (talk)04:29, 8 May 2025 (UTC)[reply]
Editors are expected to reference the template documentation before filling out the parameter, if they are unfamiliar with what is supposed to go in there. InfiniteNexus (talk) 19:47, 13 May 2025 (UTC)[reply]
Use of "Update Method" and proposing "Release Method"
The description on this page notes that this parameter is to be used for ways in which the operating system can be updated. Looking at the use of the parameter on different desktop/server OS pages it seems to be used to describe the release methodology, rather than the update methods. By definition this parameter overlaps a bit with the "package manager" parameter in the Linux ecosystem.
I think it may be a good idea to add a "release method" [RM] parameter for noting how the OS is released, separate from the methods in which to update it. For example, RM would cover concepts like Long term support, Rolling release, Continuous Delivery, major/minor releases, etc.
If a new method is undesired, then a clarification of how the Update Method parameter is intended to be used would be appreciated. OmenosDev (talk) 15:56, 16 July 2023 (UTC)[reply]
So the idea is that "update method" is "what is the mechanism used to distribute updates?" and "release method", or whatever it ends up being called, is "what is the release schedule, what types of releases are there, etc.?" If so, maybe "relase methodology" or "release policy" would be a better term, as it's not a mechanism, it's a policy. Guy Harris (talk) 18:41, 16 July 2023 (UTC)[reply]
So the parameter is currently used for both purposes, with some OSes using it for the mechanism used to distribute updates and others using it for the policy used for those updates. Guy Harris (talk) 19:01, 16 July 2023 (UTC)[reply]
Logging in for the first time in a while...
Yes, the parameter is currently used in a multipurpose capacity which is confusing as it lacks consistency across pages. From this thread alone it seems there may potentially be three different concepts to consider:
Release Policy: The policy describing the lifecycle and versioning of the platform.
Update Method: The ways in which a user can update/upgrade platform components or the version of the platform itself.
Distribution Strategy: The mediums in which users receive the base platform and/or updates from the official provider:
Physical media (floppy, disk, usb, appliance, etc)
Digital download (ISO, pre-built image, network downloads, etc)