The CBB

I'm changing the format of my comprehensive Commonthroat grammar... again. It started as markdown, then I went to Word, and now it's back to markdown again. Pandoc has a method of rendering discontiguous numbered lists that can be used to number and cross-reference examples. Unfortunately it works great in HTML but not when I try to render it as a Word doc. Haven't tried mediawiki yet.

I've finally dug into what I now termed the "language editor" for my diachronic conlanging app. Mostly setting up the basic GUI and structure of it, as well as making various design decisions in anticipation of intended features, but that's often one of the more exciting parts of programming.

Internally, a project will now be able to hold any number of languages. While I expect most people will only need one, leaving the door open for more means that users will be able to split off dialects or introduce borrowings and mergers internally, without having to import from other project files (unless they choose to).

In addition, I've set it up so that each language is stored under a (hopefully) unique and automatically generated ID, to prevent any accidental overwriting.

Nel Fie wrote: ↑20 Oct 2024 21:08 In addition, I've set it up so that each language is stored under a (hopefully) unique and automatically generated ID, to prevent any accidental overwriting.

You can guarantee uniqueness by using a UTC timestamp plus a language-counter plus a code uniquely identifying the creator and/or the computer from which the creating was done. 32 bits probably won’t be enough to guarantee uniqueness, but I bet 128 will be. (If not, surely 256 bits will be enough?)
The time probably doesn’t need to be preciser than 1 second, but you might want to use .01 sec instead.
The language-counter probably can recycle itself every million (10^6) times, but you may prefer a billion (10^9) times.

I think at max that might use:
105 bits for time-created
32 bits for creator id
32 bits for computer id
30 bits for number of languages created in this centi-second
________.

199 bits.

That’s probably overkill.

——————.

I like the problems and solutions you come up with!
I will keep lurking!

I just finished the L-words from the IGCE list. From #102,001, dab ad enzes (labellum or lip, as of a flower, lit. "landing cup") to word #103,096, Tshabillat (Chabillat, a beach town in eastern Durben, created to offset the Terran "Lytham"), I got 1,096 new words.

Along the way I passed word #103,000, which was Srentshaithrang (Srenchaithrang, a city in the Sengtan Mountains, created to offset "Luoyang").

Nice to be halfway throigh the English language with this big list!

eldin raigmore wrote: ↑21 Oct 2024 01:38
You can guarantee uniqueness by using a UTC timestamp plus a language-counter plus a code uniquely identifying the creator and/or the computer from which the creating was done. 32 bits probably won’t be enough to guarantee uniqueness, but I bet 128 will be. (If not, surely 256 bits will be enough?)
The time probably doesn’t need to be preciser than 1 second, but you might want to use .01 sec instead.
The language-counter probably can recycle itself every million (10^6) times, but you may prefer a billion (10^9) times.

I think at max that might use:
105 bits for time-created
32 bits for creator id
32 bits for computer id
30 bits for number of languages created in this centi-second
________.

199 bits.

That’s probably overkill.

——————.

I like the problems and solutions you come up with!
I will keep lurking!

Thank you for the feedback. The system I currently have implemented is a simplified version of what you suggest: it concatenates year, month, day and a randomly generated 4-digit number (with the randomiser seeded at launch time). Using information from the system is a good idea though, and I should probably add hours and minutes for safety.

It's somewhat questionable how much of a safety margin will be necessary though, since in most cases users will probably only work with their own data. With a date-based ID, the risk of overwrite would probably only come into play if 1) users have access to a file created by someone else 2) and they import data of that file into another project 3) and both the target and source files have a node of the exact same type (e.g. a language node) with the exact same ID, which requires them to have been created the same day and somehow have been tagged with the exact same randomly generated number.

The only other scenario I could imagine is if the randomiser managed to generate the same number twice on the same day while tagging the same kind of node. How likely that is, I'm not sure.

I'm adding a vocative case to Mariupol Gothic.

For feminine nouns this means just replacing /ə/ in the noun with /o/, not too unlike Romanian. Hence I have минэ /miːnə/ "moon" becoming мино /miːno/ "O moon!" For masculine nouns I'm thinking it'll be /a/ instead.

