Create indexed subentries in DSL format

[det]

I am working on a dsl-format dictionary that contains several sub-entries for many headwords. I'm looking for a way to format these entries so that the sub-entry words are indexed, but still remain part of the main headword definition. (i.e. I can search for any of the multiple sub-entry words and all will link back to the main definition.) I've looked at the following options:

1. Multiple headwords - Listing the subentries as headwords below the main entry allows them to be indexed with the full definition, but causes the main entry to be replaced by subentry. e.g. below, অংশন is indexed, but when searched for, it comes up as the main headword for the full definition below -- replacing the main headword অংশ. (It should either come up with just it's own sub-entry definition, or bring up the whole entry definition with অংশ listed as the headword.)

Code: Select all

অংশ
অংশন
অংশাংশ
   [m1][trn] n. a portion or part. [/trn][/m]
   [m3] অংশন  n. [trn] dividing. [/trn][/m]
   [m3] অংশাংশ n. [trn] a tiny part. [/trn][/m]


2. Subentry with @ - Using the Lingvo dsl convention of @ to indicate sub-entries does not seem to work with Goldendict.

3. Indicating subentry with [lang] - Surrounding the subentry words with language tags (same language as the index language) also doesn't get them indexed.

Code: Select all

[/trn][lang name="Bengali"] অংশন [/lang][trn]


Any other ideas for tackling this?

[Gloggy]

below, অংশন is indexed, but when searched for, it comes up as the main headword for the full definition below -- replacing the main headword অংশ.

Indeed, this is intended. When multiple headwords listed one after another, for the same card, that just means that each one of those headwords corresponds to the *full* card.

2. Subentry with @ - Using the Lingvo dsl convention of @ to indicate sub-entries does not seem to work with Goldendict.

Yeah, this seems to be the proper of way dealing with sub-entries. And it is indeed broken in Goldendict. Actually, I'm quite surprised that this is not implemented in Goldendict and wasn't wildly reported. Looks like DSL dictionary authors don't use @ all that much...

Personally, I just use scripts to break big entries into sub-pieces. I prefer the big cards to be left as-is, *plus* adding all those small sub-entries as separate small cards, possibly with the link to the mother entry.

So that:

Code: Select all

big-headword
  foo - bar - baz
  subheadword1
    translation1
  subheadword2
    translation2


becomes after conversion:

Code: Select all

big-headword
  foo - bar - baz
  subheadword1
    translation1
  subheadword2
    translation2

subheadword1
  translation1
  See <<big-headword>>

subheadword2
  translation2
  See <<big-headword>>


The biggest trick here is to figure out how to detect where is the sub-entry starts and where it ends...

3. Indicating subentry with [lang] - Surrounding the subentry words with language tags (same language as the index language) also doesn't get them indexed.

This doesn't look like a proper way.

[C2BlEv]

Actually, the lack of @ support was reported here a while back. Can't find it now.

[det]

Personally, I just use scripts to break big entries into sub-pieces. I prefer the big cards to be left as-is, *plus* adding all those small sub-entries as separate small cards, possibly with the link to the mother entry.

Gloggy - thanks for the reply. And yes, breaking out the sub-entries as separate entries is what I've ended up doing too. But it certainly isn't an elegant solution -- I'll end up with a lot of duplicate data.

How do you do the linking back to the main entry?

[Gloggy]

How do you do the linking back to the main entry?

I just add something like

Code: Select all

See <<main_entry>>

to the end of the sub-card.

But I agree that proper support of @-subentries in GD would be pretty useful.

[det]

Is GoldenDict's lack of @ support for subentries in dsl format being worked on? Is it likely to be fixed?

[Tvangeste]

Is GoldenDict's lack of @ support for subentries in dsl format being worked on? Is it likely to be fixed?

I just added Issue #7 in our issue tracker: https://github.com/goldendict/goldendict/issues/7

And it is in my TODO list, but I'm not sure how soon that would be, we'll see.

[det]

Great! Thank you. Could adding full-text search capability also go into the issue tracker? My lists of index words currently contains sub-entry words, but also translated words. Adding dsl @ support would make the first unnecessary, and full-text search would do away with the second. (...besides being generally a hugely useful feature.)

[Tvangeste]

Could adding full-text search capability also go into the issue tracker?

Certainly! File away. This is a very often mentioned issue.

(...besides being generally a hugely useful feature.)

Heh, yeah. But that's a bit too complicated for me to implement though. So we could just patiently wait for Konstantin

[det]

Ok, here it is: #8 on the issue tracker - https://github.com/goldendict/goldendict/issues/8