Template talk:Libera.Chat
Template:Libera.Chat is permanently protected from editing because 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. |
RfC: Template modification
edit- The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
- No need for formal closure, a clear consensus has been reached, change already enacted. PhantomTech forgot to conclude the RfC with an archive template. Esquivalience t 22:31, 30 May 2015 (UTC)
Should the changes in revision 655008232 be applied? PhantomTech (talk) 22:14, 6 April 2015 (UTC)
- In its current state, any link which appears to go to a channel with multiple # goes to the channel with one less. The proposed change causes the template to behave as is explained in the docs and how it did prior to November 4 2014, when the change that the proposed one undoes was introduced. Any template that currently attempts to link to a channel with more than one # misleads the user by showing the name with an extra #. This change does not break any transclusions which show a link to the proper channel, the transclusions it does break are broken in the sense that they will go to the channel they say they do, feel free to test that. Here's a table showing the changes and issue:
Now → Post-change Parameter Channel linked to Link text Parameter Channel linked to Link text channel #channel #channel connect channel #channel #channel connect #channel #channel ##channel connect #channel ##channel ##channel connect ##channel ##channel ###channel connect ##channel ###channel ###channel connect
- Notice that in the current version, the link's text does not always match the channel the link goes to. PhantomTech (talk) 22:14, 6 April 2015 (UTC)
- I prefer the template to behave the way an IRC client itself would. I believe all IRC clients on Freenode automatically insert a # if you type a bare word as the channel name. For example, if i type /join wikipedia-en, it takes me to #wikipedia-en. Typing /join #wikipedia-en would also take me to #wikipedia-en, and typing /join ##penguins would take me to ##penguins. In other words, Freenode just assumes that if there are zero #'s there should be one, and if there is one there should still be one, and if there are more than one it is also treated as that number. So since Im not entirely clear how the template behaved before Nov 2014, Im not sure I support either one of these options. —Soap— 03:09, 7 April 2015 (UTC)
- You're right, freenode will automatically take you to #channel if you try to join channel or #channel, but according to this templates docs, that isn't how the template is "supposed" to work and so making that change could break some templates, or more accurately, keep them broken. That said, I have no opposition to this change since that's probably how it should have been set up in the first place. My issue with the current version is a link that looks like it should take you to a channel with more than one # will take you to the channel with one less, (example: link ##channel goes to #channel) something that is easily fixed by my change with no negative effects. PhantomTech (talk) 04:12, 7 April 2015 (UTC)
- Comment I've updated the sandbox with PhantomTech's proposed code, and I am working on finding the Lua module that Theopolisme (IIRC) started working on to take over for this template to deal with this situation as-well-as add the ability to add the visitor's nick to the link to match their username on enwp as closely as possible. I'll be back once I find that and see what state it was left in by Theo and myself. I've also updated the table to offer live examples. I'll not that I don't specifically object to this change, but due to the very high transclusion rate, I want to make sure that it is done correctly and all uses of the template are properly updated before/as the change is made. —
{{U|Technical 13}} (e • t • c)
11:57, 7 April 2015 (UTC)
- This "situation" doesn't require a module to be fixed and attempting to make one to do so unnecessarily complicates and delays the fix, even more than it already has been. If you want to try to add anything to the template other than this, feel free to keep working on it but please don't let it delay something that could have been done a few days ago. If you want to check to see how this change affects current transclusions feel free, but I would be amazed if you were able to find a single transclusion where this change couldn't be considered a fix, even Soap's change would hardly affect any current transclusions. PhantomTech (talk) 19:08, 7 April 2015 (UTC)
- Well, in that case, once you update all of the existing uses of the template to explicitly have the #, then we can make changes to this template. Otherwise, all of the occurrences will break and I won't support that. —
{{U|Technical 13}} (e • t • c)
20:21, 7 April 2015 (UTC)
- I'm still not aware of a single transclusion that would be broken by the proposed change. In fact, adding a # to current transclusions would cause the proposed change to break them and would not affect (i.e. be completely pointless) transclusions if Soap's change was made. PhantomTech (talk) 20:55, 7 April 2015 (UTC)
- Well, in that case, once you update all of the existing uses of the template to explicitly have the #, then we can make changes to this template. Otherwise, all of the occurrences will break and I won't support that. —
- @Technical 13: I'd be interested to see an example of a template that it would be breaking, or two examples, or three. — kikichugirl oh hello! 03:16, 8 April 2015 (UTC)
- It changes the behavior of the end result. Going to #channel loads up the IRC client and focuses on the the channel, Going to channel loads up the IRC client and takes you to the status pane. All of the instances where no preceding # is used in the parameter will be broken if this change is made and there will be NO WAY for people to have that behavior using this template. —
{{U|Technical 13}} (e • t • c)
18:55, 9 April 2015 (UTC)
- It changes the behavior of the end result. Going to #channel loads up the IRC client and focuses on the the channel, Going to channel loads up the IRC client and takes you to the status pane. All of the instances where no preceding # is used in the parameter will be broken if this change is made and there will be NO WAY for people to have that behavior using this template. —
- This "situation" doesn't require a module to be fixed and attempting to make one to do so unnecessarily complicates and delays the fix, even more than it already has been. If you want to try to add anything to the template other than this, feel free to keep working on it but please don't let it delay something that could have been done a few days ago. If you want to check to see how this change affects current transclusions feel free, but I would be amazed if you were able to find a single transclusion where this change couldn't be considered a fix, even Soap's change would hardly affect any current transclusions. PhantomTech (talk) 19:08, 7 April 2015 (UTC)
OpposeSupport the modification.I'd rather have the template behave the same way as a standard IRC client.Also, question: is there any reason why the "link label" doesn't reflect the channel which the link takes users to? APerson (talk!) 15:18, 9 April 2015 (UTC) changed to support at 15:48, 9 April 2015 (UTC)- @APerson: The mismatch between link text and link targets is the problem the proposed change fixes. In its current state, it is impossible to link to a channel with two or more hashes, like ##chanel, and have the link display the right number of hashes. The change fixes that issue without breaking any current transclusions, though the parameter would not behave exactly as an IRC client. PhantomTech (talk) 15:38, 9 April 2015 (UTC)
- PhantomTech - oh yeah, you're right. I must have misread the template code. I changed my vote to support. APerson (talk!) 15:48, 9 April 2015 (UTC)
- This proposed change still breaks the expected behavior of loading into IRC with the status window in focus when "channel" is used as opposed to "#channel". In order for me to support this change, the talk page of every usage of "channel" will need to have a discussion about where that project wants the user to load. I know that when I use this on talk page discussions, I specifically leave off the # so that people will load to the status window and will know if they need to pick another nick because the one they want is taken or registered and won't be stuck being Guest##### unexpectedly. —
{{U|Technical 13}} (e • t • c)
18:55, 9 April 2015 (UTC)
- This proposed change still breaks the expected behavior of loading into IRC with the status window in focus when "channel" is used as opposed to "#channel". In order for me to support this change, the talk page of every usage of "channel" will need to have a discussion about where that project wants the user to load. I know that when I use this on talk page discussions, I specifically leave off the # so that people will load to the status window and will know if they need to pick another nick because the one they want is taken or registered and won't be stuck being Guest##### unexpectedly. —
- PhantomTech - oh yeah, you're right. I must have misread the template code. I changed my vote to support. APerson (talk!) 15:48, 9 April 2015 (UTC)
- @APerson: The mismatch between link text and link targets is the problem the proposed change fixes. In its current state, it is impossible to link to a channel with two or more hashes, like ##chanel, and have the link display the right number of hashes. The change fixes that issue without breaking any current transclusions, though the parameter would not behave exactly as an IRC client. PhantomTech (talk) 15:38, 9 April 2015 (UTC)
- Is the idea that it is expected for the link to a channel to take you to a status window some sort of common knowledge that I'm simply unaware of? I haven't been around here as long as some people, but last time I checked, when a policy is changed it isn't proposed on the talk pages of every affected article, I don't see why making a template work the way it did before November 4th 2014 and how it has always said it works in its docs would be more complicated than a policy change. Maybe I'm missing something but I have the strangest feeling that most people using these links use the connect button, not an IRC client. I also have a weird feeling that the shock(?) experienced by users of IRC clients when they are given a Guest nick, which realistically can only happen about once per user since if they've connected to Freenode before they've probably found a nick they like that isn't taken, isn't too severe. After all, if they're using an IRC client they're probably pretty familiar with how to change their nick and the few second delay it takes them to realize the nick they chose was taken isn't going to inconvenience them much, definitely not as much as anyone trying to link to a channel with more than one hash is currently being inconvenienced. PhantomTech (talk) 04:35, 10 April 2015 (UTC)
- Support the modification. After reading all of the arguments for and against, and asking Technical 13 to provide a straight-up specific example of a template that would be broken I found no compelling reason to retain the template in the way it is. I have a transclusion of this template on my userpage, the way docs said to, and I'm hoping that it will one day actually take visitors to the right channel, while displaying the correct number of hashes. It appears as if PhantomTech's proposal will solve this problem. As PhantomTech said, The blue button takes you through to your iRC client (which means you already know how to use IRC and can change your nick), the green one takes you to the webchat (and hopefully, the channel with the correct number of hashes.) — kikichugirl oh hello! 19:16, 10 April 2015 (UTC)
- Support as per kikichu. Unless you can produce a place where it would break the template, I see no reason why the change should not be made. TheMesquitobuzz 03:15, 12 April 2015 (UTC)
- Support the modification. It cleans up the template transclution code. Rider ranger47 Talk 00:12, 15 April 2015 (UTC)
- Here are example transclusions in my sandbox showing what the current version does. I have tested the first two in HexChat and they both go to a single-hash channel, contrary to what the documentation says should happen, so something does need to be done, though I can't say for sure what. Either Soap's or PhantomTech's changes would be good. ekips39 (talk) 03:56, 17 April 2015 (UTC)
- The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.
Template-protected edit request on 6 May 2015
editThis edit request to Template:Freenode has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Per consensus above, restore the changes in Special:diff/655008232. PHANTOMTECH (talk) 23:31, 6 May 2015 (UTC)
- Done Alakzi (talk) 23:37, 6 May 2015 (UTC)
Redirecting to help disclaimer
editPer Special:Diff/664524277, freenode links to #wikipedia-en-help need to go through Wikipedia:IRC help disclaimer. Would it be possible to add an #if statement so that if the parameter is #wikipeda-en-help it goes to the disclaimer rather than the freenode connect page? Primefac (talk) 01:51, 2 October 2015 (UTC)
Update template
editSee User_talk:Primefac#About_IRC_templates (now archived) for more info, but it looks like the [[freenode:...
links aren't working properly any more. Primefac (talk) 15:28, 18 November 2020 (UTC)
Update webchat
editThis edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Libera has now it's own webchat, thus please replace https://kiwiirc.com/nextclient/irc.libera.chat/
with https://web.libera.chat/?channel=#
. Regards --Zabe (talk) 11:22, 28 May 2021 (UTC)
- Not done for now: There are certain tools, scripts, and settings we have set up with Kiwi (mainly regarding automatic granting of usernames). Will these settings port over? Primefac (talk) 13:55, 28 May 2021 (UTC)
- @Primefac: The libera webchat is just an embeded version of kiwi irc, like the freenode webchat linked before, so there shouldn't be be any issues. --Zabe (talk) 09:34, 30 May 2021 (UTC)
- Done. Primefac (talk) 10:29, 30 May 2021 (UTC)
- @Primefac: The libera webchat is just an embeded version of kiwi irc, like the freenode webchat linked before, so there shouldn't be be any issues. --Zabe (talk) 09:34, 30 May 2021 (UTC)
Template-protected edit request on 22 June 2022
editThis edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Update template to the version at User:PhantomTech/sandbox/Libera.Chat.
The template previously made the channel name text an irc:// link to the channel, allowing users with IRC clients that support handling irc:// links to click on the channel name and have their IRC client connect to it. This was removed, the reason seems to be because it was broken. The version in my sandbox makes the following changes:
- The channel name will once again be a link, this time an ircs:// link which indicates to the client that a "secure" connection should be made. This will allow anyone using an IRC client that supports handling ircs:// links to connect to the channel through their IRC client by clicking the link on the channel name.
- When the channel name is wikipedia-en-help, the channel name will be a link to maintain a consistent appearance. However, it will link to Wikipedia:IRC help disclaimer, just as the "connect" link, due to current consensus. If this change is implemented I might try to create a similar ircs:// link on the disclaimer page to make it easier for people to use their own clients if I can think of a way that wouldn't be too intrusive or confusing for people who don't use their own client.
Testing: A test page is located at User:PhantomTech/sandbox/Libera.Chat/testcases. Not all clients can handle irc or ircs links, I tested the links using HexChat and they all worked as intended for me. If a user doesn't have any clients that can handle the link, nothing will happen when it is clicked. Using # instead of %23 in the channel name is discouraged by IETF draft but I was not able to get the links to work correctly when URL encoding the # and having it not encoded is allowed per the draft. The ischannel parameter was also required to get it to work despite the draft saying it should be assumed when omitted. While trying to fix issues I saw reports that some clients may handle a link with a single # in it as to a ## channel, as best as I can tell this is an implementation issue in the client and something that needs to be fixed by that client's developer(s). PHANTOMTECH (talk) 22:20, 22 June 2022 (UTC)
- Not done for now: I mark it this way because one of the other reasons (and I have legitimately spent five minutes looking for the thread and cannot find it) for removal of the link was the "surprise" factor, i.e it makes total sense to click a "connect" link but less so to have two links that give different ways of connecting. If this line of thinking is no longer one that holds a strong consensus, then I don't see any reason to go back to the old way, but I do no know it was discussed and it was the reason why we never re-added in a link there. Primefac (talk) 07:25, 23 June 2022 (UTC)
- @Primefac Do you want me to start an RfC or just leave this for a few days to see if anyone opposes the change? PHANTOMTECH (talk) 07:42, 23 June 2022 (UTC)
- I don't think this needs a formal RFC, but it probably needs some cross-posting since this page is only watched by 13 folks. That being said, if no one other than me objects (and/or I cannot find the older discussion) then I suppose we can implement those changes. Primefac (talk) 08:17, 23 June 2022 (UTC)
- Crossposted to WT:IRC. PHANTOMTECH (talk) 08:47, 23 June 2022 (UTC)
- @Primefac It's been a couple of weeks and no one has objected to the change. If you personally prefer the current version, I don't have a problem with it not being changed. I made the request because I thought I was fixing a feature that had been removed because it was broken, I don't have a strong preference for either version. PHANTOMTECH (talk) 08:53, 7 July 2022 (UTC)
- The short answer is yes, but I'll elaborate below. Primefac (talk) 20:29, 7 July 2022 (UTC)
- I don't think this needs a formal RFC, but it probably needs some cross-posting since this page is only watched by 13 folks. That being said, if no one other than me objects (and/or I cannot find the older discussion) then I suppose we can implement those changes. Primefac (talk) 08:17, 23 June 2022 (UTC)
- @Primefac Do you want me to start an RfC or just leave this for a few days to see if anyone opposes the change? PHANTOMTECH (talk) 07:42, 23 June 2022 (UTC)
- No real preference from me on having the channel name linked or not. My gripe (which may or may not be out of scope for this edit req, and is also such a minor gripe to be hardly worth it so feel free to tell me to go away) is with the "connect" link going to the web client. I think I'd personally prefer renaming "connect" to "webchat" or something along those lines, and I guess this becomes slightly more important if we've got two links. stwalkerster (talk) 20:18, 7 July 2022 (UTC)
- Recognising that I have no diff to point to, but the conversation I remember having was that having the channel name linked (in the style of a wikilink) but then opening up an :irc: link was problematic from an EGG perspective, especially when the "connect" link had a completely different functionality. As an aside, I genuinely don't know who would be connecting to a channel without going through the web client; i.e. if I (personally) see an IRC link, I switch to IRC and then /join the channel (i.e. anyone who would be using a client-based IRC connection is probably already connected), so seeing "connect" (which let's be honest, is probably 90% IRCHELP folks anyway) gives the indication of "oh, I guess I'll be connecting to that channel".
- Annoyingly enough I do recognise this is largely a bike shed issue, with three mostly-apathetic folks who are likely a) not the target audience of this template, and b) can find reasonably good arguments for both changing and keeping status quo. So if no one has a strong preference... what do we do? Primefac (talk) 20:29, 7 July 2022 (UTC)
- I agree with "webchat" over "connect" if there's going to be two links that both intend to connect you in some way. I don't have a preference between connect and webchat with just one link, connect seems like simpler language that more people are likely to understand but at the same time webchat isn't complicated itself. I can see how having the ircs link on the channel name could make things confusing for people. There is no feedback if you don't have an IRC client that supports those links, it just does nothing. I tried putting a blue "ircs://" link after a green "webchat" link and think that might also confuse some people so I think with the ircs links it should be left for now, and again I have no preference between "webchat" and "connect" when there's just one link. PHANTOMTECH (talk) 21:13, 7 July 2022 (UTC)
- Would it be too clunky to have something like #wikipedia-enwebchat / client or something similar? It eliminates the link-in-text issue but still provides a standalone client-based link. Primefac (talk) 04:56, 8 July 2022 (UTC)
- I've updated the template in my userspacetest cases to use webchat instead of connect and stack client over webchat when not linking to #wikipedia-en-help. I've also put the channel name in <code> tags, again only when not going to #wikipedia-en-help, to make it stand out better as distinct, especially when used inline, but there are alternatives like bolding that could be used, I'm not sure if it's needed at all. PHANTOMTECH (talk) 06:19, 8 July 2022 (UTC)
- Would it be too clunky to have something like #wikipedia-enwebchat / client or something similar? It eliminates the link-in-text issue but still provides a standalone client-based link. Primefac (talk) 04:56, 8 July 2022 (UTC)
- I agree with "webchat" over "connect" if there's going to be two links that both intend to connect you in some way. I don't have a preference between connect and webchat with just one link, connect seems like simpler language that more people are likely to understand but at the same time webchat isn't complicated itself. I can see how having the ircs link on the channel name could make things confusing for people. There is no feedback if you don't have an IRC client that supports those links, it just does nothing. I tried putting a blue "ircs://" link after a green "webchat" link and think that might also confuse some people so I think with the ircs links it should be left for now, and again I have no preference between "webchat" and "connect" when there's just one link. PHANTOMTECH (talk) 21:13, 7 July 2022 (UTC)
Edit request to complete TfD nomination
editThis edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Template:Libera.Chat has been listed at Templates for discussion (nomination), but it was protected, so it could not be tagged. Please add:
{{subst:tfm|help=off|1=Channel}}
to the top of the page to complete the nomination. Thank you. PHANTOMTECH [TALK]
07:08, 15 July 2022 (UTC)
Template-protected edit request on 24 July 2022
editThis edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Implement the changes from these sandbox edits to allow merging per Wikipedia:Templates for discussion/Log/2022 July 15#Template:Libera.Chat and remove the merge discussion notification. PhantomTech[talk]
17:31, 24 July 2022 (UTC)