Genderization! Gender support for translations.

[amdad]

It's really needed. Without it in my language forum speaks to users like sport commentator, talking to them about what's going on on forum as spectator ;). In 3rd person. Any direct speaking to user is impossible in straight way.

So I suggest extension should have option to enable in forum to REQUIRE from user choosing Man/Woman in account settings. Prompt modal window on first login,

We should be able to use male/female node/form to override/extend ANY YAML's string.

[dcsjapan]

Ahah, I didn't see what you were getting at when you brought this up the forums. Now I understand!

Allow me to jot down a few things that will need to be considered:

Where should it go?

This reminds me of the need for "name pronunciation" profile fields to allow proper sorting of Japanese names. That's a clear case of something that belongs in the language pack extension. Gender is a much more common phenomena, so there may be a case for bundling it as a default extension.

Use for other purposes

If it is bundled, then some admins may want to use the gender profile fields as a way for users to show their gender, even if they're not using a language where gender is an issue. In such cases, the profile field would have to include an "Unspecified" option for those users who'd rather not say.

Mandatory gender selection

As @amdad suggests, forums would need some way to prompt users to specify their gender. A modal that offers a choice of buttons on first login would be one way to handle it, but it may not be necessary to go that far. (And it wouldn't be necessary in situations where grammatical gender isn't important.)

As an alternative, could be handled as part of the new user welcome process. The welcome banner displays a link to a page (or sticky thread) on forum policies. There, the user finds an explanation of how to open the Settings page and set his/her gender. In the meantime, the forum uses a default setting.

... It might be nice if the extension included a configuration setting so admins could specify the default gender for their forum. (So a forum oriented specifically toward women could use the female gender as the default, for example.)

[amdad]

Most common think on the world is gender, so I think no other like, it MUST be a core extension. Even if disabled by default. Still should be shipped. Just because of language need it. Unless my language is only one who needs it. Then ok, exception don't need to be in core.

1. Option to REQUIRE from user for choosing it's gender after first login.
   • Modal popup just for that,
   • or showing this option in place of top banner that cannot be hidden without user choice,
   • else redirection to user profile which cannot be saved without defining user gender.
2. Admin should have options to enable or disable completely "Unspecified" option. Because as we can require user to make choice, admin should decide if require to choose always between male/female or male/female/unspecified. I like this "unspecified" word rather of "not tell", just from psychological perspective. Some users will more likely avoid "unspecified" (because of their convenience of yourself) when in compare "not tell" will point user to: "Oh, if I can hide something from public (more anonymous!) why not".
3. Optionally as @dcsjapan suggest in gender extension admin should choose which form of language should be used by default. If forum is only or mostly for men/women. When requiring to choose is not important. So admin can left it in just in profile as option. or even turn off those profile option. When forum is 100% oriented on one gender only.

[franzliedke]

The additional complexity that we would have to introduce by forcing users to select their gender is something I would not want to support; especially given how much it complicates localization.

@amdad Is there absolutely no way to address the user in a gender-neutral way? How is it done when you get advertisement letters where the sender don't know whether you're male or female?

[amdad]

I wrote nothing is "required" - everything is optional for site admin to choose if we require to choose from user, or if we just suggest him to choose. And then, choose between what: male/famale or maybe want to stay as undefined. Totally freedom. Site admin should decide what is required, and if Gender extension will be even enabled or not. I suggest it should be in the core but by default disabled. Since not many languages require it. Still it's very useful plugin for all sites to use. Because, it add some most basic info on the world about person. So why not in core? If not in core, no problem. It can be installed separately. But should have power to use those special Yaml's strings crafted in localization files for that matter.

You have pluralization, you have strings that allow different ordering words in phrase, Even drop punctuate() function because some languages don't use it https://github.com/flarum/core/issues/527#issuecomment-141848163.

No, it is not possible to speak neutral to people in my case. Verb always pointing person gender. Only in exceptions like "Someone replied to your message" you use by 'default' male form, because you don't know who is "someone",

I already translated Flarum by using "neutral" but incorrect form. Instead of using Simple Past I used Past Continuous. Because I cannot said "He replied", "She replied". I use "He replying", "She replying", as sport spectator. Anyway, that's incorrect.

