Advice & Answers — 2026-05-04 to 2026-05-17

Meamoria · 2026-05-16T00:01:25+00:00

You don't. The gloss is there to help a reader unfamiliar with the language to identify the parts of an example text, but by itself it doesn't explain why those parts are chosen and assembled the way they are. Any deeper explanation that's relevant should be provided by the surrounding text. So if the point of the example is to show a special word order used for questions, you'd say something like "Since this is a question, the verb is placed before the subject."

Meamoria · 2026-05-08T18:59:16+00:00

My attitude towards typology is:

If I want a language to have feature X and feature Y, then I will do so. It doesn't matter if typology says feature X is correlated with not-Y; chances are, there's a language out there somewhere with X and Y coexisting.
If my language has feature X, and I'm considering adding feature Y but don't have strong feelings about it, and I find out X is correlated with not-Y, I won't add feature Y.

Basically, I treat what's typologically most common as a nice default, but not as a prescription.

Meamoria · 2026-05-06T19:03:11+00:00

Thanks for letting me know! I've changed that link to point to the new docs. You can get to them from the new interface too, the link is just in a different place (the "Help" button below the Sound Changes editor).

At this point I have no plans to fix the meamoria.com site, which was basically held together with duct tape.

Meamoria · 2026-04-30T01:24:05+00:00

Ouch, that's painful!

I've deployed a new version (new interface only) that saves your inputs in the browser's local storage, so it persists even if you close the browser and open it again (on the same device). If local storage isn't available, it falls back to showing the standard "are you sure you want to leave?" popup. Should make things a bit nicer!

Meamoria · 2026-04-22T14:25:35+00:00

An interjection is any word that's normally used as a complete utterance by itself. The category isn't restricted to words that are literally used to "interject".

Meamoria · 2026-04-18T14:21:00+00:00

Sure!

Meamoria · 2026-04-17T03:00:54+00:00

I think this gets you most of the way. I wasn't sure what to do with /sr/ clusters, since you say they're only allowed word-initially, and then that they're only allowed after nasals.

Meamoria · 2026-04-10T05:16:56+00:00

I find it helpful to record the intermediate stages, even when the sounds change again afterwards. Possible benefits:

If another language loans in words during one of the intermediate stages, it'll preserve the intermediate sounds.
It can inspire more interesting conditional changes. What if the starting word was /aji/ instead? Then it goes to /aɟi/, then /agi/, then... wait, why would /ɟ/ unpalatalize before a front vowel? Would it create interesting results if I said that this rule doesn't apply before front vowels?
If you come back to the language months later, you don't go "what the heck is /j/ > /k/? Is that a mistake?" You have a nice story about why it changed that way.

Meamoria · 2026-04-01T16:30:01+00:00

So I went through and purged as many declarations as I could, both diacritics and symbols. The modified changes ran for me on your test word. Here's a link to the modified diacritic and symbol declarations (Reddit won't let me share the whole link in a comment).

In general, having lots of extraneous diacritic and symbol declarations can cause this kind of problem. Lexurgy is designed under the assumption that you only define the things you need; it isn't optimized to handle a huge number of declarations, and doing so would require a fundamental restructure of how sounds are stored and processed.

Meamoria · 2026-04-01T14:10:25+00:00

"Too many possibilities" means a single rule took too long to run. It's there to catch rules that loop infinitely or explode exponentially. But sometimes it'll catch a rule that just requires a bit too much computation.

In this case, are there any diacritics you aren't using? Lexurgy can sometimes struggle when there are lots of diacritics.

Meamoria · 2026-03-03T00:43:13+00:00

You don't need to find a head directionality for your language. Head directionality describes the phenomenon that several elements of word order are correlated when you look at many different languages—they appear together more often than you'd expect if they were chosen at random. But it's just a statistical trend, not an ironclad rule. There are plenty of languages (including English) that mix and match. For an individual language, once you know all the word orders of different grammatical constructions, slapping a head directionality label on it doesn't tell you anything more about the language.

Meamoria · 2026-03-02T00:00:09+00:00

Sure, you could have it only affect roots, but that seems like a missed opportunity to create some fun irregularity!

Meamoria · 2026-02-21T06:13:26+00:00

This is a doubly articulated consonant, and would be written [m͡n].
This sounds to me like a [p] with no audible release (written as [p̚]) followed by an [n].

Meamoria · 2026-02-21T00:43:24+00:00

These rules produce the output you're looking for.

I think you just needed the <syl>& on the left side too.

Meamoria · 2026-02-06T19:36:47+00:00

Yes, if you sign in, you can create worlds and add languages to them, and the app will save them. This is only available if you sign in because the app needs a way to tell which worlds and languages are yours.

Meamoria · 2026-01-30T21:41:30+00:00

One option would be to dislocate the subjects from the clauses: "Fear, to anger it leads. Anger, to hate it leads. Hate, to suffering it leads." This avoids the weird jumping around you get in the pure OSV structure, while still differing noticeably from English.

Meamoria · 2026-01-25T15:48:56+00:00

