Talk:List of Vikings episodes

Documentary tie-in
There was also some kind of documentary tie-in program[me], the title of which I don't recall. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:59, 27 April 2015 (UTC)
 * Provide a source that supports your statement and gives information that expands upon the knowledge and content of this article. Alex &#124; The &#124; Whovian  01:22, 28 April 2015 (UTC)

Viewers
Why have we been adding US viewers to a series that's Canadian-Irish? Only viewers from the originating country should be added. Alex &#124; The &#124; Whovian 15:03, 3 July 2015 (UTC)

Webisodes running time
I don't see how it doesn't benefit the table by having them here. Following the standard in The Walking Dead's web series. —  Art manha  (talk) 00:24, 24 February 2016 (UTC)
 * What further understanding is given to the webisodes that include the run time, where as regular episodes do not? Alex&#124;The&#124;Whovian ? 00:27, 24 February 2016 (UTC)
 * Exactly to differ from regular episodes running time, which are greatly longer. Regular episodes have the running time on the show's main article and the webisodes do not. Not putting the running time can give the impression that there is no difference from them. —  Art manha  (talk) 00:31, 24 February 2016 (UTC)
 * Then create a leading paragraph for the table, stating "The webisodes had a running time of X.XX minutes to Y.YY minutes". Alex&#124;The&#124;Whovian ? 00:32, 24 February 2016 (UTC)
 * Okay. —  Art manha  (talk) 00:37, 24 February 2016 (UTC)
 * If we're going to do that then we may as well get rid of the director and writer columns and just write "The webisodes were written by Sam Meikle and directed by Lucas Taylor." There is no need to repeat each name 12 times. There is more reason to include runtimes that to do that. -- Aussie Legend  ( ✉ ) 00:44, 24 February 2016 (UTC)
 * Then if we're going to do that for the webisodes, why not for the main episodes? Every episode is written by Michael Hirst. Alex&#124;The&#124;Whovian ? 00:48, 24 February 2016 (UTC)
 * There is absolutely no reason why we couldn't do that. We should only include fields where the content in each episode varies. There's also no need to evenly space columns either. Columns should be as wide as they need be, and no more. Unnecessary padding just makes the tables look ugly. It's much more professional to have one large field and several sized appropriately than to pad several unnecessarily. The only reason the table is as wide as it is made is to fit the episode summaries. -- Aussie Legend  ( ✉ ) 00:53, 24 February 2016 (UTC)
 * I partially agree with both of you. My opinion is that we should add the running time to the webisodes and let the columns for the main episodes evenly spaced— I think having one large and the other ones sized appropriately would be rather weirder since without set widths, they would be as even as they can get. Not necessarily letting the webisodes columns matching the episodes. But that's just my opinion. Thanks —  Art manha  (talk) 01:33, 24 February 2016 (UTC)
 * "since without set widths, they would be as even as they can get" - That's not actually the case. If we don't set widths, then the column widths for each season can be different, and you can have some columns much narrower than they should be, especially at lower resolutions. See, for example, List of Arthur episodes. Column widths vary from season to season and, at 1280px, season 2, episode 1 wraps "Eric Bergeron and Gerry Capelle" onto two lines. Setting widths ensures consistency throughout the page and allows you to optimise column widths so that wrapping doesn't happen. This is necessary if you ever hope to get a page to even GA status. -- Aussie Legend  ( ✉ ) 01:52, 24 February 2016 (UTC)
 * I agree table widths are absolutely necessary. My point is, when they aren't needed (for instance, shows with only one season and that, even in low resolution, display all the information without breaking it in two lines) the columns would be as even as possible. So, I don't see the point of having a large one and the others sized appropriately. —  Art manha  (talk) 01:58, 24 February 2016 (UTC)
 * I'm not sure I understand you. We're not talking about a series with one season. By having one large field and the others sized appropriately, I mean something like this:


 * The  field is the only one that is too wide, which is preferable to having multiple columns far too wide. All of the others are more conventional in width. Ideally, the table shouldn't be that wide but we need to fit in the episode summaries. Of course, that's not necessary on this page, and it is possible to change the transcluded width so that all fields line up and are only as wide as necessary. See List of Hell's Kitchen episodes, where all of the season articles use 100% wide columns, while the trancluded tables are sized so that the fields all line up, which was necessary because of the different content in each season. That would enable the inclusion of the webisode runtimes, which is not possible with the current method. It would allay Alex's concerns that the runtimes "push the columns out of alignment with the others", and we could even make the   field only as wide as it need be. -- Aussie Legend  ( ✉ ) 02:24, 24 February 2016 (UTC)
 * Since nobody seems to disagree with the above I've formatted the columns so that in the season articles the tables are 100% wide so the episode summaries fit. Here though, there's no need for that so I've reduced the size of the  field, and consequently the width of the table (tables should only be as wide as the need to be). It is still wide enough for any existing episode titles, and I've left some extra in case a longer title comes up. I've also reinstated the runtimes but with the code adjustments, these don't push any columns out of alignment as they did before. -- Aussie Legend  ( ✉ ) 16:56, 25 February 2016 (UTC)

