|
I suggest using the more powerful SCA² instead. It has many more features, works in your browser, and supports Unicode.
The program is available in three forms. Please note: right-click on the links to the executables, pick Save Target As, and save them to your disk.
For instance, sounds will take the two input files on the left and produce the output file on the right:
latin.lex port.sc port.out
sounds latin port control-parameters
The control parameters are one of the following: -p -b -l -f -.
-p tells sounds to print out which rules apply
to each word:
s-> /_# applies to secundus at 7
-b prints the output
with the original word in brackets (suitable for using as the basis of a lexicon with etymologies):
leitor [lector]
Without this parameter, the output looks like this:
lector --> leitor
-l overrides -b if present) and
omits the source word from the output, leaving only output words, like this:
leitor
The resulting output file is suitable for use as a new .lex file.
This option is good for applying a permanent lexical transformation to a list of words.
-f directs output to the output file only, rather than to both the screen and the file. This option is useful for very long vocabulary lists.
The first two non-control parameters are taken as filenames: the first gives the name of the .lex file, containing the lexicon; the second gives the name of the .sc file, containing the sound changes or lexical rules to apply. The extensions should be left off.
I find myself running the program multiple times, tweaking the rules or the vocabulary in between runs.
Common Windows problems
To use command line parameters you have to have a command line. That means running the program in a command window. Look under Programs/Accessories and run Command Prompt. Now type cd plus the name of the directory where you downloaded sounds-- e.g. cd c:\downloads\. As with all commands in the command prompt, hit Enter. Now you can run sounds as described above.
If sounds says your file could not be read in and you're sure it's there-- you probably have file extensions turned off, and what you think is a .lex or .sc file is really a Notepad (.txt) file. The easiest thing to do is to re-save the file as a real .lex file. In Notepad, for instance, change the "Save as type" dropdown to "All files" instead of "Text documents". Then it won't add .txt to your file name. If you've done this right, the file won't have the Notepad icon, and if you double-click it Windows will ask what app to open it with; select Notepad.
Variable definitions should come first, one per line; then sound changes, one per line. A line beginning with * will be taken as a comment and ignored.
More generally, a sound change looks like this:
x/y/z
where x is the thing to be changed,
y is what it changes to,
and z is the environment.
The z part must always contain
an underline _, representing the
part that changes. That can be all there is, as in
gn/nh/_
which tells the program to replace gn with nh unconditionally.
The character # represents the beginning or end of the word. So
u/o/_#
means to replace u with o, but only at the end of the word.
The middle (y) part can be blank, as in
s//_#
This means that s is deleted when it ends a word.
The environment (the z part) can contain variables, like V above. These are defined at the top of the file. I use capital letters for this, though this is not a requirement. Variables can only be one character long. You can define any variables needed to state your sound changes. E.g. you could define S to be any stop, or K for any coronal, or whatever.
So the variable definition and rule
F=ie
c/i/F_t
means that c changes to i after a front vowel and before a t.
You can use variables in the first two parts as well. For instance,
suppose you've defined
S=ptc
Z=bdg
S/Z/V_V
This means that the stops ptc
change to their voiced equivalents bdg
between vowels. In this usage, the variables must correspond one for one--
p goes to b,
t goes to d,
etc. Each character in the replacement variable (here Z)
gives the transformed value of each character in the input variable (here S).
Make sure the two variable definitions are the same length!
A variable can also be set to a fixed value, or deleted. E.g.
Z//V_V
says to delete voiced stops between vowels.
Rules apply in the order they're listed. So, with the word opera and the rules
p/b/V_V
e//C_rV
the first rule voices the p, resulting in obera; the second
deletes an e between a consonant and an intervocalic r,
resulting in obra.
The -p command line parameter can assist in debugging rules, since it causes the output to show exactly what rules applied to each word.
One or more elements in the environment can be marked as optional with parentheses. E.g.
u/ü/_C(C)F
says to change u to ü
when it's followed by one or two consonants and then a front vowel.
For instance, you may wonder whether the .lex file should be
based on spellings or phonemes. It doesn't matter: the program
applies its changes to whatever you give it. In my example I used
conventional spellings, but I could just as easily have used
a phonemic rendering. Similarly, I wrote the rules to output
orthographic Portuguese, simply to make for an easy example.
It would be better to output a phonetic representation.
This would help us realize that we really need a sound change
k/s/_F
that would handle the change from civitatem with /k/ to cidade with /s/.
The program will handle whatever you put into the .lex and .sc files, including accented characters. If the language you're working with requires a special font, simply edit the source and output files with an editor, using that font. This would allow you to use (say) an IPA font.
To improve my Latin-to-Portuguese file, for instance, I would certainly want to handle vowel length and stress. I might use accented vowels for this. Of course the program knows nothing about phonetics, so you have to remember to define the variables to match how you've set up the .lex file. If you use accented vowels, you will want to change the definition of V.
Though sound changes can refer to digraphs,
variables can't include them. So, for instance, the following rule is
intended to delete an i onset following an intervocalic consonant:
i//VC_V
However, it won't affect (say) achior,
because the C will not match the digraph ch.
You could write extra rules to handle the digraphs; but it's often more convenient
to use an orthography where every phoneme corresponds to a single character.
You can write transformation rules at the beginning of your sound change list
to transform digraphs in the input file:
ph/f/_
For an example, you can download a vocabulary of Methaiun and the sound changes for Kebreni (right-click!). You can compare this to the Kebreni grammar in Virtual Verduria.
For me, there is a peculiar, intense pleasure in creating a daughter language with a particular feel to it, merely by altering the set of sound changes. All I can think of to compare it to is creating new animals indirectly, by mutating their DNA.
What sort of sound changes should you use? You can examine the history of any language family for ideas. Some common changes that can form part of your repertoire (with some sample sounds rules):
I pay particular attention to the havoc the sound changes are likely to wreak on the inflectional system. E.g. if a case distinction is maintained in some words and lost in others, it may spread to the second category by analogy.
Sound changes can also result in homonyms. For instance, if you voice intervocalic consonants, meta and meda will merge. You can simply live with this, but if the merger is particularly awkward, the users of the language are likely to invent a new word to replace one of the homonyms. E.g. Latin American Spanish has innovated cocinar 'to cook', since the original cocer has merged with coser 'to sew'.
Most people think English spelling is hopeless; but in fact the rules predict the correct pronunciation of the word 60% of the time, and make only minor errors (e.g. insufficient vowel reduction) another 35% of the time.
