Just a couple LTTP thoughts on this thread to date (combined with a bit of Markdown practice):
About YAML:*
I'm not familiar with YAML, but like amdad I'm most concerned about how performance would be affected. I can see how custom handling of things like pluralization and gender would help reduce the overall volume of language resources that need to be translated, and that's not a bad thing. But that gain comes at the expense of additional parser complexity. Is performance going to suffer as a result?
That said, I probably need to worry less than most translators. Japanese has neither pluralization nor gender, and in fact I'm having a hard time thinking of anything in Japanese that would require that sort of custom handling. At most, it might come in handy in a few rather specialized situations. So generally speaking, I'd be able to slim down the language resource files even more than most translators. From that perspective, the main concern is whether there is any additional overhead involved in the use of YAML as opposed to another approach.
About collaborative translation:*
Several people have mentioned sites that offer tools for the management of collaborative translations. I generally avoid projects that insist on a collaborative approach, for a few reasons.
First, someone has to spend time defining the standards to be followed in a given translation, and making sure translators stick to those standards. That's time that could be spent just translating. On smaller jobs, it's generally faster to do it all myself. (Of course it's possible to have everyone pitch in and standards be damned. While that approach is fine in many cases, it's not the best way to go when a professional quality translation is needed.)
Second, collaborative projects invariably involve a certain amount of politics. That's another type of overhead I prefer to avoid.
Third, I tend to give the needs of my own site priority. While translating esoTalk, for example, we decided that we would prefer to translate the word "channel" using the Japanese word meaning "conference room". While we appreciated the "channel" metaphor, we thought the "conference room" metaphor (which was used by NiftyServe, Japan's answer to CompuServe) would be easier for our users to grasp quickly. (Yeah, okay, there was a bit of nostalgia involved in our decision as well!) The result is a perfectly usable translation of esoTalk, but one that isn't "correct" in a broader sense; that is, someone who has used esoTalk in English could visit our site and become confused or irritated by the lack of reference to "channels."
This third point brings us back to the subject of standards. The question of whether translations can and should be handled as a collaborative project is not merely a matter of infrastructure (e.g. which site to use). Someone eventually has to make decisions about standards, not only on a per-language basis, but for Flarum translations overall: What makes a good translation of Flarum? What level of quality is acceptable? How much deviation from the original is permissible?
One can choose to avoid dealing with such questions, but that too is a decision that comes with its own set of consequences.
I feel that insisting on a collaborative approach would be a good idea only if translations are going to be incorporated into the core package that will be downloaded by end users. In that case, it would be a good idea to have many translators working together to get the latest version of Flarum released, complete with translations, without too many delays.
If translations are going to be handled as optional extensions, on the other hand, then collaborative translation should also be optional. Give folks the option of contributing to the collaborative project (which may or may not be considered the "official" translation for that language), but also leave a way for solo translators to make their language packs available to the user base.
TL;DR: Collaborative translation is good if optional, bad if required.
