Conlangjugator

[Zju]

A sound change applier. It has features not present in many other similar programs, such as defining custom conjugation and declension patterns.

Use cases:

• Word generation - a broad pattern of word shapes can be generated randomly, with phonotactics applied in the process. Relative frequencies of phonemes are also configurable.
• Applying sound changes to word lists - the bog standard feature present in every SCA, but also there's support for reduplication, metathesis, irregular sound changes among other things.
• Applying inflection templates to words - that means entirely custom inflections are configurable, which then can be applied to each and every word in a wordlist.
• Inspecting how inflections change after predefined sound changes - same as above, but before final output, a list of soundchanges is applied to every wordform, adding for the possibility to study how morphology changes over time.

Download and more information at the project page.

[vegfarandi]

Very cool. I'll definitely need some time to wrap my head around how to use, but seems like I could make something with this.

[Vardelm]

Sounds cool. Once I'm done with projects for classes in the next couple weeks I may play around with this.

--Edited because apparently I need to take some English classes.

[Man in Space]

Looks nice! I'll have to tinker around with it some.

[Ælfwine]

I'll definitely make use of this, thanks!

Out of curiosity, Zju, could I edit the font used in the program manually? I use a specific font for linguistic purposes called ZRcola, which is able to handle a boatload of diacritics, and I want to see if I can apply it to the program.

Second issue: I am modelling a sound change where every odd schwa, starting from the final position, is deleted. But when I execute the command ə>/_/rtl odd to my words (tənəkə, pȍľəmə, gȏrdə) I get tənkə, pȍľmə, and gȏrd. If properly executed though, shouldn't it be tnək, pȍľəm, gȏrd?) I find this strange, as the command /rtl even gets me the desired result instead.

Finally, have you considered implementing something like a wildcard? It would be very useful for modelling umlaut and accentual changes.

[Zju]

Heads-up: I've fixed a bug related to adding segments. Now that feature can be used.

I'll definitely make use of this, thanks!

Out of curiosity, Zju, could I edit the font used in the program manually? I use a specific font for linguistic purposes called ZRcola, which is able to handle a boatload of diacritics, and I want to see if I can apply it to the program.

Second issue: I am modelling a sound change where every odd schwa, starting from the final position, is deleted. But when I execute the command ə>/_/rtl odd to my words (tənəkə, pȍľəmə, gȏrdə) I get tənkə, pȍľmə, and gȏrd. If properly executed though, shouldn't it be tnək, pȍľəm, gȏrd?) I find this strange, as the command /rtl even gets me the desired result instead.

Finally, have you considered implementing something like a wildcard? It would be very useful for modelling umlaut and accentual changes.

Firstly, you should have posted again instead of editing your post. I'm seeing your questions only now that I'm returning for something else.

You can change the font. Open conlangjugator.html with a text editor and find the portion of the text that reads

Code: Select all

table, th, td {border: 1px solid gray;}
</style>

replace it with

Code: Select all

table, th, td {border: 1px solid gray;}
div, textarea
	{
	font-family: "ZRcola";
	}
</style>

and you should be all set up. Save the document and refresh the page in your browser. In general knowing not that much html and css will get you a long way in modifying the looks and feels.

As for the words, it might be counterintuitive how it operates in hindsight. Firstly, if there's only one match, it gets executed no matter what. But then the first match is counted as position 0, not as position 1. So for the program it's e.g. t2n1k0.
To get what you want try with ə>//rtl even (no need to even include the underscore if there's no condition).

There's a wildspace character, kinda. It's the four characters [^ ], including the whitespace in between.

For quick tests if a conditions is correct, you can use this site. Just substitute # with [\s,.] and add an interval before and after each word. But groups and segments of more than one character won't be treated correctly, so keep in mind that. For groups, you can use e.g. [aouei] instead.

If you want to delete some segments in a group you can use CE = p t k, CD = b d 0 and then CE > CD / V_V

[Ælfwine]

Thanks for the reply!

