Template talk:Episode table/Archive 2

Archive 1

Archive 2

Archive 3

Template-protected edit request on 21 February 2020

{{edit template-protected|Module:Episode table|answered=no}} Please sync the module with Special:Permalink/941969397. It adds a new wrapper template for use at the end of the constructed tables.

Tested: here –MJL ‐Talk‐^☖ 19:32, 21 February 2020 (UTC)

MJL, why would a duplicate header row at the bottom of the table? In which scenario would this be required? In almost six years of being a WP:TV editor, I have never seen such a case. -- /Alex/₂₁ 21:30, 21 February 2020 (UTC)

@Alex 21: I was making List of Homicide episodes at the time I wrote that, and seasons of the show had upwards of 45+ episodes. At it certain point it becomes more inconvenient to scroll upwards than downwards to figure out what each column means. Of course, I might've done something wrong there... –MJL ‐Talk‐^☖ 21:40, 21 February 2020 (UTC)

I saw the article, and I've never seen this idea in practice before. I think it may be best for a discussion to be held on the topic and a consensus gained first before implementing it. (Especially given that the code is mostly duplication, which is never good for upkeeping, and major issues could occur between differing widths set in the header and "bottom" rows.) -- /Alex/₂₁ 21:42, 21 February 2020 (UTC)

Alright, I'll nominate {{Episode table/bottom}} for deletion and post notes at the relevant WikiProjects. –MJL ‐Talk‐^☖ 21:45, 21 February 2020 (UTC)

Recent changes to markup

Recent changes to Wikipedia have made parts of this template practically unreadable on the mobile site. For example, the header "Directed by" now looks like this:

Dir-

ect-

ed

by

Likewise, the header "No. overall" looks like this:

No.

Ov-

er-

all

I don't know why these changes were made (and I don't think it will last), but would it be possible to put a nowrap template in to make it readable? Mclarenfan17 (talk) 04:37, 21 March 2020 (UTC)

Which article are you referring to and on which device? Both of those are important to know because some articles may display more optional fields, and a small display might also cause problems. For instance, on an iPhone 6s, using Safari, and in portrait mode on List of Murdoch Mysteries episodes#Television films (2004–05) I see

No.

Title

Directed by

Writ- en by

Original air date

but further down

No. over all

No. in sea son

Title

Directed by

Writen by

O

I'm sure wider tables are worse, but this can be compensated if taken to landscape mode. No matter how hard I tried, I could not make that happen in a desktop browser, and I tried with Firefox, Chrome and Safari. Curious. Walter Görlitz (talk) 05:08, 21 March 2020 (UTC)

Use of Aux column for running times?

Hello, I recently created the article List of The Masked Singer (American TV series) episodes with episode tables that included the use of the Aux1 column for adding the running time of each episode in the table. The times were sourced from Fox's official website and I even added archive dates to the references as some of the links are not currently available. (See this edit for how this looked like). However, they were removed by Magitroopa who stated they were "not necessary whatsoever." While I realize that running times are not present on any other episode list article I could find... I don't see why there so unnecessary as though they're completely irrelevant from an episode list and must be removed. I mean... it's an episode list (isn't the runtime of an shows's episode an important piece of information about it?) and there are aux columns for a reason. I don't see what's so bad about using one of them to add running times! I would appreciate anyone's feedback on this, thanks. Heartfox (talk) 04:47, 29 March 2020 (UTC)

Over on the talk page for said article, I've just brought up this past discussion. I've never come across any other article that lists the runtimes in for each individual episode in the table, it should be fine being listed in the infobox of the main article, like it already is. It doesn't really benefit the reader whatsoever knowing if an episode is 41, 42, or 43 minutes long. Magitroopa (talk) 05:03, 29 March 2020 (UTC)

Also, see this more recent question. There's only one or two instances of a double-episode. There's no reason to specify if an episode is 44 or 42 minutes long. It's the standard- they're all about the same length, give or take a minute. Magitroopa (talk) 05:30, 29 March 2020 (UTC)

Yes, as with Magitroopa, there's no need to add runtimes as a column. Especially since each episode is running between 42-44 mins long. Double episodes can be noted on the season articles. - Favre1fan93 (talk) 17:10, 29 March 2020 (UTC)

Space before references

Contrary to MOS, this template implements a space between the table headings and any references provided for each column. An example is List of The Masked Singer (American TV series) episodes, where you can see: "Title [12][13]" and "Original air date [12][13]" etc. If we're going to use these templates across multiple articles (and I believe this is used across more than 11,000), at least can we code it correctly? Cheers. The Rambling Man (Stay indoors, stay safe!!!!) 07:46, 9 June 2020 (UTC)

What exactly are you trying to have adjusted? - Favre1fan93 (talk) 14:57, 9 June 2020 (UTC)

The Rambling Man, it seems to me that the space is there for readability, as the citation is highlighted in white and the table headings are usually colored. When not on a white background, I think it would look strange for, using your example List of The Masked Singer (American TV series) episodes, the white highlight to touch the white lettering of the S1 column titles.— TAnthony^Talk 15:47, 9 June 2020 (UTC)

The should be no spaces between text and references. That is MOS. If other issues are clouding the matter such as highlighting against background colour etc, that's a different matter altogether. The Rambling Man (Stay indoors, stay safe!!!!) 16:52, 9 June 2020 (UTC)

Agree with The Rambling Man that the MoS states that references should be presented without space. Walter Görlitz (talk) 16:28, 11 June 2020 (UTC)

Anchor parameter sometimes causes Lua error in Module:Episode_table at line 166

Adding parameter |anchor=s1 to Episode table in 99-1#Episodes, An Unsuitable Job for a Woman (TV series)#Episodes and Murder in Suburbia#Episode list causes

