So what do we say for Swedish? (was "Summary: Cultural fu'ivla")

[Stela Selckiku]

Sounds great in theory, doi cultural fu'ivla reformers! In practice,
though, here is a question that actually confronts me in speaking
Lojban day-to-day: What do we say for Sweden and Swedish? What I've
mostly seen in use is the cultural fu'ivla space "sfe'ero" and the
outré experimental gismu "zvero". I preferred "sfe'ero" on principle,
until I actually tried pronouncing both of them out loud! :)

It's all well and good to talk about the theoretical issues that might
come up someday when coining terms for all the Bantu languages, but I
think we might get a clearer view of those issues if we could first
convincingly resolve the issues that we're already encountering in the
language as we use it. The way we're heading now is towards cultural
fu'ivla for everything, none of which are used, and cultural gismu
also for any culture that actually has any Lojbanists or that we
regularly talk about. That's not what any of us want! But that's
where we're headed! We need not just an idea of what would be a more
rational method, but a strategy for how we're going to move the
language in the new direction we choose.

mi'e la stela selckiku
mu'o

[Oren]

> Lojban day-to-day: What do we say for Sweden and Swedish?

sweden: { gugde la .sy .ebu }
swedish: { bangu la .sy .vy }

My serious suggestion has been to spell out the names of the ISO
standards. Lojban claims to be culturally neutral and then decides to
forgo the worlds largest standards-making body, an international
non-government organization with a mission of consensus-based
decision-making... can we do it better? Should we try?

What I mean is, leave these decisions up to the professionals,
lojbanists have more awesome things to be doing. Lojban should be
about using lojban, not krokodili cultural omphaloskepsis in the name
of 'neutrality' ...no solution is absolutely neutral.

co'o mi'e korbi

[Luke Bergen]

hear hear.  Although I have to disagree with you.  When I physically speak out {sfe'ero} and {svero} I like the sound of {sfe'ero} better.  It has a really nice ring to it IMO.  I'm all for fu'ivla that are based on how the native speakers speak their nation/nationality/whatever.

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[Christopher Doty]

On Thu, Apr 1, 2010 at 18:35, Oren <get....@gmail.com> wrote:

> Lojban day-to-day: What do we say for Sweden and Swedish?

sweden: { gugde la .sy .ebu }
swedish: { bangu la .sy .vy }

My serious suggestion has been to spell out the names of the ISO
standards.

I'm thinking this is the way to go.  I have little interest in trying to develop lojbanized words when the entire point of doing so seems to have been lost on at least some.  I would say that we need to use the current standard for this, though (i.e., 639-3), or there will be conflicts in meaning--and, I mean, the whole list exists, might as well use it.

 

Lojban claims to be culturally neutral and then decides to
forgo the worlds largest standards-making body, an international
non-government organization with a mission of consensus-based
decision-making... can we do it better? Should we try?

I, like you (seem to be), am kind of confused by the seemingly negative response from some corners to the ISO codes.  They are specifically designed, by consensus, to be as neutral and international as possible.  Why are we revisiting that?  If you think Lojban should indeed be culturally neutral, then what is your objection?

[Leo Molas]

El 01/04/2010 11:04 p.m., Luke Bergen escribió:
> hear hear. Although I have to disagree with you. When I physically
> speak out {sfe'ero} and {svero} I like the sound of {sfe'ero} better.
> It has a really nice ring to it IMO. I'm all for fu'ivla that are
> based on how the native speakers speak their nation/nationality/whatever.

