Template talk:Official website/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Template not recognising full URL

I'm trying to add the English language version of their website to Sudanese British Society of Disabled People. The link is http://www.sudanesedisabledpeople.org/index.php?lang=en. But if I add that, as {{official website|http://www.sudanesedisabledpeople.org/index.php?lang=en}} I get the errror message "No URL found. Please specify a URL here or add one to Wikidata". If I link to the default Arabic language version, http://www.sudanesedisabledpeople.org/index.php, there is no problem. I'm sure I've added similar URLs in the past without a problem. I've got round it by using [http://www.sudanesedisabledpeople.org/index.php?lang=en Official website], and have commented out the templatised version. Can anyone help? PamD 14:09, 15 February 2016 (UTC)

@PamD: There's an equals sign in the URL, so everything before the equals is being interpreted as the parameter name. Try using {{official website|1=http://www.sudanesedisabledpeople.org/index.php?lang=en}} or {{official website|URL=http://www.sudanesedisabledpeople.org/index.php?lang=en}} instead. Best — Mr. Stradivarius ^{♪ talk ♪} 14:21, 15 February 2016 (UTC)

@Mr. Stradivarius: Thanks, works fine. I thought I'd tried that, but perhaps had used "url=" and not "URL=" - the lower-case version doesn't work. Have fixed the article. PamD 14:33, 15 February 2016 (UTC)

Wikidata links and metonymical articles

I've recently been going through the Category:Official website not in Wikidata listings trying to migrate official websites over to Wikidata. It is quite a big task (~12,860 articles at last count). One issue I've found is that there are a great many articles in that category that have an {{Official website}} on Wikipedia but shouldn't have an official website (P856) on Wikidata. Just a few samples:

• Tokyo Sports Film Award for Special Film Award
• 2015 Much Music Video Awards
• 1996 Conference USA Men's Soccer Tournament

There are plenty more like this. They tend to be pages listing either the winners of an award category, or the results of a sports tournament. The official website listed at the bottom is related only indirectly to the subject. They'll tend to be a website about the whole tournament or awards rather than the individual category or year. On Wikidata, this would be better represented by saying that, say, the "1996 Conference USA Men's Soccer Tournament" is part of (or an instance of) the "Conference USA Men's Soccer Tournament", and that the latter has an official website. The former does not because the former is only part of the latter.

There seems to be a few solutions here:

1. We transfer links over regardless. The article about the component part ends up having a Wikidata link of the whole of which it is part. This means we can use Wikidata for tracking this, but it also means that we are saying on Wikidata that some topic that doesn't actually have a directly related official website does.
2. We add functionality that allows us to follow "part of" relations in Wikidata and retrieve the ultimate official website by a process of following one's nose.
3. We ignore them and worry about it at some point in the future.
4. We add an argument to {{Official website}} which lets us say "just ignore Wikidata". This would make it so that if there is an {{Official website}} on English Wikipedia but no P856 property on Wikidata, it would not appear in Category:Official website not in Wikidata and other similar categories. We could then apply this argument ("wikidata=ignore" perhaps?) to official websites that do not need to track Wikidata.

Another issue is where people use {{Official website}} routinely throughout an article. Earlier today, I removed some examples of this from Apple community. This kind of inline use of {{Official website}} should be discouraged, but in the rare cases where it is needed (say, a long list article where each section is the canonical place on Wikipedia where that subject is discussed) being able to mark it as "wikidata=ignore".

If there's no reason not to, I'm happy to try and add some functionality like "wikidata=ignore" to Module:Official website. It would basically make it so the renderTrackingCategory function would return the empty string if there was a wikidata argument set to "ignore". For other Wikidata-driven templates, we may need to think about whether we want any Wikidata-exempting arguments.

(As he wrote the module, pinging User:Mr. Stradivarius for input.) —Tom Morris (talk) 15:05, 5 March 2016 (UTC)

I would go for both #2 and #4. Following "part of" relations sounds like the most elegant way of doing it, and adding category suppression is generally good template design anyway. Is there a need to specifically disable Wikidata-related categories, or could the parameter be |categories=no, rather than |wikidata=ignore? — Mr. Stradivarius ^{♪ talk ♪} 16:01, 5 March 2016 (UTC)

Thanks, User:Mr. Stradivarius. Yes, not having the categories is the main thing. A category like Category:Official website not in Wikidata is basically a to-do list and we should eliminate from such a list anything that doesn't need to be done. #2 would be amazing, but needs a bit more cleverness and programming than I'm willing to chuck at the problem now. I'll have a look at making the changes to implement #4 in a draft version, using categories=no instead. Probably tomorrow. —Tom Morris (talk) 17:34, 5 March 2016 (UTC)

The latter two items should be represented by the 'instance of' relation in Wikidata. #1 is a non-starter for the Wikidata community. I think the most-preferable options would be to either 5) remove these official links, since they aren't official links for the instances in question (only to the 'parent' event) or 6) identify more-relevant official links. Item 5 is preferable to me since the content of the supposed official link changes to reflect the instance of most-recent interest, where we should attempt to direct users only to an unchanging official link. #6 I presume doesn't surface many official links. I'm generally agreeable to item 4, though I would prefer the semantics in the invocation of the template not refer to categories (a reason popped into my head, briefly). --Izno (talk) 13:37, 7 March 2016 (UTC)

Official Website for Country

Hello team,

I have added official website in one of the wiki pages. But to be more precise i wanted to add country specific official website. How should i do that??? — Preceding unsigned comment added by Bharatlok (talk • contribs) 07:26, 10 March 2016 (UTC)

Bharatlok, I presume you're talking about Nobroker.com. It's only active in India. Why would it need a country specific official website when it's only active in one country? I don't see why you need to differentiate it, nor what there is to differentiate it from. Bazj (talk) 11:48, 10 March 2016 (UTC)

Wikidata–Wikipedia comparison

Why is "http://www.avignon.fr/" not recognized as equal to "http://www.avignon.fr"? Was this intentional? I guess extra "/" should be made acceptable. --Obsuser (talk) 09:08, 9 August 2016 (UTC)

The canonical URI is the former and not the latter according to the IETF. That they happen to go the same place is an artifact of your browser. I don't see a reason to make such a change, though you're welcome to do so on your own wiki (since I know you are predominantly a non-English Wikipedian). --Izno (talk) 11:18, 9 August 2016 (UTC)

Maybe because there is a significant number of pages using "http://www.avignon.fr/"-like form and it is good but still not accepted and error category is added. However you want, just noticed this.--Obsuser (talk) 18:32, 9 August 2016 (UTC)

Merge to cite web

Theoretically speaking, is there any reason this template couldn't be replaced with {{cite web}} if it had an additional parameter eg. |type=official that added an "(official)" tag on display? It would help greatly in maintaining WP:link rot with bots. It would also simplify for everyone to use a standard template. -- GreenC 16:08, 9 September 2016 (UTC)

Their functions differ sufficiently not to do so at present. What functionality from the Help:CS1 suite do you think would be beneficial for this template? --Izno (talk) 18:03, 9 September 2016 (UTC)

How do their functions differ? They both take a url as a parameter and display it. -- GreenC 18:17, 9 September 2016 (UTC)

You should probably review {{cite web}}'s extensive documentation if that is what you think cite web does... --Izno (talk) 18:21, 9 September 2016 (UTC)

Example:

{{cite web |url=http://example.com |format=official}}

Official website

{{official website |http://example.com}}

Official website

They display the same without the need for another template. Obviously web cite doesn't do this today. It's a question why it couldn't. -- GreenC 18:28, 9 September 2016 (UTC)

Your first example actually displays, currently, as:

http://example.com. {{cite web}}: Missing or empty |title= (help)

What you may mean is:

{{cite web |url=http://example.com |title=Official website}}

"Official website".

Bear in mind also that most official website URLs are now in Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:39, 9 September 2016 (UTC)

There are at least three reasons why not: this link does not need the <cite> Html that is applied to every single CS1/2 citation, nor the Coins metadata (and in fact these would be incorrect); because these links are now stored in Wikidata, meaning a set of functions in this module unsupported in CS1/2; and because this template outputs microformats, which are not used in CS1/2 either (IIRC; Pigs can correct me). And we don't need almost any of the error checking or any of the complex formatting in the CS1/2 templates.

Basically, no, there is 0 reason to use those templates here in their fulness. If you have a specific suggestion of functionality to port, please feel free to suggest that specific functionality. --Izno (talk) 20:46, 9 September 2016 (UTC)

Ok "bad idea" then. Thanks for clearing it up for me before I took it any further. -- GreenC

Templates and official website

Can this module be tweaked so that templates that use {{official website}} and are transcluded in a particular article don't cause that article to go into Category:Official website different in Wikidata and Wikipedia because official site URL is not always as same as in template? --Obsuser (talk) 01:50, 11 August 2016 (UTC)

@Obsuser: Do you have an example? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:30, 9 September 2016 (UTC)

A template cannot tell whether it's used directly or via a transcluded page. My suggestion at Template talk:Official website/Archive 2#Proposed parameter to ignore Wikidata could be used for both this and other situations. PrimeHunter (talk) 23:13, 9 September 2016 (UTC)

archivedate and archiveurl

The template doesn't support dead links. Example.

{{Official website |https://web.archive.org/web/20130512231300/http://www.irb.com/nationscup/index.html}}

Renders as:

Official website

This renders but is not ideal as it conflates the Wayback link with the official URL and the page is now in Category:Official website different in Wikidata and Wikipedia meaning technically an error.

It might instead look like:

{{Official website |http://www.irb.com/nationscup/index.html |archiveurl=https://web.archive.org/web/20130512231300/http://www.irb.com/nationscup/index.html |archivedate=May 12, 2013}}

Which would render as:

• Official website archived from the original on May 12, 2013.

@Mr. Stradivarius:

-- GreenC 01:34, 28 September 2016 (UTC)

Discussion at Template talk:Official URL#Official website language

You are invited to join the discussion at Template talk:Official URL#Official website language. 207.161.217.209 (talk) 02:50, 5 October 2016 (UTC)

Not working

|url= and |name= don't seem to work.

cf, this example from Zec Mitchinamecus:

{{Official website|url=http://zecmazana.reseauzec.com/fr}}

Adding a name does nothing.

{{Official website|url=http://zecmazana.reseauzec.com/fr|name=Zec Mitchinamecus}}

Please fix.--Auric talk 12:29, 29 October 2016 (UTC)

It's |URL=. Capitalization matters. |name= is correct but it needs a URL to display the name on:

Zec Mitchinamecus PrimeHunter (talk) 13:52, 29 October 2016 (UTC)

Thanks. It's not mentioned in the doc that it needs to be |URL= and not |url=.--Auric talk 16:49, 29 October 2016 (UTC)

I could easily add support for |url= in addition to |URL=. Any objection? It seems unusual to require an all-caps argument. URL is grammatically correct but for template arguments typically lowercase. At CS1|2 there are hardly any args that contain caps. -- GreenC 17:35, 29 October 2016 (UTC)

Template now supports |url= in addition to |URL= -- GreenC 01:11, 1 November 2016 (UTC)

Issues with URLs containing '='

I am starting to work on cleaning up Category:Official website missing URL and I've noticed a common theme. There are a number of links that are broken because the URL contains an '='. For example:

• {{Official website|http://www.andechs.de/index.php?id=2&L=0}} ->

However if the '=' sign is wrapped in {{=}} then it works:

• {{Official website|http://www.andechs.de/index.php?id{{=}}2&L{{=}}0}} -> Official website

I do not know enough about Modules to know if there is a possible solution to this but sure would be great to make it work with equal signs if possible. --Zackmann08 (^{Talk to me}/_{What I been doing}) 18:49, 7 November 2016 (UTC)

Follow up... For what it is worth, Module:ConvertDiff seems to work with equal signs... Not sure if there is some code there that can be used. --Zackmann08 (^{Talk to me}/_{What I been doing}) 18:51, 7 November 2016 (UTC)

See Help:Template#Usage_hints_and_workarounds first bullet. The best solution is always use named arguments eg.

{{Official website|url=http://www.andechs.de/index.php?id=2&L=0}} -> Official website

-- GreenC 20:53, 7 November 2016 (UTC)

Yes, please don't fix with {{=}}. It may confuse editors and tools looking for url's in the wikitext. It's technically possible for a module to detect strange parameter assignments like |http://www.andechs.de/index.php?id=2&L=0 which means the parameter name http://www.andechs.de/index.php?id is assigned the value 2&L=0. The module could then generate the intended url by joining name and value with "=" between, but this would leave a confusing mess in the wikitext. Just fix with |url=. A simple AWB find and replace can do it quickly in most cases. I will make an AWB run on the category. PrimeHunter (talk) 23:48, 7 November 2016 (UTC)

I have cleared the category. Some of the articles had an empty {{Official website}} with no url in the vicinity. I just commented it out in those cases. Many of them seemed unlikely to even have something which could be called an official website. PrimeHunter (talk) 01:19, 8 November 2016 (UTC)

Category:Official website missing URL overzealous

So there appears to be an issue with the way this module is adding pages to Category:Official website missing URL. Pages that have a website in WikiData do not need to supply a URL to the template (see Bertis Downs IV for example). Yet these pages are still being placed in the maintenance category. --Zackmann08 (^{Talk to me}/_{What I been doing}) 16:23, 23 November 2016 (UTC)

The hack for Module:Official website to 'fix' this behavior would probably not take too long, but GreenC has some stuff in there which differ from the current module (and which I'm not sure makes sense given the general move to Wikidata). --Izno (talk) 16:38, 23 November 2016 (UTC)

That was a bug in the logic and I just made a fix that should do it (it wasn't checking for all possible values of url and wikidataurl). The code in the sandbox can be overwritten, it's still in the history (right now probably not pursuing it). -- GreenC 16:49, 23 November 2016 (UTC)

Still not working (Bertis Downs IV keeps showing up in Category:Official website missing URL) not sure why. Relevant code:

local wikidataurl = fetchWikidataUrl()
if not url and not wikidataurl then
    category = 'Official website missing URL'

Taking it to sandbox to debug further. -- GreenC 17:10, 23 November 2016 (UTC)

Ah it is working, just needed to null-edit Bertis Downs IV to clear the category. -- GreenC 17:20, 23 November 2016 (UTC)

@Green Cardamom and Izno: thanks so much for getting right on this! I'm not fluent enough with Modules yet to do the edits myself. --Zackmann08 (^{Talk to me}/_{What I been doing}) 17:50, 23 November 2016 (UTC)

No problem, good catch. Lua as a language is designed for beginners, pretty approachable. This template is a little more complex due to Wikidata. -- GreenC 18:21, 23 November 2016 (UTC)

@Izno and Green Cardamom: looks like there is a problem again. Swami Nithyananda, Travel Weekly and Nick Ross are all being added to the category. --Zackmann08 (^{Talk to me}/_{What I been doing}) 21:06, 3 January 2017 (UTC)

Just checked Nick Ross and don't see that category. maybe you need to clear our cache, or maybe there is a backlog in the job queue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:10, 3 January 2017 (UTC)

@Pigsonthewing: yea I'm not seeing Nick Ross in the category anymore... but the other 2 still are. --Zackmann08 (^{Talk to me}/_{What I been doing}) 21:42, 3 January 2017 (UTC)

Null-edits did the job. -- Magioladitis (talk) 21:54, 3 January 2017 (UTC)

@Magioladitis: thanks. Can you help me understand... Is this an issue of the official website being on Wikidata but not showing up on the page yet? --Zackmann08 (^{Talk to me}/_{What I been doing}) 22:13, 3 January 2017 (UTC)

I do not think this is a logic bug as per se but rather based on the fact that categories get updated upon edits but the page contents are also updated upon purges (which happen regularly and automatically). So changes to WD will update the page (at next purge) but not the categories until next edit (null or otherwise). 50.53.1.33 (talk) 04:30, 1 April 2017 (UTC)

It wasn't checking for all values of url and wikidataurl (ie. fetchWikidataUrl()) resulting in the behavior reported by the OP. The null edits etc not a bug how the system works. -- GreenC 14:52, 2 April 2017 (UTC)

Request support for dead links

I see that this was already requested at Template_talk:Official_website/Archive_3#archivedate_and_archiveurl.

Sometimes an official website is gone, and only archival copies remain. Blue Rasberry (talk) 16:26, 21 June 2017 (UTC)

Problem with Template:' used in website description

This markup currently causes errors:

{{Official website|http://www.sho.com/site/dexter/home.sho|''Dexter''{{'}}s official website}} on [[Showtime (TV network)|Showtime]]

renders as:

Dexter's official website on Showtime

Can this be fixed? Or does it have to be worked around? – Jonesey95 (talk) 15:12, 29 June 2017 (UTC)

I played around in the sandbox and added a hack just for the apostrophe you can see in the testcases (last entry). However this isn't the right way; the problem is with Module:URL. -- GreenC 16:15, 29 June 2017 (UTC)

I fixed Module:URL so it no longer includes <wbr/> inside HTML/XML tags. The above example should now work as intended (with the exception of a small gap in the underline due to the padding that {{'}} inserts). --Ahecht (TALK
PAGE) 20:49, 29 June 2017 (UTC)

Thank you! – Jonesey95 (talk) 02:44, 30 June 2017 (UTC)

@Ahecht: Hello. (Sigh!) I thought we were supposed to test changes to widely used templates thoroughly. You tested it for the cases you want it to work for but you didn't test it for potentially unwanted results. Why didn't you? That's very irresponsible for a template editor.

I will perform addition tests and share results.

Best regards,
Codename Lisa (talk) 06:10, 30 June 2017 (UTC)

And bingo! I found one. If the title has non-HTML < and > in it, it won't get formatted.

The solution, of course, is simple: Do not insert <wbr/> in the first place if a text label is supplied. In other words, supply the <wbr/> only if a single URL is passed to the template and what's being formatted is a printer-friendly form of URL.

Best regards,
Codename Lisa (talk) 06:50, 30 June 2017 (UTC)

@Ahecht and GreenC: Alright. I made this change to the sandbox: Revision 788227414. But we seem to have unexpected outcome: Module talk:URL/testcases. Is it okay with you two?

Best regards,
Codename Lisa (talk) 07:10, 30 June 2017 (UTC)

Yes changes should be done in the sandbox and checked against the testcases page. Other than that I have nothing to add because I don't fully understand the wbr tag purpose and how widely it applies and why the one case is failing or how important it is. -- GreenC 13:45, 30 June 2017 (UTC)

The <wbr /> is totally pointless in {{Official website}}. It is for {{URL}} only, which must display printer-friendly website links in the tight spaces of the infoboxes. Basically, this tag tells the browser: "You can break the string to the next line here, even though you might normally not."

Best regards,
Codename Lisa (talk) 14:29, 30 June 2017 (UTC)

The unexpected outcome do you mean the 1964thetribute.com red X in testcases? Will that impact uses of {{URL}}? Granted it looks like a rare case. -- GreenC 15:21, 30 June 2017 (UTC)

If you want my opinion, I think we can safely disregard it. Additionally, the second parameter of {{URL}} is deprecated anyway. That means we must provide no support for it, other than removing it from the articles. But you know the rules: Communicating with Ahecht is mandatory. —Best regards, Codename Lisa (talk) 15:34, 30 June 2017 (UTC)

Oh, good! With an attitude like that, there is sure to be more edit warring in the future and maybe even another ANI case when the changes go live. 2601:5C2:200:31AE:3D52:5ACE:5878:130C (talk) 23:58, 30 June 2017 (UTC)

The "attitude" is your own. CNL is seeking input to a sandbox edit. Do you have some alternative code to contribute? -- GreenC 03:27, 1 July 2017 (UTC)

@Codename Lisa: Communicating Ahecht was mandatory before reverting. The only thing that saves you from the trouble of going to ANI and facing the music is that the code was indeed faulty. (I organized a proposal for the responsibilities of template editors in the case of a dispute. While admins agreed with my former statement, they held a particular exception in the event that the code is faulty. I think it was Johnuniq who said bad edits must be reverted with all due haste.) There is another matter and that is the fact that there is bad blood between you and Ahecht, as he had been engaged in pervasive reversion of your contributions one or two month ago. Again, I am not saying what you did was a retaliatory reversion. (If anything, the retaliation would have appeared two month ago.) I am saying that you must have taken the extra precaution of documenting the template's fault before reverting. Perhaps, taking a screenshot from the crime scenefault scene?

And now? Ahecht will return after some time away and discover that the fault that he has "fixed" is still in the wild and blames you for it. Your intention to communicate after the fact is what doesn't matter to him. And Green Cardamom has already reviewed your change. So: Deploy the fix. Waste no more time. FleetCommand (Speak your mind!) 13:27, 1 July 2017 (UTC)

Wilco. I deployed the fix. —Best regards, Codename Lisa (talk) 13:31, 1 July 2017 (UTC)

I did test it against several testcases, I'm sorry I missed the one particular corner case that was cited, but I thought erring on the side of not breaking HTML/XML tags was worth the occasional URL that doesn't wrap in certain versions of certain browsers. I will say that I have no problem with CL reverting my change (especially since I was on vacation and unable to respond), so I'm not sure it's worth the drama above. However, I do disagree with the assertion that we don't have to provide support for the second parameter in Module:URL. The second parameter in {{URL}} is deprecated, but its use in the module is required for {{Official website}} to function (and the existence of {{Official website}} is often cited as one of the reasons that the parameter in {{URL}} was deprecated in the first place). --Ahecht (TALK
PAGE) 02:32, 4 July 2017 (UTC)

@Ahecht: To be fair, CL said second parameter of {{URL}}, not the second parameter of the module or anything like that. In other words, there is no such assertion that we don't have to provide support for the second parameter in Module:URL. FleetCommand (Speak your mind!) 04:08, 4 July 2017 (UTC)

Add "Edit in Wikidata" link

How could we add an "Edt in Wikidata" link to this template similar to the ones that appeared in other templates? -- Magioladitis (talk) 16:31, 16 July 2017 (UTC)

A template editor or admin would need to do this. Hopefully, someone with the proper rights will read this and make the edit to this template. I agree, this link is needed, as I'm seeing more bots create entries in WikiData for the articles I'm watching. --DrChuck68 (talk) 19:35, 22 August 2017 (UTC)

Please make the proposed change in the template's sandbox, which should not be protected. – Jonesey95 (talk) 21:32, 22 August 2017 (UTC)

The only output of the template is "Official website". I don't think we should double the length with "Edit in Wikidata". The huge majority of page views are readers and not editors. A small link at the bottom of a big infobox is different. PrimeHunter (talk) 22:09, 22 August 2017 (UTC)

The length wouldn't be doubled, other templates like Template:Twitter add a small icon with a tooltip. The Twitter template is getting the icon from Template:EditAtWikidata. --DrChuck68 (talk) 22:51, 22 August 2017 (UTC)

Jonesey95, I've added the template EditAtWikidata in the sandbox to show the edit icon with tooltip. While it doesn't show up in the test case page, I was able to get it to show in the WPKN article and doing a preview with {{Official website/sandbox}} --DrChuck68 (talk) 00:29, 23 August 2017 (UTC)

@Hchc2009: Check this out. -- Magioladitis (talk) 10:04, 27 August 2017 (UTC)

@Frietjes: Maybe you could hep with that? Is something similar to Template:Twitter possible? -- Magioladitis (talk) 09:42, 28 August 2017 (UTC)

Template should be prefered from urls

We should add somewhere that this template should be prefered from its url in brackets eqquvalent because it compares its values with Wikidata and it content can also eventually be replaced by Wikidata to avoid link rot. -- Magioladitis (talk) 22:28, 30 June 2017 (UTC)

How do you envision Wikidata will solve link rot? -- GreenC 03:17, 1 July 2017 (UTC)

GreenC Wikidata address to a larget audience because is not language-restricted. Any change in any Wikipedia language project will be visible immediatelly to all projects. -- Magioladitis (talk) 05:59, 1 July 2017 (UTC)

Ok I thought you meant wp:link rot which is a dead links replaced by an archive links. Currently that is done in the wikitext by bot, or by History-tab -> Fix-Dead-Links. -- GreenC 12:57, 1 July 2017 (UTC)

...and can be done in Wikidata by a bot, too. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 10 July 2017 (UTC)

+1 this is very sensible. c/f {{Authority control}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:36, 10 July 2017 (UTC)

If you want to force use of this template, take it to the village pump. Template talk isn't the right venue for such a major decision. In my experience, forcing editors to use Wikidata templates rarely (never?) ends well. ~ Rob₁₃^Talk 16:38, 27 August 2017 (UTC)

A reply that came two months later. The change has to do with data comparison. By the way, already many templates use Wikidata. -- Magioladitis (talk) 17:14, 27 August 2017 (UTC)

Agree with User:BU Rob13 - this runs counter to the guidelines at WP:External, which is where the debate should happen (or at the village pump), not on a little-watched template page. Hchc2009 (talk) 08:52, 28 August 2017 (UTC)

The Wikidata use is optional. This is not the main advantage here. The main advantage is the the data comparison between Wikipedia sites. We can also via "What trascludes here" have an estimate of how many pages have official websites, we can have standard names and probably other uses the plain url does not provide. -- Magioladitis (talk) 08:56, 28 August 2017 (UTC)

Per the TfD: "Using templates like these provides consistent formatting across all articles" (BOVINEBOY2008, 03:16, 14 August 2009) and "this provides a standard and a easy way to format the addresses and text" (Peachey88, 03:54, 14 August 2009) -- Magioladitis (talk) 10:19, 28 August 2017 (UTC)

Wrong language qualifier

I was alerted to an issue in this template when I went to investigate a content dispute between Fram and Magioladitis on Medevi.

The official website property's allowed qualifiers are d:Property:P856#P2302. In that list is included d:Property:P407 but not d:Property:P2439. The change in allowed property is a result of a very long (in time) property for deletion discussion about how Wikidata handles its language properties. The current constraints list for P856 is rather short and does not very often indicate an incorrect use of the wrong language property.

Would anyone here have any heartburn changing in the module for i, lang in ipairs(prop.qualifiers.P2439) do to for i, lang in ipairs(prop.qualifiers.P407) do? --Izno (talk) 13:19, 27 September 2017 (UTC)

This template should not be pulling data from Wikidata. That is an unreliable source, which our anti-vandalism bots and watchlists can't patrol. Parameter {{{1}}} should be required, and the template should report an {{error}} when editors fail to specify the website URL. It's fine if Wikidata bots want to pull this URL from Wikipedia to enter it into their database. I am already overburdened with too many tasks and learning curves to have any desire to learn the obtuse Wikidata editing interface, which is far from user-friendly. Where was there ever a discussion or consensus to pull URLs from Wikidata? I think this is highly controversial. – wbm1058 (talk) 14:37, 27 September 2017 (UTC)

@Wbm1058: If you would like to discuss Wikidata in this template, that is a separate thread. Do you have a comment about my issue? --Izno (talk) 14:39, 27 September 2017 (UTC)

I don't even understand what your issue is. wbm1058 (talk) 14:43, 27 September 2017 (UTC)

@Wbm1058: Then you are in the wrong place at the wrong time. :) --Izno (talk) 14:46, 27 September 2017 (UTC)

What is a "language qualifier" and why do we need one? This is English Wikipedia. The language is English. KISS. wbm1058 (talk) 14:48, 27 September 2017 (UTC)

So I assume from your response that pulling URLs from Wikidata was BOLDly implemented without discussion? wbm1058 (talk) 14:52, 27 September 2017 (UTC)

@Wbm1058: My response makes no comment on whether the implementation was bold (because it is irrelevant to my concern). As for language qualifiers: Wikidata has things called statements. Each statement may be true in some cases but not others. The way we indicate on Wikidata that the statement is true only in some cases but not others is by using a qualifier. For the statement "A has official website B", we can use the "language of the work or name" property to qualify the statement to "A has an official website in English at B" (qualification is only typically done where the official website has multiple language versions available). This allows us on English Wikipedia in the module to filter out websites which aren't in English from Wikidata (which hosts all official websites per its international nature). However, the module currently uses the "language" qualifier. I want to change the module because it is referencing the wrong property. (And I have some additional info above about whether this is a Good Idea.) --Izno (talk) 14:58, 27 September 2017 (UTC)

Dead links

When the URL property in Wikidata has an end date, as, for example, in Woolworths Group (Q958479), this template (and {{Official URL}} - I'll post a note on its talk page) should do one of these things:

1. ignore the URL
2. display the URL, but not as a link (i.e. wrap the URL in <nowiki> tags)
3. display the URL, but link to archived pages at, say, archive.org as specified in archive URL (P1065)

Which is the best solution? Can someone implement it, please?

(Option 2 or 3 are best suited to {{Official URL}}, in infoboxes). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:39, 15 October 2017 (UTC)

• This is a perennial request, 4 or 5 previous requests in the archives. Question: is there a bot currently active on Wikidata that is adding archiveurls or is it being done manually? The reason I ask, it's really too big to rely on manual and we have a couple sophisticated bots that search out and add archives on Wikipedia, but they are not setup to work with Wikidata. -- GreenC 12:24, 15 October 2017 (UTC)
• Hello. Option 3 is a violation of the Wikipedia:External links policy. The policy permits a link to the official website but makes no provisions for a mirror or archived copy of the said website. The mirrors fall into the same category as other external links: Most of the time, we don't want them. —Best regards, Codename Lisa (talk) 06:13, 16 October 2017 (UTC)

The policy doesn't disallow it either. It says nothing either way. According to Adherence "Use common sense when interpreting and applying policies and guidelines". When an official website is dead, it is common sense to link to an archived version. This is already being done throughout Wikipedia. If you want explicit permission then I suppose an RfC could be held but I am pretty sure the community would support linking to archived versions of official websites that are dead. There's no common sense reason not to. -- GreenC 12:12, 16 October 2017 (UTC)

As you yourself said "The policy doesn't disallow it either. It says nothing either way." The policy allows the official website link on a no-questions-asked basis. Other links must be assessed first. When you take option 3, you are suppressing common sense for case-by-case choice in favor of automatic action.

"This is already being done throughout Wikipedia." Yes, and blindly so, without a thought, without regards for the common sense. Editors do it because they see other editors reviving other links with archived versions, never realizing that the other links are mostly citations. My evidence is that there is no justifying reason given in their edit summaries.

Best regards,
Codename Lisa (talk) 12:25, 16 October 2017 (UTC)

Well I'm pretty sure if we need to hold an RfC the community will support fixing link-rot of official-links in the same or similar manner as is currently done for citations. There's no common-sense reason to differentiate them, so far as link-rot goes. -- GreenC 15:28, 16 October 2017 (UTC)

There is a common-sense reason to differentiate between dead official links and dead links in references. If any encyclopedic information is available at the official link, it can and possibly should be added to the article with the link used as a reference. However, if the link is merely fluff showing that the organization is wonderful and offers great products, there is no reason to archive it. Wikipedia is not a link repository, and is particularly not a repository of dead links. Can someone produce a few examples showing encyclopedic benefit from archiving dead official links? Johnuniq (talk) 23:05, 16 October 2017 (UTC)

I should have included dead links in external links sections .. or anywhere else in an article (not just references). You seem to be advocating dead links outside references bet deleted entirely from an article. I doubt the community would agree with that when archived versions are available. -- GreenC 00:33, 17 October 2017 (UTC)

It's routine to remove dead links from the external links section, although that should occur after a decent search for the original and consideration of whether the link is useful for the article. Someone working on an article might go to the trouble of adding an archived external link because they know the link is sufficiently worthwhile, but in general dead links are useless if not part of a reference. Many EL sections accumulate stuff which would fill the page if not regularly pruned. Johnuniq (talk) 03:14, 17 October 2017 (UTC)

We now have bots to add archives for dead links. It's automatic at this point. Example edit from a few minutes ago but this bot has added over 6 million archive links and does a few hundred thousand more a month. It's not routine to remove archived external links. The content is still there, it's the same content, why would someone remove it? Only if they don't like the content, nothing to do with its archive status. -- GreenC 04:15, 17 October 2017 (UTC)

Seems to have an extra bracket

This template seems to be adding an extra bracket after the URL. Can't edit it or view the source because it's protected. Thanks. —DIYeditor (talk) 11:43, 17 November 2017 (UTC)

@DIYeditor: Wasn't this template – it came from a stray bracket after a category. Fixed with [1]. - Evad37 [talk] 11:57, 17 November 2017 (UTC)

Thank you! —DIYeditor (talk) 11:59, 17 November 2017 (UTC)

missing "edit wikidata" link when using template

I've noticed just now that where before there used to be the little pencil "edit wikidata" icon after the URL generated by {{Official website}} if the data for that template was coming from wikidata, it's now not showing up. This seems like a recent change, and most likely an error. Anyone more well-versed in the innards of programming Wikipedia/wikidata want to look into that? It seems like something it would be best to have back.

An example of what I mean, where the IMDb template-generated link shows the pencil icon but the Official website-template generated one does not. —Joeyconnick (talk) 21:04, 12 November 2017 (UTC)

@Frietjes: -- Magioladitis (talk) 21:19, 12 November 2017 (UTC)

Has it ever been there? It was suggested at Template talk:Official website/Archive 3#Add "Edit in Wikidata" link and added to {{Official website/sandbox}} in [2] but not the live template. PrimeHunter (talk) 22:19, 12 November 2017 (UTC)

Pretty sure it used to be there. But even if I'm wrong, it seems like a no-brainer addition. —Joeyconnick (talk) 01:50, 13 November 2017 (UTC)

Agreed. I just realised this, too. It's present on {{Facebook}} and {{twitter}} but not here. Seems a bit odd. Anarchyte (work | talk) 12:43, 1 January 2018 (UTC)

Add parameter language or lang?

I propose to add |language=, to be used when the website's language is not English. Example: Jaguar (beverage).

Should copy documentation from {{cite web}} ("The language in which the [site] is written, if not English; use the full language name; do not use icons or templates"). The visual effect would be that "_(Russian)" is added.

To consider: can we use lang codes instead? (|lang=ru?). BTW, d:Property:P856 does not have the language statement. - DePiep (talk) 11:46, 10 March 2018 (UTC)

Wikidata statements are qualified. Review the statements allowed in "allowed qualifiers constraint" in P2302 which includes "language of work or name". --Izno (talk) 15:24, 10 March 2018 (UTC)

You are right. No change: IMO we should incorporate the language note (when not en) into this template. Live when from wikidata, by dedicated parameter when local at enwiki. - DePiep (talk) 20:54, 10 March 2018 (UTC)

Add parameter checking

I propose to add Module:Check for unknown parameters, using Category:Pages using Official website with unknown parameters (new). See Template:Official website/testcases (testing {{Official website/sandbox}}).

This is not an {{Edit request}} (I can do the edit myself), but I'm asking eyeballs to check if this change makes sense. - DePiep (talk) 11:28, 10 March 2018 (UTC)

Sure. -- Magioladitis (talk) 11:29, 10 March 2018 (UTC)

This is uncontroversial. The module has been added to hundreds of templates, and I can't think of a case where it has been a problem. Standard practice is to limit the error category to article space using {{main other}}. See {{Infobox_book}} for a standard implementation. – Jonesey95 (talk) 15:08, 10 March 2018 (UTC)

 Done -DePiep (talk) 15:18, 10 March 2018 (UTC)

Note that the category can take multiple months to populate. In the meantime, you can find most of the unknown parameters in the TemplateData monthly error report, linked from the TemplateData section of the documentation. – Jonesey95 (talk) 18:02, 10 March 2018 (UTC)

Somehow it populated quite fast (and depopulate fast after the correcting edit). I know that TemplateData report: yesterday I edited most of those bad parameters out (add |URL= 500× ) ;-). - DePiep (talk) 18:10, 10 March 2018 (UTC)

@DePiep: Hi. I worked with you on this category tonight. But a couple of conflicts have occurred. For example, in revision 829762048 I attempted to fix the article at the same time you did. MediaWiki's automatic conflict resolution tried to resolve it. The result is an edit that, taken alone, makes me look like a complete fool.

Now, normally, this isn't something that even needs to be mentioned at all. But something out of normal happened today: A certain IP reverter didn't miss the chance to chastise me over it and mention WP:NOTBROKEN. One wouldn't know that this person is unscrupulous until one look at his contribution log and discover that on the same day, this same unscrupulous person, using this exact same IP, attacked JamesBWatson for the reverse of this reason. In addition, my records show that he has a history of trying (and miserably failing) to harass many Wikipedians in the past, including JamesBWatson and yours truly.

I said all this to make it clear that I was helping you tonight, not stalking and sabotaging your work. I have no preferences between |url= and |1=, or between {{Official}} and {{Official website}}. If automatic conflict resolution has made it seem that way, it is unfortunate.

Best regards,
Codename Lisa (talk) 22:11, 10 March 2018 (UTC)

Thanks for this post. I did not have the slightest idea, feeling nor impression of you contra-working. Instead, I smiled noticing that you already found 'my' new tracking category. I did not meet any ec in this, I just skipped.

Now re that IP behaviour. I did not meet their edits today at all. And I did not research them (your links). But if you want me to support actions (add ANI opinion?, reply on JBW's palkpage?, respond about something?), do ping me. Hope you got rid of those bad feelings by nasty editors. Have a nice edit, DePiep (talk) 22:29, 10 March 2018 (UTC)

Nah. Your smile (mentioned above) is all I wanted. Admins are already very supportive. Like I said, I normally don't even mention any of this, let alone write such a long message. —Codename Lisa (talk) 11:21, 11 March 2018 (UTC)

• Jonesey95, I am a bit annoyed by this edit you did to the live template. First of all, I have opened this talk exactly to prevent that: I asked for checks so you could have taken a look at the sandbox code, and comment. Code proposal was plainly linked in my OP. Second, this way you pushed your opinion into live while undiscussed. You skipped talking about the reason I have to not include that. I request you undo that edit for being undiscussed. - DePiep (talk) 23:42, 10 March 2018 (UTC)

Done. No problem. Ignoring empty parameters is the normal practice. I recommended it above, and there was no objection, so I implemented it, but if you don't want it, no problem. – Jonesey95 (talk) 14:57, 11 March 2018 (UTC)

• Codename Lisa re [3]: If I understand the /doc, a blank |1= will fetch "official website" Property (P856) from WD (see Academy Awards). So nothing is broken, and parameter |2= may correctly be used for name (label shown). I don't think this tracking will be useful -- even worse, it floods the category with these false positives. There are also the other tracking categories. And the monthly report will help just as much (it could produce that 1=blank list of articles even). Note that the report will be much cleaner next month.

On top of this, there is not need to add categorisation code to the module. What I propose is: enhance the logic wrt parameters 1, 2, url and name (in the module): shift the numbered ones in that certain unambiguous situation. - DePiep (talk) 12:13, 12 March 2018 (UTC)

Let me see if I understood correctly: You are saying there are plausible cases in which someone might want to fetch the official website URL from WikiData but customize its label? That's easily a questionable practice that masks GIGO behavior. Mind you, what I implemented does not trigger an error message when someone uses {{Official website|2=label}} or {{Official website|name=label}}.

I'd say we should let a few days pass and see if the category is populated with plausible examples that justify your concern. (Of course, I am not saying we must wait the whole period even if we see justifying examples.) If there were plausible examples, then we can proceed with reverting my edit and altering line 118 of the module.

Best regards,
Codename Lisa (talk) 15:18, 12 March 2018 (UTC)

Not GIGO, but as documented and by the editor's sound judgement. Incidentally, in the same example Academy Awards (I picked because sure it would have an URL at WD), the editor might want to change the label from possibly "Oscars" into "Academy Awards", nicely following the article title.

The only more relevant check would be to look if |2= is an url. That would need attention (the actual mistake you mentioned). However, {{Official website||anytext}} is not a mistake a priori, it is a feature. Then, the tracked articles may be too numerous to do the check. BTW, I am not that overly interested, I might let it go - the low hanging fruit is already done.

I also note that this was not the change I asked for. You have not replied to my OP below, nor to my comment 'I did not ask for categisation code in the module'. Clarified? - DePiep (talk) 15:39, 12 March 2018 (UTC)

Data, data, data. I need clay to make bricks; I need data to make better templates.

So, please let it stay for a while. Let's see which one we run into: Editorial judgment or clerical error. To be honest, I suspect the latter. I always assume good faith and never assume expertise off hand.

Best regards,
Codename Lisa (talk) 16:03, 12 March 2018 (UTC)

Name parameters handling: add friendly logic

Today, |2= is used to enter a labeltext: Labeltext here. Parameter |name= does the same; |1= is read as the url.

However, when named |url= is used instead of |1=, the labeltext is entered as |1=. Of course we could document to enter an extra pipe like {{Offical website|url=www.example.com||Example website}}, but that is not editor-friendly. Usage of |url= is good practice, and is required when the url contains a "=" character. Some 10k instances use |2= today.

I propose to add this logic to the module: "When named parameter |url=, |URL= is used, unnamed |1= is read to be the |name=. (Otherwise, |2= is read to be the name; unchanged)". This does not change when d:P856 is used. To test: {{Offical website|url=www.example.com|Example website}}. -DePiep (talk) 12:03, 10 March 2018 (UTC)

That sounds like a reasonable bug fix. – Jonesey95 (talk) 15:10, 10 March 2018 (UTC)

Yes, this is OK. -- Magioladitis (talk) 18:44, 10 March 2018 (UTC)

Strongly disagree. I think we must downplay the label parameter as much as possible. We want to eventually attach semantic value to this template, not make a replacement for standard wikilinking syntax. This template must not be used by those want to link to anything but the official website. Those who want to link to a website, give it a different label than "official website" when that website IS the official website must have a very good reason, and we must not make it easier for them.

Best regards,
Codename Lisa (talk) 16:00, 12 March 2018 (UTC)

It seems to me that discouraging the use of |2=, which may be a good idea, should be a separate discussion. The parameter is used in 11,000 articles, and I do not see any mention of discouraging its use in the template documentation or the archives of this talk page, but I could have missed something. DePiep is proposing a fix that is clearly a bug fix; |1= is used in 180,000 articles, some of which no doubt have the bug described above (assuming that the bug description above is accurate). – Jonesey95 (talk) 16:35, 12 March 2018 (UTC)

I am in no hurry to brand the mistakes of others as bugs. In the words of Friedrich Schiller, "Folly, thou conquerest, and I must yield! / Against stupidity the very gods / Themselves contend in vain." Now, if you had said a design flaw, that would have been another matter entirely. The burden of using |url= is on the person who does it, especially, given the ancient history of this alias.

Best regards,
Codename Lisa (talk) 17:06, 12 March 2018 (UTC)

If you want to change the template and its documentation to make it semantic — go ahead, but do not suggest that the users who read & follow the current /doc are doing something wrong. It is up to you to propose that somewhere else (and adding a bit of effort, I must ask by now). Meanwhile, you still don't seem to grasp my proposal here, which is no more no less than the sectiontitle says. (Already earlier on this page you failed to get it, hammering on something else instead). - DePiep (talk) 18:22, 12 March 2018 (UTC)

The current documentation does not say "when |url is specified, |1= acts in lieu of |name=".

I read your proposal carefully and I still disagree strongly. {{Offical website|url=www.example.com|Example website}} must act similar to {{Offical website|url=www.example.com}}. Users must simply learn.

Best regards,
Codename Lisa (talk) 18:32, 12 March 2018 (UTC)

The more I look at this, the more of a mess it appears to be. This template appears to have had this design flaw since 2013 (thanks for the link, Codename Lisa). The question now is: how should we fix it? In my experience, attempting to fix a problem solely by "educating" editors with documentation is doomed to fail. People simply do not read documentation. We need to start with some sort of error-tracking mechanism. The tricky parts will be determining what an error looks like, how to implement logic in the module to detect these errors, and figuring out a long-term fix to eliminate the design flaw. Jumping right to the long-term fix, I propose eliminating at least one of the unnamed parameters; having multiple named and unnamed parameters that overlap is a recipe for failure. – Jonesey95 (talk) 03:34, 13 March 2018 (UTC)

Now that is a sentiment I can reciprocate. Of course, maybe that is partly because I've seen too many satirical TV shows about concepts with too many exceptions. But the other part is my experience from programming, when we implemented an API exception for the convenience of people. Usually, we ended up confusing both the group sought a strictly rule-based approach and the group who kept making the mistake. Memory allocation for PChar is my least favorite example. PChar was auto-allocated. Other pointer types had to be allocated with GetMem and FreeMem. So, the moment we accepted it in our API, the number of allocation errors and bugs across the whole project shot up to an alarming rate. It was non-existent before. We banned PChar and sent an email to everyone saying "Please allocate memory for your pointer types. No exceptions." and banned PChar. We accepted strings only. One person was responsible for a wrapper class the fed PChar to Windows API.

Generally, in a very a complex system where people don't read documentations, like Wikipedia, a strictly rule-based approach is the best. The moment you try to make an anomaly for the convenience of the anomalous people, you end up confusing everyone. People just want to test and see what other anomalous behavior are acceptable that we didn't tell them. Come to think of it, I think it was the founder of Ford Motor Company who discovered it and used it speed up mass production.

Best regards,
Codename Lisa (talk) 07:40, 13 March 2018 (UTC)

Addition of HTTPS upgrade parameter

Whenever I want to ensure that an official website link is in HTTPS, I have to pipe in the full link to do so (after checking whether HTTPS is implemented on the site, of course), which seems verbose and adds unnecessary bytes. For example, if the website is example.com:

{{official website}} vs. {{official website|https://www.example.com/}}

As far as I am aware, there is no parameter that performs the HTTPS protocol upgrade. Because of that, might it be worthwhile to add one, such as https=y or secure=y or something similar? It would reduce on bytes and make for quicker switching. Unless there is some policy or coding issue that prevents this, it seems to me that this would be a reasonable addition that is in-line with the migration to HTTPS that the Internet in general, the Wikimedia Foundation in specific, and Wikipedia in particular are doing (or has done, in the case of the latter two). Relatedly and to further demonstrate my point, the entire function of some bots implemented on Wikipedia, such as KolbertBot, is to assist with this effort. Thoughts?

By the way, if this is not the appropriate place to suggest this, then please do direct me to where I should go with this. Thanks. ―Nøkkenbuer (talk • contribs) 23:14, 20 April 2018 (UTC)

If a page is just using {{official website}} with no parameters, then it is pulling the website URL from wikidata... if the URL there is set to http:, you can just change it to https: and everything will be fine. —Joeyconnick (talk) 02:21, 21 April 2018 (UTC)

If it is that simple, then alright, thanks and apologies for proposing from a place of ignorance, Joeyconnick. I pretty much exclusively edit the English Wikipedia and have almost never ventured to other Wikipedias or Wikimedia projects; for example, all my edits at Wikidata have thus far been a total of ten automated changes while editing here. Needless to say, I am almost completely unfamiliar with Wikidata, but I guess now is the time to learn. Hopefully, any future editor searching the archives for a similar issue finds this; at least then, my proposal would have been useful. ―Nøkkenbuer (talk • contribs) 03:08, 21 April 2018 (UTC)

Feel free to drop a note here or WT:Wikidata if you need help. --Izno (talk) 03:10, 21 April 2018 (UTC)

Indeed, just change the link on Wikidata to the secure version. That's generally seen as uncontroversial (usually where it is controversial is where the main website actually isn't encrypted but has a redirect from the encrypted scheme). --Izno (talk) 03:10, 21 April 2018 (UTC)

No need to apologize... Wikidata takes some getting used to and it can be tricky to tell exactly what's using it and what isn't at times... and which properties which template is pulling from. However, it is pretty neat once you figure things out. Someone should probably run a bot task on it to "upgrade" a list of known websites that are now using https but until that happens, the manual fix is relatively simple once you know to do it. —Joeyconnick (talk) 03:13, 21 April 2018 (UTC)