A comprehensive post, Martian, and some good points, but i think you're missing some key ideas here:
Propagation is a big ask. No argument there. I really really don't have any actual expectation that this will succeed. I'm more interested in the development of the language for the sheer academic sport of it. So, very well put.
However:
Quote:
|
Originally Posted by Martian
The downside to using a pictographic language is that one must necessarily have an individual symbol for every concept.
|
Not true. There are two approaches here, using blissymbol-style
overlaying to create compound symbols ('words', effectively) OR the chinese-style
stacking approach. I think for my purposes the stacking option is better because you can have more detailled (therefore more easily understood) symbols that might become unreadable when you start overlaying them. You might want to build, say, "Lumberjack", an occupation (a type of human for all intents) and therefore worthy of a symbol all to itself. Using my current prototype grammar (infant stage) this look like "Man:[cuts->trees*many]", or a man who cuts down lots of trees (a forest). Instead of putting all these symbols in a row to make a sentence describing the lumberjack, stack them into a 2x2 grid, all of which is equal in size to one single symbol.
As far as input methods go, I imagine that the user would only have to know the grammar, and type words in his own native language. When i type "tree" and press the spacebar, it turns it into the symbol for tree. I don't know if you've ever typed in japanese, but something similar to that, where when you finish a word it pops up a list of kanji that match it and you choose, or leave it alone.
So if I were to type "Man :[cut tree ++]" the parser will:
- render 'man'
- leave ":[" cos its grammatical
- ask me if i want 'to cut', 'cuts', 'cutting', 'cuttable' etc
- render 'tree'
- render '++' as 'many'. (alternatively I could type 'many' or if the program is advanced enough, use 'trees' instead of 'tree'.)
Pretty straight forward, all I have to know the right way to build the sentence. The parser ought to be specific to the language of the person using it.
Kinda esoteric stuff, I know. Its all in good fun tho.
Also yeah, Lojban is very refined and unambiguous as I intend this project to be, but its phonetic; vocabulary must be memorised and phonemes mastered. It is therefore quite a bit harder than an unpronounced language.