Template talk:Infobox aircraft occurrence/Archive 2

Archive 1

Archive 2

Plane crash fatalities

There's some confusion over whether or not to append "(all)" to the number of fatalities in the infobox if everyone onboard perished. In the parameters list in the template, when there are multiple aircraft involved, the total_fatalities parameter says When the total_survivors parameter is zero do not add "(all)", as it is redundant. However, for the plane1_fatalities / fatalities parameters (lower down the list) it specifies add in parentheses ... if everyone involved died, i.e. do use "(all)" in this case. Why would it be one rule for the total_fatalities parameter but a different rule for the plane1_fatalities and fatalities parameters? Am I missing something here? I think other people are confused too as there has been some argument in articles about whether or not we should be using (all) at all. Example EgyptAir Flight 990. Please can it be explained/clarified so we know what is correct. Rodney Baggins (talk) 06:00, 16 April 2018 (UTC)

My two cents is that that "(all)" should never be used. The only time it makes sense to use "(all)" is when all of the occupants (passengers and crew) of a particular aircraft die in an incident, and in those cases, the presence of a zero in the "survivors" field renders the "(all)" redundant. Sario528 (talk) 17:07, 16 April 2018 (UTC)

Thanks for starting this discussion Rodney Baggins. My preference is to never use "(all)" in the fatalities parameter when the survivor pram is 0. Take another look at pram list. It quotes "(all)" for the single aircraft injuries pram, not fatalities. - Samf4u (talk) 19:03, 16 April 2018 (UTC)

Samf4u, plane1_fatalities / fatalities parameter says "...add in parentheses if any of these people were other than crew or passengers, or if everyone involved died" which I think means the same thing, i.e. use "(all)", it's just worded differently so not very clear. My main issue with all this is that there should be clarity and consistency, not one rule for one parameter and another rule for another (equivalent) parameter. Rodney Baggins (talk) 09:19, 17 April 2018 (UTC)

Rodney Baggins, I agree it is less than clear and thought perhaps you made the same mistake I did the first time I read it. - Samf4u (talk) 12:11, 17 April 2018 (UTC)

It should be clarified that we don't use "(all)" when the numbers clearly show no survivors, it is just redundant. - Ahunt (talk) 21:17, 16 April 2018 (UTC)

I disagree; "(all)" is useful, even if logically redundant. It makes it immediately clear what type of outcome there was (a very common one, but far from universal). The reader should not have to deduce it from a set figures. Indeed, the first thing that catches my attention is the Fatalities figure; I then instinctively tend to check if Passengers + Crew is equal to Fatalities; hold on, there is a Survivors figure further down; it's 0; ah OK, everybody died. Why not just spend five more, harmless characters and save the reader all the hassle? --Deeday-UK (talk) 00:01, 17 April 2018 (UTC)

Deeday-UK, no offence but I don't think it's all that much "hassle" to notice that Survivors=0. No advanced math required there! The Fatalities and Survivors figures are mutually exclusive, so if one of them is zero we must infer that the other one is all. I wouldn't have thought there was any need to even look at the Passengers and Crew figures. And I expect the lead section would normally carry an obvious mention of the fact that all onboard lost their lives, if the reader happens to be confused by the info box. We should really be giving them a bit more credit! Rodney Baggins (talk) 06:53, 17 April 2018 (UTC)

On the other hand, what's the harm in explicitely mentioning it? I have never been bothered by it and I don't think anyone would be confused because of it. Richard 08:55, 17 April 2018 (UTC)

Rodney Baggins, why do we want readers to have to infer things, as you said yourself? An encyclopedia should present information in the clearest possible way. You look at where the "(all)" is, and you know at a glance what happened; no need to analyse figures any further. --Deeday-UK (talk) 09:04, 17 April 2018 (UTC)

Another thought I've had is: would it not be more appropriate to put the Survivors parameter first, followed by the Fatalities parameter, as surely we should be slightly more interested in how many survivors there were than how many people died. More positive angle? Slightly less obvious morbid fascination? Just a thought. And also this would have the advantage of the reader seeing the Survivors=0 figure first if everyone perished, so they would know that the Fatalities figure (below) meant all then anyway. Rodney Baggins (talk) 09:27, 17 April 2018 (UTC)

I think it should neither be be forced nor forbidden to add '(all)' to a number. What I do find strange (and it has probably to do with reordering the parameters somewhere along the way) is that the description of the first, third and fourth total_ parameters contain 'As above, add in parentheses' whereas the second does not; that description only mentions 'Add in parentheses'. Richard 09:33, 17 April 2018 (UTC)

For the sake of homogeneity I suggest to either use it in all articles or not to use it at all. As to my opinion, they should never be used, as it is a redundancy when the number of survivors is "0".--Jetstreamer ^Talk 23:36, 20 April 2018 (UTC)

I think we have shown that it is not needed to add "(all)". We can probably close this shortly and make the changes to the documentation to make this clear in all cases. - Ahunt (talk) 23:42, 20 April 2018 (UTC)

