Talk:Bourrasque-class destroyer
Appearance
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||||||||
|
What are the numbers in parentheses following each ship's name?
[edit]In the Ships section, what are the numbers in parentheses after each ship's name? Are they page numbers or other similar references? If so, to which source(s)? There is no indication in the article what they are.
Without an explanation, they should be removed. — sbb (talk) 03:40, 22 August 2021 (UTC)
- I'm fairly certain that they're the various ID numbers used by each ship over its lifetime.--Sturmvogel 66 (talk) 14:03, 22 August 2021 (UTC)
- Ah, you're probably right. Ouragan's page lists "H16" as the pennant number when it served in the Polish Navy. But that's the only indication of any pennant/ID number for that ship (and none of the others mention any pennant numbers).
- At any rate, without more information (which ID number corresponds to which navy, date or reason of reclassification/change, etc.), I still think this information should be deleted from this article, unless and until that information is at least in a ship's article too. — sbb (talk) 14:37, 22 August 2021 (UTC)
- Fine by me. BTW you should probably know that MOS:NBSP discourages non-breaking spaces in tables.--Sturmvogel 66 (talk) 20:51, 22 August 2021 (UTC)
- re: nbsp in tables, I don't read MOS:NBSP as discouraging them wholesale. For instance, the example "12 MB" is probably good advice, if the column is really only for small quantities of megabytes. But what I've been doing is keep the day and month together, so instead of "4[break]Apr 1944", the break would occur between Apr and 1944. I read that MOS as cautionary, not prescriptive. — sbb (talk) 02:14, 23 August 2021 (UTC)
- You're quite right that they're not forbidden, but I don't expect that they're generally necessary either. I guess it comes down to individual preference as I'm not bothered by a date on multiple lines in a table and you may be. Regardless, drive on with your useful work.--Sturmvogel 66 (talk) 15:30, 23 August 2021 (UTC)
- re: nbsp in tables, I don't read MOS:NBSP as discouraging them wholesale. For instance, the example "12 MB" is probably good advice, if the column is really only for small quantities of megabytes. But what I've been doing is keep the day and month together, so instead of "4[break]Apr 1944", the break would occur between Apr and 1944. I read that MOS as cautionary, not prescriptive. — sbb (talk) 02:14, 23 August 2021 (UTC)
- Fine by me. BTW you should probably know that MOS:NBSP discourages non-breaking spaces in tables.--Sturmvogel 66 (talk) 20:51, 22 August 2021 (UTC)
- Followup: I converted the list of ship information to a MOS:DTT accessible table in edit 1040655000. I deleted the parenthetical list of ID numbers following each ship name. I also discarded the translation of each ship name. They're not important for a data table, and the namesake translation is available at each article's page. — sbb (talk) 21:38, 25 August 2021 (UTC)
- Generally looks good, although I deleted the sortable code as unnecessary. Why the plainlist code? I don't bother myself, usually just treating their fates as a sentence fragment.--Sturmvogel 66 (talk) 22:52, 25 August 2021 (UTC)
- I use {{indented plainlist}} for lists in tables and infoboxes. For instance, in the the "Fate" column of most of these tables, a semicolon-separated list of events, such as "Some event explanation that will wrap, 1945; Another description that will also wrap, 1950" is really just a different type of list, after all. {{indented plainlist}} just indents the wrap by 1em (by default, but the wrap can be set to any CSS value, with "|indent=0.5em", for example). Yeah, using that in "Fate" fields where there's only a single "event" is overkill, but it's more for self-consistency within a given table. If most of the "Fate" fields in a particular table have lots of events, the small indentation makes it clear, without taking up nearly as much precious space as a bulleted list wastes.
- Perhaps a bit obsessive on my part, I'll grant. Andromeda-class attack cargo ship § Ships I think a good example of demonstrating the clearer list & separation, because most of the "Fate" fields are "busy". For some class pages where the "Fate" column is pretty consistently filled and similar data, in those cases I even assigned a sortable value (|data-sort-value="..." in the cell's prefix area) to what I considered the most salient event in that Fate field, thus making Fate sortable by date. But I've abandoned doing that (mostly because the field is usually much more ad hoc. — sbb (talk) 00:40, 26 August 2021 (UTC)
- re: sortable: Other than trivially short data tables, I think the tables should be sortable on ship name(s), hull numbers, builder, and single-date fields. If somebody wants to extract that data or view it sorted for some reason, it really helps. As far as what the threshold is for "trivially short" tables, that's certainly arguable. IMO, Bourrasque's table is long enough to be sortable, if only because a grid of 4–5 by ~10 date fields doesn't easily scan, especially with Mmmmm or Mmm month values (as opposed to ISO YYYY-MM-DD dates). — sbb (talk) 00:46, 26 August 2021 (UTC)
- Final comment, and I'll stop futzing with it. You're right,
{{indented plainlist}}
didn't add anything to this table, especially after I caught the missed full month names, which freed up a bit more horizontal space, causing almost no wrapping in "Fate" anyways. So I nixed it. Good call. — sbb (talk) 00:53, 26 August 2021 (UTC)
Categories:
- C-Class Ships articles
- All WikiProject Ships pages
- Start-Class military history articles
- Start-Class maritime warfare articles
- Maritime warfare task force articles
- Start-Class European military history articles
- European military history task force articles
- Start-Class French military history articles
- French military history task force articles
- Start-Class World War II articles
- World War II task force articles