Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: Entries in flex database which have morph type "bound root" have the Word field blank in language forge #1830

Closed
megahirt opened this issue Jul 5, 2024 · 6 comments
Assignees
Labels
bug An existing problem with our app in production user observed Issue reported by a user with our app in production

Comments

@megahirt
Copy link
Collaborator

megahirt commented Jul 5, 2024

Bug report from an user:

Describe the bug
Entries in my flex database which have morph type "bound root" have the Word field blank in language forge.

To Reproduce
To reproduce: I observed that the long list of words in language forge that didn't have accompanying word forms (though all had the lexeme form field filled in in flex) were bound roots. To test, I went to flex and changed an entry which was displaying correctly in language forge from a stem to a bound root. I send/received on both flex and language forge, and the Word field became blank in language forge.

Expected behavior
Bound-root words should show in LF, not be blank in the lexeme form / word field.

@megahirt megahirt added bug An existing problem with our app in production user observed Issue reported by a user with our app in production labels Jul 5, 2024
@rmunn
Copy link
Collaborator

rmunn commented Jul 5, 2024

LfMerge fills in the lexeme field from the LexemeFormOA property and doesn't look at the MorphTypeRA property. Apparently that's not the right thing to do for bound roots. I'll look at the liblcm code and try to figure out what should happen for bound roots, i.e. where the lexeme is stored in a bound root.

@rmunn rmunn self-assigned this Jul 5, 2024
@rmunn
Copy link
Collaborator

rmunn commented Jul 5, 2024

Marking size estimate as "Unknown" for now; once I do a bit of research, I'll be able to more properly guess the size of this task.

@rmunn
Copy link
Collaborator

rmunn commented Jul 5, 2024

The docs for the CitationForm field on lex entries say "If this is missing, then this defaults to the lexicalForm but the user has the option of specifying a real citation form especially useful for bound roots." I don't think that means that there might be no LexemeForm value for bound roots, but perhaps that's what it means? I should ask the user whether the entry he changed had a citation form.

@megahirt
Copy link
Collaborator Author

megahirt commented Jul 5, 2024

One way to see what's going on on the FW side of things would be to:

  1. start a sample FW project that has a few entries, normally stem entries.
  2. convert 1 entry to a bound root type
  3. use the FW data explorer app or whatever it's called to inspect the FWDATA for the project and try to understand what the difference in structure is between the two entries.

@rmunn
Copy link
Collaborator

rmunn commented Jul 10, 2024

I just did what Chris suggested in #1830 (comment) and converted one entry in the rmunn-testlangproj project to a bound root. I then did a Send/Receive from FLEx, and this was the change:

diff -r 5fce5a35cbc5 -r 228260e19993 General/LanguageProject.langproj
--- a/General/LanguageProject.langproj  Wed Jul 10 01:37:27 2024 -0700
+++ b/General/LanguageProject.langproj  Wed Jul 10 01:42:18 2024 -0700
@@ -24,7 +24,7 @@
                <DateCreated
                        val="2003-07-09 14:59:47.183" />
                <DateModified
-                       val="2011-07-28 16:09:21.659" />
+                       val="2024-07-10 08:41:09.021" />
                <Description>
                        <AStr
                                ws="en">
diff -r 5fce5a35cbc5 -r 228260e19993 Linguistics/Lexicon/Lexicon_02.lexdb
--- a/Linguistics/Lexicon/Lexicon_02.lexdb      Wed Jul 10 01:37:27 2024 -0700
+++ b/Linguistics/Lexicon/Lexicon_02.lexdb      Wed Jul 10 01:42:18 2024 -0700
@@ -241,6 +243,8 @@
                <LexemeForm>
                        <MoStemAllomorph
                                guid="207798b5-22a1-40c9-b3ab-e11a4ff1cd57">
+                               <Custom
+                                       name="Cust Allomorph" />
                                <Form>
                                        <AUni
                                                ws="qaa-fonipa-x-kal">kʰala</AUni>
@@ -251,7 +255,7 @@
                                        val="False" />
                                <MorphType>
                                        <objsur
-                                               guid="d7f713e8-e8cf-11d3-9764-00c04f186933"
+                                               guid="d7f713e4-e8cf-11d3-9764-00c04f186933"
                                                t="r" />
                                </MorphType>
                        </MoStemAllomorph>

That GUID change is from the GUID for "stem" to the GUID for "bound root". That matches the change that I saw in the user's original FLEx project, where lex entry 10b92aaf-b221-4b50-8980-8e50b4c0f564 (in the original project) just had a MorphType change, from and to the same GUIDs.

So I'm pretty confident that I reproduced the change the user made in FLEx. However, I did not manage to reproduce the LF bug! When I did a Send/Receive in Language Forge, pulling in the bound root change, it did not blank out the lexeme.

So I still have no idea what's causing the bug in the bug reporter's project.

@myieye
Copy link
Collaborator

myieye commented Nov 25, 2024

The user has reported that it was due to the configured WS for the Word field being wrong.
Why exactly it manifested itself in it looking like precisely the bound root entries missing their Lexeme forms is a bit of a puzzle.
But, I'm guessing we can close this 🤷

@hahn-kev hahn-kev closed this as not planned Won't fix, can't repro, duplicate, stale Dec 9, 2024
@github-project-automation github-project-automation bot moved this from To Do to In Progress in Language Forge Classic Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An existing problem with our app in production user observed Issue reported by a user with our app in production
Projects
Status: In Progress
Development

No branches or pull requests

4 participants