Template talk:URL

Template:URL is permanently protected from editing as it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.

Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

This template was considered for deletion on 2016 October 8. The result of the discussion was "no consensus to merge".

Archives

Archive 1

Archive 2

This page has archives. Sections older than 28 days may be auto-archived by if there are more than 3.

Is there any reason to trim "www" from the displayed URL?

Template:URL is designed to display the "www" as part of the link displayed and is clear that "Parameter 2 ({{URL|url name|optional display text}}) is deprecated"; I certainly don't see any reason to manually remove the "www" using parameter 2. Is there any reason to make edits such as this one, one example of many, whose only purpose is to trim the "www"? There was this discussion from 2020 that leaned against removal of the "www". Does this still stand and if so should there be a clearer admonition in Template:URL discouraging the practice? Alansohn (talk) 17:21, 12 August 2024 (UTC)[reply]

I would describe that edit as mildly negative, not helpful. It made the displayed URL longer, wrapping it in my display. The previous, shorter URL did not wrap. Since |2= is deprecated, a better edit would have been to remove "www" from |1= while removing |2=, after checking that the resulting URL worked, of course. – Jonesey95 (talk) 21:18, 12 August 2024 (UTC)[reply]

URL template, capitalization and screenreaders

User:ChirpingEmu has changed a few dozen articles, including this edit, in which links were taken out of the URL template, with the edit summary "reformatted URL for screenreader accessibility". On their talk page, the user stated that they are "using Apple’s built-in screenreader to ensure that the URL is spoken correctly. Usually, changing the capitalization of parts of the URL does the trick" but that "The issue with the URL template is that it’s not case-sensitive." Alansohn (talk) 21:44, 3 October 2025 (UTC)[reply]

Edit request 10 November 2025

This edit request to Module:URL has been answered. Set the |answered= parameter to no to reactivate your request.

Please sync code from sandbox: This inserts a check for a pre-formatted url. This will allow the use of {{url}} in a template. So for example if {{infobox settlement}} has:

| data1 = {{url|{{{website|}}}}}

You can now safely pass:

| website = {{url|google.com}}

without the template blowing up. Technically I can make this change myself, but would like a 2nd set of eyes to review it. Note that Module talk:URL/testcases had a failing test case before I made my change to the sandbox. It is unrelated to my changes. The other failing test, at the top of the page, is expected as it specifically tests the case that I am trying to fix. The sandbox version handles it correctly, the live version does not.

Diff:

Zackmann (^{Talk to me}/_{What I been doing}) 20:03, 10 November 2025 (UTC)[reply]

The testcases look like an improvement to me. Since this module is used in 647,000 pages, I wouldn't mind having a module editor review the code changes. If nothing happens in a few days, I will be happy to implement the changes and see if any bugs crop up. I anticipate finding more edge cases that would need to be added to the testcases page, but sometimes the best way to find those is by making errors appear in the wild (unfortunately). – Jonesey95 (talk) 00:29, 11 November 2025 (UTC)[reply]

Going to go ahead and implement this. Hopefully it doesn't blow up... If it does, we revert! --Zackmann (^{Talk to me}/_{What I been doing}) 22:06, 12 November 2025 (UTC)[reply]