faker
faker copied to clipboard
Change file structure for gendered lists (names, prefixes etc)
Originally posted by @ST-DDT in https://github.com/faker-js/faker/issues/547#issuecomment-1240937734
Change data-structure:
name.female_first_name ->person.first_name.female
Example:
type Gendered = {
female: string[]
male: string[]
generic: string[]
};
Also noting that the first names for the following languages are not split by gender currently, someone with better knowledge could check these:
~de_CH~ ~es_MX~ ka_GE ~ko~ ~ne~ ~zh_TW~
Also noting that the first names for the following languages are not split by gender currently, someone with better knowledge could check these:
de_CH es_MX ge ko ne zh_TW
For now I would say put them in person.first_name.generic (?) or person.first_name.index (?)
So with this change they are not anymore in the file but the folder
I prefer generic over index. (Could you explain why you suggested index? I'm unable to guess your reasons/thoughts here.)
It would be great to make a list of contributors (even if they are not that regular) who know various languages so we can ask their help for locale specific issues. So if say there's an issue with Korean we can loop them in.
I prefer generic over index. (Could you explain why you suggested index? I'm unable to guess your reasons/thoughts here.)
No I cannot => use generic
@Stichoza it looks like you originally added the data for Georgian, i wondered if you might be able to help us split the https://github.com/faker-js/faker/blob/next/src/locales/ge/person/first_name.ts file into male and female? This will help the ge locale work correctly.
https://github.com/faker-js/faker/commits?author=Stichoza
I think this will also require changes to faker.helpers.fake to get it to work with patterns like {{person.first_name}}?
No, it doesnt or at least we wont implement it that way. Instead we will change the patterns accordingly.e.g. person.first_name.generic/...
But thanks anyway, this is a good reminder for the actual implementation since we didnt write that anywhere.
i think there might be some logic in deferring this until 8.1. It's a fairly large change which will affect a lot of patterns and tests, but shouldnt have breaking changes (if implemented sensibly) and stuffing too much into 8.0 will delay and delay it.
Team Decision
We don't need this for v8.0. (We will likely immediately start with v9 after v8.0)
I don't feel this is essential for V9
I don't feel this is essential for V9
It's not essential, but we kicked this issue since pre v7. Since this would be breaking, we wanted to still include this in the next major.