Weight genders in faker.person.gender()

[matthewmayer]

Clear and concise description of the problem

faker.person.gender() pulls from a list of genders at https://github.com/faker-js/faker/blob/next/src/locales/en/person/gender.ts

This is a very inclusive list, however I feel it makes the function less realistic to have all values returned with equal probability. In reality, even in fairly LGBTQ-friendly countries, the percentage of people who define as non-cis-gender is fairly low https://www.bbc.com/news/uk-64184736

Suggested solution

Now that we have faker.helpers.weightedArrayElement i think we could change this so for example it returns "Man" 45% of the time, "Woman" 45% of the time, and one of the other genders 10% of the time (divided equally between the other 73 options)

Alternative

Keep current behavior (unrealistic)
Only return Man or Woman (non-inclusive)

Additional context

No response

[Shinigami92]

-> Keep current behavior (unrealistic)

When someone already calls the method, they intend to get just some random data for e.g. testing an input like a gender free text field on Facebook or whatever platform.

It is not meant to represent realistic data neither IMO Faker is not meant to be a real world database for everything.

Implementing weight into all and everything inside Faker is a non goal to me.

[matthewmayer]

I guess it depends what you mean by "but realistic" in the tagline:

Generate massive amounts of fake (but realistic) data for testing and development.

i think in some cases like the name patterns, adding weights makes the data more realistic.

[ST-DDT]

I agree, that we should somewhat balance the genders.
However I would keep it simple and just do 90% any binary gender and 10% non-binary/any genders, hardcoded in the method and not in the data.

[ST-DDT]

Workaround:

faker.datatype.boolean({ probability }) ? faker.person.sex() : faker.person.gender()

If you are interested in this feature, please upvote it.

[github-actions]

Thank you for your feature proposal.

We marked it as "waiting for user interest" for now to gather some feedback from our community:

• If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
• If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.

We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.

We will start the implementation based on:

• the number of votes (:+1:) and comments
• the relevance for the ecosystem
• availability of alternatives and workarounds
• and the complexity of the requested feature

We do this because:

• There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
• Every feature we add to faker has "costs" associated to it:
  • initial costs: design, implementation, reviews, documentation
  • running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors

---

View more issues which are waiting for user interest