entries with callsigns that are identical except for presence or absence of 'Team' really belong to the same team

[caver456]

Seems like previous work was done along these lines, but, wasn't able to find the right issue to reopen - so, making a new issue here.

'Bravo' and 'Team Bravo' result in two different tabs. '102' and 'Team 102' (though you have to take steps to make '102' be accepted) result in two different tabs.

Noticed during work for #560.

[caver456]

[caver456]

After adding 'Team 102' by normal means:

064251:extTeamNameList after sort:['z_Team00102', 'spacer1', 'z_Bravo', 'z_Team Bravo']

We know we want just one extTeamNameList entry for Bravo, instead of two. Changing getExtTeamName should do the trick. Should it be z_Bravo or z_TeamBravo? (Probably shouldn't have a space!)

We don't want extTeamNames like 'TeamRelay' or 'TeamTransport'. We don't want to automatically prepend 'Team' for everything.

[caver456]

Currently (with an uncommitted fix to remove spaces even when there are no numbers), getExtTeamName doesn't create a prefix - it will expand the shorthand prefix 't' into 'team' but that's all. The prepending of 'Team' is done in the NED teamField callback when the entered value is only digits.

                 123 --> z_00123
                t123 --> z_Team00123
               Bravo --> z_Bravo
          Team Bravo --> z_TeamBravo
               Relay --> z_Relay
           Transport --> z_Transport

So, in that sense, it would be cleanest to keep the prefix-creation functionality all in one place - in the NED teamField callback. To do this, it seems like we'd need to keep a list of valid names, i.e. 'what values should be prepended with 'Team '?

[caver456]

This doesn't address the question of whether or not to prepend 'Team', but, see recent deep dive discussion of getExtTeamName here.

z prefix was not originally intended for everything, but, by precedent and for consistency, the plan is to keep z as a prefix for everything.