Template talk:Episode table/Archive 3

Archive 1

Archive 2

Archive 3

Proposal to recommend a new template to close "dontclose" tables

This is a continuation of a discussion at User talk:Beland. The recommendation to use </table> at the end of an episode table that opens with |dontclose= creates awkward-looking wikicode: an HTML </table> tag that does not have an apparent opening tag. Most templates that generate wikitables use {{end}}, or a redirect to it, to avoid this problem and make the code look "cleaner". Template sets that generate HTML tables often use corresponding closing tables (see {{AbMLA/end}}, {{Tree chart/end}}, and {{CanMP end}} for examples).

I propose to create {{Episode table close}}, since its name most closely matches the existing |dontclose= parameter (although {{Episode table end}} would more closely match other templates in the family of "end" templates). That template could simply contain </table>, like {{Tree chart/end}}, and transclude the documentation for the Episode table template. This new template would be recommended in place of </table> in the documentation. – Jonesey95 (talk) 21:07, 2 April 2021 (UTC)

Support, and extend the proposal: Thinking more about this (also continuing from the discussion at Beland's talk page), I think {{Episode table}}'s |dontclose= should be deprecated, require use of a closing {{Episode table end}} in the template documentation, and change the module code to always behave as if |dontclose=y were specified. Yes, this would be a breaking change, so we'd should first go through all of the ~14,000 articles that use {{Episode table}} and insert {{Episode table end}}s. But this should happen. After all, it really doesn't make sense to have tag-like templates that act like old-school DTD-based HTML tags where tags like <p> didn't have to be closed. (Nit: because I'm suggesting killing |dontclose=, the proposed {{Episode table close}} doesn't need to match the dontclose parameter, and thus {{Episode table end}} is consistent with most other end-type templates). sbb (talk) 23:12, 2 April 2021 (UTC)

Edit: I no longer think this. See my self-reply below.

If it's possible to rejigger transclusions so that the "dontclose" parameter could always be set to "n" that would be a cleaner fix. But if that's not possible an end tag with a similar name makes sense to me. Especially since the opening might change in the future, and it would be much easier to change one end template then all the pages that do the close themselves. -- Beland (talk) 00:39, 3 April 2021 (UTC)

Okay, I've done quite a bit of research. First, some helpful searches:

1. Articles containing "</table>" and has template {{Episode table}} — 25 articles 0 now that #4 below is done.
2. Articles containing "dontclose" and has template {{Episode table}} — 224 articles
3. Articles containing "{{End|Episode table" and has template {{Episode table}} — 197 articles

The 2nd and 3rd lists mostly overlap (there are 8 articles in (C) that aren't in (B), and (A) is a subset of (B)).

There are fewer than 250 articles that have {{Episode table|dontclose=y/1}} (or the #Invoke of it). There are another handful (I think 13) Family Guy articles that don't have |dontclose= but wrongly includes an extra </table> tag (which would break layout if it were transcluded from within an enclosing table).

Takeaways:

1. Searching for hastemplate:End seems broken. It returns over 78,000 articles, and the first few seem to use {{end}}, but many in the first results page don't. Can't guess how wrong that search is, so not useful.

2. Many examples of other epsiode-related template instances, such as {{Show summary|dontclose=y}}, are used in articles that also use {{End|Show summary|html=y}}. That's not the only pair, so it's obvious that the idiom of using {{End|...|html=y}} is well-established. Because of this reason alone, I recommend against the creation and use of {{Episode table close/end}}.

3. Change {{Episode table/doc}} to recommend {{End|Episode table|html=y}} instead of </table>, to stop the propagation of the HTML tag.

4. Fix the 25 articles that use </table>. Done sbb (talk) 07:36, 3 April 2021 (UTC)

{{End|Episode table|html=y}} calls an invalid parameter |1= in {{End}}, which is currently harmless, but which will eventually cause a problem. {{End|Foobar|html=y}} yields exactly the same result. Invalid parameters in templates are not a good idea. – Jonesey95 (talk) 13:52, 3 April 2021 (UTC)

Fair enough. I don't disagree with the bigger picture, in that I'd prefer {{Episode table}} to be closed with {{Episode table end}} as opposed to {{End|Episode table|html=y}}. I supposed me previous flip-floppiness was more tactical rather than strategic, in that I was coming mostly from the Typo Team/moss standpoint, rather than more focused on long-term vision. Supporting your point, the documentation at {{s-end}} states that that template simply duplicates the functionality of {{end}}, but because {{s-end}} is supposed to close Succession navigation boxes, its name implies semantic meaning, as opposed to just using {{end}} to close all templates that leave things open.

Your point about invalid parameters is also extremely salient, and argues in favor of a simple dedicated matching close end template.

I'm going to withhold strong support for the moment, because I believe |dontclose= can still be demonstrated to be redundant and unnecessary. I haven't quite put together some sandbox articles demonstrating it yet. Working on it, in between daylight projects... sbb (talk) 22:12, 3 April 2021 (UTC)

Jonesey95, just use {{End|html=y}}? Check out Doctor Who (season 4). -- /Alex/₂₁ 01:11, 3 April 2021 (UTC)

I considered proposing that code as the content of {{Episode table end}}, but I think it unnecessarily introduces a dependency on another template that someone might change without knowing that this new template depends on it. It is easier to simply have the content of {{Episode table end}} be </table>. I suppose that instructing people to use a convoluted version of {{end}} instead of the more obvious {{Episode table end}}, which matches the pattern of most other sets of table-generating template families, would be possible, but it is better to follow the familiar pattern. – Jonesey95 (talk) 02:29, 3 April 2021 (UTC)

I mean, you do you, but there's zero need to duplicate templates when what we require here already exists, and has already been in used in over 200 articles with zero apparent issues. If {{Episode table end}} is created with straight HTML content instead of as a redirect, or taking advantage of a pre-existing template, or without implementing the content into the Episode table module, I'll likely take it to TFD to gain a wider view on it. -- /Alex/₂₁ 04:45, 3 April 2021 (UTC)

Please slow your roll and AGF. What would you propose to redirect it to? How would the documentation work? I have linked above to a number of templates that all appear to contain </table> and their own documentation. Do you propose to redirect all of those as well? If so, to what?

I have proposed a concrete solution to a problem. My proposed solution parallels a large family of templates that are well established. You (Alex 21) are proposing implementing the content into the Episode table module, but do you have proposed code for that, or a demonstration of how it would work in an article? If so, please explain, or link to an article where it is already working as you envision. (I see the example of Doctor Who (season 4), but that doesn't maintain parallel structure at all, calls a nonexistent parameter |1=Episode table, and is as confusing as a closing table tag.) – Jonesey95 (talk) 06:14, 3 April 2021 (UTC)

Sorry for the long delay for my followup. Alright, I'm convinced that |dontclose=y is unnecessary, and is basically functionally redundant with the |episodes= parameter. I wrote up my findings in my sandbox article User:Sbb/sandbox/Episode table, but briefly: I took the List of Annoying Orange episodes article (it's really long, takes awhile to parser process), and made 4 versions of it:

1. {{#invoke: Episode table|dontclose=y}} ... {{End|Episode table|html=y}}
2. {{#invoke: Episode table|episodes= ... }}
3. {{Episode table|dontclose=y}} ... {{End|Episode table|html=y}} (same as first, without #invoke:)
4. {{Episode table|episodes= ... }} (same as second, without #invoke:)

They all produced the same output, and can be transcluded or labeled-section-transcluded as desired, with the exact same effect on the rendered pages (whether transcluded or not). The only difference seems to be in how long it takes to parse the wikitext. My simple, 100% non-scientific non-exhaustive, tests show that #2 and #4 took just over 4 seconds to process, and #1 and #3 took over 5 seconds to process.

Based on my findings, I suggest one of the following outcomes (in my own preferential order):

1. Deprecate |dontclose=, replace its use with |episodes=. That way, one parameter can be eliminated from the documentation, and the warning in the param's documentation to remember to use </table> (or the preferred {{End|Episode table|html=y}}) can be completely eliminated, simplifying the use-cases. Con: Leaving the template header open, with pages of long sub-templates, and remember to close the template with }}, is possibly harder to debug for editors than having {{Template open}} ... {{Template end}} -style pairs. Acknowledged. But not enough to convince me. This suggestion seems to be slightly more performant (I'll probably regret saying that, lacking more exhaustive performance tests), and doesn't clutter the template namespace at all.
2. Require use of {{Episode table/end}} instead of </table> or {{End|Episode table}}: this would require implementing the end Lua function in the Episode template Lua module. That's trivial, all the function needs to do is emit </table> as User:Alex 21 suggested. While this does add to the template namespace, at least the definitions of the templates are all in the same Lua module, which from a coding locality and symmetry point-of-view, is more preferable than completely disjoint templates in which one is defined by a Lua module, and the other is defined as simple template text replacement.
3. Require use of {{Episode table end}} (as I have previously argued for). This has the same benefit as #2, in the sense of having a visual pair of templates to start/end the functionality. This one is trivial to implement without Lua—it just emits </table>—but otherwise has only one thing going for it: it's not as bad as just putting </table> in article wikitext.
4. Do nothing – i.e., continue to let </table> be the recommended way to close |dontclose= Episode tables. Ugh. I list it only because it's an "alternative", albeit a crappy one. sbb (talk) 02:27, 7 April 2021 (UTC)

Thanks for the thoughtful work and clear explanations. OptionTest case version 4 ({{Episode table|episodes= ... }}) seems to be the best, most template-like option. The only risk I can see is that editors inserting new episodes will break the template by not understanding that the final closing braces belong to the table template instead of to the final episode template. Do we have evidence that this is or is not a concern? I would oppose options test case versions 1 and 3 due to their use of an invalid parameter, as noted above. – Jonesey95 (talk) 02:45, 7 April 2021 (UTC)

Sorry, I'm a bit unclear on what you prefer or suggest. I think it's because I used list numbers for the 4 test cases, and list numbers for my suggested paths forward. You say "Option 4 seems to be the best", but based on earlier reponses, I don't think you're talking about my suggested outcome of "4. Do nothing", are you? That suggests leaving the recommendation in {{Episode table/doc}} to use </table>. I think you're talking about my #4 test case (the first of the numbered list of 4 things). That's what I recommend in my #1 suggestion.

As you say, "oppose #1 and #3", those are just my test case numbers to generate compute time numbers, not instances of suggested ways to do things. It sounds to me like you prefer my suggested outcome #3 (use {{Episode table end}}) over #2 (use {{Episode table/end}}). They are minimally different, IMO, and I don't feel very strongly for 2 as opposed to #3.

As far as evidence of interpreting the final close braces as the end of the last episode template, it's a concern, but in my editing (on a computer, not on mobile), I can see the entire text for the episode template, so it's easier to understand that the closing braces should match that. I suggest the best remedy is to include an HTML comment like such: }} <!-- closing "{{Episode table" template -->. My hunch is that the episode list articles are complicated enough (due to their transclusion guard tags like <onlyinclude>...</onlyinclude>) that pretty much only experienced editors will bother much with them, so those articles tend to take care of themselves. But that's just my hunch and assumption.

One thing that will probably come up in a RfC on the issue, is a parallel consideration with {{Series overview}}. It has the same |dontclose= parameter. Luckily, it has a parameter, |multiseries=y, that is the functional parallel of {{Episode table|episodes=}}. (Stats: there are about 5000 articles that have {{Series overview}}; only 20 of them use |dontclose=). sbb (talk) 03:12, 7 April 2021 (UTC)

Sorry about that. I have clarified my response above. I prefer getting rid of |dontclose=. – Jonesey95 (talk) 03:35, 7 April 2021 (UTC)

Proposal to allow better numbering system when more than 1 is used

I would like to propose to add an option for two spanned cells, |overall_span= and |season_span= which can be used in episode lists such as those used in List of Pokémon episodes (seasons 1–13) where the numbering currently used is both for overall, but for different countries, which at the moment does not allow the very useful and user-friendly season numbering from being used. The spanned cells would both have |overall= and |season= set by default (meaning there is no need to set all 4, but just the two spanned parameters). The new parameters should allow their text to be set (so the value set should be used as the column text). I've looked at the code briefly but couldn't see exactly how to do this and was hoping someone familier with the code could do this. @Alex 21:, is this something you can help with? --Gonnym (talk) 10:39, 8 May 2021 (UTC)

Sorry, I'm genuinely confused by this. Would you be able to do a hard-coded table example to visually show what you're looking for? Once we do that, I'll happily take a look at the code. -- /Alex/₂₁ 04:44, 9 May 2021 (UTC)

Sure, something like this:

Japanese no.		English no.		Title	Original air date	English air date
No. overall	No. in season	No. overall	No. in season
626	1	620	1	"Regaining the Home Advantage!"	January 7, 2010 (2010-01-07)	June 5, 2010

However, looking closely at the specific example of the Pokemon lists, it would seem that the seasonal order of episodes isn't changed between regions, but instead some episodes are just skipped. In this case, just another Aux field after the numbers and before title would work. That doesn't say that there aren't lists that wouldn't gain from the above, but that for this current situation, there is no need for it. So, the proposal is instead for:

Japanese no. overall	English no. overall	No. in season	Title	Original air date	English air date
626	620	1	"Regaining the Home Advantage!"	January 7, 2010 (2010-01-07)	June 5, 2010

--Gonnym (talk) 07:37, 9 May 2021 (UTC)

Okay, I can see how that could work! If we're just proposing the second example, we could use |overall= and |overall2= for {{Episode table}} (and then just using the |[para]T= to change the text), and then |EpisodeNumber=, |EpisodeNumber2=, |EpisodeNumber3=, etc. for {{Episode list}}. -- /Alex/₂₁ 09:17, 9 May 2021 (UTC)

Yes, that sounds great. Thanks! --Gonnym (talk) 10:53, 9 May 2021 (UTC)

I'd say you're more familiar with the code at Module:Episode list if you want to implement |EpisodeNumber3= there? -- /Alex/₂₁ 11:10, 9 May 2021 (UTC)

I've added code to the episode list template. See the testcases and see if you see something out of place. --Gonnym (talk) 11:39, 9 May 2021 (UTC)

Implemented {{Episode table}} in the testcase and all seems to be working perfectly. -- /Alex/₂₁ 11:47, 9 May 2021 (UTC)

Alignment error

I've noticed an error with the alignment of the table. All columns (besides the "Serial/Episode title/s") are centre-aligned, but this doesn't appear to apply for multi-part stories, like classic Doctor Who: the first episode is centre-aligned, but the remainder are left-aligned:

No. story	No. in season	Serial title	Episode titles	Directed by	Written by	Original air date	Prod. code	UK viewers (millions)	AI
9	1	Planet of Giants	"Planet of Giants"	Mervyn Pinfield	Louis Marks	31 October 1964 (1964-10-31)	J	8.4	57
			"Dangerous Journey"	Mervyn Pinfield	Louis Marks	7 November 1964 (1964-11-07)		8.4	58
			"Crisis"	Douglas Camfield	Louis Marks	14 November 1964 (1964-11-14)		8.9	59

I've tested this in multiple browsers on different devices, and always encounter the same problem. It appears to be a fairly recent issue, so I figured I'd raise it here. – Rhain ☔ 11:16, 18 January 2022 (UTC)

@GKFX you were the last to edit the module. Please make sure your edits didn't cause this. Gonnym (talk) 11:22, 18 January 2022 (UTC)

They likely were the cause of the issue, as I recently had to make a fix to the new Module:Episode list/styles.css, as the |EpisodeNumber= cell became left-aligned rather than center. The issue would be that the first row uses the CSS class "vevent", but the following rows do not, and thus the styling declared at the styles.css page does not apply; this is what needs to be fixed. -- Alex_21 _TALK 12:03, 18 January 2022 (UTC)

It definitely was from this edit, which adjusted/removed some alignment styling. I don't know if Alex 21's styles.css changes will fix that. - Favre1fan93 (talk) 16:11, 18 January 2022 (UTC)

I don't know Lua, but I think I may have fixed it with this edit, adding the vevent class to rows generated by the multi-row function. – Jonesey95 (talk) 16:44, 18 January 2022 (UTC)

That should do it, thank you all. I have added the above sample as a testcase on {{Episode list}}. User:GKFX^talk 18:29, 18 January 2022 (UTC)

Quick and efficient solution, thanks all! – Rhain ☔ 23:15, 19 January 2022 (UTC)

@GKFX Furthermore, as you can see at High School Musical: The Musical: The Series#Specials (2019–20), the Title cells are now centered in this one table, as opposed to being left-aligned as per the other tables. These edits have caused too many issues; I believe they should be reverted until they are thoroughly tested, instead of making constant fixes/edits. (Also, as a completely unrelated side note unrelated to the edits themselves, this discussion should have been started at Template talk:Episode list, given that it's the episode list that was modified, not the episode table header.) -- Alex_21 _TALK 13:13, 20 January 2022 (UTC)

Yes, let's revert and properly test this out. - Favre1fan93 (talk) 19:14, 20 January 2022 (UTC)

Episode list change

Moved from User talk:Jonesey95
I have no interest in whether something is centered or not, but [1] looked a bit suspicious to me since vevent is an microformat. Just checking in to make sure that you are still marking up that element (whatever it is) correctly with that change (i.e. that by marking it up you are correctly marking it up as an event). Izno (talk) 20:19, 19 January 2022 (UTC)

Thanks for checking in. I don't know from microformats, but that class was already in use in the template/module. I just changed it so that the class used in the sub-rows matched the class used in the rowspan row and in the CSS style page. If a different class entirely should be used in all three places, that is fine with me. If you want to pursue it further, I think this discussion should be moved to the talk page for the template, continuing the existing thread. – Jonesey95 (talk) 20:58, 19 January 2022 (UTC)

I couldn't find a discussion when I looked; I just found the edit in question from RecentChanges (I made a filter just for Module/talk and MediaWiki/talk changes). Feel free to move this one. Izno (talk) 21:48, 19 January 2022 (UTC)

Collapsable

Is there any way to make the table collapsed? Eievie (talk) 02:49, 13 December 2022 (UTC)

@Eievie: Nope. That's an WP:ACCESS issue; MOS:DONTHIDE. Content shouldn't unnecessarily be hidden. - Favre1fan93 (talk) 17:39, 14 December 2022 (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 chronological order like in List of Lizzie McGuire episodes and List of Sliders episodes. Is there any way to make this happen?

(I originally posted this question on March 8, 2021, but it got buried by an archival bot on January 19, 2022 after a period of inactivity.) Shāntián Tàiláng (talk) 14:52, 4 May 2022 (UTC)

This is an excellent question and request. It should be a parameter to pass in. As Episode table has been included in book table and other places, the ability to request a sortable table in the output is a great feature request. --Trödel 00:20, 28 March 2023 (UTC)

Because sorting would not be applicable to tables and entries that include summaries, and would cause unwanted behaviour. -- Alex_21 _TALK 00:29, 28 March 2023 (UTC)

That is why it should be an option for the many many tables that do not use episode summaries. I am not proposing that it be default behaviour but it should be an option for the person using the templates in the articles. They can choose to use it when they need. For example, Robert Jordan#The Wheel of Time should be sortable table, and has no summaries. --Trödel 00:31, 28 March 2023 (UTC)

I haven't written any modules before, but it seems a change to the EpisodeTable.new function would be all that is needed.

It appears that all that is needed is to add an if/then statement with a flag passed into the model that adds the following.

...
	root
		:addClass('wikitable')
		if sortable_flag = "yes"
		:addClass('sortable')
		end if
...

Just need help to make sure the bolded text is correct and the proper parameter can be passed via the table initialization templates like {{Episode Table}} or {{Book table}} etc. Thoughts? --Trödel 00:29, 28 March 2023 (UTC)

I know how it could be implemented and made optional, but including the parameter as an option opens it up to then be used in summarized tables by editors unaware of the issue, thus opening the ability to cause table sorting errors. This template has existed for years without the need for a sortable parameter; I would recommend gaining a wider consensus first. -- Alex_21 _TALK 00:36, 28 March 2023 (UTC)

I know I haven't been active but this response is frustrating to me.

1. All those tables that use it now can continue unchanged
2. Those that add this parameter should know what they are doing, and if they don't we should hold them accountable to the documentation
3. With whom should I build consensus? This is so widely used on so many varying topics, I would be willing to bet only techies are following the module/template pages so the people using this template are unlikely to see this discussion.

I see only positives from this change and people who add it to tables with summaries will be summarily reverted by others on those pages when they see it break the tables.

Anyway, thanks for confirming it can be done. --Trödel 00:45, 28 March 2023 (UTC)

As per the various past discussions regarding this, and Alex's summary of such above, this shouldn't be introduced. It would created a vast amount of breaking tables given the summary parameter and its colspan function, which would not work well with the sort function. - Favre1fan93 (talk) 22:22, 28 March 2023 (UTC)

Those that add this parameter should know what they are doing, and if they don't we should hold them accountable to the documentation; Unfortunately, this is easier said than done. There's a multitude of television-related templates that are used outside of their proper documentation, and the regular members of WikiProject Television have to maintain hundreds, if not thousands, of these occurrences, and have been needing to do this for over a decade. An example of this is {{Television ratings graph}}, which is a template that's used and abused just to display numbers because anonymous/new editors think the numbers and colours look pretty. Thus, as the "techies", the more chances we get to minimize template and parameter misusage, the better. I do genuinely apologise if this is frustrating. -- Alex_21 _TALK 22:33, 28 March 2023 (UTC)

"Alternate Air Date" → "Alternative Air Date"

Per MOS:COMMONALITY, this column should be named the latter. The latter means the same thing in all Englishes, while the former is a synonym for the latter only in US English. Getsnoopy (talk) 08:12, 13 July 2023 (UTC)

@Getsnoopy WP:SOFIXIT -- Alex_21 _TALK 09:30, 13 July 2023 (UTC)

He can't. InfiniteNexus (talk) 03:05, 14 July 2023 (UTC)

@InfiniteNexus Can you explain this further? The template documentation is not at all protected, as clearly shown by Getsnoopy's update here. -- Alex_21 _TALK 06:16, 14 July 2023 (UTC)

I only realized that the textual rendition of the parameter in the template itself would not be affected by the change after I wrote that, so I just fixed it in the documentation. Thanks. Getsnoopy (talk) 06:25, 14 July 2023 (UTC)

Ah, never mind. I thought Getsnoopy was referring to something in the actual template rather than the documentation, which would have required someone with template editing access to fix. InfiniteNexus (talk) 08:58, 14 July 2023 (UTC)

Proposal for new header variable, update to Wikipedia's template of "Episode table"

{{Edit template-protected}}

The above is added to garner the necessary attention. Since the "Episode table" template is "template-protected", it can be edited only by administrators or users in the Template editors' group, and this is the recommended action to move forward.

Unless I am misunderstanding something, "Template:Episode table" as documented at https://wiki.riteme.site/wiki/Template:Episode_table showns signs of an intended yet incomplete use case. In the Episode list data, one can define "EpisodeNumber3" (i.e.: EpisodeNumber3=100), but there is no way impliment a corresponding column in the header. So when one attempts to use "EpisodeNumber3", this results in the header actually having 1 less column defined than the rest of the table. As the template currently is written, there is apparently no easy way to fix this. What is needed is a defined header variable such as "season2" to immediately follow the "season". A default text might, for example, read "No. in alternate"; and an editor could, of course, then use "season2T" to redefine the column's text as needed.

Here, I provide an example as to why such a field would be useful. In the case of the Octonauts page currently found at https://wiki.riteme.site/wiki/List_of_The_Octonauts_episodes there is both an episode order as released by the BBC's channel CBeebies and an episode order as define by the streaming service Netflix. Yet, these both are awkwardly in the same column cell without any explanation as to what the data actually denotes. While different from each other, both episode lists are certainly worth preserving; and still, an editor seems to have resorted to the current denotation since nothing more suitable currently exists. With the inclusion of a new header variable "season 2", "season" could continue to define the episode order as defined by the BBC while "season2" could then define the episode order as defined by Netflix. Each separate season order could be in it's own column, and the new header column would easily align with data from "EpisodeNumber3".

For reference to my personal attempt to use the "EpisodeNumber3" variable but for which I had no corresponding variable in the header with which to align it, see a sample edit (reverted again by me shortly after being made) of just season 1 here: https://wiki.riteme.site/w/index.php?title=List_of_The_Octonauts_episodes&oldid=1168194241 Please, note the missing header column.

A natural enough side note: being able to sort the table by any of the first 3 column headers here would be useful even if not strictly necessary, and this would be something to keep in mind. Even while noted though, this falls outside of the scope of my immediate request, that of the inclusion of a new header variable to follow immediately after "season".

Really. it seems clear to me that the already existing variable "EpisodeNumber3" in the Episode list data was *meant* to be associated with some variable (e.g.: "season2") such as I have proposed. Furthermore, adding the variable "season2" will both follow the current expected syntax and also not break any tables already in existence on other pages. Finally, there are other pages where I can see how update this would be useful, and I can imagine such pages being transitioned over time, but these could be done at their own pace if ever and all without worry.

A future concern perhaps, this would not solve the possible problem of different providers having select episodes from one season being somehow moved to another season. Yet, that unlikely and completely separate difficulty would prove a problem with or without this proposed update; and really, it is, to my knowlege, only an imagined problem at the moment.

So in any event, please impliment a variable in the header such as "season2" set to immediately follow "season". Thanks! BoyBlueSky (talk) 04:12, 2 August 2023 (UTC)

@BoyBlueSky: only one set of episode numbers should be used, not two. So that to start is incorrect at the Octonauts article you listed. It should be following the order defined by its airing on CBeebies, as that is the original broadcaster/production company. The table does support various "Aux" columns for secondary information that may be helpful beyond the "base/default" set, but as I have noted, there is currently no consensus within the TV project to list more than one episode order for any series. As such, I am marking this request as answered and  Not done. - Favre1fan93 (talk) 14:53, 2 August 2023 (UTC)

@Favre1fan93: Thank you for your response. You say that there is no consensus within the TV project about this. Of course, a lack of concensus even with a proper discussion is always an unfortunate situation; but a lack of concensus due to never having had a conversation would really push the definition of the word "concensus". So, I am assuming then that there was a discussion thread about this topic previously; and if so, I am hoping you can direct me to it. For now, I would simply like to review the community's thoughts on the matter.

Thank you again! BoyBlueSky (talk) 08:26, 5 August 2023 (UTC)

MOS:TVEPISODELIST exists, which constitutes the TV project's current consensus on the matter. That states Episodes should generally be arranged in order of airdate, with any notable production discrepancies covered in appropriate notes or in a production section., which then translates to one set order within the episode table, not multiple. - Favre1fan93 (talk) 15:31, 5 August 2023 (UTC)

Thank you again. I am not trying to be confrontational; and still, I believe we are not actually discussing the same point.

Reading your linked information, I see that it states that "Episodes should generally be arranged in order of airdate, with any notable production discrepancies covered in appropriate notes or in a production section." I agree with this 100%; and yet, this isn't really the issue which is found with the Octonauts or other such series. There is no suggestion being made that the original ordering by airdate should ever be removed. Rather, I am suggesting that a *NEW* third column be allowed so as to preserve not only the original airdate column AND the series order as apparent when initially released in that order through CBeebies but ALSO the series order as clearly defined by Netflix.

Allow me to make a case for the significance here. The primary series of "Octonauts" was produced by Silvergate for multiple seasons. Of particular note to this discussion however, a Netflix-original spinoff, subtitled "Above & Beyond", was subsequently released. Again, this spin-off is a Netflix "original", meaning it is their own & not necessarily even released elsewhere. Clearly, Netflix has a vested interest in the series. That having been said, they host both the primary series & the spin-off series on their platform. The important point, they have a separate & easily verifiable series order for the primary series. Someone looking for this series order should be able to easily see it listed as well. So far, I think we agree on this.

In short, your linked information shows that a series' primary listing is certainly important, and I agree. Yet, it doesn't really address the importance of a series' secondary listing. This is not at all the dichotomous argument of which series' order should take precedence. On that, there is already concensus. That is not the talking point here. Rather, this is an proposal that the 2nd listing be supplemental to the first. For this, a feature which is already partially implimented needs merely to be finished. To align with the already present & fully functional variable "EpisodeNumber3", a corresponding header variable should be available; or else, the variable "EpisodeNumber3" is a misnomer.

The best way to *present* this information seems to be the way evidenced through the "EpisodeNumber3" variable. It literally already exists, and all that is lacking is a corresponding header variable. Either the existance of the variable "EpisodeNumber3" is erroneous or at least misleading, or there really should be the corresponding & appropriate positioned header variable for it. I have made the suggestion that this header variable be designated "season2".

You alternatively suggest that this might be done though "Aux" columns; and still, the real issue here is the placement of the column. In the table, "EpisodeNumber3" already very naturally follows "EpisodeNumber2". This is *already* implimented. Again, I am not suggesting this be implimented, but I am pointing out that it is already there. Using this implimentation as one expects, however, demonstrates that the table header inexplicably lacks the corresponding variable (suggested to be "season2" by naming conventions). The possible use of "Aux" wouldn't align with the column for "EpisodeNumber3"; and this seems only to be a longstanding fix for the incomplete yet apparently intended implimentation of "EpisodeNumber3" with a corresponding header variable. I prefer not to use an unsightly workaround, but I ask that the pre-existing "EpisodeNumber3" column merely have a corresponging header column.

I want to be in-line with the community, and I merely think this issue is not precisely the same as the one to which you pointed. If I have not convincingly made my point to you, is there a way to open this to a more general community discussion?

Again, my position is not intended to offend, and I thank you for both your time & patience. BoyBlueSky (talk) 23:58, 6 August 2023 (UTC)

If the alternate ordering is truly important for this series (does it have any narrative consequences?) then the suggestion would be to stick to one order for the templates and make a prose mention somewhere that Netflix has an alternate viewing order. However, seeing as this is a children's television program and very few, if any, are meant to have any overarching serialization, again, the consensus would be to stick to one ordering for the table. I do not have much experience with children's programming, but the one that I do to some extent is Bluey, and I know the ABC release order is different from what Disney+ is doing. Yet, List of Bluey (2018 TV series) episodes only has the ABC order, as it should. - Favre1fan93 (talk) 15:33, 7 August 2023 (UTC)

Table ref

Hey Alex 21, can you look at the formatting of {{Episode table/ref}} in regards to when {{rp}} is used? If that template is used to specify a page for the info being used to source in table, it comes up as white text against the white background, which feels odd since it should be outputting the page note text in black font. I've had to add {{color}} around the "rp" template to force it to be black. See Ahsoka (TV series) and I Am Groot for what's happening. - Favre1fan93 (talk) 19:28, 3 September 2023 (UTC)

 Fixed That section was inheriting the text colour of the rest of the episode table header, as I never declared a specific colour for any text inside the white span, so I've gone ahead and added that. -- Alex_21 _TALK 00:36, 4 September 2023 (UTC)

Awesome, thank you! - Favre1fan93 (talk) 00:50, 4 September 2023 (UTC)

Any way to make the table viewable on mobile phone without having to scroll sideways?

On portrait mode on mobile phone, the episode summary is cut off and you have to scroll sideways or tilt the phone to landscape mode to be able to read the episode summary. Because there is too many columns to fit in one screen horizontally. This has been bugging me for years, is there any way to fix it? Possibly by making all the columns vertical on mobile. Less radical solution would be to just cut off the episode summary cell of the table at the edge of the screen (so you can scroll sideways if you want to see the overflow information at the top of the header) Not sure. Possibly using Template:If_mobile? MarkiPoli (talk) 10:17, 2 October 2023 (UTC)