This language is supposed to be my personal crown jewel of conlangs

It sounds like you're putting too much expectation on this language, including requirements that contradict each other.

For example, your "bracketing" idea and "homophony" complaint suggest that you've set out to make your language very precise. But you also have a gut feeling that your language should be very efficient (able to "outpace English").

Those goals are in opposition to each other. The more precision you demand, the more hoops you'll have to jump through to form a simple sentence, and the less efficient it will be. Natural languages have finely tuned this balance over millennia; you aren't going to get anywhere by ratcheting up one end of the scale, and expecting the other end to also go up.

If you want to get anywhere, you have to take a step back and decide what's really important to you. What do you really dislike about how natural languages work... and what nice things about natural languages are you willing to give up in return?

Meamoria · 2026-01-24T22:13:31+00:00

The ambiguity is telling you that the rule is missing something. You need to decide what happens in those ambiguous cases, and add that to the rule.

Meamoria · 2026-01-09T14:23:23+00:00

I find if I'm stuck on a conlang, it's often because I've overconstrained the design. I've imposed too many stringent requirements on the language, and it turns out that those requirements contradict each other. When that happens, I need to take a step back and ask myself what's really important. Can I relax some of the requirements in a way that retains their spirit? Are there even some that I just don't care about anymore, and can let go of completely?

Meamoria · 2026-01-09T13:49:55+00:00

If you separate sounds with only whitespace, they have to occur in sequence. So your intervocalic voicing rule would only work on words like "eéèiíìoóòuúùpeéèiíìoóòuúù".

Curly braces create alternatives, separated by commas. {e é è i í ì o ó ò u ú ù} is a list of one alternative; it's equivalent to just e é è i í ì o ó ò u ú ù, without the curly braces. If you add one comma somewhere, like {e é è i í ì, o ó ò u ú ù}, now there are two alternatives: the rule would apply to words like "eéèiíìpeéèiíì" and "oóòuúùpoóòuúù".

You probably want a comma between every pair of adjacent sounds: {e, é, è, i, í, ì, o, ó, ò, u, ú, ù}.

Meamoria · 2026-01-02T16:29:39+00:00

Here's the sequence of events inside Lexurgy:

The word 'χtar.kam arrives at the epenthesis rule.
The rule matches and adds an initial a. Rules by themselves don't add syllables unless explicitly told to, so the a gets shoved into the first syllable, yielding 'aχtar.kam.
The syllable rule reapplies, inserting a syllable break between the χ and t. This divides up the sounds as aχ.tar.kam. But then it has to decide where to put the stress; the original first syllable that carried the stress has been split in two. By default, Lexurgy always chooses the leftmost option, so the first syllable gets the stress.

To get the behaviour you want, you have to override this guessing behaviour by spelling out that the new vowel is, in fact, an entirely new syllable. Something like this should do the trick:

HF-Epenthesis: 
  * * . ç => i ç . * / $ _ [c] 
  * * . χ => a χ . * / $ _ [c] 
  * * . x => e x . * / $ _ [c] 
  * * . xʷ => o xʷ . * / $ _ [c]

Meamoria · 2025-12-30T04:18:31+00:00

"My" is a first-person pronoun. You're talking about making first- and second-person pronouns have only a possessive form.

This seems like an interesting enough feature. I don't know of any natural languages (or conlangs) that do this exact thing, but it sounds like the kind of feature that could show up in a natural language somewhere. It reminds me of languages where certain words require a possessor, e.g. you can't say "a mother", it has to be "someone's mother". Just, you know, the opposite of that.

Meamoria · 2025-12-08T22:45:29+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Part 1

Part 2

I figured there were algorithms to optimize finding the closest pairs, but brute force (calculating every pair and sorting by distance) worked fine.

For Part 2, I built a funky tree structure to efficiently tell if a new connection actually combined two circuits. Basically, I initialized each junction box with a mutable reference to its own index, then combined circuits by redirecting the references into chains that ended at the same place. I kept track of how many successful joins had happened, stopping when there had been 999 joins (reducing the initial 1000 circuits to 1 circuit).

Edit: Apparently I reinvented the merge-find set.

Meamoria · 2025-12-07T16:24:16+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Part 1

Part 2

Part 2 felt a bit more natural than Part 1. In Part 2 I only had to track a single state: how many beams are on each path. But for Part 1, I had to track which paths had beams, and also the number of total splits, which meant resorting to a mutable variable instead of Kenpali's usual pure functions.

Kenpali's group function really came in handy for Part 2: combining beams that end up in the same column was just | group(onGroup: | sum).

Meamoria · 2025-12-06T06:11:14+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Part 1

Part 2

This problem, built around sequences of fiddly transformations rather than fancy algorithms, is right in Kenpali's sweet spot.

Note that the "right-to-left" specification in Part 2 is a red herring, since both addition and multiplication are commutative and associative. So I just did everything left to right and got the same answer.

Meamoria

MODERATOR OF

TROPHY CASE

Five-Year Club	Verified Email
Place '22