Template talk:URL/Archive 2

Archive 1

Archive 2

Import URL from Wikidata (2)

We had this before, but as this functionality got lost, a new Template:ConditionalURL was created, which has now been renamed. Basically, properly retrieving the Official website property from Wikidata seems to be basic functionality for infoboxes, though, so should be merged (back) into the module, so at least it can be used by that other template. Additional logic as per Template:Official website should be applied to determine which URL to retrieve, in case there are more than one. --PanchoS (talk) 10:25, 23 January 2016 (UTC)

I came to the Talk: page specifically to make a similar point — I'm seeing Template:Official website be used in infoboxes a lot recently and being able simply to change {{official website}} to {{URL}} would definitely be A Good Thing™. I'll take a look at this when I've next got time to think about it, if nobody beats me to it. — OwenBlacker (Talk) 11:25, 27 July 2016 (UTC)

Edit request for importing URL from Wikidata

Please amend the template from

<includeonly>{{#invoke:URL|url|1={{{1|}}}|2={{{2|}}}}}</includeonly><noinclude>{{documentation}}</noinclude>

to

<includeonly>{{#invoke:URL|url|1={{{1|{{#property:P856|}}}}}|2={{{2|}}}}}</includeonly><noinclude>{{documentation}}</noinclude>

to allow Wikidata's "Official website" property (P856) to be used if {{{1}}} is not supplied. (Please then {{ping}} me to add {{Uses Wikidata|P856}} to the Template:URL/doc page, unless you want to do so yourself.) — OwenBlacker (Talk) 12:03, 20 August 2016 (UTC)

Done OwenBlacker. Izno (talk) 12:29, 20 August 2016 (UTC)

Thank you; I have updated the documentation appropriately. — OwenBlacker (Talk)

Reverted. @Izno and OwenBlacker: Technically, this request breaks the rule of thumb of separation of concerns and the result is very funny: If you insert {{URL|http://www.example.com?request=response}} in Microsoft article, you get www.microsoft.com, causing utter confusion in the inserting editor. Best regards, Codename Lisa (talk) 07:08, 21 August 2016 (UTC)

Ah, I see what you mean; I'd not considered that. Thank you, Codename Lisa for being quite so thorough about your revert, catching the documentation and redirects and stuff too. It's very much appreciated. — OwenBlacker (Talk) 09:13, 21 August 2016 (UTC)

This would likely have been better done at the Lua module level instead of the template. The problem with {{Official URL}} is it uses {{#property:P856}} which can have multiple values and results in issues. Module:Official website could export its fetchWikidataUrl function and infoboxes and {{Official URL}} could use that instead. Perhaps I shall try to work on it in the module sandbox. 50.53.1.33 (talk) 12:53, 31 March 2017 (UTC)

Possible fix to help with Template:Official website (and others?)

Please see this discussion that may relate to Module:URL's handling of {{'}} in website names. Thanks. – Jonesey95 (talk) 19:06, 29 June 2017 (UTC)

@Jonesey95: I fixed that error here. --Ahecht (TALK
PAGE) 21:07, 29 June 2017 (UTC)

Template-protected edit request on 12 August 2017

Please change http:// to // to prevent switching from secure to insecure servers. Ups and Downs (↕) 04:23, 12 August 2017 (UTC)

Not done: That is not feasible because many sites do not support HTTPS, and links to those sites would be broken. You can explicitly make a secure link with this template like {{URL|https://google.com}}. Toohool (talk) 04:59, 12 August 2017 (UTC)

Deprecation of Parameter 2

@Codename Lisa, Pigsonthewing, Prof.Haddock, Blethering Scot, Danorton, RexxS, Littleolive oil, WhatamIdoing, and Rybec: I reverted the removal of the deprecated parameter 2 from the template, as the parameter is still in use by almost 19,000 pages, not to count the numerous pages that reply on templates that are using the parameter. I've pinged Codename Lisa, who removed the parameter, as well as everyone involved with the original threads on depreciating this parameter at WP:VPP and Template talk:URL, because I feel that the removal was a bit premature. The parameter was deprecated on the assumption that this template is only used in Infoboxes. However, due to its ability to fix up a variety of malformed URLs (including Wikidata urls that start http://, URLs with unencoded spaces, URLs without a protocol, etc), it has been widely used in a variety of templates other than infoboxes for sanitizing URL inputs. The suggested replacements don't serve the same purpose, as wiki markup doesn't support malformed or Wikidata URLs, {{Plain link}} doesn't show the external link icon, and {{Official website}} adds tracking categories. We shouldn't be removing the parameter unless we create a fork of this template for non-Infobox use and migrate all existing templates using {{URL}} with a 2nd paramter to the new template.--Ahecht (TALK
PAGE) 19:48, 21 April 2017 (UTC)

Hello, Ahecht

Please give us a few examples of pages that use this template to fix malformed URLs.

Also, I didn't assume it is only used in the infoboxes. I made the move despite knowing the contrary; things won't get fixed when there is no incentive to fix them.

Best regards,
Codename Lisa (talk) 04:26, 22 April 2017 (UTC)

@Codename Lisa: I know Template:Taxonbar, which was using this template for fixing Wikidata URLs, was broken by this change (I have since created a template for fixing those URLs and updated {{taxonbar}} to use it, but figuring out why the template was broken in the first place was a challenge). Given that 18,000 pages use this parameter, I imagine that there are other templates using it as well. --Ahecht (TALK
PAGE) 04:47, 22 April 2017 (UTC)

@Ahecht: If you've fixed it with ordinary Wiki syntax, then it is no longer an example. Can you give us some valid examples? Do you actually realize why I asked for examples? I want to see the kind of correction that this template performs which you claimed cannot be performed any in other way.—Codename Lisa (talk) 04:53, 22 April 2017 (UTC)

@Codename Lisa: I haven't searched through the other 18,000 pages, no. I'm also not claiming that the URL correction can't be done any other way, but I am claiming that removing such a widely used parameter us likely to break other templates that haven't yet been fixed or migrated, and it breaks them in a non-obvious way. --Ahecht (TALK
PAGE) 16:10, 22 April 2017 (UTC)

You said (1) "due to its ability to fix up a variety of malformed URLs [...], it has been widely used in a variety of templates other than infoboxes for sanitizing URL inputs." You added (2) "The suggested replacements don't serve the same purpose, as wiki markup doesn't support malformed or Wikidata URLs, [...]". I asked you to give me an example of this usage. You gave me an example (Template:Taxonbar/Link) for which quote #1 was true but quote #2 wasn't.

Now, I only asked for this example because you said "We shouldn't be removing the parameter unless we create a fork of this template" and I wanted to know how exactly I should fork it. Of course, it is quite fine with me if after some due diligence you have changed your mind. —Codename Lisa (talk) 17:28, 22 April 2017 (UTC)

I said We shouldn't be removing the parameter unless we create a fork of this template and migrate all existing templates using {{URL}} with a 2nd parameter to the new template. A fork can be as simple as an indentical copy of the template that doesn't use <span class="url"></span>, but we shouldn't remove the parameter here until other templates have been migrated over. I admit that fixing many templates, such as Template:Fiat are easy enough that a bot could potentially do it (changing {{URL|http://www.fiatprofessional.com|Fiat Professional S.p.A. website}} to [http://www.fiatprofessional.com Fiat Professional S.p.A. website] in that example). Other templates broken by this change such as {{USBill}} are less straightforward to fix, but we should do this work before removing the parameter. I haven't had more than a few minutes to look for more complex examples, but I will spend some time on it later this weekend. --Ahecht (TALK
PAGE) 23:10, 22 April 2017 (UTC)

It looks like finding how it's used in templates is going to be a needle in a haystack problem, since the TemplateParametersTool only seems to list usage in the article namespace, not the template namespace, and {{URL}} is transcluded in almost 600 templates. --Ahecht (TALK
PAGE) 03:33, 23 April 2017 (UTC)

So, all in all, it appears there is, as of yet, no need for forking anything. Standard deprecation process does it. FleetCommand (Speak your mind!) 04:23, 24 April 2017 (UTC)

It is disappointing that Codename Lisa is in the process of removing a perfectly valid parameter out of many articles, often claiming strange excuses as "language parameter" or template error. The Banner talk 19:18, 17 May 2017 (UTC)

@The Banner: Just doing my duty, sir. This parameter has been deprecated for years now. It is going to be removed. The problem with people like you is that all you see or willing to see a "perfectly valid parameter". You see nothing else, like the cost of it, or the consensus against it.

Best regards,
Codename Lisa (talk) 20:08, 17 May 2017 (UTC)

@Codename Lisa: A lot of your edits are causing changes that you may not be intending, so it is no surprise that you would get some complaints. For example: [1] [2] [3] [4] Your edit summaries say that the article renders the same as before, which is true, but the links now point to different URL's than what the editors intended. (Although curiously enough, the edits that The Banner is complaining about were perfectly valid fixes for straight-up syntax errors.) Toohool (talk) 20:47, 17 May 2017 (UTC)

@Toohool: Getting complaints is okay. But first, I am not getting complaints for the edits you are showing. The Banner's complaints are about something totally different. Second, although you might worry about the intent of the original editor, us TemplateEditors are actually encouraged to fix articles in why that does not impact their rendering. These revisions, per WP:SILENCE, are having consensus. Doing otherwise is construed as WP:BOLD and gives others the right to revert per WP:BRD. It is for all intents and purposes possible that the original editor eventually looked at his own mess and was satisfied with it. No, don't be surprised; people love short links.

Best regards,
Codename Lisa (talk) 20:56, 17 May 2017 (UTC)

@Codename Lisa: The fact that nobody scrutinized an edit closely enough to realize that it's a bad edit doesn't mean it has consensus. For example, in this edit to Collegedale Municipal Airport, the link previously pointed to http://www.collegedaletn.gov/index.aspx?NID=134, which is the airport's page on the city's official website. After your edit, the link points to http://collegedaletn.gov/..., which responds with a server error. My point is that in a lot of cases you seem to be mechanically removing one of the parameters without considering where the link should actually point to. The fact that the resulting page renders visually the same does not justify this. Toohool (talk) 21:16, 17 May 2017 (UTC)

@Toohool: Yes, my friend. I am mechanically doing this because I have recently come under fire for daring to guess what other people want. —Codename Lisa (talk) 21:22, 17 May 2017 (UTC)

@Codename Lisa: So you're being careless to make a POINT about some other criticism that you received? If you're not able or willing to do these edits in a constructive way, then just don't do them. Toohool (talk) 21:58, 17 May 2017 (UTC)

@Toohool: Having no impact on the article is not "disrupting Wikipedia to make a point". Leaving the functionality unchanged isn't disruption. Face it: You are criticizing me for not taking a step above and beyond my duty; something that I am free to do. —Codename Lisa (talk) 22:02, 17 May 2017 (UTC)

@Codename Lisa: Do you understand that you broke the link on Collegedale Municipal Airport? And that some of your other edits are changing the destinations of the links, i.e. not leaving the functionality unchanged? Toohool (talk) 22:14, 17 May 2017 (UTC)

There is no such thing as "duty" on Wikipecia. Beside that, why do you use fake summeries to hide what you are doing? The Banner talk 21:27, 17 May 2017 (UTC)

I wrote "Fixed syntax error in {{URL}}. This template does not have such parameters as |language=." That's entirely true. It is not fake. Have you seen its source code before accusing me? —Codename Lisa (talk) 21:43, 17 May 2017 (UTC)

Also, duty exists everywhere, and Wikipedia is not excluded. The only difference is that in Wikipedia, it is voluntary and unpaid. —Codename Lisa (talk) 21:45, 17 May 2017 (UTC)

@Codename Lisa: Duty or not, slow down a bit and give yourself enough time to get the edits right. This one, for example, replaced most of the links to the actual gazettes with links to generic top-level links to the government webpages. --Ahecht (TALK
PAGE) 22:14, 17 May 2017 (UTC)

I take no position on the deprecation of parameter 2, but best practice in deprecating parameters is to track their usage in main space with a maintenance category, and optionally to display an error message (sometimes only in edit preview mode). This helps find articles and templates that use the deprecated parameter. Once the category is empty, the parameter can be removed from the template. – Jonesey95 (talk) 15:04, 18 February 2018 (UTC)

Small changes made on fr.wiki

Hello, you might be interested in backporting these changes: [5] and [6] (edit, and this subsequent hotfix: [7]). Regards, Od1n (talk) 04:13, 23 February 2018 (UTC)

Hi.

So, basically, you are asking us to do this: [8]

It includes:

• Removing the local trim function and use mw.text.trim instead.
• Adding a local keyword to the SafeUri fuction.

I need to verify if it is alright.

Best regards,
Codename Lisa (talk) 12:38, 23 February 2018 (UTC)

 Done. —Codename Lisa (talk) 12:45, 23 February 2018 (UTC)

Yep, that's it. Thanks! Od1n (talk) 22:51, 23 February 2018 (UTC)

HTML class

At some point this template stopped applying the HTML class "url"; its raison d'etre. Does anyone know when this happened, and how to reverse it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:39, 19 April 2018 (UTC)

@Pigsonthewing: It still adds <span class="url">...</span>. What makes you think otherwise? It's done by return mw.ustring.format('<span class="url">[%s %s]</span>', url, text) in Module:URL. PrimeHunter (talk) 00:14, 20 April 2018 (UTC)

Using Firefox's "View Selection Source" on the first example in the table in the template's documentation, I see only <a rel="nofollow noopener noreferrer" class="external text" href="http://EXAMPLE.com" target="_blank">example<wbr>.com</a>; using "View Page Source", I do indeed see the span. Apologies for my mis-reading. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:09, 20 April 2018 (UTC)

Default to HTTPS

All links should default to https connection without specifying in parameters. The benefits outweigh the risk, and any possible error or breakage of links from this is not even worth considering at this point - HTTPS is the king standard. Wikipedia prides itself on security and shouldn't endorse possible breaches in the name of covering for a small contingency.--~Sıgehelmus♗_(Tøk) 21:37, 23 December 2018 (UTC)

No way. The first rule of editing templates is don't break things. That change would break many, many links all across the site. Toohool (talk) 04:38, 24 December 2018 (UTC)

How so? Can it not be failsafed back to http if the link is broken?--~Sıgehelmus♗_(Tøk) 05:21, 24 December 2018 (UTC)

No, template code does not have the ability to make a network call, such as would be needed to check if a particular hostname serves HTTPS. What we would need is a bot operator to setup a bot to go through all ~250,000 transclusions of this template to check for HTTPS availability, and flag those that don't have it, before the template default could be switched. Toohool (talk) 05:45, 24 December 2018 (UTC)

Oh, well I suppose it must be decided if the benefit is worth the effort for the bot idea. Sadly, HTTPS Everywhere is not integrated into vanilla mainstream browsers. I do not have enough knowledge of bot operation and such or even who to contact, so I guess all I can do is suggest the proposal.--~Sıgehelmus♗_(Tøk) 06:00, 24 December 2018 (UTC)

Turn off the "example" message

When the url parameter may be blank, it is sometimes advantageous to suppress the "{{URL|example.com|optional display text}}" message. This is particularly useful when fetching official website (P856) from Wikidata. I've made a quick modification to Module:URL/sandbox that implements a new named parameter, |msg=. If set to "no" or "false", it suppresses the "example" message and returns empty. That makes testing easier in infoboxes. See Template talk:Infobox person/Wikidata #Website with URL template. Here are some tests for the new functionality:

• >example.com<
• >example.com<
• >example.com<
• >example.com<
• >Sometext<
• >Sometext<
• >Sometext<
• >Sometext<
• ><
• ><
• ><
• >{{URL|example.com|optional display text}}<
• >{{URL|example.com|optional display text}}<
• >{{URL|example.com|optional display text}}<

I'll move the suppression of the message from the p.url function to the p._url function later, so that it will be available if the function is called from other modules as well. If this change is accepted for the main template, we should be able to implement wrapping the website in {{url}} in Template:Infobox person/Wikidata something like this:

• | data66 = {{if empty | {{url|{{#invoke:WikidataIB | getValue | rank=best |P856 |name=website |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced=no |noicon=y | {{{website|{{{homepage|}}}}}} }} |msg=no }} | {{url|{{#invoke:WikidataIB | getValue | rank=best |P1581 |name=blog |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced={{{onlysourced|no}}} |noicon={{{noicon|}}} }} |msg=no }} }}

I'll update the main template once I'm sure the sandbox version is working fully. --RexxS (talk) 19:38, 28 January 2019 (UTC)

[Update:] I've created a fork at Template:URL2 that suppresses the message by default and strips out html tags and wiki-links, so that it's more useful in infoboxes. See examples in the thread above. --RexxS (talk) 01:17, 29 January 2019 (UTC)

Infobox input may vary, same output preferred

I am working with template {{Infobox building}} that has |website=. The infobox shows this input unedited, unformatted. So the article editor can enter:

|website=www.example.org → www.example.org

|website=[www.example.org] → [www.example.org]

|website=[https://www.example.org] → [9]

|website=[www.example.org website] → [www.example.org website]

|website=[https://www.example.org website] → website

|website={{url|www.example.com}} → www.example.com

All are valid input, and accepting those input variants is editor-friendly (no detailed prescriptions in the documentation).

However, I would like to have the template format all input into a correct external link (as this {{URL}} does). Is there any template code conceivable or known that accepts all input forms, then reformats it as needed into good {{URL}}? -DePiep (talk) 08:04, 22 January 2019 (UTC)

@DePiep: Using {{url}} has quite a bit of url handling already, so it should be able to cope with reformatting most of the possibilities that editors might come up with. I've added some filters to the sandbox version which strip out html tags and wiki-link markup from the url parameter supplied, so that the infobox website parameter can be simply wrapped in {{url}} in the infobox design without causing problems if editors also wrap the local parameter in {{url}}:

• {{URL2|www.example.org&lang=en}} →
• {{URL2|[www.example.org]}} → www.example.org
• {{URL2|[https://www.example.org]}} → www.example.org
• {{URL2|[www.example.org website]}} → www.example.org
• {{URL2|[https://www.example.org website]}} → www.example.org
• {{URL2|{{url|www.example.com}}}} → www.example.com

There are some inconsistencies between http and https, but it might be close to being usable for what you want to do. I can't update {{url}} from {{URL/sandbox}} yet, because it really needs a lot more checking. I suppose you could simply fork the sandboxes into a new template and module, perhaps {{url2}} or something, if you want to use it sooner. Cheers --RexxS (talk) 00:30, 29 January 2019 (UTC)

[Update:] The testcases for Template:URL expect the template to handle things like www.example.com website, so it's not really compatible with the functionality we need in infoboxes. So I've separated out the html/wikimarkup stripping into a new Lua function url2 (that also suppresses the message {{URL|example.com|optional display text}} by default). I've created a new Template:URL2 which calls that function, so it should be more amenable for use in infoboxes. --RexxS (talk) 01:12, 29 January 2019 (UTC)

RexxS Thanks. More tests:

• {{URL2|{{url|www.example.com|labeltext}}}} → www.example.com -- use label
• {{URL2|{{URL2|www.example.com}}}} → www.example.com -- use URL2 nested
• {{URL2|{{URL2|www.example.com|labeltext}}}} → www.example.com -- use label, URL2 nested

Using |http://www.example.com/foo/bar?a=b&c=d input construct (bad parameter name; should use |url=):

• www.example.com/foo/bar?a=b&c=d -- {{url}} returns
• {{URL2|{{url|http://www.example.com/foo/bar?a=b&c=d}}}} → www.example.com/foo/bar?a=b&c=d -- {{URL2}} returns. I don't know how/if this one should be handled.

BTW naming uppercase "URL2" is consistent?

All this implies we should make this intended usage clear in the documentation ("use inside tempates only"). I understand the new |msg= will work as in regular {{url}}, so nothing strange to happen. I'll leave it up to you to declare fit for mainspace (= when the regular {{url}} changes I guess). Have a nice test. -DePiep (talk) 09:25, 29 January 2019 (UTC)

@DePiep: I'll have a look at those cases and see if I can clean them up at all. I don't think there's much I can do with {{url|http://www.example.com/foo/bar?a=b&c=d}} as input because it's already broken by the = signs, and would be whether or not it's wrapped in {{URL2}}. Obviously {{URL2|{{url|1=http://www.example.com/foo/bar?a=b&c=d}}}} produces www.example.com/foo/bar?a=b&c=d which is okay, I guess.

The naming is consistent, I think. I was surprised that this template lives at Template:URL although the commonest use that I see is via the redirect Template:Url (which provides the all lower-case version). It would be cheap to create Template:Url2 as a redirect for Template:URL2, but I wonder if common usage indicates that the templates should live at title-cased variants with the upper-case ones as redirects? --RexxS (talk) 13:20, 29 January 2019 (UTC)

ok. The bad = parameter is wrong but not ugly in regular {{url}} usage (and tracked IIRC), and in an infobox won't happen this way because input will be like |website=, and inside {{ULR2}} be {{URL2|url={{{website|}}}}}. So, all clear here. -DePiep (talk) 14:23, 29 January 2019 (UTC)

Merge functionality from URL2

The Module:URLWD is being discussed for deletion/merger at Wikipedia:Templates for discussion/Log/2019 February 19 #Module:URLWD. To retain the functionality of {{URL2}} in infoboxes in the long term (see threads above), we could update Module:URL from the present sandbox. As this does not affect the use of {{URL}} backwards compatibility will be ensured. I'd like to gain consensus here for implementing that update. For comparison, these are the differences in output:

Comparison of {{URL}} with {{URL2}}

Template:URL

Template:URL2

{{URL|}} → {{URL|example.com|optional display text}} {{URL|www.example.com}} → www.example.com {{URL|http://www.example.com}} → www.example.com {{URL|https://www.example.com}} → www.example.com {{URL|[www.example.com]}} → [http://[www.example.com] [www.example.com]] {{URL|[www.example.com website]}} → [http://[www.example.com%20website] [www.example.com%20website]] {{URL|{{URL|www.example.com}}}} → [<span%20class="url">.example.com www.example.com%20www<wbr/>.example<wbr/>.com]</span>] {{URL|{{URL|www.example.com}}}} → [<span%20class="url">.example.com www.example.com%20www<wbr/>.example<wbr/>.com]</span>]

{{URL2|}} → {{URL2|www.example.com}} → www.example.com {{URL2|http://www.example.com}} → www.example.com {{URL2|https://www.example.com}} → www.example.com {{URL2|[www.example.com]}} → www.example.com {{URL2|[www.example.com website]}} → www.example.com {{URL2|{{URL|www.example.com}}}} → www.example.com {{URL2|{{URL2|www.example.com}}}} → www.example.com

Please indicate whether you would support the update or not. Thanks, --RexxS (talk) 23:32, 20 February 2019 (UTC)

• Support as proposer. --RexxS (talk) 23:32, 20 February 2019 (UTC)

Bump

No comments after four days, so I've updated the main module from the sandbox. --RexxS (talk) 22:17, 24 February 2019 (UTC)

@RexxS: {{Official website}} looks broken, could that be caused by this change? the wub "?!" 22:26, 24 February 2019 (UTC)

@RexxS: Yes, lots of articles are showing "Lua error in Module:URL at line 31: attempt to index local 'msg' (a nil value)." Am having a quick look before undoing change to Module:URL. Johnuniq (talk) 22:44, 24 February 2019 (UTC)

Fixed. I was about to post the exact same fix! Johnuniq (talk) 22:48, 24 February 2019 (UTC)

(edit conflict) @The wub and Johnuniq: Indeed, it was my change that broke it. I had sanitised the msg parameter in the functions that are invoked, but not in the working function. That means it shows no extra problems in testcases, but it can fail when required by another module. One of the problems we have is that there's no quick way of checking what modules call other modules (like we have 'What links here' for templates), so I didn't check its use in {{Official website}}.

Anyway, it's easy to offer an empty string instead of a nil value for msg in the working function and I've done that now. Thanks for spotting those problems and letting me know so fast. --RexxS (talk) 22:57, 24 February 2019 (UTC)

Displaying uppercase letters within URL?

This inquiry (boxed below) was archived without any reply, and I'd belatedly like to "second" the request: Can this URL template please be upgraded to display uppercase letters when an editor provides them, so it's easier for humans to read & comprehend? —173.68.139.31 (talk) 04:52, 18 February 2019 (UTC)

I expect to have my casing shown in the presentation of the URL. Example: If I type TransUnion.com, I would like it to stay that way, not transunion.com – which is nearly illegible to me, have to work hard at it though. Is this even a possibility? —68.41.184.209 (talk) 01:24, 14 May 2016 (UTC)

It's quite possible. Maybe even simple. I've just removed the call that forces lower case at line 74 in Module:URL/sandbox-samecase.

• {{URL|TransUnion.com}} → transunion.com
• {{URL/sandbox-samecase|TransUnion.com}} → TransUnion.com

However, I think it really needs some testing before committing it to the live version at Module:URL. Perhaps someone can find some testcases? --RexxS (talk) 18:36, 18 February 2019 (UTC)

I think this change would require a well-advertised discussion. A "preserve case" option could be added without breaking existing usages. – Jonesey95 (talk) 19:44, 18 February 2019 (UTC)

Adding it as an option would be great, and presumably non-controversial. —173.68.139.31 (talk) 02:16, 28 February 2019 (UTC)

The correct URL in this case is https://www.transunion.com/ - all lower case. In eth spirit of MOS:TMSTYLE, we should not be styling it otherise. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:30, 5 March 2019 (UTC)

I don't think this is really an issue of trademark style – and even there, the main guideline on that MOS page is to "follow standard English capitalization", including an explicit statement that "CamelCase may be used where it reflects general usage and makes the trademark more readable." Indeed, the core idea of WP:Readers First is to make Wikipedia easier for humans to read. You'll find that TransUnion everywhere, including our own TransUnion article, uses this spelling consistently for readability. Domain names aren't case-sensitive, so TransUnion.com is as correct as transunion.com.

Actually, in our TransUnion article, now I see that an editor found a workaround to preserve the case of TransUnion.com while still using the URL template:

{{URL|https://www.transunion.com/|TransUnion.com}}

This syntax effectively provides the "preserve case" option that several of us have been looking for. So, I've just added this as another example in the Template description, and no coding change should be necessary to avoid unwanted lowercasing of domain names. Thanks for understanding. —173.68.139.31 (talk) 00:04, 6 March 2019 (UTC)

Template-protected edit request on 26 April 2019

Please correct a typo:

Change

--[[
The main entry point for caling from Template:URL.
--]]

to

--[[
The main entry point for calling from Template:URL.
--]]

(caling -> calling). Thanks, --DannyS712 (talk) 05:23, 26 April 2019 (UTC)

 Note: A typo in a comment which will have no visible effect is not worth forcing 350000 pages to be regenerated. I've made the change in the sandbox with a comment it should be incorporated into the next change. Special:Diff/894206747 -- Cabayi (talk) 09:48, 26 April 2019 (UTC)

Template-protected edit request on 24 July 2019

Please copy Module:URL/sandbox to Module:URL and remove the explicit passing of parameters into the module call in Template:URL, as done in Template:URL/sandbox. The changes fix the extraction of URLs that contain =. Danski454 (talk) 23:41, 24 July 2019 (UTC)

Just so I understand what this does, could you provide an example URL that the current live template fails to parse and your changes in the sandbox fix?. * Pppery * _{it has begun...} 14:28, 25 July 2019 (UTC)

From the test cases, {{URL|http://www.example.com/foo/bar?a=b&c=d}} does not work, due to the first part of the URL being interpreted as a parameter name:

Template	Sandbox
www.example.com/foo/bar?a=b&c=d	www.example.com/foo/bar?a=b&c=d

The recommended syntax for this URL would be {{URL|1=http://www.example.com/foo/bar?a=b&c=d}}, but around 100 pages that have URLs like this do not use the workaround. Someone in the past has attempted to make the module extract the URL, but this attempt did not work due to Lua interpreting an empty string as true. Danski454 (talk) 15:19, 26 July 2019 (UTC)

 Done. Apologies for asking you to provide a test case; I was under the impression that URL extraction without 1= had worked for years, and this edit request was thus fixing some obscure bug in it. * Pppery * _{it has begun...} 16:49, 26 July 2019 (UTC)

Remove the "www." from the URL label

Hello, please remove the "www." from the output of URL label same as "http://" and "https://" which are not shown.--Editor-1 (talk) 09:43, 11 April 2020 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. – Jonesey95 (talk) 13:24, 11 April 2020 (UTC)

The problem with that is that www.somesite.tld and somesite.tld are not guaranteed to be pointers to the same content. --RexxS (talk) 18:52, 11 April 2020 (UTC)

It is only about the label that is shown in the info-box, nothing is going to change the entered/provided URL; currently if www. is not entered, it is not shown and added automatically to the rendered label and the provided URL; also per www.: "The use of www is not required by any technical or policy standard and many web sites do not use it;".--Editor-1 (talk) 04:38, 12 April 2020 (UTC)

It would be misleading to show a partial url that may not work, and some sites include "www." in marketing even if it's optional. PrimeHunter (talk) 12:36, 12 April 2020 (UTC)

Discussion at Wikipedia:Bot requests § Adding url template to bare infobox websites

 You are invited to join the discussion at Wikipedia:Bot requests § Adding url template to bare infobox websites. — Goszei (talk) 05:35, 21 August 2021 (UTC) — Goszei (talk) 05:35, 21 August 2021 (UTC)

Removing deprecated argument

Hi, in the description is mentioned that the second parameter (i.e., "Display text") is deprecated. But why this argument now exists in "website" section of Infobox of the articles like Tim Berners-Lee by over 4000 visitors in a day? Shall I remove this argument from Template:url in this article and all similar usage of "Template:Infobox person"? Thanks, Hooman Mallahzadeh (talk) 08:27, 22 June 2021 (UTC)

Isn't it better to automatically neglect the third argument, by modifying the code of this template, instead of massive task of removing third argument in its usages in a huge number of articles? Thanks, Hooman Mallahzadeh (talk) 12:56, 22 June 2021 (UTC)

silly question, when did we go to 1= 2= and who then decided we don't need 2= anymore, ? 300,000 links to ? Dave Rave (talk) 21:12, 20 October 2021 (UTC)

{{Official website}} and {{URL}}s

See discussion: https://en.wikipedia.org/wiki/Template_talk:Official_website#Infoboxes --Avoinlähde (talk) 21:19, 28 March 2022 (UTC)

Wrapping

In Chicago Steel, I replaced http://chicagosteelhockeyteam.com with {{url|http://chicagosteelhockeyteam.com}} which I expect to render the same visual output. However, when using the template in the infobox, the url wrapped onto two lines. Rather than adding a {{nowrap}} to this article, is there an explanation and possible update to the template? Jonesey95? MB 19:29, 31 March 2022 (UTC)

I don't think there is a good, generalized way to fix this without breaking other uses of either that infobox or Template:URL, since some URLs are very long and should probably wrap. In this case, I used Template:nowrap around the URL template. There may be a more elegant way to achieve the same outcome. – Jonesey95 (talk) 20:32, 31 March 2022 (UTC)

Jonesey95, the strings are both 26 characters plus the link symbol. Why does it wrap only if the URL template is used? I wasn't suggesting to add nowrap within the URL template; I was wondering what the difference is. Is the URL template adding some invisible characters that are causing the wrap that shouldn't be there. Although if that were the case, they probably wouldn't make the string "longer". MB 22:39, 31 March 2022 (UTC)

I just looked at the documentation for {{URL}} and it says it adds <wbr /> before all displayed periods. I guess that explains it. Thanks. MB 22:49, 31 March 2022 (UTC)

Template-protected edit request on 15 May 2022

optional display text] as it is currently being used. This was origionally suggested by @Avoinlähde at Template talk:Official website#Infoboxes, I think this would be most suitable being implemented in {{URL|example.com|optional display text}} as it the one used in infoboxes. DownTownRich (talk) 17:34, 15 May 2022 (UTC)

Just realized request is not showing properly. The request was that {{URL}} show the URL from Wikidata instead of showing {{URL|example.com|optional display text}}. This was originally suggested by @Avoinlähde at Template talk:Official website#Infoboxes but I think it is best implemented in Template:URL as it is used in infoboxes. - DownTownRich (talk) 17:41, 15 May 2022 (UTC)

 Not done See Wikipedia:Templates for discussion/Log/2016 October 8#Template:Official URL; it's not appropriate to try to use a TPER to overturn a TFD * Pppery * _{it has begun...} 19:28, 15 May 2022 (UTC)

https?

The documentation says: "If it doesn't start with a URI scheme ... the prefix "https://" is prepended". Is that what is supposed to happen? It's not what I'm seeing. I'm getting "http://" without the 's'. This is firefox 97 if that makes a difference. GA-RT-22 (talk) 19:43, 27 May 2022 (UTC)

The documentation was edited on the 2nd May 2022 by User:PRY86400. I've fixed the error and it now says http:// again. -- WOSlinker (talk) 21:19, 27 May 2022 (UTC)