TDNT Hover Issue

The Prioritization process is a compromise. To fix it for your specific case, assuming the highest prioritized Greek resource is DBL Greek you might have a List that looks like:

• DBL Greek
  
• Louw_Nida
• TDNT
• ESL

References for Greek Strong's & TDNT# will come from DBL Greek, whilst LN# will come from Louw-Nida.

If you want to stop DBL Greek from "stealing" these data types, then restrict it to Greek

• DBL Greek ==> Greek limited
• Louw_Nida
• TDNT
• ESL

References for Greek Strong's & TDNT# will now come from TDNT!

So you may try the following:-

• DBL Greek ==> Greek limited
• Louw_Nida
• ESL
• TDNT

References for Greek Strong's & probably Hebrew Strong's will now come from ESL. Note that I didn't restrict TDNT, because I still want it for Greek headwords.

Don't promote ESL above DBL Greek as it will "steal" Greek headwords from DBL  - then you have to go and restrict ESL with another set of side-effects!

Trey Selman said:

I also tried to watch the video on advanced prioritization but it is linked to a video on nested collections.

So I see. I watched it before it was moved to its new hosting site. I will alert Mark to this.

EDIT: Here's the site for the right video: http://www.4-14.org.uk/prioritising-resources-in-logos-4

Trey Selman said:

If I click on a Greek Strongs number in the ESV it opens the WSNTDICT

I have a similar issue. However, when I hover over a Strong's number in the ESL it shows the WSNTDICT entry. When I click on it it goes to that same resource.

I am not sure why an unprioritized resource should be favored over a prioritized one.

Overall I would say my experience with this is that it is not intuitive nor is it as straight-forward as key-linking in Logos 3.

Trey Selman said:

I've been trying to resist the temptation to say something like shouldn't this "just work".

I my opinion it should. You ought to have to do something special only if you wish to have the non-intuitive response. TDNT numbers should automatically respond with the TDNT entry as long as you have it on your computer. Ditto for L-N numbers. Strong's numbers aren't so simple. In 3.0 I could set the keylink destination for Strong's numbers with ease. Here I have to go through list building and advanced prioritization and I still don't get the result I want. A return to something like the keylink customization we have in 3.0 is needed. There I could set keylink destinations based on data type (Greek Strong's Number, for example). It was datatype specific, not resource specific as in 4.0.

Dave Hooton said:

Unfortunately, the Logos designers don't really appreciate what we are aiming for that was so readily available in L3.

I recall a bit of discussion about this in the initial beta testing. I think Bob's reply (it applied to parallel resources as well) was that in their studies they discovered features few people used and others that generated too many support calls and eliminated both in 4.0. The cry for a return of the customization of parallel resources has in some measure been responded to. I don't think anything is being done for keylinking. I don't see it as that big of a deal to implement in a way that would be intuitive. Trey's question and our trouble in providing a solution is indicative of the need for this.

Trey Selman said:

Mark and Dave, I really appreciate your time and explanations. You have taught me a great deal today and I greatly appreciate it.

Compromise and side-effects.

The "new" terminology[:)]

One user solved a similar dilemma by hiding the unexpected resource. You could consider hiding WSNTDICT!