Jump to content

Template talk:Infobox software/Archive 6

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 4Archive 5Archive 6Archive 7Archive 8

Screenshot in infobox

Clicking on a screenshot in infobox should lead to the "lightbox" showing a bigger image and opening the screenshot in a new tab should open its page.Currently, the "lightbox" shows a smaller image. I'd like to fix this. Am new to wikipedia but not new to programming. thanks!

Sindhu S 06:45, 6 June 2014 (UTC) — Preceding unsigned comment added by Sindhu sundar (talk • contribs)

I tried it right now, and I had larger image in "lightbox". Could you please link to the article where you saw the smaller image in "lightbox"? — Dmitrij D. Czarkoff (talk•track) 08:38, 6 June 2014 (UTC)
  • I'm guessing this has nothing to do with the infobox itself but instead is confusion about the release of the new media-viewer. I believe I saw something similar to this on WP:VPT but it wasn't of great interest to me. You may want to look there (and check the recent archives). — {{U|Technical 13}} (e • t • c) 12:07, 6 June 2014 (UTC)
Hi. I am not comfortable with guessing and assuming in case of beta stuff. (I hope you understand my caution.) An article name would really help put this to rest. Best regards, Codename Lisa (talk) 19:49, 6 June 2014 (UTC)
Actually, please see Microsoft Visual Studio. Well, look like WP:NFCC confusion again. Best regards, Codename Lisa (talk) 19:50, 6 June 2014 (UTC)

More compact language list

Hello!

Sandbox contains an implementation of more compact way to deal with multiple languages. It places the collapse handle on the same line with language count, so that data field with the list of languages is hidden entirely. The change requires fixed-size labels (visually indistinguishable here), subbox and one more parser function. testcases are available.

In my opinion this change would improve experience with infoboxes for software in multiple languages. — Dmitrij D. Czarkoff (talk•track) 12:03, 7 June 2014 (UTC)

Question: Was there a discussion somewhere showing consensus for this? What do you think Codename Lisa? — {{U|Technical 13}} (e • t • c) 12:21, 7 June 2014 (UTC)
Technical 13, there was no specific discussion for this particular implementation, but Archive 5 of this talk page contains edit request which introduced the feature and user request to implement it. — Dmitrij D. Czarkoff (talk•track) 13:28, 7 June 2014 (UTC)
(edit conflict) Hi. I am aware of two discussion in the past. However, I don't think they apply here; not even remotely. This is just a purely good edit.
I am about to reset the sandbox and reapply the change to have a better view in the test case. (Just telling, so no one is getting surprised.) Best regards, Codename Lisa (talk) 13:30, 7 June 2014 (UTC)
While I appreciate the change in principle (thought about an easy solution myself some months ago) there are some things that need improvement:
  • Fixed width labels are unacceptable in my opinion. The labels in the testcases take up space unnecessarily and the spacing looks all wrong from an aesthetic point of view.
  • Can the label to expand the list be changed? Show/hide sounds much clearer here (and is shorter) than expand/collapse.
  • The List of languages should be aligned left. It looks better than the current centered alignment.
--Patrick87 (talk) 13:34, 7 June 2014 (UTC)
I don't particularly like the [expand] and [collapse] as opposed to [show] and [hide]. I also don't like the "List of available languages" header goes away. It does seem to work, but I think it looks kind of hacky. Finally, I don't like the list being centered, and would prefer the list be linked languages, and bullet delimited (although horizontal and not vertical). I'd be happy to take a few moments later to see if I can make it work better, but that "may" require and administrator to make a change to the site css... — {{U|Technical 13}} (e • t • c) 13:41, 7 June 2014 (UTC)
(edit conflict)
Hi. I re-synched the sandbox and main infobox, so the width change is now gone. Please check the testcase.
I don't know about the label, but I love centered language list. And linking to the languages is discouraged by the guideline.
Best regards,
Codename Lisa (talk) 13:43, 7 June 2014 (UTC)
Fixed width was required because otherwise the data fields of parent infobox (most of this template) and of child (languages) won't match each other. Now I've changed sandbox to use remote toggle, so that the list is shown/hidden by pressing "[list]" toggle. This solution is a bit simpler and doesn't break the formatting of the rest of infobox, although I can't make the toggle show context-sensitive "show/hide" label due to MediaWiki limitation. — Dmitrij D. Czarkoff (talk•track) 15:19, 7 June 2014 (UTC)
@Patrick87: I can make the list left-adjusted, but it would deviate from infobox defaults for no apparent reason. — Dmitrij D. Czarkoff (talk•track) 15:19, 7 June 2014 (UTC)
@Codename Lisa: what did you mean by "linking to the languages is discouraged by the guideline"? The plainlink in testcase is user-generated; this template provides another option for citing sources about l10n – |language footnote=, which appends footnote to the data field corresponding to "Available in" label. — Dmitrij D. Czarkoff (talk•track) 15:19, 7 June 2014 (UTC)
Oh, I was actually replying to Technical13's comment. WP:OVERLINK says the names of major geographic features and locations, languages, religions and common occupations should not be linked. And I agree with it. I unlink these whenever I see them and there haven't been any objection that I remember. Best regards, Codename Lisa (talk) 06:50, 8 June 2014 (UTC)
@Technical 13: This change is proposed with the sole reason – to get rid of immutable "List of available languages" text. The formatting of the list (prose vs. {{hlist}}) is outside the scope of this template – the data field is merely a container for user-generated content. — Dmitrij D. Czarkoff (talk•track) 15:19, 7 June 2014 (UTC)
  • What I'm saying Dmitrij, is that when the list of languages is expanded/shown, that "List of available languages" text should appear. I'm working on it and I'm fairly sure it can be done. ;) — {{U|Technical 13}} (e • t • c) 15:31, 7 June 2014 (UTC)
@Technical 13: sorry, didn't quite get you.  Done, although not an improvement IMO. — Dmitrij D. Czarkoff (talk•track) 15:45, 7 June 2014 (UTC)
@Technical 13: it seems overy verbose for me – "Available in" and "List of languages:" are redundant. That said, I like this more then current template in production. — Dmitrij D. Czarkoff (talk•track) 16:07, 7 June 2014 (UTC)
  • Dmitrij, I just don't find "Available in ## languages" an appropriate heading for a list of languages. If there was a way to magically change the text to "Available in the following ## languages" when the list is expanded, I would agree with you. As it sits, no. Magically changing that is out of scope for what this template itself can do, so I find the extra text upon expanding as necessary. Can you give me some examples of other formats for how the languages list is populated? I may be able to have to template force an hlist in most cases if I know what to expect for input. I can do it with parser functions and existing Lua modules. — {{U|Technical 13}} (e • t • c) 16:26, 7 June 2014 (UTC)

@Technical 13: probably an easier way to enforce hlist would be to:

  1. add {{flatlist}} to the tempalte,
  2. add tracking category to the |language count= (to be able to audit the use of this feature),
  3. document the change,
  4. (optionally) make {{flatlist}} spit fire when its argument is not list (doable in Lua, if not already done).

Not sure #4 is really needed. Documentation and a round of edits should probably be enough. — Dmitrij D. Czarkoff (talk•track) 17:12, 7 June 2014 (UTC)

  • Czarkoff, or we could just wrap the languages template something like:
{{Flatlist|
* {{#Invoke:String|replace|{{{languages|}}}|[,;:\-\*]|
*|plain=false}}}}
which would turn

English (America), French (Canada); Spanish (Mexico): Chinese * Hindu

into
  • English (America)
  • French (Canada)
  • Spanish (Mexico)
  • Chinese
  • Hindu
What do you think? — {{U|Technical 13}} (e • t • c) 00:30, 8 June 2014 (UTC)
@Technical 13: FWIW I would prefer requesting use of {{flatlist}}/{{hlist}} in Documentation and leave it to editors, so that more complex layout could be possible when needed, eg.:
|language count=50
|language=
Full translations:<br />{{hlist|English|French|German|[...]}}