I looked up your activity and saw that you weren't active since before I posted, ergo the edit. (Additionally, I've been to forums which banned or limited double-posting, although it seems to be tolerated here.)

Thank you for showing me how to edit the font. It makes it a lot easier to use precomposed characters with multiple diacritics.

Thank you also for the wildcard "string." Perhaps if I may make a suggestion, making a list somewhere with all the special strings/characters and their functions would be helpful.

[Zju]

Thank you also for the wildcard "string." Perhaps if I may make a suggestion, making a list somewhere with all the special strings/characters and their functions would be helpful.

As the program uses regular expressions, there's less of a list with all special strings and more of a grammar. Really those special strings are much like conditions or parts of conditions used in sound change notation and the two grammars - that of conditions in sound change notation and that of regexes - coincide somewhat. E.g. the behaviour of ? + * is the same. Infact, conditions in sound change notation are almost a perfect subset of regular expressions.
As for the regex rules, you can look them up, lots of resources on that topic out there.

[Ælfwine]

Thank you also for the wildcard "string." Perhaps if I may make a suggestion, making a list somewhere with all the special strings/characters and their functions would be helpful.

As the program uses regular expressions, there's less of a list with all special strings and more of a grammar. Really those special strings are much like conditions or parts of conditions used in sound change notation and the two grammars - that of conditions in sound change notation and that of regexes - coincide somewhat. E.g. the behaviour of ? + * is the same. Infact, conditions in sound change notation are almost a perfect subset of regular expressions.
As for the regex rules, you can look them up, lots of resources on that topic out there.

Okay, I looked it up. I'm not a programmer, so some of the terminology is quite obfuscating to the layman. Still, I am interested in learning something.

Alright, a few more questions that I am stuck with, and I'll stop pestering you.

I'm trying to recreate this code from SCA2:

o > ò / ò(C)(C)(C)_
ò > o / _(C)(C)(C)ò

Though groups of optional characters don't work the same way in Conlangjugator. Now, regex tells me the character for optionality is ? but the string doesn't seem to work properly, adding in random spaces and whatever. What should I do?

Secondly, assume I replace o with category V and ò with category V̀. Unfortunately, Category V is larger than V̀, and in SCA2 I could replace each corresponding character with that of the other category, but I can't do that here. What is the best solution? (NB: I bet I could easily use ad hoc groups like [] but that gets messy.)

Final question: I assume Regex/Conlangjugator is capable of rewrite rules?

[Zju]

That's right, parentheses have other uses here, they don't mark optional segments. Take your pick:

Code: Select all

o > ò / òC*_
o > ò / òC?C?C?_
o > ò / òC{0,3}_

Note the lack of spaces in the conditions. Adding spaces will break the syntax.

adding in random spaces and whatever. What should I do?

You can always check the log to get more information what's happening at certain point of execution.

Group names should be caps only. If there are combining diacritics or other non caps elements, they're not guaranteed to work correctly. But you can use e.g. Ù

When groups are of different size, corresponding characters are still replaced, but those that don't correspond to anything are substituted with the last one in the group.

>>clear groups
>>add group: V = a y o u e i ei ou
>>add group: VSTR = à ỳ ò ù è ì
V > VSTR
>>add

changes ayoueoieiou to àỳìèòììì

To get around this, replace the third line with

>>add group: VSTR = à ỳ ò ù è ì è ò

It's otherwise identical operation, but helps you get the correspondances right.

(NB: I bet I could easily use ad hoc groups like [] but that gets messy.)

Not yet supported feature.

What are rewrite rules?

[Ælfwine]

Re: Combining diacritics

The primary reason I use ZRcola is that I can make a lot of different precomposed characters that wouldn't be possible on regular fonts. Here I have to decouple them just to show them.

This seems to work:

V>V̀/V̀C{0,3}_
V̀>V/_C{0,3}V̀
ь>ə
ъ>ə
ə>//rtl even

gòtovъ > gotòv

I have to look into why the ? character doesn't work. I suspect that my other sound shifts have to do something about it (I applied the above in isolation, with the additional category V̀ = à ỳ ò ù è ì)

