' +
'' +
- // "otherFirst" (the already-existing person is the parent/minister side) is
- // listed first and pre-selected, since the usual workflow here is building a
- // tree top-down - the ancestor/senior side already exists, and this new person
- // being created is their child/subordinate. Defaulting to "newFirst" instead
- // silently assumed the opposite and was an easy, hard-to-notice way to enter a
- // relation backwards (e.g. recording a son as his own father's parent).
+ // "otherFirst" (the already-existing person is the parent side) is listed first
+ // and pre-selected, since a row starts out on the "family" kind and the usual
+ // workflow there is building a tree top-down - the ancestor/senior side already
+ // exists, and this new person being created is their child. Defaulting to
+ // "newFirst" instead silently assumed the opposite and was an easy, hard-to-notice
+ // way to enter a relation backwards (e.g. recording a son as his own father's
+ // parent). Non-family affiliations default the other way around - see
+ // togglePersonRelativeKind(), which flips this select's value on kind change.
'