Today

1. A given quantum of information is sourced in a root language, which could be a single language organization-wide or multiple languages.
2. Structured markup languages provide metadata and semantics irrespective of eventual output formats.

Concept

Continue the abstraction of information in 2 by eliminating 1 above as well: content is divorced from format and language.

Implementation

1. Codify grammar into conditions, objects, actions, results, and all other relevant dictional objects. (Consider the constructed language Unker for models of logical, nonlinear grammar diagrams.)
2. Document conceptual, procedural, and reference information as information maps that diagrammatically describe the information.
3. Develop Dictional Style Sheets (DSS) that render the information maps into textual, visual, or even multimedia deliverables. (For textual DSS, additional transformation via CSS and such continues as in B above).

Simple Example

Intent

“The door-open chime sounds and the door-open dashboard light illuminates when a door is ajar while the key is in the ignition.”

Information Map of Objects and Relationships

COND:[(OBJ:car-door:any)open AND (OBJ:key)inserted]
<=>
RES:[(OBJ:door-chime)on AND (OBJ:door-dash-light)on]

COND:[(OBJ:car-door:any)closed AND [ (OBJ:key)inserted OR (OBJ:key)removed] ]
<=>
RES:[(OBJ:door-chime)off AND (OBJ:door-dash-light)off]

REL:alert-types(OBJ:door-chime, OBJ:door-dash-light, …)

DSSs

[Magic happens here. LOTS of object:style mappings, but only need to be done once for each dictional output. Free translation; free infographics; free texts: all from running the information maps through DSSs and then output generators that can handle the renders. A tiny example:]

OBJ:key == “ignition key” | singular-only |

Outputs

Conceptual Contexts

“The door-open chime sounds and the door-open dashboard light illuminates when a door is ajar while the key is in the ignition.”

“When the door is closed, the door-open chime does not sound and the door-open dashboard light does not illuminate, regardless of whether the key is in the ignition or not.”

Procedural Contexts

“To test the door-open chime and the door-open dashboard light, insert the ignition key into the ignition switch and open a door.”

Troubleshooting Contexts

“If the door-open chime is sounding and the door-open dashboard light is illuminated, one or more doors is ajar. You can stop the alerts by either closing the open door or by removing the key from the ignition.”

Infographics

[You’d have graphics mapped to objects and relationships in the DSS that, when generated as output, show up like, say, an Ikea or LEGO manual. In fact, see Lego Digital Designer for a great model of a user interface for assembly mapping by sub-assemblies and stages.]

As you can tell if you’ve read this far, this isn’t a new idea: there are conlang folks who’ve thought about this stuff for decades, but not typically from the perspective of one:many translation (rather more like many:one ‘interfaces’ via written and/or spoke languages).

And I also just realized that many of the OBJ-REL information maps could be scraped straight out of software code! *headsplode*