On Fri, Apr 2, 2010 at 2:27 PM, Christopher Doty <
suomichris@gmail.com> wrote:
>
> I think it works for all examples, not just a select few.
OK, I'll hold back my skepticism until I see the full list. Or at
least an unbiased sample, let's say aaa, aab, aba, abb, baa, bab, bba,
bbb.
(Not sure if all of them are in use, if not, replace a vowel or a
consonant by another vowel or consonant.)
Ok. I will say that the sample I have presenting is not really that biased. There are some language families I haven't done yet, for example, but I made sure to pull ones that it does work for. Keep in mind, though, that the intent here was to establish the fu'ivla for the languages included in the first iteration of the ISO codes (between 200 and 300 somewhere, depending on how we slice it). I agree that things could get messier as we go on and use this for other languages, although at least one person suggested that, for languages with smaller numbers of speakers where there is no agreed fu'ivla, cmene are used. I'm not sure I like this, except as a stop gap.
Nonetheless, I take your point, and can pick some out and see what they would look like.
> Some will need
> various changes to make them fit (three-consonant codes, for example, will
> need a buffer vowel, or the addition of an autonym vowel somewhere, for
> example), but there is no reason that we couldn't do that in a consistent
> way, so that, say, if you see a buffer vowel, get it out of there when
> you're looking for the autonym (that was in obvious, I realize, but it could
> still work for other things).
How will you tell a buffer vowel apart from a vowel coming from the code?
I was thinking specifically the vowel {y}, although there are other possibilities that would be more complex. I haven't encountered one of those yet, but there are some that are messy (Turkic is trk, for example).
> I think, too, that the representation of language family is a great idea,
> but I wonder about giving ourself more leeway with the form these would
> take. {-ine}, for example, works pretty well; {-esx} less so. We might be
> able to get a better match if we used the language family codes as the first
> part of the fu'ivla and changed them a bit to assure that they had a good
> cluster in a require position; we thus wouldn't have to tweak the language
> code as much (if at all, except clusters), making it more recognizable.
> {-ine}, for example, might become {.inde-}. And, presumably, the language
> code is more important to be able to look up than the family code.
That starts to look a bit like what I proposed, with the prefix
"bangu-" replaced by something coming from the language family.
Indeed, although hopefully with something a bit more pronounceable. Plus, even if people don't make use of the family names, having a limited set of prefixes/suffixes that can code languages still makes the words identifiable as languages, but more learnable, since the starts wouldn't be identical for every language.
> We could also do some other things to make pretty clusters that are more
> autonymic. For example, the Niger-Congo language family is spread across
> nearly all of Africa, and is such a large grouping as to not be that useful.
> But, as mentioned before, nearly all Bantu languages (a large subset of
> Niger-Congo) have a prefix for languages of the form ki-, with variants in
> different languages like iki- and ichi-. Thus, we could use a separate
> prefix for Bantu languages, say {itci-} or {tci-} making them look more
> autonymic.
".itci" won't work, as the ".i" will fall off, "tci-" might, but
depending on what follows, you could end up with lujvo forms.
Ah, right. And I just asked you about that. Must have a hole in my brain somewhere...
.kris.