Re: Rewrite rules

I'll let Mark explain this one for me on his site:

Rewrite rules
These allow you to apply global substitutions to the input and output. The most important use is to allow digraphs.

If you use digraphs, you must follow the rules in this section. SCA² won’t handle digraphs properly on its own.

Rules with diagraphs will work so long as they can be treated as sequences of characters. For instance, these all work fine:

c/ch/_a
sh/zh/V_V
u/o/_ng

But you can’t define categories with digraphs. E.g. this was probably intended to define three fricatives kh sh zh

F=khshzh

but in fact it defines the F category as k h s h z h, which won’t at all do what you expect.

The old SCA required that you use single characters instead. E.g. you might write

F=xßΩ

That still works, but you can use rewrite rules instead. E.g. define some rules like this:

kh|x
zh|ž
sh|š
ng|ŋ

Now you can use kh zh sh ng in any of the other input boxes— categories, sound changes, input lexicon. The SCA will apply the rewrite rules to provide single characters it can work with, and then apply them again backwards to provide output using digraphs.

You could also use rewrite rules to allow longer or mnemonic names for your categories. E.g.

<front>|F

Now you could write sound changes like

i/ü/_<front>

(The category names still have to be unique— you can’t use F to define both front vowels and fricatives. But recall that you can use any Unicode character now for category names.)

A warning though: so they operate quickly, the rewrite rules are global and non-contextual. The results may surprise you if you didn’t realize your transcription system was ambigious. E.g. don’t use kh both for IPA /x/ and for the cluster /k h/.

If you need contextual rewrite rules... just use SCA²! Add your rewrite rules at the top and bottom of the file, with the appropriate context specifications.

Sometimes you want the rewrite rules to apply only to the input. (For instance, the orthography may only apply to the parent language.) In that case, make sure Rewrite on output is unchecked.

So basically, these are rules that rewrite the character or group of characters you apply as something else into the program, and then they spit back at you the original writing.

[chris_notts]

Out of interest, are you mapping everything to string regular expressions, or have you implemented your own regular expression engine?

Many years ago I wrote a featural SCA called HaSC in Haskell. Like yours, it supported a large subset of regular expression syntax, but extended to allow pattern matching and capturing of features of phone(me)s as well. You could do things like this, which captures the manner of a following non-vowel and then assimilates a preceding consonant to it:

C −> <{manner: %m} / _ {%m = manner: ∗ −vowel , ∗}

I found it almost impossible to "compile" the SCA patterns to patterns of a string regex engine because of the two tier structure (phone, feature) being matched against, so i ended up writing my own regular expression engine. Haskell made this surprisingly easy to do, because of pattern matching and lazy evaluation, and performance was pretty good.

[alice]

Likewise, my SCA doesn't use normal regexps but a custom matching and replacing - er - engine? They're much more appropriate to SCAs, and more fun, too!

[Zju]

You can treat rewrite rules as sound changes. If they have conflicts or are incompatible with the sound changes, it makes sanse to clear the segments in between conversions, as in

Code: Select all

//define pre-rewrite groups
//pre-rewrite rules
>>clear all segments
//define phoneme groups and segments
//actual sound changes in here
>>clear all segments
//define post-rewrite groups
//post-rewrite rules

Out of interest, are you mapping everything to string regular expressions, or have you implemented your own regular expression engine?

The former.

Many years ago I wrote a featural SCA called HaSC in Haskell. Like yours, it supported a large subset of regular expression syntax, but extended to allow pattern matching and capturing of features of phone(me)s as well. You could do things like this, which captures the manner of a following non-vowel and then assimilates a preceding consonant to it:

C −> <{manner: %m} / _ {%m = manner: ∗ −vowel , ∗}

That's always an idea to do, but you can get around it with groups. Currently I have other features on my wishlist.
Why the less than sign in the output and what would just {%m = manner: ∗ −vowel} do?

On a sidenote, maybe I'll have to look into Haskell, R or the like eventually should the lexicons start getting too large.

