Gender field for FE users

Current situation

Currently, different extensions that define or use the gender field for FE users assign different meanings to different values of the field in the TCA:

Extension	Type	no gender set	male	female	diverse	code
sr_feuser_register	self-registration	99	0	1	(not available)	https://codeberg.org/sjbr/sr-feuser-register/src/branch/master/Resources/Private/Language/locallang_db.xlf#L66
femanager	self-registration	99	0	1	2	https://github.com/in2code-de/femanager/blob/v7/Resources/Private/Language/locallang_db.xlf#L36
sf_register	self-registration	(not available)	1	2	(3)	https://github.com/evoWeb/sf_register/blob/develop/Resources/Private/Language/locallang.xlf#L18
feuserextrafields	field provider	99	0	1	2	https://github.com/oliverklee/ext-feuserextrafields/blob/main/Resources/Private/Language/locallang.xlf#L15
onetimeaccount	self-registration	99	0	1	2	https://github.com/oliverklee/ext-onetimeaccount/blob/main/Resources/Private/Language/locallang.xlf#L36

Why these extensions affect each other

Self-registration extensions that define additional FE user fields are "providers" for these fields. They are usually used in combination with other "consuming" extensions (e.g., the seminars extension that has a CSV export for event registrations) that rely on the values of these fields having special meanings.

Problems with the current situation

• If a site switches from one self-registration extension to another, the existing users might get an unwanted gender change (at least in the backend).
• "Consuming" extensions that rely on the gender value schema can only work in conjunction with certain self-registration extensions, but not with others.
• If the default value for the gender field in the BE is something other than "no gender set", FE users might have the incorrect gender set.
• According to a German court decision, persons need to be able to provide "diverse" as their gender.

Proposed solution

Why have a gender field in the first place?

Nowadays, forms should try to avoid having a gender field and use a salutation field instead (or none at all).

However, there are cases (mostly for API usage) where providing a gender for users still is required. For those cases, we need a machine-readable, interoperable gender field.

Criteria for a proposed solution

1. Provide a "no gender set" value and make it the default.
2. Provide a "diverse" gender value.
3. The new values must not overlap with the old values so that upgrade wizards can clearly recognized whether an FE user record has already been migrated, has not been migrated yet, or has been newly created.
4. The new values must not be language-specific in order to allow conversion for APIs and in order to allow localized output.
5. The values should be the same across as many extensions as possible.

Proposed values

Switch the gender field from an integer to a string (so that the intuitive default value for that type can mean "no gender provided") and use these values:

value	meaning
empty string	no gender provided
f	female
m	male
d	diverse

How to ensure consistency between the extensions

I see these possible approaches:

• add the field to the Core (for V13 and up) - this would technically enforce this
• use the feuserextrafields extension as the "one source of truth" for the gender field and add it as a dependency to the other extensions
• have an agreement (between the extension authors), but do not enforce the values technically

Upgrade wizards

1. check if there are any users with an numeric gender value 0, 1, 2 or 99.
2. if so, convert only those according to the table

These wizards should be repeatable.

If the field gets added to the core, the upgrade wizard should only be active in V13 installations, not in V11 or V12.