Template talk:Episode list/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Sandbox version update

Please take a look at the sandbox and testcases. I've updated the code with the following changes:

• Added support for non-English languages with |TranslitTitle=, |NativeTitle= and |NativeTitleLangCode=. This should enable us to remove {{Japanese episode list}} per the merge result and correctly handle non-English languages, as the module now uses Module:Lang for these languages.
• Added support for multi-part rows with |NumParts= and |Title_n= parameters. This should enable us to remove {{Japanese episode list multi-part}}.
• Added support for serials, such as the the ones on Doctor Who (season 1)#Serials, with |NumParts= and |Serial=.
• Added support for multiple episodes with correct MoS usage.
• Fixed visual bugs where a title cell would display two rows with an empty top row. Now displays one row if missing information.
• Fixed accessibility bug where row scope was not handled if |EpisodeNumber= was not used.

There should be no bugs still in the code, but test it out and let me know if you have any comments. --Gonnym (talk) 17:41, 16 January 2019 (UTC)

Gonnym, the module is reporting errors on usages of the template. Please fix immediately. See the article you linked in the third dot point. -- /Alex/₂₁ 09:08, 27 January 2019 (UTC)

• On it. --Gonnym (talk) 09:10, 27 January 2019 (UTC)
  • Thanks. (just wanted to post here since I saw these as well) CriticismEdits (talk) 09:16, 27 January 2019 (UTC)

  Gonnym, please make sure that the module is completely working before restoring again, to prevent clogging the edit history with continuous reverts, and to prevent any sorts of errors on such a high-usage module. Perhaps it would be in your best interests to file a template-protected edit request to implement the code, so that another template editor, another party, can review your sandbox changes and test cases before implementing. -- /Alex/₂₁ 09:46, 27 January 2019 (UTC)

  Sure Alex, no problem. The issue was that while it was in the sandbox version the check title.namespace == 0 was blocking the code to continue so I didn't notice any bugs that came after that. I've now noticed that check and working on those issues. I'll submit an edit request when I'm done. --Gonnym (talk) 09:55, 27 January 2019 (UTC)

  @Alex 21: want to test the sandbox version? Don't see any errors anymore (remove the mainspace only check so you can check not on mainspace). --Gonnym (talk) 10:06, 27 January 2019 (UTC)

As requested above, would appreciate if any template editor can verify my code on Module:Episode list/sandbox throws no errors. --Gonnym (talk) 07:16, 28 January 2019 (UTC)

Gonnym: something strange on the Triple episodes testcase. Is that intentional? — Martin (MSGJ · talk) 12:57, 30 January 2019 (UTC)

Are you refering to the number range or to something else? If it is the range, that was intentional as I was following MOS:NUMRANGE. --Gonnym (talk) 14:52, 30 January 2019 (UTC)

In Triple episodes, the Live template shows 43 44 45 with hr between. The sandbox shows 43 45 with hr between. Where did the 44 go? Same with 23 24 25. – Jonesey95 (talk) 15:59, 30 January 2019 (UTC)

Following the style that MOS:NUMRANGE says to use (ndash). The only exception is the hr style, which I didn't change to an ndash. --Gonnym (talk) 16:08, 30 January 2019 (UTC)

But in the hr "style", the 44 is just gone. It seems like it should be displayed, if actual range notation is not being used. – Jonesey95 (talk) 05:30, 31 January 2019 (UTC)

If the complete list style with an hr is what is wanted, that can be changed. I personally felt that the number range should be used in each style and that it was understood (should also be worth noting that this is a very theoretical discussion as I couldn't find an example with 3 episodes and even taking into account the probability of it, it's probably not more than a handful). --Gonnym (talk) 09:02, 31 January 2019 (UTC)

In "Double episodes", the Live template shows "22, 24" and the Sandbox shows "22–24", which has a different meaning (i.e. 22, 23, and 24). Is this change intentional? Other than these two minor problems, the rest of the test cases look perfect to me. – Jonesey95 (talk) 15:59, 30 January 2019 (UTC)

The example should have been 22, 23 as that is the next number.

OK, I fixed the test case then. Let's not have a test case with an error unless it is marked as such to demonstrate how erroneous input is parsed. – Jonesey95 (talk) 05:30, 31 January 2019 (UTC)

Any other comments? Did anyone see any errors in the code on main-space pages? --Gonnym (talk) 12:12, 3 February 2019 (UTC)

I have no other comments. Would you like to make the edit, or would you like me to do it? I think it makes more sense for you to do it if you have permissions. – Jonesey95 (talk) 17:24, 3 February 2019 (UTC)

Thanks for checking it out. Moved changes to live version. I've looked at a few articles, including those reported before and don't see any issue. Please report if you see something. --Gonnym (talk) 17:33, 3 February 2019 (UTC)

I have restored the original functionality and usage of the "TBA" values, in their small display and left-aligned nature in the Title parameter. In the documentation, while the given example of Doctor Who may be an optimal example of the serial usage, there is no consensus to change the Doctor Who articles to this format, and thus another live example of the parameter is required. Furthermore, the |1= parameter should not be needed in articles where the episode table is not transcluded; I'm not sure if this is a requirement for the template, or just in the documentation, but it should be displayed as the template is meant to be used. Realistically, it isn't necessary at all, and can just be used as it is currently used, in the form of an unnamed/unnumbered parameter. -- /Alex/₂₁ 03:47, 4 February 2019 (UTC)

@Alex 21: commenting on the issues:

1. |1= - For TemplateData there is no such thing as an unnamed parameter and it treats all unnamed parameters as numbered parameters. So |1= is necessary for the documentation. Since Template:Episode list/sublist was setup to use this documentation page, and that template needs it, not a lot I can do here. However, as I've noted here, if the usage of this parameter is only used in one of these templates and not both, I can eliminate the need for it altogether and get that data without user input.
2. Left-aligned TBA - could you explain your reasoning for why a left-aligned TBA is better than a centered one when all other TBA values are centered?
3. Doctor Who - since you are one of the major contributors to those articles, would you mind explaining your opposition to my change? The current tables do not follow MoS guideline MOS:PLIST (by using the br tag), and have incorrectly placed values in the table. Each row of information should be separate, but in the Doctor Who tables (see example), the data is all thrown in together. This creates two main issues - the first, is that a screen reader will read a lot of irrelevant data (reading 4 air dates in a row); the second is that the data is not even the same - the first item in the title section is not an episode title, but the arc/story title and that title does not even have a corresponding date, viewers and AI data, since it isn't an episode, but it will still get read as an episode for a screen reader.

--Gonnym (talk) 07:49, 4 February 2019 (UTC)

1. Sure, makes sense. But then include it only in the TemplateData, then, it's not needed in the documentation itself, as that's not how the template is used. I've never seen {{Episode list}} or {{Episode list/sublist}} use |1=.
2. To reflect the rest of the title column. Titles are left-aligned, hence the TBA should be left-aligned. Other columns are center-aligned, hence their respective TBA's should be center-aligned.
3. All MOS's are guidelines, not policies, and each article should use what is best for that article. As the 39 articles use the currently-existing format, then that is where the consensus stands. They do not use the "new" format, and thus the documentation should not display it as if they do. Incorrectly placed values? Such as? And all those point are all well and good, but there is still no consensus for it, or even a discussion to change them. -- /Alex/₂₁ 09:37, 4 February 2019 (UTC)

1. |1= and unnamed is the same thing - it's not a change in the code or something (accessing an unnamed parameter in lua is accessing it from the numbered/position its placed). Not really sure what change you want me to make in the documentation.
2. But why? It isn't a title. It looks very strange that all TBA values are centered and this is not.
3. Actually, MOS:ACCESS is the consensus and is based not on a guideline nor even an en.wiki policy, but on a WMF policy. Please note the part in the lead that reads The WMF asserts that its policies "may not be circumvented, eroded, or ignored by Wikimedia Foundation officers or staff nor local policies of any Wikimedia project - are you sure you want to get into this? (regarding your question about the incorrectly placed values, the next sentence I wrote has that answer - you're adding a story arc title AND episode title in the same field - that is mashing two distinct fields into one) --Gonnym (talk) 17:15, 4 February 2019 (UTC)

   1. Is |1= used in tables that aren't transcluded? It isn't, and thus shouldn't be used in the documentation. And I'm aware that it's the same thing, but they are used differently. I've never seen {{Episode list/sublist|(newline)1=Article}}, only ever {{Episode list/sublist|Article}}.
   2. Again, everything in the title column is left-aligned. Titles and TBA. If it looks strange, then why has this been the way it's appeared since {{TableTBA}} was implemented into this module, and before that when it was used manually? What looks strange is when all the titles are left-aligned, then a random TBA is center-aligned.
   3. Yes, noted, you still need consensus for it. -- /Alex/₂₁ 23:47, 4 February 2019 (UTC)

You can use |1= or you can use it without it - it is the same thing when invoking a template. The documentation still needs to call it "1" as you can't call an unnamed parameter unnamed. This is a rather pointless argument. Also, I find it amazing that a veteran editor like yourself knowingly ignores accessibility issues and the actual point in that policy which states that I actually do not need a consenous to point out that your usage in the Doctor Who articles is incorrect. Pretty amazing Alex. --Gonnym (talk) 00:55, 5 February 2019 (UTC)

Yes, you can. But the manner in which it is used has never been with |1=. But I agree, it is pointless, so I'll update the documentation accordingly. And truly, I live to amaze; if you want to change the articles from their standing layouts, I'll be there to restore and wait for a discussion. Cheers. -- /Alex/₂₁ 01:04, 5 February 2019 (UTC)

@Alex 21: The guidance at MOS:PLIST enjoys site-wide consensus and you need a very good reason to breach it. Your personal preferences don't meet that requirement. Looking at the table in Doctor Who (season 3) #Serials, a screen reader would hear "Galaxy 4, Four Hundred Dawns, Trap of Steel, Air Lock, The Exploding Planet" for the first Title cell. They would then hear "11 September 1965, 18 September 1965, 25 September 1965, 2 October 1965" for the first Original air date cell, and so on. The former is just about acceptable, but the latter is nonsensical to anyone using assistive technology. The table needs to have "Four Hundred Dawns" in the same row as "11 September 1965" and in a different row from the row containing "Trap of Steel" and "18 September 1965", etc. I agree with Gonnym that the table needs to be reformatted to make it accessible to visually impaired readers. I'll be happy to re-revert you if you ever decide to revert accessibility improvements to the layout of those tables. The question of how we implement tables on Wikipedia is already settled; the only discussion would be concerning your behaviour. --RexxS (talk) 02:20, 5 February 2019 (UTC)

Noted, cheers. Clearly this needs to be discussed at a wider venue before further implementation. -- /Alex/₂₁ 02:25, 5 February 2019 (UTC)

@Alex 21: Clearly it doesn't. Here's what MOS:DTAB tells you:

Avoid using <br> tags in adjacent cells to emulate a visual row that isn't reflected in the HTML table structure. This is a problem for users of screen readers which read tables cell by cell, HTML row by HTML row, not visual row by visual row.

The onus is on you if you want to create a consensus to change that, and if another editor implements improvements to eliminate the <br> tags, any reversion will certainly be viewed as disruptive editing. Is that clear enough for you? --RexxS (talk) 16:47, 5 February 2019 (UTC)