Lua error in Module:Episode_table at line 166: bad argument #1 to 'gsub' (string expected, got nil).

but worked in Always and Everyone#Episodes.

These are the only UK TV series articles that I’ve found so far that use Episode table. The majority of UK TV series articles use Episode list without Episode table. Around half of these have repeated episode numbers and no production code. Is it possible to set the anchor prefix in these cases? If not, could Episode list create an anchor using the episode title, or have a parameter to specify a text anchor, please? Jim Craigie (talk) 10:44, 19 June 2020 (UTC)

• Using parameters incorrectly can cause breakage of the code, and the module should not be coded to handle these. Looking at An Unsuitable Job for a Woman (TV series)#Episodes I see two problems. The first is that it is using {{Anchor}} inside the table. That is not supported in anyway. The second is that the {{Episode table}} is not using |overall=. When you have two series (=seasons) you should use the |overall= parameter and it's numbering as that is how the template (and the TV MoS) are designed to work. Once you fix these issues it should work correctly without needing you to add an anchor. --Gonnym (talk) 15:06, 19 June 2020 (UTC)
  • @Jim Craigie and Gonnym: I've implemented the changes Gonnym said. Jim, you can now link to each episode as follows: An Unsuitable Job for a Woman (TV series)#ep1, where the last number is the "overall" number, as that is its unique anchor id. - Favre1fan93 (talk) 16:11, 19 June 2020 (UTC)

Link Production Code with its page definition

Something like:

[[Production_code_number|Production code number]]: Production code number

--Stdedos (talk) 17:05, 14 July 2020 (UTC)

We don't link any other info in the headers, and I don't see the need for this to be linked. - Favre1fan93 (talk) 17:32, 14 July 2020 (UTC)

Implementing Template:Sronly