• Oppose "(all)" as redundant. In a one aircraft incident, with no ground fatalities, there is just no way that anyone could possibly misunderstand what "survivors=0" means. If anyone thought I needed that in order to understand the infobox, I'd find it a little insulting. I assume this came about because aircraft collisions and crashes with ground fatalities are more complicated, and those tallies require further explanation. Those events appear to be the exception rather than the rule, so it shouldn't have been extrapolated from there to try to apply it to every instance. Geogene (talk) 00:53, 21 April 2018 (UTC)
• ALL should not be used This information is already given in the infobox via the use of a numeric digit paired with a descriptor, such as "fatalities", which when combined with the process of deduction, gives you the answer (e.g., passengers minus survivors equals fatalities, or 100 – 0 = 100). It's also in the article, with the use of prose ("All of the passengers were killed in the crash."). Thus, the inclusion of a secondary, non specific indication seems trivial. According to Help:Infobox#What_should_an_infobox_not_contain? "Infobox templates should not be used for details that are too trivial to include in the article body.". IMHO there is no difference between the inclusion of trivial information and the trivial inclusion of information. The simple act of including trivial information, itself, renders that inclusion as trivial. They are one in the same. Its usage is trivial, because non-specific words, unlike numbers, are not usually used in isolation. The information is trivial, because single, non specific predeterminer-type words such as "all" tells us nothing when used in either the survivors or fatalities parameters, since that usage does not otherwise specify in which group the fatalities occurred: "All means all what? All the passengers? All the crew? All the people on the ground?" Using the trivial word "all" by itself in a trivial manner could end up creating just as much confusion as it purports to solve. The editor who supports this change the most believes that the power of deduction may not be as strong or as common as most people would think. And I will grant them that. But at the end of the day, the use of the infobox to solve problems of deduction is usage beyond the infobox's purpose.   SPINTENDO           05:35, 28 April 2018 (UTC) 
• I want to draw this to a close now as I think we've pretty much reached consensus. Thanks to everyone for pitching in with your opinions and reasoning. When I started the discussion I simply stated that there was confusion and please could it be clarified. I didn't actually state my opinion which is a proposal that we should drop the "(all)" from the Fatalities parameter for a one aircraft incident if all onboard died, to match the guidelines for the other instances of the infobox. As such, there are SEVEN votes for that proposal, ONE against (Deeday-UK) and ONE neutral (Richardw). So let's be bold and get it done. The template's source code doesn't need changing, just the documentation, so I'll go ahead and do it when I get a minute and meanwhile please look out for any articles that contravene the consensus and delete the "(all)" accordingly. Thanks. Rodney Baggins (talk) 10:31, 28 April 2018 (UTC)

 Done after a bit of faffing about (!) hope it's to everyone's liking, let me know if anything looks incorrect. Rodney Baggins (talk) 10:26, 29 April 2018 (UTC)

Template-protected edit request on 28 April 2018

I'm requesting a number of edits to the template, most of which are the result of the above consensus. However, some of them are just my own observations, common sense, etc.

In the Parameters table, please edit:

Parameter / alternate: site
Explanation: Location of accident or incident (e.g. placename, nearest city/town, country).

Parameter / alternate: coordinates
Explanation: Site coordinates of accident or incident. Use {{coord}} with display=inline,title. Please do not be overly precise.

Parameter / alternate: total_fatalities
Explanation: (For a two/three-aircraft occurrence only) Total number of deaths caused by the accident or incident. Add in parentheses if any of this number were people other than crew or passengers (e.g. "123 (4 on ground)"). If the total_survivors parameter is zero do not add "(all)", as it is redundant.

Parameter / alternate: total_injuries
Explanation: (For a two/three-aircraft occurrence only) Total number of injuries caused by the accident or incident. Add in parentheses if any of this number were people other than crew or passengers (e.g. "123 (4 on ground)") or if everyone involved was injured (e.g. "123 (all)").

Parameter / alternate: total_missing
Explanation: (For a two/three-aircraft occurrence only) Total number of people missing in the accident or incident. Add in parentheses if any of this number are people other than crew or passengers (e.g. "123 (4 on ground)") or if everyone involved is missing (e.g. "123 (all)").

Parameter / alternate: total_survivors
Explanation: (For a two/three-aircraft occurrence only) Total number of people who survived the accident or incident. Add in parentheses if everyone involved survived (e.g. "123 (all)").

Parameter / alternate: plane1_fatalities / fatalities
Explanation: For a single-plane occurrence, the total number of deaths caused by the accident or incident. For a two/three-aircraft occurrence, the number of people killed onboard the first aircraft. Add in parentheses if any of this number were people other than crew or passengers (e.g. "123 (4 on ground)"). If the plane1_survivors / survivors parameter is zero do not add "(all)", as it is redundant.

Parameter / alternate: plane1_injuries / injuries
Explanation: For a single-plane occurrence, the total number of injuries caused by the accident or incident. For a two/three-aircraft occurrence, the number of people injured onboard the first aircraft. Add in parentheses if any of this number were people other than crew or passengers (e.g. "123 (4 on ground)") or if everyone involved was injured (e.g. "123 (all)").

Parameter / alternate: plane1_missing / missing
Explanation: For a single-plane occurrence, the total number of people missing in the accident or incident. For a two/three-aircraft occurrence, the number of people missing from the first aircraft. Add in parentheses if any of this number are people other than crew or passengers (e.g. "123 (4 on ground)"), or if everyone involved is missing (e.g. "123 (all)").

Parameter / alternate: plane1_survivors / survivors
Explanation: For a single-plane occurrence, the total number of people who survived the accident or incident. For a two/three-aircraft occurrence, the number of survivors onboard the first aircraft. Add in parentheses if everyone involved survived (e.g. "123 (all)").