I think fu'ivla should be based on how native speakers speak them. But
it has the problems chris commented... Nevertheless, I think it would be
worth trying (given that all fu'ivla should be that way)

BTW, I like sfe'ero :)

mu'o mi'e .leos.

--
My lojban journal: http://learninglojban.wordpress.com
My personal blog: http://leomolas.tumblr.com

[Pierre Abbat]

On Thursday 01 April 2010 21:35:38 Oren wrote:
> > Lojban day-to-day: What do we say for Sweden and Swedish?
>
> sweden: { gugde la .sy .ebu }
> swedish: { bangu la .sy .vy }

Doesn't parse (try "gugde la me sy.ebu"). And are the people of Cyprus
speakers of Welsh?

Pierre
--
li ze te'a ci vu'u ci bi'e te'a mu du
li ci su'i ze te'a mu bi'e vu'u ci

[Oren]

right. i guess the code doesn't belong in a sumti place.

[Christopher Doty]

Right.  So we're back to autonyms have problems, and the codes not really working on their own.

I **really** think the ISO codes should at least be incorporated into the fu'ivla in some way--what about chucking out the language family stuff, and expanding the ISO codes to fu'ivla, based as much as possible on the autonym?

[Jorge Llambías]

On Fri, Apr 2, 2010 at 10:30 AM, Christopher Doty <suomi...@gmail.com> wrote:
>
> I **really** think the ISO codes should at least be incorporated into the
> fu'ivla in some way--what about chucking out the language family stuff, and
> expanding the ISO codes to fu'ivla, based as much as possible on the
> autonym?

Some random thoughts here, I'm not suggesting this is necessarily a good idea:

aaa -> bangu'a'a'a
aab -> bangu'a'abu
aba -> bangu'abu'a
abb -> bangu'abubu
baa -> bangubu'a'a
bab -> bangubu'abu
bba -> bangububu'a
bbb -> bangubububu

The remaining problem would be what to do with codes containing h, q,
w, y, which cannot appear in fu'ivla.

One option is to convert h->x, q->k, w->v, y->j and use a different
vowel (instead of "u") for those, so:

aah -> bangu'a'axe
aqa -> bangu'ake'a
aww -> bangu'aveve
yaa -> banguje'a'a

This scheme is univocal and reversible.

mu'o mi'e xorxes

[Jorge Llambías]

2010/4/2 Jorge Llambías <jjlla...@gmail.com>:

>
> aba -> bangu'abu'a

I just realized this one is actually a lujvo, so, it would need some
additional tweaking.

[Jonathan Jones]

I think I prefer Christopher's language/family naming method, as presented in the topic this one came from.

2010/4/2 Jorge Llambías <jjlla...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

--
mu'o mi'e .aionys.

.i.a'o.e'e ko klama le bende pe denpa bu

[Jorge Llambías]

On Fri, Apr 2, 2010 at 1:53 PM, Jonathan Jones <eye...@gmail.com> wrote:
> I think I prefer Christopher's language/family naming method, as presented
> in the topic this one came from.

The problem is it only works for a few selected examples, not as a general rule.

In my opinion, if you are going to use the codes, then there should be
a systematic transformation to get the fu'ivla from the code and the
code from the fu'ivla. Otherwise, I see no point in preferring the
code to the autonym.

[Jonathan Jones]

2010/4/2 Jorge Llambías <jjlla...@gmail.com>

I don't prefer the code to the autonym. I prefer Christopher's method of using the code to the one you suggested.

 

I would prefer the Lojban name for something to resemble the autonym as closely as possible while still being a valid stage-4 fu'ivla. {bangu'a'a'a} et al. doesn't resemble anyone's name for any language, doesn't provide any information other than "it's a language" unless you know the ISO code, and looks ugly.

 

mu'o mi'e xorxes

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[Christopher Doty]

Well, there would still be be a much more consistent representation in the code-to-fu'ivla transformation verses autonyms.  It won't be precise in every case, but you will have a good shot at a guess.  Plus, we can always rethink some of the changes I made to make the matching more precise (e.g., /c/ is just /s/, regardless).

The ones I presented most recently all had the three-letter language code and the three letter family code in the same order, and adjacent to each other, except for the c > ck change (as far as I recall; one or two might have slipped through the cracks, but that was my intent, anyway).  (Note, though, that the addition of a /t/ to the front of forms like Czech actually gets use closer to the autonym, plus gets a consonant, so might be preferred.)  When the need to add an additional vowel or consonant to the middle of the fu'ivla, this phoneme was always chosen based on the sound of the autonym, in an effort to not only make it match the autonym, but also hopefully make people who like the autonym idea a bit happier with these.

Specifically responding and summarizing what I just said:

2010/4/2 Jorge Llambías <jjlla...@gmail.com>

The problem is it only works for a few selected examples, not as a general rule.

I think it works for all examples, not just a select few. 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).

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.

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.

Okay, I said I was summarizing by then I said new stuff.... :p

Chris

[Jorge Llambías]

On Fri, Apr 2, 2010 at 2:27 PM, Christopher Doty <suomi...@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.)

> 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 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.

> 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.

[Jonathan Jones]

Christopher, I can see you've been putting a lot of thought into this. I appreciate all the effort, and I look forward to seeing the finished result.

 

I don't see the point to placing the family half in front of the language half, though. As long as it's the same half every time, I don't see how it would be any easier to look up the language.

2010/4/2 Jorge Llambías <jjlla...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[Christopher Doty]