This discussion has been closed. Please do not modify it.
The following discussion has been closed. Please do not modify it.
Koavf, state your opposition to the edit. -- /Alex/21 14:05, 8 August 2020 (UTC) Alex 21, As I wrote, there was no discussion about this here (or at WT:TV). Additionally, there is no language at MOS:TABLECAPTION saying that non-displaying captions should be default (and, in fact, the example cases are the opposite). ―Justin (koavf)❤T☮C☺M☯ 14:13, 8 August 2020 (UTC) Discussions are not necessary for every edit. State your opposition to the edit. Read the template's documentation; the template is completely accessible, and is supported by consensus through the discussion that resulted in the template's creation. -- /Alex/21 14:18, 8 August 2020 (UTC) I have to agree with Alex. The implementation of the Sronly template allows this template to be fully compliant with MOS:ACCESS regarding captions and screen readers, but will hid the captions for non-screen reading devices when 99% of the time the caption's text is redundant and would not be necessary if it were not to comply with accessibility issues. For example, having an article A Great Show (season 1) and the episode table, coming right after an "Episodes" header, with the caption "A Great Show, season 1 episodes" is highly redundant and does not help a reader beyond it's use for a screen reader (which is great). So with this implementation, the screen reader can have the information it needs to help those readers, while not showing for others. - Favre1fan93 (talk) 19:41, 8 August 2020 (UTC) Favre1fan93, And in other cases, it wouldn't be highly redundant. ―Justin (koavf)❤T☮C☺M☯ 02:52, 9 August 2020 (UTC) Then a flag parameter can be created to allow the caption if it does not duplicate information. But as I said, in the vast majority of cases, these captions are redundant text. - Favre1fan93 (talk) 14:45, 9 August 2020 (UTC) Koavf, if you have no further opposition, or no actual policy- or guideline-based reasons to oppose the edit, I'll be restoring it presently. Cheers. -- /Alex/21 00:50, 9 August 2020 (UTC) Alex 21, I do have other objections: you should make this optional, not the default. ―Justin (koavf)❤T☮C☺M☯ 02:52, 9 August 2020 (UTC) Alex 21, I didn't say that discussion was necessary: you started the discussion. I also didn't say that a different template lacks consensus. ―Justin (koavf)❤T☮C☺M☯ 02:51, 9 August 2020 (UTC) Koavf, you certainly did; you stated there was "no consensus" or discussion, making discussion necessary when you reverted with no policy- or guideline-based reason. For the hidden caption to be optional rather than default, there would need to be more cases where the caption would need to be visible than cases where the caption would not need to be visible. Can you provide proof that there are more of the former case than the latter? -- /Alex/21 04:05, 9 August 2020 (UTC) Alex 21, "For the hidden caption to be optional rather than default, there would need to be more cases where the caption would need to be visible than cases where the caption would not need to be visible." Where are you getting this idea? Also, why is it necessary for one option in particular to be more popular for someone to have options? ―Justin (koavf)❤T☮C☺M☯ 04:12, 9 August 2020 (UTC) Koavf, are unable to provide such cases? Also, is there a reason why you decided to revert first, without discussing first? Discussing instead of automatically reverting, was that not part of the conditions for the release of your most recent block for edit-warring? -- /Alex/21 04:19, 9 August 2020 (UTC) Alex 21, You answered my questions with questions. I reverted per WP:BRD. No, you are not understanding what edit-warring is or why blocks were instituted or evidently how to have a simple discussion with another person. ―Justin (koavf)❤T☮C☺M☯ 04:23, 9 August 2020 (UTC) Koavf, no, you didn't. Per WP:BRD-NOT, BRD is not a valid excuse for reverting good-faith efforts to improve a page simply because you don't like the changes, and BRD is never a reason for reverting. Unless the reversion is supported by policies, guidelines or common sense, the reversion is not part of BRD cycle. I'm trying to have a discussion with you. You made a claim. Can you provide such cases to support your claims, or not? If you cannot, then don't make claims you cannot back up. If you cannot, then there was and is no reason to revert. -- /Alex/21 04:26, 9 August 2020 (UTC) Alex 21, Common sense is that this should be optional just like it is with standard tables. Enforcing it that it doesn't display with no obvious documentation or ability to change it seems pretty common sense to me. If you want to have a discussion, how about you answer the questions I asked? ―Justin (koavf)❤T☮C☺M☯ 04:36, 9 August 2020 (UTC) Koavf, so you realize that you didn't revert per BRD? Answer, then, why you reverted. If anything, the invisible caption should be default with the option to display the caption, but so far, I've seen no examples of where this would be required, because none have been able to be provided. You're saying that "in other cases, it wouldn't be highly redundant", but have provided nothing to back this up. Why not? Concerning "no obvious documentation", please don't lie. -- /Alex/21 04:41, 9 August 2020 (UTC) Alex 21, I am not answering your questions until you answer mine. ―Justin (koavf)❤T☮C☺M☯ 04:44, 9 August 2020 (UTC) Koavf, let it be noted that you refuse to discuss the issue, even when presented with a compromise. Happy editing! -- /Alex/21 04:46, 9 August 2020 (UTC) Alex 21, Let it be noted that you refuse to discuss the issue. Please don't lie. See also WP:TPECON. ―Justin (koavf)❤T☮C☺M☯ 04:46, 9 August 2020 (UTC) Koavf, I started this discussion, and have attempted to get you to provide examples that back up your cases. You have not. You have also not asked any clear questions; you have only reverted with no reason. -- /Alex/21 04:48, 9 August 2020 (UTC) Alex 21, Alex, what is unclear about quoting you and then saying, "Where did you get this idea?" Have you discussed in bad faith so long that you've literally forgotten that I wrote: ""For the hidden caption to be optional rather than default, there would need to be more cases where the caption would need to be visible than cases where the caption would not need to be visible." Where are you getting this idea? Also, why is it necessary for one option in particular to be more popular for someone to have options? " and then you ignored it and I asked you to respond over and over again? Note also that I have now provided a policy that you must adhere to regarding how edits to the template's code visually change with template editor privileges. ―Justin (koavf)❤T☮C☺M☯ 04:49, 9 August 2020 (UTC) Koavf, For the hidden caption to be optional rather than default, there would need to be more cases where the caption would need to be visible than cases where the caption would not need to be visible. Because there are far more tables where the visible caption is redundant than cases where there are not, so it should not be visible by default. You're saying that it should be optional to hide the caption than to show it. I provided you a compromise where I said that it should be optional to show the caption than to hide it, but you ignored that. I see no policy? I see "a rough guide", but no policy. -- /Alex/21 04:55, 9 August 2020 (UTC) Alex 21, To be clear here, you are saying that Wikipedia:Template editor is not a policy, when it is in fact a procedural policy? And even tho it explicitly says that "Changes that significantly affect a template or module's visual appearance to the reader" require "substantial discussion" before they are made, you did the exact opposite anyway? I just need to be clear on this because you seem like an excellent candidate for someone to not have these user rights. ―Justin (koavf)❤T☮C☺M☯ 04:59, 9 August 2020 (UTC) Koavf, you linked WP:TPECON. Can you state that in TPECON is says it's a policy? "Changes that significantly affect a template or module's visual appearance to the reader" No significant changes have been made. Unfortunately, here, we have another case of you going off on a tangent. I explained my position as you requested, and you've ignored it again. Are you going to respond to it, or not? If you are, I planned to continue in detail: if such a compromise were coded in, then it would need to be applicable to at least a decent range of articles, not one or two. Templates should not be expected to cover every case, I've been taught recently, especially in such minor cases where the changes would affect such a minimal level of articles. This is the reason why I've asked you to provide a range of articles where the caption would need to be visible. -- /Alex/21 05:03, 9 August 2020 (UTC) Alex 21, Yes, I did link WP:TPECON which is a policy. And you said it's not a policy! It's not a "tangent" when you requested a policy that you evidently had not read or comprehended or realized was incumbent upon you as a template editor. I am arguing that making something invisible is a significant visual change and you're saying that making something that used to display no longer display is not a substantial visual change? That's a pretty ridiculous hard sell, Alex and frankly, hard for me to even believe that you think that's true. You seem to have the burden of proof backwards here but examples of times when captions displaying would be valuable are "list of [x] episodes" that transclude several templates from several individual articles. There are several dozen of these on Wikipedia. ―Justin (koavf)❤T☮C☺M☯ 05:08, 9 August 2020 (UTC) Koavf, TPECON is a guide. Not a policy. Any policy will be prefaced with {{Policy}}; TPECON is prefaced with {{Notice}}. As for examples of times when captions displaying would be valuable are "list of [x] episodes" that transclude several templates from several individual articles... No, these would still be valid for the case of an invisible caption. For example, this table (which is a "list of [x] episodes" that transclude several templates from several individual articles) has the caption "The Flash, season 1 episodes", despite being at the article "List of The Flash episodes" and in the section "Season 1 (2014–15)". Hence, redundant, and a supportive case for an invisible caption. Have I now answered your questions? -- /Alex/21 05:16, 9 August 2020 (UTC) Alex 21, TPECON is a section in Wikipedia:Template editor which is a policy. Please stop your bad faith wikilawyering. You are obliged to seek consensus before making substantial display changes and removing the appearance of a caption is a substantial display change. Yes, I have a question: why did you think this edit was appropriate? Have you seen Wikipedia:Template_editor#Dispute_with_a_fellow_template_editor? ―Justin (koavf)❤T☮C☺M☯ 05:19, 9 August 2020 (UTC) Do you intend to discuss the content at hand or not? I'd like to provide a similar example here. I recently made another update to a television-related module to cater for the case of about 90-odd television articles. It was reverted, as the issue was easily able to be fixed manually at those articles, so that the module/template would work properly at those articles, and thus my edits would have not been necessary anymore. Do you see how this relates here to the use of "visible" captions being needed at a minimal number of articles? -- /Alex/21 05:31, 9 August 2020 (UTC) Koavf, will you be continuing this discussion, or not? -- /Alex/21 05:55, 9 August 2020 (UTC) Alex 21, I asked you questions and you didn't answer them. As I have already explained to you, I am not answering your questions until you answer mine. ―Justin (koavf)❤T☮C☺M☯ 05:57, 9 August 2020 (UTC) Koavf, I have answered your questions in detail. In case you have forgotten, I replied in detail here, expanded in further detail here, answered your "list of [x] episodes" questions here, and provided a related case here. Is that not enough for you? -- /Alex/21 05:59, 9 August 2020 (UTC) Alex 21, "Yes, I have a question: why did you think this edit was appropriate? Have you seen Wikipedia:Template_editor#Dispute_with_a_fellow_template_editor?" ―Justin (koavf)❤T☮C☺M☯ 06:00, 9 August 2020 (UTC) Koavf, talk pages are where editors discuss content, not conduct. The administration board is the location for conduct discussions. Where have I not answered a question about the content? Specifically, where I have not answered a question about the captions, the module, the template or the episode tables themselves? Please, link me, and I'll answer you. -- /Alex/21 06:03, 9 August 2020 (UTC) Alex 21, according to the page you just linked, the conduct issue needs to be resolved before the content one and yet, you are trying to address the content while the conduct issue remains unresolved. Is that correct? ―Justin (koavf)❤T☮C☺M☯ 06:07, 9 August 2020 (UTC) Koavf, no conduct is occurring now that is preventing the content discussion. The conduct itself that was reported occurred almost two hours ago, and yet you seemed fine discussing the content after that in the first place. What has changed? Do you intend to continue discussing it or not? I'll need to ask again, where I have not answered a question about the captions, the module, the template or the episode tables themselves? You specifically stated I am not answering your questions until you answer mine, and I've specifically detailed that I have answered all of your questions. Please now answer my questions. Thank you. -- /Alex/21 06:11, 9 August 2020 (UTC) Alex 21, I asked: "Why did you think this edit was appropriate? Have you seen Wikipedia:Template_editor#Dispute_with_a_fellow_template_editor?" and you didn't answer. If you answer those questions, I'll answer yours. You seem to display a fundamental ignorance about Wikipedia:Template editor: what is required, what is best judgement, what constitutes consensus (it is not built in the course of three comments in one hour by two editors), how to resolve disputes, and the collegiality that should exist among template editors or even that the page is a policy at all. I'm suggesting that your judgement is poor both in the case of changing something visual without seeking prior consensus and in terms of attempting to discuss for the purpose of consensus here. Common sense would dictate that you should have the option to display or not display and when you reverted, you didn't implement those options. You are either not actually trying to seek any consensus or you are fundamentally misunderstanding what constitutes consensus. ―Justin (koavf)❤T☮C☺M☯ 06:22, 9 August 2020 (UTC) Koavf, please discuss content, not conduct. I'll need to ask you again, where I have not answered a question about the captions, the module, the template or the episode tables themselves? You specifically stated I am not answering your questions until you answer mine, and I've specifically detailed that I have answered all of your questions about the captions, the module, the template or the episode tables themselves. Please now answer my questions about the same topics. -- /Alex/21 06:31, 9 August 2020 (UTC) Alex 21, As I have written more than once, I will not answer your questions until you've answered mine. You have not told me if you have read Wikipedia:Template editor#Dispute with a fellow template editor nor have you explained why a revert to your first edit was your decision instead of including the option to display or not display it, as was discussed above. ―Justin (koavf)❤T☮C☺M☯ 06:59, 9 August 2020 (UTC) Koavf, if you have questions concerning conduct, I will happily answer them at AN. Until then, I have answered your questions concerning the content. Please answer my questions concerning the content. This talk page is titled Template talk:Episode table, and thus, we are here to discuss Template:Episode table and Module:Episode table. -- /Alex/21 07:02, 9 August 2020 (UTC) Alex 21, Well, you know what you need to do: answer a yes or no question and justify a revert that you made. If you elect to not, that's up to you. You now clearly know that you are obliged to seek consensus on visual changes before you make them and reverted back to it anyway without consensus and you also refused to include the option to display or not display it, knowing that this would meet the concerns of other editors. ―Justin (koavf)❤T☮C☺M☯ 07:15, 9 August 2020 (UTC) Koavf, if you ask at the correct venue, I'll answer you. If you ask the correct questions at this venue, I'll answer you. I cannot gain a consensus and discuss the content with you if you refuse to answer my questions on the conten. If you have no intention to continue the discussion on the content, please let me know, so I can take it elsewhere. You now clearly know that you are required to answer the questions on content if you want some consensus formed. As for you also refused to include the option to display or not display it; did you mean the part where I suggested a compromise of this exact idea once, twice, thrice? Is this you admitting that you haven't actually read any of my replies? -- /Alex/21 07:20, 9 August 2020 (UTC) Alex 21, Well, you know what you need to do: answer a yes or no question and justify a revert that you made. If you elect to not, that's up to you. I won't be answering your questions unless you answer mine first. ―Justin (koavf)❤T☮C☺M☯ 07:21, 9 August 2020 (UTC) Koavf, I just continued the discussion on content, and you still refuse to answer. I'm convinved you have no intention to discuss it, regardless of any of my contributions, by copy-pasting the same bludgeoning answer. I deem this discussion with you closed, you admit that you have no issues with the edit or anything further to contribute at this venue. -- /Alex/21 07:27, 9 August 2020 (UTC) Alex 21, Stop pinging me on this unless you answer my questions. I've objected to your edit based on policy and I've given you an alternative that you could implement. You've displayed ignorance of the policy and a refusal to engage in a good faith change that would allow the option to display or not display the caption. You've made your choices to not seek consensus and instead revert to your preferred version minutes later. You've also made the decision to willfully misconstrue others' behavior, policy, the nature of consensus, and whether your actions show common sens and good judgement. ―Justin (koavf)❤T☮C☺M☯ 07:30, 9 August 2020 (UTC)' Koavf, copy-pasting the same answer isn't you discussing. Discuss the content. How many times do you need to be told? Take conduct elsewhere. I will continue to ping you until our discussion on the content concludes satisfactorily. I've given you an alternative that you could implement. Can you point me to where you did this before I did? I recall my compromise being my suggestion. Are you taking credit for my suggestion? -- /Alex/21 07:33, 9 August 2020 (UTC) Alex 21, I have told you to stop pinging me multiple times now. ―Justin (koavf)❤T☮C☺M☯ 07:35, 9 August 2020 (UTC) Koavf, and I have told you to discuss content over conduct multiple times now. Either discuss content over conduct and I stop pinging you, or discuss conduct over content and I continue pinging you until you comply. Thank you. Also, answer me: are you taking credit for my suggestion to you? -- /Alex/21 07:37, 9 August 2020 (UTC) Alex 21, I am putting you on mute as you are harassing me. I will not see your pings in the future. You should know better than to keep pinging someone on a discussion where he says to not ping him. ―Justin (koavf)❤T☮C☺M☯ 07:39, 9 August 2020 (UTC) Koavf, and you should know better than to keep discussing conduct over content with someone in a discussion where he says to discuss content over conduct. Please continue the discussion on the content. -- /Alex/21 07:40, 9 August 2020 (UTC) @Alex 21: Will you be reverting yourself as you should not have made this edit without prior consensus? ―Justin (koavf)❤T☮C☺M☯ 03:18, 25 August 2020 (UTC) @Mdaniels5757: ―Justin (koavf)❤T☮C☺M☯ 03:20, 25 August 2020 (UTC)