In advertisement letters you can say sometimes directly by YOU. Like "You'll buy", "Your choice". But in case you want to be more formal. You just using "Welcome mr/mrs!" And so on.. Just placing 2 full forms separated by slash. Or just different endings of verb. But it's not cool anyway.

When sender is know if receiver is male or female sending two different forms of letter. Even in advertisement. So Franz, you want Flarum to be worse than SPAM? :stuck_out_tongue:

[amdad]

Oh.. DAMN! I thought, I lost this first message because accidentally close tab. So read it twice. Ough.

If it still not clear here you go:

Hey, who said FORCING? I meant Option for admin to require it or not. Because some sites want suggesting (push) user to decide, and some of them require from user to decide. I gave you few scenarios here. Only in just one of them admin can decide if user must choose. And if must choose, even then he is not required to choose between man/woman but can choose undefined.

I already translate Flarum without using direct gender oriented messages. But it is really weird way of speaking here. Extension will not harm any way languages that don't need it. You just don't enable it or (if it will not core) don't install it at all. Just extend possibilities for those languages who want to use it. What's problem with that?

In natural way I must say like this:

User posting... User replying... User removing... User ...ing. All the time. So all of it is in

I cannot use just normal verb User posted, User replied, User removed. Cannot say, "She replied" or "He replied" because there is another form of verb according to gender. There is even third for of verb if you taking about child! :) But here we don't need it. Since, child also have own gender.

So it's not correct to use Past Continuous form of verb where should be Simple Past,

So we just in verb form give you information what gender is person we speak about. And understand this. Forum is much more informative that way, because you instantly know that this User is woman or male. From user experience is +1. People feel treated better way, more individual by software. From years, it was just crappy done in forums. We just added alternative form or ending of form after slash. That sucks. In advertisement letters too, but in this type of you can say directly YOU and then you skip problem of gender. For example "Someone replied to your message" is correct in male form. Just because we don't know who this person is. But for example We cannot say the same about woman. Like "Anna replied to your message". We need to use different ending of verb 'replied', because "default" form pointing that Anna is male.

I hope you understand now. You have {placeholders} in Yaml's because different languages have different orders of phrase. You have pluralization for the same reason. Without it, local grammar is violated. And the exactly the same issue is with gender.

[amdad]

Feature is pull off from stable release. But I hope it will be done after? This "needs discussion" tag make me nervous a little bit ;)

[dcsjapan]

"Needs discussion" simply means the devs need to discuss how to implement it.

[amdad]

That's good info! Thx

[franzliedke]

