We now export a frequency.json, with string keys in a list. Since we haven't actually collected frequency data, the order is currently (roughly) random:

https://secure.phabricator.com/source/translatewiki/browse/master/projects/phabricator/maniphest/frequency.json;00108900457eda804c9c786dd76ff96620a05195

1. Proto-english strings.
2. Nested English translations.
3. Variable types.
4. Usage frequency information ("this string has frequency 0.9 out of 1.0", or "this string is part of the 'most common 10% of strings' group").
5. Application groupings ("this string is part of Maniphest").
6. Places in the code where the string appears ("this string appears at x.php line 234").
7. Additional human-readable context information, like "qqq" (very rarely available).

What works out of the box is JSON files with string key-value pairs for source text. For documentation the qqq.json that is "just-another-language" is what we use most often. The strings of that file are parsed as wikitext using MediaWiki syntax and displayed automatically to translators.

Okay, I have been thinking this for a bit. I don't have a perfect solution, but I have the following proposal.

In other words is your array syntax always messagekey[gender][plural] or could it also be messagekey[plural][plural] depending on the variables?

We support unlimited gender/plural variants in any order. We have a number of strings like this:

When multiple variants exist, should we export a nested structure like this?

[...]

In T5267#199335, @epriestley wrote:

Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.

At least some translators are likely familiar with $1, {{GENDER:$1|X|Y}}, and so on, right? And you have documentation on this syntax to help translators who aren't familiar with it learn it?

Some of the terms that I use below (e.g. outdated) are explained in https://www.mediawiki.org/wiki/Help:Extension:Translate/Glossary

• When exporting, I don't know how to escape $ for Translatewiki (this affects ~10 strings).

Naturally people can work on what they want – that is the promise of open source. I am not contesting that. What I do want to make sure is that our values and goals are aligned. For example you and we recommend people to collaborate first. If we are sufficiently aligned, I don't see much need to continue discussing about things that might or might not happen.

If we submit patches, say once or twice a week, will you be able to review and merge them before the become stale?

Usually, yes, but I can't promise we'll always be able to review patches promptly.

Like you say, Phabricator is a big project. This means I am willing to give some amount of special treatment to it that I would not give to smaller projects because that would not scale. For example, requiring all messages to have message documentation up-front is unreasonable. But a good way forward would be to establish good practices such as:

• having message documentation for new or changed messages;
• accepting bug reports and patches about source texts;
• and enhancing and enforcing best practices in code review with regards to parameters, plural handling etc.

The Lato font is causing problems for some people, including me. See https://phabricator.wikimedia.org/T104047#1419642 for example or the screenshot below.