Likewise, my SCA doesn't use normal regexps but a custom matching and replacing - er - engine? They're much more appropriate to SCAs, and more fun, too!

If you don't mind asking, how are they more appropriate? The three things missing that I can think of (ad-hoc groups, features, matching groups in input/output and condition) can be easily added in the current system.
Though yes, regexes aren't really a replacing engine, just a matching one. I had to sweat a bit before making everything work.

[alice]

Likewise, my SCA doesn't use normal regexps but a custom matching and replacing - er - engine? They're much more appropriate to SCAs, and more fun, too!

If you don't mind asking, how are they more appropriate? The three things missing that I can think of (ad-hoc groups, features, matching groups in input/output and condition) can be easily added in the current system.
Though yes, regexes aren't really a replacing engine, just a matching one. I had to sweat a bit before making everything work.

Partly for the reasons you mention, and partly because it's easier to get closer to the reality of what you're trying to represent, such as it is. And partly because regexps are, well, just too heavyweight.

[chris_notts]

That's always an idea to do, but you can get around it with groups. Currently I have other features on my wishlist.

The "<" is really an arrow. It represents merging / modifying features.

C -> {manner: %m} would change the C into a phone(me) whose only feature was "manner".

C -> <{manner: %m} merges the new manner into the preceding consonant. It's shorthand for (1=C) -> 1<{manner: %m}, where 1 is a capture variable, and 1<{..} is a merger of 1 and {..} with the contents of {..} having priority.

I guess you could think of it like merging dictionaries in a language like Python or Javascript.

Why the less than sign in the output and what would just {%m = manner: ∗ −vowel} do?

Match a phone(me) whose only feature was manner. * at the end means "and whatever other unmentioned features happen to be present".

On a sidenote, maybe I'll have to look into Haskell, R or the like eventually should the lexicons start getting too large.

Not sure I'd recommend either of them for you. It depends what you want.

Haskell isn't an easy language to pick-up if you're coming from a dynamic language like Javascript, or even from something OO-ish like Java or C#. It's more or less strictly functional, it discourages in-place mutation, it's not object orientated, and evaluation is lazy by default which is both a blessing and a curse. Its main user-base is programming language nerds, so half the libraries rely on unnecessarily complicated concepts to work around the restrictions of the language. Most things is Haskell are either unexpectedly easy (writing a regular expression engine) or unexpectedly hard (write a GUI or anything else that relies on global mutable state). I actually like it, but only for some kinds of project.

R... well, the packages are great if you want to do stats. For my taste, the base language is a nasty mess, and it's not that fast either. If you want a general purpose dynamic language, go with Python instead, you'll get much better libraries for everything that isn't stats related.

If you don't mind asking, how are they more appropriate? The three things missing that I can think of (ad-hoc groups, features, matching groups in input/output and condition) can be easily added in the current system.
Though yes, regexes aren't really a replacing engine, just a matching one. I had to sweat a bit before making everything work.

Of course, to a certain extent you can emulate a featural SCA by just building long lists of groups or iterating over possible combinations. I don't remember where it all fell over since it was 2011 when I wrote HaSC, but I did find there was a point where it all fell over and a string regexp engine just wasn't the answer. And as I said, writing my own had perfectly acceptable performance in Haskell, which is compiled to machine code surprisingly quite efficiently. It might not have worked quite so well in Python...

[bradrn]

This project looks great! I like the language, which looks to be quite flexible. However, I do think the UI and documentation could be improved:

• It would be nice to have in the README an overview of what features this SCA contains as opposed to other already-existing SCAs.
• The UI is not explained anywhere, so I had to figure it out by trial and error. It would be nice if the documentation had an explanation of what each UI element does, something along the lines of 'This pane is where you enter the commands, this one is where you enter the words, this button runs the rules' etc.
• It is impossible to tell just by looking at them that three of the rows of buttons at the top of the page are actually used as tabs. Fixing this could be as simple as adding a border-radius to the top of the tab buttons.
• The third row of buttons is possibly better suited as a menu bar, containing menus Project, Execution, Output, Template etc. The contents of this menu could also change depending on which one of Commands & output, Templates, Log are selected.
• It would be nice to have an overview of regex syntax in the documentation for people who haven't used them before.
• You don't seem to talk much about templates in the documentation, which is a pity because it looks like one of the best features of this SCA.

