Search Forums
Forums
Kiwitrees on Twitter
    Tags

    Fancy imagebar, 3.0.0. setup, nickname, 3.1.1, fatal error, prison, xmas, family facts, family navigator, cousin tab, getClientIp, edit, merge, html, notes, mysql5.7, reports, time, locked out, library, calendar.php issue, husband, footer, blocks, validation, googlemaps, contacts, index, webtrees 1.4.4.1, css, spouse, 3.0.0, folder, REFN, Google Maps, lists, mystyle, dead, duplicates, session, googlemap, individual resource, logs, spam, stories, 2.0.2, request, 3.2.3, places, simpl_pages, future, road map, seo, title, image, 2.0, HTML block, Support/Bug Reporting, message contactform, widget

    Tagged: 

    Topic:   Gender change  

    This topic contains 2 replies, has 2 voices, and was last updated by macalter macalter 6 months, 2 weeks ago.

    Viewing 3 posts - 1 through 3 (of 3 total)
    • Author
      Posts
    • #7569
      macalter
      macalter
      Participant

      536 posts

      Question arose in the Reunion forum I subscribe to and made me wonder: I’ll use former Bruce Jenner as example (not following exact coding). If I recall, TYPE is free form therefore I could use this to indicate the gender change (finding politically correct term of course). Bruce to Caitlin is public knowledge but extreme care would be needed for actual situation to respect privacy/knowledge of the change.

      1 NAME Caitlin Jenner
      2 TYPE ?????
      1 SEX Female
      1 NAME Bruce Jenner
      2 TYPE birth
      1 SEX Male

      -----
      Kiwitrees:
      "A-D connections 3.3.0 (rev)"
      PHP 5.6.29 Fast CGI

      "The Royals 3.3.0.."
      PHP 7.0 Fast CGI
      mySQL server: 5.1.56
      MacOS: 10.11.6  (El Capitan)
      Browsers (mac): Safari  Version 10.1.1 (11603.2.5);  Firefox 53.0.2
      [updated: 22 May 2017]

      #7570
      kiwi
      kiwi
      Keymaster

      1443 posts

      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

      #7571
      macalter
      macalter
      Participant

      536 posts

      Will be interesting over time how this does play out. Especially given that legal recognition isn’t law in all countries. Being introduced to Caitlin Jenner doesn’t mean I know by birth she was Bruce Jenner hence would miss a lot of records. Oh what mysteries being created for future genealogists.

      I understand the general policy within genealogy is using birth name forever, but legally the person is given new identity (name & gender) where law permits. If it was a question of transgender, then birth name/gender would be used. Will pose it to some people one day (in the LGBTQ community) and see how they respond.

      -----
      Kiwitrees:
      "A-D connections 3.3.0 (rev)"
      PHP 5.6.29 Fast CGI

      "The Royals 3.3.0.."
      PHP 7.0 Fast CGI
      mySQL server: 5.1.56
      MacOS: 10.11.6  (El Capitan)
      Browsers (mac): Safari  Version 10.1.1 (11603.2.5);  Firefox 53.0.2
      [updated: 22 May 2017]

    Viewing 3 posts - 1 through 3 (of 3 total)

    You must be logged in to reply to this topic.