I had in mind an auxlang.  Obviously I wouldnt be the one deciding this by myself, but my preference would be to emphasize practicality and to use a prototyping methodology (from software engineering), or perhaps a blitzkrieg methodology.

In blitzkrieg, if you encounter any resistance that puts up a good fight, the strategy is to surround them with the minimum number of troops necessary to contain them, and then proceed to attack the next target.  The idea is, you isolate your resistance and then keep pushing into the heart of the enemy territory to destroy their infrastructure.  (I suspect getting bogged down with a particular detail might kill a young auxlang project.)

This is what I would tend to do with an auxlang.  If there is one particularly difficult problem, simply set it aside for a while and implement an easier imperfect solution.  Once the language is progressing nicely, then go back and tie up any loose ends.  Also I would tend to emphasize practicality over seeking an increasingly difficult to achieve ideal (effort becomes increasingly difficult as we seek to approach perfection).

For example, rather than get hung up on what alphabet to use, I would determine the number of characters in the alphabet and then simply declare that we're putting that off to the side for a moment.  The interim solution would be that each culture can use its own alphabet or some variation of it to display those characters, and that eventually a universal character set would be introduced.  In the meantime, at least communication across languages would only involve learning a new character set.

For practical reasons I would have simply said "use the english character set because most people use english keyboards and it is extremely tedious to use non-english characters with current keyboards" and also that for the most part english characters are minimalist and easy to write and distinguish from one another.  However, for the sake of those who would advocate a completely unique system to avoid eurocentrism, I would propose the above solution.

Also I am not really interested in creating a "bloblang", that is, a language with a 120 character alphabet that can represent the precise phonetics of every language on earth (and probably more if the language is expected to be able to isolate accents, higher/lower "voice"/pitch like ancient greek had, etc.).  My opinion is that there should be some threshhold for similarity.

If there is another "e" that sounds 98% like "e" but has some strange quality that makes it technically different, I really dont think it's worth putting that into the language.  Let regions have their accents, let people's pitch be a little bit different.  As long as they are able to understand each other across borders, we've done our job.  Also I don't like the idea of having to concentrate very hard on speaking.  It's nice to be able to speak lazily and not accidentally tell someone "your daughter is a pig's tooth at the lake" instead of "how are you today?".

In other words, I'm comfortable with symbols being a reasonable approximation of a few distinct sounds, and I suppose the threshhold of similarity would need to be determined.  I'm also comfortable with leaving out a few sounds, due to their being extremely uncommon and perhaps not used at all in the language.  However, I do have an alphabet that accomodates clicks and taps, and the common sounds of most languages I'm aware of, and does so phonetically.  (Phonetically as in, consonant combinations are not used to create sounds that are not created by naturally pairing those consonants, etc.)

Just because we're trying to create an international language doesn't mean we need to include every existing language.  The point could merely be to create a new language without a particular bias to a nation.  That we do not include one or two sounds from a particular language is not an intended assault on that language, and to include those sounds when they would otherwise not be included in a nearly-ideal language would represent an improper bias.

Jim Henry <[log in to unmask]> wrote: On 5/31/07, Douglas Treadwell  wrote:
> Is anyone here currently building a conlang?  Is anyone interested in a collaborative effort to develop a conlang?  I have a few thoughts about how to resolve the issues that usually slow down progress on collaborative projects.

I've been involved in several collaborative conlang projects at one
time or another.  The most interesting and enjoyable of the lot was
Kalusa, which was developed using a corpus management engine
built by Gary Shannon, plus (later) a message board and mailing list.
The others, still interesting but not as intensely so as Kalusa,
were built at (which ran on Drupal) before its demise,
and on another conlang wiki, whose name I can't recall.

It seems to me that a collaborative conlang would do well
to use a combination of an archived mailing list, a wiki to document
the results of decisions made on the list, and some other tools
(like a database, and perhaps the Kalusa engine) to manage
the lexicon and corpus.  Trying to manage everything with
just a mailing list makes a huge barrier against new people
coming in and getting up to speed; trying to manage discussions
as well as document the current state of the language on
a wiki is more cumbersome than a mailing list.

Gary Shannon seems to have dropped off of the Internet or at least
the conlang lists, but you could probably get the source code for
the Kalusa corpus management engine from David J. Peterson, who
uses it to document some of his conlangs on his personal site.

What kind of conlang are you aiming to build?  Artlang, auxlang,

Jim Henry