Variants / Minor entries are not shown in headwort list

Dictionary App Builder
#1

There already is a forum post where a minor entry that is supposed to show up in the headword list is not shown, whereas this post reports that showing the entries was possible, but showing the glosses not. Unfortunately, both topics have not been publicly answered.

I, too, have the issue that minor entries, unspecified variants to be precise, are not shown in the headword list. I have the feeling that at one point in time they were shown so I’m wondering what went wrong. I have the “Show Minor Entry” function checked in Fieldworks, both in the main entry and in the minor entry. I also see this in the LIFT-file that I export. Here is what FLEX exports (I took Spanish as an example):

<lexical-unit>
<form lang="es"><text>escuelaVARIANT</text></form>
</lexical-unit>
<trait  name="morph-type" value="stem"/>
<relation type="_component-lexeme" ref="escuela_8084ae0c-efcb-4111-a877-851cbfe0d09c" order="0">
<trait  name="variant-type" value="Unspecified Variant"/>
</relation>
</entry>

If I uncheck “Show Minor Entry” this is reflected in the LIFT-file, FLEX adds the following before /relation:

<trait name="hide-minor-entry" value="1"/>

Thus, I have the feeling that the issue lies in DAB, but I just can’t find a way to control this. The ‘Fields’ menu only really lets you control how things are displayed if they are there, and the unspecified variants are showing up there…

#2

Nobody on the forum who has successfully exported variants into DAB? It would tremendously help if you could post the entry for a variant in the LIFT-file for me to compare. I don’t have much to play with in Fieldworks Tools > Configure > Dictionary. I’ve changed the paragraph style for for content to normal, thinking it might be style issue, it isn’t. I’ve checked every single checkbox to show in the minor entries - the headword still will not show up in DAB…

#3

@Rhina Looking at your LIFT entry. It may be that if there is no sense with a definition then the entry is ignored. Can you modify the entry and test that?

Most of the FLEX settings affect the XHTML export but not the LIFT export.

#4

Thank you for your reply, @Ian_McQuay!
I have checked the following:
-Main entry: lexeme form, variant, and gloss
-Main entry: lexeme form, variant, gloss, and definition
-Main entry: lexeme form, variant, gloss, reversal entry, definition, restrictions
Together with:
-Variant: various variant types, comment, dialect label
In the fieldworks Tools > Configure > Dictionary tab I have tried the above with Main entry > Senses > Definition (or Gloss) checked and unchecked, but as you say, this doesn’t seem to affect the LIFT file, it certainly does not affect how DAB shows the entry. All of the above will not show the variant. You can (and always could) find it by searching, but it doesn’t show in the headword list.

There are people who have used LIFT files to create dictionaries and have succeeded in showing variants in the headword list, are there? If yes, then the answer must be somewhere in my settings, I just don’t know, where.

I have tried to make an XHTML export, I didn’t know but this basically shows one to one what fieldworks shows in the preview for each entry. It does also show the variants in the list. However, I was not able to include a reverse entry list, when I chose the file I exported via Export > Reversal Index Web Page (XHTML) nothing happens. That’s an essential for our purposes.

Even if somebody would help me fixing that, what are the pros and cons of XHTML? It seems to me that with LIFT you do the style creation of an entry in DAB, and you are very limited in what markers are imported into DAB, while with XHTML, you do everything in fieldworks, can basically change nothing in DAB (except for font size etc.) but you get in DAB what you see in fieldworks. What about audio and pictures? (The documentation says nothing about these topics, so I need to ask)

#5

I have a problem with the LIFT import into DAB that may be related to what Rhina wrote about. I have tried both the LIFT and the XHTML imports and had problems with each, but here I will just focus on the LIFT import, and the app it produces. The main problem is that if a word has two subsenses, only the first subsense is reflected in the dictionary app, and the second subsense is ignored. Unless I can find a solution for this problem, I will not be able to use the LIFT import. I will write separately about my other problem with the LIFT version of DAB, and about my problems with the XHTML version.

#6

@linguafranka It took me a while to understand what you mean. You mean that in the list view (preview), only the first sense of a word is shown, and the second sense (along with the example sentences etc.) show up only when you tap the word, right?

DAB acts the same in my case. Were you able to resolve that using XHTML?

#7

No. It has been more than a month since I have tried using the LIFT import into DAB. I have given up on that and have concentrated on using the XHTML input, which also has some problems but not so serious. No, what I was saying (as I recall) was that when I tried using the LIFT input into DAB, any second, third, etc. senses of the entries were not shown at all in the dictionary app. They were left out completely (as I recall). So I cannot work with that format, using LIFT input. At this point I am not expecting to find any help to make it work. I have made lots of progress trying to use the XHTML input though.

#8

Thank you for your reply. Apart from all the other issues with LIFT, this works just fine for me, if you tap a word, all senses and example sentences are shown. I’m trying to hold on to LIFT because of the great search function (search results highlighted & searching in example sentences).

Just to be one hundred percent sure, though: Fine, entries look great when created with XHTML. But what about the list view? Are all subsenses shown? In my test XHTML dictionary, if an entry has two or more senses, only the first sense is shown in list view. Therefore, I don’t see a difference between LIFT and XHTML in this respect.

#9

I’m just curious, why is it that LIFT search method is different than the one for XHTML?
I wanted to use a XHTML database but keep the search function of LIFT.

1 Like