I would like to submit a translation to upstream. Where do I start?

Suggesting to prioritise this task. Non-English interface on Phabricator would be useful, as it would let people file non-English bugs. This is useful for two purposes:

• Development initiatives within non-English-speaking Chapters. While there usually is at least one English-speaking person within the Chapter who could handle the translation, it would be more convenient for them to have the list of non-English issues on phabricator and translate them routinely than having them on a piece of paper and file them "later". This way the reporter is up-to-date on the progress of the bug, and the bug tracker is there to dump everything on it in the first place so that things are not lost.
• Gathering feedback from end users. This is more interesting: I saw Mozilla come to it over the years to the extent of establishing a special 'user feedback' tag on their issue tracker, and writing a special code on their knowledge base site for users to type their problem and submit it to bugzilla without interacting with bugzilla directly (this knowledge base site is aggressively multilingual with lots of readers in each language for about a decade at least).

Now, I don't have to do all this, because the information freedom movement does not need to be centralized; I should be free to mirror any Wikimedia project and play with my software issue tracker whimsicals there, and leave you with the task of needing to merge my software and my content back at your discretion. But the way Mozilla does the international scope of the movement is nice and I would not mind it if Wikimedia considered following it, as it would unleash some more potential and merging back would be easier, as you would be informed of the things happening at these non-English projects. :-)

RSS feeds have a clear use-case: that of viewing recent events at a dozen of websites without visiting each of these web sites by hand and without spamming email with messages I don't intend to reply to.

cost of a false positive is higher than the cost of a false negative

OK. Where can I find documentation on metamta.reply.* config settings?

My argument is that in some projects, phabricator is exposed to end users, and the e-mail needs to reflect that (99.9% of users don't need the reply handler actions, for example). However I don't see this argument fly in other projects where phabricator is not exposed to end users. Hence the need to make emails customizable.

I know a project (a big non-profit) which runs Phabricator whose users are unhappy with the emails layout and find them confusing. I imagine fixing this bug is a better solution than having them write a custom patch...