2010/4/2 Jorge Llambías <jjlla...@gmail.com>

On Fri, Apr 2, 2010 at 2:27 PM, Christopher Doty <suomi...@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.

[Christopher Doty]

What it would get is that, currently, because of Lojban phonotactics (what is called/grouped with "Morphology" in CLL, I think), we have to get a cluster close to the beginning of the word.  If we are using language-family order, that means that we may have to mess with the language code itself in order to get a cluster in there (for a code like, say, afa or aar).  But, if we assume that the language family is, overall, less important to keep intact, we can simply have the family code come first, and have an acceptable cluster, so that there is less chance of needing to change or add anything to the language code.  So, consider Latin.  The form I sent yesterday was {latnine}, with an /n/ added in order to make the cluster (which was drawn from the autonym, latina).  If we had it the other way, we wouldn't have have to do that, though--we could have {indelatV}, where the {inde-} deals with the consonant cluster.  There is the vowel issue, which would have to be figured out in such a way that it could always be determined if it was a part of the language code, but I think that is doable.

Hope that clarifies what I was thinking.

Chris

[Jorge Llambías]

On Fri, Apr 2, 2010 at 2:58 PM, Christopher Doty <suomi...@gmail.com> wrote:
> 2010/4/2 Jorge Llambías <jjlla...@gmail.com>

>> 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.)

According to Wikipedia, they are all in use:

aaa: Ghotuo
aab: Alumu-Tesu
aba: Abé
abb: Bankon
baa: Babatana
bab: Bainouk-Gunyuño
bba: Baatonum
bbb: Barai

I propose those eight be used as test cases.

[Jonathan Jones]

2010/4/2 Jorge Llambías <jjlla...@gmail.com>

I expect it'll be much easier now that he's decided to put family first. :)

 

mu'o mi'e xorxes

--

You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[Christopher Doty]

Well, I wouldn't say I've decided anything; I'd really hoping for input.

But, I agree--the language first should make these easier. I'll try to cook up both, though :p

Chris

[Christopher Doty]

Yeah, so, the three same consonant ones would be ugly, not surprisingly, although still possible.  There could simply a pattern of vowels (say, {i, o, a}) that is inserted into this (very few) codes.  This doesn't necessarily create a problem with other three-consonant codes, as there is always the possibility for a cluster in there.  Plus, if one did do something along the lines of an initial, more variable language family thing, that could have different forms to accommodate different language codes--one for before vowel-initial ISOs, one before a C-initial ISO were it makes a valid cluster which is not an onset, and one where the following ISO starts with a valid onset....

[Jorge Llambías]

2010/4/2 Jorge Llambías <jjlla...@gmail.com>:

> aaa -> bangu'a'a'a
> aab -> bangu'a'abu
> aba -> bangu'abu'a
> abb -> bangu'abubu
> baa -> bangubu'a'a
> bab -> bangubu'abu
> bba -> bangububu'a
> bbb -> bangubububu

Since bangu'abu'a means "language-work-brother" (which by a happy
coincidence happens to be kind of what we are now) that scheme fails.
So here is an improved version (it also gives shorter words):

aaa -> banga'a'a
aab -> banga'abu
aba -> bangabu'a
abb -> bangabubu
baa -> banbu'a'a
bab -> banbu'abu
bba -> banbubu'a
bbb -> banbububu

For codes that begin with "n":

naa -> baurnu'a'a
nab -> baurnu'abu
nba -> baurnubu'a
nbb -> baurnububu

And to answer the question in the subject:

swe (Swedish) -> bansuve'e
swl (Swedish Sign Language) -> bansuvelu

[Christopher Doty]

So, I kind of distracted from this, but here is what I had come up with.  Putting the language families first, and having alternate forms for different clusters, does work a lot better.

Also, this is a bit weird, since six of these eight languages are Niger-Congo, so also isn't quite a random sample, but it does illustrate, as do the examples from .xorxes., the idea of different initial elements.  So, Niger-Congo might be {nirk} when the ISO is V initial, {nirko} when it is VV initial, etc....

