Template talk:Infobox website

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Websites / Computing  (Rated Template-class)
WikiProject icon This template is part of WikiProject Websites, an attempt to create and link together articles about the major websites on the web. To participate, you can edit the article attached to this page, or visit the project page.
 Template  This template does not require a rating on the quality scale.
Taskforce icon
This template is supported by WikiProject Computing.


What does IncreaseNegative Negative increase and DecreasePositive mean? How can increase be negative and vice versa?--Mika1h (talk) 20:23, 9 October 2016 (UTC)

Yes, indeed the increase can be negative. For example, in a car race, the best becomes the first. The worse-performing the racer, the higher ranking he (or she?) gets.
In Alexa, the top website is #1.
Best regards,
Codename Lisa (talk) 08:07, 10 October 2016 (UTC)

Is Alexa even accurate nowadays (if it ever was)? Trivialist (talk) 10:39, 22 April 2017 (UTC)

... as long as it isn't wildly inaccurate and there isn't a better replacement...
What made you ask this question? FleetCommand (Speak your mind!) 04:26, 24 April 2017 (UTC)

IP address field[edit]

This template has a field for a site's IP address: this is now amazingly out of date and essentially meaningless. IP addresses of websites change all the time: frequently, a single site has multiple A records associated with it, often via a CNAME, the use of HTTP redirects can lead to the address of the server serving the root HTML page being different from the server that took the initial HTTP connection, and, after the delivery of the root HTML page, the content of modern webpages generally loads from a large number of endpoints at once, including CDNs. I propose that we delete this field, unless there is evidence that it still has a useful purpose. -- The Anome (talk) 00:22, 15 December 2016 (UTC)

It goes without saying that the field should only be used when there is a static, relatively stable IP address associated to the site — preferably backed by reliable sources. The field is both useful and put in use on a number of articles, albeit not many — but that it is used rarely is not an argument to remove it. It is especially relevant where DNS-level censorship exists and there is a known official IP address associated with a site. Carl Fredrik 💌 📧 00:34, 15 December 2016 (UTC)
Can you give an example of this where it might actually be useful to someone? If someone is bothered enough to do DNS blocking, IP blocking is just as easy to do. -- The Anome (talk) 11:22, 16 December 2016 (UTC)
Now let's not pretend this is about hypotheticals, and let's not forget that Wikipedia isn't only used by people in western democracies. Certain states profusely deploy DNS-blocking, and while they also use IP-blocking it is far less pervasive. The EFF does significant work to map these phenomena, but by definition it is difficult to get stats from countries with significant blocks in place. If we can aid as much as one person in accessing information that is more than enough reason to use the field. However, I'd be happy to explain in the documentation that this is for these specific use cases. Carl Fredrik 💌 📧 12:09, 16 December 2016 (UTC)
Isn't that basically an invocation of WP:RIGHTGREATWRONGS? --Izno (talk) 17:08, 16 December 2016 (UTC)
Huh? Obviously not. It is clearly a utility argument. FleetCommand (Speak your mind!) 17:29, 16 December 2016 (UTC)
You know, I find in Wikipedia, it is very difficult to remove something just because it is not useful, unless you can demonstrate there is a harm in it. FleetCommand (Speak your mind!) 16:49, 16 December 2016 (UTC)
The only harm would be deliberate misuse adding this to sites like google.com or yahoo.com, where there is no single static IP-address available. As for righting great wrongs, the fact that it purports to do some good is not an argument against using it — while on its own it isn't an argument for it. However when sites have official publicized IP-addresses, like a number of DNS-servers have: notably and for Google DNS it is clearly useful to provide this information in the infobox. I am not entirely sure which articles use this parameter, to understand where it is useful it may be good to show this. Otherwise as Fleetcommand says, it seems reasonable to demand evidence of harm before removing it. So far there is not even the suggestion of potential harm, merely a statement that it is useless (for you). That isn't enough… Carl Fredrik 💌 📧 17:41, 16 December 2016 (UTC)
The onus of proof for keeping a feature lies on its proposers. I still haven't seen one single actual use of this parameter that uses it to provide encylopedic information that is backed up by reliable, third-party sources, and I'm still waiting for those who advocate keeping this field to provide it. Google DNS is not such a case: it's not a website. As for justification: since Wikipedia is not a vehicle for collating WP:INDISCRIMINATE information, any non-notable uses of the field should be removed; and any field which is not used for any encyclopedic purpose is just cruft that should be removed as not furthering Wikipedia's mission. As for harm: I can name at least one, trivial, harm. The only use of this field I've seen was to provide an IP for fuckingmachines.com on the infobox for that site. A quick DNS dig reveals that it was wrong. That's a piece of bogus information on Wikipedia. If something does even the most trivial harm, but no actual policy-compliant good, that's justification enough to remove it. -- The Anome (talk) 18:07, 16 December 2016 (UTC)
I am afraid I have to disagree with you here. Metadata of something is never indiscriminate. (Try (not) having due weight though.) And a WhoIs lookup is always from a third-party source not interested in the matter. And the onus of keeping a feature is definitely not with the purposer as far as WP:EDITCONSENSUS goes; once a feature is added and was not immediately contested, it is assumed to have weak consensus in its favor that can be overturned by explicit consensus to remove. FleetCommand (Speak your mind!) 18:31, 16 December 2016 (UTC)
  • Per Carl. With the wording strengthened in the template documentation to highlight that this is only to be used if the IP is the regular mode of access for the site, rather than DNS, and that this is vanishingly rare. Andy Dingley (talk) 18:29, 16 December 2016 (UTC)
    • Can you give an example of this "vanishingly rare" practice? I can't think of a single example. Also, on a technical point, Whois lookups do not give IP addresses. Perhaps you're thinking of DNS queries via a tool such as dig? If so, the lookup is not WP:RS. -- The Anome (talk) 01:39, 18 December 2016 (UTC)