Mdaniels5757, it's time to {{hat}}/{{hab}} this discussion, so we can proceed with the discussion on how to implement the changes, as per your proposal, as well as discussion on my pre-prepared sandbox edits and testcases. Would you be able to do this, please? Cheers. -- /Alex/₂₁ 04:16, 25 August 2020 (UTC)

@Alex 21:  Done. —‍Mdaniels5757 (talk • contribs) 14:41, 25 August 2020 (UTC)

Implementing Template:Sronly: sandbox and test cases

As part of the compromise suggestion that I provided in the earlier discussion, I have implemented sandbox and test case edits. There are three cases:

• The first episode table uses |caption=, the standard parameter, which provides a hidden caption.
• The second episode table uses |visiblecaption=, a new parameter, which provides a visible caption and a tracking category (Articles using Template:Episode table with a visible caption).
• The third episode table uses both |caption= and |visiblecaption=; this would cause a conflict, and thus |visiblecaption= overrides |caption=, to provide a visible caption and a tracking category (Articles using Template:Episode table with two caption parameters).

-- /Alex/₂₁ 14:50, 25 August 2020 (UTC)

Alex 21, Will you be reverting yourself? Why are you making the default behavior different from what it originally was when there is no consensus to do that? If anything, you should have caption and invisiblecaption as options. ―Justin (koavf)❤T☮C☺M☯ 05:01, 27 August 2020 (UTC)

