Talk:S-class destroyer (1917)
This is the talk page for discussing improvements to the S-class destroyer (1917) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Range
[edit]The article (in the info-box) now says: "Range: 250-300 tons of oil". I think this is a bit too cryptical. Isn't it possible to find some estimates instead? Greswik (talk) 22:18, 22 January 2010 (UTC)
Major revision of this article 30 May 2017
[edit]- expanded background and design history sections,
- additional section on operational history
- Ship list now in tabular format (separate lists of Australian and Canadian vessels deleted since listing ships twice was confusing).
- Photographs added
- added references to published sources
Discrepancies in the ship building dates
[edit]- launch date of Senator: 7 April 1918 according to Friedman; 2 April 1918 according to Dittmar & College, Colledge, Conway's, Jane's 1919 and March (we have taken the majority opinion).
- launch date of Scythe: 25 May 1918 according to March, Colledge, Jane's 1919 and Friedman; 25 April 1918 according to Dittmar & Colledge and Conway's (we have taken the majority opinion).
- launch date of Tomahawk: 11 May 1918 according to Friedman, Conway's, March; 16 May according to Dittmar & Colledge, Jane's 1919, Colledge (we have taken the first alternative).
- completion date of Stormcloud: 28 Jan 1919 according to Friedman (which is before the launch date, 30 May 1919); pendant assigned from Jan 1920 (we've assumed a typo of 1919 for 1920).
- launch date of Sturdy: 26 June 1919 according to Friedman, March and Conway's; 25 June 1919 according to Dittmar & Colledge, College, Lenton, (we have taken the first alternative).
- laid down date of Thracian: 17 Jan 1918 according to Friedman and Jane's 1919; 10 Jan 1918 according to Lenton, (we have taken the first alternative).
Discrepancies in the pendant list
[edit]- wartime pendant number of Seraph: G.50 according to Friedman; G.60 according to Dittmar & Colledge (we assume Friedman has made a typographical error, since he has Vampire also assigned G.50, as do Dittmar & College).
- wartime pendant number of Tobago: G.11 according to Friedman; G.61 according to Dittmar & Colledge (we assume Friedman has made a typographical error, since there is a photo of Tobago wearing G61).
- postwar pendant number of Scythe: H.33 according to Friedman (which is also the number he gives for Vanoc); H22 according to http://www.worldnavalships.com/forums/attachment.php?attachmentid=160739&d=1489442208.
- postwar pendant number of Thanet: H.28 according to Friedman and Lenton (both of who also give this number for Sturdy); H29 according to Jane's 1931 and http://www.worldnavalships.com/forums/attachment.php?attachmentid=160739&d=1489442208).
Dfvj (talk) 08:54, 30 May 2017 (UTC)
Reasons for removal of edit on 1 Aug 2017
[edit]- this is not the venue to discuss the internal politics of the Irish Free State
- you removed the link to the wikipedia page on the Irish civil war
- you claimed the Irish civil war ended in 1923, which contradicts the wikipedia page on the subject.
- you ascribed motivation for the attack without any reference to support your claim: original research is not permitted on wikipedia. FYI, according to contemporary press reports the attack seems to have been perpetrated by mutineers of the Irish Free State Army; the Irish Free State government, and Catholic church authorities roundly condemned the attack at the time, and later paid compensation to the victims.
- contemporary British press accounts and Parliamentary records give the name of the port as Queenstown; however it was also known by the Irish name Cobh by this time; we have altered the article to reflect this.
Dfvj (talk) 05:20, 1 August 2017 (UTC)
Reasons for removal of edit on 12 Aug 2018
[edit]Please refer to the Manual of Style: http://en.wiki.x.io/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers#Dates,_months_and_years
In particular Abbreviated dates are acceptable Only where brevity is helpful (refs,[b] tables, infoboxes, etc.). Spelling out the months in full adds extra clutter to the long table of ships, and does not add any useful information. Dfvj (talk) 00:56, 20 August 2018 (UTC)
We obviously differ in if we feel brevity is helpful in this case. I hold that it serves no purpose to deviate from the general rule as there is sufficient space in the table for dates in full, it's helpful for non english speakers who have to translate the page, that because there is considerable text in the fate field the date there should be in full and that every other ship class table has the dates in full so this article should be consistent with the accepted norms used by many other editors. Describing full dates as "clutter" is an interesting opinion and goes against how MoS requires dates to be entered Lyndaship (talk) 09:20, 20 August 2018 (UTC)
Using abbreviated dates just makes the page harder to read. We are writing an encyclopedia, not a text message.Nigel Ish (talk) 17:13, 20 August 2018 (UTC)
Lynda, Nigel -- I have been thinking a lot about what you said: the tabular list of ships is useful for (a) looking up concise details of one particular vessel (though this does NOT really need a tabular format); (b) to search for how many ships were built in a particular year or a particular building yard, or whatever: having a compact tabular format, with one ship per line, and as many ships as possible appearing on the screen thereby minimizing the necessity to scroll, is surely very useful in such circumstances, no? Do you really think a non-native speaker, who can cope with the technical expressions (of which there are many in this article), will be confounded by abbreviating January by "Jan"?Dfvj (talk) 21:33, 22 August 2018 (UTC)
- The abbreviated format doesn't give any advantage. The table is large anyway, so we don't really gain anything by abbreviating it.Nigel Ish (talk) 21:53, 22 August 2018 (UTC)
- Don't dispute the merits of having this information in a table. I'm not sure if this level of detail should be included in an article about the class but given that most of the individual ships do not yet have articles I accept it is the only place for it currently. I've just checked with google translate and to my surprise it happily translates the short form of the month to the full form in all major European languages. However I still feel this table should conform to the usual practice and have the months in full. Lyndaship (talk) 08:08, 23 August 2018 (UTC)
- Lynda, Nigel --have a look at these articles covering similarly numerically large classes of destroyers: http://en.wiki.x.io/wiki/Allen_M._Sumner-class_destroyer; http://en.wiki.x.io/wiki/Gearing-class_destroyer; http://en.wiki.x.io/wiki/Spruance-class_destroyer (there are many more). Points to note: a) they present lists of ships in tabular format just like the article under discussion here, and with comparable level detail; thus your comment ″I'm not sure if this level of detail should be included in an article about the class″ is rather at odds with a number of existing precedents, and you want to start pruning details you consider inappropriate you might encounter quite a bit of push-back from other editors. b) they all present dates without abbreviations for months; and yet all of these tables need a very wide screen in order to be presented with one entry per line (too large a screen for most laptops or handhelds); thus users of such devices are presented with a lot of extraneous space with no information; if abbreviated dates were used, the table would be a lot more compact (as is the table in this article). I reiterate: abbreviated dates ARE permitted by the MOS in these circumstances, and (as Lynda has pointed out) do NOT present any particular difficulties for foreign language users capable of using Google translate. Use of full months rather than abbreviations conveys no extra information, and causes tabular data to appear in a much less accessible and useable formDfvj (talk) 02:57, 29 August 2018 (UTC)
- I think your examples just go to prove my point. That despite the concern about reading the articles on hand held devices every other editor has chosen to put the months in full rather than to use the exemption permitted in the MoS. So while you're not wrong in shortening months you are the only editor in step with yourself, I think if you changed some of these articles to shortened months in tables you would experience more than a little "push-back" too Lyndaship (talk) 08:32, 29 August 2018 (UTC)
- I've posted notification of this discussion to WP:SHIPS asking for other editors views Lyndaship (talk) 08:50, 29 August 2018 (UTC)
- FWIW, I always use full months in tables I use, like this one. Shortening a word by 3 or 5 characters isn't going to make or break the table. Parsecboy (talk) 13:09, 29 August 2018 (UTC)
- I don't think that the Bismarck table is at all comparable as it is just 5 columns of data and doesn't require a column for narrative (it only covers six ships, with histories below); it has stayed an easy read because it has not produced any word-wrap - everything on single lines. That is impossible to achieve on the S-Class tables without the tables becoming too wide (6 extra characters for each of three date columns and about a dozen for the 'fate' column with text as it stands - some 30 characters in all). Look at this version and compare the tables for Admiralty S and Thornycroft/Yarrow S; the former looks a mess, with the vast majority of ships requiring two lines - on my PC screen I can see the first 21 ships, but 33 in the current version, so much less scrolling. It is not that full months are clutter per se, but in this table they certainly produce it. It is big, wide tables like this one that well illustrate the wisdom of the "Only where brevity is helpful" flexibility. The poorly designed tables in other articles should not prevent improvements - a good case of WP:IAPD, or WP:IAR if you prefer policy. Davidships (talk) 22:48, 29 August 2018 (UTC)
- I wasn't comparing the two, just giving an example of a table format I use pretty routinely to illustrate that I prefer to spell out the months fully. I've looked at the tables here on two different desktops (and neither wrapped the text - in fact, significant white space was present on the right side) and my phone (but in those cases where wrapping occurred, it was because of the fate column (and abbreviating the months does not fix the problem). Parsecboy (talk) 00:34, 30 August 2018 (UTC)
- I don't think that the Bismarck table is at all comparable as it is just 5 columns of data and doesn't require a column for narrative (it only covers six ships, with histories below); it has stayed an easy read because it has not produced any word-wrap - everything on single lines. That is impossible to achieve on the S-Class tables without the tables becoming too wide (6 extra characters for each of three date columns and about a dozen for the 'fate' column with text as it stands - some 30 characters in all). Look at this version and compare the tables for Admiralty S and Thornycroft/Yarrow S; the former looks a mess, with the vast majority of ships requiring two lines - on my PC screen I can see the first 21 ships, but 33 in the current version, so much less scrolling. It is not that full months are clutter per se, but in this table they certainly produce it. It is big, wide tables like this one that well illustrate the wisdom of the "Only where brevity is helpful" flexibility. The poorly designed tables in other articles should not prevent improvements - a good case of WP:IAPD, or WP:IAR if you prefer policy. Davidships (talk) 22:48, 29 August 2018 (UTC)
- FWIW, I always use full months in tables I use, like this one. Shortening a word by 3 or 5 characters isn't going to make or break the table. Parsecboy (talk) 13:09, 29 August 2018 (UTC)
- Lynda, Nigel --have a look at these articles covering similarly numerically large classes of destroyers: http://en.wiki.x.io/wiki/Allen_M._Sumner-class_destroyer; http://en.wiki.x.io/wiki/Gearing-class_destroyer; http://en.wiki.x.io/wiki/Spruance-class_destroyer (there are many more). Points to note: a) they present lists of ships in tabular format just like the article under discussion here, and with comparable level detail; thus your comment ″I'm not sure if this level of detail should be included in an article about the class″ is rather at odds with a number of existing precedents, and you want to start pruning details you consider inappropriate you might encounter quite a bit of push-back from other editors. b) they all present dates without abbreviations for months; and yet all of these tables need a very wide screen in order to be presented with one entry per line (too large a screen for most laptops or handhelds); thus users of such devices are presented with a lot of extraneous space with no information; if abbreviated dates were used, the table would be a lot more compact (as is the table in this article). I reiterate: abbreviated dates ARE permitted by the MOS in these circumstances, and (as Lynda has pointed out) do NOT present any particular difficulties for foreign language users capable of using Google translate. Use of full months rather than abbreviations conveys no extra information, and causes tabular data to appear in a much less accessible and useable formDfvj (talk) 02:57, 29 August 2018 (UTC)
- Full months should be used. Dates get garbled when its May or Mar, Jun or Jul. Shortcuts lead to confusion and errors. It's the same reason I abhor those who use the 08-10-18 format. Depending on who wrote that, that could be 8 October or August 10. Clarity is the issue here. If reading on mobile is such a big problem, go to the web developers to see if there is a way to fix that problem, turn the screen sideways or get a bigger phone. In the meantime, providing clarity should be the utmost focus of the authors of the encyclopedia and we should be aiming to prevent the kind of date errors we sometimes see in our sources. Llammakey (talk) 23:15, 29 August 2018 (UTC)
- This is a good point - anything that is entered by human hands can be fat-fingered, so spelling the months out fully will give readers more assurance that what's written is correct. Parsecboy (talk) 00:34, 30 August 2018 (UTC)
- Suggesting people get a bigger phone because you don't like abbreviating months is rather disrespectful to readers who can't afford bigger devices. Your assertion that abbreviations lead to errors because there is only one letter difference in some of the abbreviations for certain months could equally be used to require the day of the month and the year be spelled out in words rather than using numbers: e.g. since 11 Nov 1918 could, by a single slip, easily end up as 12 Nov 1918 or 11 Nov 1718, by your argument all dates should be rendered as "Eleventh of November, Nineteen-hundred and eighteen"(etc.). It goes without saying that care must be exercised to present the correct data, but the line between conciseness/usability and clarity/unambiguousness must be drawn somewhere (and that's why we have the Manual of Style!) Dfvj (talk) 06:29, 30 August 2018 (UTC)
- No, I suggested problems with reading on mobile should be addressed in the proper place, where the mobile version of the site is programmed. You just read the second part of the sentence. By the way, bigger devices are not always more expensive. You can get a larger tablet for cheaper than any iphone. So that's a strawman argument. As for date errors, the month error can be avoided just by spelling out the month. We should be trying to avoid errors. Using the possibility of other errors to allow for these errors is an odd argument to make. Llammakey (talk) 11:11, 30 August 2018 (UTC)
- Your first suggestion can be paraphrased thus: "I don't like abbreviations for months, and if that results in table looking like a mess, it's not my problem; someone else should fix the problem by developing new software or buying a new computer"; I am more interested in finding pragmatic solutions using the tools we have, rather than unthinking adherence to some arbitrary standard inconsistent with the MOS. Your second point is well taken, when making abbreviations can result in errors can occur; my response is also applies to the numerical day-of-the-month and the numerical year, which would result in an even more unweildy appearance if they were spelled out, so obviously one must make a compromise; and editors must be very diligent to avoid errors (which is true in all circumstances). I reiterate: the use of full months rather than abbreviations conveys no extra information, and causes tabular data to appear in a much less accessible and useable form; abbreviations for dates are unequivocally permitted by the MOS.Dfvj (talk) 13:41, 30 August 2018 (UTC)
- No you're moving the goalposts. I disagree with the abbreviated months add no extra information, because those who translate the pages would find it easier to translate the full word than an abbreviation. Once again a strawman argument. Look, I understand you like your mobile phone and it means a lot to you, but books do not shorten words because mobile phones are small. They change the format of the book so the full words fit. I sincerely believe you should be going over to the programmers and finding a way to fix your problem there. Clarity and error prevention should take utmost precedence over whether something looks pretty. We are not in a beauty contest here, we are not here to win awards, we are here to present the facts and introducing new ways to create errors just because to sum up your argument "it doesn't look nice" is not a healthy way to build an encyclopedia. Pragmatism involves prevention of errors. Shortcuts that introduce errors is the opposite of pragmatism. This argument is getting circular with you. You obviously want your pretty, but possibly error-ridden data tables. I hope whomever closes this argument sees this for what it is. Llammakey (talk) 13:53, 30 August 2018 (UTC)
- I notice that back in the mists of time when this information wasn't presented in a table, but as prose lists, the information was actually sourced - why was the referencing removed?Nigel Ish (talk) 18:06, 30 August 2018 (UTC)
- First, in response to Llammakey(13:53, 30 August 2018 (UTC)): you seem peculiarly averse to presenting data in a well organized, readily accessible manner: I agree this not a beauty contest, but neither is it an exercise in masochism. Specifics: you claim that the table is "possibly error ridden": I spent a considerable amount of time meticulously checking all the published sources I could find and resolving any discrepancies between them, so would it be too much to expect that you point to an example of such an error before making such scurrilous and unfounded assertions? You say ″books do not shorten words″; well in the standard published references, such as the contemporary editions of Jane's, or more modern works like Conway's, the tabular lists for numerically large classes of ships invariably use either numbers for months, or abbreviations similar to those used in this article. Your assertion about abbreviations confounding foreign readers has already been shown to be spurious in comments above: I refer you to that discussion. I reiterate again: the use of full months rather than abbreviations conveys no extra information, and causes tabular data to appear in a much less accessible and useable form; abbreviations for dates are unequivocally permitted by the MOS.Dfvj (talk) 21:18, 30 August 2018 (UTC)
- Now Nigel (18:06, 30 August 2018 (UTC)): the "prose list" presentation in the earlier versions of this article was the starting point for the table currently appearing in the article. The reasons for replacing the list with a table were: (i) that the list was cumbersome (i.e. a table presents the data directly in a readily accessible manner; with the prose list each entry had to be read through to extract a particular fact) and the list contained contained much redundancy (e.g. the words "laid down", "launched", "completed" were included in every entry). Indeed some of the individual dates in the list format had direct references for their source (although in most cases this was a repetitive reference to a single citation, which is excessively pedantic). All the data currently displayed was re-checked against multiple sources (which are all referenced at the foot of the table); there are a few discrepancies between these sources, which are noted on this talk page above (these can be moved to the main article very easily of course, though I doubt it adds much for the general reader). I hope this clarifies things for you.Dfvj (talk) 21:18, 30 August 2018 (UTC)
- First, in response to Llammakey(13:53, 30 August 2018 (UTC)): you seem peculiarly averse to presenting data in a well organized, readily accessible manner: I agree this not a beauty contest, but neither is it an exercise in masochism. Specifics: you claim that the table is "possibly error ridden": I spent a considerable amount of time meticulously checking all the published sources I could find and resolving any discrepancies between them, so would it be too much to expect that you point to an example of such an error before making such scurrilous and unfounded assertions? You say ″books do not shorten words″; well in the standard published references, such as the contemporary editions of Jane's, or more modern works like Conway's, the tabular lists for numerically large classes of ships invariably use either numbers for months, or abbreviations similar to those used in this article. Your assertion about abbreviations confounding foreign readers has already been shown to be spurious in comments above: I refer you to that discussion. I reiterate again: the use of full months rather than abbreviations conveys no extra information, and causes tabular data to appear in a much less accessible and useable form; abbreviations for dates are unequivocally permitted by the MOS.Dfvj (talk) 21:18, 30 August 2018 (UTC)
- I notice that back in the mists of time when this information wasn't presented in a table, but as prose lists, the information was actually sourced - why was the referencing removed?Nigel Ish (talk) 18:06, 30 August 2018 (UTC)
- No you're moving the goalposts. I disagree with the abbreviated months add no extra information, because those who translate the pages would find it easier to translate the full word than an abbreviation. Once again a strawman argument. Look, I understand you like your mobile phone and it means a lot to you, but books do not shorten words because mobile phones are small. They change the format of the book so the full words fit. I sincerely believe you should be going over to the programmers and finding a way to fix your problem there. Clarity and error prevention should take utmost precedence over whether something looks pretty. We are not in a beauty contest here, we are not here to win awards, we are here to present the facts and introducing new ways to create errors just because to sum up your argument "it doesn't look nice" is not a healthy way to build an encyclopedia. Pragmatism involves prevention of errors. Shortcuts that introduce errors is the opposite of pragmatism. This argument is getting circular with you. You obviously want your pretty, but possibly error-ridden data tables. I hope whomever closes this argument sees this for what it is. Llammakey (talk) 13:53, 30 August 2018 (UTC)
- Your first suggestion can be paraphrased thus: "I don't like abbreviations for months, and if that results in table looking like a mess, it's not my problem; someone else should fix the problem by developing new software or buying a new computer"; I am more interested in finding pragmatic solutions using the tools we have, rather than unthinking adherence to some arbitrary standard inconsistent with the MOS. Your second point is well taken, when making abbreviations can result in errors can occur; my response is also applies to the numerical day-of-the-month and the numerical year, which would result in an even more unweildy appearance if they were spelled out, so obviously one must make a compromise; and editors must be very diligent to avoid errors (which is true in all circumstances). I reiterate: the use of full months rather than abbreviations conveys no extra information, and causes tabular data to appear in a much less accessible and useable form; abbreviations for dates are unequivocally permitted by the MOS.Dfvj (talk) 13:41, 30 August 2018 (UTC)
- No, I suggested problems with reading on mobile should be addressed in the proper place, where the mobile version of the site is programmed. You just read the second part of the sentence. By the way, bigger devices are not always more expensive. You can get a larger tablet for cheaper than any iphone. So that's a strawman argument. As for date errors, the month error can be avoided just by spelling out the month. We should be trying to avoid errors. Using the possibility of other errors to allow for these errors is an odd argument to make. Llammakey (talk) 11:11, 30 August 2018 (UTC)
- Suggesting people get a bigger phone because you don't like abbreviating months is rather disrespectful to readers who can't afford bigger devices. Your assertion that abbreviations lead to errors because there is only one letter difference in some of the abbreviations for certain months could equally be used to require the day of the month and the year be spelled out in words rather than using numbers: e.g. since 11 Nov 1918 could, by a single slip, easily end up as 12 Nov 1918 or 11 Nov 1718, by your argument all dates should be rendered as "Eleventh of November, Nineteen-hundred and eighteen"(etc.). It goes without saying that care must be exercised to present the correct data, but the line between conciseness/usability and clarity/unambiguousness must be drawn somewhere (and that's why we have the Manual of Style!) Dfvj (talk) 06:29, 30 August 2018 (UTC)
- This is a good point - anything that is entered by human hands can be fat-fingered, so spelling the months out fully will give readers more assurance that what's written is correct. Parsecboy (talk) 00:34, 30 August 2018 (UTC)
One point which I hope does not need stating, but I'll state it anyway: I do appreciate everyone's shared commitment to making Wikipedia in general (and its nautical articles in particular) both useable and authoritative; we share common goals, even if we differ on the relatively minor matter of when it is appropriate to abbreviate months!Dfvj (talk) 06:47, 30 August 2018 (UTC)
- C-Class Ships articles
- All WikiProject Ships pages
- C-Class military history articles
- C-Class maritime warfare articles
- Maritime warfare task force articles
- C-Class Australia, New Zealand and South Pacific military history articles
- Australia, New Zealand and South Pacific military history task force articles
- C-Class British military history articles
- British military history task force articles
- C-Class European military history articles
- European military history task force articles
- C-Class World War I articles
- World War I task force articles
- C-Class World War II articles
- World War II task force articles
- C-Class Australia articles
- Low-importance Australia articles
- Low-importance Australia, New Zealand and South Pacific military history articles
- C-Class Australian maritime history articles
- Low-importance Australian maritime history articles
- WikiProject Australian maritime history articles
- WikiProject Australia articles