This is an exceedingly complicated subject, even among trans and queer people.
Personally I think the predefined Gender types should align with the Sex types and that is it. All other values for Gender types are custom values at that point because of the wide diversity of opinions about things.
I agree. The Genders I listed I would see as a default drop-down list but the user could add a more specific identity.
And as a user customizable list, this would not lend itself to being used to set a symbol identifier.
I could see this only working if the Gender field were to be integrated into the Name record.
But that assumes that only the standard he / she are the appropriate pronouns which is no longer the case.
Good point, those may have to be tied to birth sex. Or come up with some new symbol if it doesn’t fit the in the male/female/intersex/unknown categories.
Seems no good solution, now matter what is done some people probably won’t be happy.
That only applies as the code exists currently. With extra granularity, new pronoun composition rules can be developed by those who are motivated
enough to do so.
However, if the granularity is not made available in the core, the opportunity is suppressed.
That seems like a good starting point.
However, we could decide to break down non-binary further. The wikipedia article on non-binary gender gives the following definitions:
Third genders appear to be culturally specific and would probably be best recorded using custom types.
What do you think? Any comments?
The term “Intersex” seems to be preferred, at least by InterACT. Personally I also think it sounds better than “Non-binary” or “Other”.
Yes. “Non-binary” seems to be a gender term.
So perhaps for the Sex field we should have:
We could add the full Gedcom definition as a tooltip and in the documentation.
There’s not a clear boundary between sex and gender. A lot of non-binary folks (probably the majority of non-binary folks I know) wouldn’t say their sex is any one of those 4.
Phil.
The current sort order in the dropdown and in column displays is alphabetic by description:
female
male
unknown
Also note that the descriptions are lowercase without an initial capital letter.
Will “intersex” thus appear between “female” and “male”?
If that is not desirable, perhaps it could be “X - intersex” or “X (intersex)” instead, which also serves to hint at the underlying GEDCOM value.
Following up on this
Following up on this, Transequality has a better explanation.
That seems to support the need for two separate fields in general, and the use of “intersex” as a value for “sex” and “non-binary” as a value for “gender” in particular.
Perhaps it would help if the new functionality also included a “Display Gender Editor” similar to the current Display Name Editor in the Preferences. Just as users can currently choose how to format names based on their components and other text, so also they could choose how to format a combination of the sex and gender fields and other text.
Something like this may not be a bad idea.
The Gedcom standard for the Sex field is clear. It refers to the sex at birth, not gender identity. The values are as follows:
We can decide on a short description for use in the drop-down menu and also the order that they are listed.
We are free to decide the values for the Gender field. I have suggested:
or:
The Gender field can also allow custom values.
We are doing too much guessing. (Like… are "man’ & ‘male’ so interchangeable in the new Gender refinement? )
How about inviting input from a subject matter expert on LGBTQ+ genealogy?
For instance how about someone who was been doing presentations on the Genealogical implications for years and has a published a series of online articles about how LGBTQ+ is handled/mishandled in software.
Literally, that is bad. That proposal means you have to enter a non-binary person as having a “sex” of male, female, intersex or unknown, and all those options are going to be wrong for a large number of non-binary people. “sex” and “gender” are overlapping concepts.
For sex, male, female, other (or non-binary) and unknown so things can be exported to GEDCOM. If I had my druthers, this would be a place where I could enter whatever, but I know that makes it difficult to export/import from GEDCOM.
For Gender, a field with male, female, non-binary, unknown, and allows you enter whatever else you want. Agender and bigender are concepts that are used, but are pretty uncommon and are accommodated by it being a free-form field. Ideally a dated field like name is, which would allow people to use it if someone does consider themselves to have changed sex. (I don’t know many who do consider that, but there are some.) It would also be good if, like name, you could attach citations and notes to this field. Notes because people will probably want to explain someone’s gender expression in depth. Citations because it’s genealogy and should be sourced.
Everything I just described in the preceding paragraph can be done right now in Gramps with a dated “Gender” event with attributes, or a “Gender” attribute on a person. It’s just not formatted well, and the Place on a Gender event doesn’t make a lot of sense.
Phil.
I had to look up what Agender and Demigender mean.
I would also add Transgender to the list.
The family member I have was born Female but is now a transgendered Male. I think most of the cases we will learn about will fall into this category.
I totally agree, in terms of how they are used by most people in everyday English. (I’m not qualified to talk about other languages, and I hope our translators will step into this discussion sooner rather than later.)
I think there is general agreement on that point too, which is why people are proposing separate fields.
Although it could be awkward, perhaps labeling the proposed “sex” field as “sex at birth” would emphasize that it has nothing to do with personal choice or identity, just like the name or citizenship given to someone at birth, or the religion they may have been baptized into in infancy. True, someone may also choose to identify with those things at a later age, but then it is their choice and not simply a circumstance. Similarly, the proposed “gender” field could be labeled “gender identity”.
That could be a good solution (instead of having two fields), if some work can be done on the weaknesses that you point out, but something would still need to be done for GEDCOM import and export. Would users have to configure which values get classified as “male”, “female”, and “other”?
Thanks for pointing that out.