Honestly, in this case I added the label because we need to discuss whether/how we want to implement this at all. Because there is lots of complexity involved (language files; dealing with the setting in user profile; we'd still need a neutral variant for all strings if no gender is configured).

:christmas_tree: :christmas_tree: :christmas_tree:

[amdad]

Franz, please treat gender specific translation as optional. As additional strings under general translation strings.

As I see, first of all in stable there will be no gender support. And it's not a problem since stable release have enough problems to solve. So this is answer to your question. Basic Flarum will speak.

Real example from older Flarum lang file:

In locale/core.php

return [
    'plural' => function ($count) {
        if ($count == 1) {
            return 'one';
        }
        else if ($count > 1 AND $count < 5) {
            return 'two';
        }
        else {
            return 'other';
        }
    }
];

The same we should be able to do for genders:

    post_stream:
      added_tags_text: "{username} added the {tagsAdded}."
         male: "{username} 'he_added' the {tagsAdded}."
         female: "{username} 'sheadded' the {tagsAdded}."

In core result it will be like:

      do_something: 
           one: "{username} did something"
                 male:  "{username} 'hedid' something"
                 female:  "{username} 'shedid' something"
           two: "{username} 'bothdid'_ something"
                 male:  "{username} 'twomalesdid' something"
                 female:  "{username} 'twowomansdid' something"
           other: "{username} 'manydid' something"

So, if gender extension is not exist or not enabled. Also if gender specific strings are not included in lang file there will be no problem at all.

But if languages like mine need it then, Gender plugin can be enabled. And sub strings will be used. So it doesn't affect/hurt any of you at all who doesn't need it.

Even for people who don't want to split community with gender choice, for some reason. Forum will speak in gender neutral way. Ignoring additional strings. Or if we let user decide. MALE / FAMALE / INCOGNITO then also global phrases will be used.

This is important as I said many times in this topic https://discuss.flarum.org/d/164-proposal-translation/17 . Because there are RULES in language that cannot be broken. Not all languages are simple.

[amdad]

Franz, I fight fot this matter from two years man. And was told this will be implemented this way or a not her. And you kick the doors and... SURPRISE MOTHER FURTHER!^#%!

[franzliedke]

I don't understand what this is about.

I've said I am not too happy about supporting this additional complexity in core. But as you can see, we haven't made a decision here, either.

[amdad]

I didn't ask it for 'Core' support. Only by extension. But official one. Lang file is made by authors. And if they ignore extending it for additional strings it's like it didn't exist. Only for those who need it. It is such a simple thing to do, and pros are giant.

[amdad]

From Gitter:

Dominion @dcsjapan sep 21 2015 22:42 Now: please believe me when I say that we understand the need for genderization. I studied French in high school and majored in linguistics in college. Franz is German, a language with three genders. So even though we may not know much Polish, we understand well how important gender can be.

What we're talking about now is how to best implement gender, not whether it should be implemented. There's a big difference there. At any rate, the issue tracker is not the best place for long discussions. It is a place for programmers to note down what needs to be done (or discussed), and is not really designed for hashing out the details at great length. If you feel a subject needs more discussion, the best thing to do would be to create a topic in the forums (or use an existing one if it exists) and drop a link to it in the issue tracker. reate a topic in the forums (or use an existing one if it exists) and drop a link to it in the issue tracker.

If you feel a subject needs more discussion, the best thing to do would be to create a topic in the forums (or use an existing one if it exists) and drop a link to it in the issue tracker.

[amdad]

Something like example above from forum/extensions/langpack/locale/core.php

return [
    'genderize' => function ($gender) {
        if ($gender == male) {
            return 'male';
        }
    else if ($gender == famale ) {
            return 'female';
        }
        else {
            return 'default';
        }
    }
];

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum. In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

[amdad]

So... I'm refreshing topic.

[tankerkiller125]

Do any other forums software support genderized translations? I have yet to see one that does. Generally speaking they tend to stick with "neutral" translations or default gender translations regardless of user genders.

[jtojnar]

Some languages are inherently gendered and trying to make the phrases “neutral” just make them sound weird. (Speaking from experience as long-time Czech software translator. And Czech is still one of the more flexible languages on this matter.)

If some software does not support this, it is likely for technical reasons. But we should not cop out of user experience improvements just because other software is not particularly user friendly. These days, there are solutions (e.g. Mozilla’s Fluent) allowing to implement this rather easily.

[amdad]

Über language!

[franzliedke]

These days, there are solutions (e.g. Mozilla’s Fluent) allowing to implement this rather easily.

Fluent is super-cool! :+1: I've liked that ever since I discovered it. It takes some things that we already do (like referencing translation keys in other translations) and takes it to a very good extreme, in my eyes.

May be worth switching to it at some point. But first ... stable!

[bryantmilan]

Hi, I just found this topic thanks to clarkwinkelmann. Below I will put the post I wrote in one discussion on Flarums forum to see what my problem is. I see that a solution has been found with Mozilla Fluent, at first glance it looks like the right solution and I think it should be inserted, it should not be a priority, but it would be great!

My post from Flarums forum: "Well, I found one small issue while I was translating from english to serbian language. In the serbian language, we have a difference between the masculine and the feminine. In fact, some words do not have the same ending depending on gender. Here's an example to better understand:

For the masculine:

English: John started the discussion a few seconds ago. Serbian: John je započeo diskusiju pre nekoliko sekundi.

For the feminine:

English: Barbara started the discussion a few seconds ago. Serbian: Barbara je započela diskusiju pre nekoliko sekundi.

As you can see there is a difference between the words "započeo" and "započela". When I was translating from english to serbian I had to use the universal word "započeo/la" so users could use correct form of the word depending of the situation. It would be great if during registration users could choose what gender they are, whether they are male or female. The translation would be adjusted accordingly. This would make the translation much more meaningful and make it easier for users to use and read on forum. I am not an expert in literature and grammar, but I think this does not only apply to the serbian language but to all the languages of the former Yugoslavia and I think it also applies to the russian language, but I do not want to speak on their behalf. This isn’t such a big deal, but it would be great to have."

[amdad]

There is a reason why in Fluent third and last example is Polish. I told you ;) Słowianie (eng. Slavs or I would say Slavians) means exactly Wordians. We're masters of this craft :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum. In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum. In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