aaa -> nirka'a'a' (cf. banga'a'a)
aab -> nirko'abu (cf. banga'abu)
aba -> nirkaba or ... (cf. bangabu'a)  
abb -> ... bangabubu
baa -> ... banbu'a'a
bab -> babnicV or nirbabV (cf. banbu'abu)
bba -> ... banbubu'a
bbb -> tagbVbVbV (cf. banbububu)

I think that, although it is important to think about how to deal with these, they are always going to be somewhat, given that there are a limited number of these cases.  And, if we were careful, as .xorxes. notes, we could use, say, only /u/ for tri-consonantal roots, which would mean in any time you see CuCuCu at the end of one of these, you would know the ISO code would be just CCC.

Chris

2010/4/2 Jorge Llambías <jjlla...@gmail.com>

[Jorge Llambías]

2010/4/2 Jorge Llambías <jjlla...@gmail.com>:
>

> aaa -> banga'a'a
> aab -> banga'abu
> aba -> bangabu'a
> abb -> bangabubu
> baa -> banbu'a'a
> bab -> banbu'abu
> bba -> banbubu'a
> bbb -> banbububu
>
> For codes that begin with "n":
>
> naa -> baurnu'a'a
> nab -> baurnu'abu
> nba -> baurnubu'a
> nbb -> baurnububu

OK, I found another glitch. Codes that begin with "g" and codes that
begin with "u" give identical results:

uam -> bangu'amu
gam -> bangu'amu

So, to fix that, codes that begin with "g" will have to pattern with
those that begin with "n":

gaa -> baurgu'a'a
gab -> baurgu'abu
gba -> baurgubu'a
gbb -> baurgububu

Hopefully now everything is unambiguous.

Some examples:

eng (English) -> bangenugu
spa (Spanish) -> bansupu'a
rus (Russian) -> banru'usu
jbo (Lojban) -> banjubu'o

[Jorge Llambías]

On Fri, Apr 2, 2010 at 5:36 PM, Christopher Doty <suomi...@gmail.com> wrote:
> So, I kind of distracted from this, but here is what I had come up with.
>  Putting the language families first, and having alternate forms for
> different clusters, does work a lot better.
> Also, this is a bit weird, since six of these eight languages are
> Niger-Congo, so also isn't quite a random sample,

Apparently Niger-Congo is the family with the most members, so that's
not too surprizing.

So, you want to create a prefix or series of prefixes for each of (how
many? more than a hundred?) families?
Is it really worth going to all that trouble? What's the advantage,
over just using bang-, ban-, baur-?

> but it does illustrate, as
> do the examples from .xorxes., the idea of different initial elements.  So,
> Niger-Congo might be {nirk} when the ISO is V initial, {nirko} when it is VV
> initial, etc....

If you do that, how do you distinguish code "aab" from code "oab"?
"nirko'abu" could be either. (At least if they both happen to be in
the same family.) And why would you want to change the vowel?

> aaa -> nirka'a'a' (cf. banga'a'a)
> aab -> nirko'abu (cf. banga'abu)
> aba -> nirkaba or ... (cf. bangabu'a)

I could do "bangaba" too. The reason I prefer "bangabu'a"is that this
way every language name has four syllables. But if giving three
syllables to languages with VCV codes does not violate neutrality,
that can be done.

> abb -> ... bangabubu
> baa -> ... banbu'a'a
> bab -> babnicV or nirbabV (cf. banbu'abu)

"nirbabV" works with a nir- family code, but it wouldn't work with
other family codes.

> bba -> ... banbubu'a
> bbb -> tagbVbVbV (cf. banbububu)

tag- won't work for codes that begin with voiceless consonants.

[Stela Selckiku]

2010/4/2 Jorge Llambías <jjlla...@gmail.com>:

> jbo (Lojban) -> banjubu'o

.ui .ue lo do banjubu'o sidbo cu cizra melbi mi doi bangu'abu'a

[Pierre Abbat]

On Friday 02 April 2010 14:20:28 Jorge Llambías wrote:
> According to Wikipedia, they are all in use:
>
> aaa: Ghotuo
> aab: Alumu-Tesu
> aba: Abé
> abb: Bankon
> baa: Babatana
> bab: Bainouk-Gunyuño
> bba: Baatonum
> bbb: Barai
>
> I propose those eight be used as test cases.

I've never heard of any of those languages, except Ghotuo which I found when
looking at template aaa on Wiktionary, and I think that if you run this
nunfu'ivlazba to completion, you're going to end up with a humongous list
that's as desuet as a dule of doves.

The way language names are coined in natural languages is completely
different. People who are interested in a particular language (hereinafter
Pelonian) find out what the Pelonians call their language (which requires
learning some Pelonian) and what their neighbors the Almonians call it. Then
they decide what to call it in, say, English. Then they write reports about
Pelonian and other people learn that there is such a language. They may, on
learning more Pelonian, figure out that they used the wrong word to name the
language ("Auca", for instance, is an exonym meaning "enemy", so they are now
called "Waorani" or other spellings thereof).

I do not see a need for coining a type-4 or even type-3 fu'ivla for Baatonum
or Babatana until some Lojbanist is interested in those languages. Leave them
at type 1.

Pierre
--
li fi'u vu'u fi'u fi'u du li pa

[Jorge Llambías]

On Fri, Apr 2, 2010 at 6:37 PM, Pierre Abbat <ph...@phma.optus.nu> wrote:
> On Friday 02 April 2010 14:20:28 Jorge Llambías wrote:
>> According to Wikipedia, they are all in use:
>>
>> aaa: Ghotuo
>> aab: Alumu-Tesu
>> aba: Abé
>> abb: Bankon
>> baa: Babatana
>> bab: Bainouk-Gunyuño
>> bba: Baatonum
>> bbb: Barai
>>
>> I propose those eight be used as test cases.
>
> I've never heard of any of those languages, except Ghotuo which I found when
> looking at template aaa on Wiktionary, and I think that if you run this
> nunfu'ivlazba to completion, you're going to end up with a humongous list
> that's as desuet as a dule of doves.

Well, the nice thing about my algorithm is that you don't really need
to make any actual list. You just know that for any three letter
language code, there is a fu'ivla there ready to be used that goes
with that code. You don't create it until you want to use it.

> I do not see a need for coining a type-4 or even type-3 fu'ivla for Baatonum
> or Babatana until some Lojbanist is interested in those languages. Leave them
> at type 1.

You can think of "banbubu'a" not as meaning "x1 is Baatonum" but
rather as meaning "x1 is the language with ISO-code 'bba'".

Then if Baatonum for some reason became a hosehold word in
Lojbanistan, and people found "banbubu'a" too cumbersome, a more
friendly name could be coined.

[Oren]

nelci

[Oren]

can we have a pseudocode version of the algorithm, or something similar?

2010/4/3 Jorge Llambías <jjlla...@gmail.com>:

[Jorge Llambías]

On Sat, Apr 3, 2010 at 12:30 PM, Oren <get....@gmail.com> wrote:
> can we have a pseudocode version of the algorithm, or something similar?

For countries:

VV -> gugde'V'V
VC -> gugde'VCu
CV -> gugdeCu'V
CC -> gugdeCuCu

Codes with "h", "q", "w", "y" use "xe", "ke", "ve", "je" instead of
"xu", "ku", "vu", "ju".

For languages:

VVV -> bangV'V'V
VVC -> bangV'V'Cu
VCV -> bangVCu'V
VCC -> bangVCuCu

CVV -> banCu'V'V
CVC -> banCu'VCu
CCV -> banCuCu'V
CCC -> banCuCuCu

special case: codes that start with "n" or "g":

(n|g)VV -> baur(n|g)u'V'V
(n|g)VC -> baur(n|g)u'VCu
(n|g)CV -> baur(n|g)uCu'V
(n|g)CC -> baur(n|g)uCuCu

[Christopher Doty]

2010/4/2 Jorge Llambías <jjlla...@gmail.com>

On Fri, Apr 2, 2010 at 5:36 PM, Christopher Doty <suomi...@gmail.com> wrote:
> So, I kind of distracted from this, but here is what I had come up with.
>  Putting the language families first, and having alternate forms for
> different clusters, does work a lot better.
> Also, this is a bit weird, since six of these eight languages are
> Niger-Congo, so also isn't quite a random sample,

Apparently Niger-Congo is the family with the most members, so that's
not too surprizing.

So, you want to create a prefix or series of prefixes for each of (how
many? more than a hundred?) families?
Is it really worth going to all that trouble? What's the advantage,
over just using bang-, ban-, baur-?

I don't think it would take 100, but I'm not sure of the specific number; in part, this is because our decisions about how to group things could change the number.  As I mentioned yesterday, we could split Niger-Congo into Bantu and, basically, "other" Niger-Congo. Likewise with Chinese (which, linguistically, is either a worthless term, or a family and not a language).  There are only five or six major ones on the list that I've been looking at, but if we keep to the highest level classifications possible, it shouldn't be too bad.

I think using the language families has any number of advantages.  First, I was envisioning this as something that would be both useful to linguists and easily learnable.  I think a list of alphabetized language names in Lojban would be really scary, and possibly worthless, if they all started exactly the same (granted, you could sort some other way, but still).  An alphabetized list with family names at the beginning, though, would actually group languages together by family.  Plus, I really just think learning words which are half the same as any other word for any other language is going to make learning language names REALLY difficult, and thus likely cause these to never be adopted.

 

> but it does illustrate, as
> do the examples from .xorxes., the idea of different initial elements.  So,
> Niger-Congo might be {nirk} when the ISO is V initial, {nirko} when it is VV
> initial, etc....

If you do that, how do you distinguish code "aab" from code "oab"?
"nirko'abu" could be either. (At least if they both happen to be in
the same family.) And why would you want to change the vowel?

Er, right, I think I mistyped.  {nirk} would probably be for any vowel-initial root (I haven't tried this out yet, but that is my sense).  And I didn't change the vowel, I put it on the wrong line, I think: {nirko'abu} would be, in the system I proposed earlier, for language code abu, not aab.  If we take {nirk} for any vowel-initial root, we'd have nirka'abV here.

> aaa -> nirka'a'a' (cf. banga'a'a)
> aab -> nirko'abu (cf. banga'abu)
> aba -> nirkaba or ... (cf. bangabu'a)

I could do "bangaba" too. The reason I prefer "bangabu'a"is that this
way every language name has four syllables. But if giving three
syllables to languages with VCV codes does not violate neutrality,
that can be done.

I don't think length violates neutrality--even if it does, we can't do much about it given the restrictions of Lojban phonotactics.

 

> abb -> ... bangabubu
> baa -> ... banbu'a'a
> bab -> babnicV or nirbabV (cf. banbu'abu)

"nirbabV" works with a nir- family code, but it wouldn't work with
other family codes.

 

> bba -> ... banbubu'a
> bbb -> tagbVbVbV (cf. banbububu)

tag- won't work for codes that begin with voiceless consonants.

Then tak- before a voiceless; or, language family names are carefully constructed so as to always end in a sonorant.  Or some use their longer for here (tagnukVkVkV, say, for kkk).  Or, the language family names are done in such a was to always have something that would make a nasty cluster.

[Jorge Llambías]

On Sat, Apr 3, 2010 at 12:50 PM, Christopher Doty <suomi...@gmail.com> wrote:
>
> I don't think it would take 100, but I'm not sure of the specific number;

Wikipedia says ISO 639-5 has 114 codes for language families:
http://en.wikipedia.org/wiki/ISO_639

> in
> part, this is because our decisions about how to group things could change
> the number.  As I mentioned yesterday, we could split Niger-Congo into Bantu
> and, basically, "other" Niger-Congo. Likewise with Chinese (which,
> linguistically, is either a worthless term, or a family and not a language).
>  There are only five or six major ones on the list that I've been looking
> at, but if we keep to the highest level classifications possible, it
> shouldn't be too bad.

But if we go with ISO for languages, it's hard to justify using a
different arbitrary preference for families.

> I think using the language families has any number of advantages.  First, I
> was envisioning this as something that would be both useful to linguists and
> easily learnable.  I think a list of alphabetized language names in Lojban
> would be really scary, and possibly worthless, if they all started exactly
> the same (granted, you could sort some other way, but still).  An
> alphabetized list with family names at the beginning, though, would actually
> group languages together by family.  Plus, I really just think learning
> words which are half the same as any other word for any other language is
> going to make learning language names REALLY difficult, and thus likely
> cause these to never be adopted.

It's only the first out of four syllables that is common to all. And
the other three syllables correspond each to one of the letters of the
code, so if you know the code you know the fu'ivla, and vice versa.

> I don't think length violates neutrality--even if it does, we can't do much
> about it given the restrictions of Lojban phonotactics.

With my proposal every language uses four syllables. The number of
letters varies slightly if you don't count the apostrophe, and
depending on the three prefixes.

[Christopher Doty]

2010/4/3 Jorge Llambías <jjlla...@gmail.com>

On Sat, Apr 3, 2010 at 12:50 PM, Christopher Doty <suomi...@gmail.com> wrote:
>
> I don't think it would take 100, but I'm not sure of the specific number;

Wikipedia says ISO 639-5 has 114 codes for language families:
http://en.wikipedia.org/wiki/ISO_639

Yeah, but there are codes for any number of subfamilies included in that number.  So, for example, there is a Niger-Congo code, but also a Bantu code; there is an Afro-Asiatic code, but also codes for Berber, Semitic, etc.  We wouldn't need to have all of these; we'd just pick a level (highest or otherwise) and only use it.  We'd need (totally educatedly guessing) 20 max, with maybe a couple more for things like Basque that aren't clearly placed in a family.

 

> in
> part, this is because our decisions about how to group things could change
> the number.  As I mentioned yesterday, we could split Niger-Congo into Bantu
> and, basically, "other" Niger-Congo. Likewise with Chinese (which,
> linguistically, is either a worthless term, or a family and not a language).
>  There are only five or six major ones on the list that I've been looking
> at, but if we keep to the highest level classifications possible, it
> shouldn't be too bad.

But if we go with ISO for languages, it's hard to justify using a
different arbitrary preference for families.

I don't think it's THAT hard to justify (although a little bit, maybe :p).  The language family name is something that people won't really need to look up languages by, as such, but could still tell you what family a language belongs to.  Plus, while most of the ISO codes for language families are pretty good, some are really stupid (Austronesian is "map"???); I'm not sure there's a disadvantage to changing that, especially since it will show up a bunch of times in the system.

 

> I think using the language families has any number of advantages.  First, I
> was envisioning this as something that would be both useful to linguists and
> easily learnable.  I think a list of alphabetized language names in Lojban
> would be really scary, and possibly worthless, if they all started exactly
> the same (granted, you could sort some other way, but still).  An
> alphabetized list with family names at the beginning, though, would actually
> group languages together by family.  Plus, I really just think learning
> words which are half the same as any other word for any other language is
> going to make learning language names REALLY difficult, and thus likely
> cause these to never be adopted.

It's only the first out of four syllables that is common to all. And
the other three syllables correspond each to one of the letters of the
code, so if you know the code you know the fu'ivla, and vice versa.

Right, but because of the various forms of {bangu}, the alphabetization is still going to be wonky; personally, I would never, ever want to look at a list of any number of things that all start with the same syllable; it would make it very hard to find anything.  And, really, a single syllable that's the same is not the issue--it's that it's the FIRST syllable.  This makes words seem much more similar, because of the way speech is processed, than a list of words that all ended in the same syllable.  It would present a rather difficult issue in terms of learning.  And, in terms of being able to read a paper comparing three languages and keeping straight which is which, then if they were all more different from each other.

Chris

[symuyn]

Small questions:

1. For language fu'ivla, which part of ISO 639 is being used: 639-2 or
639-3? (I prefer 639-3, since it's basically the same as 639-2 except
more robust.)

2. For country fu'ivla, why would using ISO 3166-2 (three-letter
codes) be worse than 3166-1 (two-letter codes)? The three-letter
codes:
A. Resemble their autonyms more
B. Are more future-robust
C. Would have the same algorithm as the languages, except for the n/
g exception (I think).

On Apr 3, 8:45 am, Jorge Llambías <jjllamb...@gmail.com> wrote:

[Christopher Doty]

Both .xorxes. and I have been using the 639-3, so that it would work for any language.

Chris

-- Sent from my Palm Pre

---

[Leo Molas]

On 04/03/2010 04:16 PM, symuyn wrote:
> Small questions:
>
> 1. For language fu'ivla, which part of ISO 639 is being used: 639-2
> or 639-3? (I prefer 639-3, since it's basically the same as 639-2
> except more robust.)

As chris said, we were always using iso 639-3

>
> 2. For country fu'ivla, why would using ISO 3166-2 (three-letter
> codes) be worse than 3166-1 (two-letter codes)? The three-letter
> codes: A. Resemble their autonyms more B. Are more future-robust C.
> Would have the same algorithm as the languages, except for the n/ g
> exception (I think).

I didn't found iso 3166-2 as a three letter code. What I found is a
variable letter code with two places, one for the 3166-1 code, and
another one for territories of that country. It even has alpha-numeric
codes... so, it's complicated.

Quote from the page:
> ISO 3166-2 contains a complete breakdown into a relevant level of
> administrative subdivisions of all countries listed in ISO 3166-1.
> The code elements used consist of the alpha-2 code element from ISO
> 3166-1 followed by a separator and a further string of up to three
> alphanumeric characters e. g.
>
> DK-025 for the Danish county Roskilde
> IT-MI for the Italian province of Milano
> MG-T for the Antananarivo province in Madagascar

http://www.iso.org/iso/country_codes/background_on_iso_3166/iso_3166-2.htm

Right now, there are 676 (26 ^ 2) possibilities for countries, and 246
used codes. I think it's future robust as it is.

mu'o mi'e .leos.

[Jorge Llambías]

On Sat, Apr 3, 2010 at 4:16 PM, symuyn <rbys...@gmail.com> wrote:
>
> 2. For country fu'ivla, why would using ISO 3166-2 (three-letter
> codes) be worse than 3166-1 (two-letter codes)? The three-letter
> codes:
>  A. Resemble their autonyms more
>  B. Are more future-robust
>  C. Would have the same algorithm as the languages, except for the n/
> g exception (I think).

In addition to what Leo said, a three letter code could not use quite
the same algorithm for countries, because of the pecularities of the
gismu "bangu" and "gugde".

For codes that begin with a vowel, a bang- or gugd- prefix are equally usable.

For codes that begin with a consonant however, ban- is much more
effective than gug-, for two reasons: any consonant except "n" can
follow "n", and "nC" is never a permissible initial. After "gug-" a
much more limited set of consonants can follow, and also "gr" and "gl"
are permissible initials, which will cause the leading "gu" to fall
off in most cases. e.g. gugru'usu -> gu gru'usu.

Another advantage that "bangu" has is its "bau" rafsi, which allows us
to use "baur-" as a meaningful prefix when the code starts with "n" or
"g".. For gugde we can use "gu'er-" too, but that means adding one
syllable, and also it would not be just for two consonants but for c,
d, f, g, h, k, l, p, q, r, s, t, x, and we would even have to make an
exception to the exceptions and use "gu'en-" when the code starts with
"r". So, a lot more "exceptional" cases (in fact more than the
non-exceptional ones: b, j, m, n, v, w, y, z).

We were quite lucky with "bangu" and its two rafsi.

[Michael Turniansky]

On Fri, Apr 2, 2010 at 3:24 AM, Oren <get....@gmail.com> wrote:
> right. i guess the code doesn't belong in a sumti place.
>
> On Fri, Apr 2, 2010 at 11:57, Pierre Abbat <ph...@phma.optus.nu> wrote:
>> On Thursday 01 April 2010 21:35:38 Oren wrote:
>>> > Lojban day-to-day: What do we say for Sweden and Swedish?
>>>
>>> sweden: { gugde la .sy .ebu }
>>> swedish: { bangu la .sy .vy }
>>
>> Doesn't parse (try "gugde la me sy.ebu"). And are the people of Cyprus
>> speakers of Welsh?
>>
>> Pierre

I didn't see anyone comment on this (unless they did so in a
different thread), but I don't think Oren understood what Pierre was
saying. "gugde la sy .ebu" isn't grammatical, because "sy. ebu" is a
pro-bridi. When you stick a "la" in front of it, that means "the one
named ____ associated with SE". But since we don't have a cmevla or
selbri following after, the blank is unfilled, and therefore fails
grammatically. (An example might make this clearer: "gugde la sy .ebu
gerku" means "(something is) a country inhabited by SE's Dog" (where
"Dog" here is a name of someone/soemthing, not necessarily a dog,
somehow associated with who-/whatever "SE" is standing in for).

Pierre's objection had no objection to the place that "la sy ebu"
was in (although you are correct Oren, that the place didn't make much
sense). Pierre's corrected version was "a country those named
"SE'ers" which makes more sense.

--gejyspa

[Pierre Abbat]

On Wednesday 07 April 2010 16:25:14 Michael Turniansky wrote:
> I didn't see anyone comment on this (unless they did so in a
> different thread), but I don't think Oren understood what Pierre was
> saying. "gugde la sy .ebu" isn't grammatical, because "sy. ebu" is a
> pro-bridi. When you stick a "la" in front of it, that means "the one
> named ____ associated with SE". But since we don't have a cmevla or
> selbri following after, the blank is unfilled, and therefore fails
> grammatically. (An example might make this clearer: "gugde la sy .ebu
> gerku" means "(something is) a country inhabited by SE's Dog" (where
> "Dog" here is a name of someone/soemthing, not necessarily a dog,
> somehow associated with who-/whatever "SE" is standing in for).
>
> Pierre's objection had no objection to the place that "la sy ebu"
> was in (although you are correct Oren, that the place didn't make much
> sense). Pierre's corrected version was "a country those named
> "SE'ers" which makes more sense.

My other point is that it doesn't make sense to use "la me <two-letter code>"
for the people of a country or the speakers of a language, since "bangu la me
cy.ybu" is Welsh and "gugde la me cy.ybu" is Cyprus, and the Cypriots
generally don't speak Welsh, so what "la me cy.ybu" means when not preceded
by one of those words is quite unclear.

What kind of facilities should Greeks and Turks have?
Cypriot but equal.

Pierre
--
Don't buy a French car in Holland. It may be a citroen.