Then the season articles should be changed it to <hr>. Same layout given, no <br> tag, no issues in DTAB with <hr>, and quite fitting as this module already uses <hr> to split rows. -- /Alex/₂₁ 22:35, 5 February 2019 (UTC)

Don't be ridiculous. ANI doesn't take kindly to wiki-lawyering. The season articles will be changed to a format that places each episode in its own table row so that screen reader users can access them. Do you really not understand the difficulty you cause for those less fortunate than yourself while you disrupt Wikipedia to make a point? --RexxS (talk) 23:15, 5 February 2019 (UTC)

"disrupt Wikipedia to make a point"? Isn't that changing the articles based on a guideline? If you don't want <hr> used either, then state a policy that bans it and/or remove it from this module as well. -- /Alex/₂₁ 23:33, 5 February 2019 (UTC)

No, it would be changing the articles from one inaccessible format to another. Using <hr> or <div>...</div> or <p>...</p> or any other block-level html to put text on new lines within a table cell produces exactly the same problem for a screen reader user. --RexxS (talk) 00:02, 6 February 2019 (UTC)

Your opinion is duly noted, cheers. Does this module need updating? -- /Alex/₂₁ 00:04, 6 February 2019 (UTC)

The module needs updating or scrapping as it produces inaccessible tables. I'll show you tomorrow how the tables should be rendered. --RexxS (talk) 01:31, 6 February 2019 (UTC)

Scrapping? Scrapping a module used on over 18,000 articles? I look forward to your sandbox testcases. Cheers. -- /Alex/₂₁ 01:33, 6 February 2019 (UTC)

@Alex 21: You say on your user page that you are a "website developer in my spare time". Any web developer worth their salt understands accessibility issues; you can start at WCAG. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:10, 6 February 2019 (UTC)

Irrelevant to the discussion at hand; try again. -- /Alex/₂₁ 23:59, 6 February 2019 (UTC)

Directed here from Wikipedia talk:WikiProject Doctor Who#Season articles layout change. Clear improvement to align with site-wide consensus at WP:DTAB, which the Doctor Who project is currently violating. Pleased to learn that <br> should not be used going forward for the benefit of those using screen readers. No objections at all to the proposed changes. U-Mos (talk) 03:20, 7 February 2019 (UTC)

Interesting, so you no longer support the use of line breaks in cast tables either? -- /Alex/₂₁ 03:46, 7 February 2019 (UTC)

I'm not and don't claim to be an expert on table coding, but the accessibility issue obviously means that multiple rows should be used instead of line breaks wherever possible, yes. I was not aware of that until reading this discussion. Are you referring to any particular article? U-Mos (talk) 04:09, 7 February 2019 (UTC)

On another interesting note, why the separate rows for identical directors and writers, but a rowspan for the title? An Unearthly Child applies to the whole serial, as does the director and writer, Waris Hussein and Anthony Coburn. Same for the production code. -- /Alex/₂₁ 03:52, 7 February 2019 (UTC)