In section 2.2. Examples – Two or three aircraft (using Pacific Southwest Airlines Flight 182), please change:

| plane1_fatalities = 135 (all)

to:

| plane1_fatalities = 135

The "(all)" should also disappear from the infobox over on the right.

Rodney Baggins (talk) 22:49, 28 April 2018 (UTC)

Rodney Baggins  Not done All the changes I see you are requesting are edits to the documentation page, which you should be able to do yourself. Galobtter (pingó mió) 08:39, 29 April 2018 (UTC)

Thank you. I was looking at the template and couldn't find the documentation. It was very late at night or early in the morning... At least this way people get to see the precise changes I'm making! Rodney Baggins (talk) 09:35, 29 April 2018 (UTC)

 Done Rodney Baggins (talk) 10:24, 29 April 2018 (UTC)

I notice that some fields still allow the (all), could that be confusing when we have removed it from other fields? MilborneOne (talk) 10:26, 29 April 2018 (UTC)

The only fields that allow (all) are injuries/missing/survivors as these figures are all independent of one another. The fatalities field doesn't require (all) because it has a mathematical relationship with the survivors field, i.e. fatalities+survivors equals number of people on board, so the consensus is that it's not necessary to put (all) after the fatalities figure if survivors is zero. (And if anyone else was killed, e.g. people on ground, they would be mentioned in parentheses so that's covered.) Rodney Baggins (talk) 10:36, 29 April 2018 (UTC)

Thanks but that does allow "survivors=123 (all)" is that intended? MilborneOne (talk) 10:41, 29 April 2018 (UTC)

→ Yes because when fatalities=123 and survivors=0, the infobox would look like this:

fatalities=123

survivors=0

Both parameters are included in the infobox (because even though survivors is a "null" parameter, it's obviously very important to show it here) and we can immediately see that everyone died from the very fact that there were no survivors

But at the other end of the scale, if fatalities=0 and survivors=123, the infobox would look like this:

survivors=123 (all)

In this case fatalities is not shown because it's an unnecessary "null" parameter – there's no need to tell people that there were no fatalities because the default assumption (by dint of human nature) is that no-one died if nothing is mentioned about it! – so survivors=123 needs to be clarified with (all), otherwise we'd just be left with the rather ambiguous survivors=123

Which, funnily enough, is the very crux of the original argument that started all this off in the first place. So QED! Thank you for inducing me to uncover the elusive fundamental logic behind our consensus! Rodney Baggins (talk) 11:18, 29 April 2018 (UTC)

Only now I've taken the time to read this, and I'm struck by its absurdity: essentially we want to convey the information that everybody died by adding the parameter survivors = 0 and omitting the '(all)' next to Fatalities, whereas if everybody survived we put '(all)' next to Survivors and omit fatalities = 0. Where is the logic in that? It is confusing for editors and makes it less clear for readers. If the reason is some 'default assumption' that some editor made, as stated above, that is wrong: we know nothing what assumptions each individual reader will make, and we should not leave it to readers to deduce information from an incomplete set of figures. We should keep it simple and clear: always state all parameters, even the 0 ones, and add an '(all)' wherever appropriate. --Deeday-UK (talk) 11:13, 6 June 2018 (UTC)

We had a lengthy discussion about this, reached a consensus (you were the only person in opposition), we made the change, period. It is not absurd to assume that if no-one died we don't need to explicitly state that no-one died. The very omission of the parameter (by human nature) will be interpreted (at a subconscious level) as meaning that there were no fatalities, because if there had been any we would most certainly have mentioned it!

By putting (all) next to Survivors we're essentially saying "Hey look, everyone survived, thank God!"

If we were to put (all) next to Fatalities it would be like saying: "Hey, everybody died, how about that then!?"

It's fascinating having this little discussion with you but it's not going to change anything. If you feel the need to start a new discussion, then please go ahead, I really think you should, but my guess is that it might very well reach the same conclusion as before. You could always bring it up on the project talk page where I notice that you and I have the polar opposite opinion on the use of flags. I do hope it's nothing personal. I guess you and me just don't see things the same way! Rodney Baggins (talk) 12:01, 6 June 2018 (UTC)

No, it's not personal; I'm looking at the arguments, and I don't see much sense in them. The result of the earlier discussion is an illogical mess: the '(all)' can be used in some fields but not in others; when it's missing, it could still be the case that all on board died, but the reader has to work it out by looking for some other field that may be set to zero, while being expected to make some arbitrary assumptions on how the data is presented and praise the lord as required. As you can see, I'm not the only editor who has expressed doubts about the current confusing situation, and yes, I will start a new discussion, when I care enough about it. --Deeday-UK (talk) 01:09, 8 June 2018 (UTC)

Template-protected edit request on 20 July 2018

Per above discussion, the proposed new version of the template is currently in the sandbox. It contains the proposed new parameters for flight number and call sign, for up to three aircraft involved in the occurrence. List of known parameters sorted alphabetically. Deeday-UK (talk) 23:49, 20 July 2018 (UTC)

Done Looks good to me. Enterprisey (talk!) 13:44, 27 July 2018 (UTC)

Flight number and callsign

Any thoughts on adding the IATA and ICAO Flight Numbers and Callsign to the infobox rather than in the lead sentence:

IATA Flight No	BA123
ICAO Flight No	BAW123
Callsign	Speedbird 123

MilborneOne (talk) 17:31, 10 June 2018 (UTC)

I think this is a good idea - why not make the format the same as Template:Infobox_airline? CapitalSasha ~ talk 01:04, 11 June 2018 (UTC)

Probably not a bad idea, we just need somebody who can tweak the code. MilborneOne (talk) 15:00, 15 June 2018 (UTC)

Agree with the idea. That data belongs to the infobox, not to the lead (let alone in bold, as it is sometimes formatted). --Deeday-UK (talk) 20:33, 17 June 2018 (UTC)

I've had a shot at implementing the proposed new parameters, see example below. The parameters names (IATA, ICAO, callsign) are the same as the ones used for {{Infobox_airline}} as suggested – also with provision for multiple aircraft (i.e. plane1_IATA, plane3_callsign etc.) The proposed labels (IATA flight No. and ICAO flight No.) take into account MOS:CAPSACRS and MOS:NUMERO. Also, call sign seems to be preferred to callsign, here on WP and on dictionary.com. Any comments or suggestions? --Deeday-UK (talk) 16:20, 15 July 2018 (UTC)

British Airways Flight 9

G-BDXH, the aircraft involved in the accident, photographed at San Francisco Airport in 1980.
Accident
Date	24 June 1982
Summary	Quadruple engine flameout
Site	near Mount Galunggung, West Java, Indonesia
Aircraft
Aircraft type	Boeing 747-236B
Aircraft name	City of Edinburgh
Operator	British Airways
IATA flight No.	BA009
ICAO flight No.	BAW009
Call sign	Speedbird 9
Registration	G-BDXH
Flight origin	London Heathrow Airport, London, England
Destination	Auckland Airport, Auckland, New Zealand
Passengers	248
Crew	15
Injuries	0
Survivors	263 (all)

Thanks for Deeday, that look OK and certainly be better than cluttering up the lead. MilborneOne (talk) 18:13, 15 July 2018 (UTC)

I forgot to say: this is only a draft from my sandbox; the actual template code is still unchanged (I have to raise an edit request for that). --Deeday-UK (talk) 19:51, 15 July 2018 (UTC)

Deeday-UK, would you be okay with having 'No.' changed into 'no.', 'nr.' or 'number'? Richard 08:43, 6 August 2018 (UTC)

'No.' seems to be the preferred form according to MOS:NUMERO (which doesn't mention 'nr.') and I think it's preferable to 'no.' (there's less risk of confusion with no as in yes and no, especially because the dot at the end of the field looks like a full stop). Arguably, number would be even clearer, but the resulting field is too long and squeezes all the infobox data to the right, which doesn't help readability. See example below. --Deeday-UK (talk) 22:54, 6 August 2018 (UTC)

Okay, then we'll leave it at that. I wouldn't have used a capital mid-sentence, but in the examples in MOS capitals are used as well. I don't really think that confusion with 'no' would occur (there's no semicolon between 'flight' and 'no' as in 'IATA flight: no.'), but who knows? Richard 08:01, 7 August 2018 (UTC)

British Airways Flight 9

G-BDXH, the aircraft involved in the accident, photographed at San Francisco Airport in 1980.
Accident
Date	24 June 1982
Summary	Quadruple engine flameout due to blockage by volcanic ash
Site	near Mount Galunggung, West Java, Indonesia
Aircraft
Aircraft type	Boeing 747-236B
Aircraft name	City of Edinburgh
Operator	British Airways
IATA flight number	BA009
ICAO flight number	BAW009
Call sign	SPEEDBIRD 9
Registration	G-BDXH
Flight origin	London Heathrow Airport, London, England
Destination	Auckland Airport, Auckland, New Zealand
Passengers	248
Crew	15
Injuries	0
Survivors	263 (all)

Embedding

It's likely to come up soon that Template:Infobox NRHP will need to be added to 1947 Oregon Beechcraft Bonanza crash. The preferred way to do this will be to embed the NRHP infobox into the aircraft occurrence infobox (see this documentation). However the aircraft occurrence template doesn't appear to offer this functionality. Can an appropriate parameter be added? — Ipoellet (talk) 16:25, 15 September 2018 (UTC)

Not sure why you would class an accident as an historic place. MilborneOne (talk) 16:28, 15 September 2018 (UTC)

The accident site, of course. Portions of the accident aircraft remain in situ. The crash location really has no other significance, so having separate articles for the accident and the site is excessive. — Ipoellet (talk) 16:36, 15 September 2018 (UTC)

I would still argue that an accident cant be a place, if the place is considered notable then the place or accident site should have an article. I cant see it myself but I assume the NRHP thing is related to the notability of Governor Earl Snell not the accident. MilborneOne (talk) 17:14, 15 September 2018 (UTC)

Of course an event and the location where it happened aren't the exact same entity. But they can be discussed in the same article. You wouldn't write about a battle but omit all mention of the battlefield. This is Wikipedia, not Wikidata. As an encyclopedia reader, I would be sincerely irritated to have to go to two different places to get full information about a single topic if it wasn't necessary. — Ipoellet (talk) 18:02, 15 September 2018 (UTC)

Its more to do with adding an NRHP infobox to something that is not a place but a series of events so I cant see why you would ever need to to embed it. MilborneOne (talk) 18:35, 15 September 2018 (UTC)

• Wikipedia talk:WikiProject Aircraft notified to get other views on the request. MilborneOne (talk) 18:50, 15 September 2018 (UTC)

I think user Ipoellet may have a point. We already show the accident site prominently in the infobox (and even display its co-ordinates at the top of the article); if that site – say a random nameless spot on a mountainside – makes it into the NRHP because of the crash, then the most logical place where to cover that information is the accident article, rather than in any biography of notable victim (and what if there are more than one notable victim?) --Deeday-UK (talk) 20:11, 15 September 2018 (UTC)

I have to agree with Deeday-UK. It seems to me that several accident sites are bound to end up on the NRHP list. For instance, the location of the 9/11 flight that went down in PA in 2001. IF someone created a separate article for the crash, then it would be expected to find the NRHP listing on the same page. — TadgStirkland⁴⁰¹ (Tadg^Talk) 22:39, 15 September 2018 (UTC)

@Deeday-UK: You have a point about multiple notable victims. In the immediate case, 3 of the 4 fatalities have their own Wikipedia articles.

@TadgStirkland401: In the case of the Flight 93 case, the crash site has been made into a national park with a constructed memorial. Because of that, the physical location has enough independent significance that it is appropriate to treat it in its own article, especially when applying summary style. — Ipoellet (talk) 02:40, 16 September 2018 (UTC)

• Wikipedia talk:WikiProject National Register of Historic Places notified to get other views on the request. — Ipoellet (talk) 17:51, 16 September 2018 (UTC)

Look at Kent State shootings as an example of an event where the site was listed on the NRHP Einbierbitte (talk) 20:24, 16 September 2018 (UTC)

Perhaps a good example of a similarly situated article would be 1956 Grand Canyon mid-air collision, whose debris field area is not otherwise notable (beyond being in the Grand Canyon). That article does not presently have an NHRP infobox. Magic♪piano 21:53, 16 September 2018 (UTC)

• Agree this makes sense if the site is on the NRHP, then there is no reason to have separate articles; it is logical to cover the site and the crash together as they are obviously tightly related. There are many articles that are 95% about some topic (such as a school) with just an infobox and a few paragraphs devoted to a NRHP structure there. In those cases, it is conceivable that the NRHP info could someday be expanded into a separate article. But with a crash site, I don't see that ever happening. I also not that while embedding infoboxes is probably preferable, a separate NRHP infobox could be used as well. MB 21:12, 16 September 2018 (UTC)

Ditto to User:MB. I am primarily an editor of NRHP topics, and saw notice of this discussion at Wikiproject NRHP's talk page. --Doncram (talk) 03:57, 23 September 2018 (UTC)

• Support Embedding. Actually there's no reason not to make this work. It works fine for embedding NRHP infoboxes within infoboxes for lighthouses, for ships, for train stations, for many other infoboxes. This has helped simplify / remove duplication / improve hundreds of articles making them more understandable by readers. --Doncram (talk) 00:44, 25 September 2018 (UTC)

• Oppose Embedding - if the site is an NRHP topic, simply add the NRHP infobox where relevant in the article, such as the section which discusses the site. There's no need to modify the infobox for something only related to the US, and which is applicable to only a small number of articles. - BilCat (talk) 04:08, 23 September 2018 (UTC)

the most obvious and correct response in my mind. Trying to embed one template in another can lead to formatting in one affecting the other. The KISS principle apllies. So that's an 'oppose' from me. Should situation change further down the line, then revisit the issue of course. GraemeLeggett (talk) 09:16, 23 September 2018 (UTC)

Actually this postulation that there could be problems moves me to "!vote" in support of embedding. There has been no problem whatsoever from the minor changes needed so that embedding NRHP infoboxes (and perhaps others) works for infoboxes of lighthouses, ships, train stations, museums, many other infoboxes that routinely include NRHP information occasionally. This removes duplication/confusion across the infoboxes in any given article. --Doncram (talk) 00:44, 25 September 2018 (UTC)

• Support Embedding - Not to contradict @BilCat:'s comment above, the template called "Infobox mountain" is used for mountains all over the world. Yet, in cases like the Fort Mountain article, it allows the NRHP infobox to be embedded. For conformity and consistency, I support the idea of embedding in the case of the infobox aircraft occurrence. — TadgStirkland⁴⁰¹ (Tadg^Talk) 01:23, 24 September 2018 (UTC)

"ICAO Flight No." field

ICAO codes are not (typically) used commercially; they are used for ATFM purposes (as part of the aircraft identification), where the code may or may not be followed by the commercial flight number - in Europe in particular, it is increasingly the case that it is not. In radiotelephony the three-letter designator is swapped out for the telephony designator, which is what gives rise to the call sign. In the Germanwings Flight 9525 infobox the "ICAO Flight No" is listed as "GWI9525", but this is not an identifier you'd encounter anywhere. I suggest removing this field. 62.228.48.165 (talk) 22:03, 10 December 2018 (UTC)

Template-protected edit request on 8 February 2019

Can we please change each of the labels for fields referring to the number of people injured to replace the word "injuries" with "injured". We would naturally say "there were two people injured in an accident", not "there were two injuries in an accident". As it currently is, using "injuries", its meaning is ambiguous as that could mean one injured person with two injuries or two injured people with one injury each.

Specifically, please change:

"label33 = Injuries" to "label33 = Injured"

"label60 = Injuries" to "label60 = Injured"

"label86 = Injuries" to "label86 = Injured"

"label91 = Ground injuries" to "label91 = Ground injured"

-- DeFacto (talk). 20:53, 8 February 2019 (UTC)

Please get consensus for this. The current labels almost all have parallel structure: Passengers, Crew, Fatalities, Injuries, Survivors, etc. (except "Missing"). The above proposal would break that parallel structure. – Jonesey95 (talk) 05:35, 9 February 2019 (UTC)

Label change proposal

I propose changing each of the labels for fields referring to the number of people injured. I think we need to replace the word "injuries" with "injured". We would naturally say "there were two people injured in an accident", not "there were two injuries in an accident". As it currently is, using "injuries", its meaning is ambiguous as that could mean one injured person with two injuries or two injured people with one injury each.

Specifically, I propose the following be changed:

"label33 = Injuries" to "label33 = Injured"

"label60 = Injuries" to "label60 = Injured"

"label86 = Injuries" to "label86 = Injured"

"label91 = Ground injuries" to "label91 = Ground injured"

What do other editors think. -- DeFacto (talk). 08:40, 9 February 2019 (UTC)

• Oppose – Within the context of a breakdown of casualties, it seems perfectly clear to me that 'injures' refers to the number of people injured. Googling 'fatalities and injuries' seems to return plenty of examples of such usage (these two among the top ones [1] [2]). The proposed change is a bit too pedantic to justify the added complexity of yet another parameter alias (which would be required to maintain both back-compatibility and label/parameter name consistency). --Deeday-UK (talk) 12:50, 11 February 2019 (UTC)

It wouldn't be an alias, it's only the label I'm proposing we change. -- DeFacto (talk). 18:45, 11 February 2019 (UTC)

Yes, but if we wanted to keep things consistent within the template (the 'parallel structure' Jonesey95 was referring to above), a new set of parameters such as injured=, plane1_injured= etc would need to be added as aliases of the existing ones injuries=, plane1_injuries= etc, so your proposal does add complexity to the template. --Deeday-UK (talk) 09:30, 12 February 2019 (UTC)

There is no need for a 'parallel structure', which is only partial anyway, so no need to worry about any added complexity. This is just a minor label change, nothing else is required. The only decision is whether we want the number of people injured to be labelled as "Injuries" or "Injured". -- DeFacto (talk). 14:07, 12 February 2019 (UTC)

• Oppose As Deeday pointed out, this would require a fair bit of work to make the changes without breaking something. I don't see it as being worth the effort, especially considering that the word is not being used in a sentence, but rather is a part of a list. Also, I believe that "injuries" may be the more common usage in international forms of English. (If any of our non-American editors can confirm or deny that, please let me know.) Sario528 (talk) 13:24, 11 February 2019 (UTC)

Just those four changes I mentioned above, I think. But we should be deciding on what we think is correct, and not worry about the details of the implementation. "Injuries" is the plural of the noun "injury", whereas "injured" is an adjective - so "1 injuries" sounds like nonsense, but "1 injured" makes perfect sense, to me, at least. -- DeFacto (talk). 18:31, 11 February 2019 (UTC)

If necessary, it could be programmed that if the value of the parameter is 1, a singular form would be shown. Richard 09:44, 12 February 2019 (UTC)

• Oppose for reasons already given by others. Richard 09:44, 12 February 2019 (UTC)

@Richardw: which reason in particular, the one about added complexity is, I believe, a red herring. -- DeFacto (talk). 14:17, 12 February 2019 (UTC)

Time to drop the "(all)" from casualty figures?

The last time the "(all)" annotation was discussed, I was of the idea that it should be added consistently to all applicable casualty figures in the infobox (fatalities, survivors, injured etc). What was agreed, instead, is the current guidelines, which are illogical and confusing: do not add "(all)" to the Fatalities field if everybody on board died (and let the reader deduce it by looking at Survivors=0), but do add "(all)" to Survivors if everybody survived, even if Fatalities=0 is clearly shown. Not very logical.

Anyway, all that was before the Occupants and the Ground casualties fields were widely adopted. Now that they are, any "(all)" annotation is pretty much redundant, since the set of figures is now complete and makes a lot more sense. No reliable source (ASN, tables in official reports etc.) uses such annotations either.

Therefore, I propose to remove from the template documentation all references to adding "(all)" next to any figure (e.g. "Add in parentheses if everyone involved was injured (e.g. "268 (all)")") and leave only the explanation of what the parameter is for. The "(all)" from existing infoboxes will be gradually removed, as long as the Occupants field is present. --Deeday-UK (talk) 19:20, 4 August 2019 (UTC)

• Agree - Ahunt (talk) 18:00, 6 August 2019 (UTC)
• Agree - MilborneOne (talk) 18:34, 18 September 2019 (UTC)
• Agree - Signing my agreement belatedly (realizing I hadn’t yet) per above editors. Shelbystripes (talk) 22:19, 26 January 2020 (UTC)

Proposed update of passengers/crew display

Sandbox Flight 123

Fictional Sandbox Accident
Date	February 30, 1876
Occupants	50
Passengers	47
Crew	3
Fatalities	45
Injuries	3
Survivors	5
Ground casualties
Ground injuries	1

Per the earlier template changes and above conversation, I've been meticulously filling in the "Occupants" field on infoboxes, and other editors have been doing the same, and a large number of accident/incident pages have it filled in by now. This does have a bit of a clunky appearance, and I've had a fix in mind, but it wasn't something I felt I could propose until we'd gotten this far.

I've updated the template sandbox page, to add three spaces (actually "   ") in front of each instance of "Passengers" and "Crew" in the template. This indents the words "Passengers" and "Crew" underneath "Occupants" (implying, correctly, that they're subsets of the total number of "occupants" of each aircraft). Since an article should always have "Occupants" (and most already do, and the rest can be updated when we come across them), I think this visually helps with reading the page. You can see an example of what this does in the sandbox-based rendering to the right. Additional examples of what the sandbox code does are available on the testcases page.

Please let me know what you think. Shelbystripes (talk) 19:27, 5 February 2020 (UTC)

UPDATE: I have also updated the order of survivor/injury/fatality counts displayed, so that "injuries" will (if populated) always display immediately under "survivors", permitting an indent of "injuries" to indicate that injuries are a subset of "survivors". (Injuries of people on the ground will go in the ground injuries box instead.) Articles should never have "injuries" without "survivors", but can have survivors without listing any injuries. Shelbystripes (talk) 03:00, 7 February 2020 (UTC)

• Seems a reasonable change to aid readability. MilborneOne (talk) 11:42, 7 February 2020 (UTC)

• Comment – A nice improvement apart from one thing: the swapping of order between Fatalities and Survivors. The original order (Fatalities first) makes more sense to me for two reasons: the No. of fatalities is generally a more relevant piece of information than the No. of survivors (considering that it's arguably one the most important factors in determining an accident's notability); Fatalities-first keeps the layout tidier, by having the indentation going in and out fewer times. --Deeday-UK (talk) 14:28, 7 February 2020 (UTC)

I've edited the sandbox template restoring the original order of the Fatalities/Survivors entries (reflected in the infobox here in this section). It looks more meaningful and tidy to me. --Deeday-UK (talk) 13:34, 12 February 2020 (UTC)

I’m OK with this change. Shelbystripes (talk) 22:21, 12 February 2020 (UTC)

Ship incidents

Can we use this template for ship incidents? Is there any other template that we can use on ship-related incidents? Note: Infobox ship begin/doc and Infobox ship career are used for ship article such as SM U-20, and it does not have relevant labels to indicate or describe incident-related articles like Draft:Kerch Strait incident (2019). TheBirdsShedTears (talk) 13:17, 23 March 2020 (UTC)

I am sure you could adapt it with some changes for that purpose. Just checked Sinking of the RMS Titanic and it seems to use Template:Infobox event, which is probably not an ideal solution. - Ahunt (talk) 13:43, 23 March 2020 (UTC)

Maps

Pakistan International Airlines Flight 8303 has a separate infobox for the map images. How can they incorporated into this template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:23, 3 July 2020 (UTC)

Its very rare that maps are much use, certainly the ones in PK8303 dont really provide much value to the article. MilborneOne (talk) 20:36, 3 July 2020 (UTC)

The statement "It's very rare that maps are much use" seems to be very far from true. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:29, 28 July 2020 (UTC)

In the above example knowing where Karachi is adds zero value to the article. MilborneOne (talk) 14:48, 28 July 2020 (UTC)

For you, perhaps, but not for others. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 28 July 2020 (UTC)

Template-protected edit request on 8 August 2020

Regretably I am not aware of how to do this, but wouldn't it be sutiable to add a pushpin map into the infobox? Practically every aviation in existent happened at a location, and coordinates don't seem to be sufficient. — Yours, Berrely • ^Talk∕_Contribs 10:22, 8 August 2020 (UTC)

I have added |pushpin_map= and a couple of related parameters to the sandbox. It requires |coordinates= in order to display. You can see the result in the first test case. Does this look like what you want? The appearance can be adjusted; if there is another infobox in which the pushpin map looks better, link to it here, and I'll see what I can do. – Jonesey95 (talk) 19:22, 8 August 2020 (UTC)

Add NTSB ID to template

NTSB assigns an identification number to all aircraft incidents within its purview or investigations it's involved in. NTSB is the authority responsible for all air crash investigations in USA and is a reliable and reputed institution. https://www.ntsb.gov/_layouts/ntsb.aviation/index.aspx One can search for all incidents on this page by date, aircraft, airport, NTSB ID etc. — Preceding unsigned comment added by Joejose1 (talk • contribs) 10:42, 9 June 2020 (UTC)

I came to the talk page just now to discuss this very thing. I think adding the option to display/link directly to an investigation docket/report for at least a handful of, at a minimum, the safety agencies that publish in English would really add depth to many articles. It would also create a consistent place where one could find the source info -- instead of digging through the ref list at the bottom... (Kinda like how the infobox for Supreme Court cases has the ability to link directly to the PDF Opinion....). The NTSB [USA], TSB [Canada], AAIB [UK], BEA [France], BFU [Germany], ATSB [AU], and TAIC [NZ] seems wise. After the NTSB, it seems that the BEA of France is often included on many international investigations probably because Airbus' HQ is in Toulouse.

As for the NTSB stuff, there are two things: The accident Docket ID - which has a standardized(ish?) format - e.g. DCA09MA026 is the docket ID for US Airways 1549 for example, but the final report ID is AAR-10-03.

The docket format AFAIK is:

XXX YY AB NNN where:

• XXX is the office in charge (DCA = DC - NTSB HQ)
• YY is a 2 digit year when the docket was opened
• A is a code letter to indicate seriousness (M for Major, F for Fatalities, I believe)
• B is the Mode (A= Aviation)
• NNN is a just a sequential number assigned

It's important to include both since the dockets often contain faaar more detail than just the summary report. (Docket access is here: https://dms.ntsb.gov/pubdms/

Jewell D D (talk) 23:54, 28 October 2020 (UTC)

First Aircraft - Override description

In a recent article, it is not possible to easily and intuitively differentiate the two aircraft involved in a collision because the two aircraft are the same make and model. The term, "First Aircraft" and "second aircraft" does not tell us anything about the colliding aircraft. Which one is first when they both collide at the same time?

I think it would be preferable to allow the editor to override this and add more contextual information about each aircraft. For example, arriving helicopter instead of "first helicopter". See 2023 Gold Coast mid-air collision for why this is could be useful for some articles. Hrbm14 (talk) 15:17, 8 January 2023 (UTC)

Crew names

In small helicopter crashes, it might be useful to allow an editor to specify the name of the pilot of each aircraft. This may further help readers identify the two or three aircraft involved in an accident. Hrbm14 (talk) 15:17, 8 January 2023 (UTC)

I would question the idea that the name of the crew is relevant enough to warrant inclusion in the infobox. The box is already more-than-enough crammed with information. Besides, I'm not sure why 'small helicopter crashes' should be treated any differently from other air accidents, once it is agreed that they deserve their own article. --Deeday-UK (talk) 23:08, 9 January 2023 (UTC)

I agree. Lists of non-notable people are non-notable and don't belong in the infobox. Also pretty close to WP:NOTMEMORIAL as well. - Ahunt (talk) 23:52, 9 January 2023 (UTC)

A parameter for the OpenStreetMap of the place of occurrence

Hi, as for 2024 Varzaqan helicopter crash, there exists no parameter for OSM map of occurrence. So I propose to add these codes:

| image2      = {{#invoke:Infobox mapframe|auto|onByDefault={{#if:{{{pushpin_map|}}}{{{map_type|}}}{{{image_map|}}}|no|yes}}|mapframe-width=250|mapframe-frame-width=250|mapframe-marker=|mapframe-zoom={{{mapframe-zoom|6}}}| mapframe-wikidata = yes}}
| caption2    = {{#invoke:Infobox mapframe|autocaption|onByDefault={{#if:{{{pushpin_map|}}}{{{map_type|}}}{{{image_map|}}}|no|yes}}}}

Thanks, Hooman Mallahzadeh (talk) 09:20, 21 May 2024 (UTC)

@UnladenSwallow Please follow this request, you too. Hooman Mallahzadeh (talk) 09:21, 21 May 2024 (UTC)

In my opinion, there's no need to include the map in the infobox. Clicking the globe icon to the left of the coordinates (displayed in the "Site" parameter) shows an inline map. — UnladenSwallow (talk) 11:41, 21 May 2024 (UTC)

No. In my opinion, such maps give a general information at the first glance, and are required. Hooman Mallahzadeh (talk) 12:10, 21 May 2024 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{Edit template-protected}} template. Primefac (talk) 11:59, 22 May 2024 (UTC)

Stopovers

Hi, for an article I am writing about American Airlines Flight 327 in 1957, I need stopover6, stopover7, and stopover8 parameters added, functioning the same as stopover0-stopover5. This flight was scheduled from Providence-Boston-New York City-Syracuse-Rochester-Detroit-Chicago-St.Louis-Springfield-Joplin-Tulsa and crashed on approach to Tulsa. Three of the stops are relevant in the article as the crew changed in Chicago and there was a maintenance issue that caused a flight delay, a second, unreported maintenance issue that may have played a part in the accident occurred in Springfield, and the final leg of the flight was between Joplin and Tulsa when it actually crashed. Thanks, RecycledPixels (talk) 17:44, 25 September 2024 (UTC)

@RecycledPixels: I resolved this a different way, by adding |stopovers= parameters that can take an arbitrarily long list of stopovers. --Ahecht (TALK
PAGE) 20:48, 25 September 2024 (UTC)

@Ahecht: Great, thank you. RecycledPixels (talk) 22:06, 25 September 2024 (UTC)

Hi. So I was wondering if there was a way to somehow "extract" or convert coordinates displayed on OpenStreetMap within the Aviation Safety Network to actual coordinates. For example, in this ASN entry, the coordinates aren't listed but at the bottom of the page, it shows the location of the crash site in OpenStreetMap. I don't exactly know if this is possible or not but it would be helpful.
Regards. Aviationwikiflight (talk) 15:41, 1 October 2024 (UTC)

Actually, nevermind, I just found a way to do it and it works. Thanks anyways. Aviationwikiflight (talk) 15:45, 1 October 2024 (UTC)

I'm not sure if this is the method you used, but in Firefox, I can right-click on the plane icon, then choose "Inspect", then in the inspection window, go down to the first <script> section and expand it. Either the "L.marker" parameter or the "setview" parameter has the the GPS coordinates in it. I've tried it on a few different ASN pages and it seems to be a reliable method. Putting this technique out here in case someone else is looking for the same answer. RecycledPixels (talk) 16:44, 1 October 2024 (UTC)

My method was to either use "View Page Source" or also use "Inspect".

From there, I searched for the source code of the map and, for example, came across this line of code: <iframe src="https://asn.flightsafety.org/statistics/geographical/kml_map_iframe_wiki.php?ll=2.313164,38.020643" height="410" width="100%" frameborder="0" scrolling="no"> </iframe> which linked the map along with the coordinates that were in the link. Aviationwikiflight (talk) 17:12, 1 October 2024 (UTC)