Template talk:Infobox software

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Frequently asked questions (FAQ)
Q: Why does this template not support importing version numbers from WikiData?

A: If you imagine that WikiData is a perfect mean of centralizing version number information across all articles of all lingual editions of Wikipedia, get ready to be shocked by the reality. As of May 2016, the means of importing from WikiData is so poor that the following scenarios fail entirely:

  1. Providing source for the version numbers. (Version number vandalism is not rare in English Wikipedia; hence a source is always required.)
  2. Formatting said sources in CS1 or CS2 styles
  3. Providing multiple version numbers and release dates for each of independent platform variants of the product, as seen in Adobe Acrobat and Adobe Flash Player articles.
  4. Accommodating for the cases where there are multiple version numbers and release dates on WikiData, i.e. when WikiData contains a full version history.

If you have written working code that deals with the first one (or with more), please feel free to open a thread in this regards. Wikipedia loves you for that. Otherwise, your thread might receive either no answers or curt dismissals.

Q: Why multiple software releases support, seen in {{Infobox web browser}} is not imported?

A: As of May 2016, there are still too many bugs. In its current state, it threatens to negatively impact articles that have not been edited and are working just fine. Main concerns are:

  1. When the edit button provided by {{LSR}} or {{LPR}} are pressed, how can one be sure that the right template gets edited?
  2. How can editors switch between methods of providing external info without needing undue amount of administrator assistance?
WikiProject Free Software / Software / Computing  (Rated Template-class)
WikiProject icon This template is within the scope of WikiProject Free Software, a collaborative effort to improve the coverage of free software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Template  This template does not require a rating on the project's quality scale.
Taskforce icon
This template is supported by WikiProject Software.
Taskforce icon
This template is supported by WikiProject Computing.

Change "Last release" to "Final release"[edit]

If the "discontinued" parameter is set, then the phrase "Last release" is displayed. But "last" is ambiguous. It can mean "final" or it can mean "most recent" - see meanings 1 and 2 at https://en.wiktionary.org/wiki/last#Adjective. To remove this ambiguity, "Last release" should be changed to "Final release". Nurg (talk) 01:50, 27 July 2016 (UTC)

Repository URL[edit]

I tried to add a new optional field to provide a link to the web-based repository of source code, if available, but with the dataXX-type parameters I am not sure what such changes entail. Is is problematic if I change the numbering of existing parameters to insert a new one in the middle of the list, or should I number the new one as the number of the last existing one +1, even if it is placed in the middle (i.e. the numbering will cease to be sorted)? And what changes do I need to make in TemplateData for it to continue working in VisualEditor? Please advise. --Waldir talk 08:57, 14 August 2016 (UTC)

Nevermind, I had forgotten about the labelXX/dataXX system. I've now implemented a new "repo" parameter in revision 736511975. --Waldir talk 01:09, 28 August 2016 (UTC)

Your implementation seems to be broken, see MooseFS. HTML source output is below:

<th scope="row" style="white-space: nowrap;"><a href="/wiki/Source_code_repository" class="mw-redirect" title="Source code repository">Source code repository</a></th>
<td><span class="url"><a rel="nofollow" class="external text" href="https://github.com/moosefs/moosefs,%20https://sourceforge.net/projects/moosefs/">github<wbr>.com<wbr>/moosefs<wbr>/moosefs,%20https:<wbr>//sourceforge<wbr>.net<wbr>/projects<wbr>/moosefs<wbr>/</a></span></td>
</tr> (talk) 17:57, 30 August 2016 (UTC)

I can't see that issue, it looks fine to me. Did you change something in the infobox or in the Wikidata item? I looked at the history of both but didn't find a clear culprit. --Waldir talk 09:34, 1 September 2016 (UTC)
Looks like one of those mysterious backend issues. We have this, the line break problem I reported earlier and an edit by Matt Fitzpatrick that apparently broke many articles but I don't think it is his fault. Maybe we should report this.
And while we are at it, I must say I strongly disagree with adding source code repo to the infobox. (We have an "External Links" section for that.) But you are admin and that means I probably can do nothing about it.
Best regards, Codename Lisa (talk) 10:07, 1 September 2016 (UTC)

When there are more than one source code repository, it shows as a single broken URL, see for instance https://en.wikipedia.org/wiki/Phabricator . It is probably also better to display the human readable URL instead of the machine readable URL. For instance if a git:// URL is provided as well as a link to the matching gitweb interface, the later should be prefered. The protocol qualifier can be used to distinguish between the two, as explained at https://www.wikidata.org/wiki/Wikidata:WikiProject_Informatics/FLOSS#source_code_repository . Dachary (talk) 13:06, 1 September 2016 (UTC)