Partial translations:<br />{{hlist|Spanish|Russian|[...]}}
Having copy-paste example in Documentation and flexible layout sounds optimal for me. — Dmitrij D. Czarkoff (talk•track) 03:31, 8 June 2014 (UTC)
Hi. I made an edit to establish natural flow for accessibility using <P>...</P> but also added "text-align:justify;" to see how everyone likes it. (So, how do you like it?) Still, it can be easily reverted by removing "text-align:justify;" and the flow returns to infobox default.
Best regards,
Codename Lisa (talk) 07:32, 8 June 2014 (UTC)
@Codename Lisa: I would prefer either centered or left-aligned style, although default option (whatever it is or may be in future) seems best to me. — Dmitrij D. Czarkoff (talk•track) 07:41, 8 June 2014 (UTC)
Okay, if Technical13 and Patrick didn't make a comment about it within 24 hours, I'll undo. Best regards, Codename Lisa (talk) 07:44, 8 June 2014 (UTC)
Actually I'd still prefer left alignment or no specified alignment (which turns out to be centered) as a second choice. Justified text just doesn't work nicely in browsers. --Patrick87 (talk) 13:32, 8 June 2014 (UTC)
I like it justified, or left aligned. — {{U|Technical 13}} (e • t • c) 15:04, 8 June 2014 (UTC)
So we stick with left aligned I suppose? At least this is the only choice all four if us can consent so far... --Patrick87 (talk) 20:04, 8 June 2014 (UTC)

@Codename Lisa and Technical 13: Now, I made the toggle also hide away the whole field "n languages[ref]" (together with toggle itself). I also removed "List of languages:" and added "(n total)[ref]" at the bottom. Overall, it became more less verbose. The fields may be toggled bak by clicking anywhere (except links) inside language list field, and cursor is changed to "pointer" to hint at this. (Although I am unsure whether toggling back is needed at all, given that all info is already present.) I welcome comments and style changes. — Dmitrij D. Czarkoff (talk•track) 08:05, 8 June 2014 (UTC)

And now, it is impossible to collapse the list again?
Codename Lisa (talk) 08:09, 8 June 2014 (UTC)
@Codename Lisa: Clicking anywhere in the language list data field will collapse the list and restore "n languages[ref] [list]" data field. "Point"-style cursor should aid [otherwise poor] discoverability of this "feature". I can make the handle visible in both states if needed. — Dmitrij D. Czarkoff (talk•track) 08:16, 8 June 2014 (UTC)
Look, your first edit was great. I didn't mind much about the "expand/collapse" wording. The edit with "list" was not as good; it should have optimally been "show/hide" but I thought I'd suggest "toggle list" in due course. But this one is too freaky. I would not discover it unless I move my mouse cursor over it, only I don't because I don't move my mouse pointer anywhere unless I think there is a point in doing that. (Not knowing meant seeing no point.) And beside, touch-screen user do not get a mouse pointer at all. So, they can only discover by accident.
Please put the toggle back.
Best regards,
Codename Lisa (talk) 08:26, 8 June 2014 (UTC)
 Done. — Dmitrij D. Czarkoff (talk•track) 08:52, 8 June 2014 (UTC)

@Codename Lisa and Technical 13: I've made a new {{collapse toggle}} template that provides switchable text in the toggle. I used it in sandbox to make proper show/hide handle or for collapsible list and to reduce the amount of HTML in the template. Opinions? — Dmitrij D. Czarkoff (talk•track) 12:58, 8 June 2014 (UTC)

The current sandbox version overdoes it a little. There are just too many unnecessary (and even faulty) animations:
  • The initial label (e.g. "53 languages") should not be hidden on expanding
  • The button itself does not really need an animation; the current one is even jumping around in Firefox 29.0.1 on Windows 7.
  • The sliding looks inappropriate for Wikipedia. At most I'd use some fading, but nothing that dynamically changes position during animation.
--Patrick87 (talk) 13:32, 8 June 2014 (UTC)
I didn't know about sliding. Apparently it is an effect of MediaWiki, the Wikipedia engine, that is only available (and enforced) in Vector theme which I don't use; I have absolutely no control over it. I reverted the "animated" toggle for that reason. I would also happily remove the hiding of "initial label" (as you call it), but per Technical 13's opinion that requires the heading for the list of languages, which is in my opinion unacceptable. — Dmitrij D. Czarkoff (talk•track) 14:25, 8 June 2014 (UTC)
OK, you fixed my second point, however the text is now static (always showing "list"), which *might* be acceptable but is surely not optimal. Regarding sliding: It was OK in you first two iterations (once without any animation and once with fading in/out), so I assume there actually is some possibility to control this behavior?
And lastly (list of languages): I doubt Technical13 would be happy with the current situation either? Let's hear him, but hiding the initial field value (which also often contains a reference) is certainly not an option! If we can't consent on this, we have to keep the status-quo I'm afraid. I could totally live without the heading for the list of languages cause I think it's obvious (especially if the button is called "list"). Maybe Technical13 can consent, too, after getting used to the new and therefore unfamiliar appearance... --Patrick87 (talk) 14:49, 8 June 2014 (UTC)
  • I do not like the sliding at all. That is just horrible, this is an encyclopedia, not MySpace... I liked it with the simple toggle link and I liked it when it said "List of languages". What we might be able to do though, is adjust the sliding so it doesn't look like sliding but instead says "Available in ## languages   [ list ]" when collapsed and "Available in the following ## languages   [ hide ]" when expanded, that would be great. — {{U|Technical 13}} (e • t • c) 15:04, 8 June 2014 (UTC)
  • @Technical 13 and Patrick87: from what I gather, I can't make a toggle with context-sensitive text because of animations enforced by MediaWiki and/or particular Wikipedia setup of it. The "fade out" animation appears to be enforced onto table cells, while sliding annimation is enforced for the rest of elements (divs, spans, p, etc). This means that I can get rid of sliding annimation by either of three means:
  1. Revert to "subbox" approach, which only works with fix width. (Otherwise align gets broken.)
  2. Modify Module:Infobox to set ids of table cells.
  3. Somehow make Wikipedia abandon animations. Given that they are recent feature, I consider this option hopeless.
P.S.: for the record, I don't care for animations. At all. Not only because I don't see them anyway, but also because we are editing encyclopedia, not a social site, so these details are IMO completely irrelevant, compared to the content issues like unnecessarily verbose UI. — Dmitrij D. Czarkoff (talk•track) 16:22, 8 June 2014 (UTC)
Note: I have deactivated the edit request for now. You guys are no doubt discussing constructively, but are not quite ready yet to apply a change to the actual template. When you guys reach an agreement, reactivate this edit request and provide a permalink to the sandbox version that you guys agreed on, and I'll apply it. —cyberpower ChatOnline 00:16, 10 June 2014 (UTC)

@Codename Lisa, Patrick87, and Technical 13: I requested changes in module:infobox, which will enable collapsing table element (as opposed to div inside table). Side effect of this change is table collapse animation (fading) instead of div collapsing animation (sliding). See discussion here. — Dmitrij D. Czarkoff (talk•track) 07:39, 14 June 2014 (UTC)

Add to my watchlist. Best regards, Codename Lisa (talk) 12:20, 15 June 2014 (UTC)

convenience br/

@Codename Lisa, Patrick87, and Technical 13: Following recent changes in module:infobox I reinmplemented collapsing in sandbox in a manner that avoids sliding animations whatsoever. I also duplicated toggle in collapsible list, so that we now have two separate toggles, visible one at time, with context-sensitive labels. See testcases for new rendition. Opinions? OKs? — Dmitrij D. Czarkoff (talk•track) 08:15, 19 June 2014 (UTC)

The separate toggle is a problem, since it looks as if the toggle was jumping up and down. The toggle's position should be static. Besides that it's looking quite good, though. --Patrick87 (talk) 11:13, 19 June 2014 (UTC)
Well, there is another option with misplaced static toggle. I'll show it off once I gather opinions for this revision. — Dmitrij D. Czarkoff (talk•track) 11:23, 19 June 2014 (UTC)
Man, this moving toggle is cool! Best regards, Codename Lisa (talk) 16:45, 19 June 2014 (UTC)
  • I have good news and bad news:
The good news is: I love your supercool edit.
The bad news is: It just occurred to me that to have id added to the Template:Infobox means an article with two or more infoboxes has a risk of id duplication and consequently invalid HTML. I tested it in Sandbox and unfortunately, the toggle button can toggle all infoboxes, no just one. See for yourself. Should we try generating a dynamic ID by adding {{{name}}}?
Best regards,
Codename Lisa (talk) 00:48, 23 June 2014 (UTC)
  • I was going to say it looks great as well. The id thing occurred to me before, and I had forgotten about it because most browsers just don't care. If we are going to fix it, Lisa, I don't think that trying to make it dynamic based on {{{name}}} is optimal, because that is likely to be the same. What is likely to be different in two uses of the same infobox on the same page? I would guess OS is the most likely reason, agree? — {{U|Technical 13}} (e • t • c) 01:23, 23 June 2014 (UTC)
  • No! It is not guaranteed, neither by practice nor by convention. Name is guaranteed by convention to be unique; i.e. for a long time we required users to use it as a technical device, not to use images in it and defer to using |title= whenever cosmetic issues conflicted technical issues. We even implemented a mean to avoid the Special:WhatLinksHere/Template:Latest_stable_software_release/ fiasco. I don't see why we must stray from this convention just because we are worried about malpractice while we can require it.