I am 100% against these recent changes. I have never seen a script series that has an episode table that isn't 100% wide. Is there any Wikipedia policy or guideline that states "tables should only be as wide as they need to be"? What "makes the table look ugly" is having them like this. What I meant above was that by having a table that doesn't require widths, it would evenly divide along themselves, like this:

So having one wide column and the others only as wide as they need is incompatible to what Wikipedia automatically does when there aren't set widths. Thanks —  Art manha  (talk) 17:34, 25 February 2016 (UTC)
 * The actual code that creates tables, by default, makes cells only as wide as they need be. We actually have to force tables to be wider than that, so forcing the width to 100% is actually "incompatible to what Wikipedia automatically does when there aren't set widths". It's the design of episode table that forces a 100% width. If you just use the standard wiki-coding without forcing the width, this is what you get:


 * This is standard practice with tables virtually everyhwere, not just on Wikipedia. See, for example, the w3schools guidance on table widths, which says Normally, a cell takes up the space it needs to display the content. Tables contain data and whitespace just makes tables a lot bigger than they need to be. It's generally considered to be bad practice to force whitespace into a table, and has been for at least the past 36 years that I've been working with spreadsheets (which are just tables). There is actually no consensus that tables have to be 100% wide, and in many articles they are not. We just tend to do it in episode lists because there is so much data that it fills the width anyway. We did at one stage reduce the size to 99% because it was causing issues on mobile devices. I don't understand you being "100%" against the changes. You are the one who wanted the runtimes in the first place. One of the concerns about them had by Alex was that the extra column forced others to the left and forced the tables to be out of alignment. The current code fixes that. Without that, you can't have the runtimes. The table example that you've used is one of those "bad practice" tables that I spoke of. There is far too much whitespace. Readers shouldn't have to scroll across the page to find information. You can't seriously argue that a table with fields that are 15-20 times wider than the data in the fields aren't ugly? It's far better to have one over-size field than 6 over-size fields. You'll note that, at List of Teen Wolf episodes the title field is set to 67% to enable column alignment. That's wider then the field was set to in the season articles for this series. -- Aussie Legend  ( ✉ ) 18:22, 25 February 2016 (UTC)
 * We had reached a consensus before regarding the runtimes (where it would be cited in text form rather than inside the table). And that is exactly my point, there's a consensus to use episode table with 100% width, so I don't see the point of not doing so here, specially once WikiProject Television explicitly states: This is to guide the structure and normalize the standard of articles dealing with the Television medium and television series or other forms of episodic programs. —  Art manha  (talk) 20:47, 25 February 2016 (UTC)
 * Plus, the Teen Wolf specials table is only that wide because of the lack of writers and directors there. —  Art manha  (talk) 20:50, 25 February 2016 (UTC)
 * We hadn't reached a consensus, it was just a suggestion based on Alex's preference, and after that you came back and still argued My opinion is that we should add the running time to the webisodes. There is actually no wide consensus to use episode table at all. Again, it's just something we do because it's a good template. There is certainly no consensus to stick with 100% and certainly not at this article. In fact it's not possible to use 100% at many articles, which is why total_width exists. The subject is clearly still under discussion and I only added the new code after neither you nor Alex opposed my suggestion (I waited over a day while you both made multiple edits at multiple articles). The quote you've included is not a mandated principle. Note that it only says "to guide". We have to use common sense and apply the guidelines of MOS:TV (the the project page) on a case by case basis. This is how we have done it for the 9 years that I've been editing TV articles. As for the Teen Wolf specials, the point is that you're forcing a wide column rather than letting the columns "even themselves out". That's exactly what my code did, so to argue against it is not logical. Note that I've suggested we don't bother including writes and directors for the webisodes at all, and Alex has suggested we can eliminate the writers column in the season articles for the same reason. That will result in in some very wide columns. -- Aussie Legend  ( ✉ ) 04:06, 26 February 2016 (UTC)
 * Then I took it back once again, agreeing about not including the runtime for the reasons you and Alex pointed (about the columns widths). You claim that There is actually no wide consensus to use episode table at all. but yet I've never seen an episode table for a script series such as Vikings with a table with other than 100%, 99% or even 101%, and these adjustments are always to better fit the information, when it is too long. Mostly other tables (not episodes one) use tables with other width (e.g.: ratings tables). And my quotation is as you stated, to guide. But I see no reason other than your will to not follow this guide. Yes, we have been applying the MOS:TV on a case by case basis, yet none of our fellow editors (even more experienced than you, which is a hard thing to find here) have ever wanted to do it on episode lists articles for scripted series. As for the Teen Wolf table, it wasn't me who did it like that, and it is that wide because and only because there aren't columns for writers and directors, and the editor who did it like that wanted to adjust the airdate with the series' ones. I don't think we should eliminate any of those columns on Vikings. As for having one wide column and the other ones adjusted, I'm not against if it isn't too adjusted, leaving a little more space to the other columns as well. Also we could try to add other parameters such as prodcode or viewers. Thank you —  Art manha  (talk) 12:40, 26 February 2016 (UTC)
 * "Then I took it back once again" - Actually no, you made the comment after you'd changed the table, and you've said nothing since then about it.
 * "I've never seen an episode table for a script series such as Vikings with a table with other than 100%, 99% or even 101%" - With all due respect, you've only edited 344 pages. Most editors don't really know much about tables, and don't realise that you can change widths when transcluding. You might note that the code that I used set the width in the season articles to 100%, because the table needs to be that wide for the episode summaries. At this page, there are no episode summaries, and it was only here that the table was narrower, in accordance with standard practice for tables, as the tables don't have enough data to justify 100%. It doesn't matter whether the series is a "script series", or some other type of program, when we transclude we don't normally include summaries. You might also note that the templates created by Alex are not used in every article. That's because they're relatively new and haven't been added. We're changing all the time. There are a lot of things that we do now that we didn't do 2 years ago, either because we couldn't, or didn't know how. That doesn't mean we should stick to the old, often non-compliant ways.
 * "none of our fellow editors (even more experienced than you, which is a hard thing to find here) have ever wanted to do it on episode lists articles for scripted series." - That's a bold claim to make, and it's not supportable. There are plenty of things that we've wanted to do, but we're only just able to now, so we're changing with the times. In this case it's using standard practices that we didn't previously know how to.
 * "As for having one wide column and the other ones adjusted, I'm not against if it isn't too adjusted" - The code that I used was entirely variable. You can make the columns as wide or as narrow as you need, but you didn't ask if that was possible.
 * " leaving a little more space to the other columns as well" - Why do you need the extra space? What does             all              that              whitespace              between              words              do              ? -- Aussie Legend  ( ✉ ) 15:41, 26 February 2016 (UTC)
 * Please, don't mistake the number of pages I've edit with my knowledge about Wikipedia. Even though I have nothing but respect for you, as usual, you won't take anyone's opinions but yours, so there's no point to feud. We should only wait for Alex to give us his input, since he is a part of this discussion as well. But be aware that other pages such as List of House of Cards episodes would also "require" these changes.
 * P.S.: please consider that I'm still not in favor of these changes, but rather want this discussion to come to an end, so for this reason, we reached a consensus. Thank you —  Art manha  (talk) 18:16, 26 February 2016 (UTC)
 * That's entirely unfair. I'm more than willing to listen to the opinions of others, but you've made some obviously incorrect statements, like the standard width of tables, which indicates you are making decisions based on incorrect assumptions about what is, or isn't, the correct way to do things. No articles "require" these changes but, when the changes are made, they shouldn't be reverted just because you think they are wrong. You need something more than "I don't like it". I don't see a great problem with List of House of Cards episodes. The widths could do with some trimming, but it's not essential. Here though, the cells are far too wide, based on standard practice, which I've already explained above. Note that you can't arbitrarily declare consensus. It's an issue that is still under discussion. -- Aussie Legend  ( ✉ ) 04:43, 27 February 2016 (UTC)