Koavf, please discuss the content. I have made a compromising suggestion that requires discussion. Thank you. -- /Alex/₂₁ 06:40, 27 August 2020 (UTC)

Alex 21, So, that is a no, you will not be reverting yourself? Note how I did discuss the content and you ignored it. ―Justin (koavf)❤T☮C☺M☯ 07:49, 27 August 2020 (UTC)

If you wish to discuss conduct, you're more than welcome to use my talk page, and I'll happily answer there.

If anything, you should have caption and invisiblecaption as options. A default parameter should exist for the most commonly occuring situation, and an alternate parameter should exist for the least commonly occuring situation. For example, we track episode tables with incorrect colour usages and don't track episode tables with correct colour usages, not vice versa. Same concept here. We track and provide for the minimal situation.

Episode tables most commonly exist in their own section by themselves without other prose, as per MOS:TV, meaning that not requiring a visible caption is the most commonly occuring situation. Hence, the most commonly occuring situation would be to provide a hidden caption with the pre-existing |caption=, and the least commonly occuring situation would be to provide a visible caption with the new parameter |visiblecaption=. -- /Alex/₂₁ 08:24, 27 August 2020 (UTC)

In the vast majority of cases, a caption isn't necessary, so the default should be not show, with the option to show, not the other way around. - Favre1fan93 (talk) 17:18, 27 August 2020 (UTC)

@Alex 21: A few comments. Seeing as I don't know Module editing, can't you just have |caption= and then a flag paramater such as |show_caption= set with "y/Y" etc.? Or is that what's happening? Also, do we need to create a tracking category for this? - Favre1fan93 (talk) 17:18, 27 August 2020 (UTC)