Of course, I have another comment that I must make after seeing Dmitrij's feedback.
Best regards,
Codename Lisa (talk) 01:36, 23 June 2014 (UTC)
I've edited sandbox to use {{{name}}} in IDs. This involves 6 lua invokations: spaces have to be stripped from names because jquery.makeCollapsible is based on CSS classes, which are whitespace-separated. Consequently it is impossible to ship sandbox version in production until the issue is fixed within Module:Infobox. I also changed the sandbox to require names, and I consider requiring them in Module:Infobox either. — Dmitrij D. Czarkoff (talk•track) 07:45, 23 June 2014 (UTC)
Don't you think this problem is getting rampant? The amount of additional code needed to make this thing work at least somehow (I don't think it's working anywhere close to satisfactory right now) is just not worth the gain in my opinion. If we can't find an easy possibility to do this – why not just stick to the old version that worked for everybody for ages and live with the extra line of text? --Patrick87 (talk) 09:13, 23 June 2014 (UTC)
Your assumption that current version worked satifactory for everybody is wrong: it never did. It was merely a hack to avoid yet uglier problem. — Dmitrij D. Czarkoff (talk•track) 10:25, 23 June 2014 (UTC)
Yeah, and it worked, didn't it? You could read the list of languages couldn't you? What I'm trying to say is that replacing a "hack" as you call it with another hack that needs substantially more code and is substantially more expensive for the parser is not the way to go. I'm totally supporting the idea behind your efforts, but currently I don't see how it could be implemented reasonably. Given the limitations some users have (number of languages should be hidden on expanding exhaustive list) it's just not doable in a proper, non-hacky manner (in the end expanding/collapsing is a hack by itself from the start, that doesn't play well with regards to compatibility). --Patrick87 (talk) 19:21, 23 June 2014 (UTC)
As it stands now, the changes from sandbox can't be merged to the template due to excessive use of processing power. I am working on some sane solution, which would most likely include changes to jquery.makeCollapsible, Module:Infobox and/or site CSS. So yes, currently my proposal can't be implemented in a reasonable manner, and this discussion is put on hold until the issue is resolved. — Dmitrij D. Czarkoff (talk•track) 19:42, 23 June 2014 (UTC)

Add open source reference to infobox software

Since a lot of software is open source-software these days I'd like to see 'proof' by references to the actual source code directly on wikipedia with a 'source code' link to e.g. the Github or sourceforge pages. A lot of 'open source' projects actually hide the source code deeply within their commercial pages. (:murb: (talk) 10:05, 22 July 2014 (UTC))

Please, draft your proposal in the template's sandbox, or at least describe it more thoroughly. This template does not include a parameter which would denote software as open source – all we have is |license=, which is supposed to be set to the name of license or licensing scheme. — Dmitrij D. Czarkoff (talk•track) 22:18, 22 July 2014 (UTC)

removal of hardcoded image px sizes

I've placed a change in the sandbox (permanent link) to the logo and screenshot image parameters that removes the hard-coded px sizes per Wikipedia:Manual of Style/Images#Size and Wikipedia:Image use policy#Displayed image size. Doing this allows the image to scale based on each users Help:Preferences#Files thumbnail setting (which defaults to 220px). The |upright= setting sets a default scaling that approximates the current hard-coded sizes. For example, the logo setting of upright=.3 results in a size of .3 x 220px = 66px which is then rounded to 70px. This will not affect any articles where the hard-coded size is specified in the template's call, it only allows the hard-coding to be no longer necessary. For articles that long-term require hard-coding, the option exists using the logo_size= and screenshot_size= parameters (but those will be very rare instances). -- Netoholic @ 05:48, 8 August 2014 (UTC)

Oppose. As I said in {{Infobox OS}} case, the result as I observed in the article space, looks inferior.
Seeing why is quite easy:
  1. There is a lot invested in the infoboxes having fixed widths. Significant change in infobox width can distort its layout and the article's layout as well. And mind you, infoboxes are tall too; their distortion has larger magnitude. And not everyone is using 1920×1080 screens. Some people visit Wikipedia on 320×240 phones.
  2. Screenshots are reproductions of subjects that live and die in the confines of pixels. Accommodating dynamic size means many of the existing screenshots must be reuploaded because they are not suitable for just any size between 300px to 408px. (Some of them don't even have 408px width.)
Using a fixed size (here, contentiously labeled as "hardcoding") is not inherently bad. Wikipedia:Image use policy § Displayed image size says "do not do this without very good reason" and here is your very good reason: Practical test unsatisfactory.
Best regards,
Codename Lisa (talk) 10:17, 8 August 2014 (UTC)
"looks inferior" and "unsatisfactory" are not actionable complaints... why do you see it as inferior or unsatisfactor? What specifically? Also, please explain where you're getting this "408px" number. You've mentioned it 3 times in this section, but I don't understand where its coming from. If the screenshot is small, the upright setting will not overscale the image larger than its largest available size. -- Netoholic @ 16:32, 8 August 2014 (UTC)
Hi.
Your proposition involves setting image sizes to frameless with an upright factor of 1.36. Minimum size resulted this way is 163px (=120×1.36). Maximum size resulted is 408px (=300×1.36). Default size is 300px (=220×1.36). (I have set my preference to maximum and I am getting 410px instead of 408px at testcase. Hmmm...)
Most Wikipedia editors will tell you that all of these are okay because most subjects are not computing. A horse looks good at any of these sizes. But, without looking at the address bar, can you tell me which computer program is being shown in this link? Besides, image of a horse is always free and can be millions of megapixels in size. Software inforboxes contain non-free images that are brutally downsized. Infobox can contain images up to 255px (I might have by mistake said 225 somewhere) without its width growing. Now 300px has a huge benefit: Mobile devices with a 320px screen can show a full-width infobox without displaying a vertical scroll bar in full-screen mode.
But I still haven't heard your reason behind all this complicated tampering with code. What's the benefit of all this, besides perhaps some performance impact?
Best regards,
Codename Lisa (talk) 17:25, 8 August 2014 (UTC)
No, my original suggestion was upright=1.25 which at default settings makes the image 280px (upright rounds to the nearest 10px) because that is more typical for images of this proportion. In the most current version I use 1.35 which is the maximum per policy for lead images, which results in a 300px thumbnail (exactly the same as current). There is no "complicated tampering with code"... at least its not complicated to those that actually work on these things, nor is it tampering because it is implementing image use policy and repeating the same settings used across hundreds of thousands of pages already. The benefit is that a user can set there thumbnail size preference and things will scale accordingly. Hard-coded px may look good on your screen, but that means your preference is being imposed on others. Like I said, if there are specific cases where a hard-coded px is needed, you have that option using logox_size= or screenshot_size= but it should only be rare occasions. -- Netoholic @ 17:45, 8 August 2014 (UTC)
Look, I once had a job whose purpose was to make good ideas look ugly and bad ideas look very beautiful. So, I don't feel sympathetic with your words. If I wanted to make the act of using fixed-size look good, I'd use the terms "consistency" and "integrity" to describe it whereas if I wanted to make variable size look good, I do exactly what you are doing: "Consistency" becomes "hard-coding" and "integrity" becomes "freedom". From a pro-fixed-size perspective, your POV "misleads" to "anarchy" because a user with a different "preference" would see everything in Wikipedia wrong and set out to "right the wrong" in good faith, no doubt. What you are doing is branding it as "violation of freedom".
So put all these peacock terms aside and level with me: What problem are you trying to solve? And how are you trying to mitigate the problems that I mentioned?
Best regards,
Codename Lisa (talk) 18:10, 8 August 2014 (UTC)
  • Wrong forum. Provided that indeed many efforts are routinely invested by editors into fine-tuning the screenshots for readability in infoboxes, this question requires discussion. This infobox is not different from rest of them in terms of image usage, and best practices require consistency between pages in regard of presentation, so centralized discussion should precede such changes. — Dmitrij D. Czarkoff (talk•track) 11:03, 8 August 2014 (UTC)
  • I'd like to emphasize that the word "infobox" in your reply is a keyword. Imagine a user wanting to read an article on a 800×600 screen when the image size is 408px. On the other hand, an infobox can accommodate an image as big as 225px without growing.
But although I do think that this issue applies to many infoboxes dealing with software and screenshots of software, I think this issue is to big to go to a centralized discussion without a local test. Going straight to a centralized discussion is like a sportsman wanting to start his career by participating in an international match without having a local success first. Let's test it in the sandboxes of one infobox only and if the issue proved satisfactory, we can promote it to centralized with evidence of success. That way the chance of being shot all the way down is minimized.
Best regards,
Codename Lisa (talk) 12:22, 8 August 2014 (UTC)
  • I disagee. Discussion on this talk page will give no answer to the question whether this change is an improvement or not – the only question we will answer is whether we, the editors keeping this template on our watchlists, like it or not. The opinions of other editors about the worth of this change in this particular infobox will likely be no different from their attitude towards the same change in any other infobox out there, so the only result we'll have from local discussion is the local consensus due to limited participation.
    Let's avoid the path that is prone to creating a drama. Centralized discussion of the very same testcases page will generate much more decisive results due to participation level, and testing this change on other infoboxes must be carried out to reduce the amount of uninformed voting with subsequent problems at implementation stages.
    TLDR: I don't see a point of establishing local consensus on this issue here. — Dmitrij D. Czarkoff (talk•track) 13:02, 8 August 2014 (UTC)
  • When you say "centralized" do you mean "having a large number of participants"? That's okay. As you know, I am very easygoing in these details.
If the subject, however, not restrict itself to one infobox, there is a risk of the entire discussion being shot down with no hope of recoverting. Let me remind you that video gaming articles do not even abide by Manual of Style. Remember what happened to {{VG requirements}}? Trying to conquer Everest without learning to climb a hill is impossible.
Best regards,
Codename Lisa (talk) 14:57, 8 August 2014 (UTC)
  • I still don't see how local discussion can help. In any case the matter can't be resolved here and now bus three of us, and someone will have to present this idea to wider community, including the maintainers of {{infobox video game}}, and all other people you expect to oppose this change on spurious grounds. FWIW: What exactly do you hope to accomplish in this discussion? Particular values for |upright=? — Dmitrij D. Czarkoff (talk•track) 15:27, 8 August 2014 (UTC)
  • No local; restricted in scope. Look, this is very simple: If you introduce a solution and say "this is the magical solution to all problems", someone will just find an exceptional case to say "no, it isn't like that". That's the end of the discussion. But if you say "this solution worked perfectly in area X, here is the proof. Would you accept it in area Y too?" participants have something to go on with.
Best regards,
Codename Lisa (talk) 17:41, 8 August 2014 (UTC)
I know what you are talking about, and I still think that it is wrong forum case. Otherwise I would rather support Netoholic's suggestion in principle. — Dmitrij D. Czarkoff (talk•track) 18:59, 8 August 2014 (UTC)
  • {{infobox video game}} already uses a |upright=1 setting, as they should. My goal is to implement image use policy and MoS guidelines, which deprecate the use of hard-coded image px sizes, because that practice overrides user preferences. The specific value for upright= has more to do with the typical width vs height of the images... since screenshots are most often in landscape, that means an upright= value of greater than 1.0 (portrait style, like video game box art, is typically 1.0). -- Netoholic @ 16:37, 8 August 2014 (UTC)
  • Not for screenshots, no. Only for cover images. The video gaming project instead closely monitors the size of the uploaded cover arts. They chose value that won't hurt. So far, I only Pokémon Red and Blue to have such a big cover and at the same time is not enforcing an image size locally.
I still don't understand what tangible problem you are trying to solve or what tangible improvements are you trying to bring about.
Best regards,
Codename Lisa (talk) 17:41, 8 August 2014 (UTC)
  • This isn't the wrong forum, because the use of upright= is already MOS guideline and image use policy. It's already been implemented on the most widely used templates. It's slowly being implemented across lesser-used infoboxes like this one, Infobox_OS, and Infobox_web_browser. This is just not that controversial anymore... what is controversial is to keep hard-coding image sizes when its no longer necessary or preferable to do so. -- Netoholic @ 16:42, 8 August 2014 (UTC)
  • Wikipedia laws aren't etched on stone tablets. Whenever breaking them is beneficiary, we change them. These specific policies are very flexible; and with the introduction of media viewer, there is definitely going to be a change in them.
What tangible problem are you trying to solve? Or what tangible improvements are you trying to bring about?
Best regards,
Codename Lisa (talk) 17:41, 8 August 2014 (UTC)
  • That module has legacy support for pixel sizes because we're in the middle of a transition, and because there are occasionally rare cases where we have images that fall outside of normal ranges (such as when they are very tall compared to width). This change will be applied here, eventually. -- Netoholic @ 02:58, 9 August 2014 (UTC)
  • No, read again. It warns that the {{image}} template may not work in all cases to implement upright=. This is not what is used here though. Strike that.. that line was added literally yesterday and there is no evidence that there is any issue with upright= in any infobox. -- Netoholic @ 19:35, 9 August 2014 (UTC)
Probably related to the last shitstorm (search for upright). Note the reference to mw:Requests for comment/Square bounding boxes, where this is indication WMF is trying to get rid of upright :( Not sure if this will happen. What we really need is a method for Module:InfoboxImage to access the native width and height of the image, then do some smart math, and voila! But, we shall see if that happens (crossing my fingers). FWW, I agree we should get rid of hardcoded image widths, but it's not clear how to do that in a smart way (yet). Thanks! Plastikspork ―Œ(talk) 19:59, 9 August 2014 (UTC)
OK, let's suppose that there is consensus in community regarding appropriateness of upright usage in infoboxes. That does not address my concern about consistency between different infobox templates and respective settings. This is a massive change that is performed with minimal participation, behind the scenes. This flies in face of the very idea of Wikipedia. — Dmitrij D. Czarkoff (talk•track) 21:09, 9 August 2014 (UTC)
The only real way to get people's attention who don't watch the talk page is to simply make the change, wait for comments/complaints, and then revert if necessary. That's the beauty of WP, you can very easily revert minor changes. Case-in-point being when WMF decided to fuck up the default behavior of frameless. They rolled it back rather quickly after the shitstorm rained down, and that was a change to the backend software, not to a single template. Thanks! Plastikspork ―Œ(talk) 21:15, 9 August 2014 (UTC)
Do you understand that the at the point when people start filing the complaints the change will be old enough for new content to depend on it? There are two ways of doing that:
  1. Ensure maximum participation – place notifications on all infoboxes' talk pages, talk pages of related WikiProjects, Village Pump (yes, this is issue is that big) and stand the discussion.
  2. Carry it out in the dark and make problems everywhere.
The second way is easier; it secures "victory". Be Wikipedia a huge battleground, it would be appropriate. But we are editing crowd-sourced encyclopedia, and whatever uninformed, misguided and whatnot crowd may be, it should be asked first. Particularily with large-scale disruptive changes, which make efforts of many editors obsolete.
TL;DR: I insist that this change must be taken through large-scale discussion. While still holding this opinion, I refrain from further participation in this discussion to avoid breaking our conduct guidelines. — Dmitrij D. Czarkoff (talk•track) 22:21, 9 August 2014 (UTC)
Strong oppose with bad nomination in a patently wrong forum. Netoholic arguments are patently wrong because:
  1. Wikipedia:Manual of Style § Size and Wikipedia:Image use policy § Displayed image size evidently discuss article thumbnail sizes only. Their text does pertain millions of other images shown in message boxes, navigation boxes, user boxes or info box.
  2. The 300px size is supported by a more powerful policy that former two: Wikipedia:Consensus § Reaching consensus through editing. Before 16 June 2013, articles had individually implemented 300px of their own accord. (A global size was not applied.) An administrator then observed this wide consensus and enforced it by adding it to the infobox. As such, 300px fixed size now has the force of a clause of a Manual of Style and can even be added there if there is need.
Wikipedia is not a democracy and "freedom" alone is not a value here. To change this size, Netoholic or any other interested party needs to demonstrate not only the will of the entire community as a whole to change it, but also has to show how it would significantly aid Wikipedia's mission (rather than just being an arbitrary change to piss of certain editors or establish dominance over them.) Fleet Command (talk) 06:12, 10 August 2014 (UTC)
You do realize that this section and proposal was with regards to this template only, right? Many other templates have already converted, and some haven't yet. This is not meant to be a discussion with project-wide ramifications. -- Netoholic @ 06:17, 10 August 2014 (UTC)
Oh, really? Prove it. Fleet Command (talk) 06:28, 10 August 2014 (UTC)
Okay, I was messing with you. You see, there is a policy in favor of community-wide consensus. There is no policy in favor of "other stuff exists". (Actually, there is an essay against it.) What just happened? One moment, you were the torch-bearer of enforcing policies and now your best argument is "other stuff exists"?
But I do agree that "This is not meant to be a discussion with project-wide ramifications". And by that I mean you have to obtain community-wide consensus for changing just this template; another community-wide consensus for changing another; so on, so forth.
Fleet Command (talk) 06:37, 10 August 2014 (UTC)
You must be trolling. You even linked Wikipedia:Consensus § Reaching consensus through editing... a page that describes that consensus can be reached simply by making a beneficial change, and if people agree it is beneficial, they let it stand. No complicated "must get community-wide consensus" grand requirements. My mention that other templates have already been converted is more a comment to indicate the progress of the implementation of image use policy and manual of style guidelines that have already gotten a large amount of community participation. I really don't understand what your diatribe is about... this change generally makes no perceptable change to the majority of users that have their image thumbnail preference set to the default. If someone made the change without commenting here, you wouldn't notice it while visiting most articles (there are some rare cases where the image setting was done manually at the article that may appear different, but thats an exception). Is your goal here like the others to debate using grand statements about gathering consensus, or have you actually looked at the purpose of the upright= parameter? Do you just want to continue to disregard user preferences by keeping this infobox image sizes hard-coded? -- Netoholic @ 06:49, 10 August 2014 (UTC)
But she is arguing that the users' preference is the fixed-size 300px. I don't know about her, but I have no plans to disregard the preference by letting you change it. Your reasoning has changed from clinging to a policy that does not apply here, to the opposite of WP:OSE, and now to a personal attack. And all along you had been faking having the interest of the community at heart while never even trying to demonstrate any benefit aside from complication in arranging the layout.
I am starting to think there is actually a troll here, but it is neither me, nor, Fleet, nor Plastik, nor Dmitrij.
Concerned,
Codename Lisa (talk) 17:23, 10 August 2014 (UTC)
upright=1.35 produces a 300px image by default, while giving users the option to change their personal preferences to make it larger or smaller. -- Netoholic @ 17:38, 10 August 2014 (UTC)

Help please

Hi I am trying to add template:LSR to http://www.mediawiki.org/wiki/Template:Extension but it seems to not be working correctly please could I have some help. 86.135.248.241 (talk) 23:18, 28 September 2014 (UTC)

mw:Template:Extension is part of another project, namely mw: or MediaWiki (see mw:Main Page). mw:template:LSR does seem to be basically the same as en:template:LSR. Can you ask for help at mw:Template talk:Extension? Wbm1058 (talk) 01:28, 1 October 2014 (UTC)
That page has been protected so that only registered users can edit it, so you will either need to register or ask someone to edit it for you (on the talk page). Wbm1058 (talk) 01:35, 1 October 2014 (UTC)

AsOf - take out?

HipHop Virtual Machine has "AsOf" and it isn't clear what it means to readers of the Infobox.. Should it be taken out there or in the Template (maybe not documentation about it)? comp.arch (talk) 15:18, 10 December 2014 (UTC)

Hello! You're totally right, that was confusing in the HipHop Virtual Machine's infobox and I've deleted it. However, it might be useful if someone more experienced with this template could shed some light on the |AsOf= parameter. — Dsimic (talk | contribs) 20:10, 10 December 2014 (UTC)
Hi. Actually, it is according to Wikipedia:As of. The more confusing thing, however, is |data=, especially since it is populated by a bot and is not defined in the template code. Best regards, Codename Lisa (talk) 11:47, 12 December 2014 (UTC)
Thank you for the clarification! Should we expand the template documentation so |AsOf= parameter is better explained? In its current form, the documentation is quite confusing, if you agree. — Dsimic (talk | contribs) 13:18, 12 December 2014 (UTC)

add Owner?

Dec 2014

I feel that there should be an Owner parameter, or someway to designate who or which company owns the software. For example Waze is now owned by Google. There is no way to easily display who owns Waze. Also, in the history on Waze someone has edited in the owner parameter already in hope that it would display. --Frankthetankk 21:49, 19 December 2014 (UTC)

Not done: In Waze, use |author=Waze Mobile |developer=Google. If Google is not developing it, use |developer=Waze Mobile and do not assume that Google acquired everything that Waze Mobile owned, unless you have a source. We have no end of trouble with people who assume Microsoft now owns Symbian OS because it has acquired Nokia. (This assumption is wrong; Symbian is owned by Accenture.) Otherwise, the justification given is not enough. If you have additional justifications, I'll be on around. Best regards, Codename Lisa (talk) 10:45, 20 December 2014 (UTC)
Thank you for your help. That's a great response. --Frankthetankk 19:14, 20 December 2014 (UTC)

Not so Fast

I think that it still might be a good idea to consider having (something like) an "Owner:" field. For example, in the article [about] TaxACT, it is stated clearly in the body of the article (not in the "Infobox software"), that

Blucora, then Infospace, acquired TaxACT in January 2012.[8]

. However, I think (and the [future!] consensus might agree) that it would be useful, to [also] have some kind of appropriate slot in the {{Infobox software}} template, for a place to mention Blucora (and maybe even to "also" mention that Blucora is the "parent company" or successor [or, new name] of what used to be called "Infospace").

If this template had an "Owner:" field, then (apparently) the correct contents for the "Owner:" field, in the article about Symbian, would be "Accenture". (right?) IMHO if someone were to enter something that is not correct, -- (no matter whether in the body of an article, or in an "Infobox software" template) -- then the solution would be for some later editor to come along and make a correction.

It seems to me that the decision about whether the information (OR the error, "if any") belongs (only) in the body of an article, or (both in the body of the article, and) in an "Infobox software" template, is a separate issue from the goal of trying to make sure that the information being provided is correct.

In general (like, in the example of TaxACT), (and maybe also Waze), if the information about the owner is useful (interesting and notable) enough to appear in the body of the article, then IMHO it might be a good idea to include some mention of it, in the {{Infobox software}} template. Just my 0.02. YMMV. Any comments? --Mike Schwartz (talk) 19:54, 26 January 2015 (UTC)

Another Example

The page "Android (operating system)" uses the {{Infobox OS}} template. (Is that similar to {{Infobox software}}?) I noticed that, under "Developer" (as in "Software developer") there, it lists both "Google" and "Open Handset Alliance".

Is that misleading? From what I have read, it appears that "Android" was [originally developed by] an existing company, which became part of "Google" through a purchase transaction -- ("Google" bought "Android" Inc.). (See Android (operating system)#History). ["See also" the account given, [off-site] -- in about 12 paragraphs or so, starting with "By 2005", (here).]

Of course, the continuing development, after it became part of "Google", was occurring under the guidance of Larry Page, and was occurring as a part of Google. But wouldn't it be more helpful (more "correct") for this to be indicated by having an "Owner" field, and listing Google as the "Owner"?

I am not sure whether that topic (the issue of having an "Owner" field, in the {{Infobox OS}} template, is a separate topic from the issue of having an "Owner" field, in {{Infobox software}}. But IMHO the two [topics] are (at least) similar -- if not related. --Mike Schwartz (talk) 21:19, 1 February 2015 (UTC)

Not done: Hi. Apart from the fact that I find your style of writing (which consist of an abundance of redundant links, repeated links, broken links, boldfaces, nested parentheses and nested brackets) is extremely annoying, I don't think you have grasped the concepts of due weight, verifiability and software ownership properly. The more I read, the more I become sure that the request is a can of worms.
Best regards,
Codename Lisa (talk) 09:47, 2 February 2015 (UTC)

Discontinued parameter

I believe this parameter shouldn't exist or be repurposed to show the date of discontinuation. Since there's already a 'status' parameter where the software discontinuation can be (and is) shown, it's redundant. Not to mention, the 'discontinued' parameter replaces (for some reason) the 'latest stable release' which is useful information to the reader. LusoEditor (talk) 14:21, 7 March 2015 (UTC)

"Original authors"

I think that the term 'Original authors' is misleading. Especially in Open Source projects can be started by one person, taken over a by another person which over time replaces the whole content of the original author. Still that first person thinks he/she is the original author - that leads to conflicts. Better would be 'Main authors' or just 'Authors' (as the tag indicates) Curlybracket (talk) 12:17, 11 June 2015 (UTC)

Released parameter

(Note: Resurrected from Archive 3 by —SamB (talk).)

IMO there should be separate parameters for the first public release and the first stable release. The current released parameter is misleading, as "initial release" implies that it refers to the first release, while the template documentation specifies that it should be used for the 1.0 release or the equivalent. -- Gordon Ecker (talk) 02:01, 12 December 2008 (UTC)

I tend to agree, and I *certainly* think that we should have field(s) for the corresponding version number(s) of such early release(s) as we have dates for. The names first preview version, first preview date, first release version, and first release date would seem appropriate, with bolded text about the "1.0" bit. It would probably be a bad idea to insist on these "version" fields actually appearing, though, as proprietary commercial software could easily fail to advertise a version in its initial release. —SamB (talk) 19:57, 27 April 2015 (UTC)
Hi.
First about the date: Why don't we have a Development started instead? Most projects keep a better track of when they started than when they released the first public unstable release. (I feel it is deliberate. It is nothing they are proud of.)
As for the version number, I think it is worthless. Why must anybody care that the first version ever of a computer program was, say, 0.93.12.5864165? What does this tell you? It is indiscriminate info, something that nobody can do anything useful with it.
I remember something like this was once proposed, and one of my colleagues, Patrick87 vehemently contested. Perhaps this esteemed colleague would care to participate?
Best regards,
Codename Lisa (talk) 20:43, 27 April 2015 (UTC)
Instead of "development started", I propose "alpha release". Right now, we have an absurd situation over at Apache Hadoop where it says its initial release is December 20, 2011. Yet Cloudera released its 1.0 in 2009! Really, there needs to be an "alpha release" field which would be populated with January 11, 2007 for its 0.10 version, the first Apache version (i.e. ignore Cutting's internal releases at Yahoo!). — Preceding unsigned comment added by Michaelmalak (talk • contribs) 16:44, 11 June 2015 (UTC)

Add the "Predecessor" and "Successor" Parameters

I think that this template would be neater if these parameters were included. Some software are successors of other software just as some hardware are successors of other hardware, so let us have those parameters for this template as well. Gamingforfun365 (talk) 00:18, 21 June 2015 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. --Redrose64 (talk) 13:32, 24 July 2015 (UTC)

Consensus

Okay. My idea is to have those parameters added; I believe that it is a good idea to provide information which regards what software came before and after another software. This is a little like the templates for hardware and operating systems, and I would not have a problem with the parameters for this template. For examples, id Tech 4 is the predecessor of id Tech 5, Source is the successor of Goldsource, and Microsoft Office 2007 is the predecessor of Microsoft Office 2010 (yes, they all are software). Unless there be a reason to say "No." to it, I would approve of these two parameters. Gamingforfun365 (talk) 23:29, 16 August 2015 (UTC)

Wikidata

Are there plans to acquire version information from wikidata? IIRC the russian Wikipedia already does this: https://ru.wikipedia.org/wiki/TortoiseGit tHis way lots of information only has to be edited once instead of 100+ for e.g. Firefox. --MrTux (talk) 20:15, 26 August 2015 (UTC)

Hi.
Our existing articles are too complex for that. Different languages of Wikipedia do have different approach about when to include latest preview versions and whether the release date means release to manufacturing date or general availability date. In addition, are we supposed to include "8.1 Update 1" in Wikidata or "8.1 обновление 1"? How are we going to handle multiple version numbers in Wikidata? e.g. Template:Latest stable software release/Adobe Acrobat? (Fortunately, the last one is easier: I leave it to be handled locally.)
I have already implemented website URL acquisition from Wikidata. But even the implementation of size acquisition has stomped me. i.e. How are supposed to show "101 MB" when the word "MB" needs to be linked to the local version of Megabyte in each Wiki?
Best regards,
Codename Lisa (talk) 23:35, 26 August 2015 (UTC)

Duplicated parameter

Change this: 

| label14    = [[Software license|License]]
| data14     = {{{license|}}}
| label15    = [[Software license|Licence]]
| data15     = {{{licence|}}}
...
</noinclude>

To this: 

| label14    = [[Software license|License]]
| data14     = {{{license|}}}
| label15    = [[Alexa Internet|Alexa]] rank
| data15     = {{#if:{{{alexa|}}}|{{nowrap|{{{alexa|}}}}}}}
| label16    = Website
| data16     = {{#if:{{{website|}}}
                  |{{#ifeq:{{{website|}}}|hide||{{{website|}}} }}
                  |{{#if:{{#property:P856}}
                     |{{URL|{{#property:P856}}}}
                   }}
               }}
| label17    = [[Technical standard|Standard]](s)
| data17     = {{{standard|}}}
| label18    = As of
| data18     = {{{AsOf|}}}
}}<noinclude>
{{documentation}}
</noinclude>

'label14' and 'label15' are duplicated. --Namoroka (talk) 14:13, 13 September 2015 (UTC)

Done, but now I'm curious to know why it wasn't being printed twice. Alakzi (talk) 14:18, 13 September 2015 (UTC)
@Codename Lisa: Could you please explain the revert? Alakzi (talk) 14:25, 13 September 2015 (UTC)
Oh, it's spelled differently. They could still be merged into a single field. Alakzi (talk) 14:31, 13 September 2015 (UTC)
@Alakzi: Oh, good! You discovered half of it on your own, sooner than I can write here. Bravo! Now, discover the other half: Why the must not be merged?
Best regards,
Codename Lisa (talk) 14:35, 13 September 2015 (UTC)
Well, sod off with that attitude. Best regards. Alakzi (talk) 14:36, 13 September 2015 (UTC)
@Alakzi: Impeccable precision is a mandate for a template editor; and carelessness and rudeness are the worst combinations. So, next time, instead of "sod off", try "Sorry for committing a breaking change that may impact over 100 articles." This is the second time that I am complaining about your carelessness. If you can't handle the requirements, maybe your permission should be removed.
Concerned,
Codename Lisa (talk) 14:45, 13 September 2015 (UTC)
Being human, sometimes I make mistakes. I do not need to apologise for being human. If you are concerned about my use of TE, please file a complaint at WP:AN. Taunting me repeatedly is what I'd call rude; telling you off for it is but a natural reaction. Alakzi (talk) 14:51, 13 September 2015 (UTC)
I said "Bravo"! That's not a taunt. That's an expression of appreciation. The natural reaction would be "you are welcome!" Now, back to discussion: I now assume you know why you are reverted? —Codename Lisa (talk) 14:58, 13 September 2015 (UTC)
As were "that's all I can say" and "now discover the other half", I presume? Please don't try to pass off your condescension as sincerity. And why are you asking me whether I know, when you've already acknowledged my 14:31 comment? Alakzi (talk) 15:09, 13 September 2015 (UTC)
Exactly. I could have instead offended you just as you did to me. So, don't mistake politeness for condescension. But what you did was a huge mistake with grave consequences; you should not expect royale treatment. —Codename Lisa (talk) 18:09, 13 September 2015 (UTC)
I believe I've made it abundantly clear that you have offended me with your "polite" snark. Alakzi (talk) 18:36, 13 September 2015 (UTC)
Hello to both of you! Could we, please, leave the egos aside and focus on what we're here for, which is making Wikipedia better? I know, people make mistakes (count me in first) and that's perfectly fine, but other people are there to fix those mistakes, and we're all here to learn from both our and others' mistakes. It would be the best to just shake hands and move along, if you agree. — Dsimic (talk | contribs) 23:56, 13 September 2015 (UTC)
P.S. I was writing an explanation here, but twice today, I was stopped by the edit conflict error. Of course, in templates, one must always revert first. Best regards, Codename Lisa (talk) 14:38, 13 September 2015 (UTC)
Was it an explanation, or was it another taunt? Alakzi (talk) 14:42, 13 September 2015 (UTC)

It goes to a completely different page. Maybe that wasn't the case back when the link was inserted, I don't know, but now the link is / has become a detriment. — Preceding unsigned comment added by 82.139.82.82 (talk) 17:05, 21 September 2015 (UTC)

Wikidata Property:P277

Hello, would it be possible to add this property at the line of "programming language"? Actually if the template hadn't been protected, I would have done it with a Lua module that automatically adds some hyperlinks, like I did on the French Wikipedia: the result is fine as well. JackPotte (talk) 12:33, 10 October 2015 (UTC)

Hi.
Yes. We can definitely start working on it. Can you please explain briefly how it works there? I assume it is the {{Format}} that does it? How does it parse C# into [[C Sharp (programming language)|C#]]?
There is also a big concern: Here, in English Wikipedia, we are concerned that people just put in "C / C++" when they actually don't know what the programming language is. Sometimes, they do provide a source, but when we investigate, that source also has been telling us its own assumption. Is it possible to important the Wikidata reference as well?
Best regards,
Codename Lisa (talk) 00:04, 11 October 2015 (UTC)
Wikidata can attach some references to each property.
Concerning the internal links, the French Wikipedia as many others actually uses the template fr:Modèle:Wikidata, which I've imported to the French Wikibooks yesterday: it's probably too long, so I'm still searching for an equivalent here.
And even without the internal links it's not simple: after this modification, the developper parameter displays correctly in BeOS, but not the license one, which showed a Wikidata code, instead of its text, before this edition. JackPotte (talk) 14:41, 11 October 2015 (UTC)

GUI vs. CLI

Where to state that the software has a command line interface or a graphical interface? Nemo 09:07, 26 October 2015 (UTC)

Hi.
The screenshot in the infobox supplies this information already. So, as the creators of the infobox have correctly decided, adding separate fields for them is redundant. Also, having a field for this information can be misleading: Some apps have both GUI and CLI aspects; servers apps are mostly background apps, services or daemons and shouldn't be classified based on their user interfaces. Software frameworks are for all intents and purposes invisible.
Best regards,
Codename Lisa (talk) 12:15, 28 October 2015 (UTC)

Both the last release (label4) and preview release (label5) parameters link to software release life cycle. The article doesn't discuss directly the topics. There's really no need to link to the article. Please just remove it. Thanks. I don't watch this template so please ping me with the response. Thanks. Walter Görlitz (talk) 04:25, 22 October 2015 (UTC)

Not done: Walter Görlitz, please establish a consensus for this alteration before using the {{edit template-protected}} template. Painius  11:16, 22 October 2015 (UTC)
Opppose removal of the link. Actually, the software release life cycle article directly discusses both. Information about "Latest release" can be found under software release life cycle § Release. Information about "Latest preview" can be found under software release life cycle § Stages of development. Best regards, Codename Lisa (talk) 15:46, 22 October 2015 (UTC)
You’re wrong. It doesn't directly discuss either directly. But fine. If you don't actually want to do the work, I’m fine with it. I'll make it more obvious there. Walter Görlitz (talk) 05:02, 29 October 2015 (UTC)
And by "wrong" I mean the term "stable release" does not appear in the article. Anywhere. Also your term, "latest release", is oddly missing from the article, probably because it's not a formal software development term, although it is used informally. Walter Görlitz (talk) 05:07, 29 October 2015 (UTC)
Nice save, Walter. I agree with the part that "Stable release" does not appear in the "software release life cycle" article. It has long been one of my grievances: The infobox is an amalgamation of two different release cycle schemes.
  1. The traditional release cycle is highlighted in the "software release life cycle" article. In this cycle, each time a new major version comes out, there are alpha and beta tests. The software compiled for these stages are called "preview builds". (Hence, latest preview.) When the version is finalized, there is a release. (Hence, latest release.) The release could be either physical, in which case there is a release to manufacturing and a general availability. It can also be web-based, in which case there is only a release to web. It can be both.
  2. The rapid open-source development cycle is not highlighted in the "software release life cycle". In this cycle, the development team consistently compiles new builds. Some are strictly for test purposes and must not be used by ordinary users. These are called "unstable builds". Those suitable for the ordinary users are called "stable builds". In addition, in this cycle, there is stage in which the major version number is zero. At this stage, the product is unsuitable for production use.
IMHO, the infobox must not use this mangled scheme. I think I've made a proposal in the past about this but I think it was rejected on the ground that—
Well, I don't know why it was rejected.
Best regards,
Codename Lisa (talk) 18:35, 29 October 2015 (UTC)
And one further question: where's the discussion to add the spurious link? I’d be glad to see who supported the addition, when it was added and what the stated of the linked article was at the time of the original link. Walter Görlitz (talk) 05:11, 29 October 2015 (UTC)

Bug in inclusion of this template in Music Player Daemon

The "Stable release" field in the current version of that page (permalink) is broken; it shows wiki markup for the inclusion of Template:LSR. Can someone with more wikisyntax knowledge have a look, please? -- 178.24.107.75 (talk) 16:11, 15 November 2015 (UTC)

 Fixed. Hello. The problem was in {{Latest stable software release/Music Player Daemon}}; I fixed it in revision 690780012. Best regards, Codename Lisa (talk) 17:26, 15 November 2015 (UTC)

Discontinued after only one release…doesn't show up

I'm looking at Emojli which only had one release before being discontinued, and {{{discontinued}}} seems to be ignored in this case. It would be nice if this worked properly, and it would be even nicer if setting {{{discontinued}}} to the appropriate date did something meaningful. Any thoughts? TIA HAND —Phil | Talk 11:02, 4 December 2015 (UTC)

Not done: Hello, Phil. Emojli article is using |discontinued= incorrectly, without regard to what is said in the documentation page. This parameter only accepts "yes" and "no" and only has effects when |latest release version= is set. To specify discontinuation date, please use |status=. Best regards, Codename Lisa (talk) 03:27, 6 December 2015 (UTC)

Add maintainer field

Maintainer field is missing in this template. Because of this developer field is wrongly used. For example, in iproute2 developer field is used for maintainer but its maintainer is not the only developer of iproute2 (see iproute2's stats). Also Version control would be nice.--RamachandraTimoteus (talk) 20:36, 31 December 2015 (UTC)

Hello, RamachandraTimoteus
Please clarify which of the three definitions of "maintainer" do you mean. If you know more than three, or simply don't know which three I am talking about, please write the definition in your own words.
Best regards,
Codename Lisa (talk) 16:08, 1 January 2016 (UTC)
Hello Codename Lisa,
I am actually unaware of the three definitions. So this is my understanding of "maintainer":
Maintainer of open source project is a trusted person performing tasks that cannot be done collaboratively.
--RamachandraTimoteus (talk) 18:13, 1 January 2016 (UTC)

Latest updates

Is this field really meant to supply every incremental update? Wouldn't it be more encyclopedic to limit the field to every "significant"/"major" release (rather than every release)? – czar 14:38, 18 September 2015 (UTC)

Hi. I agree with your general concept but can you define an inclusion criteria?
Best regards,
Codename Lisa (talk) 18:25, 21 September 2015 (UTC)
Every release regarded by secondary sources (or at least by the developer) as a "major" release. Usually this would be landmark releases that come with press releases (4.0, OS X 10.11, etc.) The point is not to update the infobox with every 0.0.1 update, which is not encyclopedic. @Codename Lisa, eh? czar 05:19, 30 October 2015 (UTC)
Hello again. By my experience, secondary sources do not usually care or feel obliged to call something "major" or "minor" unless it is pertinent to a context they try to establish.
Also, since the last time we communicated, another daunting problem has come to my attention: How are you going to treat violations of this principle? Revert the violating edits? Reverting unreferenced allegations and asking for sources could be plausible, especially since I have seen version number vandalism. But reverting someone who reflects a very recent release and saying "the last stable version came out a years ago"? That has "lamest edit war" written all over it.
Best regards,
Codename Lisa (talk) 22:20, 30 October 2015 (UTC)
As opposed to its current usage where it is replaced for every version change? While a primary source might refer to its release as "major", a secondary source doesn't need to say that explicitly—if they are covering a new release, it assumed that the new version is a major release. Another option is dropping it from the infobox altogether. czar 03:06, 31 October 2015 (UTC)
There is a big difference between things that must be and the things that can be. If the community as a whole is decided to do an edit for every version change, you either need to educate them to stop, have executive power to enforce a preventative measure, or revert them every single time. I tell you, I am not going to do the latter. A reversion is taken extremely personally.
As for dropping it from the infobox, I pretend I didn't hear you.
Best regards,
Codename Lisa (talk) 20:10, 31 October 2015 (UTC)
  • I still think this is an easily rectifiable problem that bloats the infobox. WP is an encyclopedia and not the place readers should be going to find the latest iOS beta number. There are other reference sources for that. Changing the guidance to list the latest "major release" would be an obvious step in the right direction. Enforcement is a chicken & egg problem—start using the infobox as advised and the rest works itself out. czar 01:20, 2 January 2016 (UTC)

Default logo size

How about increasing the default logo size from 64px to 200px or so when there is no screenshot image? Have a look at the last few revisions of Handy Backup (edit | talk | history | protect | delete | links | watch | logs | views) as an example; I think it would be nice if this happened automatically. -- John of Reading (talk) 09:57, 16 February 2016 (UTC)

Hi.
Quite frankly, that's the worst idea I have heard today. The consequence is: One good-faith rookie editor adds a screenshot and ends up distorting the infobox logo size.
I don't know why people suddenly stop thinking when it comes to infobox logos? Where should I start? First, the parameter should have been called |Icon=, not |logo=. (All Windows, OS X and iOS apps have icons, but few have logos.) But then, there are times that people use the company's logo on a software article. Again, sometimes, the manufacturer uses a fancy text as a heading in its website; people snap that and call it a logo! Some other times they put a splash screen instead of logo. (If I remove it and say "this app has no logos", they get offended.)
Is it very offensive if I asked my fellow editors (whom I love, by the way) to spend a few more seconds thinking?
Best regards,
Codename Lisa (talk) 13:59, 16 February 2016 (UTC)
@Codename Lisa: I agree that changing the default logo size isn't desirable, but I think describing it at "the worst idea I have heard today" and accusing John of Reading of having "suddenly stop[ped] thinking" is entirely unnecessary and combative. You could have made your point just as well without resorting to insults. Your opinion is obvious to you, but implying it ought to be obvious to someone else when they make a good faith suggestion isn't constructive. —me_and 19:03, 18 February 2016 (UTC)
@Me and: Please don't put words in my mouth! I addressed John of Reading's idea not his personal self. I explicitly wrote "whom I love, by the way", yet you ignore that?
That said, every problem requires a tone of speech proportionate with that problem. And the problem of infobox icons (not logos!) is big.
Best regards,
Codename Lisa (talk) 11:05, 20 February 2016 (UTC)
Stop trolling... Do you insult your loved ones? Slapping someone in the face an telling them one loves them, doesn't make it true. --Patrick87 (talk) 21:56, 20 February 2016 (UTC)
Wow! Look! It's "me_and" and "Patrick87", two people who had a past disagreement with me. Looks like there are only three persons missing from this revenge party.
Say whatever you want. I commented on the contribution only and I am not sorry. Going to don't feed the Avengers mode.
—Codename Lisa (talk) 12:53, 21 February 2016 (UTC)

Template-protected edit request on 19 February 2016

I noticed on Cydia that the screenshot and the caption are aligned to the left. I know it's a minor change, but could someone make them centered?

I previously did this on {{Infobox dot-com company}} by adding |contentstyle=text-align:center to {{hidden begin}}. See the edit here. Manifestation (talk) 22:06, 19 February 2016 (UTC)

Done. Codename Lisa (talk) 12:58, 21 February 2016 (UTC)

Multiple stable software releases template

What do you think about adding support for Template:Multiple stable software releases, as has been done to Template:Infobox web browser? The last time the Multiple stable software releases template was discussed here was in May 2014, but that discussion did not provide any clear result. --Dodi 8238 (talk) 14:49, 15 April 2016 (UTC) [edited 18:29, 15 April 2016 (UTC)]

  • Work in progress; bug already found. When I am done with the sandbox version, I am going to need community support to implement this. As a TemplateEditor, I can't just implement a change that I like if it has been contested in the past. Best regards, Codename Lisa (talk) 09:15, 28 April 2016 (UTC)

Wikidata Version

The website-field already uses Wikidata if no local value is given. Can we enhance the template to also use Wikidata for the latest version-number and -date if no local value is given? This is already used that way in the german Wikipedia. -- MichaelSchoenitzer (talk) 00:12, 6 March 2016 (UTC)

Hello, Michael
No, we can't.
As discussed before, we still cannot do this in a way that does not prevent or deter the article from becoming Featured Article. Featured articles must be well-referenced and use a consistent citation style. (To be fair, this is a reasonable expectation from any article.) This is not yet possible with imported WikiData properties and values. Even sometimes we override the website coming from WikiData because it must match our expectations highlighted in MOS:WEBADDR.
Best regards,
Codename Lisa (talk) 08:59, 6 March 2016 (UTC)
Most articles are best served by having the best available information, which can be achieved via Wikidata rather than by updating a mere number in N places (template subpages, infobox, comparison tables etc.). If some article happens to feel worsened, that article should be free to pass a parameter to disable the Wikidata import. Other than that, importing data and references from Wikidata is the only reasonable way to improve quality. Nemo 16:01, 1 May 2016 (UTC)
I am afraid you are unduly super-optimistic. Adding facilities to import from Wikidata only serves to turn those N places into N+1 places and is sure to violate Wikipedia:Verifiability 100% of times. Wikipedia is an immensely successful project; Wikidata is only a bad idea.
Best regards,
Codename Lisa (talk) 17:28, 1 May 2016 (UTC)
@Nemo bis: Actually, just the opposite. Wikidata right now is more in collection mode, and is using the templates to pull data from wikipedia infoboxes into wikidata. The template can be changed to provide a failsafe (displaying wikidata content when a parameter is undefined), but its preferable right now for the parameters to be filled out. -- Netoholic @ 21:51, 1 May 2016 (UTC)

Successor & Predecessor

Certain software develpment discontinue and new ones are created off the code or philosophy or the API of the old one. It would be good to have a field to link successors and predecessors. Lord Bharath Bhushan Lohray (talk) 14:14, 7 May 2016 (UTC)

Software publishers

Hi, I was wondering if someone could implement a software publisher field, to be used only if different from developer. E.g. newer RPG Maker versions are published by Degica, developed by other companies, or XSplit, which's Steam version is being published by Devolver Digital, developed by SplitmediaLabs, etc. 88.77.28.197 (talk) 18:36, 13 June 2016 (UTC)

Change "Last release" to "Final release"

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)

Unexpected line break

Infobox software/Archive 6
Stable release
1.0 / 25 December 2024

Hi.

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)

What's the reason for the restrained Wikidata usage?

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)

Hi.
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)

Bug(s) with getting website from Wikidata

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://wiki.riteme.site/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)

UX: Expandable/collpasable screenshot component is confusing

This is a user experience critique of the user interface.

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

Example

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

https://wiki.riteme.site/w/index.php?title=Google_Keep&oldid=735889480

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

  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. :)

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

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

Repository URL

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: 

<tr>
<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>

80.221.159.67 (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://wiki.riteme.site/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)
WITHDRAWN
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?

Demonstration of what will happen to the infobox
Source code repository

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

Caveats:

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

Poll

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)

Discussion

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
Repository

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 URL (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 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 URL (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 95.156.216.107 (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? 98.244.77.73 (talk) 08:35, 9 September 2016 (UTC)
Probably accuses me of edit warring on another article on which I have no diff! 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

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

Benefits:

  • 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.

Caveats:

  • 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

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 codehttps://github.com/WhisperSystems

Benefits:

  • 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.

Caveats:

  • 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.

Source code

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)

Hi.

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

Any ideas as to what to do?

@Waldir:

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)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Infobox_software/Archive_6&oldid=1138087695"