Template talk:Infobox software/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

Edit request on 19 July 2012

I think that it would be more useful to link to internationalization and localization for the language parameter label, as in: Available in Thanks.

Kiwi128 (talk) 09:29, 19 July 2012 (UTC)

Perhaps better to delink it rather than have an unintuitive link. — Martin (MSGJ · talk) 12:16, 19 July 2012 (UTC)

The current link, [[Language|Available in]] (Available in) is certainly unintuitive and falls foul of WP:OVERLINK. The suggested piped link to Internationalization and localization seems much more fitting and I support the proposed change. -- Michael Bednarek (talk) 12:22, 19 July 2012 (UTC)

These are both a bit WP:EASTEREGGy to me. Can we go with a slightly longer link for both programming language and language? How about "Programming language used" and "Translations available"? Chris Cunningham (user:thumperward) (talk) 13:34, 19 July 2012 (UTC)

I support Chris Cunningham's suggestion. I think that linking to internationalization and localization would make sense in the context of that change. Kiwi128 (talk) 10:49, 21 July 2012 (UTC)

Same here; "Programming language used" (instead of "Written in") and "Translation available" (instead of "Available in") seem much more sensible labels. -- Michael Bednarek (talk) 12:51, 21 July 2012 (UTC)

 Done; thanks for the input, folks. Chris Cunningham (user:thumperward) (talk) 11:42, 22 July 2012 (UTC)

With the change from "Written in" to "Programming language used", the text is much longer, more than twice, the Infobox becomes much wider. You can see this for example in VLC media player. I suggest to revert this change, or to use "Programmed in", which is smaller. --KDesk (talk) 18:03, 24 July 2012 (UTC)

The main reason for the size of that infobox is the screenshot size specification of 300 pixels. Still, you're right to point out that the infobox will indeed be wider using this label. I suggest to break it over two lines. -- Michael Bednarek (talk) 06:44, 25 July 2012 (UTC)

Thanks for pointing that out, now I know why the text in the infobox in Game Maker shows just a word per line. I agree with KDesk, please revert. Longbyte1 (talk) 02:55, 4 August 2012 (UTC)

I also think it should be reverted. — Dmitrij D. Czarkoff (talk) 03:04, 4 August 2012 (UTC)

I agree, the width is an issue. A viable option would be to remove "used" --TheJosh (talk) 02:02, 6 August 2012 (UTC)

Why not "Written in" or "Programmed in" with the link to "Programming language"? --KDesk (talk) 02:39, 6 August 2012 (UTC)

Would it not be more sensible simply to remove the white-space: nowrap declaration which prevents these lines from breaking? Chris Cunningham (user:thumperward) (talk) 10:46, 7 August 2012 (UTC)

I strongly support TheJosh's suggestion to remove "used". Jesus Presley (talk) 22:50, 9 August 2012 (UTC)

+1 Please wrap programming language used so it doesn't effect the width of the infobox (like OS infobox wraps Default user interface). --Pak1standby (talk) 09:50, 6 September 2012 (UTC)

• I have marked the edit protected request as answered, but I haven't implemented any changes at this time. I don't see a consensus for any particular action in the above discussion, and changes to the template should be supported by consensus. Maybe you could start an RfC here and link to it from the relevant WikiProjects? — Mr. Stradivarius ^{(have a chat)} 08:06, 15 August 2012 (UTC)

 Started RfC and notified WikiProjects:

• WikiProject Computing
• WikiProject Software
• WikiProject Free Software

Any other suggestions? — Dmitrij D. Czarkoff (talk) 12:00, 15 August 2012 (UTC)

Proposed changes

I prepared a draft changing two aspects of this infobox:

1. Translations are handled by three parameters allowing to have a number of supported languages in "Translation available" section of infobox with the full list collapsed. The change is intended to improve the readability of infobox and to leave a place for mentioning all available translations (articles normally don't list those in body, and probably can't do so per WP:WEIGHT). The old syntax also works with no visual changes.
2. Another format for alexa rankings is proposed in docs (no code changes).

See draft (diff and doc diff) for details. — Dmitrij D. Czarkoff (talk) 16:21, 3 August 2012 (UTC)

In the lack of opposition requesting edit. — Dmitrij D. Czarkoff (talk) 23:02, 9 August 2012 (UTC)

 Done. Let me know if there are any issues with the code. Best — Mr. Stradivarius ^{(have a chat)} 08:15, 15 August 2012 (UTC)

Now, when the whole thing landed, could please someone more experienced in collapse/hide templates tell me, where it is possible to have "show/hide" handle in one field of infobox and the collapsed text in another, so that the whole collapsed section would become invisible unless "show" handle from another field is used. In this particular case I would prefer to hide the "language" field ("List of languages" thing) completely and place the "show/hide" handle into "language count" field (currently "Translation available"). — Dmitrij D. Czarkoff (talk) 08:04, 17 August 2012 (UTC)

