I agree with the intention, but what about a sentence that doesn't rely on gender references?

aklapper is following this task

$user is following this $object

It doesn't in English, but I'm not positive offhand every language - I worked on i18n at Facebook, but that was about 6 years ago now. I'm just generally for language construction I know won't cause issues down the road.

Meaning I don't actually know the ramifications of your suggestion. Phrases tended to matter:

Easy to translate:
Married: Yes

Harder to translate (gender needed):
Chad is married.

Just for the sake of argument: ;)

Married: Yes

In Spanish translates to

Casado: Sí
or
Casada: Sí

Now let's look at the current string

aklapper added a subscriber: aklapper

which corresponds to

$user (verb) (noun): $user

(noun) is clearly gender dependent in many languages e.g. suscriptor/suscriptora (Spanish). You have already a gender problem in this string.

Is (verb) gender dependent in any language? Perhaps, but at least not in Latin languages, which love to attribute gender to just anything.

The formula I proposed above:

aklapper is following this task

which corresponds to

$user (verb) (attribute)

(verb) contains the same risk of gender as above, but (this attribute) doesn't depend on the gender of the user.

Therefore, the formula proposed not only sounds more natural, it also contains less gender risk.

PS: if you tell me "I have more important things to discuss and fix", I will understand. I just happen to like L18n and gender appreciation. :)

I think you are correct, we are using a verb in both cases, so it's likely to sound bad regardless (if it did at all). Most of this is all theoretical anyways as we never knew what languages would cause which issues and likely the same true with Phabricator. FIGS was where we started, and generally easy, and I think I left the team after having to get IE6 to support RTL languages. BTW is any of that you think useful for Wikimedia (i18n) - we were surprised it didn't come up.

Thank you for reconsidering.

In T4968#16, @chad wrote:

I think I left the team after having to get IE6 to support RTL languages.

No wonder, poor you. :)

BTW is any of that you think useful for Wikimedia (i18n) - we were surprised it didn't come up.

(offtopic) It is not coming in the short term because English is the only language officially supported in our development infrastructure. However, thanks to Phabricator I can foresee someone proposing the possibility to create bug reports in other languages, tagging them for the corresponding project "Reports in (ISO code)". We have already Tech Ambassadors connecting the different language communities with Wikimedia tech, so imho it is just a matter of time.

We already have at least some level of gender support in i18n, so that shouldn't be a huge issue. We'll need to glue some bits together, but the idea is that Settings -> Pronoun gets passed through pht() and we already support per-gender alternative translations.

I think this is generally a reasonable change to make. We should also make a closely related change, which was discussed elsewhere, but which I can't immediately dig up: when a user implicitly subscribes to an object by adding a comment or making an update, we pick "Subscribed" as the strongest action, but it's uninteresting and should not be the strongest action in this case. That is:

• When a transaction group includes a subscription, and the subscription adds or removes exactly one user, and that user is the actor, the subscription transaction should have weaker action strength than a comment transaction.

Two specific cases are:

• You comment "hi" on a revision you aren't involved in. The email currently says [Added Subscribers] or something, but should say [Commented].
• You comment @alincoln look at this on a revision. The email currently says [Added Subscribers], and should still say that.

On the gender thing, specifically, we can write this in the code:

pht('%s subscribed him/her/it/them/selfs(es) to this task.', $user);

English can reasonably translate this in a gender neutral way, so it could provide a single translation:

'%s subscribed to this task.'

Esperanto or whatever might not be able to, so it can provide gendered translations:

array(
  '%s he-subscribed to this el tasko.',
  '%s she-subscribed to this el tasko.',
  '%s it-subscribed to this el tasko.',
)

The framework is smart enough to handle those cases reasonably. So I think that's sufficient?

I believe we currently have no gendered language anywhere in the product in English (although I could be wrong) but that's mostly just because it's generally easier.

Is %s subscribed him/her/it/them/selfs(es) to this task. notation parsed automatically?

The fact that "%s" is gendered is automatic, because the value passed implements PhutilPerson. The text in the string is not: the string in the code isn't ever displayed if there's a translation available, so you can write whatever you want. We'll often do this:

pht('%s added %s task(s).', $user, $count);

This isn't correct even in English (including "task(s)" in the UI is awkward), so we'll translate it into English:

array(
  array(
    '%s added a task.',
    '%s added %s tasks.',
  )
)

In Esperanto, alternatives can be provided for both variables. Plural form rules can be specified per language:

array(
  array(
    '%s he-added a task.',
    '%s he-added severalo tasks.',
    '%s he-added %s-many tasks.',
  ),
  array(
    '%s she-added a task.',
    '%s she-added severalo tasks.',
    '%s she-added %s-many tasks.',
  ),
  array(
    '%s it-added a task.',
    '%s it-added several tasks.',
    '%s it-added %s-many tasks.',
  ),
)

D9168 fixes the tangentially related issue @cpojer ran into.

This would be nice to fix soon as subscribing to a task is such a common action and the "X added X" all over the place looks robotic and weird. :P

Assuming T5604 sticks, this is unblocked. Implementation approach is:

• Convert PhabricatorEdgeConfig::TYPE_OBJECT_HAS_SUBSCRIBER and PhabricatorEdgeConfig::TYPE_SUBSCRIBED_TO_OBJECT to Phabricator...EdgeType classes. D9839 has an example of how to apply this modernization.
• Change the prototypes on PhabricatorEdgeType for getTransactionAddString(), getTransactionRemoveString(), getTransactionEditString(), getFeedAddString(), getFeedRemoveString(), and getFeedEditString() to take $object as the first parameter. Change callsites in PhabricatorApplicationTransaction to pass $this->getObject().
• Add all of these methods to PhabricatorSubscribableInterface, as getSubscribersAddString(), getSubscribersFeedAddString(), etc., and implement these methods for every object which implements PhabricatorSubscribableInterface (it looks like there are 14).
• Have the new PhabricatorObjectHasSubscriberEdgeType call these methods to provide strings per subscribable object type.

These steps must be completed in order but can be completed in four separate stages. This task is appropriate for third-party contributors if someone wants to pick it up; it's time consuming (you'll need to implement nearly 100 methods to render these strings correctly across all applications) but substantially mechanical.

In T4968#87010, @epriestley wrote:

• Convert PhabricatorEdgeConfig::TYPE_OBJECT_HAS_SUBSCRIBER and PhabricatorEdgeConfig::TYPE_SUBSCRIBED_TO_OBJECT to Phabricator...EdgeType classes. D9839 has an example of how to apply this modernization.

Looks like this was done in rP7c2a7

In T4968#87010, @epriestley wrote:

• Change the prototypes on PhabricatorEdgeType for getTransactionAddString(), getTransactionRemoveString(), getTransactionEditString(), getFeedAddString(), getFeedRemoveString(), and getFeedEditString() to take $object as the first parameter. Change callsites in PhabricatorApplicationTransaction to pass $this->getObject().

Seems we'd also need to rename the current $object in the getFeed*String functions to something like $object_name. This ends up being a quite large change.

And we'd need some way to pass through exactly which subscribers changed, so the object can be sure that the user is adding only their own account:

<epriestley> So probably we need to pass something like $extra or $context, which would maybe just be something like array('isAuthorSubscribingOnlyThemselves' => <bool>) in this case.
<epriestley> Then the calling class (ApplicationTransaction?) can do the logic, compute the relevant hint, and pass it into the string methods.

test