That you cannot come up with examples is really not an argument. I previously asked if there was a way to see what articles actually use this functionality, and so far there hasn't been an answer. I have the examples of a number of DNS services that exist, and even though that benefit is small it is still infinitely greater than the harm from a hypothetical case of misuse. Carl Fredrik 💌 📧 15:36, 19 December 2016 (UTC)
P.S. Also clarify why a DNS-query to an official DNS server does not abide by WP:RS? I understand that it may not indicate that this is the stable IP, but there is no reason why it constitutes WP:OR if the source is given. Carl Fredrik 💌 📧 15:37, 19 December 2016 (UTC)
I think it's really strange that so many people are vigorously defending the existence of this field in the template, without a single example of a valid use. DNS services, for which stable IP addresses are actually useful and reported by WP:RS, are not websites, and so this field does not apply to them. IP addresses change all the time in modern web deployments, and many sites are hosted in such a way that accessing the site by just the IP address is not going to be useful at all. Most of all, it's a redundant feature: if you want a fresh, valid DNS lookup, your browser will supply one for you, in a far more reliable way than looking it up on Wikipedia. And even if you are subject to DNS spoofing or interception, getting the IP address from Wikipedia is unlikely to be helpful, as IP addresses can be spoofed just as easily as DNS lookups. -- The Anome (talk) 21:49, 19 December 2016 (UTC)

TOR urls in the url field[edit]

There are some sites (e.g. DuckDuckGo) where a text Onion url has been added to the url field in addition to the official link. This would appear to violate the definition of the field as it calls for an WP:ELOFFICIAL link. Also WP:ELMINOFFICIAL and WP:ELNO #7. Onion links are also in the blacklist[1]. Now, these are not links but text, since the blacklist will normally prevent adding an actual link. But, this appears to be a method of circumventing the blacklist as well as violating the definition of the field. Question is, are these valid uses of the infobox? I think not. Objective3000 (talk) 12:56, 26 March 2017 (UTC)

Since it is clearly a circumvention of what is forbidden, it is forbidden. And such extraneous info disrupts the field's machine readability.
Best regards,
Codename Lisa (talk) 13:09, 26 March 2017 (UTC)

Proposal: |client os=[edit]


Lots of websites these days have native client apps. Off the top of my head: Google.com, Bing.com, Stack Overflow, Pastebin.com, OneDrive, Google Drive, LinkedIn, Facebook, Twitter, DropBox, Mega.co.nz, Google Translate, Bing Translator, etc.

So, is it a good idea to add a |client OS= to the infobox? The label would read: "Client app runs on".

Best regards,
Codename Lisa (talk) 10:24, 10 April 2017 (UTC)

Template-protected edit request on 15 May 2017[edit]

Please change the sizedefault= value in the image= switch to 64px per the documentation. If it is supposed to be 250px then the documentation needs to be changed. However, most logos do not look good at that size and become very distorted. Majora (talk) 23:19, 15 May 2017 (UTC)

Not done: @Majora: 64px is not correct; the documentation should be corrected. Also, see #Edit request 8 October 2016. — JJMC89(T·C) 02:20, 16 May 2017 (UTC)