So, among other things, I decided to implement a similar "generative ID" system for the storage of phonological transcription systems, because I felt that they as well might be subject to accidental overwriting. Until then, they were stored by name.

Which might have turned out to be unnecessarily cautious on my part. Not unnecessary as a safety measure per se, but unnecessary because it gave me (and still gives me) a lot of work that I didn't fully expect and that I wish I didn't have. But oh well, what's done is done.

At least it motivated me to rewrite from scratch the mechanism which displays all units in the system on the editing sheet, because the previous mechanism was one of the oldest parts of my project and thus woefully outdated. The new one is probably only a third as long and much more readable. Between that, and the fact that it implements a lot of things that I've learned since writing the old one, it'll be much easier to maintain and modify in the future.

I'm not looking forward to a bunch of other bugs I expect to discover as a result of switching to the ID system, though. And I regret that it will make the project storage file less human-readable as well (it takes the form of a JSON file, which is extremely easy to parse and modify manually if needed), since every mention of a phonological transcription system would be replaced by the ID, e.g. in a section describing a sound change.

So, what I'm pondering right now is to maybe make the ID internal and use the name as the main referent, in order to preserve that readability.

After hunting down and fixing a bunch of bugs, then implementing some stuff I noticed I hadn't in the process, I've finally gotten back to working on my diachronic conlanging app's "language phonology editor", specifically the inventory and phoneme editors.
You can now add units from any transcription system as a phoneme to the inventory of a chosen language. A separate "phoneme editor" tool will display all information about the phoneme upon selection (i.e. symbol, unicode equivalent, phonological system, and a grid of features and the feature sets they belong to); and allow the addition of language-specific notes and tags to each phoneme.

Next up, I'll adapt the widget to also display information about units not yet added, and next I'll probably work on an inventory display system where users can create their own charts. I'm curious as to how difficult or easy that will turn out to be.

I added sample sentences for Omlueuet and Kobardon to my website.

Creyeditor wrote: ↑02 Nov 2024 03:25 I added sample sentences for Omlueuet and Kobardon to my website.

Where is your website?

I thought it already was in my signature. Turns out it wasn't. So here it is: https://sites.google.com/site/creyeditor/.

Creyeditor wrote: ↑03 Nov 2024 02:17 I thought it already was in my signature. Turns out it wasn't. So here it is: https://sites.google.com/site/creyeditor/.

Edit: Updated my signature.

Your sig does seem to imply that Indonesian is a conlang.

I added Mamabam (with sample sentences) to my website. (I'm planning to add more languages, such as K'uk'uts' and sample sentences for the other languages.) I also decided that the sapient Water Bears on Fredauon will not have language in any way that humans can recognize. They will show stuff and might point to it whwn trying to communicate with humans and they will use posture and the like to communicate with each other. This contrasts with the sapient avian Hoatzyn, which have some kind of language-like communication.

So I've been trying to come up with a conlang that isn't IE-like, like all my extant conlangs are to date, but it's hard. It keeps veering into IE-territory. And I'm just talking about phonology here. Meh, I like what I like.

That said, I've come up with enough material that I may post it soon. It's not perfectly IE-free, but maybe it doesn't have to be.

My diachronic conlanging tool finally has the bare-bones mechanism to sort a language's inventory into a grid. It's pretty basic and still wants refining as well as proper implementation, but it's there and it works. I spent a while dealing with other issues, and then racking my brain over how to implement it. The basic idea of filtering for features isn't complicated, but I wanted to leave some doors open for other methods - and accounting for that kind of polyvalence makes things a whole lot more difficult.

But I think I have something that does the basic stuff most people need, and if down the line someone needs to create a single hexadimensional grid to sort phonemes across three unrelated phonological transcription systems, I might just be able to implement that.

I've ported my Commonthroat lexicon from Excel to Obsidian. This should allow for much richer and deeper documentation, more closely mirroring the lore-heavy lexeme posts I make in the CT thread here. I've also changed the romanization again, this time to avoid the use of capitals. The lexicon now uses combining macrons over long vowels, but I'll probably still use the second, case-sensitive, Romanization on the forum (the first one was the one with vowel letters).