Sound changes

← Guide index · 中文 · fourth item in the navigation bar

The Sound changes page manages rule sets. A rule set is a piece of rule text — class declarations, digraphs, stage snapshots and rules — applied from top to bottom. The same rule language is also used for orthography transcription, script mapping and the morphophonemic rules in paradigms, so the syntax described on this page applies throughout the app.

1. Rule sets

The tab bar at the top lists every rule set in the project; click to switch, and press and drag to reorder. New rule set creates an empty one; Import reads Yinbianji’s three files, Lexicanter pronunciation rules, Zompist SCA² or plain text (see section 6); Export saves the current rule set, or saves every rule set as its own .txt in a folder. Rename, write notes or delete (undoable) in the inspector.

The rule text itself is the single source of truth; the three views are just different editors:

• Rule list (default): one card per rule, numbered from 1 (only rule lines are counted; comments and declarations don’t take a number). Click a card to expand its form: target, replacement, several environments, exceptions and a comment. Above the cards is a panel for classes and digraphs where you can add and remove them directly; press a chip and drag it onto another to move that declaration line to its position. Selecting a rule makes the test bench show intermediate results “up to this rule”, and the card plays a small animation of a sample word changing. Rule cards can be dragged into another stage or in front of another rule; while dragging, a dashed gap opens where the rule will land, and releasing inserts it there.
• Chain graph: a mind-map of stages and rule chains; click a node to jump to it.
• Source: a text editor with line numbers and highlighting. Syntax errors are marked in red and warnings in yellow on each line, all diagnostics are listed at the bottom, and clicking a line number jumps there.

The status bar at the bottom shows the number of rules, stages, classes and diagnostics, plus Export as text and Evolve lexicon. The complete rule syntax is in section 4 of this page (the User guide button next to the title goes straight there).

2. Stage snapshots and language bindings

-* name records the word form at the moment that line is reached and gives it a name. The test bench shows one column per stage; Languages for stages in the inspector binds each stage to a language in the project. Bindings are used for:

• The paradigm step that runs sound changes after concatenation can specify which stage to derive from and to.
• Lexicon evolution uses the language of the first bound stage as the default source and the last as the default target.
• When the rules are parsed, the classes and digraphs of the first bound language are used as the base.

3. Test bench (inspector)

• Words: one per line (spaces also separate); saved with the rule set.
• Results: one row per word with a column per stage; cells that changed are highlighted. Click a row to see its trace: every rule that applied, the form before and after, and the stage it belongs to. Click a rule number to jump to that line in the editor.
• When a rule is selected in the list view, the results switch to the intermediate forms “up to rule n”.

4. The rule language

4.1 What a rule text can contain

; a semicolon starts a comment that runs to the end of the line; a # at the start of a line is also a comment (for old files)
V=aeiou                 ; single-letter class: members are split by character
{Vlong}=ā ē ī ō ū       ; long-named class: members separated by spaces or commas; with no separators, split by character
th|θ                    ; digraph: th is treated as one unit θ while matching, and turned back on output
-* Proto                ; stage snapshot: record the current form under a name
a > e / _i              ; a rule
-* Modern

Rules are applied from top to bottom; each rule matches repeatedly from left to right across the whole word. Class and digraph declarations can appear anywhere and apply to the whole text. Classes and digraphs defined on the Phonology page are available automatically; a declaration with the same name in the text overrides them.

4.2 A rule

target > replacement / left0_right0 , left1_right1 , … - leftExc_rightExc , leftExc_rightExc …

Inside / outside the environment: write one ? in the target or replacement and the rule splits into two branches — what comes before ? applies where the environment matches, what comes after it applies everywhere else.

a and b can be any kind of replacement: class correspondence ([ptk] > [bdg]?[fθx] / V_V), \ metathesis, 2 gemination, or empty for deletion; metathesis inside and gemination outside is written \?2. “Inside” means matching any one of the environments and not falling in an exception; every other position counts as outside. Both branches look at the word as it was before this rule and are applied in one go; where both branches match the same spot, the inside branch wins. Target and replacement can each contain only one ?; a ? inside an environment still means “anywhere in between”. To write a literal question mark, use \?.

4.3 Symbols in environments

Characters without special meaning in environments go straight into the regular expression, so things like | can be used directly; conversely, put a backslash in front of +, * and similar characters to match them literally (\+, \*).

A one-page summary of the rule syntax is always available inside the app: Rule syntax on the start page, or the open-book icon at the top right of the top bar (between the inspector toggle and Close project), opens it in the inspector; opened from the Sound changes, Paradigms, Script, Phonology or Morphemes page, it scrolls straight to the relevant section.

4.4 Example

V=aeiou
{Vlong}=ā ē ī ō ū
C=ptkbdgmnlrsh
-* Proto
e > a / _h , h_          ; e becomes a next to h
V > {Vlong} / _#          ; word-final vowels lengthen
h > / V_V                 ; h is lost between vowels
> e / #_[nm]C             ; e is inserted before a word-initial nasal + consonant
bm > \ / _                ; bm metathesises to mb
p > pp / V_V - _#         ; p doubles between vowels, but not word-finally
-* Modern

4.5 Common patterns

5. Diagnostics

An undefined class produces a warning and is treated as literal characters; a missing >, an environment without _ and the like produce an error, and the line is skipped. Diagnostics are shown line by line in the source view and listed at the bottom; when there are errors, the status bar shows a red count.

6. Importing other formats

After picking the files, you first confirm the rule set name and file format in the import panel in the main area (you can change the format if it was guessed wrong), while the inspector shows the converted rule text. Changing the format re-converts immediately, and changed lines are highlighted and then fade. The rule set is only created when you click Import.

7. Evolving the lexicon

The Evolve lexicon button at the bottom opens a panel that runs every entry of the source language through the current rule set into the target language, creating etymology links automatically. Headwords containing spaces are evolved word by word (just like the test bench).

The workflow is Preview (a table listing input, output, the existing word in the target language, and the action: create / update / unchanged / skip) → Write to target. New words get the etymology type “inherited (sound change)”, with their source pointing to the source entry or morpheme; the input form is recorded, and the notes carry the rule set’s name. The whole inheritance chain then shows up in the lexicon’s relation graph.

8. Connections to other modules

• Classes and digraphs can come from the Phonology page; @morpheme references come from the Morphemes page.
• Once stages are bound to languages, both the paradigm step that runs sound changes and lexicon evolution use them.
• Orthography rules and script mapping rules use the same syntax but are stored separately.