I prepared another draft (in this template's sandbox this time), and I would ask everyone to express opinions on this change (see testcase), which is potentially controversial: the collapse handle is "◳" symbol, so discoverability might be a problem. — Dmitrij D. Czarkoff (talk) 19:58, 19 August 2012 (UTC)

Yeah, I don't think the ◳ thing is going to work, sorry. The current version is clearer and easier to use than your proposed version. Why do you want to do this anyway - is it just to save one row? — Martin (MSGJ · talk) 08:42, 14 September 2012 (UTC)

For me, the ◳ symbol is a box containing the number 25F3 - I realise that it's supposed to look like this, which seems logical. However, with the entire second column showing "no", I'm not the only one with trouble, so it's not a good idea to use characters which don't have wide support. --Redrose64 (talk) 09:18, 14 September 2012 (UTC)

@MSGJ: Ideally I want a standard [show] handle in that row, as having this handle following the show/hide template is more natural and intuitive. Still, as I get it, it is currently impossible.

@Redrose64: decisive argument. I just thought that these days unicode is supported to greater extend. Are you using XP? — Dmitrij D. Czarkoff (talk•track) 10:17, 14 September 2012 (UTC)

Yes, Windows XP SP3. --Redrose64 (talk) 10:41, 14 September 2012 (UTC)

Does it render properly this way: ◳? — Dmitrij D. Czarkoff (talk•track) 10:59, 14 September 2012 (UTC)

No; it's the familiar numbered box. --Redrose64 (talk) 19:28, 14 September 2012 (UTC)

FWIW, my windows 7 SP1 box also uses a font without u+25F3:-( 82.113.98.214 (talk) 19:45, 23 January 2013 (UTC)

RfC: natural and programming languages labels

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The result was to implement option 1. There were good arguments made about the clarity of some of the terms (namely "written in", "available in", and "language"), but these were equally matched between option 1 and option 3, and well countered by the argument that all of the terms would be clear in context. Given that option 1 saw more popular support and that multiple editors were of the opinion that the terms in option 3 were too technical, there seems to be a rough consensus to use option 1. Also, there did not appear to be any consensus to use any particular wikilinks for the terms, and it seems that the terms in option 1 will be comprehensible enough without linking them anywhere. — Mr. Stradivarius ^{(have a chat)} 04:24, 16 September 2012 (UTC)

---

This RfC is supposed to probe for consensus on infobox labels in the fields about natural languages the software is available in and programming languages the software is written in. The context for this RfC can be found in Edit request on 19 July 2012 section above. — Dmitrij D. Czarkoff (talk) 11:51, 15 August 2012 (UTC)

Wording

The previously proposed versions are listed in table below. Feel free to amend it if you have a better idea.

Option 1 Written in C++, C#, HTML5 and JavaScript Available in English, French, German, Italian, Spanish and Arabic

Option 2 Programming language used C++, C#, HTML5 and JavaScript Translation available English, French, German, Italian, Spanish and Arabic

Option 3 Language C++, C#, HTML5 and JavaScript Localization English, French, German, Italian, Spanish and Arabic

Support Option 1

1. It is shorter and still as intelligible as the second one, but does less impact on the size of infobox. — Dmitrij D. Czarkoff (talk) 11:51, 15 August 2012 (UTC)

   Though I'm not opposed to option 3 with its "common names" rationale, I prefer option 1 as "Written in C" sounds more like a sentence then "Language C". The option 2 is a nightmare. — Dmitrij D. Czarkoff (talk) 13:11, 18 August 2012 (UTC)

2. Maybe I am missing something, but, like DDC, I don't see any problem with 1. JonRichfield (talk) 12:43, 15 August 2012 (UTC)
3. Slight preference over 3--"Language" in isolation could mean either one, the terms used in this option are both short enough and unambiguous. --j⚛e decker^talk 02:10, 17 August 2012 (UTC)
4. This option is friendly to the less-technical reader and gets the point across in a concise manner. --Nouniquenames (talk) 16:03, 17 August 2012 (UTC)
5. For being short and unambiguous, I prefer this option. --KDesk (talk) 21:40, 18 August 2012 (UTC)
6. This option is clear and obvious, even to those who don't have a clue what "Localization" means. Ebikeguy (talk) 21:24, 28 August 2012 (UTC)
7. This is less technical and more comprehensible to the ordinary Wikipedia user. —JOHNMOORofMOORLAND (talk) 09:48, 7 September 2012 (UTC)
8. This option is compatible with both single and multiple languages in both rows.IvanKesson (talk) 18:35, 8 September 2012 (UTC)
9. Hi. This option seems the best (and significantly better) in comparison to the rest. (Option #3 is the worst, due ambiguity; Option #2 gives article an awkward look.) However, I prefer "written in" was changed to "developed with". Best regards, Codename Lisa (talk) 15:48, 9 September 2012 (UTC)
10. "Written in:" is a fine choice, given the other two. At Quassel IRC an editor has gone so far as to delete the parameter rather than look at the squished infobox contents. Can we have this wording as an optional parameter until this is closed? --Lexein (talk) 09:34, 12 September 2012 (UTC)
11. Option 1 is the best, although I’d align the languages bit with “Infobox OS” where it results in “Available language(s)” (with line break), Option 3 too technical, Option 2 a complete catastrophe, although the biggest problems with Option 2 are the non-breaking spaces. Option 2 with line breaks would be somewhat bearable. --KAMiKAZOW (talk) 10:39, 12 September 2012 (UTC)
12. I think this is the best option. Clear and simple. — Mr White 20:21, 13 September 2012 (UTC)

Support Option 2

Support Option 3

1. The simplest combination of technical terms and clarity. --Errant ^(chat!) 13:08, 15 August 2012 (UTC)
2. per above, common names, this is an encyclopedia! mabdul 22:19, 16 August 2012 (UTC)
3. 76Strat ^String da _Broke da (talk) 16:09, 17 August 2012 (UTC)
4. Least-worst option, if only just. This slightly increases template complexity because of the need to introduce a UK/US language switch for localisation/localization, but "available in" could mean anything and we want labels which impart meaning by themselves. Chris Cunningham (user:thumperward) (talk) 16:14, 18 August 2012 (UTC)
   • I wouldn't worry about localising Localization (ahem ;)). It's hardly as if they are totally incomprehensible on either side of the Atlantic. --Errant ^(chat!) 19:57, 18 August 2012 (UTC)
   • "Available in" on its own is very ambiguous, but "Available in English" is not, and this label isn't shown if programming language is not specified. — Dmitrij D. Czarkoff (talk•track) 22:26, 8 September 2012 (UTC)
5. I like this one the best. Very clear. • Jesse V.^(talk) 06:54, 20 August 2012 (UTC)
6. per user:ErrantX Kaini (talk) 19:17, 21 August 2012 (UTC)
7. It is concise and clear, from the context it is clear that it's referring to a programming language, so "Language" suffices, and "localization" is a better term than the others Silvrous (talk) 15:20, 5 September 2012 (UTC)
8. This is a table, not an effort at constructing sentences from separate components. The concise wording (single words) makes option 3 easy to follow at a glance. For comparison, traffic signs (the signs themselves, rather than that article) are supposed to be designed with the minimum wording necessary to accurately convey the necessary information. Although users of Wikipedia aren't physically travelling at speed as drivers do, their eyeballs are moving quickly and therefore the same KISS principle should apply. (Apologies for the ironic lack of brevity in my comment here.) TL;DR Keep it simple, stupid! -- Trevj (talk) 12:21, 11 September 2012 (UTC)

Another wording

• How about "Implemented in" and "Localized in"? —Ruud 21:55, 16 August 2012 (UTC)

Wikilink for natural languages

These are proposed targets for wikilinking the labels (see previous subsection):

1. Language
2. Internationalization and localization
3. Language localisation
4. better target of your choice.

Wikilinking: !votes and discussion

• 2 (Internationalization and localization) — it seems to be more relevant in this context. — Dmitrij D. Czarkoff (talk) 11:51, 15 August 2012 (UTC)
• "Language" and "Localization" (drop Internationalization) seem the obvious choices; they are the technical terms, and can be linked to help the uninitiated comprehend them --Errant ^(chat!) 12:20, 15 August 2012 (UTC)
  • Eh, you mean language, localization or both? This is about wikilinks to the labels above, not about labels themselves. — Dmitrij D. Czarkoff (talk) 12:30, 15 August 2012 (UTC)

Oh, OK. Well my general view is that it should be e.g.

Language PHP, Python

Localisation English, French

That is short but clear to any technically literate person, and easily linked to the definitions. --Errant ^(chat!) 12:39, 15 August 2012 (UTC)

• If option 1 or 2 above is used, I see no need for this. With option 3, it may be a good idea. --Nouniquenames (talk) 16:06, 17 August 2012 (UTC)

A simpler approach

Stable release	2.8 / May 3, 2012 (2012-05-03)
Preview release	2.7.5 / March 14, 2012 (2012-03-14)
Programming language used	C and GTK+
Operating system	AmigaOS 4, FreeBSD, Mac OS X, Microsoft Windows, Linux, Solaris

In the section above, I suggested simply removing the whitespace override that this template invokes to keep labels on one line. I didn't receive a response to that, and unfortunately this RfC started before I thought to roll it out. Anyway, I've made that change to the deployed template. Can everyone have a look to see whether this, the simplest way to fix the issue, seems to work out for them? If not I'll revert and chip in regarding the above proposals. Chris Cunningham (user:thumperward) (talk) 10:38, 18 August 2012 (UTC)

• Strong oppose: the unnatural, long wording. I would also note, that it is specifically ugly in the real world instances (as on the right), where the label is split to three rows with a single-row data field. And my calculation using List of programming languages shows that average length of programming language name (with no regard to languages' popularity, which would lower the average per-infobox number) is 6.699 symbols, so the data field would normally be single raw unless more then 3 programming languages are used. Please, revert ASAP. — Dmitrij D. Czarkoff (talk) 12:35, 18 August 2012 (UTC) updated 13:01, 18 August 2012 (UTC)
  • That infobox displays at two rows for every resolution. What browser are you using? Note that the operating systems row splits to two as well, and this also causes frequent problems with width at the moment. Chris Cunningham (user:thumperward) (talk) 13:09, 18 August 2012 (UTC)
    • I use xombrero and Web, though I suppose every WebKitGTK+ browser renders similarly (screenshot). I believe that labels in infoboxes shouldn't be split until there is no reasonable doubt that the data field will be split in yet more rows. — Dmitrij D. Czarkoff (talk) 13:16, 18 August 2012 (UTC)
      • Ah, right: it appears to be a theme issue, because you're running one of the alternative page themes (incidentally, any chance of using an image host which doesn't have such, erm, NSFW adverts in future? Thanks!). I've reverted. Chris Cunningham (user:thumperward) (talk) 16:12, 18 August 2012 (UTC)

• Folks, I am rapidly getting that shoe davmi cotinpikin hedred feeling. Bring back my minder, someone! Look, it is largely a matter of:

• Who are we (errr..., you, plural?) writing this for?

• • If for anyone sane, it hardly matters, because no one sane would read it for long, and they would rapidly drop it for the sake of their sanity.
  • If for anyone else, it hardly matters, because either they would know what it is all about and understand it because they were not encumbered with sanity, or would not understand it and not care because they were not equipped for sanity, or the other way round on choose days.

Not shell snortig into either such circumscription myself (not by day anyway), I still would go for option 1, but if for reasons (you should excuse the expression!) of aesthetic concision (blackmail and localization are such ugly words, aren't they?) that should happen not to suit, then why not use Idiom and Argot instead, as option 4? Those terms have the right number of letters at least, and the right sense, which is more than I can say for myself. JonRichfield (talk) 15:01, 18 August 2012 (UTC)

May be I'm stupid, but I don't understand this comment. — Dmitrij D. Czarkoff (talk) 15:26, 18 August 2012 (UTC)

Bottom line: I recommend 1, as being clear and easy, but if you guys are hard up for something minimalist in character, how about "idiom" and "argot"? JonRichfield (talk) 16:29, 18 August 2012 (UTC)

Well; "written in" may well be nonsense for some programs. And "available in" could mean many things. Better not to dumb it down for the sake of hand holding, especially if it is actually more confusing. --Errant ^(chat!) 19:59, 18 August 2012 (UTC)

Don't forget that these labels are only shown with data fields, so ambiguous "available in" becomes unambiguous "available in English, Klingon". Could you please draw example of nonsense "written in" BTW? — Dmitrij D. Czarkoff (talk) 20:04, 18 August 2012 (UTC)

This is storm-in-teacup stuff. The difference between the most and least cumbersome version is more trivial than the amount trouble expended already in discussion. I reckon that 1 is the most nearly universally acceptable, so if you don't all accept it without further ado, I'll go and slit my wrists, so there! (Mind you... "argot"... hmmm... don't rush me, be you never so tempted...) JonRichfield (talk) 08:44, 19 August 2012 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Text on template

Please pay attention it does not always display well, for example: Hudson (software). --Aleksd (talk) 16:50, 30 August 2012 (UTC)

What does not display well? Maybe it is a problem with your browser, do you have a screenshot? --KDesk (talk) 00:19, 31 August 2012 (UTC)

At least for me it indeed does not "display well". From layout point of view this is a disaster. — Dmitrij D. Czarkoff (talk) 01:02, 31 August 2012 (UTC)

I think the problem is that some words, like 'Programming language used' are to wide. This is being discussed in this same talk page, above. --KDesk (talk) 19:12, 31 August 2012 (UTC)

Lack of Preview Release in GIMP says "non" instead of "none"

Hi all, in GIMP currently, the Preview Release in the infobox says "non" instead of "none". Here is a link to the current version. Please look into fixing it - I don't have the necessary permissions. Shlomif (talk) 19:24, 19 October 2012 (UTC)

Edit request on 8 December 2012

Please would you add devices to this and would you also add purpose please

Google9999 (talk) 10:11, 8 December 2012 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. Also, are the existing parameters |platform= and |genre= lacking in some way? --Redrose64 (talk) 16:53, 8 December 2012 (UTC)

Discontinued

Hi I would like someone to add a separate place to put discontinued instead of next to latest software realise is please 109.155.48.80 (talk) 07:37, 9 January 2013 (UTC)

Hi. You already have status. You can write: |status = Discontinued on {{start date and age|YYYY|MM|DD}} Best regards, Codename Lisa (talk) 12:59, 9 January 2013 (UTC)

List of languages

On MPC-HC I tested the nice language count feature. The visible result are four lines: (1) "Available in 24 languages", (2) empty, (3) indented and collapsed "list of languages [show]", (4) empty. How about only one collapsed line "Available in 24 languages [show]"? –82.113.98.214 (talk) 19:24, 23 January 2013 (UTC)

In principle this sounds like a good idea to me. However it seems not quite trivial to implement this correctly. Right now the "List of languages" is defined as an additional data field in the {{infobox}} and is a {{hidden}} section that requires a title. Probably we should omit the additional data field and omit the title (or use the number of languages as title). However we have the problem that the long list of languages is then squeezed right to the "Available in" label and doesn't use the whole width of the infobox as it does now, though wasting a lot of space and making the box very long as soon as the list is expanded.
To solve this satisfactory it probably needs somebody with a little more experience with Wiki source and the used templates. -- Patrick87 (talk) 15:35, 3 February 2013 (UTC)

Edit buttons for "Stable release" and "Preview release"

Over at Template talk:LSR there's currently discussed a recent style change for {{LSR}} (and {{LPR}} respectively): {{LSR}} was changed to show a little [edit]-button next to the version number whereas {{LPR}} shows the old style where the version number itself is linkified. Since {{LSR}} and {{LPR}} are mainly used in {{Infobox software}} it's probably best to make the decision considering also how it appears in {{infobox software}} and make changes accordingly. Considerations so far are:

• Is it really intuitive to click a version number to edit the corresponding Wiki page? The common reader would rather expect a link to the changelog or something like that. Therefore we should probably have a separate "edit"-button of some kind.
• The {{infobox software}} right now adds an additional edit button in the form of the small [±]. That's in fact not bad. However right now this results in two links doing the same. Therefore the button should probably be part of {{LSR}} and {{LPR}} and should be removed from {{infobox software}}.
• The [±] button is compact which is good. However it's not clear what it really does. It should be decided wether we prefer compactness an keep the [±] or if we prefer clearness and change it to [edit] or something similar.

Please feel free to discuss here or over at Template talk:LSR -- Patrick87 (talk) 15:59, 3 February 2013 (UTC)

Latest release date not displaying

I've just added an infobox to GnuWin32, with a "latest release date" parameter, but no "latest release version" parameter. The infobox isn't displaying this information, despite the documentation saying it ought. I don't have enough skill (or, right now, the time to learn) at editing template formatting to fix this. Would somebody care to take a look and resolve? —me_and 13:25, 8 March 2013 (UTC)

Hello. This behavior seems to by design. Nevertheless, this template is locked and only users holding at least sysop privilege (administrators) can edit it. You can insert an edit request template on this topic to attract the attention of an admin. For the time being, I updated the documentation to reflect the current condition until it is changed. Last but not least, why would anyone provide a release date without providing a version number? Best regards, Codename Lisa (talk) 14:08, 8 March 2013 (UTC)

Yes, this is totally intended. A release date is always an additional information regarding a release version. Without specifying a version it doesn't make sense to specify a release date (at last I can't imagine any case where this could be useful). Additionally this is very helpful in case of the "latest preview version": If this version becomes stable one only has to delete this parameter to completely remove the "Latest preview release" entry (including release date) from the infobox. -- Patrick87 (talk) 14:48, 8 March 2013 (UTC)

The use case I saw was for a software project that bundles a number of pieces of free software; each contained piece of software has its own version number, but there's no overall version number. This is the case for GnuWin32–I think it's useful for readers to see at a glance that the project was last updated in 2010 (updating the sed package to v4.2.1), even when GnuWin32 as a whole has no version number. —me_and 10:13, 11 March 2013 (UTC)

Well, I see the problem now. Basically one would need to add a new parameter to the {{infobox software}} like "last updated" (since there can't be a release date if there is no release) but I think this use case is so rare that it would hardly justify such a change. You could put in the version number of GetGnuWin32 or maybe a simple "–" or "no version number" as a workaround. -- Patrick87 (talk) 13:23, 11 March 2013 (UTC)

Fair enough. Thanks for your help! —me_and 17:05, 11 March 2013 (UTC)

Hi. Actually, you can use {{infobox}} as well to fully customize the output. But, just for the record, I am not in favor of changing this template for now. I favor methodical approaches to problems and believe an exception does not merit a fix on global level. Best regards, Codename Lisa (talk) 18:00, 11 March 2013 (UTC)

P.S. Isn't 0.6.3 the latest version of GnuWin32, released on 16 November 2009?[1] Best regards, Codename Lisa (talk) 18:06, 11 March 2013 (UTC)

That's only the version of the installer. It downloads/updates pages from the internet if I understand correctly. -- Patrick87 (talk) 18:22, 11 March 2013 (UTC)

Good point on using {{infobox}} directly. I've swapped the article to use that instead. Thanks again! —me_and 11:15, 12 March 2013 (UTC)

"Stable release" and "Preview release"

I'll be updating the code of {{infobox software}} to fit the new style of {{LSR}} and {{LPR}}, that is mainly removing the "[±]" button for updating the LSR and LPR templates since the button is now included into these templates themselves.
There are however two cases where I'm not sure what the best behavior in {{infobox software}} would be and some feedback would be welcome:

1. If there is no content displayed by {{LSR}} or {{LPR}} respectively (e.g. if there is currently no preview version but there has been one before and the version number in the template has been edited out, see GIMP for an example) – should we omit the field "Preview release" release then? That would be the behavior favored by me. However there's no way to quickly see if there already exists a latest release template and to edit it quickly by making use of a button.
2. Should we allow to use the parameters "frequently updated" and "latest preview version" to be used at the same time? A software that is often updated doesn't necessarily have preview releases often. Therefore many blank Template:Latest preview software release/XXX pages exist which wouldn't be necessary.

Regards -- Patrick87 (talk) 15:16, 22 March 2013 (UTC)

I updated the code in sandbox so it doesn't show the [±]-button twice anymore and request to change the template code to Template:Infobox_software/sandbox&oldid=547517774. For now also empty {{LSR}} or {{LPR}} templates are suppressed (see 1. above) and mixing "frequently updated" and "latest release version"/"latest preview version" works (but it did that before, too; see 2. above). Some input on the two questions would still be welcome, though. -- Patrick87 (talk) 23:36, 28 March 2013 (UTC)

Done --Redrose64 (talk) 10:39, 29 March 2013 (UTC)

Thanks! -- Patrick87 (talk) 13:53, 29 March 2013 (UTC)

hi could you update Template:Infobox OS and Template:Infobox OS version and remove the + button because it is showing twice Skybliei (talk) 09:02, 9 April 2013 (UTC)

Sure, I'll fix it when I get home. Are there any other info boxes that use {{LSR}} and {{LPR}} templates I'm not aware of which need fixing, too? -- Patrick87 (talk) 11:12, 9 April 2013 (UTC)

I fixed Template:Infobox OS but Template:Infobox OS version actually doesn't use LSR and LPR at all. What should be updated then? -- Patrick87 (talk) 19:06, 9 April 2013 (UTC)

Wikidata

FYI, it isn't up to the English Wikipedia's standards yet, but Wikidata now provides latest stable version data. Since most of the LSR templates at the Vietnamese Wikipedia were quite outdated, we replaced them with Wikidata claims using this module and this edit button. The module is capable of handling multiple versions for different platforms and sorting 12.34.56-style version numbers. You can see an example of it in action at "Google Chrome". We haven't all-out adopted Wikidata yet, but LSR seemed like a good starting point, since {{LSR}} and Wikidata are both attempts to isolate infobox data from the rest of the article.

Eventually, once Wikidata has adequate support for dates and citations, it'd be great to see the English Wikipedia share its data through Wikidata, pending the results of the RFC. Other wikis' software articles would benefit greatly from the English Wikipedia's participation, just as they did when this wiki transitioned to Commons for free media.

 – Minh Nguyễn (talk, contribs) 11:10, 13 May 2013 (UTC)

The problem with Wikidata generally is its less immediate access and that fewer eyeballs watch it. For access, something like the current system for interwiki links is needed. As for eyeballs: I don't see any way of implementing safeguards against mischievous modifications of Wikidata properties. -- Michael Bednarek (talk) 13:18, 13 May 2013 (UTC)

Revive Proposed Change: Add "Repository" Field

This proposal was made, and not done previously: Template talk:Infobox software/Archive 3#Source Code Repository Field. I'd like to revive the change, which I have commenced through opportunity for discussion on Wikipedia talk:WikiProject Computing and Wikipedia talk:WikiProject Software, as well as with a specific diff of the proposed edit.

Mattsenate (talk) 17:52, 16 May 2013 (UTC)

What's the point of this? We already have a URL - and from that URL, the user should easily be able to get to the source code repository. Why maintain two links here, instead of letting the main URL maintain the repository link? --Obi-Wan Kenobi (talk) 18:05, 16 May 2013 (UTC)

I'm sharing the opinion of Obiwankenobi. Additionally a link to the repository would be interesting only for a very small group of experts, anybody else doesn't care about source code anyway. --Patrick87 (talk) 18:17, 16 May 2013 (UTC)

Hi. I agree. Infobox should not turn into a medium for circumventing WP:ELNO and MOS:ELINKS. Repositories are often linked from the main website and sometimes from the version number, as a reference. ELNO and ELINKS forbid such links. Best regards, Codename Lisa (talk) 20:02, 16 May 2013 (UTC)

To me it's not really about MOS:ELINKS, it's more about (1) dual maintenance of two URLs vs one, especially when the second URL may be more likely to change than the first (someone moves from sourceforge to github but retains their software.com URL (2) source repositories generally only exist for open source software, so for much software this link would have nowhere to point. --Obi-Wan Kenobi (talk) 20:19, 16 May 2013 (UTC)

Only a small proportion of titles have an accessible source code repository; that makes it unsuitable as an infobox field. -- Michael Bednarek (talk) 01:35, 17 May 2013 (UTC)

I've removed the edit request until there is consensus for a change. --RA (talk) 20:49, 20 May 2013 (UTC)

As a compromise w/r/t the discussion above, I added links to the version number values such as on the LocalWiki page. I'd like to update the help text for this template to recommend linking from version numbers if source code is available. Mattsenate (talk) 21:34, 24 May 2013 (UTC)

Hi. I am afraid I neither think it is a good idea nor a compromise. I am not sure it is not against WP:EL either. What's wrong with standard citation style anyway? Best regards, Codename Lisa (talk) 11:18, 25 May 2013 (UTC)

In line with WP:EL#What to link, when reading the article, the link to source code allows one to browse immediately to content that is accessible, tasteful and factual, as well as likely to remain functioning (it is reasonable to expect that a source code repository will remain on github, and may be updated at some reasonable point in the future). Further, since this article refers specifically to a software project, linking to the source itself seems to me to qualify for both options 2 and 3 of WP:ELYES. By demonstrating this on LocalWiki I'm attempting to be bold and rather than needing to ignore all rules, I think folks can assume good faith when I claim that I think adding links to available source code is an overall improvement to the value of individual Wikipedia articles to cover specific topics--such as software--akin to making links to available primary sources. - Mattsenate (talk) 21:51, 28 May 2013 (UTC)

Hi. I don't believe I have seen anyone editing Wikipedia in bad faith and I don't think I am about to find a lot of 'em. But aside from that, your edit, at very best, introduces inconsistent optional style, which WP:MOS frowns upon. By all mean be bold (and if you have to, stay hungry, stay foolish, per Steve Jobs), but when laws are good, hug 'em and don't let them go. Consistency is good, so use Help:Citation Style 1. Best regards, Codename Lisa (talk) 23:24, 28 May 2013 (UTC)

Excellent, I'm glad we agree I'm suggesting good-faith changes. Could you explain why you think this style suggestion is inconsistent? Can you also explain what specific item of WP:MOS is particularly relevant to the proposed change to this infobox's documentation? For reference, I am suggesting a change to Release version on Template:Infobox software#Parameters usage of a parameter that could be stated as below (replace "#0" with whatever appropriate number):

Example #0: If the article is about a product called Example Software and the source code is available online, specify:

[https://link-to-repository.com/full/path/ v1.5]

Further, if citations are to be used, it seems the most relevent is {{Cite:Web}}, which provides very little helpful data specific to source code for software. My previous comment outlines why a direct link is relevant, within guidelines, and less obfuscated than a citation in this particular instance.

Also, consider this use-case of using a direct link in the Infobox, rather than a citation. DuckDuckGo, is an excellent, privacy-based search engine that promotes open content and integration with various web databases, repositories, and services--including snippets of Wikipedia articles. See this search for "LocalWiki", the results include a direct link to the official website. If the infobox's release version parameter value contained a link to a software repository, those projects with available source code could be included alongside the official software link. As demonstrated in this one (of many) examples, there are clear advantages to adding content to the infobox without use of a citation--that ultimately promote re-use and deeper integration of Wikipedia content on the web. E.g. one could see:

More at Wikipedia | Official site: localwiki.org | Stable release: v0.5.4

Thanks for any further clarification and feedback. - Mattsenate (talk) 20:19, 30 May 2013 (UTC)

Your ideas are nice in theory. However I have to refuse them for practical usage. All in-line links in Wikipedia articles are Wikilinks linking only to other articles on Wikipedia (and even here we have the policy not to link between namespaces). The only exceptions are the "External links" sections (were the reader expects external links) and the official Website link directly in the info boxes (which is given without link text though, therefore the user directly nows he's leaving Wikipedia). All other external links inside article text should be given as references. If we start mixing Wikilinks with external links we'll get a hell of a mess, even if it's "only" a version number inside an info box. --Patrick87 (talk) 21:05, 30 May 2013 (UTC)

Hello guys. Sorry, I have to bail on this one to offload some of my Wikitime to normal life (although I don't know the computer meaning of "offload" applies to real life too!) Maybe later. Best regards, Codename Lisa (talk) 10:04, 1 June 2013 (UTC)

Cheers, let me know if you get a chance to address any of my questions or suggestions above, thanks. - Mattsenate (talk) 09:13, 3 June 2013 (UTC)

Patrick87 - If there is no room for external links in the article infobox--why have a "Website" parameter that may contain an external link? Perhaps linking directly to the official website is a beneficial reference that requires more than a citation? For software, if the official source code is available, should there not be a similar direct link? Shouldn't it be easy for folks to travel directly from the Wikipedia article to reading source code? The article is about software after all. - Mattsenate (talk) 09:13, 3 June 2013 (UTC)

It seems you didn't read my answer close enough. I said that we have a Link to the official website and this link isn't hidden behind any link text but the plain URL is shown. This is an exception! And the exception was made because the URL of the software is very important (as you say) with the fact in mind, that all resources the developers are offering are reachable from the developers homepage: Downloads (including source), documentation, etc. Don't you think if we had a source field we also needed a download link field (at least downloading a software is what most people want, don't they)? And if we have a download field we could add a documentation field, since documentation is very important to understand how the software works. Now tell me: Don't you think by yourself this would just be overkill? Wouldn't you consider download links or links to the documentation more important than a link to the source repository? And that's exactly why we'll exclusively keep the official website as a direct link in the info box, since each and every of the above can be reached from the homepage. If you want to add other links you can the to the "external links" section where appropriate. --Patrick87 (talk) 11:30, 3 June 2013 (UTC)

I see where you're coming from, and I appreciate the context you're proposing. I'm glad you brought up documentation and downloads as examples--I actually agree they are not appropriate for the infobox! What's unique about source code is that it is the core content about which the article is focused. Documentation and downloadable copies of the software (zip's, compiled code, etc) are secondary to and distinct from the human-readable implementation in source code. Even non-programmers can read code, and I say this from personal experience and working with other non-coders! Especially consider in-line comments, and various other components of software source code. It is in this unique circumstance that I even make the suggestion that a link is appropriate in the infobox. Source code is in a tricky position. Source code doesn't fit on the page itself WP:NOTREPOSITORY, nor on WikiSource Wikisource:Wikisource:WWI#Reference_material. However, according to item 2 on WP:ELPOINTS, 'External links should not normally be used in the body of an article.[1] Instead, include appropriate external links in an "External links" section at the end of the article, and in the appropriate location within an infobox, if applicable.' Further, there is no mention of "external links" in the Manual of Style for Infoboxes WP:IBX. The stated goal of the Infobox is "to summarize key facts in the article in which it appears" and it is also noted that "[u]sing an infobox also makes the data within it available to third party re-users such as DBpedia in a granular, machine readable format, often using microformats." These are two reasons why I've offered that a link to source code is appropriate, within scope, not against style guidelines, consistent with the goals and intentions of the infobox, true to the core of software articles, and ultimately in-line with the first of WP:5. -- Mattsenate (talk) 22:22, 10 June 2013 (UTC)

Edit request: License → Licensing scheme

Hi. I'd like to propose label 14 ("license") to be changed into "licensing scheme". Hopefully, this will convey that what the infobox is looking for a scheme, not a name printed on top of the license agreement, which is often Company + "EULA", e.g. Microsoft EULA, Adobe EULA, Autodesk EULA, etc.

Although I know this is discussed at great length before, but here is a short explanation: The problem with Company + "EULA" is that it communicates zero information. For instance, Microsoft always supported various licensing scheme for all of its Windows Server operating system, such as retail, volume licensing, Microsoft Software Assurance, etc. "Microsoft EULA" used to appear on top of all of them, although each differed from the other. (Not anymore; Microsoft itself has realized how meaningless this is.) This is opposed to named licensing schemes such as GNU General Public License and Creative Commons license: Any CC-BY-SA v3.0 or GNU GPL v2.0 license contains exactly the same words as another.

Best regards,
Codename Lisa (talk) 13:20, 25 June 2013 (UTC)

I have to oppose. First of all, label 14 is just "License" (and links to the article software license). So I think it's as common and as short as possible (which I think is preferable). What do you expect a change of this label to improve? I'd think this would be confusing for most readers and maybe even wrong (since we give the names of software licenses most of the time). What would a "licensing scheme" of a Microsoft product be (e.g. what do you think of)? If people fill in the wrong information it should simply be clearly stated in the documentation on how to correctly fill in the fields. --Patrick87 (talk) 14:21, 25 June 2013 (UTC)

Hello. Both of your questions are already answered in my original message. The first is "Hopefully, this will convey that what the infobox is looking for a scheme, not a [...]". The second are: Trialware, freeware, freemium, commercial software, retail, volume licensing, SaaS, Microsoft Software Assurance, etc. These are the words that are currently in use in infoboxes and therefore we have vast and overwhelming consensus through editing for them.

I think there should be an arbitration committee ban on using "this would be confusing for most readers" phrase which is used ad infinitum ad nauseam in every discussion without a reason provided. And remember: I am here to answer questions, so if you have a question, please say "I have a question" instead of "Oppose".

Best regards,

Codename Lisa (talk) 06:04, 26 June 2013 (UTC)

Question: Codename Lisa: do you mean you want the article-visible text changed from "License" to "Licensing scheme", the template parameter changed from "license" to "licensing scheme", or both? I think Patrick87's objection is to the former, while my reading of your request is relating to the latter.

I've marked the request as answered. If you're only requesting a change to the template parameter, I see no reason not to reactivate it again once you've clarified. If you're requesting a change to the article-visible text then it's clearly not an uncontroversial change, so you'll need to establish consensus first.

—me_and 17:08, 25 June 2013 (UTC)

Hello

Regarding your question: I proposed a change to the text of label14. Yes, a change to the parameter name is too silly. That said, as I mentioned in my reply to Patrick, there is vast and overwhelming consensus through editing in favor of using licensing schemes in infoboxes. In addition, you have expressed that you do not know what I am proposing; therefore, you are not in a position to decide whether it is controversial and mark it as answered. Finally, if it proved necessary to obtain consensus, I'll call an RFC right here.

Best regards,

Codename Lisa (talk) 06:04, 26 June 2013 (UTC)

• OK, thanks Codename Lisa for clarification. Given these new facts (it didn't get as clear from your initial post as you might have thought) I'd still oppose changing the actual label. Let's keep it as simple as possible (therefore just "License"). That's also consistent across Wikimedia Wikis and everybody has some expectation to what to find labeled with "License" whereas a "License scheme" might make some people stumble. Why I think people might find it confusing? Most laymen don't even really know what "license" means but are used to software having such a "license". The concept of a "license scheme" is more complicated to understand and might cause confusion.

Actually I'm not quite sure if we know what a "license scheme" might be? Or have different definitions of it? Why is "GNU General Public License" a "license scheme" for you? It's a set of similar licenses for me, all being "FLOSS licenses" (that would mean "license scheme" to me, but I don't think this is what you're intending?).

However I concur we might change the documentation to make clear something like "Microsoft EULA" was unacceptable and just to put "Proprietary License" in this case. We have to think a little about the exact phrasing though, since the whole idea of yours isn't that simple after all. --Patrick87 (talk) 09:30, 26 June 2013 (UTC)

• You are welcome. Your concern is also valid: "Licensing scheme" is the same as "Licensing"; scheme is implied here. (I was hoping that "scheme" would prevent such things as "Microsoft EULA" which still give me trouble.) In other words, I did want them to stumble and think before making a change. However, you are right; your examples show that. Marking the topic as "answered". Thanks. Best regards, Codename Lisa (talk) 10:20, 26 June 2013 (UTC)

• OK, great we could consent on this. Do you think we should change the documentation? It's already close to what I proposed above but could probably use some update nonetheless. --Patrick87 (talk) 11:40, 26 June 2013 (UTC)

Problematic parameters

The parameters "standard" and "AsOf" are virtually undocumented. What standard is the first one referring to? What date is the second one referring to?

In any case, the parameter "AsOf" should be removed entirely as a WP:DATED violation (the parameter requires unnecessary updating of the article on a regular basis). Also, note that the version parameters already have associated date parameters anyways. Dogmaticeclectic (talk) 15:40, 2 July 2013 (UTC)

Contradictory message at best. You say you don't know what the parameter is doing, but at the same time say it must be deleted! So, the question is: What has brought you here?

Standard is easy: The word standard says it all. Any technical standard that the software product in question uses, implements or adheres to goes there. The interpreted scope is wide. However, this parameter is underused populating it requires a reliable source. The problem is: Primary sources (the words of the product producers) are not reliable, e.g. ACD Systems claimed that ACDSee Pro v1.0 supported Unicode, whereas in reality it only detected Unicode and generated an error message that does not support Unicode. (Previous versions that did not support Unicode often crashed upon encountering Unicode or simply bailed.

The AsOf parameter is a Wikipedia maintenance parameter, well outside the scope of WP:DATED or any guideline about article contents. Certain bots and members of WikiProjects Software set it per Wikipedia:As of when they feel the date of the last update to infobox must be known. Not used when |frequently_updated= is set. Fleet Command (talk) 20:56, 2 July 2013 (UTC)

Mind adding this information about the parameters to the documentation?

Regarding the apparent contradiction, I'm simply guessing about how that parameter is intended to be used. In any case, you have not actually explained why the parameter should be kept - specifically, you did not provide any examples of when "the last update to infobox [sic] must be known". Per WP:DATED, simply adding a date without specific reasoning is not justifiable - should Wikipedia have last updated dates for every section? Also, this parameter is far too prominently visible to simply be a "maintenance parameter".

"The interpreted scope is wide." - This basically means that this parameter is useless, since the purpose of an infobox in general is to provide information in a standardized way across articles of a particular type... note the "standardized" part. Dogmaticeclectic (talk) 22:19, 2 July 2013 (UTC)

Well, your comment was very useful: It shows that you are stuck in a disruptive editing case, possibly having made edit wars, and to get out, you are trying to make it look like a plausible genuine dispute. But since you have obviously started to think after hitting a revert button or making the wrong contribution, your sentences are argumentative instead of interrogative and the amount of logic in your comment is below zero. I tell you what's the solution: Send him or her a WikiLove, promise collegiality in the future and ask him or her nicely to discuss with you; or cede the discussion to him or her altogether. Continuing this discussion will only make you look bad, because your comments are absolutely nonsense. Fleet Command (talk) 05:39, 3 July 2013 (UTC)

• I'd remove the "AsOf" parameter. It was used in none of the Infoboxes I ever edited and it is an information that is mostly useless to the user. Either we claim that our pages are current (then no such parameter is needed) or we know that they are not (then we don't need iteither since the user knows he has to be cautious).

As for the "standard" parameter I can not think of having this seen either. Since it's bad documented this will not change. Either we clearly state what should be put here (and "Unicode" is not an important information after all) or we get rid of it, too.

If anybody has some examples were these parameters are actually used, some Wikilinks are most welcome! --Patrick87 (talk) 22:53, 2 July 2013 (UTC)

I support removing the "standard" parameter too, but I didn't mention that in anticipation of responses just like the one the other user posted above. Dogmaticeclectic (talk) 23:22, 2 July 2013 (UTC)

Hello, Patrick. Generally, something like Wikipedia:As of represents a public consensus in Wikipedia and won't be changed simply because five or ten editors disagree with it. In addition, the "we know that they are not" is fallacy, because knowledge comes from a source. No one can just step into an article and simply "know" that it is outdated unless he or she investigates. Some articles like Windows 8 have numerous maintainers who frequently vist it, so yes, you are right: They know, because they are in constant contact. On other articles, which do not have fixed maintainers, |AsOf= helps achieve this knowledge.

Now, as for |standards=, just arguing that "I don't use it and haven't seen it used" is far from enough here. A counterargument is "let's start using it." To remove it, you need to prove that it is actually harmful.

Mind you, Infobox software is a locked template, so things don't just find their way in here. You know what mean? No just every editor can add them. Best regards, Codename Lisa (talk) 23:46, 2 July 2013 (UTC)

Regarding WP:As of: I do not question this guideline, but I question it's usability and reasonability in case of infoboxes. {{As of}} is intended to be used on single facts (e.g. a population number, gross domestic product, etc.). It would therefore be needed to be applied separately to almost each and every field of the infobox – unless you make sure every editor always checks/updates all fields of the infobox and only then updates the "As of" date. I think we agree that the former is nonsense, the latter is highly improbable (If I update a version number I normally don't check if a new translation just got available, too). Therefore I think the "AsOf" parameter is just useless in our case since it is either not used at all or if it would be used wouldn't reflect the current state of the infobox correctly in most cases. It only adds unnecessary complexity and another field that is quickly outdated and needs to be updated regularly.

Regarding the "standards" parameter: If you say we should use it – can you actually explain what you think should go there? Can you come up with a reasonable example? Can you explain it in a way even new editors will understand? Can you write an explanation that makes sure the parameter will be used correctly without duplicated/wrong/missing/inappropriate content? — I can't! If you are fit for the job I'm happy to support you in promoting this parameter in the future, but I'm afraid whatever we will do, this parameter will always lack clarity and will therefore contain duplicated/wrong/inappropriate content (or will just be omitted as it is currently done in most cases).

Regarding locking: So what? A locked template neither guarantees that the current content is reasonable nor does it state that we can't easily add/remove content as long as there is consensus. I requested changes to many protected templates already. If we decide one or both of the parameters should be removed, we just request the edit and get it done. No magic involved, no harm done. I don't understand what is upsetting you here. --Patrick87 (talk) 01:09, 3 July 2013 (UTC)

Hello again, Patrick. As always, there is fine judgment behind your messages, only your first communication does not show it! (Let's hope you read: "there is fine judgment behind your messages". ) That said, I am not upset. It has always been a pleasure to talk to you, even though we just occasionally talk and rarely agree. But I have always found you a reasonable person. In our last discussion (see above) you persuaded me into withdrawing my proposition. Now, let's see how we disagree this time...

• Your comment on practicality of As Of did not take two points into consideration: First, it gives the editors a point of reference in time. The editor can query that point in the Article History. And since this parameter is meant for rarely-edited articles which may quickly become outdated, the month and year are enough. The second point is that from a download page, it is usually possible to extract several items in one go, including version number, size and hardware platform. Release date needs looking up in the changelog which also reveals OS changes. So, yes, I am inclined to think this parameter is more useful than you credited it for.
• Yes, I can give you examples. HTML5, CSS3, H.264, OOXML, etc. These are famous standards which are recurrently talked about in software articles. See Internet Explorer, Firefox, Google Chrome, etc. Now, whether they do appear on the infobox or not is a matter of users remembering to add them.
• Again, that's right: There is no guarantee. But there also no aberrant editing. A change has a good chance of being contested between the time it is proposed and the time it is applied, e.g. what you did to my proposition. (See the last discussion in this page.)

Best regards,

Codename Lisa (talk) 01:44, 3 July 2013 (UTC)

I'm afraid we'll really disagree this time, but at least it's always a constructive discussion I'm having with you which makes me think about the topic, so kudos for you as well.

• I'm probably a little biased here: If I need a point of reference (as an editor) I just dig into the history page and don't trust any manually set dates anyway as they are easily forgotten to update whereas you can't trick the history page. Also as a reader I always mistrust dated informations and double check them anyway if they are important to me. But there actually might be use cases as you mentioned.
  I'm afraid this will still not solve the problem with "AsOf" parameters not being correctly updated, but maybe future proves me wrong. Also I don't know how realistic it is that editors are really checking all the infos you mentioned when they change something trivial like a new version number (I'd vote for improbable. Are you actually verifying all parameters whenever you do a small change to an infobox? I admit I don't do it.)
• What you just gave are "web standards". Those make sense for Webbrowsers (as you accordingly gave examples using {{Infobox web browser}}). But how is this supposed to work for the common {{infobox software}}? There are web standards, video standards, audio standards, compression standards, encryption standards, military standards, industrial standards, and so on. There's no indication of what type of standards are supposed to go here. Should we decide on basis of the respective software? How shall we make sure it is used consistently? Some might add a coding standard but is this important to the common reader? Above was suggested to give the character encoding standard – how does that matter in my day-to-day work?
  I still think the definition of the "standard" parameter in this template is by far to vague (rather not present at all). There are many standards for many applications and there is no indication on what standards are supposed to be given.
• That's why we are discussing...

--Patrick87 (talk) 02:23, 3 July 2013 (UTC)

Hi. Fortunately we can consolidate at this stage. I'll see if I can recruit the aid of a bot to ensure the field is properly updated, but it seems we have to agree to disagree at this point. Let's see what others think.

Next, the standard: Yes, the field supports web, video, audio, compression, encryption, military, industrial and every other standard that you might think of in exchange for a source. Sky's the limit, source required. This field gives editors freedom; considerable freedom. I do not see why we should strip them of their freedom just because that freedom is not exploited to its fullest extent. Wikipedia is a work in progress and some areas of it might be unattended. But incompleteness, IMHO, is no reason for deletion. If you love this freedom, you just go nuts and add standards and source. If not, just don't mind. In the meantime, I don't bother my head with the mysterious "common readers" who always become a barrier in every attempt to add contents. Articles need to be complete and even give technical details not appropriate for common readers. Experts are also human and refer to encyclopedia.

Best regards,

Codename Lisa (talk) 12:22, 3 July 2013 (UTC)

A bot? How should a bot do this job? Could you clarify?

I don't mind if we keep standard, but we have to make sure the documentation is written in a way that it is used in a reasonable way. --Patrick87 (talk) 14:01, 3 July 2013 (UTC)

Reasonable, yes. But what do you have in mind?

What I have in mind is secondary sources... although I am evidently cheating here. Just as companies can claim that their product is "premium", "top of the [noun]", etc., they can also claim that it complies with a certain standard. The parameter does not require full compliance but I think there should be referenced supporting prose in the article from a secondary source. For example, in case of OOXML, there is a lot of supporting prose with a lot of source. Best regards, Codename Lisa (talk) 14:30, 3 July 2013 (UTC)

I'd prefer to only allow standards which are particular relevant for the type of software. So if we talk about a Mailserver/client SMTP/POP/IMAP are appropriate and maybe TLS, (but not HTML5 or CSS3, since even if the mail client might support those standards, those are none of the core functionalities of the software). Secondary sources is hard since supporting the fundamental standards is crucial for software but normally not mentioned in reviews unless it's exceotionally notable. --Patrick87 (talk) 14:48, 3 July 2013 (UTC)

Hi. We have other secondary sources beside reviews, such as books and tutorials created by third-parties. But as for your requirement, I fear it is vague enough to be abused while secondary source requirements fulfills it. For example, I doubt a mail server ever try to adhere to an industrial waste disposal standard. Even if it does so, the book will probably not mention it. If, however, it proved so funny or noteworthy that everyone started mentioning it, the editors will probably bypass your requirement and mention it anyway. Best regards, Codename Lisa (talk) 15:10, 3 July 2013 (UTC)

frequently updated

The article Nimbuzz is written with dmy date formats. However, the 'frequently updated' parameter is activated in the infobox, and the imported dates are all mdy. Is there any way of making the dates display as dmy, according to user option? -- Ohc ^¡digame!_{¿que pasa?} 05:30, 6 July 2013 (UTC)

You have to edit Template:Latest stable software release/Nimbuzz (you can reach this page via the small "±" links which are given with the version numbers). There you simply add the parameter "df=yes" to the template {{Release date and age}}. --Patrick87 (talk) 12:33, 6 July 2013 (UTC)

Edit request on 24 August 2013

Long denied request that has been answered

There are many software programs that have three (or more) stages of development, this template should support at least three. I propose inserting a new "alpha" section into the template and replacing "latest version" with "beta". My proposed replacement would look like:

Declined code to changes section

<!-- Two open curly brackets -->Infobox
| bodyclass  = vevent
| bodystyle  = {{{bodystyle|}}}
| title      = {{{title|{{{name|<includeonly>{{PAGENAME}}</includeonly>}}}}}}
| titleclass = summary
| labelstyle = white-space: nowrap;
| image      = {{#invoke:InfoboxImage|InfoboxImage|image={{{logo|}}}|size={{{logo_size|}}}|sizedefault=64px|alt={{{logo_alt|}}}}}
| caption    = {{{logo caption|}}}
| image2     = {{#if:{{{collapsible|}}}|{{hidden begin|title=Screenshot|titlestyle=text-align:center}}}}{{#invoke:InfoboxImage|InfoboxImage|image={{{screenshot|}}}|size={{{screenshot_size|}}}|sizedefault=300px|alt={{{screenshot_alt|}}}}}
| caption2   = {{{caption|}}}{{#if:{{{collapsible|}}}|{{hidden end}}}}
| label1     = [[Software design|Original author(s)]]
| data1      = {{{author|}}}
| label2     = [[Software developer|Developer(s)]]
| data2      = {{{developer|}}}
| label3     = Initial release
| data3      = {{{released|}}}
| label4     = [[Software release life cycle|{{#if:{{{discontinued|}}}|Discontinued|Stable release}}]]
| data4      = {{#if:{{{latest release version|{{{latest_release_version|}}}}}}
 |{{{latest release version|{{{latest_release_version}}}}}} {{#if:{{{latest release date|{{{latest_release_date|}}}}}}
   | / {{{latest release date|{{{latest_release_date}}}}}}
  }}
 |{{#if:{{{frequently updated|{{{frequently_updated|}}}}}}
  |{{#ifexist:Template:Latest stable software release/{{{name|{{PAGENAME}}}}}
   |{{Latest stable software release/{{{name|{{PAGENAME}}}}}}}
  }}
 }}
}}
| label5     = [[Software release life cycle|Beta release]]
| data5      = {{#if:{{{beta version|{{{beta_version|}}}}}}
 |{{{beta version|{{{beta_version}}}}}} {{#if:{{{beta date|{{{beta_date|}}}}}}
   | / {{{beta date|{{{beta_date}}}}}}
  }}
 |{{#if:{{{frequently updated|{{{frequently_updated|}}}}}}
  |{{#ifexist:Template:Latest preview software release/{{{name|{{PAGENAME}}}}}
   |{{Latest preview software release/{{{name|{{PAGENAME}}}}}}}
  }}
 }}
}}
| label6     = [[Software release life cycle|Alpha release]]
| data6      = {{#if:{{{alpha version|{{{alpha_version|}}}}}}
 |{{{alpha version|{{{alpha_version}}}}}} {{#if:{{{alpha date|{{{alpha_date|}}}}}}
   | / {{{alpha date|{{{alpha_date}}}}}}
  }}
 |{{#if:{{{frequently updated|{{{frequently_updated|}}}}}}
  |{{#ifexist:Template:Latest preview software release/{{{name|{{PAGENAME}}}}}
   |{{Latest preview software release/{{{name|{{PAGENAME}}}}}}}
  }}
 }}
}}
| label7     = Development status
| data7      = {{{status|}}}
| label8     = Written in
| data8      = {{{programming language|{{{programming_language|}}}}}}
| label9     = [[Operating system]]
| data9      = {{{operating system|{{{operating_system|}}}}}}
| label10     = [[Computing platform|Platform]]
| data10      = {{{platform|}}}
| label11    = [[File size|Size]]
| data11     = {{{size|}}}
| label12    = Available in
| data12     = {{#if:{{{language count|}}}|{{{language count}}} languages|{{{language|}}}}}{{{language footnote|}}}
| data13     = {{#if:{{{language count|}}}|{{#if:{{{language|}}}|{{hidden top|title=List of languages|titlestyle=background-color: transparent;}}{{{language|}}}{{hidden bottom}}}}}}
| label14    = [[List of software categories|Type]]
| data14     = {{{genre|}}}
| label15    = [[Software license|License]]
| data15     = {{{license|}}}
| label16    = [[Software license|Licence]]
| data16     = {{{licence|}}}
| label17    = [[Alexa Internet|Alexa]] rank
| data17     = {{#if:{{{alexa|}}}|{{nowrap|{{{alexa|}}}}}}}
| label18    = Website
| data18     = {{{website|}}}
| label19    = [[Technical standard|Standard]](s)
| data19     = {{{standard|}}}
| label20    = As of
| data20     = {{{AsOf|}}}
}}<noinclude>
{{documentation}}
</noinclude>

As I have done on Template:Infobox_software/Sandbox and have created a few Template:Infobox_software/Test_cases. Thanks for your time to review this request. Technical 13 (talk) 18:54, 24 August 2013 (UTC) Technical 13 (talk) 18:54, 24 August 2013 (UTC)

I don't think this is a good idea:

• The ordinary reader is not interested in development versions. The latest version that is considered stable would suffice for them.
• Giving the possibility to specify a development version is already a sort of compromise and should be enough for 99 % of people.
• The 1 % of people that are interested in alpha versions keep themselves update through other channels, not a Wikipedia info box
• Right now, "latest preview release" is often outdated (and even "latest stable release" is for not overly popular software). Giving even three possibilities will make this problem even worse.
• "Stable", "Beta" and "Alpha" is a very stiff naming scheme. Many softwares won't fit into this scheme (were they e.g. have nightlies or GIT repositories as preview version but no dedicated "betas" or "alphas". Also softwares are often considered stable, although the version is officialy called "beta")

I'd propose to use the "often updated" parameter in cases were really more than a stable and a preview version are relevant (should be the very small minority of articles). You can add multiple {{LPR}} templates then which are all shown in the infobox. --Patrick87 (talk) 19:22, 24 August 2013 (UTC)

Not done: Sorry, but there doesn't seem to be a consensus to make this change now. Technical 13, perhaps you could bring this up at WT:SOFTWARE? — Mr. Stradivarius ^{♪ talk ♪} 00:52, 25 August 2013 (UTC)

• I've modified the sandbox version as is reflected by the test cases to the following code so that the template is fully backwards compatible and nothing will change unless specifically entered otherwise. The new code is:

Code section

<!-- Two open curly brackets -->Infobox
| bodyclass  = vevent
| bodystyle  = {{{bodystyle|}}}
| title      = {{{title|{{{name|<includeonly>{{PAGENAME}}</includeonly>}}}}}}
| titleclass = summary
| labelstyle = white-space: nowrap;
| image      = {{#invoke:InfoboxImage|InfoboxImage|image={{{logo|}}}|size={{{logo_size|}}}|sizedefault=64px|alt={{{logo_alt|}}}}}
| caption    = {{{logo caption|}}}
| image2     = {{#if:{{{collapsible|}}}|{{hidden begin|title=Screenshot|titlestyle=text-align:center}}}}{{#invoke:InfoboxImage|InfoboxImage|image={{{screenshot|}}}|size={{{screenshot_size|}}}|sizedefault=300px|alt={{{screenshot_alt|}}}}}
| caption2   = {{{caption|}}}{{#if:{{{collapsible|}}}|{{hidden end}}}}
| label1     = [[Software design|Original author(s)]]
| data1      = {{{author|}}}
| label2     = [[Software developer|Developer(s)]]
| data2      = {{{developer|}}}
| label3     = Initial release
| data3      = {{{released|}}}
| label4     = [[Software release life cycle|{{#if:{{{discontinued|}}}|Discontinued|Stable release}}]]
| data4      = {{#if:{{{latest release version|{{{latest_release_version|}}}}}}
 |{{{latest release version|{{{latest_release_version}}}}}} {{#if:{{{latest release date|{{{latest_release_date|}}}}}}
   | / {{{latest release date|{{{latest_release_date}}}}}}
  }}
 |{{#if:{{{frequently updated|{{{frequently_updated|}}}}}}
  |{{#ifexist:Template:Latest stable software release/{{{name|{{PAGENAME}}}}}
   |{{Latest stable software release/{{{name|{{PAGENAME}}}}}}}
  }}
 }}
}}
| label5     = [[Software release life cycle|Preview release{{#if:{{{beta version|{{{beta_version|}}}}}}|{{#if:{{{alpha version|{{{alpha_version|}}}}}}|s}}}}]]
| data5      = {{#if:{{{latest preview version|{{{latest_preview_version|{{{beta version|{{{beta_version|}}}}}}}}}}}}
 |{{{latest preview version|{{{latest_preview_version|{{{beta version|{{{beta_version|}}}}}}}}}}}} {{#if:{{{latest preview date|{{{latest_preview_date|{{{beta date|{{{beta_date|}}}}}}}}}}}}
   | / {{{latest preview date|{{{latest_preview_date|{{{beta date|{{{beta_date}}}}}}}}}}}}
  }}
 |{{#if:{{{frequently updated|{{{frequently_updated|}}}}}}
  |{{#ifexist:Template:Latest preview software release/{{{name|{{PAGENAME}}}}}
   |{{Latest preview software release/{{{name|{{PAGENAME}}}}}}}
  }}
 }}
}}
| label6     = {{#if:{{{latest preview version|{{{latest_preview_version|{{{beta version|{{{beta_version|}}}}}}}}}}}}|&nbsp;|[[Software release life cycle|Preview release{{#if:{{{beta version|{{{beta_version|}}}}}}|{{#if:{{{alpha version|{{{alpha_version|}}}}}}|s}}}}]]}}
| data6      = {{#if:{{{alpha version|{{{alpha_version|}}}}}}
 |{{{alpha version|{{{alpha_version}}}}}} {{#if:{{{alpha date|{{{alpha_date|}}}}}}
   | / {{{alpha date|{{{alpha_date}}}}}}
  }}
 |{{#if:{{{frequently updated|{{{frequently_updated|}}}}}}
  |{{#ifexist:Template:Latest preview software release/{{{name|{{PAGENAME}}}}}
   |{{Latest preview software release/{{{name|{{PAGENAME}}}}}}}
  }}
 }}
}}
| label7     = Development status
| data7      = {{{status|}}}
| label8     = Written in
| data8      = {{{programming language|{{{programming_language|}}}}}}
| label9     = [[Operating system]]
| data9      = {{{operating system|{{{operating_system|}}}}}}
| label10     = [[Computing platform|Platform]]
| data10      = {{{platform|}}}
| label11    = [[File size|Size]]
| data11     = {{{size|}}}
| label12    = Available in
| data12     = {{#if:{{{language count|}}}|{{{language count}}} languages|{{{language|}}}}}{{{language footnote|}}}
| data13     = {{#if:{{{language count|}}}|{{#if:{{{language|}}}|{{hidden top|title=List of languages|titlestyle=background-color: transparent;}}{{{language|}}}{{hidden bottom}}}}}}
| label14    = [[List of software categories|Type]]
| data14     = {{{genre|}}}
| label15    = [[Software license|License]]
| data15     = {{{license|}}}
| label16    = [[Software license|Licence]]
| data16     = {{{licence|}}}
| label17    = [[Alexa Internet|Alexa]] rank
| data17     = {{#if:{{{alexa|}}}|{{nowrap|{{{alexa|}}}}}}}
| label18    = Website
| data18     = {{{website|}}}
| label19    = [[Technical standard|Standard]](s)
| data19     = {{{standard|}}}
| label20    = As of
| data20     = {{{AsOf|}}}
}}<noinclude>
{{documentation}}
</noinclude>

• This doesn't affect any of the existing uses of the template where the reader may not want to see the progress of the product or where the development is too fast to keep it updated properly.
• "should be enough for 99%" ummm...
• "The 1% ... not Wikipedia infoboxes" again...
• Umm... so update them? I'm sure there are plenty of BOLD readers and people viewing them that they will be reasonably updated... If you come across one that isn't, feel free to update it. ;)
• New code has removed most of that terminology from the infobox display (still the name of the variables, because it is what it is...)

I hope that this resolves all of Patrick87's concerns. Technical 13 (talk) 17:03, 25 August 2013 (UTC)

• Oppose. Hi. I am afraid I have to disagree with this nomination. Wikipedia practice is to list the latest build only. When a stable release comes, we throw away the information about the older preview version. (I do not want to discuss the logic of this practice here; suffice to say I agree with it.) So, the "latest preview version" should suffice to list the alpha version and it is still viable to discard this info when a new alpha, beta or RC comes out.

That said, alpha is sneaky thing. To know about an internal test, which is private by definition, a source must compromise this info. Such sources are not accepted in Wikipedia because they are either NDA violators or rumor-mongers. I have never a seen a company to announce something like: "We are working on Some-Superb-Piece-Of-App build #234328497, compiled 31 February 3212." In case of open-source software, alpha is just a misnomer for "first beta" and we can still treat it as alpha or beta as I explained. Given all these, we are now equipped with the facility to treat alpha builds equally as just a build. But proposing to give this dodgy bit of information is, I am afraid, not justifiable. Best regards,
Codename Lisa (talk) 18:23, 25 August 2013 (UTC)

• As a developer on the Yet another AFC reviewer script (which is why I used it in the Test cases page exclusively), I can say that are softwares that are willing to offer these versions to anyone wanting to use them. I suppose I could make a second template Template:Infobox opensource software and put my template in there... *sigh* Seems like a lot of extra work and space for something that could be accomplished with a little modification to the existing template. Like I stated above, this change does not force any of the currently existing pages to change in any way, and new pages can use the old style, if that is what they prefer. That shouldn't exclude those that want to have more than one prerelease version noted from doing so. Technical 13 (talk) 18:58, 25 August 2013 (UTC)

• Hi. I appears you either did not read my message entirely or deliberately chose to ignore portions. I explicitly said: 'In case of open-source software, alpha is just a misnomer for "first beta" and we can still treat it as alpha or beta as I explained.' My primary argument was that current config facilitates alpha already, under "preview" umbrella term.

Now, I advise you to obtain consensus for the change you intend to make because if you make a template to circumvent consensus, one might nominate it for deletion, and with consensus against it, it will be deleted. Best regards, Codename Lisa (talk) 20:30, 25 August 2013 (UTC)

• Codename Lisa, I did read that part of your message, and didn't ignore it at all. I disagree that alpha is just a misnomer for "first beta". If you actually look at test cases (and click the edit button), you'll see that it is still the "preview" umbrella term being displayed in the infobox... The terms "alpha" and "beta" are inputed on the page and are not in the template code... Only the variable names used include those words, and the developer/editor adding the information would presumably (should) know what the terms mean.

Yet another AfC helper script Original author(s) Timotheus Canens Developer(s) on github Stable release master (changelog) / 18 August 2013 (2013-08-18) Preview release beta / frequently updated Written in JavaScript Platform MediaWiki Available in English

{{Infobox_software/Sandbox | name = AFCH | bodystyle = float: none; clear: both; margin-left: auto; margin-right: auto; | title = Yet another AfC helper script | logo = [[File:AFC-Logo.svg]] | screenshot = <!-- [[File: ]] --> | caption = | collapsible = | author = [[User:Timotheus Canens|Timotheus Canens]] | developer = [https://github.com/WPAFC?tab=members on github] | latest release version = <span class="plainlinks">[https://github.com/WPAFC/afch/tree/master master]</span> ([[Wikipedia:WikiProject_Articles_for_creation/Helper_script/Changelog|changelog]]) | latest release date = {{Start date and age|2013|08|18|df=yes}} | beta version = <span class="plainlinks">[https://github.com/WPAFC/afch/tree/beta beta]</span> | beta date = updated weekly | alpha version = <span class="plainlinks">[https://github.com/WPAFC/afch/tree/develop "first" beta]</span> | alpha date = updated daily | programming language = [[JavaScript]] | platform = [[MediaWiki]] | language = English | status = Active development }}

Yet another AfC helper script Original author(s) Timotheus Canens Developer(s) on github Stable release master (changelog) / 18 August 2013 (2013-08-18) Preview release beta / updated weekly "first" beta / updated daily Written in JavaScript Platform MediaWiki Available in English

Codename Lisa, can you tell me which of ⇑ is the sandbox version without looking at the source? (There is a hint). Now look at the source, and tell me which one has easier to read source... That is why I want to add the extra parameters. Thanks! Technical 13 (talk) 12:52, 26 August 2013 (UTC)

Hi. All three of these infoboxes are against current consensus and if you take the article containing them to WP:FAC, it is rejected immediately. That's why I am keeping my oppose for now. But as for the reason, date field shows non-date values like "updated weekly", "updated daily" and "frequently updated", whereas it should only contain a date. (Mind you, the infobox emits microformats too a and this is not good.) They are not dates, they are adverbs of habit. In general, I oppose your proposal and your assumptions as to how infobox should be used, in favor of existing consensus. Wikipedia is an encyclopedia, not a developer's wiki. Best regards, Codename Lisa (talk) 18:25, 26 August 2013 (UTC)

Codename Lisa, what you're saying is that Template:Infobox software should be deleted because it is against current consensus. Two out of three of the above examples are using the currently live version of the template. If you wish to support your claim I expect to see this infobox deleted in a TfD within a couple weeks, otherwise your claim is unsupportable. Technical 13 (talk) 19:51, 26 August 2013 (UTC)

I never said such a thing. Try reading the messages more carefully. I am not going to repeat myself. Best regards, Codename Lisa (talk) 20:48, 26 August 2013 (UTC)

Umm, the box above is not on an article, and assuming that the template is only for article use is another flaw in your logic. Wikipedia:WikiProject Articles for creation/Helper script is a Wikipedia project in project space where it belongs and your implying the template is only for use on articles ludicrous... Thanks. Technical 13 (talk) 23:37, 26 August 2013 (UTC)

Seriously, sir, if you think personal attack is the way of obtaining my consent (any consent), I am afraid I must disappoint you. Meanwhile the logic which you describe as flawed is not my logic; like I said, you must consider being more careful while reading. Apart from that, I see no reason to consent with a change that affects millions of articles just to indulge you and that single consensus-violating page. Best regards, Codename Lisa (talk) 08:16, 27 August 2013 (UTC)

• Codename Lisa, I have made (or intended) no personal attacks here, and apologize if you felt that I had. You still haven't shown any evidence to support your claim of any violation of consensus. You've taken to exaggerating ("millions of articles" for a template that is transcluded on 11,002 total pages.) to make a point based on flawed logic that wikiproject use of this template is a violation of consensus and that somehow my request changes any of those pages (it would have made zero change to existing pages, but allowed for more detail where appropriate). Anyways, I've gone ahead and created a wikiproject specific version of this template, so this request is closed. Technical 13 (talk) 13:31, 27 August 2013 (UTC)

Edit request on 2 October 2013: "frequently updated"

Hi.

Template:Infobox web browser has implemented a mechanism that eliminates the need for |frequently updated=. Let's implement it here and eliminate this parameter. At least, people no longer indiscriminately set it to "yes" in new articles only because they think the subject of their articles are frequently updated. Codename Lisa (talk) 12:17, 2 October 2013 (UTC)

Could you put the required code in Template:Infobox software/sandbox and then reactivate the request? Thanks — Martin (MSGJ · talk) 12:55, 2 October 2013 (UTC)

Done, Codename Lisa (talk) 14:19, 2 October 2013 (UTC)

Test cases updated too. Best regards, Codename Lisa (talk) 14:25, 2 October 2013 (UTC)

• I oppose this change as the test cases seem to make it appear that using this method will not allow for a nice, tight, compact, little infobox. Also, I see no evidence of backwards compatibility for those that like the current system. Technical 13 (talk) 14:53, 2 October 2013 (UTC)

• Hi. The case shows quite the opposite. It is totally backward-compatible because it renders external data regardless of the presence of |frequently updated=. That is exact why no one opposed this change in {{Infobox web browser}}. As for "a nice, tight, compact, little infobox", this change makes the infobox neither less nor more "nice, tight, compact, little". In fact, what are you talking about? Best regards, Codename Lisa (talk) 15:25, 2 October 2013 (UTC)

• Testcases as I see them... Sandbox version in both is bulky and unwieldy. Technical 13 (talk) 16:35, 2 October 2013 (UTC)

• It is exactly as I see it, as it is supposed to be and as it is meant to be, with or without this edit request being granted. Even if this request is denied, the infobox of Avidemux article still looks like the right one.

In other words, you have registered your opposition in the wrong discussion. If you wish to propose a change in infobox trends, the right place is Wikipedia:Village pump.

Best regards,

Codename Lisa (talk) 03:02, 3 October 2013 (UTC)

I interpret Technical13's opposition to mean that it is harder not to use the release data for the article if that decision is made locally. Before you could just remove the |frequently_updated= parameter from the infobox and the extra stuff will disappear (to make the "nice", "compact" infobox). With the proposed system you might have to get the appropriate subtemplate of Template:Latest stable software release deleted in order to remove this information. I propose a compromise solution: not only will the template check if that page exists, but it will also make sure it is not blank. This would allow an ordinary editor to blank the template and remove the information without the need for administrator intervention. Thoughts? — Martin (MSGJ · talk) 09:47, 3 October 2013 (UTC)

Hi. This is the second time you made my jaw drop today.

Before I ask "why would anyone want the stuff to disappear?" I might say it may be achieved by disassociating the {{PAGENAME}} from {{{name}}} parameter. e.g. {{#ifexist:Template:Latest preview software release/{{{name|{{PAGENAME}}}}} becomes {{#ifexist:Template:Latest preview software release/{{{name}}}. As a result, deleting |name= parameter or renaming it to |title= removes version info without impacting anything else.

But again, why would anyone want the versioning data to disappear? Would commenting them out or emptying external template not suffice? And since this is not implemented in {{Infobox web browser}}, it tallies that those article never needed to peremptorily hide the versioning data.

Best regards,

Codename Lisa (talk) 10:23, 3 October 2013 (UTC)

All this jaw-dropping; you need to work on your jaw muscles :) Your suggestion would work as well, but I think my proposal works better. I'll wait for for more input from others, before responding further. — Martin (MSGJ · talk) 10:53, 3 October 2013 (UTC)

• I can see a few reasons for not wanting to display it. First, there could be a need to remove such information in cases where there is a dispute as to accuracy of the data. Second, not all of the data may be available, so it would be better to omit those sections. Third, the version may change so rapidly, that it may be unfeasible to keep such information up to date for a period of time and better to just suppress it. Technical 13 (talk) 12:46, 3 October 2013 (UTC)

I also think we're searching for a solution without problem and I'm more or less of Codename Lisa's opinion. First of all I can't think of a case where one actually wants to hide version information supplied via the templates if available (do you have any cases where the "frequently_updated" parameter is used in this way Technical 13?).
Secondly most other problems that might arise are already taken care of or can be easily solved without increasing the complexity of the template with further parameters:

• If one really doesn't need a template any longer just delete it, it's not so hard after all.
• Emptying out those pages to "hide" them is a bad idea and unnecessary in my opinion since one doesn't know that they exist (therefore they are dead afterwards and can just as well be deleted).
• If one temporarily wants to remove some info (e.g. the because of a released preview version) the templates {{LSR}} and {{LPR}} take care of this: Just remove the version number and they will only show the small [+/-] sign so one the template is still available for easy editing.

--Patrick87 (talk) 15:16, 3 October 2013 (UTC)

Hello guys.

Patrick87 mentioned fine points. I have another to add: What kind of content dispute warrants removal of all four elements of release version, release date, preview version and preview date indiscriminately at the very same time? The likelihood of this drops further when the version field mentions multiple versions; e.g. for different OSes or architectures. In terms of personal experience, I am yet to see such a dispute.

@MSGJ: I'm not sure if that's possible. Could you please elaborate? More specifically, please define empty and empty enough in this context and explain how we should deal with each.

Best regards,

Codename Lisa (talk) 16:01, 3 October 2013 (UTC)

Based on the additonal support from Patrick87 I have implemented this change and we can see how things work. Lisa: I don't understand why you are asking me to define "empty" because I don't even think I used that word in this page? — Martin (MSGJ · talk) 19:47, 3 October 2013 (UTC)

Hi. Since the main discussion is ended, I can't decide whether I should post a reply here. I am putting the reply in your talk page but please feel free to bring it back here, replacing this message completely. Best regards, Codename Lisa (talk) 08:20, 4 October 2013 (UTC)

• As I seem to remember it, the original idea behind |frequently updated= [2] was to allow the [+/-] edit links to display even if the associated LSR/LPR template did not exist so that the preload logic action=edit&preload=Template:LSR/syntax could allow the blank {{LSR/syntax}} file to be preloaded into Template:Latest stable version/Foo. It never was quite finished though, and from the looks of it, someone has removed the preload code from several of these infobox templates. I implemented other logic in {{LSR}}/{{LPR}} so that their output would be blank if there was no version was defined, since that had caused other infobox display problems in the past. --Tothwolf (talk) 11:59, 18 December 2013 (UTC)

• Hi. It is good to know a bit of history, although the old idea cannot be redeemed. The way Wikipedia is going, we are soon going to put versioning data on WikiData. Best regards, Codename Lisa (talk) 13:56, 18 December 2013 (UTC)
  • The only reason I (and presumably the editor who initially came up with the idea) never "flipped the switch", so to speak on the functionality is that I wasn't happy with how it would add the [+/-] edit link to all software infoboxes, even those where we didn't want the edit links. The |frequently updated= parameter was a compromise since that allowed it to be turned off completely, however in hindsight I think the correct way to handle this would have instead been to have a different parameter that could be used to disable the preload code (enabled by default) instead. As far as WikiData goes, if we are still going to have edit links, I don't see why we couldn't still use preload so editors would have a nice well formed blank template or whatever to start with. --Tothwolf (talk) 20:31, 18 December 2013 (UTC)

Edit request: Autocategorisation

Please add the feature that I've just added to the sandbox, which autocategorises software into Category:XXXX software when the released parameter mentions the year XXXX (e.g. software released in 2007 would be automatically added to Category:2007 software). This should be a suitable default; in the minority of cases where the article should instead go in a subcategory, the new parameter |nocat=y can be added to disable autocategorisation. --greenrd (talk) 14:11, 19 October 2013 (UTC)

• Why is this an identifying feature that needs to be categorized? I'm unsure I follow the rationale for this. Technical 13 (talk) 14:16, 19 October 2013 (UTC)
  • Many pieces of software are already categorised by their release date on Wikipedia. These are not new categories! We could instead delete all those categories, and create an article Timeline of software for people (such as myself) who are interested in the history of software, but categorisation is less work (it does not require spending any time on any "what to include" decisions), and autocategorisation makes it even easier. These categories (although not new) are not without precedent on Wikipedia: we already categorise notable people by birth year (if known), businesses by year of establishment, and other products by year of introduction, for example. --greenrd (talk) 14:33, 19 October 2013 (UTC)
    • I'm not following this either. How can we delete the categories if this will add them to every software page, and how will the timeline of software page work? Jackmcbarn (talk) 15:54, 19 October 2013 (UTC)
      • Sorry, I wasn't clear. I was presenting creating an article Timeline of software as an alternative to the existing categories, if anyone wants to go down the route of proposing to delete all the existing yearly categories. (I hope no-one wants to go down that road. I don't think it's a sensible option at all, and note that they've existed on Wikipedia for 7 years.)--greenrd (talk) 16:18, 19 October 2013 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template.. Also, cats like Category:2007 software are content categories, so please see WP:TEMPLATECAT regarding the use of templates to categorise into content categories. --Redrose64 (talk) 19:18, 19 October 2013 (UTC)

Missing parameter tests

This template is generating links to {{Latest_preview_software_release/}} and {{Latest_stable_software_release/}}, most likely due to a missing test somewhere for the {{{name}}} parameter not being set. - TB (talk) 17:07, 27 December 2013 (UTC)

• @MSGJ and Codename Lisa: I'm assuming this is because of your doing above in the October 2nd request. Please revert those changes and/or fix. Thank you. Technical 13 (talk) 17:15, 27 December 2013 (UTC)

Hello. You are assuming wrong. Thus, request denied.

This problem very old; it is direct result of users not reading the documentation pages carefully. However, if any of you two are willing to explain the problem and perhaps establish that it is not because of what I said, I am listening.

Best regards,

Codename Lisa (talk) 17:26, 27 December 2013 (UTC)

Apologies in advance if I'm answering the wrong question. It's always good practice to treat values passed to your code with skepticism. Here, a parameter is being used to build up a reference to an external object; if a wider than intended range of inputs is accepted, a wider range of external objects than intended can be referenced. This introduces potential for abuse. I for one shall resist creating the page Template:Latest_preview_software_release/ with the content "Jimbo's got smelly feet". - TB (talk) 21:03, 27 December 2013 (UTC)

Hi. Reverting a template change on a mere assumption is wrong, be it my code or anybody else's. Reverting and editing must occur only when I have a shred of idea as to what I am doing.

Now I must once again ask you to include steps of reproducing your case or give me a diff to one instance.

Our only port of call to those templates is the following code:

| label4     = [[Software release life cycle|{{#if:{{{discontinued|}}}|Discontinued|Stable release}}]]
| data4      = {{#if:{{{latest release version|{{{latest_release_version|}}}}}}
                  | {{{latest release version|{{{latest_release_version|}}}}}}
                    {{#if:{{{latest release date|{{{latest_release_date|}}}}}}
                       |/ {{{latest release date|{{{latest_release_date|}}}}}}
                    }}
                  | {{#ifexist:Template:Latest stable software release/{{{name|{{PAGENAME}}}}}
                       |{{Latest stable software release/{{{name|{{PAGENAME}}}}}}}
                    }}
               }}
| label5     = [[Software release life cycle|Preview release]]
| data5      = {{#if:{{{latest preview version|{{{latest_preview_version|}}}}}}
                  | {{{latest preview version|{{{latest_preview_version|}}}}}} 
                    {{#if:{{{latest preview date|{{{latest_preview_date|}}}}}}
                       |/ {{{latest preview date|{{{latest_preview_date|}}}}}}
                    }}
                  | {{#ifexist:Template:Latest preview software release/{{{name|{{PAGENAME}}}}}
                       |{{Latest preview software release/{{{name|{{PAGENAME}}}}}}}
                    }}
               }}

Thus, if I create a page and call it GIMP and put "{{infobox software}}" with no other parameters on it, I get {{Latest stable software release/GIMP}} and {{Latest preview software release/GIMP}} transcluded.

Best regards,

Codename Lisa (talk) 21:27, 27 December 2013 (UTC)

• Not if you have all empty parameters, namely |name= which would tell the template the name of the page is " " (empty space) which would prevent it from defaulting to {{PAGENAME}}. A more elegant solution to resolve the issue here is:

| label4     = [[Software release life cycle|{{#if:{{{discontinued|}}}|Discontinued|Stable release}}]]
| data4      = {{#if:{{{latest release version|{{{latest_release_version|}}}}}}
                  | {{{latest release version|{{{latest_release_version|}}}}}}
                    {{#if:{{{latest release date|{{{latest_release_date|}}}}}}
                       |/ {{{latest release date|{{{latest_release_date|}}}}}}
                    }}
                  | {{#ifexist:Template:Latest stable software release/{{#if:{{{name}}}|{{{name}}}|{{PAGENAME}}}}
                       |{{Latest stable software release/{{#if:{{{name}}}|{{{name}}}|{{PAGENAME}}}}}}
                    }}
               }}
| label5     = [[Software release life cycle|Preview release]]
| data5      = {{#if:{{{latest preview version|{{{latest_preview_version|}}}}}}
                  | {{{latest preview version|{{{latest_preview_version|}}}}}} 
                    {{#if:{{{latest preview date|{{{latest_preview_date|}}}}}}
                       |/ {{{latest preview date|{{{latest_preview_date|}}}}}}
                    }}
                  | {{#ifexist:Template:Latest preview software release/{{#if:{{{name}}}|{{{name}}}|{{PAGENAME}}}}
                       |{{Latest preview software release/{{#if:{{{name}}}|{{{name}}}|{{PAGENAME}}}}}}
                    }}
               }}

which would prevent the base template pagenames from rendering without the proper sub-pagename. Technical 13 (talk) 21:51, 27 December 2013 (UTC)

Hello, Technical 13. I can implement this (resolving the error in your code in process) but isn't it a solution in search of a problem? When |name= contains a white space, transclusion code would look for {{Latest stable software release/_ }} or {{Latest stable software release/ }} and would only transclude them if they exist. The problem is that a user must create one with "Lisa's got smelly feet". He or she can just as easily create any other page with any other arbitrary name. (It is no harder and no easier.) Best regards, Codename Lisa (talk) 22:38, 27 December 2013 (UTC)

Thanks Lisa, I could have implemented myself, but wanted to confirm that was really the issue that TB was having. The extra pipe you added wasn't necessary (and I've removed it) because if the parser gets to that point, {{{name}}} has already been proven to exist. Technical 13 (talk) 23:23, 27 December 2013 (UTC)

Well, thank you too. I still want to know if it is the issue to which TB was referring, because if it is the issue, he is the person with the power to solve it: As an admin, he can salt that page, can't he? Best regards, Codename Lisa (talk) 23:35, 27 December 2013 (UTC)

Happy to salt the offending titles if their creation would indeed cause issues, although I'm not sure I understand the utility in transcluding an entity that is required to be empty. Then, markup is weird - it wouldn't be the first time an apparently illogical construct has been used to good effect. - TB (talk) 12:08, 28 December 2013 (UTC)

Because this is Wikipedia. It is built with assuming good faith instead of security as a principle. Software security requires assuming evil faith. Assuming that a malicious user intends to abuse your construct. Best regards, Codename Lisa (talk) 16:46, 28 December 2013 (UTC)

• TB, is the template still creating those links or did the collaborated edits by Lisa and myself fix that? Would be helpful if you could offer links to the pages were the improper links are/were generated. Thanks Technical 13 (talk) 17:00, 28 December 2013 (UTC)

Of course. Pages that link to "Template:Latest preview software release/" and Pages that link to "Template:Latest stable software release/" will show the necessary. Links remain, but I've carried out null edits on a few items and they've vanished in each case. Once the rebuild queue catches up, I believe there'll be no more odd links. Good job guys. - TB (talk) 17:27, 28 December 2013 (UTC)

Ouch! Why didn't you say this in the first place? We should have investigated this before the change. (And to think that I dropped you a talk page message asking for clarification.) You see, these two pages do not exist. #ifexist: must have never returned true. Even if it did, the result would have not been a link; it would have been a transclusion. (The word "transclusion" would appear in the report in front of the article name.) Please, please, please, TB; do not withhold such critical pieces of info again.

I will keep monitoring those two reports. Best regards, Codename Lisa (talk) 00:06, 29 December 2013 (UTC)

• Since it is less than 200 pages there, I'm just going to fire up AWB and null edit them all. This should clear this issue up. If it was more than a few hundred, I would of course allow the job queue to do its job... Technical 13 (talk) 00:27, 29 December 2013 (UTC)

• Update: That cleared out most of what links to those pages, the rest of them are actual links (like this section on this page) or are seemingly abandoned userspace drafts (that should be tagged as drafts with the AfC draft template, which I'll do once the afch script is fixed) so they can be cleaned out in six months (most of them have been untouched for 2-5 years and many read somewhat promotional). Technical 13 (talk) 01:09, 29 December 2013 (UTC)

• Or, I can force a title regardless. ;) At least this should let editors know where those data come from.

On the whole, I preferred version information where subpages. We could have checked for {{./Latest release data}} and {{./latest preview data}}. No more unclean code.

And there is one thing that I must do: I must hang a note on my user page that reads "Assume good faith; assume double good faith in Technical 13". Every time we've met, you came out a little forceful but I can't never blame you. Best regards, Codename Lisa (talk) 10:23, 29 December 2013 (UTC)

• Well thank you Lisa, and I'll be there first one to admit that my communication skills in dealing with other is horrible (I'll blame it on a bad childhood). I hope we can have many more productive discussions in the future. :) Technical 13 (talk) 14:16, 29 December 2013 (UTC)

Add source code parameter

I tried to add a parameter for "source code", but I don't think I did it correctly. If somebody could help me, it would be greatly appreciated. --WikiTryHardDieHard (talk) 03:38, 3 January 2014 (UTC)

• I don't see any edits by you to the sandbox and the template itself is WP:PINKLOCK protected. Can you show me the diffs of where you tried to make the edits or better explain what you were trying to do? Thanks. Technical 13 (talk) 05:30, 3 January 2014 (UTC)

• I think he's talking about his own sandbox at User:WikiTryHardDieHard/sandbox. He has added a |source code to the {{infobox software}}, which is not a supported parameter. It is natural that it doesn't work. The edit itself horrifies me. Having a |source code parameter turns Wikipedia into a battlefield of a war between open-source software proponent and everyone else. Fortunately, WP:EL forbids such links. Fleet Command (talk) 15:39, 3 January 2014 (UTC)

We already had that discussion above and mostly consented that such a parameter was a bad idea. --Patrick87 (talk) 17:34, 3 January 2014 (UTC)

Label Changes

I think the latest label changes by Codename Lisa weren't a good idea and should be partially reverted:

• "Latest release" is misleading since a preview release is also a release (and therefore probably the latest)
• "Latest preview" keeps it to the reader to figure out a preview release is meant (in contrast to a product preview on a convention or something like that). It also destroys the analogy between stable/preview release (both are releases! they only differ in that one is stable and the other a preview).
• Natural language is a very useless Wikilink. If somebody didn't know what "Available in" meant he certainly doesn't know after reading that article. If it is necessary to Wikilink this entry at all link to something appropriate like Language localisation or Internationalization and localization.

Regards, --Patrick87 (talk) 20:09, 30 March 2014 (UTC)

Hi, Patrick87.

I will address the first two bullet points in one. Hope that's okay.

1. No, it isn't. We do not have such a thing as "preview release". There are two methodologies: In one, it is either a release version or a preview version, which can be technical preview, community preview or release candidate. "Release" in this methodology implies that "development phase has relinquished control (released it.)" In another, it is either a "stable release", "unstable/experimental release" or "nightly build". It implies that the development process is open and there is no wait for seeing what is what involved. (Hence, there are no sneak peaks or previews; the entire hoopla is yours.) "Preview release" is a vague colloquialism. Parameters names already and properly adhere to the first methodology. Why must the official text not adhere to it?
2. Since we had an RFC-based debate about "available in", I cannot touch this label text. But "available in" could also mean geographical location, as in "Available in United States, Germany, UAE, Russia and Japan." I resolved this ambiguity with a wikilink. Still, I am totally open to negotiation on this one. If you want it reverted now and unconditionally, say the word. (You have BRD right.)

Best regards,

Codename Lisa (talk) 20:36, 30 March 2014 (UTC)

I think you misunderstood my intentions:

1. If you're pedantic about what makes a "release" then at least be consistent with wording (whatever wording you prefer). E.g. say "Release version" and "Preview Version". The way it is now is inconsistent (even if it might be exact within your definition of the terms) and it will cause confusion for some readers. In the end being slightly less precise if it increases comprehensibility for the layan is the way to go (that's also the reasoning for "available in" if I'm not mistaken).
2. Regarding "available in" I did not request to change the label but the link target (please reread my statement!). And no, I don't really have the "BRD right" since I didn't acquire this stupid and bureaucratic template editor right yet.

--Patrick87 (talk) 21:29, 30 March 2014 (UTC)

Hi.

1. It is a combination of latest release version and latest release date in one field. |discontinued= makes them "final release" and "final preview". I wanted to make them "latest release info", "latest preview info", "final release info" and "final preview info" but that sounded a bit long. I'm not sure what is "pedantic" but if you have an idea, I am all ears.
2. Oh, okay. Will do. (By the way, I said "say the word"; I do the revert for you.)

Best regards,

Codename Lisa (talk) 23:25, 30 March 2014 (UTC)

"Pedantic" is that you oppose using "release" for both labels because you state a release would be a finalized version of the software and that you oppose using "version" for both entries because also the date is contained in the field. Both objections feel like nitpicking for me while (regardless of any minor imprecisions) both options would make up for a much better label than "Latest preview". I hate it to be exact. Laymen won't understand it and I tend to say that most experts will find it "inventive" to put it kindly.
As I wrote before I still prefer the labels which were used before your change: "Stable release" and "Preview release". If you dislike release so much in this context I'd agree with "Stable version" and "Preview version". If you really want to incorporate "Final" then append it to these suggestions. It will make the label longer than necessary but it's still much clearer than what we got now. --Patrick87 (talk) 00:35, 31 March 2014 (UTC)

As a compromise I could offer "Latest release" and "Latest pre-release". Then one can also use "Final release" and "Final pre-release". --Patrick87 (talk) 00:41, 31 March 2014 (UTC)

Hello again, Patrick

Rule #1 of being a template editor is: A template editor must not abuse his power to gain an upper hand in an edit dispute. Hence, if it was a matter of my personal preference, I must have reverted it immediately in your favor. However, I made this change as a matter of user feedback from the article namespace or talkpages of the users to whom I talked. So, I am not at liberty to make such compromises as reinstating a typo based on "I hate it" reasoning or the incorrect state of laymen's mind (if what you say is indeed true). The best I can do is to link to an appropriate section of software release life cycle, so that users can read it and learn.

If you indeed have a genuine concern beyond "I hate it" and "laymen think so", you can apply appropriate changes to software release life cycle article, supported by reliable sources, so that we can link there. Then, file a change request here.

On a sidenote, if the confusion and inventiveness claim is indeed real, why it didn't come up when the parameters were actually named |latest release version=, |latest release date=, |latest preview version= and |latest preview date=?

Best regards,

Codename Lisa (talk) 02:25, 31 March 2014 (UTC)

P.S. Some people use the word "release" to metaphorically mean "version". But these two words are not always interchangeable. The problem with your suggestion, "Stable version" and "preview version" is that they come from different methodologies. That you might not feel it because some other people also use "preview" to metaphorically mean "unstable" or "experimental". (Corporate marketing loves it because it hides the notion of flaw by replacing it with the notion of privileged early access.) But again, if you are so worried about confusion of readers, how comes you endorse double metaphors and cross-methodology labeling? Best regards, Codename Lisa (talk) 02:41, 31 March 2014 (UTC)

Sorry, but were at the point were you twist my every word. "I hate it" for the multitude of valid reasons I gave above + it sounds crappy + nobody regardless of being layman or expert understands it. Your only concern are some silly "methodologies" probably nobody but you understands (or at least nobody thinks are practical) plus some "user feedback from the article namespace or talkpages of the users to whom I talked" to protect your edit (of which you did not link a single discussion which makes me feel like those weren't the clearest decisions either).
In fact if one looks at your status quo (the article software release life cycle) the only reasonable consequence is to drop "preview" altogether and start over with "development release" or "development version" since it explicitly states that "some developers refer to this [the beta] stage as a preview". Nothing more! "Preview" in the light of the article seems therefore highly inappropriate to start with (if you really want to play the "sources" game). --Patrick87 (talk) 09:10, 31 March 2014 (UTC)

Hi. I am afraid this discussion is approaching the borders of contentious labeling and assuming bad faith. So far, you had implied that I am adhering to some semblances of reason and method but I am not seeing your arguments adhering to any. (And I can't see how your quotation from the article serves against the word "preview".) So, if calling my methodologies "silly" is the best argument you have to offer, I am afraid our discussion ends here. I will invoke a WP:3O in preparation for a WP:RFC, but if you want a change, you must at least give me some semblances of rationale.

Best regards,

Codename Lisa (talk) 17:51, 31 March 2014 (UTC)

P.S. I just notified 3O and an admin. Hopefully, this works best for all of us. Best regards, Codename Lisa (talk) 18:23, 31 March 2014 (UTC)

Actually I was hoping for a third opinion (I thought more people were actively watching this page). Let's see if the formal process sheds any insight on this.
The fact that you act as if I provided no valid arguments reducing everything I have written to some citations taken out of context trying to turn these against me without actually replying to my valid concerns makes me sad. This is no ground for a constructive discussion. At least I tried to go into you point of view (even if I don't think it makes much sense here). --Patrick87 (talk) 22:08, 31 March 2014 (UTC)

• I actually have been watching right along, and some of your conversation is a little on the TL;DR side. However, my thoughts on the matter are:

1. Stable release v. Latest release → "Stable" is a more technical term only programmers would expect to see and "Latest" is more laymen/generic.
2. Preview release v. Latest preview → I think "Latest preview release" would be the most generic, but is too long so "Latest preview" works the best as it is more in sync with "Latest release" above it.
3. Written in v. Written in → It hurts nothing to have the link, so there is no real reason to not have the link. There seems to be no dispute about this particular link.
4. Available in v. Available in → I agree that particular link adds little to the understanding of the term, Lisa, you mention there was an RfC-style debate about it, but I can't seem to find the link to this. I would like to read it before I say it should stay or go. Thanks.

— {{U|Technical 13}} ^{(t • e • c)} 22:31, 31 March 2014 (UTC)

Regarding 1./2. you actually say you favored the full label "Latest preview release". The whole reason for this whole discussion is that Condename Lisa refuses to use the term "release" for a preview version of a software (otherwise we could have sticked with the previous labels).

Regarding 3. – this was never topic of this discussion; from my side there are no objections at all regarding this change

Ragarding 4. – this has alreay been changed in the meantime to be more meaningful.

--Patrick87 (talk) 22:55, 31 March 2014 (UTC)

To reboot this whole issue: The only objection left is the label change from "Stable release" and "Preview release" into "Latest release" and "Latest preview" which I think is inappropriate. My proposed labels (to prevent usage of the ambiguous term "release") would currently be "Stable version" and "Preview version" as they are clear and easy understandable. Codename Lisa even used similar terms in his last edit on Infobox OS version. I think it would make all parties happy to use my proposed labels or the exact same labels Codename Lisa introduced in the diff-link. --Patrick87 (talk) 22:55, 31 March 2014 (UTC)

"Stable" and "Version" are more techy words that are less understandable by laymen and those not familiar with the technical world. Your proposed labels are also more ambiguous and I think that "Latest" is a good thing to have in there so people don't try to list all versions and releases. — {{U|Technical 13}} ^{(t • e • c)} 23:13, 31 March 2014 (UTC)

Hello, Technical 13. I think it is appropriate to tell you how and where the discussion originated.

• Diff hunting is a bit hard but I do know that originated in Expression Web article, when an editor, User:LusoEditor, objected that |discontinued= and |status= are not mutually exclusive. It was then that the reason behind some wrong edits in the past became apparent: |discontinued= Changed "Stable release" to "Discontinued" making readers think the actual discontinuation occurred on the date given in |latest stable date=. So, I made this quick-remedy edit and eventually, after studying consensus through editing, decided Label 4 and Label 5 must say "Latest" on normal occasions but say "Final" when |discontinued=yes is present.
• Now, the question is: "Latest what?" and "Final what?" Data 4 would contain "version and publication date of [latest|final] incarnation of software released to manufacturing/web". Data 5 would contain "version and publication date of [latest|final] alpha, beta or release candidate incarnation of software". Naturally, I needed to make these concise. So, exit "version and publication date"; people can see that. "incarnation of software released to manufacturing/web" became "release"; I could have called it "stable" but that is an adjective an beckons a noun and leaving it to the imagination of the reader was unwise. "alpha, beta or release candidate incarnation of software" became "preview". "Test", "unstable" and "experimental" were alternatives but again, they are adjectives and imply a noun.
• My curse was that all words at my disposal had multiple meanings. A "version" is not just a version number, but also any instance or iteration of software packages, like editions, subeditions, SKU. A "release" is also an alternative name for version with all the aforesaid functions as well as a result (past participle) of the verb "release" which can mean "publish". But I saw and advantage: Software release lifecycle had a diagram and a section distinctly called "Release". Hence, the readers had a mean to understand the labels if they didn't know better.
• I told Partick about methodologies and linguistic problems of the previous labels. Well, I still think I was right. I was acutely aware of the problematic nature of the standing labels.

Best regards,

Codename Lisa (talk) 00:35, 1 April 2014 (UTC)

Are you even aiming to find a compromise here or are you unwilling to give in (even a little) trying to sit it out now, thereby also ignoring the advice by MSGJ? I had hoped that at some point you would offer some alternatives as you don't seem to like any of my suggestions (at least that's what I get from all the silence). But slowly I get the impression you're being unwilling to change anything beyond the current point... --Patrick87 (talk) 18:45, 2 April 2014 (UTC)

Hi Codename Lisa, I noticed that you again changed the labels (in attempt to make me "happy" I assume). However I'm afraid that you still do not see the point of my objections! This edit is no improvement for me!
My point is that we need to tell the user what the infobox entries in question are about and this has to be contained in their label:

• It's a "release" or a "version" of a software (pick which you like most, I have no specific preference).

Therefore the labels need to include either of those two terms! This is the fundamental content of this infobox entry. Then we need to further explain what kind of release/version we're talking about:

• Is it "stable"? Or Is it a "preview"/"pre-release" etc.? Is it the "latest"? (Pick whatever you like to describe the release/version more closely; I'm totally open for discussion here).

Therefore an appropriate label needs to contain the two elements described in the two bullet points above! By leaving out the first bullet point as you currently do, you withhold the most crucial information: What is the fundamental content of the infobox entry? This might seem clear to you, but it certainly isn't clear for the casual reader not familiar with our infoboxes. --Patrick87 (talk) 08:56, 3 April 2014 (UTC)

Latest LTS version and date

How about adding latest lts version and latest lts date parameters to this template? Many software applications have separate long-term support (LTS) versions, beside their latest release and preview versions. Thoughts? — Dsimic (talk | contribs) 03:55, 2 May 2014 (UTC)

I have started {{multiple stable software releases}}, which is currently hooked from {{infobox web browser}}. It allows listing several versions of the same software both in infobox and in comparison tables, as LSR template does. It may be used for this purpose also. — Dmitrij D. Czarkoff (talk•track) 08:39, 2 May 2014 (UTC)

Hi. Your version has potentials, so I am leaning towards that. If you just could refine it a bit. But there is a discussion right above this one. You might want to see that first. Oh, God, I will NEVER do such a thing again. Best regards, Codename Lisa (talk) 00:45, 3 May 2014 (UTC)

Wow, look at that nit-picking and bean counting above! That was a mess! However, I don't see a possibility for any objections if we add latest lts version and latest lts date parameters, as so many software projects have their LTS releases. — Dsimic (talk | contribs) 02:57, 3 May 2014 (UTC)

Regarding {{multiple stable software releases}}, beside {{LSR}} (for stable releases) and {{LPR}} (for preview releases) templates we'd also need {{LLR}} or something similar for the LTS releases, if I got it right? — Dsimic (talk | contribs) 03:03, 3 May 2014 (UTC)

I was thinking about using {{LSR}} for that. I dislike the idea of blending development life cycles with support policies. With separate field I am also concerned with duplicated content: eg. when LTS Firefox release happens, for several months LTS and stable releases match each other, while duplicated info in infoboxes is something to be avoid at all costs. — Dmitrij D. Czarkoff (talk•track) 09:53, 3 May 2014 (UTC)

Hm, to me it would be even good to have both versions of Firefox listed even while regular and ESR versions are the same, so there's no room for confusion. Anyway, that's what we currently have in Template:Latest stable software release/Firefox. — Dsimic (talk | contribs) 05:33, 13 May 2014 (UTC)

Content license

You need to add the parameter "content_license". Spotify should have "content_license = DRM", right? --David Hedlund (talk) 05:13, 2 May 2014 (UTC)

This is IMO too narrowly focused to be added into such general infobox. Also note, DRM is not a license – you should choose proper wording before insisting on this version. — Dmitrij D. Czarkoff (talk•track) 08:42, 2 May 2014 (UTC)

"content_license = proprietary" match Spotify. --David Hedlund (talk) 04:23, 3 May 2014 (UTC)

Which |content_license= matches Microsoft Word, Adobe Photoshop, Google Documents and all articles that, unlike Spotify, should use this template? — Dmitrij D. Czarkoff (talk•track) 09:32, 3 May 2014 (UTC)

Adding a copyfree section

Can we please add a copyfree yes|no section to this template? Many users prefer copy-free to other forms of software and it is easier than scanning the article for this text. — Preceding unsigned comment added by Voomoo (talk • contribs) 22:20, 2 June 2014 (UTC)

• Oppose: {{notability}} template right at the top of the copyfree article suggests that you are landing undue weight to this aspect of licensing. We already have |license=, which is just enough to cover licensing status. — Dmitrij D. Czarkoff (talk•track) 06:14, 3 June 2014 (UTC)
  • We have a 'free software' section which insufficient for people that prefer truly free software. Voomoo (talk) 18:28, 3 June 2014 (UTC)

• Hello, Voomoo. We already have. It is called |License=. Programs marked as freeware, freemium, free and open-source, GPL and GNU Public License can be used free of charge. But we cannot have the parameter you suggested because it has previously failed to achieve consensus. e.g. Some people prefer free and open-source only. Best regards, Codename Lisa (talk) 14:19, 3 June 2014 (UTC)
  • Exactly. Some people prefer truly free software and don't want restrictive licenses. At the moment there is no attribute which covers this. Programs marked GPL and GNU Public Licenses are not considered copyfree/truly free. Voomoo (talk) 18:28, 3 June 2014 (UTC)
    • Exactly! Basically you can deduce whether softtware is copyfree or not from its license, so we are back to square one. Also, judging on my own experience, users are more concerns with the actual licensing restrictions then with approval by certain organizations. Basically, if you are concerned with licensing and you see a piece of software, that is said to be copyfree, but is distributed under ILWC license, you most likely would want to see the license deed anyway. — Dmitrij D. Czarkoff (talk•track) 18:56, 3 June 2014 (UTC)
      • So lets remove the "Free Software" attribute which just means the FSF approves of the license. — Preceding unsigned comment added by Voomoo (talk • contribs) 00:24, 4 June 2014 (UTC)
        • What?! There is no |Free Software= in this template. Are you suggesting to add |copyfree= or to document ability to use |license=copyfree? — Dmitrij D. Czarkoff (talk•track) 05:46, 4 June 2014 (UTC)
          • "Free software: Software products that can be used, studied, and modified without restriction, and which can be copied and redistributed in modified or unmodified form." under license=. I am proposing to add another option, or remove the bogus one. sorry I was not clear, in my first post i read that as something different. Voomoo (talk) 06:36, 4 June 2014 (UTC)
            • Well, technically, "copyfree" is subtopic of "free software", so simply adding it appears to be inappropriate. While I would be happy to remove "Free software" options (for other reasons), it requires proper discussion, not as a branch of discussion about adding new parameter. Thus my !vote still stands. — Dmitrij D. Czarkoff (talk•track) 07:37, 4 June 2014 (UTC)

Discourage use of "Free software" in "license" parameter

Following the discussion above I suggest to explicitly discourage usage of "|license=free software" in favor of specific license in template documentation. The rationale is following:

1. The difference between the licensing terms collectively known as "free software" is huge. Some of them are mutually incompatible. So the label "free software" does not tell the whole story.
2. There is a well-known argument within free software camp, so the readers may be interested in licensing details that may be hidden by "|license=free software".
3. To be considered "free software", program have to be released under license with particular set of terms. In other words, license deed must be available (and linkable) anyway. Why hide details then?
4. For well-known licenses we already have a suggestion to name licenses explicitly; this suggestion could be extended to all licenses with linkable articles about them. For custom or obscure licenses more precise terms (eg. "|license=custom copyleft", "|license=custom permissive", "|license=MyVeryOwnTerms") would be more informative.

The suggestion is limited to documentation only. — Dmitrij D. Czarkoff (talk•track) 07:37, 4 June 2014 (UTC)

Hi. The discouraging that you speak of is already in place. Please see: MOS:COMPUTING#License and Template:Infobox software/doc. MOS:COMPUTING especially places four requirements on the license descriptor but also demands: "specify the licensing terms of the subject of a computer program article accurately and concisely".

I don't seem to be able to spot an additional need for changes.

Best regards,

Codename Lisa (talk) 14:47, 4 June 2014 (UTC)

The current wording is:

You may specify a type of well-known license. For example:

• Proprietary commercial software ([[Proprietary software|Proprietary]] [[commercial software]]): Software products which are licensed for use for a price. Most software today are published under this license type. (As in this example, please be sure to link to [[Proprietary software]], which is an article about this type of software, and not to [[Proprietary]], which is a disambiguation page.)
• Freeware: Software products which are licensed for use (and sometimes redistribution) but free of charge.
• Freemium: Software products that are provided in both freeware and commercial versions, with the free version being usable without the need for any compulsory payment, but lacking certain features (not to be confused with shareware)
• Free software: Software products that can be used, studied, and modified without restriction, and which can be copied and redistributed in modified or unmodified form.
  — Template:Infobox software/doc 14:25, 1 June 2014‎ (UTC)

My problem is with the last line, which I suggest to replace with separate options "copyleft" and "permissive". I would also add a specific discouraging comment against "Free software" option, but this may be too much at this point. — Dmitrij D. Czarkoff (talk•track) 19:13, 4 June 2014 (UTC)

 Done Best regards, Codename Lisa (talk) 22:14, 4 June 2014 (UTC)

This way it is even better. Thanks! — Dmitrij D. Czarkoff (talk•track) 22:34, 4 June 2014 (UTC)