Thank you. Will update the WMF task with this information.

The tools to perform this export are available in that project already. We don't plan to run the tools for you, since this just makes the workflow more complicated: you already have access to the tools you need to do this yourself.

Another user mentions project icon names are not translatable, which is I presume the same issue. That extendable options are not translatable,

Feel free to submit patches for these!

Do this man

Awesome (thanks for the super fast answer)!

My belief is that we've satisfied all the requirements for Translatewiki to move forward on their side.

Seeing the long list of merged commits here (thanks Evan and Nikerabbit for elaborating and explaining needs!), are there any further code changes in Phab needed before someone could set up a "Phabricator" project at http://translatewiki.net and let volunteers start contribute translations?

Yes, it is not "incorrect" but it is not human-readable format problem same with T8973 either. Chinese / Japanese / Korean unicode should be shown as what it is instead of some unreadable unicode digitals, especially in TRANSLATION functions, otherwise how to translate and confirm that?

This behavior is not "incorrect", it just isn't the most human-readable format we could use. I'm going to merge this into T8973, which discusses this and other potential improvements to human-readability for JSON encoded for presentation.

Sure, not a problem.

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

We now export strings into projects/<project>/<group>/en.json, etc. For example, here are strings which appear ONLY in Maniphest:

Okay, I believe we already produce a format which is compatible with that definition:

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).

Maybe it would be simplest if you just give me an example of exactly what you want us to emit?

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.

That sounds fine to me. Do you have any preference on what format you'd like the proto-english + variable type annotations in? Maybe something like this, since it sounds like you're doing some level of custom stuff on your side anyway?

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

Pausing this from our perspective since we're waiting on guidance to move forward.

Sounds good, thanks!

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:

%s cannot be repeated as far as I know.