[Wadera]

+1

[askvortsov1]

There are 2 parts to this issue:

1. Supporting genderization in translation formats.
2. Providing gender to the translations.

With Symfony 5, transChoice, the system we currently use for pluralization, was dropped. It looks like we missed this, as that now non-existent method is now called in Flarum's translator. Not ideal, as this means that pluralization in translations is now broken.

Symfony has decided to switch to the ICU MessageFormat standard. Among other benefits, it's a more dynamic format that supports genderization. I think that instead of re-implementing transChoice, it would make sense to follow that decision. This entails several changes:

• All currently pluralized translations would need to be updated for the new format. This would be significantly more verbose, but as mentioned, a lot more flexible.
• Translation files would need to be renamed to have the +intl-icu suffix. Alternatively, maybe core should treat all files as having this suffix?
• The JS translator would need to be rewritten to support MessageFormat. On the bright side, since MessageFormat is relatively standard, tools like https://www.npmjs.com/package/@ultraq/icu-message-formatter (6kb minified) mean that we'd be getting rid of a lot of custom logic. That's a fair bit more maintainable.
• All code currently using transChoice would need to switch back to trans.

These would be breaking changes, but I think they would be worth it for the long term.

While we're at it, we might as well try to add infrastructure for supporting genderization in core in the future. My proposal:

• Add a gender method to User that currently returns a hardcoded value, maybe "default" or "neutral" or "other". Maybe we should have consts somewhere that establish "male", "female", and "neutral" as the options to be used in translation files? Otherwise, if we leave that bit completely to extensions, we might get inconsistencies.
• Pass that value via BasicUserSerializer.
• Add a gender attribute to the frontend User model
• Start using that gender attribute in translations. Via core, this would still make everything gender-neutral.
• In a future release, introduce "Gender driver" support (and an extender), allowing extensions to implement a UIs and management for user genders.

[askvortsov1]

Quick question @rob006 @amdad @Wadera, as I'm far from an expert in linguistics. Even if we relegate the gender selection / driver UI to extensions, we'd still need to provide user genders to translator.trans() calls in core and extension code. I know this is needed for 3rd person, but should genders also be provided when talking about someone in the first person?

Especially if so (but even without this requirement), there'd be a lot of code modifications necessary. I've been thinking about scalable ways to do this, and have an idea: we could introduce "magic variables" for user arguments to translations. This could work as follows:

Arguments are currently provided to trans as a map of string keys to string values (or HTML values for JS, but that's irrelevant to this). What if we also supported passing User model instances as values? In that case, the translator would automatically create new string arguments USER_KEY.display_name and USER_KEY.gender. That way, extensions and core code wouldn't need to explicitly provide the gender every time. Furthermore, it would increase consistency significantly: otherwise, we'd get some instances using gender_of_user, others user_gender, and yet others user.gender, and so on.

So, the arguments:

{
    count: 5,
    points: 100000,
    user: "admin"
}

would be unchanged. But the arguments:

{
    count: 5,
    points: 100000,
    user: SOME_USER_OBJECT
}

would be turned into:

{
    count: 5,
    points: 100000,
    user.display_name: THE_USERS_DISPLAY_NAME,
    user.gender: THE_USERS_GENDER
}

And that transformation would be based on checking the type of all arguments to see whether it's an instance of User (for both the JS and PHP models).

This would also standardize format of arguments for display names, which is a bonus IMO.

[clarkwinkelmann]

@askvortsov1 What if we also supported passing User model instances as values? In that case, the translator would automatically create new string arguments USER_KEY.display_name and USER_KEY.gender

We actually already kind of do that. If you pass a user property, it fills the username attribute. The comment even references the future ability to customize gender

https://github.com/flarum/core/blob/12f6b1b3750a0e04286a1535dab8074046413218/js/src/common/Translator.js#L53-L62

I'm personally unsure this really needs to be supported by core itself and could well be an extension, either first party of community.

If instead of transforming user to username, we transformed {any}: User to {any}_username and put that logic into a method that can be monkey-patched by extensions, an extension could easily set its {any}_gender value to whatever, and it would work for both the "subject" and "target" of translations that reference multiple users.

Something similar should be done in the backend to allow extension to manipulate parameters to the translator to allow for the same user-to-username/gender mapping. There probably aren't many use cases for gender in API translations but that will be very important for email.

I feel like if we allowed extensions to plug into the translator like that, and that we publicly define how the gender key should be called in translations so that all translators use a compatible syntax, we should be good.

For an extension that would implement gender, most of the work would likely be around the settings/prompts and storage of the value. Hooking into the translator would be just a few lines of code for both JS and PHP, so I don't feel like it's worth a whole extender set that we would need to maintain.

EDIT: The biggest change for us would be to actually pass the user to almost all translations, because it will need to be available even when the username isn't shown. Maybe we could automatically inject app.session.user as the user if no other parameter has been passed as to not make the use of the translator too verbose.

[askvortsov1]

We actually already kind of do that. If you pass a user property, it fills the username attribute. The comment even references the future ability to customize gender

Ah, that I didn't know. The problem (IMO) is that this only works for one argument, and that argument must be named user. What if we needed to refer to multiple users in the third person in the same translation?

[clarkwinkelmann]

and that argument must be named user

That's why I suggested checking for any attribute with instanceof User and adding attributes with the same prefix. I think that's also the exact same thing you were describing in your own comment.

So in the end it doesn't really matter what we already have because we would have to change it anyway :hear_no_evil: But I just wanted to point out we already do dynamic translation attributes.

[askvortsov1]

Maybe we could automatically inject app.session.user as the user if no other parameter has been passed as to not make the use of the translator too verbose.

I like this idea

I checked with MessageFormat, and if no argument is provided, it defaults to other, which is exactly what we want it to do. So translations can have gender support even if core doesn't support it, and no genderization extensions are defined.

For actual implementation, an extension could override the translator container binding. This would leave core gender-free, which is nicer, as all the relevant code would be in the extension.

[rob006]

Quick question @rob006 @amdad @Wadera, as I'm far from an expert in linguistics. Even if we relegate the gender selection / driver UI to extensions, we'd still need to provide user genders to translator.trans() calls in core and extension code. I know this is needed for 3rd person, but should genders also be provided when talking about someone in the first person?

In Polish you basically always need gender, no matter if this is for 1st, 2nd or 3rd person.

Also I don't like the idea of moving this responsibility to extension, especially if it will be community extension. This is something that will affect all extensions and will have big impact on translations in many languages, it should have well defined list of genders and it may require some additional logic, especially for plural forms.

In Polish phrase "X and Y liked this" will be translated differently depending on whether X and/or Y is a male. We have "only" 2 forms in this case - if group has at least one male, male form is used, in other case non-male form is used. But other languages may have different rules, so you may need handle this as 3 cases: all male, all female, mixed. And it may escalate quickly if you will want to handle more genders, like neutral. And there is also default state, which may need to be treated differently depending on language - in Polish we have neutral form, but it may be treated as offensive, so I wouldn't want to automatically assign neutral gender for all users that does not set it manually.

[askvortsov1]

This is something that will affect all extensions and will have big impact on translations in many languages, it should have well defined list of genders and it may require some additional logic, especially for plural forms.

This is true, but if we define the list of genders as "male", "female", "other":

• Extensions will know to use those particular options
• Translators will know to use those particular options
• The MessageFormat standard will default to the other option if no gender is provided. This would match current behavior, so if the gender extension isn't installed, it would display like it does now. You can test this out at https://format-message.github.io/icu-message-format-for-translators/editor.html. We don't even need to limit it to "male", "female", "other": translations could include other options, as could the extension.

What do you mean by "additional logic for plural forms"? MessageFormat handles combinations of numbers and "selects" quite well. Furthermore, the "gender" option is actually just a generic select, so it could handle deeper combinations than just gender and plurality. It's really quite powerful :grin:

but it may be treated as offensive, so I wouldn't want to automatically assign neutral gender for all users that does not set it manually

But that's the current state of Flarum. An alternative would require prompting users for gender in core, which doesn't really align with the minimalism philosophy. What I proposed initially a few posts above would include very, very minimal stubs for gender in core, but that would still default everyone to "other". Keeping all that in extension land would avoid imposing core's structure on the actual implementing extension, allowing more flexibility.

[rob006]

What do you mean by "additional logic for plural forms"? MessageFormat handles combinations of numbers and "selects" quite well. Furthermore, the "gender" option is actually just a generic select, so it could handle deeper combinations than just gender and plurality. It's really quite powerful grin

I gave an example in previous comment. Assuming that you have phrase "X and Y liked your post", and you have language that have different forms for 3 cases:

1. X and Y are male.
2. X and Y are female.
3. X is male and Y i female.

How would you handle this using ICU syntax with generic select, when you have only separate genders as X_gender and Y_gender? And how it would scale if you have 3 persons and 3 genders?

What I proposed initially a few posts above would include very, very minimal stubs for gender in core, but that would still default everyone to "other".

And that would make it useless for Polish. We have separate form for neutral gender, but using it as default is no-go. I would need to treat "other" as male, because while it is incorrect, it is more practical default. "unknown" should not be treated the same as "other", this is not the same.

And if you want to ignore all this complexity, then at least allow language pack to preprocess gender of user / list of users before it will be passed to ICU message formatter. Language pack maintainers will have more flexibility if they could do this in PHP (they can treat 'default'/null differently than 'other') and it will simplify handling plural forms (it is super easy to select form in Polish if I could just iterate trough list of users in PHP, but I have not idea how reliably handle this if I would have 3 users and 3 genders). AFAIK it works in that way in gettext for plural forms - gettext does not have internal knowledge about pluralization rules, they're included in po/mo files.

[askvortsov1]

How would you handle this using ICU syntax with generic select, when you have only separate genders as X_gender and Y_gender?

{ user1.gender, select,
 male {{
    user2.gender, select,
      male {X and Y are male}
      female {X is male, Y is female}
      other {X is male, Y is other}
  }}
 female {{
    user2.gender, select,
      male {X is female, Y is male}
      female {X and Y are female}
      other {X is female, Y is other}
  }}
  other {{
    user2.gender, select,
      male {X is other, Y is male}
      female {X is other, Y is female}
      other {X and Y are other}
  }}
}

Try it on https://format-message.github.io/icu-message-format-for-translators/editor.html

And how it would scale if you have 3 persons and 3 genders?

Poorly, as would any other solution, But it would scale, these can be infinitely nested. I don't think I've seen examples with 3 users like that though.

And that would make it useless for Polish. We have separate form for neutral gender, but using it as default is no-go. I would need to treat "other" as male, because while it is incorrect, it is more practical default. "unknown" should not be treated the same as "other", this is not the same.

As ICU MessageFormat requires other to be the "default" option, the genderization extension could select alternative wording for nonbinary genders. For example, nonbinary or neutral. Because genders could be anything, this system could expand to support a potentially infinite list of "gender keys".

then at least allow language pack to preprocess gender of user / list of users before it will be passed to ICU message formatter

The genderization extension could include extenders and frontend hooks / util methods allowing language packs to add custom code. After all, language packs are extensions, and can use all the APIs available to extensions.

[rob006]

Poorly, as would any other solution, But it would scale, these can be infinitely nested. I don't think I've seen examples with 3 users like that though.

First, by "scale" I didn't mean "it is possible" but it "is relatively convenient to use". Your example would have almost 30 combinations with 3 users.

Second, I think that approach with gender "preprocessor" will scale much better. For Polish preprocessor for users group would look like (declared once in language pack):

static function (array $users): string {
    foreach ($users as $user) {
        if ($user->gender === 'male') {
           return 'male';
        }
    }

    return 'other';
}

and then translation:

{ users_gender select,
     male {X i Y polublili}
     other {X i Y polubiły}
}

Number of users would not matter here.

Third, we already have phrases like "X, Y, and Z replied to this." or "W, X, Y, and Z like this.". And AFAIK they're handled in two steps: first generate users list, then translate "{users} like this.". So it wouldn't be handled automatically, since users are not passed while translating "{users} like this." - extension would either need to pass them manually (even if they're not used in phrase) and then translation would need such crazy nested syntax, or calculate group gender (and then helper that uses preprocessors from language pack woulds be helpful) and pass it to translation which will simplify it.

The genderization extension could include extenders and frontend hooks / util methods allowing language packs to add custom code. After all, language packs are extensions, and can use all the APIs available to extensions.

So I would need to require this extension in my language pack, in order to use these extenders. And other extensions will often need it too, because translations depends on gender. Moving such extenders outside of core is like moving pluralization outside of core - it just makes translations API incomplete.

[tankerkiller125]

The problem I see with asking someone for gender right in core is that it's inevitably going to lead to someone thinking "their taking my information and selling it" instead of "oh cool, their using my gender when referring to me"

The only alternative I can think of is leaving the default as "other" when a user registers, but then if a language pack is installed that supports genderization we have a GUI in the user settings area that lets them set their gender if they wish. (That GUI would be part of core, but not shown or used with the default english)

[askvortsov1]

For Polish preprocessor for users group would look like (declared once in language pack):

Hmm, I see what you mean. I was thinking more about a predetermined, small number users ("User1 liked your post and User2 approved your post"), not a punctuated list of users. And even in the example I just said, it might make more sense to split that into 2 translations.

For punctuated lists of users, I like the concept of "argument preprocessor" callbacks that could be registered on both the frontend and backend. This is a generic concept useful for things beyond just genderizations, so it could be a core feature / extender. That could be used by the genderization extension to do its pre-processing, and by language packs that need to apply their own transformation to arguments.

So I would need to require this extension in my language pack, in order to use these extenders. And other extensions will often need it too, because translations depends on gender. Moving such extenders outside of core is lidiscreteke moving pluralization outside of core - it just makes translations API incomplete.

Not necessarily. It could be an optional dependency, and you could optionally add the relevant extenders to your extend.php, depending on whether the class in question exists. But if we go with the route I described above, the extenders you would be adding would be from core, not from the genderization package.

The problem I see with asking someone for gender right in core is that it's inevitably going to lead to someone thinking "their taking my information and selling it" instead of "oh cool, their using my gender when referring to me"

My main argument against including it in core is that it violates minimalism. Not all communities need it, it requires an opinionated GUI, and I can see some communities wanting tailored approaches to it (for instance, supporting pronouns as well as gender, adding custom genders, etc). At the very, very most it would be a bundled extension, but even that I think would be too much, given the lack of domain expertise among the core team. I'm not convinced we would come up with the best solution.

What I DO want to do is to enable extensions to support genderization, and features like it. IMO, ICU MessageFormat is a lot more flexible than transChoice, because it supports arbitrary combinations of pluralization and value-based selection. If we include the ability to add translator argument pre-processors, that would enable genderization, and a lot more.

[rob006]

The problem I see with asking someone for gender right in core

I'm not talking about asking for gender in core, I'm talking about providing API and standardized way for working with gender, especially in context of translations. Frontend management may be provided by extension, and even may be many concurrent extensions that will provide different look and behavior for it, but there should be only one standardized way how to store, use and handle gender, so there will be no fragmentation and multiple concurrent APIs to work with.

[tankerkiller125]

This is exactly what @askvortsov1 is proposing.

[askvortsov1]

After flarum/framework#2759 is merged, the remaining task here will be implementing a more robust "argument preprocessor" system for translations, with extenders in the frontend and backend. After that, we can consider this issue to be in extension space.