If screen readers would still read the item in a merged rows each time encountered (i.e. Waris Hussein's name after each individual episode title), I agree that rowspans should be used rather than repeating the information. U-Mos (talk) 04:09, 7 February 2019 (UTC)

There were a few discussions in the past which, if I remember correctly, said that using a rowspan is ok as long as it is continuous, but shouldn't be used in the middle of a table. I could be wrong. @Izno: I think you had more knowledge with this, right? --Gonnym (talk) 07:58, 7 February 2019 (UTC)

I would be interested in seeing such discussions, and at least a written guideline supporting it. Do be aware that you need to update the usage at Template:Episode list#Episode with multiple titles to apparently not use block-level tags, and if the statement on row spans is correct, then the date rows will need to be updated to singular rows too. -- /Alex/₂₁ 08:08, 7 February 2019 (UTC)

I have no preference for the multi-title example. I followed your code at {{Japanese episode list multi-part}} when I implemented it. That said, I did ask at Wikipedia talk:Manual of Style/Accessibility#Use of the hr element in a table before I implemented it and got an answer that it is not incorrect (might not be optimal though). As I said, I have no preference in this matter so if you're inclined to change it to a better version, go ahead. --Gonnym (talk) 08:16, 7 February 2019 (UTC)

Apparently, it's not about preference, as I have been told so clearly, it's about what must be done. But if it the <hr> tag is acceptable for the multi-title example, then that means that the Doctor Who articles can indeed use the <hr> tag instead of <br>. [T]here should be no problem that I can foresee. -- /Alex/₂₁ 08:41, 7 February 2019 (UTC)

Apples and oranges. The Doctor Who entries are different rows of information - each has a different title, different air date, different viewers and different AI. The multi-title one is just alternative titles for the same episode. It is the same as Title and AltTitle. And also, as I said, if the multi-title one is also incorrect, I have no objection for you changing it to something better. --Gonnym (talk) 08:59, 7 February 2019 (UTC)

Except that [a]s long as whoever uses that technique understands that a screen reader will effectively ignore the horizontal rule and will read out the entire contents of that table cell as if the rule wasn't there, then there should be no problem that I can foresee. No comment was made in that thread discerning the use of <hr> in only a singular column vs. multiple columns. If it can be used in one column, why can it not be used in multiple columns? Or, on the other hand, if it cannot be used in multiple columns, why can it be used in one column? -- /Alex/₂₁ 09:05, 7 February 2019 (UTC)

it's not a question here just of columns, but also of rows. Adding horizontal rules to a table cell does not split it into separate rows. In the case of a single column, it won't make a big difference to what a screen reader user hears, but when you have related information like Title, Original air date, UK viewers and Appreciation Index, then bundling all of each type into the same data cell means that all of the titles are read out before all of the air dates, before all of the viewer numbers, before all of the AIs. How do you expect anyone using assistive technology to work out what dates, numbers and indices apply to each of the 12 episodes in Doctor Who (season 3) #Serials, story 21, serial 4? --RexxS (talk) 19:01, 7 February 2019 (UTC)

Nor does it split it into rows at Wikipedia talk:Manual of Style/Accessibility#Use of the hr element in a table. Either it is acceptable here, in this discussion, or it is not acceptable at that discussion. One cannot have it both ways. -- /Alex/₂₁ 23:39, 7 February 2019 (UTC)

And now we're having the same discussion in two separate places, Wikipedia talk:Manual of Style/Accessibility#Accessibility disagreement. As stated, I can support the table displayed at that discussion. -- /Alex/₂₁ 23:43, 7 February 2019 (UTC)

@Alex 21: Nobody's asking to "have it both ways". The two scenarios you are looking at are fundamentally different. If you compare these two tables:

Table 1 with rows

Title
Galaxy 4
Four Hundred Dawns
Trap of Steel
The Exploding Planet
Air Lock

Table 1 with hr

Title
Galaxy 4 Four Hundred Dawns Trap of Steel The Exploding Planet Air Lock

A screen reader will hear the same five pieces of information in the same order in both cases. But if you compare these:

Table 2 with rows

Title	Air date
Galaxy 4
Four Hundred Dawns	11 September 1965
Trap of Steel	18 September 1965
The Exploding Planet	25 September 1965
Air Lock	2 October 1965

Table 2 with hr

Title	Air date
Galaxy 4 Four Hundred Dawns Trap of Steel The Exploding Planet Air Lock	11 September 1965 18 September 1965 25 September 1965 2 October 1965

although they are visually similar, for "Table 2 with rows", the screen reader user will hear "Galaxy 4"; "Four Hundred Dawns, 11 September 1965"; "Trap of Steel, 18 September 1965"; "The Exploding Planet, 25 September 1965"; "Air Lock, 2 October 1965". However, for "Table 2 with hr", the screen reader user will hear "Galaxy 4, Four Hundred Dawns, Trap of Steel, The Exploding Planet, Air Lock"; "11 September 1965, 18 September 1965, 25 September 1965, 2 October 1965".

That is a considerable difference; a sighted reader can make a visual association between each episode's title and air date in both cases, but a screen reader user cannot in the second case. I hope you can see why we shouldn't use hr, br, div, p, ul, etc. to mimic rows inside a table cell in an attempt to associate data from one column to another. If there's only one column, obviously the issue won't arise, so that's one of the "occasional common sense exceptions" that we have with guidelines. --RexxS (talk) 00:31, 8 February 2019 (UTC)

Revisiting

How do the updates solve the accessibility problems of using block elements like those seen at Agents of S.H.I.E.L.D. (season 2)#ep43, List of Unbreakable Kimmy Schmidt episodes#ep48, Big Mouth (TV series)#ep21 and/or Once Upon a Time (season 4)#ep74? -- /Alex/₂₁ 11:54, 20 February 2019 (UTC)

Let me start by saying that I did not invent the "hr" style and I personally don't like it, so none of my changes were in adding that. Like I said earlier, I did ask about the use of it and got a response that it isn't incorrect per accessibility - my understanding of that is since it isn't taking data that is supposed to be in two rows and splitting it visually its ok. However, looking at the examples you gave, that doesn't seem to be the case. Agents of SHIELD example - I'd say that the use of HR there does violate that, as it is supposed to be two episodes with two different writers; Unbreakable Kimmy Schmidt - I'm not sure what the two separate rows of writers mean, which is usually a sign of a problem. A reader shouldn't need to guess what data in a table represents; Big Mouth - should be seperated into two parts; Once Upon a Time - is the worst, since even the episode summary is divided. All the examples you gave are, in my opinion, things that should be fixed. --Gonnym (talk) 12:08, 20 February 2019 (UTC)

I didn't say you did, but the mass update seemed to be majorly focused on updating accessibility, and it seemed incomplete given that these cannot be fixed with the recent updates. Each of the episodes listed are listed and given as singular episodes by their original broadcasters and thus cannot be split. I was simply curious to see if there were any such further updates coming to continue the support for accessibility. -- /Alex/₂₁ 12:14, 20 February 2019 (UTC)

I could work and add any style that is wanted, I just need to be given specific needs and I'll see how to make it work. Regarding the episodes though - AoS has two episode numbers, two directors, two writers. That to me seems very 2 different episodes. OUaT could be handled in a few options - the easiest/simplest way (which I prefer) is to just make it two separate rows with an episode number of 74A and 74B with an attached note that explaining it (the one at the bottom of the episode summary atm). Kimmy Schmidt - US writing credits are not written like in the table, so I'm not sure what that means. if the separation bar is supposed to be an "and", then that should be replaced and written like that. Big Mouth can be also handled like OUaT. Other ways are of course much more complex and require much more work. To me, the above simple options seem to work good. --Gonnym (talk) 12:25, 20 February 2019 (UTC)

Another question, how do these changes allow us to display different writers and/or directors for different episodes of the same serial? -- /Alex/₂₁ 21:58, 23 February 2019 (UTC)

Look at User:Gonnym/sandbox. I've added |DifferentDirectors= and |DifferentWriters= parameters, which when set to true, will check for DirectedBy_# and WrittenBy_# parameters. Does this work for what you need? --Gonnym (talk) 08:33, 24 February 2019 (UTC)

It does. Why are separate parameters needed for directors and writers, and not aux, viewers, etc.? -- /Alex/₂₁ 09:09, 24 February 2019 (UTC)

When I created the code I based it on the DoctorWho serials as I only knew of them using this style and those had unique parameters for those parts, so the code I did had those parts setup with |Serial=. If there are other styles that work differently, then if needed I'll change the code to this setup. Let me know what's needed, and if I need to change something or add the sandboxed code. --Gonnym (talk) 09:12, 24 February 2019 (UTC)

I would recommend that the module automatically detects if any parameter uses its Parameter_# counterpart, and when this is the case, automatically create the relevant rows based on how many Parameter_# counterparts are used. This would also fix the issues raised in the first revisit, and should make the case of differing parameters easier to handle. -- /Alex/₂₁ 09:20, 24 February 2019 (UTC)

That system as proposed has potential to easily break. Say someone adds |WrittenBy_1=, |WrittenBy_2= and |WrittenBy_3= but only |DirectedBy_1= and |DirectedBy_2=, there is no way to know what the editor meant by that and the system shouldn't be used for guessing. So in this case |NumParts= should still be used and all para# parameters should have the matching number of entries. Other than that I think it could work. Will have time later to work on it. --Gonnym (talk) 10:26, 24 February 2019 (UTC)

Then fill out |DirectedBy_3= with {{TableTBA}}, as empty cells currently and already are, and add the article to a tracking category. I'll see if I can implement some sandbox changes and whip up some test cases. -- /Alex/₂₁ 10:29, 24 February 2019 (UTC)

Done. Sandbox code at Module:Sandbox/Alex 21, test cases at User:Alex 21/sandboxM. For the first table, the first row is a live version of the existing template. Second row is where the episodes have different writers. Third row is where the episodes have different writers, but the second one isn't set, and hence adds a category. Fourth row is where every column has separate parameters. The above examples I linked as well are given as accessible examples beneath the serial table. This deprecates |Serial= and |NumParts=; the less parameters to deal with, the better. -- /Alex/₂₁ 11:38, 24 February 2019 (UTC)

Looks good, though a couple of comments. 1. See my sandbox as there is a bug somewhere which is causing a column not to show up as "TBA"; 2. "TBA" text should be switched to something else, as "TBA" ("To be announced") does not fit here. Easy fix; 3. While the code works, I think the getnumberOfParameterGroups(args) function is much less efficient than just having a |NumPart= parameter, as you are looping over 100 entries for each column, while the values could be 2 or 3. Rest of the code seems good. --Gonnym (talk) 12:13, 24 February 2019 (UTC)

1. I think that it may be the production code column; I'll look into it. 2. How about N/A? These cases will only be temporary, as they should be fixed soon after being categorized. 3. True, but there's less potential for screw-up if the module calculates it automatically. The less parameters to be confused by, the better. -- /Alex/₂₁ 12:33, 24 February 2019 (UTC)

N/A is a better option. Well, if you choose to go that way, you should at least add a break to the loop, so if you don't find param_#, don't continue looking for param_#+1. While again, less efficient, this at least makes it so you aren't looping 90+ times when the previous one was not found. --Gonnym (talk) 12:37, 24 February 2019 (UTC)

N/A it is. And I can add a break to the loop, that's a good idea. -- /Alex/₂₁ 12:47, 24 February 2019 (UTC)

Missing cell fixed. (Production code still says TBA, but that's not a massive issue at the moment.) N/A added. Loop break added. -- /Alex/₂₁ 13:21, 24 February 2019 (UTC)

Also broken is the Template:Episode list#Episode with multiple titles. --Gonnym (talk) 15:19, 24 February 2019 (UTC)

I fixed the "The time allocated for running scripts has expired." error issue by restoring |NumParts=; guess it is better to keep that. Still working out the multiple titles issue, not sure why that's erroring. -- /Alex/₂₁ 23:23, 24 February 2019 (UTC)

Issue was that it assumed that a Japanese episode was a serial. All fixed, cannot see any further issues now. -- /Alex/₂₁ 03:56, 25 February 2019 (UTC)

Nice, good work. Make sure you update the template documentation (parameter list, templatedata, examples) with any change that affects it. One side-comment though, you've asked me above to to make sure my code works before making it live, while you've just added code, reverted, re-added and later fixed your latest change. Please hold yourself to the same requirements you ask others, and please use the module sandbox before implementing as it makes this process easier to test. --Gonnym (talk) 09:16, 25 February 2019 (UTC)

Noted, but this wasn't six consecutive edits of over 18k bytes within the span of a half hour with three required updates to restore previous functionality; this was one revert and two smaller updates. Updating the documentation now. -- /Alex/₂₁ 09:28, 25 February 2019 (UTC)

If rowspans are not to be used on the right side of a table, after a non-rowspan column, then the module should be updated to not automatically de-columnize all columns, but only those that need it. For example, if the title and director are the same, but the writers are different, then the title and director should rowspan, but the writers and everything afterwards become separated rows. If everything is the same up until the airdate, then everything up until the airdate is rowspan'ed, and only the airdate and everything afterwards become separated rows. See Special:Permalink/889810349#Episodes raw. -- /Alex/₂₁ 02:36, 28 March 2019 (UTC)

Short Summary Not Appearing

Dear Admins,

The short summary is not appearing on my page no matter what? Kindly help me figure out what i am doing wrong? Page is Draft:The Fish'n Canada Show Thank You! --KoolKrazy (Talk To Me!)

Fixed one example for you, the sublist article name you provided was not the same as the article draft article name, which is why it didn't show. But you also don't need /sublist as you are not creating season pages, but a stand-alone page. --Gonnym (talk) 22:47, 19 June 2019 (UTC)

Script errors

Gonnym, I had to revert the most recent change because it added several articles to Category:Pages with script errors including List of Good Mythical Morning episodes, List of Horizon episodes, The Dr. Oz Show, and List of The Nature of Things episodes. I imagine it's due to the string processing on very large input. perhaps if these pages are fixed, we can add the tracking back again? Frietjes (talk) 22:02, 25 October 2019 (UTC)

Thanks for the revert, I checked a lot of pages but I should have checked very long ones as well. I need to think how to identify the initial usage and then only check it once per table. I could check if the number of the first or second episode columns is 1, but not every table uses that column or starts at 1, though most probably do. Will try and think of another way. --Gonnym (talk) 22:37, 25 October 2019 (UTC)

I already have a sandbox that tracks these articles: User:Alex 21/sandbox/Episodes. Just update it through the AWB list comparer. -- /Alex/₂₁ 22:46, 25 October 2019 (UTC)

Oh, that's great Alex, I didn't know! --Gonnym (talk) 22:51, 25 October 2019 (UTC)

Guests and MusicalGuests for talk shows

Per the ongoing discussion at TfD there is some desire to add |Guests= and |MusicalGuests= as an alternative to using the less obvious |Aux1= and |Aux2= in the ca. 106 pages using {{lnep}}. are there any objections to adding these parameters? Frietjes (talk) 18:16, 6 December 2019 (UTC)

I'm perfectly fine with having them added, as long as they are only aliases to the latter two parameters, instead of brand new parameters. -- /Alex/₂₁ 21:07, 6 December 2019 (UTC)

I put some code in the sandbox, which seems to work. We would need to do the same for the episode table. Thanks! Plastikspork _―Œ^(talk) 20:08, 14 December 2019 (UTC)

now deployed. Frietjes (talk) 00:28, 20 December 2019 (UTC)

How is an id parameter set to provide a row anchor?

How is the id parameter set on a table row created with Episode list to create a row anchor for a sectionlink, see Help:Table#Section link or map link to a row anchor? Jim Craigie (talk) 17:24, 28 November 2019 (UTC)

The module creates two possible IDs for each entry - one to the episode number and one to the production number. The relevent code is:

row:tag('th')
	:attr('scope', 'row')
	:attr('rowspan', numberOfParameterGroups)
	:attr('id', 'ep' .. idTrim(idTrim(episodeNumber, ' ----'), '<'))
	:css('text-align', 'center')
	:wikitext(episodeText)

row:tag('td')
	:attr('id', 'pc' .. idTrim(idTrim(args.ProdCode, ' ----'), '<'))
	:css('text-align', 'center')
	:wikitext(args.ProdCode)

--Gonnym (talk) 17:29, 28 November 2019 (UTC)

Thanks for the answer, but an example of what the section link actually looks like would help as none of my guesses have worked.The episode number parameter is EpisodeNumber=79–80 Jim Craigie (talk) 18:38, 28 November 2019 (UTC)

#REDIRECT [[Article#ep79]]. --Gonnym (talk) 18:42, 28 November 2019 (UTC)

So why does episode ''[[List of Silent Witness episodes#ep81|Suffer the Children]]'' episode Suffer the Children not work? Jim Craigie (talk) 22:00, 28 November 2019 (UTC)

The entry is incorrectly formatted. Instead of "ndash;" use "–". --Gonnym (talk) 23:27, 28 November 2019 (UTC)

I have replaced the HTML code with proper "–"'s. However, ''[[List of Silent Witness episodes#ep81|Suffer the Children]]'' still does not work – but, ''[[List of Silent Witness episodes#ep81–82|Suffer the Children]]'' now does work (e.g. Suffer the Children). Now, I have no idea if that impacts the template coding here or not – that's above my pay grade... --IJBall (contribs • talk) 23:40, 28 November 2019 (UTC)

Ok, it seems that using "-" as in 1-2 will work for #ep1, but using "–" as in 1–2, will not. The template usage should be consistent in this. --Gonnym (talk) 23:51, 28 November 2019 (UTC)

FWIW, it definitely should be an 'ndash' not a "regular dash". --IJBall (contribs • talk) 23:53, 28 November 2019 (UTC)

If |EpisodeNumber= uses <hr /> or <br /> (or any other HTML tag), then the anchor is the first number. If the |EpisodeNumber= uses – (or anything else), then the anchor is whatever is displayed/used.

So, the anchor to 1<hr>2 is #ep1, the anchor to 1–2 is #ep1–2, and the anchor to 1–2 (as the example article previously used) would literally be #ep1–2 (see Special:Permalink/927849664#ep1–2 ). -- /Alex/₂₁ 23:57, 28 November 2019 (UTC)

Thanks IJBall for providing a solution for the Silent Witness episodes article. However, it doesn't work for "[[List of Waking the Dead episodes#ep67–68|Duty and Honour]]" "Duty and Honour" which already uses the ndash character rather than HTML, so I don't see why this doesn't work. I copied the episode number in the link from the input parameter to Episode list.

Thanks also to Alex for providing the link into the article as it was, though the part of your answer hidden in your comment is vital: #ep1–2 does not work – it actually has to be #ep1–2 not just for display, but to make the link work. Jim Craigie (talk) 05:48, 29 November 2019 (UTC)

List of Waking the Dead episodes#ep67–68 works now; the article used hyphens, not dashes. -- /Alex/₂₁ 05:53, 29 November 2019 (UTC)

If you are updating Episode list would it be possible to create a third ID containing the |Title= parameter value – it would be much easier to use than having to find the episode number (and its format, which may change invalidating links – if anyone had previously created links into Silent Witness episodes using Alex's solution then IJBall's edit tonight has just invalidated them all!), and production numbers don't exist publicly for UK productions? Jim Craigie (talk) 06:30, 29 November 2019 (UTC)

That's not going to work for lists such as List of Gogglebox episodes; there's too many duplicated titles for IDs to work, and episode numbers are (typically always) unique entries. -- /Alex/₂₁ 06:57, 29 November 2019 (UTC)

Agreed it wouldn't work everywhere, but most places Title would be unique and easier to use. Jim Craigie (talk) 07:35, 29 November 2019 (UTC)

Except there's already a unique option to use. Yes, it does need to be made easier to access, but there's no point implementing another feature when it's already present. -- /Alex/₂₁ 07:40, 29 November 2019 (UTC)

I've modified the declaration for an episode number's ID attribute to simplify it. Now, it's simply the first alphanumeric characters before any special characters (e.g. dashes, ndashes, hyphens, line breaks, etc.); see this at List of Silent Witness episodes#ep81, List of Waking the Dead episodes#ep67, Special:Permalink/927849664#ep1. -- /Alex/₂₁ 07:59, 29 November 2019 (UTC)

A good fix, but I just found episodes numbered with a decimal point in Survivors (2008 TV series) so ''[[Survivors (2008 TV series)#ep2.04|Episode 2.4]]'' Episode 2.4 doesn't work (and their episode titles aren't unique either!). Jim Craigie (talk) 17:00, 30 November 2019 (UTC)

Then fix the tables. An episode number should be an integer. 2.04 represents season and episode. Gonnym (talk) 17:36, 30 November 2019 (UTC)

 Fixed. --IJBall (contribs • talk) 18:24, 30 November 2019 (UTC)

@Alex 21:, while we are fixing issues with the episode ID, do you have any idea for a solution for cases where we have a specials or webisode table? List of Heroes episodes as an example. Can't like to any specific episode, is they share the anchor with regular episode. --Gonnym (talk) 08:28, 29 November 2019 (UTC)

{{Episode table}} now supports |anchor= which allows duplicate numbering on the same page. See doc for more info. --Gonnym (talk) 06:25, 13 January 2020 (UTC)

Raw code for template??

Where is the raw code for this template so that some people have the ability to use it on other mediawiki sites? — Preceding unsigned comment added by 69.137.181.135 (talk) 17:48, 14 January 2020 (UTC)

Episode lengths?

Has any thought ever been given to adding an optional parameter for episode lengths? With an increasing number of shows where this varies, seems it would be useful information to tabulate in some cases. U-Mos (talk) 21:20, 7 February 2020 (UTC)

If added, it should be documented to only to be used on shows that can have variable lengths: BBC programs, HBO programs, etc. but not your typical American series where each show is basically the same length plus-or-minute a minute. In the latter case, most likely one might get a double-length episode, but this can be noted in the short description. (Basically, it would be boring to see "43 min" over and over and over again in an episode list if that's the standard) --Masem (t) 21:34, 7 February 2020 (UTC)

Agreed. U-Mos (talk) 22:24, 7 February 2020 (UTC)

Mobile display problem - text needs to wrap

Is there anything that can be done about the way this template displays on mobile? Someone posted this screenshot on Reddit: instead of wrapping the text, it merely cuts it off and nothing can be done to scroll over and view it. Adding a scrollbar would be just as ugly, but can't the table width be set to fit the window and automatically wrap? Thanks. —Мандичка^YO 😜 16:21, 9 March 2020 (UTC)

You can scroll to keep viewing the table. I don't know why you believe you can't when you said nothing can be done to scroll over and view it. Additionally, I don't really think there's anything that can be done because the table inherently is larger in px width than your standard mobile phone display. - Favre1fan93 (talk) 17:02, 9 March 2020 (UTC)

I believed the person who posted about it — it's not my technical issue. I'm guessing since it should be obvious that you should be able to touch the screen to move over, this isn't working on all phones. —Мандичка^YO 😜 17:19, 9 March 2020 (UTC)

I have very limited HTML knowledge, but found some guide that shows this User:Gonnym/sandbox/tests1 (view it also with the mobile version and resize the window size). The only issue is with the initial headers. The MediaWiki does not support <thead>, <tfoot> and <tbody> which are needed to hide them. Anyways, even to get this to work would require probably a lot of work to redesign the code better. --Gonnym (talk) 17:24, 9 March 2020 (UTC)

TBA and TBD

I don't think the template should automatically fill in "TBA" and "TBD" for empty values. That sort of assertion is not encyclopedic. The template should only list information that's available without guesswork about something that "will be announced" or "will be determined." Some episodes are many decades old and the missing information will never be announced or determined. Even with new shows, it's presumptuous that some missing information will be announced or determined. NameMyRemember (talk) 09:17, 24 March 2020 (UTC)

In the example you stated regarding older shows, simply put {{N/A}} or Unknown for any fields in which TBA or TBD are not appropriate. - Favre1fan93 (talk) 15:46, 24 March 2020 (UTC)

I think, unless there's a source, it's never appropriate to "fill in the blanks". NameMyRemember (talk) 06:18, 7 April 2020 (UTC)

The reason you "fill in the blanks" with "N/A", "TBD/TBA", is because it helps readers know that someone has looked and there is no information available. As opposed to people thinking something is missing and inserting their own information they think is true.  BIGNOLE  (Contact me) 15:45, 7 April 2020 (UTC)

Duration

The template has no parameter for 'Duration' or 'Total length'. I think it should be, as it's useful for many users like me. Thank you. Empire AS ^Talk! 08:27, 31 July 2020 (UTC)

There are custom parameters you can use if you feel one is needed. I personally feel duration adds no value when most episodes for a series are roughly the same length. Gonnym (talk) 08:36, 31 July 2020 (UTC)

We've actually discussed this in the past and the consensus was that it isn't necessary. The runtime for episodes varies and even the infobox for main series articles only requires an approximation. Pssst, Gonnym, I think you meant custom.) --AussieLegend (✉) 08:39, 31 July 2020 (UTC)

oops! --Gonnym (talk) 08:46, 31 July 2020 (UTC)

From Aux1, duration can be used. Thank you for your help. Empire AS ^Talk! 10:05, 31 July 2020 (UTC)

Seems to broken

Seems to be broken right now. 2601:14F:4500:4300:E56D:E54A:DAA7:549B (talk) 07:50, 4 August 2020 (UTC)

An error has happened. It's loading some text 'Lua error' written in red colour. Perhaps it happened due to latest edit of Alex 21. Tears. Empire AS ^Talk! 08:01, 4 August 2020 (UTC)

Terribly sorry. It's been reverted; I'll work on a better solution. Cheers. -- /Alex/₂₁ 08:42, 4 August 2020 (UTC)

Better solution implemented and tested. -- /Alex/₂₁ 08:59, 4 August 2020 (UTC)

Problem when removing number field

Without | EpisodeNumber field, title becomes bold. See for example List_of_Sailor_Moon_episodes#Shorts. Smeagol 17 (talk) 11:12, 3 September 2020 (UTC)

Background for references in table header on Chrome/webkit browsers looks bad/is not accessible

Hello maintainers 👋

While editing Elmo's World, I noticed that the background to references added for accessibility looks different on Chrome than they did in Firefox. The result does not look good and is not accessible as roughly half of the reference does not have a high contrast.

Episode list table header with reference on Chrome

I took a crack at modifying the inline CSS and was able to get it to look good in Chrome but but it subsequently broke it in Firefox.

Some things we could consider to fix this is:

• more CSS hacking to try to get this to work across all browsers
• use Template Styles to utilize CSS selectors to put the background just on the <sup> tag, without needing to wrap it in a <span>.

I'd be happy to work on this, but I'd appreciate some input first. —motevets (talk) 15:51, 15 September 2020 (UTC)

Can you provide some more info? I mainly work on Wikipedia on Chrome on a Macbook Pro, and the reference backgrounds are working properly for me. The tables as they existed here at Elmo's World render properly for me. - Favre1fan93 (talk) 18:49, 15 September 2020 (UTC)

Also works for me viewing that diff on the mobile site using Chrome for iOS. - Favre1fan93 (talk) 18:50, 15 September 2020 (UTC)

Now I feel silly. The issue is happening for me on Vivaldi which is a Chromium fork. I assumed that if it was a problem on Vivaldi, then it was a problem on all Chromium based browsers, but that's not the case. It's working fine for me on Chromium and Google Chrome on Ubuntu Linux 20.04. It's likely a bug in Vivaldi. —motevets (talk) 23:57, 15 September 2020 (UTC)

@Motevets: No worries. That's why I wanted to know your additional info, given things were working for me on Chrome proper. Yes, I'm going to assume it's an issue on Vivaldi's end, as for comparison, the refs render fine on Safari. - Favre1fan93 (talk) 01:26, 17 September 2020 (UTC)

Remove "TBA"

I think the TBA default entry should be removed or replaced by a dash. It shows up in episode lists of old shows where the director and/or writer are unknown or information hasn't yet been entered into the article. That is clearly not the same thing as "to be announced". 93.136.110.156 (talk) 06:40, 4 December 2020 (UTC)

Yes, using a blank entry would probably work — Martin (MSGJ · talk) 19:58, 4 December 2020 (UTC)

A black entry or dash would work perfectly fine at those relevant articles. However, we need not removal the default, no, as there are more articles that require the TBA as an actual "to be announced" then those that don't. We don't remove a widespread feature to fix the articles. You are more than welcome to insert dashes or black entries at the articles for those older series, or use {{TableTBA|N/A}}. -- /Alex/₂₁ 02:05, 10 December 2020 (UTC)

Wikidata functionality

It would be great if the module could get data like title, director, screenwriter, etc. from Wikidata if not specified in the article. For example on The No. 1 Ladies' Detective Agency (TV series)#TV series (2009) I could write

{{Episode list|qid=Q102864920}}

and all relevant data would be read from Wikidata. Apart from the summary (which would need to remain in the article) most of the other fields are supported in Wikidata — Martin (MSGJ · talk) 20:05, 4 December 2020 (UTC)

@Alex 21: would this idea be worth exploring? — Martin (MSGJ · talk) 21:50, 9 December 2020 (UTC)

MSGJ, certainly. (Thanks for the ping, I must have removed this page from my watchlist.) I've never implemented Wikidata into a module, but it's definitely something I can look into. I'd also recommend only using this feature for older shows, or concluded shows, where absolutely nothing is set to change in the future. -- /Alex/₂₁ 02:06, 10 December 2020 (UTC)

EpisodeNumber in NumParts

Not sure if this has been discussed before, but is there a reason why there is no EpisodeNumber_1, EpisodeNumber_2, EpisodeNumber2_1, EpisodeNumber2_2, etc.? - adamstom97 (talk) 08:08, 9 December 2020 (UTC)

Probably because dashes provide exactly the same meaning. We can't use dashes to separate credits or dates, and since we shouldn't be using <hr> to separate episode numbers (as the only usage for that tag is a "visual" separation), we can just use dashes for episode numbers, as it shows the spanning range. -- /Alex/₂₁ 02:08, 10 December 2020 (UTC)

I just think it would be more useful to have the numbers line up with the rest of the info, at the moment it looks like it is wrong (which is no doubt why people keep trying to make it look more correct by using <hr>). - adamstom97 (talk) 07:03, 10 December 2020 (UTC)

The iPhone was first released in 2007

Despite having a mobile website (that still looks completely different to the desktop website) for some years now, this template hasn't been updated to work well on phones. Sticking prose into a table that requires constant side-to-side scrolling on narrow screens isn't a great idea. List of Not Going Out episodes is a particularly awful example of this. Why is the Wikipeedia "community" so consistently uncaring about half your readership? Perhaps one of the 'template editors' could do some template editing to bring this template into the 2010s (a decade late). Oh, DrPizza! (talk) 02:57, 11 January 2021 (UTC)

If you have a suggestion on how to replicate the amount of info/formatting conveyed horizontally in this table (that works well on a desktop) in a way that won't make the info insanely squished to fit in the smaller confines of a phone screen's width, I'm sure the TV projects would be all ears. - Favre1fan93 (talk) 04:02, 11 January 2021 (UTC)

Oh, DrPizza!, agreed with the above. Do you actually want to provide a solution, or even ask in a more civil and contributive manner? Or are you uncaring about being polite to your fellow editors and template editors? -- /Alex/₂₁ 04:37, 11 January 2021 (UTC)

As I indicated, the problem is the constant side-to-side scrolling of the prose added using the ShortSummary parameter. This causes the text to wrap to the width of the table, which on phones is often wider than the width of the screen. So a solution would seem to be to remove the non-tabular data from being inside a table. Let tables be used for the tasks they were designed for instead of doing double duty as a (poorly-working for half your readership) container for a paragraph or two of text.

Alex 21 Yes, I am uncaring about Wikipeedia editors, in much the same manner as your good self. When it comes to on-wiki rudeness, you are an inspiration and personal hero of mine. Oh, DrPizza! (talk) 01:16, 12 January 2021 (UTC)

Irregardless, this template is based on your standard "wikitable" css class, which on any other article having a full spanning normal table is in this same boat as this needing to side-to-side scroll on mobile. - Favre1fan93 (talk) 02:10, 12 January 2021 (UTC)

Given your lack of civility in both your contributions here and your edit summaries (and lack of serious editing), it's clear that you're WP:NOTHERE. Thank you for your post and lack of contributive suggestion. -- /Alex/₂₁ 13:08, 12 January 2021 (UTC)

Noted. And thanks for the thank you. Oh, DrPizza! (talk) 05:43, 14 January 2021 (UTC)

So? The problem isn't that the *tabular data* scrolls - that's just how it tends to be on mobile. The problem is that *non-tabular data* is inappropriately shoehorned into the table and therefore must also be scrolled in order to be read. If it was presented appropriately, i.e. outside a table, it would wrap to the width of the screen or window. The problem is not with the wikitable CSS, it's that a table is being used to do something it isn't designed for - with predictably poor results. The problem lives in this template and its ham-fisted attempt to provide one solution for dealing with two different types of content. Oh, DrPizza! (talk) 02:50, 12 January 2021 (UTC)

To follow up on this, your own Manual of Style lists 'prose' and 'page layout' as inappropriate uses for tables. This template is certainly in violation of the former and arguably in violation of the latter as well. Oh, DrPizza! (talk) 04:51, 12 January 2021 (UTC)

What's the actual problem here? Is it just that you have to scroll from side to side? - adamstom97 (talk) 06:00, 12 January 2021 (UTC)

Over and over again. On my phone, using Doctor_Who_(series_12)#Episodes as an example, I get about 8 or 9 words into the summary before needing to scroll. Then about 3 or 4 words later I reach the end of the line and need to scroll back to the start of the next line. There are about 13 to 16 lines per summary. Oh, DrPizza! (talk) 12:15, 12 January 2021 (UTC)

Is there an accessability policy stating that scrolling is detrimental to accessing Wikipedia? I fail to see one. -- /Alex/₂₁ 13:09, 12 January 2021 (UTC)

I was perusing Archive 7 to amuse myself with examples of you being you (you delivered!). So it comes as a surprise (/s) to see you caring about accessibility issues. But you tangentially raise a good point; the repetitious side-to-side scrolling would not be helpful for people with (or preventing people from developing) RSI problems. But I'm impressed with your implication that you do in fact care about Wikipeedia's readers. As for the amazingly specific question of whether Wikieedia has policy on detrimental scrolling, I'm going to go out on a limb and say no. Anyway, nice stalling, Alex. You're a clever one. For instance, you wouldn't forget that you hadn't logged in. Oh, DrPizza! (talk) 05:43, 14 January 2021 (UTC)

Yawn. Have you got anything to actually contribute to the fixing of the issue or not? I'm sure that if you contribute to the sandbox, an editor will be happy to implement your fix. -- /Alex/₂₁ 12:32, 14 January 2021 (UTC)

Yawn. Are you bored? That would be a shame. I thought you enjoyed being a pugnacious wikisoldier. Well, participating in this discussion is entirely optional. Oh, DrPizza! (talk) 03:58, 17 January 2021 (UTC)

The more you post, the more it is clear that you are WP:NOTHERE to construct an encyclopedia with your repeated derision and attacks on other edits. As for the issue of side-to-side scrolling, there is no way to resolve this other than to remove the summaries altogether. There is no possible way to incorporate them without side-to-side scrolling. 24.149.102.22 (talk) 11:54, 14 January 2021 (UTC)

The mysterious IP (how did they know about this discussion given IPs can't watchlist anything - must have used the Atom feed, ha ha) almost gets it when they say As for the issue of side-to-side scrolling, there is no way to resolve this other than to remove the summaries altogether. As stated, the prose summaries should be taken out of a table and put into compliance with your own MOS. Something like this. The separate episode "rows" can still be combined into a consolidated table:

User:Oh, DrPizza!/Having a ton of fun with Alex 21

Anyway, I look forward to the "community" sticking its head in the sand and continuing to pretend this isn't a problem, just like last time. Oh, DrPizza! (talk) 03:58, 17 January 2021 (UTC)

Something like this. God, that's horrifying and a complete violation of tabular formatting and accessibility policies. Absolutely not. Thanks for the suggestion but let's take a heavy pass. I can guarantee you're going to get 0% consensus from any WikiProject for that. I mean, you're welcome to try, though. Go for it. -- /Alex/₂₁ 04:02, 17 January 2021 (UTC)

Your opinion is noted. Oh, DrPizza! (talk) 04:29, 17 January 2021 (UTC)

That's very much worse, not to mention WP:ACCESS issues and basic formatting issues. I will add as other have said, unless you have anything substantial to add to solve this, stop the personal attacks and drop the stick. - Favre1fan93 (talk) 04:48, 17 January 2021 (UTC)

I'm going to ignore the personal attack since that doesn't have anything to do with the discussion. But if the episode summaries are removed from the tables, then where should they be moved to? Because outright removing them would be a violation of the WP:SPOILER guideline and many readers do find the summaries useful. 216.30.146.95 (talk) 14:52, 17 January 2021 (UTC)

The above link was deleted given its title, but the editor proposed having a table with a single row for episode credits, then summary as prose, then another table with a single row for episode credits, then summary as prose, etc; i.e. having ten tables in the article for ten separate episodes, all with prose in between them. -- /Alex/₂₁ 23:50, 17 January 2021 (UTC)

Pokémon transliteration

I have a question regarding the first example under Template:Episode list#Non-English titles. Following WP:ROMAJI, I was expecting it to be written "Pokémon", because that is the common English name, based on the title and text of the article Pokémon. Custardbandlers says following WP:ROMAJI it should be "Pokemon" because that's the Hepburn romanization. Which is correct? Thanks! -- Beland (talk) 04:28, 5 March 2021 (UTC)

"Pokémon" is ultimately how it is officially marketed and trademarked, but that's just for that reason. Since Hepburn romanization doesn't use é in its transliteration rules, ポケモン should be transliterated as Pokemon except in instances when we're talking about the franchise's title.--十八 08:46, 5 March 2021 (UTC)

@Juhachi: "Pokémon" also seems to be the spelling used in English when referring to a class of creatures, such as some of the uses in Pokémon episodes removed from rotation. Is that an error? -- Beland (talk) 08:03, 7 March 2021 (UTC)

Okay, yeah, and also when referring to the titular monsters. But you were specifically asking about transliterating ポケモン when used in an episode title, such as in episode 1, Pokémon, I Choose You!. Basically what I'm saying should be done is how that article does it in the lead, using "Pokémon" for the English title because that is how it was written in the English version of that episode title, and Pokemon! Kimi ni Kimeta! as a transliteration of ポケモン！きみにきめた！ because Hepburn romanization only uses macrons as diacritics for long vowels and doesn't employ any other diacritic. This is simply following the rules of Hepburn romanization which is the standard for romanizing Japanese on Wikipedia based on WP:ROMAJI.--十八 09:13, 7 March 2021 (UTC)

OK, thanks for the third opinion! -- Beland (talk) 22:47, 15 March 2021 (UTC)

Sublist

There's no explanation of what Episode list/sublist is for in the documentation. There are usage examples but no clear description of it's purpose. What is the purpose of sublist? - X201 (talk) 07:49, 23 April 2021 (UTC)

It's detailed in the "Transclusion of the list on another page" section, as well as in the ShortSummary parameter explanation. If an episode table is not transcluded, we use {{Episode list}}; if an episode table is transcluded elsewhere, we use {{Episode list/sublist}}, so that the summary only appears on the primary article. -- /Alex/₂₁ 08:03, 23 April 2021 (UTC)

Episode table at Seabound_(Ninjago_season)

The episode table at Seabound_(Ninjago_season)#Episodes is behaving strangely, and I can't figure out why. The Viewers parameters are empty, and the template adds "N/A" to the Viewers column for episodes 1 thru 6, but adds "TBD" to episodes 7 thru 16. Any ideas?— TAnthony^Talk 16:18, 19 May 2021 (UTC)

I wonder if the switch to state "N/A" or "TBD" has to do with checking against the airdate? Perhaps that's the issue? - Favre1fan93 (talk) 17:49, 19 May 2021 (UTC)

That is correct. The viewers list as TBD until a month after the airdate (or rather, four weeks), after which the code automatically assumes that viewer's won't be added, hence N/A. You can manually revert this by setting |Viewers={{TableTBA|TBD}}. -- /Alex/₂₁ 21:20, 19 May 2021 (UTC)

Not Mobile Friendly

Episode guides are still painful to read on mobile because the episode metadata columns are too wide, forcing the description field to be wider than the screen, such that you have to scroll horizontally back and forth to read them. This screenshot from a tweet 6+ years ago shows the problem that still exists today: https://twitter.com/jelsert/status/659548147086204928

It's 2022, and the rest of the web has solved this with responsive web design a decade ago. What would it take to fix this? It would require updating the CSS, but I have no idea who is responsible for that, or how we could encourage that? --ToastyKen (talk) 03:46, 11 February 2022 (UTC)

You got any suggestions? I'll happily implement them if there's ideas presented. -- Alex_21 _TALK 03:48, 11 February 2022 (UTC)

Slash is interpreted as en/em-dash in episode number parameter

Hello! Recently I was editing Jay Leno's Garage#Compilation (2020) to make the "Number overall" display as N/A instead of TBA since they aren't considered to be part of the main series and therefore don't have a number overall. I was forced to use / instead of "/" as in the "episode number" parameter, the "/" character is displayed as an en/em-dash (I don't know what the difference is at first glance, all I know is one is longer). Any reason why it does this? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:27, 14 March 2022 (UTC)

Misuse of template parameters will cause unexpected issues. If a column is empty, or as in this case, full of "N/A" values, then just don't use it. Gonnym (talk) 19:08, 14 March 2022 (UTC)

@Gonnym: Ah alright then. Wasn't sure if removing it would break anything. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 19:11, 14 March 2022 (UTC)

Proposal to use title as heading cell

The title of an episode might be a more natural heading for the row in table. It also provides the link to the standalone article, if it exists, so would give this link more prominence at the beginning of the row. I will try and provide some examples of how it might look. — Martin (MSGJ · talk) 21:32, 11 May 2022 (UTC)

Current

No. overall	No. in series	Title	Location	Directed by	Original air date	UK viewers (millions)
13	1	"The Devil of Christmas"	Alpine chalet	Graeme Harper	27 December 2016 (2016-12-27)	1.03

Suggested

Title	No. in series	Location	Director	Original air date	UK viewers (millions)
"The Devil of Christmas"	1	Alpine chalet	Graeme Harper	27 December 2016 (2016-12-27)	1.03

Some episodes do not have actual titles, so the "Title" column/parameter shouldn't be our row header. The number in series/season or number overall should still have that distinction. - Favre1fan93 (talk) 16:39, 12 May 2022 (UTC)

Proposal to include plot summary within heading cell

Related to proposal above, I think it would be clearer, more semantic and accessible if the heading cell of each episode spanned the plot summary too. Then it would be more obvious which episode the summary related to. Mock up will be posted below. — Martin (MSGJ · talk) 12:04, 12 May 2022 (UTC)

Suggested

Title	No. in series	Location	Director	Original air date	UK viewers (millions)
"The Devil of Christmas"	1	Alpine chalet	Graeme Harper	27 December 2016 (2016-12-27)	1.03
	In a film within the episode, an English family (Pemberton, Rula Lenska, Jessica Raine and George Bedford) travel to an Austrian chalet in December 1977. They are told the story of the Krampus by their guide (Shearsmith). Meanwhile, the film's director (Derek Jacobi) provides audio commentary.

I don't think it is an improvement to have the episode titles in a narrower column like that where many titles will have to be broken over multiple lines, unlike the current style. I also don't think there is any issue with understanding which summary goes with each episode in the current design. - adamstom97 (talk) 10:36, 13 May 2022 (UTC)

Although this is a late comment, I would agree that the narrower column would be problematic - especially in situations where there are multiple titles for an episode (as can occur in animated series). It looks nice for some, but would/could be quite a mess for other. ButlerBlog (talk) 14:22, 23 September 2022 (UTC)

The title column could be auto-width or changed by parameter like it is now if necessary, this just seems like an example. Thanks, Indagate (talk) 18:41, 24 September 2022 (UTC)

ShortSummary parameter description

The description for ShortSummary is that it be a plot summary. There has been, and continues to be, a trend towards including additional information as "notes" and I've seen this from new and experienced editors alike. Where do we draw the line on what's appropriate and what's not, and should the parameter description be a little more clear on what's allowed? I think it's obvious when it's trivia. For example, I recently removed a "note" that was describing a stock footage scene in The Waltons that was also used by Gilligan's Island. But there are other less obvious situations, especially when it comes to cast. We do see a lot of guest cast noted in the ShortSummary, which I think is an appropriate place to note specific cast additions. But sometimes this gets extended to information about So-and-so appears but is not credited, or So-and-so is credited but does not appear; and for a series that uses stock credits, that can get tedious for minor characters who are in the standard credits but do not appear in every episode. Am I being too rigid in trying to figure out a bright line on this? ButlerBlog (talk) 14:30, 23 September 2022 (UTC)

I don't know if we need to be too specific on this, I think it is clear when things have gone too far. If the article doesn't have a cast list and is including guests in the episode table then I think that makes sense, if they are adding things that only TV nerds care about such as "so-and-so appears but is not credited" then that should be taken out. My rule of thumb is, do we need the note in order to understand the plot summary? And if not, is there local consensus that the note is definitely needed in the article and the table is the most logical place for it? - adamstom97 (talk) 23:17, 26 September 2022 (UTC)

Empty parameters switch to "NA" over TBA based on date

Currently, if a parameter is included (such as |DirectedBy=) with no content, "TBA" will fill the cell. However, this doesn't necessary make sense for episodes that have not filled in the parameter after its air date. In that case, it should be "N/A" or perhaps a "–". Is this possible to add in a check against whatever is placed in the "airdate" parameter, and make it be TBA for a future episode, and "N/A" or "–" for a past one? See A Touch of Grace, a show from the 1970s with a number of unfilled in parameters, as an example where this is a problem. - Favre1fan93 (talk) 21:45, 18 September 2022 (UTC)

Courtesy ping to Alex 21, any chance this is possible? - Favre1fan93 (talk) 17:18, 19 September 2022 (UTC)

Thanks for that! And yeah, absolutely. It's how the viewer cell changes from TBD to N/A if it's been left empty for more than four weeks, it's certainly something I could look into implementing across a row's cell. -- Alex_21 _TALK 22:40, 19 September 2022 (UTC)

No worries! I'd say the same time frame works just as well. Anything past four weeks that isn't filled in should either not be in the table or changed to "N/A". - Favre1fan93 (talk) 00:08, 20 September 2022 (UTC)

Thinking more on this, if it can happen, I don't know if "N/A" is best, at least for directors and writers, because that implies there aren't any if someone hasn't included them like at A Touch of Grace. Perhaps it should become "Unknown"? - Favre1fan93 (talk) 02:15, 20 September 2022 (UTC)

 Done -- Alex_21 _TALK 04:55, 26 September 2022 (UTC)

@Alex 21: This causes Lua errors if there's no original air date set, for example at List of Makutano Junction episodes. Please revert or fix this. --rchard2scout (talk) 12:41, 26 September 2022 (UTC)

 Reverted * Pppery * _{it has begun...} 13:09, 26 September 2022 (UTC)

@Rchard2scout  Fixed -- Alex_21 _TALK 23:56, 26 September 2022 (UTC)

Summary text is too wide on mobile

Because these tables can get pretty wide, I often notice that the ShortSummary text is stretched beyond the width of a mobile device screen. The result is a poor experience on mobile where you have to swipe the screen left and right to read across the lines of the paragraph.

You should consider limiting the width of the text in the ShortSummary cell to the width of the viewport on mobile. Something like a max-width of 90vw would make it a lot easier for mobile users to read the summaries. DrewBino ^talk (afc0703) 01:39, 31 January 2023 (UTC)

In my experience, the width of the table on mobile is being determined by the header row and the summary text is just following suit. Forcing all of the column names to fit within a max width of 90vw is going to create a worse experience then having to scroll back and forward a little bit. - adamstom97 (talk) 02:51, 31 January 2023 (UTC)

I'm not suggesting to force the column names to that width. I'm suggesting to force only the text in the ShortSummary cell to that width. (e.g., surround the ShortSummary text with a div or inline-block span and set the max-width on that div/span.) DrewBino ^talk (afc0703) 13:45, 31 January 2023 (UTC)

Proposal to split EpisodeNumber in NumParts

Per consistency with other multipart episode parameters that have been added to this template, I propose we also use EpisodeNumber_1, EpisodeNumber_2, EpisodeNumber2_1, and EpisodeNumber2_2. Many episode lists currently use <hr> to split episode numbers, which has been objected to by User:Alex 21 for accessibility reasons (see our own user talk discussion), so these further NumParts additions would address those concerns. The residual dashes which are still used in certain episode lists are really less clear visually – especially the cases where directors/writers are only credited in part 1 or part 2 specifically – and the dashes are inconsistent with the visual grammar of presenting all other episode numbers vertically. Discovered this idea was previously floated two years ago by User:Adamstom.97, and I agree this should be implemented. -- Wikipedical (talk) 20:46, 6 December 2022 (UTC)

So, there are two ways of representing multiple episode numbers: with an en dash and a range ("119–120") or with a line break ("119", and on the line below, "120"). And there's much agreement over the facts and the pros and the cons. For accessibility and consistency, we either need one parameter and en dash ranges or multiple parameters and line-break-separated values.

The pros of line breaks: consistency with other parameters. The pros of en dash ranges: one parameter; more compact. And disputed is which is more readable—I would say that line breaks make for quicker eye scanning, so I would favour this multi-parameter setup and move away from en dash ranges. Since many volunteers have been manually recreating the line breaks without the parameter support for that, it seems like this might be a majority opinion. — Bilorv (talk) 00:46, 29 December 2022 (UTC)

I still agree with this change, if it makes sense to split other fields into two then I definitely think there should be an option to do the same for the episode numbers. - adamstom97 (talk) 22:28, 7 January 2023 (UTC)

Yes, this should be implemented. - Favre1fan93 (talk) 20:18, 25 January 2023 (UTC)

Also agree with this. InfiniteNexus (talk) 06:07, 26 January 2023 (UTC)

Hey @Alex 21: Could you look into this? Thanks. InfiniteNexus (talk) 16:57, 31 January 2023 (UTC)

I noticed this has yet to be implemented, and I do want to note I support it. Would it be best if we use the edit template-protected notice as indicated at the top? Trailblazer101 (talk) 23:35, 10 February 2023 (UTC)

We can ask someone else. @Gonnym: Are you able to help implement this? InfiniteNexus (talk) 19:49, 11 February 2023 (UTC)

I haven't followed this disscussion nor have I touched this module in a long time. I'll take a look at this this week and see if this is something I can help with. Gonnym (talk) 22:52, 11 February 2023 (UTC)

Thanks. InfiniteNexus (talk) 18:57, 12 February 2023 (UTC)

Hi @Gonnym:, were you able to take a peek this week? -- Wikipedical (talk) 19:40, 18 February 2023 (UTC)

@Gonnym: Not to rush you, but if you are unable to implement this, please let us know so we can make an edit request instead. Thanks. InfiniteNexus (talk) 18:11, 6 March 2023 (UTC)

@Alex 21: I know you have been active again recently. Any chance you would also be able to take a look at adding this functionality? Many thanks as always. - Favre1fan93 (talk) 00:05, 7 March 2023 (UTC)

Hmmm. I can take a look, but no promises; to be honest, I'm not overly familiar with many parts of the code since its overhaul some years back, especially the spanning and accessibility parameters, but I can give it a stab. -- Alex_21 _TALK 01:44, 7 March 2023 (UTC)

I've had the day off, so I thought I'd give it a crack to see what I would get. Let's analyze the following results:

No. overall	No. in season	Title	Directed by	Written by	Original air date	U.S. viewers (millions)
43	21	"S.O.S."	Vincent Misiano	Jeffrey Bell	May 12, 2015 (2015-05-12)	3.88
43	21	"S.O.S."	Vincent Misiano	Jeffrey Bell	May 12, 2015 (2015-05-12)	3.88
			Billy Gierhart	Jed Whedon & Maurissa Tancharoen
43 44	21 22	"S.O.S."	Vincent Misiano	Jeffrey Bell	May 12, 2015 (2015-05-12)	3.88
			Billy Gierhart	Jed Whedon & Maurissa Tancharoen
43	21	"S.O.S."	Vincent Misiano	Jeffrey Bell	May 12, 2015 (2015-05-12)	3.88
44	22		Billy Gierhart	Jed Whedon & Maurissa Tancharoen

• The first example is a standard episode listing without a split.
• The second example is a split episode listing, where both splits take the same episode number.
• The third example is a split episode listing, where the episode numbers use the format that's currently used in episode listings, using either Number<hr>Number or Number–Number. This shows that if the module is updated, existing episode listings won't become broken.
• The fourth example is a split episode listing, where the episode numbers use the format that's being requested, with split parameters.

However, this new fourth example then leads me to the following observation. Notice how the airdate and viewers cells are also split, despite having equal values. The reasoning for this in the past has been that, if we have a cell that's single-spanning, all cells afterwards must also be single-spanning (i.e. we cannot have a multiple-spanning cells after single-spanning cells), due to "accessibility reasons". However, I've never seen any contributing support or documentation for this, and if we were to implement these edits, then we have single-spanning episode numbers and a multiple-spanning title following. This has also never been an issue for spanning cells in {{Series overview}} (e.g. List of Star Trek television series), so after this edit, I would suggest that we implement the merging of those equal-valued cells to be multiple-spanning rather than duplicated single-spanning cells. -- Alex_21 _TALK 05:04, 7 March 2023 (UTC)

@Alex 21: Thanks for taking a look! Yes I agree about the spanning concern, and think if the material is the same for however many parts of the split, it should be a single cell. Because in theory, won't the "single" row still be that instance of {{Episode list}} being used? So I think that shouldn't affect accessibility. - Favre1fan93 (talk) 19:13, 7 March 2023 (UTC)

Fantastic; I already have the code ready and tested to implement. I'll wait a bit to see if there's any other opinions first. -- Alex_21 _TALK 19:50, 7 March 2023 (UTC)

Actually, doesn't it already span? This is what happens when I trying to do this on the content for Marvel Studios: Legends (using the live code and hr for the episode numbers):

No. overall	No. in season	Title	Associated MCU work	Original release date
1 2	1 2	"Wanda Maximoff"	WandaVision	January 8, 2021 (2021-01-08)
		"Vision"

Aux3 and Airdate already span. Is something different happening with the examples you gave Alex? - Favre1fan93 (talk) 20:02, 7 March 2023 (UTC)

When |Title_1=, |Title_2=, ..., are used, they don't generate a split cell, and instead just use <hr> between the titles, meaning none of the cells above are actually spanning, they're just all, by default, spanning one row. They're visually split, yes, which is where and why all the accessibility discussions came into being years ago, because this is what was being done for all cells. Note how for that example, you didn't need to use |NumParts=2. The reasoning for this is slightly unclear to me; I think it's to do with the long-deprecated Japanese episode lists, where titles where the only things there were multiples of, hence the row didn't need splitting. To generate actual split rows for the titles, see how the wikicode does it for The Sandman (TV series)#ep11; we need to use |Aux1_1=, |Aux1_2=, ...

When any other split parameters, such as |Director_1=, |Director_2=, ..., are used, then all cells after that are split by default. So if you duplicated the table above, but copied the formatting from The Sandman as linked, and used |Aux1_1= and |Aux1_2= to actually split the titles, you'd find that |Aux3= and |OriginalAirDate= would also split. -- Alex_21 _TALK 20:10, 7 March 2023 (UTC)

Ah got it. Thanks for the additional info! So to circle back, I'm still for implementing on |EpisodeNumber= and then helping span info as needed correctly, however that is accomplished. - Favre1fan93 (talk) 16:14, 8 March 2023 (UTC)

I also agree with implementing this. InfiniteNexus (talk) 16:51, 8 March 2023 (UTC)

 Done -- Alex_21 _TALK 20:04, 8 March 2023 (UTC)

Thanks Alex! InfiniteNexus (talk) 16:43, 9 March 2023 (UTC)

So I don't know if I'm doing something wrong, but this is what happens when I try to use |Title_1= and |Title_2= with the new code:

Extended content

List of Marvel Studios: Legends episodes No. overall No. in season Title Associated MCU work Original release date  1 1 "Wanda Maximoff" WandaVision  January 8, 2021 (2021-01-08) 2 2 "Vision" 3 3 "Falcon" The Falcon and the Winter Soldier  March 5, 2021 (2021-03-05) 4 4 "The Winter Soldier" 5 5 "Zemo" 6 6 "Sharon Carter" 7 7 "Loki" Loki  June 4, 2021 (2021-06-04) 8 8 "The Tesseract" 9 9 "Black Widow" Black Widow  July 7, 2021 (2021-07-07) 10 10 "Peggy Carter" What If...?  August 4, 2021 (2021-08-04) 11 11 "The Avengers Initiative" 12 12 "The Ravagers" 13 13 "The Ten Rings" Shang-Chi and the Legend of the Ten Rings  September 1, 2021 (2021-09-01) 14 14 "Hawkeye" Hawkeye  November 12, 2021 (2021-11-12) 15 15 "Doctor Strange" Doctor Strange in the Multiverse of Madness  April 29, 2022 (2022-04-29) 16 16 "Wong" 17 17 "Scarlet Witch" 18 18 "Thor" Thor: Love and Thunder  July 1, 2022 (2022-07-01) 19 19 "Jane Foster" 20 20 "Valkyrie" 21 21 "Bruce Banner" She-Hulk: Attorney at Law  August 10, 2022 (2022-08-10) 22 22 "King T'Challa" Black Panther: Wakanda Forever  November 4, 2022 (2022-11-04) 23 23 "Princess Shuri" 24 24 "The Dora Milaje" 25 25 "Mantis" The Guardians of the Galaxy Holiday Special  November 23, 2022 (2022-11-23) 26 26 "Drax"

InfiniteNexus (talk) 17:59, 10 March 2023 (UTC)

Yeah, there definitely seems to be an error with the code. I'm working on it today and I've come close to a fix. I'll also be moving titles to their own separate rows (like every other parameter) instead of using <hr>. -- Alex_21 _TALK 01:02, 11 March 2023 (UTC)

 Fixed -- Alex_21 _TALK 02:03, 11 March 2023 (UTC)

Thanks again! InfiniteNexus (talk) 17:58, 11 March 2023 (UTC)

@Alex 21: There seems to be an issue with the production code table. Can you please fix it? BaldiBasicsFan (talk) 02:31, 11 March 2023 (UTC)

I'm not quite sure how to fix a "seems to be an issue" problem without context. Can you give me an example, please? -- Alex_21 _TALK 02:39, 11 March 2023 (UTC)

Here, as you can see, production code is repeated twice when ever NumParts is implemented:

No. overall	No. in season	Title	Directed by	Written by	Storyboard by	Original air date	Prod. code	U.S. viewers (millions)
1	1	"Anne or Beast?"	Bert Youn	Matt Braly & Jack Ferraiolo	Kyler Spears, Yonatan Tal & Bert Youn	June 17, 2019 (2019-06-17)	103	0.39
		"Best Fronds"	Derek Kirk Kim		Aaron Austin & Hannah Ayoubi

As far as I can tell, that was always the case even before my edits, but I can look into adjusting it. -- Alex_21 _TALK 02:46, 11 March 2023 (UTC)

@BaldiBasicsFan  Done -- Alex_21 _TALK 07:52, 11 March 2023 (UTC)

@Alex 21: One final thought regarding this now. I think there could be a benefit to potentially darkening the grey lines to delineate "part" episodes in the transcluded tables or tables that don't use |Line Color= much like you do with {{Series overview}}. If you look at List of Agents of S.H.I.E.L.D. episodes#Season 5 (2017–18) and Marvel Studios: Legends, you can see how (especially with Legends) it is a bit harder to make out the groupings. - Favre1fan93 (talk) 15:48, 11 March 2023 (UTC)

Hm, I'm not sure how this would work. The darker line in the series overviews is to differentiate the separate series groupings, which is something I could absolutely see working for an example like Legends, but then with AoS it's only a single multipart episode among a table of regular episodes and the darker line would stand out as an oddity among the rest of the regular table if such a darker colour was forced to be used.

What I could do is introduce a new parameter, such as |BottomColor=color, that when optionally used, forces the line color to be shown with or without a summary and even in transclusion. (FWIW,   #A2A9B1 is the table border default, and   #8D939A is what is used as the darker color in overviews.) |BottomColor= would then override |LineColor=, since you can't have two border colours at the same time. Thoughts? -- Alex_21 _TALK 23:12, 11 March 2023 (UTC)

@Alex 21: Sorry for the delayed response back. I wasn't thinking for a "one" off thing, but rather globally for all pages using this template. So a darker color as default all around for each episode separation, with the current lighter color used for the fewer instances using parts. I don't think it's worth adding another parameter to keep track of. - Favre1fan93 (talk)

References

Notes

References in ShortSummary get transcluded even when the text isn't displayed

@Alex 21, Alexiaa, AussieLegend, Frietjes, GKFX, Gonnym, Izkala, Izno, Jackmcbarn, John of Reading, Johnuniq, Jonesey95, Lemondoge, Markun, Mr. Stradivarius, MSGJ, Plastikspork, Pppery, Primefac, PrimeHunter, and Xaosflux: please see Wikipedia talk:WikiProject Television#Refnotes in transcluded episode summaries. The issue mentioned there describes {{efn}}, but it also happens for <ref>...</ref>. It appears to be Template talk:Episode list/Archive 6#Bug with references in the ShortSummary, I don't know if it was not completely fixed at the time, or whether it was fixed and has since regressed. I hardly know any Lua, but quite a few people who presumably do know Lua have edited either Module:Episode list, Module:Episode list/sandbox or both since then. --Redrose64 🌹 (talk) 14:00, 25 June 2023 (UTC)

The problem here, if I'm reading this correctly, is that references are added as soon as Lua accesses the |ShortSummary= argument, regardless of whether the short summary is included in the final output or not. When Lua accesses |ShortSummary=, MediaWiki expands the wikitext in it, including any references contained, and hands the expanded wikitext to Lua. In doing so MediaWiki adds any references to the reference list, and leaves a strip marker to denote where to add the superscript ^[1] link. If the Lua module chooses not to output the strip marker then the superscript link will not be displayed, but as the reference itself has already been added to the reference list, the reference will still be displayed regardless.

The section to blame is this one:

	-- Do not show the summary if this is being transcluded on the initial list page
	-- Do include it on all other lists
	if (onInitialPage and args.ShortSummary) then
		local bottomWrapper = createShortSummaryRow(args, lineColor)
		return tostring(root) .. tostring(bottomWrapper) .. trackingCategories
	else
		return tostring(root) .. trackingCategories
	end

By testing if args.ShortSummary exists before deciding whether to output the summary, you expand the argument's wikitext, and add the reference to the reference list. You could remove the phantom reference problem by changing the if statement to if (onInitialPage) then; however, this would mean adding an empty table row if the |ShortSummary= argument does not have any content in. Or you could add a separate parameter to decide whether to use the short summary, maybe |ShowShortSummary=no, but this would clutter the parameter list. I'm not sure there's a great solution here. — Mr. Stradivarius ^{♪ talk ♪} 14:48, 25 June 2023 (UTC)

Testing if onInitialPage before testing args.ShortSummary seems like the best solution. I know in Module:Sports table they were very careful to make sure that they only touched the args being used in the table to avoid showing phantom references when only part of the table was displayed. Thanks! Plastikspork _―Œ^(talk) 15:28, 25 June 2023 (UTC)

Some edits at Module:Episode list on 20 June 2023 (diff) by Gonnym added function addRowDividerTrackingCategory. That function evaluates every argument twice. Experiment shows that disabling the addition removes the current problems so I have done that (diff). Asking at WT:WikiProject Television#Refnotes in transcluded episode summaries produced List of Agents of S.H.I.E.L.D. episodes as an example where the problem was visible. The problems appear to have gone. Before my edit, that article showed "Cite error: The named reference LunaBlaze was invoked but never defined (see the help page)." at ref 80 and the reported "Cite error: There are <ref group=lower-alpha> tags or {{efn}} templates on this page, but the references will not show without a {{reflist|group=lower-alpha}} template or {{notelist}} template (see the help page)." at the bottom of the page. Johnuniq (talk) 07:57, 26 June 2023 (UTC)

Thanks for finding the issue Johnuniq. I'll modify the code to exclude checking that parameter. Gonnym (talk) 15:25, 26 June 2023 (UTC)

No! Don't evaluate all the args unless you first understand all the intricate details of how the module works, and how it is used and what can go wrong. What problem are you trying to solve and who says it is important? Johnuniq (talk) 00:46, 27 June 2023 (UTC)

@Johnuniq: The purpose was to populate this maintenance category displaying articles using the module where <hr> (or a derivative such as <hr />, <hr/>, {{hr}}) was used. As noted in the discussion above, this presents accessibility issues and should be resolved by using |NumParts=. I had been using the tracking category loaded into AWB to address these. Would you be willing to take a look at addRowDividerTrackingCategory and debug/reinstate in order to continue? (If the evaluation of args.ShortSummary for |ShortSummary= was the issue, this param does not need to be checked as there is no split of the field when |NumParts= is used). ButlerBlog (talk) 15:29, 6 July 2023 (UTC)

Someone who understands all the details of the module is needed. I only visited here because I was pinged. Can you give an example of where a problem existed? Perhaps a couple that you have already corrected. It might be possible to search the wikitext for the problem. At any rate, seeing some examples would clarify what is needed. Johnuniq (talk) 04:59, 7 July 2023 (UTC)

No problem - I understand - and thanks for your willingness to look at it. Essentially, what we're looking for is when an <hr> (or derivative like <hr/>, <hr />, or {{hr}}) is used instead of using |NumParts= to separate multiple values into rows. For example, in this one [1] there were a couple of 2 part episodes where the season and overall series values were on a single line, but split by an hr tag. This should have used NumParts and a _1/_2 value for the episodes. Similar examples, but with other fields are [2] & [3]. As noted in the discussion above this one, using the hr instead of the multipart approach results in an accessibility issue and we want to use a maintenance category to identify these so they can be cleaned up and monitored going forward. As you probably know, the Television project uses maintenance categories to track the use of various templates the project articles use in order to fix these problems, so what @Gonnym had placed in there was to identify when this formatting exists so it can be monitored for fixing by project members. I actually trust Gonnymn's knowledge of the module as they've worked extensively on the various maintenance categories in the TV project for this module as well as others (Template:Infobox television and others). Hope that gives some clarification. TIA for any input you may have. ButlerBlog (talk) 15:50, 7 July 2023 (UTC)

It's not a solution but a Wikipedia search can find problems. Example: hastemplate:"Episode list" insource:/EpisodeNumber[ -~]*\<hr/. The problem with the proposed code (which I removed) is that it evaluates every parameter regardless of whether the parameter ends up being used. If a parameter includes a ref, evaluating it will generate a reference error. I'll try to examine the code and see where it uses specific parameters—they could be checked. Johnuniq (talk) 08:53, 9 July 2023 (UTC)

Thanks - I actually didn't know about the search values. I can use something like that in AWB, so that helps as a workaround for now. ButlerBlog (talk) 12:35, 9 July 2023 (UTC)

Is this template working correctly?

It seems like it doesn't emit footnotes given in the Rtitle paramteter. One example is Atomic Puppet, which tries to use a reference named "auto" on the "Brawl for all!" episode. That reference isn't emitted, subsequent inovcations for fotnotes aren't emitted, and later an error is emitted because "auto" isn't defined. @MSGJ:, @The Mol Man:, I don't see any code in the new LUA implementation that handles rtitle, and there are no /testcases. Should this conversion be reverted until it can be made to work correctly? -- Mikeblas (talk) 19:22, 13 July 2023 (UTC)

The documentation isn't quite complete. Turns out Rtitle will not adda footnote to Title_1 and that RTitle_1 is necessary. -- Mikeblas (talk) 19:30, 13 July 2023 (UTC)

That is correct; the appropriately numbered parameters need to match. -- Alex_21 _TALK 20:58, 13 July 2023 (UTC)

Mobile users and long descriptions

I have made a change to the sandbox to let mobile users read the description without having to scroll sideways if there's too many columns in the header to fit horizontally on one thin mobile screen. Specifically, wrapping the description text in a div and setting the max-width of that div to 90vw (90% of the viewport (window) size). View Template:Episode list/testcases on mobile to see what i'm talking about, or even resize the window to be thin on a computer.

With the Vector 2010 skin on computer, because it goes on total window size, it is "off" by the amount of the left sidebar, not relevant with mobile or Vector 2022 because there's no sidebar, but IMO its less of an issue with a resizable browser window than a fixed width mobile device.

Its very clear on the pokemon episode 1 row (live you have to scroll right to read the whole description, sandbox you don't). The good part of it is you can scroll right if you want to see more of the information in the header, so the template doesn't have to be remade for mobile (i.e. you could also make it so the columns go vertically on mobile but that's kind of unwieldy).

It seems to work with testcases, can someone look it over and see if its good? I'm not 100% sure if 90vw is the right size, it might need tweaking and further testing. I really don't want to have to scroll right to read episode descriptions anymore lol. MarkiPoli (talk) 12:15, 2 October 2023 (UTC)

Template protected edit request on 12 November 2023

Greetings and felicitations. The "TranslitTitle" fields are outputting the label "Transcription" rather than the accurate "Transliteration", as seen in Kyō Kara Ore Wa!! § "Episodes" Would you please be so kind as to change this? —DocWatson42 (talk) 04:12, 13 November 2023 (UTC)

Presentation of foreign script titles

The module underlying this template says

	Line 1: <Title><RTitle> (with no space between)
    
	Line 2: <AltTitle><RAltTitle> (with no space between) OR
    
	Line 2: Transcription: <TranslitTitle> (<Language>: <NativeTitle>)<RAltTitle> (with space between first two parameters)

But normal presentation expected would be

1) Transliteration, not transcription (transcription is copying down)

2) Normal expectation would be [script language] [transliteration] [English translation], the latter needed separately when translation of original episode name is different to the English language name used in dubs/subs etc.

Further the output outputs a linked language name, contributing to overlinking in the article. GraemeLeggett (talk) 21:17, 16 January 2024 (UTC)

Edit request 16 January 2024

Description of suggested change: Change from outputting "transcription" under native title to "transliteration" Diff:

−

"transcription"

+

"transliteration"

GraemeLeggett (talk) 21:06, 16 January 2024 (UTC)

 Done -- Alex_21 _TALK 23:48, 16 January 2024 (UTC)

Edit request 17 January 2024

Description of suggested change:

Per Wikipedia:Manual_of_Style/Japan-related_articles#General_guidelines, referrring to Wikipedia:Manual_of_Style#Foreign_terms transliterated text should be italicised, currently it is not. The display code needs to be changed to italicise the output from the | TranslitTitle = parameter

Diff: So when applied to first episode listed at Full_Dive#Anime

"VR⨯Reality"
Transliteration: "Bui Āru×Riaru" (Japanese: ＶＲ×リアル)

Should render as

"VR⨯Reality"
Transliteration: "Bui Āru×Riaru" (Japanese: ＶＲ×リアル)}}

GraemeLeggett (talk) 19:38, 17 January 2024 (UTC)

Episode titles are not in italics though. So we have two conflicting guidelines. Gonnym (talk) 20:20, 17 January 2024 (UTC)

I believe that this should take predence, as WP:MOS/TV is a sub MoS of the primary WP:MOS. Implementing this would mean that the episode title itself is still within quotes; I see no issue with this. -- Alex_21 _TALK 23:46, 17 January 2024 (UTC)

I have modified the example above to retain the needed quotation marks around the episode title. It looks like changing line 381 of Module:Episode list may effect this change. – Jonesey95 (talk) 14:21, 18 January 2024 (UTC)

This should be an easy change to make technically. @GraemeLeggett and Gonnym: do either of you object to the current proposal? (transliterated title is italicized but remains in quotes) Elli (talk | contribs) 17:05, 18 January 2024 (UTC)

Now I think on it, the actual format should probably be closer to

"ＶＲ×リアル" (Bui Āru×Riaru, [translation of Japanese title if different])

mentioning transliteration at all is unneeded, and that the language is Japanese is also known from context of article. GraemeLeggett (talk) 20:13, 18 January 2024 (UTC)

FYI, the template you are using in your example is incorrect here as it places English language text in a Japanese language tag. Regarding your comment though, I might be ok with removing the "Japanese:", but "Transliteration" seems important here as then you just have a piece of text that isn't explained. Is this an alt name? Is this the native name? Gonnym (talk) 11:55, 21 January 2024 (UTC)

Elli, No objection. Gonnym (talk) 11:48, 21 January 2024 (UTC)

Deactivating edit request as weeks in there still seems to be no agreement on any specific change to be made. Please come to an agreement, code it in the sandbox, and, if you still need an uninvolved template editor to implement, reactivate the request. * Pppery * _{it has begun...} 02:56, 6 February 2024 (UTC)

Guests and MusicalGuests are not aliases, but they should be

When Guests and MusicalGuests were originally requested here, there was a requirement that they would be aliases of Aux1 and Aux2 and would not be able to be used at the same time, which is indicated by a comment in the code: Module:Episode_list#L-57. But in fact they freely coexist separately as independent parameters (also being undocumented):

aux1	aux2	aux3	Guest(s)	Musical/entertainment guest(s)
Aux1	Aux2	Aux3

I still think it should be the way it was originally intended to be. That it is, they should be aliases for Aux1 Aux2, created simply to force predefined headings. Solidest (talk) 12:43, 7 February 2024 (UTC)

I've  Done this since it is what the consensus was to do, but for the record I dislike templates imposing this kind of arbitrary restriction on their users - just don't do that. * Pppery * _{it has begun...} 23:33, 7 February 2024 (UTC)