We certainly could have |show_caption=, if you think that that works better. In that case I've suggested, it's simply a matter of replacing |caption= with |visiblecaption= to toggle between not displaying and displaying it. The first tracking category is to find articles that incorrectly use |visiblecaption= where it's not needed (although the category won't be a tracking sort that needs to be empty, as there will be correct usages of it), and the second tracking category is to find conflicting situations where both |caption= and |visiblecaption= are used; clearly in that case, one parameter needs to be removed (this category should always be empty). While the second category is required, the first might not be needed as much. -- /Alex/₂₁ 09:48, 28 August 2020 (UTC)

I think having two distinct parameters where one could show the caption and one can't could get unnecessarily cumbersome. That's why I suggest the flag option. Here's what I would suggest if I was coding it in wikitext {{#if: {{{show_caption|}}} | {{{caption}}} | {{sronly|{{{caption}}} }} }} And then for tracking, do {{#if: {{{show_caption|}}} | {{main other| [[:Category:Articles using Template:Episode table with a visible caption]]}} }}. So however that translates over to module editing, should be what should be implemented. - Favre1fan93 (talk) 16:00, 28 August 2020 (UTC)

Agreed. I think we're better off going with a flag option. - Brojam (talk) 18:18, 28 August 2020 (UTC)

That's certainly doable, and if there's more agreement for it, then I certainly agree with it myself! I've updated the sandbox and test cases for this; if there's no further disagreement, I can implement this. -- /Alex/₂₁ 01:09, 29 August 2020 (UTC)

With no further opposition, I'd say it's safe to implement with a clear agreement. -- /Alex/₂₁ 11:48, 30 August 2020 (UTC)

Yeah go ahead. - Favre1fan93 (talk) 15:06, 30 August 2020 (UTC)

 Done -- /Alex/₂₁ 23:26, 30 August 2020 (UTC)

"Caption" not working?

It seems as if the | caption = is not working, which is a violation of MOS:ACCESS. Any way to remedy this? livelikemusic (TALK!) 04:19, 12 September 2020 (UTC)

Livelikemusic, see the documentation for the parameter. MOS:ACCESS has indeed been conformed to. -- /Alex/₂₁ 04:38, 12 September 2020 (UTC)

Ah, yes, I see that now. Thank you. livelikemusic (TALK!) 12:36, 12 September 2020 (UTC)

"total_width" issues

Hello, I'm a bit puzzled because I haven't been involved in this template before, but it doesn't seem like the total_width parameter is being correctly applied. A number like "75" will work, yielding an HTML property of {{{1}}}, but specifying "auto" (which the documentation says is a valid option) will yield the invalid property {{{1}}}. Naming the parameter but leaving it blank yields {{{1}}}, also invalid, though my browser defaults to using something like "auto" for the table, so it looks okay. Not supplying the parameter at all defaults to 100%, which seems to be an improper choice because it causes a bad interaction with any table floating on the right such as an infobox. For an example, see this revision of "Bamboo Blade" and set your browser's viewport to no more than about 1350px width, and the episode table will be pushed down below the infobox on the side. Can the template please supply a default value of "auto" for this parameter so it plays nicely with other tables? --Iritscen (talk) 11:17, 21 September 2020 (UTC)

Iritscen, I've added a width clause to the module, that determines between a set numeric with, an auto width, or the default of 100%. So, |total_width=75 and |total_width=75% will produce width: 75%; |total_width=auto will produce width: auto; |total_width= will produce width: 100%.

However, given that the episode table you provided as an example includes episode summaries, the default/automatic width of the table will be 100%. That's outside of this template's control and lies with the HTML automatically stretching the table to fit the summaries. -- /Alex/₂₁ 11:57, 21 September 2020 (UTC)

Thanks. That was fast! Re: auto vs. 100%, my experiment with the Bamboo Blade page shows that width:100% will cause the two tables to collide (which is happening right now, with the template/module code the way it is currently), but width:auto will allow the tables to sit snugly next to each other. Specifying no width or a bad value causes the browser to default to width:auto, the desired behavior, although I haven't tested this in multiple browsers (I'm primarily using Opera). But based on that test, it seems to me that you would want the table to default to auto, not 100%, to allow the tables to always interact nicely. --Iritscen (talk) 12:16, 21 September 2020 (UTC)

Yes, that's a common occurence in the WikiProject Television, unfortunately. We combat this by changing the set width or reorganizing the content so that the episode table is below the infobox. In the case of Bamboo Blade, auto seems to fix this problem. Cheers. -- /Alex/₂₁ 12:31, 21 September 2020 (UTC)

Okay, thanks. I held off on setting the template call to use "auto" because I didn't want to create confusion by changing something while you were in the midst of looking into the issue :-) That does in fact solve the problem. --Iritscen (talk) 13:00, 21 September 2020 (UTC)

Default background color not working?

I'm noticing today that the {{Episode table}} template is currently not defaulting to #CCCCFF as the background color – e.g. List of Handy Manny episodes.

Can anyone with coding knowledge take a look into this please, and hopefully find a fix? Thanks. --IJBall (contribs • talk) 03:30, 8 November 2020 (UTC)

That's deliberate. Last week, I updated the default colour for an episode table header, to match the colour used by a regular wikitable header, like the table at WP:DTABTUT#Overview of basics. There's no need to differentiate them, and if colours aren't needed, they should reflect a regular wikitable header's default. Furthermore, if colours aren't needed, they can be remove from {{Series overview}} as well, as seen at List of Unsolved Mysteries episodes. -- /Alex/₂₁ 03:38, 8 November 2020 (UTC)