On a sidenote, maybe I'll have to look into Haskell, R or the like eventually should the lexicons start getting too large.

Not sure I'd recommend either of them for you. It depends what you want.

Haskell isn't an easy language to pick-up if you're coming from a dynamic language like Javascript, or even from something OO-ish like Java or C#. It's more or less strictly functional, it discourages in-place mutation, it's not object orientated, and evaluation is lazy by default which is both a blessing and a curse. Its main user-base is programming language nerds, so half the libraries rely on unnecessarily complicated concepts to work around the restrictions of the language. Most things is Haskell are either unexpectedly easy (writing a regular expression engine) or unexpectedly hard (write a GUI or anything else that relies on global mutable state). I actually like it, but only for some kinds of project.

I know I'm getting a bit off-topic here, but I've had a completely different impression of Haskell - I've always found it to be a very practical language, to the extent that I rarely use other programming languages any more. I would actually find it hard to think of a project more suited to the language than this one; in particular, I would suggest having a look at the threepenny-gui library.

[chris_notts]

I know I'm getting a bit off-topic here, but I've had a completely different impression of Haskell - I've always found it to be a very practical language, to the extent that I rarely use other programming languages any more. I would actually find it hard to think of a project more suited to the language than this one; in particular, I would suggest having a look at the threepenny-gui library.

As I said, I like it for certain kinds of project, and an SCA definitely plays to its strengths. But there are definitely some things it's not good for, in my opinion, and it's also not easy for someone new to it from almost any mainstream language. Basically any OO or scripting language is built on having mutable state everywhere, so you need to break that habit and go cold turkey before you can use Haskell properly.

[Zju]

Not sure I'd recommend either of them for you. It depends what you want.

So at the end, do recommend Python or Haskell for a SCA workhorse? Just in case JS struggles with hundreds/a couple thousand of words.

I don't remember where it all fell over since it was 2011 when I wrote HaSC, but I did find there was a point where it all fell over and a string regexp engine just wasn't the answer.

Here's hoping that this project won't stumble upon these roadblocks.

(documentation and interface)

I admit that the documentation was done a bit in a rush. I was thinking of what I could add. The buttons, most are self explanatory, maybe tooltips won't hurt though. I don't exactly have much free time on my hands right now, so not sure when I'll be able to address the issues.
In the meantime, I won't mind if somebody proposes a better implementation of the interface. I'm not that well versed in HTML and CSS and interface and engine are fairly decoupled.

[Travis B.]

As for Python versus Haskell, Python is certainly "easier" while Haskell definitely has a steeper learning curve along with some gotchas in the form of how laziness often behaves performance-wise (it is awfully easy for naive code to have space leaks), but once one has wrapped one's brain around Haskell I have found Haskell to be more rewarding to work with, and it has some useful characteristics such as that far more bugs are caught by the compiler in Haskell than in Python, so that once the code compiles one can be more sure of that it actually works, space leaks aside. Of course, while mutable state is a given in Python, one has to intentionally introduce it in Haskell (one can have mutable state in Haskell, contrary to popular belief), with things like State monads, IO monads, ST monads, IORefs/MVars/TVars/MVectors, etc.

If one is concerned primarily with performance, even though it is lazy by default Haskell outclasses Python (I have seen it compared to Java with regard to straight-line performance). Also, Haskell has excellent concurrency support, being able to support thousands of threads at a time across multiple cores, and has very nice concurrency-related facilities such as Software Transactional Memory and Async, whereas Python has relatively poor concurrency support (e.g. even though it can have multiple threads, it cannot take advantage of multiple cores). The only other language I have seen which is comparable to Haskell with regard to concurrency is Erlang.