• TranslateWiki integration should be optional
• language fallbacks should be customizable

@Ricordisamoa: I'll go ahead and put "TranslateWiki integration should be optional" into the Acceptance criteria. For the other features, we'll want to make follow-up tasks I think.

Assessment for prioritization:
Support: Medium/High
Feasibility: Medium/Difficult (won't be trivial to implement)
Impact: High
Risk: Medium

Priority: Normal

If by "translatewiki.net integration" you mean the ability to for them to pull and push updates, then this requirement is redundant with "Retrieve messages by key and language from the JSON files".

The "Banana" file format that Intuition uses is the same that translatewiki uses.

Perhaps not in the first iteration, but I've got a few other suggestions for features needed for the implementation to be good enough for end users in majority of tools:

• Support fallback chain (not just from target to English, but include intermediary language as well. This is important in order to support languages that only override a few messages and is expected by those that author the translations).
• Message variables. (expand $1 and $2 placeholders)
• Message language functions. (transform {{PLURAL:}})
• Map language code to directionality (e.g. getDir() "ltr" or "rtl" - required to produce HTML output that doesn't render in an unreadable way for RTL users).

@TBolliger: This task is open but not associated to any active project/tag. Could you please fix that? Thanks.