This change should have gotten more discussion, or at least a lot more advance warning IMO. I've purposely left default colors out of the table code at a number of articles because I knew it would default to #CCCCFF. Now I would have to go back and fix those tables manually (and I don't have such a list). And while I agree that {{Episode table}} and {{Episode list}} should have the same default color, I'm not sure that it should be the default wikitable color. (I'm not against making that an option – perhaps something like "background=wikitable" could be the coding choice for that.) But I think #CCCCFF should be restored until we figure out how others feel about this, and can maybe see a list of how many articles this would affect, and if there are other approaches here. --IJBall (contribs • talk) 03:46, 8 November 2020 (UTC)

Hm. Why the set need for a random default colour? Why do they need fixing, what does #CCCCFF provide? There's no difference between what an episode table and a raw wikicode table provide in terms of a table, they're both wikitables and should thus go by the same defaults. -- /Alex/₂₁ 04:19, 8 November 2020 (UTC)

That's not the point – the point is that this should have been discussed before being unilaterally implemented, as it affects a number of articles, and represents a change to relatively long-standing practice. --IJBall (contribs • talk) 04:35, 8 November 2020 (UTC)

Sure. Can I see where this long-standing practice was initially agreed upon? Did we use #CCCCFF as a default before this template was created? -- /Alex/₂₁ 04:50, 8 November 2020 (UTC)

Again, not the point. If you think the initial way this has been handled is wrong, it's on you to start a discussion on it. Other editors may or may not have agreed with you on it, but this is what should be done when a long-standing practice like this is changed. Again, I personally like the #CCCCFF color much more than the "standard Wikitable format color", and would have liked, at a minimum, a heads up that a change was coming, along with a list of exactly which articles this change was affecting, so I could have made contingencies. Of course, the even better solution would have been something that allowed for the old practice to continue, while also allowing the "new" way to go forward. --IJBall (contribs • talk) 15:10, 8 November 2020 (UTC)

I'm sorry, I'm just not seeing anything that supports this "relatively long-standing practice", or any outside agreement as to its beginning and usage, and only what one editor personally likes. Unfortunately, we don't base Wikipedia around our personal likings. What about my two previous questions? Adding a third question, what is the major difference between an episode table and a wikicode table that determines that we need a different colour? -- /Alex/₂₁ 23:46, 8 November 2020 (UTC)

Of course you don't – you think you are right, and to hell with anyone who disagrees with you. But it would be nice if, for once Alex, you remembered that you don't exist in a vacuum and what you do affects other editors. This whole thing is an example of the twisted environment of Wikipedia where template editors think editors serve their whims, and editors think readers serve their whims, which is the exact opposite of how this is also supposed to work.

So, Alex, can you at least provide a list of which articles have {{episode table}}s with no background color so that the rest of us can fix your massive change without discussion if we want to?! That would be super considerate of you. Thanx. --IJBall (contribs • talk) 14:46, 9 November 2020 (UTC)

"Of course you don't"? Of course I don't see the support for a "relatively long-standing practice"? I don't get your comment there, I just asked where this practice started or was discussed, that's all. I don't think I'm "right". I'm just not seeing how I apparently "arbitrarily" changed a colour (which wasn't arbitrarily at all, but based on Wikipedia styling that's been in place for at least a decade) that was picked arbitrarily with no consensus, discussion or agreement.

What needs fixing? Again, what does #CCCCFF provide that no other colour does not? -- /Alex/₂₁ 23:26, 9 November 2020 (UTC)

Alex 21, to IJBall's point, whether or not have #CCCCFF as a default had any merits or functionality beyond it just being chosen as such, it still has been the "standard" for the TV project as long as I've been here for that to be the default table color. And going in and changing it to not be that, can be viewed as disruptive. It's a small thing yes, but there was nothing wrong per se with it being used, as it was accessibility color compliant. I will say, given that vast majority of tables pick some sort of color, having CCCCFF default helps distinguish the table as being an episode table from another wikitable. I would like to see it restored until a larger discussion is had. - Favre1fan93 (talk) 23:39, 9 November 2020 (UTC)

Thank you for a civil response. I've temporarily restored the #CCCCFF colour.

However, about your comment on distinguishing an episode table from another wikitable takes me back to my comments from earlier: what is the difference? They're both wikitables, there is no difference between them. There's no difference between what an episode table and a raw wikicode table provide in terms of a table, they're both wikitables and should thus go by the same defaults.

If the colour does not have "any merits or functionality beyond it just being chosen as such", then there is no use for it. Wikipedia does not use colours just for the sake of them, we use them to differentiate content, which is why we use different colours for different episode tables, to differentiate between separate seasons. However, if there is no colour needed to differentiate between episode tables, such as at List of Unsolved Mysteries episodes or List of Handy Manny episodes, then a colour should not be used, and it should be presented as a regular wikitable. Can you show examples of other regular wikitables that use a standard colour? -- /Alex/₂₁ 23:56, 9 November 2020 (UTC)

I gave you about 17 "civil" responses, and you simply stonewalled me. As to the broader point, not everything has to have a pure "functionality" component. You may have a point that many-season TV series tables should possibly simply dispense with the colors and do a standard "wikitable". But for our usual 2–7 season TV series, having colors to differentiate the seasons is a good idea. Unfortunately, not all TV series have had someone "pick a color for every season" (e.g. List of Handy Manny episodes), so having them default to #CCCCFF in the meantime is useful. Frankly, the "plain wikitable" color is unappealing, esp. considering we've been using #CCCCFF for a long time. That should not be changed willy-nilly on the whims of one template editor. --IJBall (contribs • talk) 02:13, 10 November 2020 (UTC)

P.S. And I again a request a list of articles using {{Episode table}} with no background color – how many articles we're talking about is an important part of this discussion. Is it a few articles, or many? --IJBall (contribs • talk) 02:17, 10 November 2020 (UTC)

