I would like to suggest adding a custom gender entry option. Not everyone is male or female and it would be useful. It could be like the “unknown” entry but without throwing a prompt that asks you to pick another option, and lets you just enter any text you like as the label. Preset Nonbinary, Intersex, and Other options would be good as well. The custom entries could be flagged as both male and female for the purposes of creating a “family” in the tree. Additionally, it would be good if instead of opting between the binary options when creating a family (male or all, female or all) there was a little dropdown menu where you could filter for individual gender options, for example male, female, nonbinary, intersex, other, custom, or all.
Suggestions for symbols, if needed: ⚦ (combined) ⚥ (combined 2) 
(transgender) ☿ (mercury; intersex)
Suggestions for alternate colors: Purple, yellow, green
Version 5.1.5 OS Win10
Sorry if this is done incorrectly, I’m new here. As far as I can tell this feature doesn’t exist but it has been requested before.
Yes Gramps should have a new field e.g. other in the gender drop-down menu to distinguish from unknown:
- The option unknown is for people where a researcher does not know the gender, because information is missing.
- The option other is for people where the gender does not fit to male/female.
At the moment I’d add e.g. a intersex person to my database by using the unknown option for the gender and use person attributes, so I can filter for them easily e.g. gender = other and gender_description = Intersex.
“Other” as a fourth option is a good starting point, to have something to label people other than unknown, but really ideal would be the ability to create new gender options and save them as like setting customization or being able to custom label people at all.
I too have this issue. I have a transgender son who was born female. There is no clean way to enter him properly. We really need to have all of the options available. I don’t think that using other would be right either as it just seems to sweep the issue under the carpet. I really want to show the birth as female, then the change and list him as transgender. The current field is not boolean as it has three values. Why would it be so difficult to add additional choices to it?
The issue is that historically until recently most people used the terms gender and sex interchangeably and they are distinct things.
Gender in Gramps really should be relabelled Sex, and it is the observable and documented sex as identified at birth, and it needs to be expanded to include intersex although it is only recently some countries have begun documenting such births and not lumping them into one or the other category.
Gender as in identity should then be a separate attribute maybe. Whether it is purely user defined, or we have some pre-defined enumerations with user defined custom support, would need to be determined. But then since it can change perhaps events are associated with it as well.
One would question if those two really are enough to cover things from a genetic standpoint as well. So perhaps a Biological Sex attribute is also needed.
@Nick-Hall how do you want to see this handled? Would you accept a PR against 5.2 to change the labelling from Gender to either Sex or perhaps Birth Sex to be clearer/more specific and add some new Person attribute for Gender?
I have one such case.
So far I have changed their gender to their transitioned gender. I have also added a tag to their record “Transgender FtM”. I also created a tag “Transgender MtF” for possible future use.
One of the problems is that as of right now, a record can only have one Gender setting. To give a person more than one, Gender would need to be moved onto the Name record or given their own similar multiple settings.
Keeping a single Gender entry would probably be easier to implement by just expanding the options.
Modern society seems to be agitating to retroactively redefine terms that have been in use for centuries. Usually, that’s not how scientific languages evolve. Normally they add a new variant of the term. That way, the meaning of earlier publications won’t be compromised.
But that doesn’t seem to be the direction being proposed OUTSIDE of genealogy.
Instead the CISGENDER term is being proposed as a replacement for the historical “gender” where whose gender identity corresponds to their sex assigned at birth.
And a TRANSGENDER term to fit all other cases. Where the types are likely to continue to evolve. So a Custom Type capable
So maybe Chris’ suggestion that Gramps change the existing label of “Gender” to “Sex” for the assigned sex at birth would work best. (Both for backwards compatibility in Gramps and to minimize ambiguity with what genealogy sources will list in the VAST majority of cases.)
Then use a second Custom Type Field with a few pre-defined terms. The GUI could be like the Multiple Surnames feature. Most of the time it will be utterly invisible.
What is bothersome are the edge cases. For instance, should we worry about anomalous genetic birth sexes like XXY (occurs in approximately 1 in 500-1,000 males) or XYY (occurs in approximately 1 in 1,000 males)?
And won’t we need a date range capability? Sex is assigned at birth and so has an implicit date. People will adopt a transgender Gender Identity at different points in their life. And it seems likely that some might adopt more than one Gender Identity over their lifetime.
There IS a GEPS 027: Gender as an Entry Field
Creating a meaningful way to enter all possible variations of biological sex and gender identity as well as changes during a life is difficult. Keep in mind that seemingly small changes in the user interface can require huge changes in the code/database to make everything work.
Gedcom 7 defines Sex as sex at the time of birth, and adds X for intersex. Gender in Gramps has always been the equivalent Sex in Gedcom, so renaming that to better qualify the intent seems pretty straight forward and the right thing to do.
Attributes should be used to document Gender and change in Gender over a life time. Gramps attributes currently lack a date or duration though. I just checked and Gedcom 7 finally fixes that though, so hopefully at some point the Gramps data model is refactored to enable that.
This was discussed in feature request #5730 well before the recent Gedcom 7 specification.
I think that we should add “Other” as an option to our existing field. This would enable us to conform to the Gedcom specification. We may also wish to rename the field as “Sex” rather than “Gender” and clarify that it is typically used to store the sex at birth. Many countries allow “M”, “F” or “X” on birth certificates now.
What do we want displayed on views and reports? Do we need a new field to store a preferred sex or gender, if different from the sex at birth?
Enhancing attributes to include a date range also seems like a good idea. Perhaps we could have sex and/or gender attributes?
Probably so, and meanwhile one can achieve that by attaching the attributes to an event?
Perhaps we could establish an interim standard for dated Attributes? (Or other custom Attributes that are ‘structured’, needing more than 1 value to maintain context.)
Where the name AND value are CSV lists?
So an Attribute “Transgender, Date” could have a value of “MtF, after 8 Sep 2022”
That would make some sense, to treat Sex like any other attribute. If both Sex and Gender were attributes then we might have both a sex_index and gender_index to point to the preferred ones. That would provide the most flexability as some people will distinguish between the two and others may not. Reports and views might choose to show both, or some user option could set the default of showing one over the other.
I think it depends on how we want to implement it:
- The term
othermakes sense if you have a text field where users can enter any text they want. - If we split
sexandprefered_sex, usingintersexfor the sex field is more accurate. A new fieldprefered_sexcould use an index of predefined values as @cdhorn suggested.
The advantage of (1) is more freedom for adding a gender description which fits best to what one identifies, but has the disadvantage that it very difficult use in reports/tools in any chase other than displaying the text value.
The advantage of (2) is that the distinct values are easier to use/analyze, but the disadvantage could be people complaining about more values which need to be added.
A compromise between (1) and (2) could be to allow custom entries for prefered_sex field in addition to the predefined values (similar to event_types). Only the predefined ones can be used, but the custom ones could be displayed.
Some use cases:
Current:
- sex=unknown, prefered_sex=NONE => unkown sex (If sex is unknown, prefered_sex should not be selectable)
- sex=male, prefered_sex=male => cis-male
- sex=female, prefered_sex=female => cis-female
Transgender:
- sex=male, prefered_sex=female => trans-female / male-to-female (MTF)
- sex=female, prefered_sex=male => trans-male / female-to-male (FTM)
Intersex (some):
- sex=intersex, prefered_sex=male => male intersex person (e.g. XXY, XYY, …)
- sex=interesex, prefered_sex=female => female intersex person (e.g. X, XXX, …)
- sex=intersex, prefered_sex=indetermined => intersex person where the sex is indetermined
Custom:
- sex=(male, female, intersex), prefered_sex=[custom_value] => a person who wants to use a custom description for their prefered sex.
Let’s try to avoid preferred in field names. It is a very commonly misspelled word.
Also, “preferred” is not the nomenclature that is used within the transgender community. Most don’t think of their gender as “preferred” or that they “changed gender” or “changed sex”. I strongly suggest engaging with transgender orgs for advice before making changes. This is one we want to get right.
I suggested using attributes for both Sex and Gender, but I wasn’t thinking clearly, I forget that a given attribute can not have a value that is also a type. So that won’t work for Sex which needs enumerated values. So Sex would need to stay as is, well after being renamed and adding the intersex option.
For Gender though if it was an attribute then it would be free form. And if attributes had dates, and a person changed gender over their lifetime, then you could select one and would use a gender_index to point to it the same way the birth_index in the Person object points to the primary birth record when there are more than one present.
But I am now thinking making Gender a new type and adding it to the Person object, and allowing for custom types, would be the better approach as you suggest. You could default it to Sex when creating a Person as 95% of the time they are equivalent, and then it could be changed as needed after.
That is true and understandable.
I think two fields are needed as there will be those who want the ability to distinguish just as there will be those who think they should be the same. How they are used is then a matter of personal choice.
Converting the existing Gender to be Sex (at birth), creating a new typed Gender field with a far wider array of pre-defined types and enabling custom types for it, and then continuing to use that new Gender field in reports and elsewhere instead of the Sex field, would seem to make the most sense.
It would be good to get feedback from others.
It would also be good to actually see this come to fruition soon. I see it has been over 10 years since the need was first brought up.
Another gender thread on the “Genealogy! Just Ask” group started in the last hour.
But it is leaning hard into the political correctness & touchy-feely side rather than the technical aspects.
One thing to consider is: discussing a non-binary birth sex is still fairly taboo. So if you’re concerned with the simple record keeping side, the already rare cases will be further under-reported.
The Gedcom standard gives four values for the Sex tag:
M = Male
F = Female
X = Does not fit the typical definition of only Male or only Female
U = Cannot be determined from available sources
The description given for the tag is:
“This can describe an individual’s reproductive or sexual anatomy at birth. Related con‐
cepts of gender identity or sexual preference are not currently given their own tag. Cul‐
tural or personal gender preference may be indicated using the FACT tag.”
I am happy to consider short terms to use for the “X” value. “Other” was the first that came to mind.
A new GrampsType for Gender does appear to be the best option. It would also allow for custom values. We just need to come up with a list of pre-defined values.