Another example of this can be seen on Signal (software). I think the repo field should be taken out (or commented out) until this issue of showing a single broken URL is resolved. --Dodi 8238 (talk) 22:14, 2 September 2016 (UTC)
Thanks for the example, that clarifies the issue. As Dachary pointed out, the problem is that when a property has multiple values, and none of them has a preferred rank, Wikidata returns a list of all of them. This wasn't an issue with articles whose Wikidata item already had a preferred rank associated with the repository property.
Module:Official website handles this by sorting the property values and returning only the top one (see the fetchWikidataUrl function), so one solution could be to implement similar logic in a more generic module, one that could accept any property (or one of a curated list whose values are known to be URLs); then again, the very example of the Signal software shows a case where this wouldn't be appropriate, since I don't think either the Android, iOS or the desktop version could be considered the primary one (and d:Wikidata:WikiProject Informatics/FLOSS#source code repository says explicitly that in cases like this one, it isn't an option to link to the organization page (https://github.com/WhisperSystems), since that contains repositories that don't contain code for the Signal project (this could raise the issue of whether https://whispersystems.org sould be considered the website for the Signal project, from a data integrity perspective, but I'll leave that deliberation for those better versed in semantic data management than me).
So for now I restored the parameter using a simple test: if the value returned by Wikidata is a list, present it as-is; otherwise, use the {{URL}} template. This should prevent this bug from reocurring, but we can always manually fill in the infobox in those cases, if we feel an alternative presentation works better (e.g. {{URL}}-wrapping the individual links). Thanks all for the helpful comments. --Waldir talk 17:59, 3 September 2016 (UTC)

For the record a query was added to show items with no preferred source code repository in the FLOSS project. As explained by Waldir, there are cases where setting a preferred source code repository may not be sensible but it's good to have such a query around because it is far from trivial ;-). Dachary (talk) 23:15, 3 September 2016 (UTC)

@Waldir: since @Codename Lisa: strongly opposes the display of multiple URLs for the source code repository, what about not displaying the links when there are more than one ? The alternative would be to display a single link, chosen at random, but that would mostly likely provide a misleading information because the link is about the repository where the plugins for the software are stored instead of the software itself (for instance). In other words, it seems sensible to restrict the display to a single link, either because there is only one or because one of them is preferred and to hide multiple links otherwise. What do you think ? Dachary (talk) 07:24, 6 September 2016 (UTC)

Actually, if you read my RFC below, I oppose any link besides the official link in the infobox. If we open this gate, tomorrow we'll find many other links like official blog, Uservoice, Facebook, Twitter, YouTube, Instagram, Google+ and even StumbleUpon channel coming to the infobox and everyone argues that they are "useful". Wikipedia is not an external link farm. Best regards, Codename Lisa (talk) 07:39, 6 September 2016 (UTC)
Note that a source code repository (whether it's public or not) is a fundamental characteristic of software projects, so it's definitely in a different league than social media links and whatnot. I don't think slippery slope applies here. --Waldir talk 07:44, 6 September 2016 (UTC)
That sounds like a good compromise :) Eventually we might want to implement a proper module to check whether there's a single URL marked as preferred, so that we can use that, but this approach is simple and works for now (and should cover the majority of cases, I suppose). --Waldir talk 07:40, 6 September 2016 (UTC)

Some discussions reach a natural end sooner than their set end date. Codename Lisa (talk) 16:26, 15 September 2016 (UTC)

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.

Should we add a "source code repository" field to the infobox?[edit]

Demonstration of what will happen to the infobox
Source code repository

RFC Question: Should we add a "source code repository" field to the infobox?


  • It could go against WP:EL that says links that can be found as part of official website should not be included in the article.
  • Doing so can make the infobox long and unwieldy. Sometimes, like in the case of Signal (software), there are four or five links. The External Links section is a better place.
  • It is technical information that is no readily usable to every reader. Only programmers willing to participate in development need ready access to such links.

Best regards,
Codename Lisa (talk) 08:02, 4 September 2016 (UTC)


Place your verdicts here. Start each verdict with Oppose or Support as needed. This section is moderated, meaning non-verdict items will be moved to discussion section.

  1. Oppose for the three reasons mentioned in Caveats section. Best regards, Codename Lisa (talk) 08:02, 4 September 2016 (UTC)
  2. Support as original proponent. To prevent polluting this section, I'll add my reasoning in the discussion section, so I can address each raised caveat individually. --Waldir talk 09:57, 4 September 2016 (UTC)
  3. Support as primary maintainer of the Source code repository property in wikidata, because it is a primary source of information that allows verification of licenses, authors, inception date etc. It is often difficult to find from the official website. The poll proposal is negatively biased (does not show any expected benefits) and reflects a single point of view. Dachary (talk) 08:42, 7 September 2016 (UTC)
  4. Support as an interested consumer of this information. Having wikipedia-curated information about where to find source code of a given (FOSS) software would be invaluable. --Zacchiro (talk) 08:57, 7 September 2016 (UTC)
  5. Support I think it is an rather essential part of FOSS, and people reading these pages probably have an affinity to visit the source code pages. A shortened URL would probably be good. Instead of a key-value pair maybe just display the link with the label "Source Repository"? --Tobias1984 (talk) 20:14, 7 September 2016 (UTC)
  6. Support, as the primary source of information about software. To avoid polluting the infobox only one URL should be allowed, preferably one leading to the OS-independent root of the main mirror. If several are necessary, only short name of the target and not the full URL should be visible in the infobox. WarKosign 07:37, 13 September 2016 (UTC)
  7. Indifferent The caveats seem fairly mild and so do the needs. Sorry I can't be more definite, but it is not a facility that I am familiar with. I recommend that anyone who cares enough proceed rather than chewing the subject to rags; the discussion so far already exceeds any reasonable investment in such a facility. If nothing horrible happens the naysayers could best swallow and look pleasant. JonRichfield (talk) 08:57, 14 September 2016 (UTC)


I don't think the caveats mentioned above are as problematic as to warrant removal of the field. Specifically:

  1. "It could go against WP:EL": WP:EL is naturally a sensible and mature guideline, but in this particular case I believe WP:IAR applies, because including the source code link in the data infobox for articles covering software increases the encyclopedic value of the project, which is the primary aim we ought to strive for.
  2. "Doing so can make the infobox long and unwieldy": The size of the infobox entry can be managed in various ways that don't involve outright getting rid of the field: from shortening of the field name (say, to "source code" or "repository"), to manually providing shorter values in articles where the content returned by Wikidata is undesirably long, to directly editing the Wikidata item so that one of the repo entries is marked as preferred, to full-on implementing a more general form of Template:URL by improving its Lua module based on Module:Official website so that it gains the ability to pretty-print multiple URLs. Only the latter of these options requires more than a quick fix, so I wouldn't say this is particularly problematic.
  3. "It is technical information that is no readily usable to every reader": We could make the same argument about the license field, or others. Ultimately, we must consider that the audience of FLOSS articles (the only ones where this field will appear) is likely composed of a greater percentage of tech-savvy users and/or those concerned/acquainted with the concepts related to openly-licensed software and collaborative development projects. In this light, I'd argue that it's a disservice to the reader to deprive them from this relevant information which otherwise would not be presented in a predictable, consistent format.

For these reasons, I stand by my initial position that a repository field is a net positive in this infobox. --Waldir talk 10:12, 4 September 2016 (UTC)

Some smaller projects don't have a website other than their repo. How would those be handled if the repo parameter is removed? Matt Fitzpatrick (talk) 03:21, 5 September 2016 (UTC)

|website=Codename Lisa (talk) 09:15, 5 September 2016 (UTC)
Demo of how the infobox could display

Just to offer the "other side of the coin", is there any reason why the infobox couldn't be coded and documented like this? --RexxS (talk) 18:04, 5 September 2016 (UTC)

That can already be done by filling a custom value in the repo parameter. To make it work automatically using data from Wikidata would be more involved. Maybe there could be a qualifier to the repo statement indicating the repo name? I'm not sure, but if so, we could access that qualifier using a custom module and generate the link automatically. --Waldir talk 21:10, 5 September 2016 (UTC)
Looking at 'what links here' from source code repository (P1324), almost all of the urls contain an identifying string between the penultimate and final / that could be used as a label (with the exception of Mozilla Firefox (Q698)). When pulling the data from Wikidata, it would be relatively straightforward in Lua to extract that identifying string and construct a hyperlink using that for the text. In the odd case where it is blank, then the full url could be returned. Update: actually, the repository for Firefox was pointing to the root; I've fixed it and now it reads https://hg.mozilla.org/firefox/ and would fit the algorithm. --RexxS (talk) 21:40, 5 September 2016 (UTC)
Isn't that too brittle, though? e.g. the Wikidata item's URL is https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FWikidata.git, so the extracted string would be either "extensions" or "summary" (depending on whether we decode percent-encoded url characters), neither of which would be a useful label. Or am I misunderstanding your proposal? --Waldir talk 22:59, 5 September 2016 (UTC)
Whenever we fetch data from Wikidata, we have to accept that (1) the stored values were not designed just for our use and (2) the constraints on data values are rather weak. The result is that it's quite difficult to write code that is guaranteed to cover all cases. In my experience it's best to use code that handles most of the cases as simply as possible, and rely on the ability to override unwanted returned values by supplying a local value to the parameter. It's also worth checking when you find exceptions that the Wikidata value is actually the best, as I did with Firefox. If you follow https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FWikidata.git you actually arrive at https://phabricator.wikimedia.org/diffusion/EWDA/ which would be a much better value, imho.
Naturally, you can try to modify the way the value is stored on Wikidata, perhaps by adding a qualifier which would constitute the displayed text as you initially suggested. The initial problem there is that I can't see a good match for what we want among the properties available - perhaps official name (P1448)? The remaining problem then would be to persuade everyone adding a source code repository (P1324) url to add the qualifier, otherwise we end up having to add it ourselves - in which case I'm wondering why we would bother fetching the value from Wikidata rather than just using a local value? --RexxS (talk) 23:32, 5 September 2016 (UTC)
I don't think there is a way to automatically figure out a sensible short name for the repository. And I also do not see how that could be consistently maintained in wikidata. It's a nice idea though :-) Dachary (talk) 08:47, 7 September 2016 (UTC)
@RexxS: Yes, there is. According to MOS:COMPUTING, infobox links must be printer-friendly. But you can display as many of them as you link in "External links" section. I've already said WP:EL's angle against it, but let's call this a compromise I readily accept. Best regards, Codename Lisa (talk) 07:32, 6 September 2016 (UTC)
@Codename Lisa:MOS:WEBADDR: Certain areas of Wikipedia such as infoboxes require website addresses (URL) to be exposed in print. To maintain readability and conciseness, certain parts of the web addresses may need to be hidden or their shorter forms used. (my emphasis). Infoboxes, where space is at a premium, are not the places to put full urls. If you're worried about people printing the page out and losing the full url, then check the version of an article like aspirin that you get after clicking on "Printable version" in the left side toolbar. It has all of the external urls in the infobox expanded. It's not pretty on paper, but no information would be lost by using the scheme I suggest. Cheers --RexxS (talk) 15:28, 6 September 2016 (UTC)
My dear RexxS, you really need not bother with emphasizing; I know that part of MOS:WEBADDR like the back of my hand. The parts that you proposed to hide aren't those that MOS:WEBADDR sanctions. But that's really not my concerns. My concerns are those that I counted above. And really, being told that I am using a fallacious slippery slope argument doesn't give me the fuzzy feeling to withdraw my position without a step in the way of compromise from the opposition.
Best regards,
Codename Lisa (talk) 21:23, 6 September 2016 (UTC)
Please don't patronise me; you won't like my responses if you do that again. It's quite obvious that emphasis is required when you've ignored the very point that MOS:WEBADDR makes: Don't put long urls in infoboxes. The parts that I showed as hidden are precisely what WEBADDR requires. There's no need for long urls in infoboxes, and "printer-friendly" just isn't an argument, as I assume you've realised by now. I have no interest in seeing you withdraw your position; personally I am rather indifferent about whether there's a "source code repository" field in the infobox, although if pushed I'd probably prefer to see those in the External links sections, rather than extending an already lengthy infobox. Nevertheless - and I tried to put this politely first time - your illustration above is a misleading and deliberately contrived piece of nonsense. That's all I was drawing attention to. I hope I was clearer this time. Cheers --RexxS (talk) 23:58, 6 September 2016 (UTC)
Just for the peace of mind of anyone else reading this, I was trying to oppose politely, not patronize. Patronizing and other social unpleasantness is a waste of time to which I never commit.
Waldir, I would like your frank and honest comment on this: Do you also believe what I write is a "misleading" and "deliberately contrived piece of nonsense" and that I am harassing you by it? Please don't hold back, because if it is true, I will do every effort to make up for it. Thanks.
Best regards,
Codename Lisa (talk) 09:08, 7 September 2016 (UTC)
I've been deliberately avoiding reacting to aspects of the discussion that aren't focused on the objective facts under scrutiny and possible compromises, as that tends to carry out the conversation to less helpful, emotionally-charged, person-focused (rather than argument-focused) observations. But since you ask: I wouldn't put it in those terms, but I agree that the way the RfC's opening statement was presented didn't reflect an unbiased view of the discussion that preceded it (for instance, it used a worse-case example as if it were a typical one, and listed only downsides to the addition). I'd say that is indeed misleading, regardless of that effect being deliberate or not.
By the way, I wouldn't do this in a way that calls the attention of others (e.g in an unrelated discussion like this one), but again, following your prompt, allow me to comment generally on the tone of your comments in the interactions we've had so far: I tend to perceive from you a tendency to take actions and words as if directed to your person, or reflecting a power dynamic that is (at least from my part) not intended. Your comments about me being an admin ("But you are admin and that means I probably can do nothing about it.") are a prime example of this. That RexxS interpreted your comment as patronizing (and by the way, he also failed to refrain from escalating the discourse further) should have made you at least consider the possibility that your words were poorly chosen and could indeed have been interpreted that way, rather than merely denying the assessment. In fact, you have admitted to overreacting yourself, when we last conversed. I am afraid realizing this hasn't yet had the effect of preventing the same from occurring again. Please work on that, as the whole community will benefit from a less charged discourse. And everyone else: let's try to avoid escalating the discussion and aim for a calm and reasonable compromise, as we've all got better things to do, and we don't want to end up in XKCD for the wrong reasons, do we? :) --Waldir talk 10:30, 7 September 2016 (UTC)
@Waldir: That is not what I asked you to comment on. I asked you about MOS:WEBADDR and caveats, not any of this. Or that is what I received from a "misleading" and "deliberately contrived piece of nonsense".
As for the patronizing perception, I did consider it. You cannot tell because it happened in my mind. (I dismissed it as I find the reaction disproportionately hostile.) And as for you being an admin, everyone knows that reverting an admin's action done in admin capacity without just cause is wrong. Whatever else you have interpreted from my comment, please throw into the trash can. Finally, invoking connection to a conversation that happened over two years ago and suggesting I am still under the same misapprehension is a wrong that merely invites conflict. Best regards, Codename Lisa (talk) 10:56, 7 September 2016 (UTC)
A few loose points:
  • My comments were meant in a general sense, not attempting to imply a personal grudge between us two (I certainly don't hold anything against your person, just against the way you communicate sometimes, as I attempted to expand above). I am sorry that my words didn't make this explicit to you.
  • I was reacting to what I thought was the reason you mentioned me specifically: "Do you also believe what I write is a "misleading" and "deliberately contrived piece of nonsense" and that I am harassing you by it?". I seem to have misinterpreted what you were asking, but still believe what I said to be of some value -- I wouldn't "throw it in the trash can", to use your words, as I still think it is useful commentary for this discussion and others.
  • "As for the patronizing perception, I did consider it. You cannot tell because it happened in my mind." -- I considered pointing out precisely this, but was already writing too much. The part I highlighted demonstrates the issue. You surely are aware of the increased difficulty of written communication in getting unverbalized thoughts across, so my suggestion is to give some more weight to this, and generally erring on the side of (polite) explicitness, just in case.
  • Responding specifically about MOS:WEBADDR, since you insist that my opinion is particularly relevant (compared to other participants in this discussion): I believe RexxS is interpreting the rules correctly, and that his proposal holds both to the spirit and to the letter of that guideline.
  • Finally: I disagree with every word of "deliberately contrived piece of nonsense" -- at best, they are unprovable assumptions, and at worst they are a personal attack which is explicitly repudiated by our community guidelines. --Waldir talk 11:24, 7 September 2016 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── Good. Finally we are on the same page. This RFC was seriously at risk of becoming the worst RFC in my life. MOS:WEBADDR is proponent of using the more succinct forms of URL when they are displayed in bare form. Since the proposition above contains hyperlinks not bare URLs, MOS:WEBADDR hardly applies to it. This is something I just noticed. MOS:WEBADDR doesn't say in link added to the infobox must be bare. It is an Infobox Software initiative to display a bare official website link. That's a good initiative, one that we can overlook. Best regards, Codename Lisa (talk) 17:42, 7 September 2016 (UTC)

The proposal above should be amended with the expected benefits of having the source code repository displayed in the infobox. The example infobox should be changed to reflect that a single link would be displayed since nobody supports the idea of displaying multiple links. An earlier version of the page has these suggested changes but they were reverted. Without these changes the reader is asked to give an opinion based on an incorrect display of the infobox and with none of the expected benefits. It is to be noted that the primary focus of the author of the poll is proprietary software and Windows in particular, even in his most recent activity. This does not change the validity of his opinions, but that calls for a special attention to represent the diversity of the interests of the readers by including the views of at least one person with a primary interest in Free Software articles. Dachary (talk) 10:11, 7 September 2016 (UTC)

Agreed. --Waldir talk 10:32, 7 September 2016 (UTC)
Excuse me? This isn't your message to agree or disagree. Not agreeing with the nominator is natural, but disrupting and subverting his message is outrageous. I never modify anyone's nominations in RFCs, AFDs, RFAs, RFBs, or ANEWs. Best regards, Codename Lisa (talk) 10:41, 7 September 2016 (UTC)

Question for Codename Lisa (talk): Have you ever built or tried building a software from its source code repo? If yes, please name them. — Preceding unsigned comment added by (talk) 18:22, 7 September 2016 (UTC)

Irrelevant question, but the answer is yes. SVGOMG, Fraunhofer FDK AAC, Visual Studio Code. —Codename Lisa (talk) 18:14, 8 September 2016 (UTC)
What a suspicious question and answer. I wonder if @Mike V: would see any cause for concern? (talk) 08:35, 9 September 2016 (UTC)
Probably accuses me of edit warring on another article on which I have no diff! Face-wink.svg I wonder what he says about you contribution history though. It smells harassment.
No regards, Codename Lisa (talk) 09:18, 9 September 2016 (UTC)

Johan Richer and Emmanuel Raviart both work for a catalog of software for the French government, which motivated their interest in supporting this proposal. Their existence is real, their interest is genuine, to the extent that they both participated in the french wikiconvention organized in Paris a few weeks ago. This information is easily verifiable with a search engine. But the author of this poll came to a different conclusion and opened a socketpuppet investigation which was ruled within 24h. No attempt was made to contact either of them. Immediately after the ruling, the author of the poll removed the support expressed by Johan Richer and Emmanuel Raviart. I noticed the edit and added a user comment to the socketpuppet investigation and I'm hopefull this wrong will be undone. Dachary (talk) 20:38, 8 September 2016 (UTC)

My friend, it is "sockpuppet" not "socketpuppet".
But come to think of it, how do you know these accounts belonged to Johan Richer and Emmanuel Raviart? Maybe an intelligent cheater took advantage of their names in choosing his account names. I mean, anyone can create an account named User:Bill Gates, User:Richard Stallman or User:Obama.
In any case, Eraviart parroted Jricher's statement word for word without adding a layer of thinking to it to see that it is patent-nonsense. That's meatpuppetry which is equally bad. (Patent-nonsense because WP:ELOFFICIAL is a part of WP:EL and does not override it. Moreover, when I said WP:EL I really meant WP:ELOFFICIAL. So, this is a reason to oppose not support.)
Best regards,
Codename Lisa (talk) 09:18, 9 September 2016 (UTC)
I know these accounts belong to Johan Richer and Emmanuel Raviart because we discussed about it the same day. You can see from their profile that both are very much invested in the topic at hand. And I hope we can turn this unfortunate first experience into something more positive. They both acted in good faith and do not deserve to be treated in this way. I understand some explaining is necessary because a technicality (same IP and same comment, new comer mistake) made them look suspicious. Now that it is out of the way, asking even more proof and justifications is unnecessary. Dachary (talk) 11:13, 9 September 2016 (UTC)

Dachary's summary[edit]

Note: this summary is intended to be neutral and should reflect the diversity of point of views. It has been added because the author of the Rfc was unresponsive to suggestions to modify the summary of the Rfc to be neutral. Dachary (talk) 11:30, 9 September 2016 (UTC)

Demonstration of how the infobox could look like
Source code


  • It is the primary source of information for a number of facts about the software. For instance the license, the authors, the inception date.
  • It significantly helps every reader and editor to verify facts about the software.
  • It is frequently non trivial to find from the official website.


  • It could go against WP:EL that says links that can be found as part of official website should not be included in the article.
  • It is technical information that is no readily usable to every reader. Only programmers willing to participate in development need ready access to such links.

Dachary (talk) 14:17, 9 September 2016 (UTC)

It is your point of view and as non-neutral as it can get. It has the following problems:
  1. "It is the primary source of information for a number of facts [...]" If it is a source, it must go to the citations section and cannot appear as a standalone external link.
  2. "It significantly helps every reader [...]". So basically, WP:IJUSTLIKEIT. Veteran Wikipedians get inoculated against the allegations of "It significantly helps" unless it is proven or displayed. Virtually every spammer claims his addition significantly helps! Furthermore, WP:NOT has it that Wikipedia deliberately avoid being a collector of thousands of useful things; includes WP:NOTLINK.
  3. "It is frequently non trivial to find from the official website." In that case each link requires a source! Contents without source are challenged or deleted, meaning that I am at liberty to challenge or delete these statements that come from WikiData without a source. I would be at the right to suppress the addition of this field because it adds potentially unreferenced non-trivial information. Seriously, how do you call this a benefit?
  4. The demo infobox is not faithful demonstration of how Waldir made it look like, causing me to start this RfC. One of the purposes of this RfC is to mitigate this issue. This is your idea and one of the ideas, but:
    1. It contains one link only and does not demonstrate what catastrophe would occur if multiple come from Wikidata.
    2. The [[source code repository|source code]] link in it is a violation of WP:SUBMARINE. This problem didn't exist in the Waldir version.
  5. "because the author of the Rfc was unresponsive to suggestions to modify the summary". Hint: Try easing off on ad hominem comments and try not censoring other people's messages. Aside from that, you seem to have trouble understand what is the purpose of an RFC: For the author to request comment on his opinion! You want to change my opinion. If you change it won't be a request for comment on my opinion.
Best regards,
Codename Lisa (talk) 13:13, 9 September 2016 (UTC)
The caveats are not my point of view, they are copy/pasted from your point of view, which makes the section above neutral as it represents a diversity of viewpoints. I would be more than happy to amend this section if someone feels an aspect is missing, regardless of the fact that I agree or disagree with her/is point of view. I did not include the caveat where you describe the infobox layout that nobody supports as the desired layout because it does not convey any information or opinion, it relates to a bug in an earlier implementation that no longer exists and has no relevance in this discussion. In a Rfc the statement and summary should be neutral and brief, not opinionated. Dachary (talk) 20:52, 9 September 2016 (UTC)
Are you talking to someone else who is not here? I didn't even mention the caveats section.
But you are not neutral. Between everything you have done so far, like your personal attacks, filling an ANI case against me, digging dirt on me, etc., you are the last person in the universe I would believe to be neutral. —Codename Lisa (talk) 08:07, 10 September 2016 (UTC)
In the spirit of going back to a more productive dialog I will let the non factual comment above, the removal of my edit and the modification of another edit slide. I could dispute them but that would bring nothing to the discussion. Let's be grown ups and move on, shall we ? Dachary (talk) 10:59, 11 September 2016 (UTC)

Updated summary[edit]

Note: this summary is intended to be neutral and should reflect the diversity of the point of views expressed in the above discussion. If a benefit, caveat or implementation detail is missing or misrepresented, please let me know and I'll update it.

Demonstration of how the infobox could look like
Source code https://github.com/WhisperSystems


  • Including the source code link in the data infobox for articles covering software increases the encyclopedic value of the project (see WP:IAR).
  • The audience of FLOSS articles (the only ones where this field will appear) is likely composed of a greater percentage of tech-savvy users and/or those concerned/acquainted with the concepts related to openly-licensed software and collaborative development projects. It would be a service to these readers to present them with this information which otherwise would not be presented in a predictable, consistent format.
  • It is the primary source of information for a number of facts about the software. For instance the license, the authors, the inception date.
  • It helps every reader and editor to verify facts about the software because it contains most of them.
  • It is frequently non trivial to find from the official website. If it was, it would be redundant with the official website URL.


  • It could go against WP:EL that says links that can be found as part of official website should not be included in the article.
  • It is technical information that is no readily usable to every reader. Only programmers willing to participate in development need ready access to such links.

Implementation notes:

  • If multiple source code repository links exist and none has a preferred rank, no link is displayed because they would clutter the display.
  • If a quick fix is not enough, more general form of Template:URL by improving its Lua module based on Module:Official website could be implemented to handle the various cases.
  • If the URL is undesirably long (MOS:WEBADDR), it can be manually overriden by a shorter URL, as can be done with the official website.
  • The label is shortened from Source code repository to Source code: both have the same meaning in this context and comply with the recommendation of MOS:SUBMARINE.

Dachary (talk) 08:56, 12 September 2016 (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.

Unexpected line break[edit]

Infobox software
Stable release
1.0 / 28 September 2016


I've noticed the infobox is inserting a line break between the version number and the "/".

This happened today. Or at least I did not notice it in my previous tests and nobody reported to have seen it during the feedback period since I implemented it in Template:Infobox web browser. (31 May 2016)

Does anyone have any idea as to how to mitigate it?

Best regards,
Codename Lisa (talk) 09:56, 28 August 2016 (UTC)

It appears to be the <p> tag in Template:Infobox software/stacked. I suppose we could change it from <p class="plainlinks" style="font-size:smaller; margin:0px">...</p> to <span class="plainlinks" style="font-size:smaller; margin:0px">...</span>. But that wasn't introduced recently, so it's weird that the issue hadn't been noticed before. Regardless, making this change seems like it couldn't harm. --Waldir talk 10:05, 28 August 2016 (UTC)
@Waldir: The code in this case, is transcluded from Template:Infobox software/simple, not stacked. That's what amazes me. I am on a desktop computer, so I can hit F12 and inspect the code. And the result is that somehow, a <p>...</p> is injected into the code.
Best regards,
Codename Lisa (talk) 15:16, 28 August 2016 (UTC)
Okay, I inserted a diversionary <div>...</div> tag to suppress the injection of <p>...</p>. I guess I am lucky I discovered this. Probably this is the effect the HTML optimization backend of MediaWiki. I have added explicit cases to the test case. Best regards, Codename Lisa (talk) 15:39, 28 August 2016 (UTC)

Bug(s) with getting website from Wikidata[edit]

The template behaves wrong if there's two website URLs present on Wikidata. For one thing, it should not display historical URLs (end time/P582 in the past). If there are several websites nevertheless, it should properly separate the two URLs – two individual links, proper whitespace in between, etc.

See OpenWebRTC for an example.--Flugaal (talk) 11:46, 31 August 2016 (UTC)

Yes, that's because this template was implemented with the naive Wikidata parser function. Module:Official website makes this work by considering the ranks, as does the getValue function of Module:Wikidata. The rank is already fixed on Wikidata; @RexxS: should be a simple fix in the infobox, and you've got a bit more savvy with the Wikidata module functions. --Izno (talk) 12:36, 31 August 2016 (UTC)
I would have thought that an infobox should be displaying just one "official website", in line with our guidance on keeping infoboxes concise and policy on external links. If multiple official sites exist or have existed, then the text of the article should be the place to discuss that, if it's relevant and due. My advice would be to update the documentation.
For those reasons, I'd suggest that editors should ensure that the Wikidata property official website (P856) for each article contains no more than one preferred value, as you've done already for OpenWebRTC (Q26721332). The #property function returns the best ranked values, so we don't really need to complicate the Template:Official URL further with a Lua module. By the way, if you want to provide a link to edit the Wikidata entry, the Template:EditAtWikidata and Module:EditAtWikidata are available for use inside templates and modules. --RexxS (talk) 13:38, 31 August 2016 (UTC)

Hello. I am closing this question because the aforementioned problem was not observed in OpenWebRTC. It is showing one website at this time and its WikiData entry has two websites. One of them is now assigned the preferred rank, so I believe what my dear colleague Izno said was not entirely correct. (Sorry about that.)

Best regards,
Codename Lisa (talk) 08:56, 1 September 2016 (UTC)

I've left a message at Template talk:Official URL, since {{Official URL}} uses identical code and so has the same problem. Making sure there's one preferred value wherever possible is a great idea. It would be nice to handle the possibility of two co-official URLs, though, just in case that ever comes up. Matt Fitzpatrick (talk) 23:55, 1 September 2016 (UTC)

The same problem occurs for the "repo" tag, for which I'd say it's valid to have multiple URLs. e.g. https://www.wikidata.org/wiki/Q657028 and https://en.wikipedia.org/wiki/Sinatra_(software). So would be really nice to fix this, no ? --Farialima (talk) 03:40, 2 September 2016 (UTC)

Very well. It appears that this field could use better implementation and its creation was not well thought out. I myself found the addition of this field highly questionable but could not decide whether to show my disagreement with a revert. For one thing, the Wikipedia:External links guideline says a link that is generally found in the official website must not be inserted into the article. For another, I don't believe infobox is a place to collect external links. (The "External links" section is.) To make matters worse, the string "Source code repository" occupied a lot of space leaving very little space for the link itself, cramming a usually long link (not to mention visually unpleasant) into a usually very small space, causing the infobox to become tall and ugly.
But now that these reports have come through, I finally went ahead and reverted the addition. We can plan our next move carefully now. Is it not better to create a {{Repo}} for the external links section that takes all the factors into account?
Best regards,
Codename Lisa (talk) 06:37, 3 September 2016 (UTC)

What's the reason for the restrained Wikidata usage?[edit]

So I've read the note on version numbers, but why doesn't the template get things like programming language, license, operating system from Wikidata? They seem pretty obvious and easy candidates.--Flugaal (talk) 14:38, 31 August 2016 (UTC)

Everything in Wikipedia needs a source and Featured Articles require proper citations with proper style as well. WikiData does not support adding sources with proper citation style. (Sources in WikiData amount to bare URLs and are prone to link rot.) Our standards for a Featured Article are already brutal. We cannot impede our editors efforts to promote an article to FA by tying their fate to such flimsy website as WikiData.
Proper sources aren't just required for FA; they are required to counter sneaky vandalism and non-deliberate introduction of factual error. (For example, "Programming language" is one area in which people resort to guesswork; they don't know the programming language of an app, so they insert "C/C++" in there!) Vandalism in WikiData is impossible to control without implementing additional cross-wiki monitoring measures.
Best regards,
Codename Lisa (talk) 06:15, 3 September 2016 (UTC)

UX: Expandable/collpasable screenshot component is confusing[edit]

This is a user experience critique of the user interface.

I noticed that the expandable/collapsable screenshot component can be confusing.


For an example of the confusion I experienced, I opened the below page.


I am used to seeing a useful summary of useful information on the right side of the page, which is what my perception chunked. And then I started reading from the top.

I first read the header "Google Keep", and then I saw the icon below, and right below that icon I noticed the "Screenshot" text.

I was under the impression that what was being implied is that the Google Keep icon is a screenshot, thinking that the "Screenshot" text was a caption for the above Google Keep icon. Of course the Google Keep icon would not be considered a screenshot of Google Keep on a display.

I attempted to "fix" this error by viewing the source. I was not familiar with the Infobox template, but I soon suspected that there was no error in the use of the Infobox template.

From there, I returned to the view of the Infobox, and, after some moments, I noticed the "[show]" text that is far to the right of the "Screenshot" text.

I believe it is not clear that the

"Screenshot                   [show]"

component is meant to show a screenshot, and thus can confuse readers to believe that something else is a screenshot (or perhaps some other erroneous interpretation).

Some Fix Ideas[edit]

  1. Instead of the collapsed form looking like
    "Screenshot         [show]"

    Instead the collapsed form could be "[show a screenshot]". In this case, the expanded form would look the same, but perhaps the "[hide]" text could be closer to the "Screenshot" header text.
  2. Another possible fix is to have the "[show]" text closer to the "Screenshot" header text. In this case, it might be more clear that, in the collapsed form, that "Screenshot[show]" is for a collapsed screenshot component. However I don't think this is the most clear.
  3. Perhaps the cleanest solution would be to position the "[show]" text centered and directly below the "Screenshot" text. This would maintain the content of the current 3 texts, and would use vertical relative positioning to imply that the "Screenshot" text header is somewhat parental/hierarchically ancestral to the "[show]" text, and thus that the "[show]" text button will show a screenshot.

Anyway, hopefully this is helpful. Thanks. :)

-- (talk) 05:54, 3 September 2016 (UTC)

Done Codename Lisa (talk) 17:04, 5 September 2016 (UTC)

Source code[edit]

Would it be possible to replace Source code repository with Source code ? It is shorter and unambiguous. Dachary (talk) 14:18, 23 September 2016 (UTC)

I agree. --Waldir talk 21:35, 25 September 2016 (UTC)
Cannot be done, per WP:SUBMARINE.
But I have already implemented RexxS's suggestion to the effect that we use "repository" instead. Of course, back then, you said you agree with that too. —Best regards, Codename Lisa (talk) 08:58, 26 September 2016 (UTC)

More repository problems (no value / unknown value is not handled)[edit]


eyeOS article now has a no%20value in its repo field.

Any ideas as to what to do?


Best regards,
Codename Lisa (talk) 09:34, 26 September 2016 (UTC)

This happens when we know there is no source code repository for this software (see no value for more information). It should be handled as a special case and either be not displayed at all (as if the statement did not exist in wikidata) or displayed as unavailable. Note that this is different from not knowing where the source code repository is. This is about knowing there is no source code repository at all. Dachary (talk) 16:19, 26 September 2016 (UTC)