So, given that it's "unappealing", it's based on what's aesthetically pleasing, that's it?

You can easily use the search function to find transclusions of {{Episode table}} that don't use |background=. -- /Alex/₂₁ 02:21, 10 November 2020 (UTC)

And now you're assuming that every editor is as technically savvy as you are – plenty are not. It seems like you're willing to be "helpful" to certain editors but not to others – I have a suspicion if Favre1fan93 had asked this question, you would have already have answered it. So we're back to stonewalling. --IJBall (contribs • talk) 02:25, 10 November 2020 (UTC)

I said no such thing. In the case of being "helpful", it was because there were more editors who disagreed with the change instead of just one, so I respected that and reverted it. There's help pages where you can look up how to do these things; no offense, but you shouldn't expect other editors to do all of the work for you. -- /Alex/₂₁ 02:29, 10 November 2020 (UTC)

Oh, I definitely don't expect you to do work for anyone else. P.S. Even one editor objecting, as I did, should have been enough to trigger WP:STATUSQUO. But, like I said, apparently it depends on who does the asking... --IJBall (contribs • talk) 02:31, 10 November 2020 (UTC)

STATUSQUO is an essay, not a guideline or policy, and does not state that the edit must be reverted. Would you like to get back on topic now, or? -- /Alex/₂₁ 02:35, 10 November 2020 (UTC)

I understand and agree with IJBall's point that it's possible some editors do not put their own background color because it defaults to the CCCCFF, and so they use that. To your question about the difference in a wikitable and this. Yes, they are both wikitables, but our WikiProject encourages the use of heading colors, so if we wish to conform to our guidelines and practices, a default color should be utilized. I also suggest a new discussion be started below or at the TV project talk regarding if the default color should remain, so more editors can weigh in beyond the three of use. It can link back to this one for other editors to reference. - Favre1fan93 (talk) 15:28, 10 November 2020 (UTC)

Director parameter

I recently asked (and got answered) about a similar thing involving television infoboxes at Template talk:Infobox television#Producers question.

For the episode tables themselves, would the same thing apply? As in only those listed as 'director' and not anything else (ex: 'supervising director') should be listed in the tables? For example, the director credits were recently added to Kamp Koral: SpongeBob's Under Years here, but all of them are either supervising or storyboard director.

Not sure if there are any exceptions, such as a show that doesn't list main directors. For example, the first episode, "The Jellyfish Kid" now has the supervising directors and storyboard director listed in the episode table. Looking at the opening credits, the only credits given are 'Written by', 'Storyboard director', 'Supervising directors', 'CG supervisor', 'Co-executive producers', and 'Executive producer'- no main 'director'. So would this be an example where it's fine to list supervising/storyboard directors, or should only writers be listed and leave the directors out like previously? Magitroopa (talk) 20:47, 4 March 2021 (UTC)

Any way to make this table template sortable?

I think it would be great if one could sort the Episode-number and Production-code columns, especially in cases where episodes were aired out of order like in List of Lizzie McGuire episodes and List of Sliders episodes. Is there any way to make this happen? Shāntián Tàiláng (talk) 19:40, 8 March 2021 (UTC)

Calculate text color automatically depending of the table header background color

Is it possible to add some logic for style calculation of the table header or restrict styling of these elements? For dark/black themes in iOS/Android might happen issue with colors overlap like in this example (check Episodes section) - https://en.wikipedia.org/api/rest_v1/page/mobile-html/The_West_Wing_(season_7)?theme=dark Additional details - https://phabricator.wikimedia.org/T284327 VadimKovalenkoSNF (talk) 08:23, 6 September 2021 (UTC)

Pinging @Izno who might know what needs to be done. Gonnym (talk) 08:26, 6 September 2021 (UTC)

I left a comment on Phab and CCd you on it. Izno (talk) 15:56, 6 September 2021 (UTC)

Reference Spacing

I had this issue brought up at at an FAC of mine. Not sure if this is an issue with every reference that is added into the table but with |airdateR= it adds what appears to be a partial space between the text in the reference. (Original Air Date [1] instead of Original air date[1]). It wouldn't copy and paste here exactly as it appears, but if I paste it into a web browser field, and remove the space and then hit my space bar the spaces are not the same size. Hopefully that explanation wasn't too confusing but unless there is a specific reason can this issue be fixed so that there is no space there? TheDoctorWho (talk) 15:32, 13 October 2021 (UTC)

Module:Episode table#L-34 uses   which is the space used for Template:Hair space. For why that is, Alex would probably know. Gonnym (talk) 15:43, 13 October 2021 (UTC)

Pinging @Alex 21: just to bring attention. If there's a specific reason I can bring that up at the FAC, thought I'd ask though since we don't typically space between the text and the reference. TheDoctorWho (talk) 15:57, 13 October 2021 (UTC)

Yes – this styling has always violated MOS:REFPUNCT. If there is no good reason for it, the "extra space" should be removed. --IJBall (contribs • talk) 18:34, 13 October 2021 (UTC)

@IJBall Incorrect. MOS:REFPUNCT very clearly states that [a] <ref>...</ref> tag can be spaced apart from the preceding content by a hair space in the unusual case that the results of not spacing could be visually confusing, so no, it's never "violated" anything. Thank you.

Anyways, a reference in an episode table cell is sometimes provided with an automatic background colour due to WCAG contrast requirements, and thus the above is why the hairspace was added, given that coloured text and a reference with a coloured background directly next to each other can be visually confusing. However, this should not affect a FAC at all, and if it does, you can simply quote this reasoning and how it is completely acceptable per REFPUNCT. -- /Alex/₂₁ 20:28, 13 October 2021 (UTC)