Signs and symbols: Writing systems (hieroglyphs, nail writing) and Signed Toki Pona; unofficial scripts too
Signoj kaj simboloj: Skribsistemoj (hieroglifoj, ungoskribado) kaj la Tokipona Signolingvo; ankaŭ por neoficialaj skribsistemoj
jndn wrote:
I have a similar idea, to make all vowels facultative, to give more freedom for native speakers.
your idea is very interesting but not similar, it deals with some phonetical and lexical changes of tp. it will hardly please jSonja and jKipo, but it is interesting. there was more similar idea on this forum. somebody proposed to treat vowles i and e as the same sound and traet o and u in this way. this will not disturb tp except kin vs ken. so he proposed to replace ken with kan.
perhaps your idea should be discussed in the separate topic
I agree that the idea is a bit crazy (to reduce such a short dictionary) but my idea was to give more freedom in pronunciacion.
As far as I know, people of different language background have problems with correct pronunciacion of vowels (of course, consonants too, but to a lesser extent).
Also, facultative vowels give a lot of freedom in poetry, too: pona toki = pon tok = pona tok = pon toki = buona tuoka etc.
What about another idea mentioned in my post: to introduce lu, which changes the word order. toki pona = lu pona toki = lu pon tok
So, to sum up, your idea is to have a biliteral frame and allow vowels to float a bit more broadly than the present (rather generous -- perhaps to the point of confusion) limits, various diphthongs allowed in particular, but also dropping or undifferentiating finals and maybe allowing voiced consonants in various places. Most of these are in fact already in place in the present rules, though not usually written out. I am relatively sure that most American speakers of tp use a diphthong for e and o and probably i and u and reduce most final vowels to schwa (which is also a common form of a). In the consonants, pronunciation often follows the original word when it is known ('fini' for 'pini' and 'bona' for "pona' and so on). Should we ever all get together, it would be a while before we were easily understood (I have suspicions about pronunciation by French and Russian speakers at least as well and just don't have a feel for further cases). Writing things that way, however, is a different matter and I would not like to see it happen (except as a deliberate dialect story).
I don't see the point of 'lu' -- there are other grammatical problems in phrases that seem to require much more attention than this one (if it is a problem at all).
Then lu would be an adjective introducer and the very last word (before the next pi) would be a noun. I'm not sure if that would help in resolving modifier relationships, but maybe it could.
a b pi c d pi e f --- does e modify a or c?
a b lu d c lu f e --- I suppose this feels more like the lu phrases could only modify the headmost noun, a.
I seems a lu would be for poetic flexibility, more that a desire to make it easy to say what currently would be cumbersome to say. I'd rather have a verbal introducer, as I have noted elsewhere so as to resolve issues like ostrich, running bird. waso tawa, waso pi tawa noka => bird with legs, bird of trips on foot vs. waso pu tawa, running bird, waso pu tawa noka, bird running on foot.
As for toki pona being an easylang, I take the position that the rules on intonation and pronunciation should be stricter. While it currently is legal to shift all the consonats (dogi buma) or add the intonation of a fire truck to all sentences, it would just make it hard to understand. Having to pronounce an "e" as "e" is mitigated by the small phonetic inventory, etc.
I'm writing a compressor/decompressor. I get frame errors if there is a proper modifier because I don't know what to do with it-- so I just pass it through. Since Apika doesn't have an even number of letters, it throws off the entire series on decompression. How are proper modifiers meant to be encoded/offset in the 2 letter code system?
janMato wrote: How are proper modifiers meant to be encoded/offset in the 2 letter code system?
2 options:
1) as is in upper case: lnmaAPIKA (for maximal compression)
2) flank with some symbols, e.g. lnma'apika' (if upper case is not supported)
3) flank with spaces if you use them: ln ma Apika (as you have in current version)
I'm going with the convention of putting proper modifiers and other non-TP letters in all caps, since the goal is compression. At the moment, on my compression page I display everything twice, once with spaces, and again without spaces. Readability really drops off when the spaces are gone. Maybe if the spaces were remove and the first letter of each word was capitalized one could get the best of both worlds.