This proposal assumes the need to support 5 different language patterns, currently named Universal, Monolingual, Strict, Free, and Mapped.
Note that nomenclature is NOT central to this proposal. Please feel free to suggest new names for these patterns (after reading how we define them, of course!)
Universal.
Some kinds of data should not be treated like natural language. Numbers and programming languages fit this pattern.
Examples
Numbers, Dates, etc: units and things need to be translated, and dates may be presented in different languages, but generally what we're going to store is going to be one universal numeric notation that can be easily translated automatically; it's not something users should ever have to bother with editing multiple versions of.
Javascript, CSS, etc: you definitely don't want to handle separate copies of code cards for separate languages. This is placed in "Universal," because, by definition, computer languages are not natural languages, and their linguistic differences are already addressed by giving them separate cardtypes.
Monolingual
Monolingual content is clearly associated with a specific language, but there should not be different versions of this content for different languages.
Examples
structure rules (cards ending in +*structure): When you update a structure rule (a content pattern), you don't want to have to update it in several languages, and you almost certainly don't want the case where your page has different structure in different languages (with different CSS to maintain, etc. YUCK!) What you want is to update the structure in one language but have the change take effect in all languages. For example, if you add {{+age}} to a structure rule, and you already have a spanish variant of the "age" card, then it should handle this translation in the nest processing, not with translated structures. Similar logic applies to many rules (permissions, default, style, etc), but not all. *table of contents is a number, for example, so that follows the "universal" pattern. And help text should be explicitly translated.
Strict
A third kind of card should support (and encourage) translation. The core idea of "strict" translation is that the name or content should have the same meaning in different languages. This means that if you update one, you should update the others. This implies a lot of special functionality to make it obvious when languages are not in sync.
Examples
Legal Documents: this is an obvious case where you don't want versions in different languages contradicting each other. They need to say the same thing!
Cards about site policy: even without the involvement of formal law, the same idea holds true of site policy in general.
Free
Alternative cards will support variants in different languages where there is no expectation that content in any two languages will actually have the same meaning as each other. In content terms, the different languages will essentially be independent.
Examples
+discussions. Clearly we don't want to make people translate discussions into multiple languages, but a given card should be discussable in multiple languages.
+Articles, +About, etc : (as in the actual +Article cards on the Analysis pages). If we end up having, say, 20 versions of the "Apple+Climate Change" card (as it would be called in English), they would all vary, probably by quite a bit. While we'd love to have these alternative versions inspire each other, there's no reason why each version needs to be a direct translation of the others. Each could still have citation visualizations, but the citations might come in different orders. And, if/when we support upvotes on articles, those should apply only to a specific language (since once might be great and another might be rubbish).
Mapped
The basic concept here is that translation is performed automatically on Wagn based on how names of other cards are translated.
Examples
Pointers (+topic, +company, etc.) It would be highly inefficient to store pointers in multiple languages, because (as will be explained below), the translation is very easy to automate based on the cards being pointed to. Note that the "+" in the examples (+topic, +company) is very important here. We're not talking about Topic cards, we're talking about +topic fields on, say, a Claim or a Source. If a claim has been related to a topic in English, it should automatically be related to that topic in any other language.