
On initial startup, you'll be presented! with the form above. There needs to be some way to identify you in the system.
The "Email Address" field is usefully filled out by a real email address that you would like to be identified by. But it is not necessary. The email address can be fake. One should not just make up a fake address at random. It may turn out to be someone's real email address. There is a standard domain name that is set aside for the purpose of providing URLs and email addresses for example purposes that should be used for fake addresses, "example.com". So, if one does not wish to use a real email address, they should invent some username, like "catlover2000" and invent an email address "catlover2000@example.com".
There are advantages to using a real email address. For instance, "catlover2000" may prove to be a popular username. At some point your data could be merged into a larger collection, where there is another catlover2000. It will be less likely that someone has your real address, since service providers tend not to reuse email addresses. It may also help others working with the same data contact you. Even though email addresses are not permanent, they are relatively stable.
The name field should be self-explanatory. It doesn't have to be a real name. It is up to you how you would like to be identified (or not) in the database. Something must be entered, but one can just put "x". Try to think of a useful name if you are not going to use an actual name. The system will often replace the identifier, the email address, with the name, which is a little nicer to read. If everyone is just "x" or "99", it doesn't help others understand who made a particular change or note. So, for anonymous names, think up some system that you'll find useful.
Names must be at least one character. They may be in any language, any character set, and need not assume North American conventions, such as everyone having a first and last name, where the last name is a family name. Write your name as you prefer with confidence! (Unless your project lead tells you otherwise. I don't want to get you in trouble.)
![[Pasted image 20260331143416.png]]
After filling out the initial form you'll be rewarded with a largely blank window that says "Welcome!" This is a genuine sentiment that I built in to the program for everyone who uses it. I hope you feel welcome using the software I wrote! Thank you!
Every database belongs to a project, and there is only one database per project. There is other information that a project tracks, for instance, you may put files under a project folder and reference them from notes and other data in the database. A single Menkayonta instance allows you to work with multiple projects at one time. For this reason, it is important to clearly identify each project so that you can tell which you're working with at any given time.
To get started, you will need to use the "File" menu and choose "New Project". This will open the form below.
![[Pasted image 20260331144213.png]]
The top line is a project identifier. It is automatically generated and is very unlikely to accidentally be the same as another identifier. It is something that one need not concern themselves with unless they are doing something very complicated with the software.
The project title is a friendly name for the project. I would keep it relatively short. Long titles may be more descriptive, but it can be confusing to have too much information on the screen at one time. A language name may be a good title.
The project key is a one character symbol that references the project in places where there is not much horizontal space. For instance, you can see the little orange tab that says "New Project". There will potentially be many similar tabs open, perhaps for multiple projects. Having a full project title in such a small space distracts from other useful information that may be displayed in the tab.
If you are working with others, you may enter the URL to a CouchDB server in the "Server URL" field. This will cause the software to automatically synchronize with a remote database, where others can also receive your changes and send their own. This happens automatically in the background.
By default your database lives only on your computer. You must tell Menkayonta to connect to a remote server. The "Server Url" field above is for "ad hoc" synchronization. That means that anyone with access to the database has the same privilege level, and there are no rules to help make sure that some data can only be changed by an admin user, for instance. I am still working on a more comprehensive solution to managing projects in a hierarchical manner with different levels of permissions and roles.
Think of the URL as a bank account number. Someone with access to a server sets it up and shares it with you, just as a bank account number is set up by an authorized employee of a bank. The account number is linked to a ledger at the bank, which tracks deposits and withdrawals. Many people may share a bank account number. For instance, a parent may wish to make it easier to deposit funds in the account of their child, then both parent and child will know the account number and have access to the ledger.
Though it may be going out of fashion, many people do not simply make deposits and withdrawals without some private record. When people used checks, it took a long time for a check to be cashed and then registered on the central ledger of a bank. In order to keep track of the actual funds that one had available, one would need to balance their checkbook. You may have seen these ancient paper artifacts that used to come with box of checks. In a more modern setting, there are also applications like Quicken and innumerable phone apps meant to help one track their finances and budget.
These private ledgers are conceptually the same as the ledger the bank keeps. They are authoritative based on locally known information. One's private ledger may reflect a recurring utility payment that the bank ledger won't reflect until after it happens, yet in your private ledger, it is known to be a fact. Likewise, banks have creative ways of thinking up fees, or may pay their customers interest. Very few people know these values precisely until they check their bank app or website to resolve any discrepancies.
One can imagine a scenario where the child is away at college. Both the child and the parent are motivated to keep a separate ledger to track their expenses and income. Each of the ledgers that they use reflects facts that they know. The ledger is their own. If the kid spends $500 on boring sweatshirts and hats that have the initials of their college on them, the transaction may not register at the bank until the next day. Their private accounting software (they are going into a carrier in finance, obviously) will register a total $500 less than the bank. Their parents, who have just sent them a special birthday present, have logged a total that is $200 more than the bank total. At some point, both transactions will appear on the bank's ledger, and the parents and their child can update their totals.
Not only are the ledgers independent sources of truth, they are also physically independent. The child may name their account "Gravy Train" in their phone app. Their parents may name it "Chris's College Fund". What unifies the accounts is a reference to the bank.
The database synchronization in Menkayonta is different in some ways. It isn't just about adding and subtracting numbers. The point is just to give one an understanding to the independence of these ledgers. One's local project can be called whatever one likes. It may have a key that is the letter 'k' for 'key' or an emoji key. The database is a local object. When a URL is provided, it does not change this. It only allows for a shared accounting of changes made to different databases that share the same URL.
An important point to make is that synchronization with the remote database will stop when you are not connected to the internet. That means that other people may continue to make changes when you are not connected. You may also continue to make changes to your local database. When you connect to the internet again, the local database automatically reconnects to the remote and begins to synchronize the changes you made locally with the remote.
Do not be surprised if others have been editing some of the same data and you see their changes but not your own. Your changes have been saved, but the synchronization rules may have favored someone else's edits. With reference to the bank account metaphor, it is like someone made a deposit, but it isn't evident since someone else made an equivalent withdrawal. But there is a record of both the events, so no information is lost.
![[Pasted image 20260331151322.png]]
Later, the concept of "Modification" will be introduced, these record everyone's changes, and will help you deal with situations where you wish to compare "overwritten" or past changes, with the current state of some record.
![[Pasted image 20260331164135.png]]
After a project is created, it is listed under "Projects" in the sidebar. If you click on this, it will reveal various options.
![[Pasted image 20260331164243.png]]
(The image above does not reflect the current version of the software.)
![[Pasted image 20260331164722.png]]
The new gloss form is presented above. Let's go through it piece by piece from top to bottom.
The first bit is the tab title. Note that "t:", this is the key for the "Test Project" that I created. The key let's one know that this gloss will be added to the "Test Project" rather than some other project.
(This may be renamed to "orthography" or something similar.) In Dative the "Text" field is called a transcription field, but since these items are not always transcribed from some source, I found that title misleading. In the future there may be a real system for transcription and it would be not only be inaccurate but confusing to talk about the first line of an interlinear gloss as necessarily representing a transcription in that case.
The "Text" field is the only field that is required. One can edit the entry to add additional fields later.
The "Text Judgement" field is optional. It may be anything. The standard '*' and '#' marks can be used, but if one has a much more elaborate system the space could be used for that.
If the project requires a phonemic representation, it may be provided here.
This field is for representing affix breaks with "-". This character is currently privileged.
The affix break field is also sensitive to spaces. If the spaces on the "Text" line are not equal to the spaces in the "Affix Breaks" field, an error message appears. Currently this will stop someone from saving. Soon it will only supply a warning.
![[Pasted image 20260331171807.png]]
This is the field for glossing individual affixes. Just as the spaces were significant above, and caused errors when the number of spaces did not match, here the number of dashes for glosses must match the "Affix Breaks" line.
![[Pasted image 20260331172434.png]]
In the future, the Leipzig rules for the breaks and glosses lines will be enforced, requiring matching '=' for clitics, as well as other rules.
There may be zero or more translations. To add a new translation, click "+ Add Translation".
![[Pasted image 20260331173833.png]]
This will cause a number of additional fields to be displayed.
![[Pasted image 20260331173914.png]]
Once a translation has been added, it cannot be blank. The judgment field may be blank.
To mark a translation for removal, there is a "Remove Translation" switch at the top of the sub-form. One can change their mind before saving.
You may have noticed the '🗘' symbol at the beginning of the field title. Clicking this will take a field back to its original state before any changes were made. Since this is a new item, the original state is always blank, but for a previously saved item, it would revert any changes.
There are fields that are important, but that are considered metadata in the system. Currently, there is no enforcement of what metadata must be associated with an interlinear gloss (essentially the same as Dative). In the future, there will be a means of configuring necessary metadata and even having fields like "Speaker" or "Elicitation Method" show up in the main form. For now, the idea is to get the general ability to work with a wide variety of secondary data working, and then to make refinements and allow for custom configurations.
![[Pasted image 20260331174733.png]]
After saving, the new interlinear gloss item is displayed. The lines of the gloss should be self-explanatory for a linguist.
Following the gloss lines there is an ID. This uniquely identifies the item in the database and is so unlikely to repeat that one can safely synchronize one's database with someone else without worrying about conflicting IDs.
There are several kinds of metadata. Not all of them are visible in the figure above. One of these is "Modifications", which indicate when data was modified but also allows for indicating that check points and validations have been passed. I will not discuss this in detail here.
To add a tag, click the "Add Tag" button.
![[Pasted image 20260331175358.png]]
This will cause a small form to appear at the top of the pane. It provides some advice on tagging strategy and naming.
Since this is an example for this documentation, I add a tag "example" and click save. Now the new tag appears in the metadata area.
![[Pasted image 20260331175733.png]]
To add more tags, I may click on the plus. To remove a tag, I can click on the 'x' beside the tag name.
In order to view all items with the "example" tag, I may click on the tag name.
Properties are like tags but they have both a name and a value. To add one, click the "Add Property" button.
![[Pasted image 20260331180036.png]]
A new form appears at the top of the pane. It provides some basic advice on attribute-value naming.
![[Pasted image 20260331180255.png]]
Now the attribute value pair are listed in a table under "Properties". The 'x' deletes the property. Clicking on "language" displays all items with the attribute "language". Clicking on "kichwa" displays all items with the value "kichwa" for the attribute "language".
At the top of the pane there are links for editing the entry and for a "Note". Each item may have a note.
Clicking "Note" opens a new tab.
![[Pasted image 20260331180717.png]]
Some basic context is provided, which gets save along with any note.
One can edit the note with "Edit".
I will leave off on describing the notes system for now. It is fairly powerful.
Obviously, anyone using a database system like this will be very interested in searching it. Before one can do this, they need some data to search. For former users of Dative, they likely have a large amount of stored data in their existing database.
![[Pasted image 20260331181534.png]]
Currently Menkayonta only imports Dative's JSON format. Go to your Dative instance and export JSON. Save the file to your computer.
Then in the Menkayonta "File" menu, choose "Import File". A file dialog will open and you can select the JSON file that you saved from Dative. Afterward, the following form will open.
![[Pasted image 20260331181857.png]]
The "File Path" was filled in by the file picker. For "Import Type" there is currently only one option, "Dative Form Json". Under "Project" you must choose the project that you want to import the data into.
![[Pasted image 20260331182051.png]]
The above provides an example.
Click the "Import" button to begin the import. It will happen fairly fast, but it is possible that if you click on the "Gloss Index" before it is finished that you won't see anything yet. Count to ten and try again.
The full search capabilities are currently incomplete, but already powerful.
![[Pasted image 20260331182436.png]]
There is a single search form. It automatically searches over all the gloss lines and translation line. The plan is to implement the Lucene Query Syntax minus some things that are unneeded and with some additional features that are useful to linguists.
There will also be a way to include metadata in a search. Currently one must click on a tag or property first, and then search within the items that match the tag or property, but this is only due to the unfinished nature of the software.
There are a number of things that one may do with tabs other than simply click on them to view the contents associated with a tab.
Double clicking most tabs will create a duplicate tab. Below I double clicked on "t: Glosses" and now there is a second "t: Glosses". This may not seem obviously useful.
![[Pasted image 20260331183314.png]]
The utility of duplication comes in when one wishes to view the contents of tabs side by side or one above the other.
Right click on a tab to see a list of operations on the tab.
There are four directions that one may move the tab. One may also chose to "clone" or "duplicate" a tab, or close the tab.
With two gloss listings open, one can move one of them to the right. This allows a split view.
![[Pasted image 20260331183839.png]]
On one side, one may wish to search for "cat" and the other "dog".
![[Pasted image 20260331183954.png]]
This is only one possible use. The idea is that one should not feel as though they need to open multiple windows, but also to provide the ability to arrange a workspace or control panel like view.
Note that many data entry forms cannot be duplicated.