Template talk:R from domain name

Proposal to merge R from dotcom into here

I have proposed this merger because, although this template is somewhat newer than Template:R from dotcom, this one is used a lot more extensively and its name is bigger-encompassing, more clearly indicating that it can be applied to titles with .edu and .org suffixes. Thoughts? If there's no disagreement, I'll go ahead and perform the merger. $\sim$ Lenoxus " * " 21:33, 16 April 2008 (UTC)

R from .com domains

I just saw the subcategories in Category:Redirects_from_domain_names today. These categories are manually added to the redirects and not with a R from templates. I suggest that this template (R from domain name) just check the ending of the redirect title and then add a second category i.e. Category:Redirects from .com domain names. Christian75 (talk) 14:31, 5 February 2019 (UTC)
It could be made with something like, {{#ifeq:{{#invoke:String|match|{{PAGENAME}}|%.com$|nomatch=nomatch}}|.com|[[Category:Redirects from .com domain names]]}}. Christian75 (talk) 14:59, 9 February 2019 (UTC)

Good idea? Can someone with enough editing skill (and user rights) do this? --Geolodus (talk) 09:32, 17 February 2019 (UTC)

I think it is probably easier to do this simply with a new parameter. This would also help with edge cases, such as where a redirect title doesn't actually contain the domain name (such as steamcommunity or target com). I added an optional |domain= parameter to the sandbox; if no one opposes I think it should be fine to just add it. ―Jochem van Hees (talk) 15:00, 16 June 2021 (UTC)

And then of course it should be recommended to use the new parameter in the documentation. Maybe there could even be a tracking category for transclusions that don't include the parameter or something, because in almost all cases the parameter should be used. ―Jochem van Hees (talk) 16:24, 16 June 2021 (UTC)

Purpose

I changed the text:

This is a redirect ... to an article about a website (or the entity to which the official website belongs) that is more often referred to by its short name or company name rather than its domain name

to:

This is a redirect ... to an article about an associated entity or website, which is more often referred to by its official name than by its domain name.

This seemed more useful, since there are way more articles about people and organizations that have websites than about websites themselves. —Sangdeboeuf (talk) 20:39, 4 September 2020 (UTC)

Template-protected edit request on 13 September 2021

Implement the changes to the sandbox that improve the |domain= parameter. You no longer have to precede the domain name with a dot, and the domain name will be displayed on the template. Otherwise the template will instruct you to add the domain parameter. I have tested these changes and they appear to work. ―Jochem van Hees (talk) 11:56, 13 September 2021 (UTC)

 Not done Greetings Jochem van Hees. The main purpose of these Rcat templates is categorization. While the changes are asthetic improvements, they can not be implemented unless they properly sort the domains into their appropriate subcategory. If you correct this, you can reinstated the request by changing the |answered= parameter from yes to no.--John Cline (talk) 13:18, 14 September 2021 (UTC)

@John Cline: I think I made them correctly sort in the appropriate subcategory? If I for example use |domain=.com then it will categorise it under both Category:Redirects from .com domain names and Category:Redirects from domain names. Or should it only be the subcat? ―Jochem van Hees (talk) 14:34, 14 September 2021 (UTC)

That's correct Jochem van Hees, the only redirects that should be in the main category are redirects that use the template without any parameters, specifically |1= (or the 1st unnamed parameter) or |domain=. Ostensibly this is to allow users willing to visit these pages to add the unused parameter and sort them from the main category into the appropriate subcategory. One other thing, which I did not check but is important: because these templates are transcluded, you must maintain the functionality in current use and your changes can not have a detrimental affect on the pages where the template is already in use. In particular I'm concerned that where you cause the parameter to accept |1=com yet render as .com doesn't cause the parameters in use that use |1=.com to render as ..com possibly emptying the .com subcategory and moving the pages to a red/non-existent ..com subcategory. I didn't look at the template's coding but I suspect it will be a significant challenge to bring all these things together. Best regards.--John Cline (talk) 15:41, 14 September 2021 (UTC)

I have now changed it so that they only get categorised in the subcategory. I have also double checked that the template now works exactly the same way with or without the dot (see also the testcases). ―Jochem van Hees (talk) 15:54, 14 September 2021 (UTC)

 Done Nice work Jochem van Hees I did verify that everything is in order and, in my opinion, improved overall. If you would, please copyedit the template's documentation subpage so that everything accords with its new and fuller functionality. Thank you for your efforts and interest in this area.--John Cline (talk) 17:15, 14 September 2021 (UTC)

Ripe for automation

I see Christian75, Glades12, and Jochem van Hees were discussing automatically filling the .com subcategory above. I agree and think we can probably go further. This template should be extracting the top-level domain from the title, checking to see if it matches a subcategory, and sorting it automatically if so. There will still be some edge cases that'll need doing manually, like the Target example above, but the vast majority can be automated, and that'll save us a lot of busywork. {{u|Sdkb}} ^talk 03:41, 18 November 2021 (UTC)

I wasn't so sure about automating because there will always be those oddly titled redirects that mess it up. But I guess as long as the |domain= parameter is preferred I think it could work. ―Jochem van Hees (talk) 10:29, 18 November 2021 (UTC)

|domain= will always override any automatic detection. The only situation we need to be worried about is a page title that ends in one domain with a category but actually belongs in a different one, since those would be miscategorized until overridden. I can't think of any circumstance in which what could happen—can you? {{u|Sdkb}} ^talk 16:07, 18 November 2021 (UTC)

No, I highly doubt that'd be a problem. The ones I mentioned earlier, steamcommunity and target com, don't have a dot at all in their name and therefore should just default to the main category. I made a test on the sandbox that works as far as I can tell, although it does involve using the same regex four times. I wonder if there is a smarter solution. ―Jochem van Hees (talk) 16:17, 18 November 2021 (UTC)

@EN-Jungwon, bringing this to your attention, since I've seen you making a bunch of edits to these recently. It really doesn't make sense to hardcode the fact that Payscale.com is a redirect to a website, rather than just deriving that information from the page name. {{u|Sdkb}} ^talk 02:47, 21 December 2021 (UTC)

@Sdkb, I agree that this can be automated in some way. Unfortunately I'm of no help as I have very little clue about how templates work. EN-Jungwon 15:48, 21 December 2021 (UTC)

The sandbox test from @Jochem van Hees appears to work fine, based on the preview checks I just did at Amazon.sg, Target com, and Payscale.com. As this has sat for a month with no concerns, I'm going to call that sufficient consensus to proceed and implement. If any bugs/concerns crop up, please let me know. Cheers, {{u|Sdkb}} ^talk 20:34, 21 December 2021 (UTC)

Creating redirects by bot

 You are invited to join the discussion at Wikipedia:Bot requests § Redirects from organization/newspaper domain names. {{u|Sdkb}} ^talk 08:28, 12 October 2023 (UTC)

Template-protected edit request on 5 May 2024

Add {{lowercase title}}. Website domain names are always written in all lowercase. InfiniteNexus (talk) 06:58, 5 May 2024 (UTC)