Support Allomorph Data

[alex-larkin]

This issue requests that LF add support for allomorph data. Allomorphs are an important part of language data. FLEX entries have an entire category for allomorph data, but allomorphs are not yet supported in LF. First, let me explain what they are and why they are important to users and potential users of LF.

Example 1: Suffix -s

• In English we know that if we want to make a noun plural, we add an -s to the end of it. So, "cat" and "dog" becomes "cats" and "dogs." But really, if you touch your throat while saying those two words, one realizes that the last sound is different. Because g in "dogs" is voiced (the vocal cords vibrate), it makes the -s voiced too, turning it into a -z. Sometimes speakers realize this (ever see a teen write something like "dogz" as a joke?) but most of the time people conceptualize this as being the same sound.
• The suffix -s has its own entry in the dictionary: https://www.merriam-webster.com/dictionary/s?#h4-anchor (sense 5)
• In an English language lexicon (language data database), for the entry -s, it would have two allomorphs: -s and -z. Each allomorph is indexed along with the entry words, so that they will show up in a search. Thus, if a user searches for z, they would see the entry -s in the results. (To further experience that the only difference between the s and the z is the vibration of the vocal cords, try saying "sssssszzzzzzsssssszzzzzzsssssszzzzzz" with your hand on your throat!)

Example 2: "Gota"

An Arab student once told me how confused he was when the directions that he received were "Gota the corner and turn right." What goes "gota" mean?! Really, what had happened is the "to" in "go to" had turned into "ta" because of the sound of the following word. If an English dictionary were to index the allomorph "ta", a student would be able to search "ta", find the word "to" and see that "ta" is a form of "to."

While these two examples are fairly plain, allomorphs take on a bigger role in other languages such as Quechua, in which a word can have eight or even more suffixes, and each root and suffix frequently change their form depending on what sounds they are surrounded by. Searching "ićhipa" will show the entry for "ićhipU" in my personal DAB app for Panao Quechua. Allomorphs can show up anywhere. "Swangur" (thornbrush) can change to "wangur".

How does FLEX display allomorphs? There are a lot of data fields, but the most important (in my view) are the form and the environment (under what conditions a form appears).

It is important to add support to allomorphs because it will enable minority language speakers to be better able to document their language, understand how it works, and share that understanding with others when they export the data into a dictionary. Linguists -another major stake holder- also depend on allomorphic description and documentation in their work. In order to make a good natural-sounding translation of any text (such as the Bible) it is vital that the language's allomorphs are well understood and documented.

@megahirt expressed concern about adding all of the data fields and suggested showing just the allomorph form in LF. I would suggest showing at least the form and environment. However, if we are aiming for one-to-one correspondence in the data fields between FLEX and LF, then they should all be available (but I would say, most of them hidden by default).

@megahirt also mentioned to me that over the years he has had multiple users request that LF add support for allomorph data.

Please let me know if my explanation of allomorphs and their importance makes sense, and what your thoughts are. Thanks so much!

[alex-larkin]

(I should clarify that "Allomorph Morphem[e Properties]" in my screenshot is a custom field.)

[megahirt]

At this point the goal of LF is not to have 1-to-1 feature or field compatibility with FLEx. We would like to improve our field compatibility with FLEX such that FLEx users are able to do basic and common tasks in LF.

@rmunn and I have been discussing the technical aspects of implementing this issue and have decided that more research is needed on the scope of changes required to implement this feature. At this time, it's looking like a fairly large change that requires an extensive model and UI change, something we are not geared up for right now. I can promise that we will do more research to figure out what is required and report that back here.

[megahirt]

LF Classic is in maintenance mode so we won't implement this in LF Classic.