Reply

Hi

Yes, that is one of a number of increasingly more frequently requested entries. Many like this one are simple conceptually, but get more complex the further you think through the issues.

Technically your answer is fine, and yes, TYPE “should” be free-form according to GEDCOM specs. But from a coding perspective there are problems. Free-form text anywhere in the system can’t be translated, and we get more requests to translate these than we do for it to be free form. It also makes it more likely your data would end up with all sorts of variations (“gender change”, “change gender”, “gender reassignment”, etc.). So a long time ago it became a drop-down select list of fixed terms. You can still edit the raw data to add a free form entry though.
So there are two choices in the existing code:

1. Use one of the current choices (“change of name” ?) and a NOTE for further explanation
2. Ask for a new TYPE to be added. Within reason I wouldn’t object, though a list of 20+ might be a hassle.

That takes care of the name change.

Your two SEX entries are OK. Though perhaps a NOTE added to the second as explanation might be useful. However this is all currently a raw data edit. There is no GUI option to add a second gender.

Then you might want to add a custom EVENt so that a date (and even place?) can be included and the event shown in the list of facts & events. In this case the EVEN and it’s TYPE ARE free-form, so again you do have the issue of translation and to some extent also issues of different entries for the same TYPE. However at least here the TYPE field has auto-complete, so you would be prompted by a list of pre-existing terms in your data.

The final issue is choosing which name, which gender (and hence the colour of various chart boxes) etc. to use all over the system. At present we use the standard GEDCOM rules for indicating use-preference – where there are two entries (same tag) at the same level (e.g. two “1 NAME ……” entries) then the first shown in the GEDCOM data is the “main” one used in most charts, lists, etc. The same applies to SEX, BIRT, etc.. Pretty much anything where you have two versions of the “same” data. Again, changing this generally requires manually adjusting the positioning within the raw data edit screen.
The general policy within genealogy is that all references to individuals is based on their birth situation, so their primary family is their birth parents (not adopted, foster etc; their primary name is the one given at birth (not married name, changed name, etc). The same would presumably apply to gender. So Bruce would for ever be displayed primarily as Bruce and male; but I can imagine many people preferring to be displayed with their current situation.
I guess one advantage of the current manual re-ordering is that it’s relatively easy to change the display to suit each individual preference where it matters. The alternative would be to use a custom sub-tag (“_PREF” perhaps) for all / most tags. But apart from a huge job to implement, would give users more data entry, and maintenance. I believe some software does use this, but of course such tags don’t transfer well between platforms.

Nigel
My personal kiwitrees site is www.our-families.info