Since we're talking about them, it should be noted that the column widths were arbitrarily altered when Alex removed the viewer figures. The values for the old and new widths are shown in the following table: The title and the airdate were both made wider. I can see value in increasing the width of the title column, but there is no value in increasing the width of the airdate column, and I'm still waiting for some justification why all the columns need to be so wide. -- Aussie Legend  ( ✉ ) 09:30, 27 February 2016 (UTC)
 * Finally getting around to coming back to this. (The reason I wasn't able to reply to this when you implemented the edits was because of a 24-hour "enforced vacation". My bad.) While reverting straight away may not have been the best option, I too disagree with the new layout. First and foremost, the argument is the white-space and padding not being necessary. However, there's still white-space after the tables are resized that isn't used for anything constructive anyways, so I'm not entirely sure what actual benefit any of this would produce? That's the real question here. "Don't fix what isn't broken." I've always followed the standard that's run fine on all the television series' pages that I've worked on in my 18 months here, and this is the first deviation from this. Besides, all of this hassle would return if even one new writer was introduced, or Canadian view figures became available. While the some of the columns may not need to be as wide as they currently are, there should be a certain amount of space to allow for screens with lower resolution so that the directors, writers, etc. don't wrap. Also, the webisodes table still doesn't need the lengths column given that it can be described in prose. Alex&#124;The&#124;Whovian ? 13:58, 27 February 2016 (UTC)
 * Whitespace is unavoidable in most episode lists. The aim is to minimise it. When creating any table, the aim is to group the data, like in the table above, so that readers don't have to read text, jump across the page, read the next text, jump across the page, read the next text and so on, as you'd have to do in this table:


 * In a table like the one below, you read the data, read the next data, read the next data, jump across the page, read the next data, read the next data, read the next data:


 * There is only one jump, not the three that we have in the existing version of the page. The following format would be ideal, as there are no jumps, but it's not possible in Episode list, so we have to work with what we have. Note that there is some whitespace you can't eliminate. Columns can only be as narrow as the column headers allow.


 * "I've always followed the standard that's run fine on all the television series' pages that I've worked on in my 18 months here, and this is the first deviation from this" - There is no deviation. We're always battling to find room for writers and directors and this requires us to minimise the space used by other columns so as to stop the episode header rows wrapping. To suddenly make columns much wider than they need be is the deviation.
 * "there should be a certain amount of space to allow for screens with lower resolution so that the directors, writers, etc. don't wrap." - I did check that, and the whitespace that I left was sufficient to prevent wrapping at lower resolutions. The arguments I'm seeing here really seem to be "Let's not bother about whitespace at all", but we've done that before, replacing "Production" in the  field header with "Prod." because "Production" was far wider than most production codes. We've also done it in the episode number fields, relacing "Number" with No.. Why here do we seem to want ugly whitespace? I have a table here printed on B0 paper. If it was formatted the way these tables are, it'd probably span the Pacific Ocean. As for the runtimes, they're all different so it's actually a lot harder to describe them adequately in the prose than the writer and director, which we seem happy to have in the table. We need some consistency here. If we're not going to include the runtimes, we should get rid of the writer and director as well. They can be replaced by "All webisodes were written by Sam Meikle and directed by Lucas Taylor." -- Aussie Legend  ( ✉ ) 17:29, 27 February 2016 (UTC)
 * You're saying that the deviation is how the layout currently is? I respectfully disagree - I have never seen a case of the table widths changing between the season page and the list of episodes page. You speak of battling to find room for directors and writers and having to shrink other columns to do so, but that's not the issue here - there's already plenty of space. Nor did we shrink/abbreviate the production codes and episodes numbers for concerns about whitespace, but to provide more room for the other credits. Onto the webisodes table, the columns for the director and writer in the webisodes table is to match the layout in the main episodes tables. While we could do what we mentioned before and remove the writers completely (and directors from the webisodes), if even one episode is then written by another writer, then we need to reinstate the entire current layout again. Same with viewer figures. We'll be having this discussion all over again. Also, I wouldn't disagree with the episode table layout you've provided, since it is available to do Episode table and Episode list, using Aux4, per the example below. Alex&#124;The&#124;Whovian ? 04:39, 1 March 2016 (UTC)


 * Just because you haven't seen them, doesn't mean they are not there, and I've already given an example above. However, if we ignore the natural tendency and convention to make tables only take up as much space as is necessary, deliberately expanding columns so they are scattered across the page is certainly not conventional. The only time we see that sort of thing is when people force 100% width and then don't bother with individual column widths at all, which used to be the standard until WP:FL raised its ugly head at List of Friends episodes back in 2012, and we made significant changes to Episode list as a result.
 * "Nor did we shrink/abbreviate the production codes and episodes numbers for concerns about whitespace, but to provide more room for the other credits." - And how do we do that? By reducing the space used by columns that don't need to be a s wide as they are. i.e. reducing column widths. We always reduce, we never expand unnecessarily.
 * I did try to use Aux4, but it wouldn't work. That was a week ago so I've forgotten why but since you're agreeable to your version, we can try that. -- Aussie Legend  ( ✉ ) 08:48, 4 March 2016 (UTC)

Arbitrary section break

 * I'm in favor of these changes. But I think it would be wiser to fill the aux4 space with information such as featurecharacters, prodcode, viewers (Canadian or Irish), etc. if available —  Art manha  (talk) 12:34, 4 March 2016 (UTC)
 * featurecharacters isn't a valid paramater, but there really does need to be a column for Canadian viewers. Alex&#124;The&#124;Whovian ? 12:44, 4 March 2016 (UTC)
 * I don't see a need for prod codes, as they serve no real purpose here, but even if we do add Canadian viewers, we'll still end up with 28 empty cells that seem to serve no purpose. -- Aussie Legend  ( ✉ ) 12:57, 4 March 2016 (UTC)
 * Production codes are EXTREMELY useful and they do serve their due purpose. And I'm sorry Alex, you are correct. The parameter doesn't exist. The Episode tables which use this information use parameters such as aux2 or aux4 combined with aux4T Feature character(s) (e.g.: List of Orange Is the New Black episodes and List of Lost episodes). Remembering that I've made only a suggestion of those parameters, in case they are available —  Art manha  (talk) 16:01, 4 March 2016 (UTC)
 * Production codes are important in some circumstances but in most cases they add absolutely nothing to a reader's understanding of a TV program. They certainly don't seem important at all here. -- Aussie Legend  ( ✉ ) 16:35, 4 March 2016 (UTC)
 * So we should not add them to the table simply because you don't consider them important? —  Art manha  (talk) 16:43, 4 March 2016 (UTC)
 * We don't add everything just because we can. How do you believe production codes are important here? -- Aussie Legend  ( ✉ ) 17:15, 4 March 2016 (UTC)
 * Their purpose is widely known. Now the reason not to include them is what I fail to realize. Wikipedia does not contain only necessary information and certainly not only what you see fit, when you see fit —  Art manha  (talk) 19:34, 4 March 2016 (UTC)
 * "Their purpose is widely known" - That doesn't answer the question. Assume I don't know what the purpose is and please explain how they are important here.
 * "Wikipedia does not contain only necessary information" - Well actually it does. We don't add something just because we can. It has to be relevant and encyclopaedic. -- Aussie Legend  ( ✉ ) 06:28, 5 March 2016 (UTC)
 * "Assume I don't know what the purpose is and please explain how they are important here" - I don't need to pretend you don't know something to prove the point. And again, your argument is invalid, if we were to follow you and don't add production codes because "They certainly don't seem important at all here", we wouldn't need to have production codes in essentially every article that displays them. You can further read about their purpose here. You can't use as arguments things like I don't want/like it or it isn't necessary.
 * "We don't add something just because we can. It has to be relevant and encyclopaedic" - How are production codes not relevant? If they weren't, there wouldn't be a parameter (prodcode) for them at all. —  Art manha  (talk) 17:45, 5 March 2016 (UTC)
 * I don't need to pretend you don't know something to prove the point. - The point is that you haven't demonstrated how production codes are important here. I don't think they are and you haven't made any attempt to convince anyone otherwise.
 * If we were to follow you and don't add production codes because "They certainly don't seem important at all here", we wouldn't need to have production codes in essentially every article that displays them. - That's true. They don't usually serve any purpose. When episodes are aired out of sequence and that affects a storyline, they do prove useful, but otherwise...
 * You can further read about their purpose here - I know the purpose of production codes but that doesn't explain why we need to list them here.
 * How are production codes not relevant? - How are they relevant? I can't see how production codes would be helpful here, and you won't explain why you think they are. Your entire argument seems to be "we should include them because"
 * If they weren't, there wouldn't be a parameter - Just because a parameter exists doesn't mean it has to be used. We regularly delete "RTitle" form episode lists and "Aux1-4" are often not used. Do you even realise we have an important parameter called  that is rarely used. -- Aussie Legend  ( ✉ ) 14:13, 6 March 2016 (UTC)
 * So why don't we start removing them from other pages, since they seem to serve no purpose at all?! What I'm trying to tell you is there's no reason not to include them, even if you fail to see their purpose. As we cannot assume all editors' desirability upon Wikipedia's content, we cannot omit important information (such as prodution codes) from Wikipedia, whenever it's available. I for one—for both personal and professional reasons—like to get a hand on these kind of information. Plus, it would help us decrease the excessive whitespace. Thank you —  Art manha  (talk) 14:36, 6 March 2016 (UTC)

Can I also ask, Aussie, why you deleted the references for the upcoming episodes when you implemented the change of format? Alex&#124;The&#124;Whovian ? 13:37, 6 March 2016 (UTC)
 * Did I? I wasn't aware that I had. It looks like I used the same template for season 4 as I had used for seasons 1-3 and it dumped the RTitle fields in episodes 33-36. Thanks for picking that up. -- Aussie Legend  ( ✉ ) 14:13, 6 March 2016 (UTC)

Webisodes: New "Epilogue" Webisode
I do believe that an epilogue episode was released that follows on from the final webisode. You can watch it on youtube. But I can't find any information on it. Supadog —Preceding undated comment added 14:00, 17 January 2017 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on List of Vikings episodes. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://www.webcitation.org/6FhcvQ1Iu?url=http://www.irishfilmboard.ie/irish_film_industry/news/VIKINGS_Tops_The_Ratings_With_83_Million_Viewers/2149 to http://www.irishfilmboard.ie/irish_film_industry/news/VIKINGS_Tops_The_Ratings_With_83_Million_Viewers/2149

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 02:51, 28 December 2017 (UTC)

Ratings
Hi / Alex /21 , I saw that you deleted the US ratings I've added, with the reason that this isn't a US TV show. However, this TV show did premiere on March 3, 2013, in Canada and the United States. So, even if it isn't produced by Americans, I don't think it's a good idea to delete the US ratings. I understand that you don't want to add every rating of each country here, but is there a consensus regarding this issue? If there is could you link to it please? Because with musicians you do try to add how well a single or an album performed in each country.

My second remark would be that this show was filmed in Ireland and premiered in Canada (and the US). So, should the ratings of both Canada and Ireland be included in this case? And do you know which sources provide this information? From what I've seen, the Canadian ratings are only available if you pay for them. And I couldn't find the Irish ratings. That's the second reason why I would want to keep the US ratings. MrUnoDosTres (talk) 23:34, 11 December 2019 (UTC)
 * MOS:TVRECEPTION: Ratings should only be included from the program's country of origin or where it debuts, unless viewership is particularly notable in another territory and can be reliably sourced. Why is it particular notable in the US? It's not. If you have Irish and Canadian ratings, then by all means. But unless they are available, then we don't add them, other countries or not. -- / Alex /21  06:16, 12 December 2019 (UTC)