issues with the Token detail

[Ansa211]

I will list them here so that they are not forgotten.

• [ ] multiword KWIC issue, already addressed upstream by Tomáš, but not yet pulled into our instances: clicking on non-first words inside the KWIC or on words to the right of a multi-word KWIC looks up a wrong word
• [x] the open book Unicode character is not handled properly by my instance of chromium-browser and is displayed as an empty box instead: in Firefox, it is rendered properly, , but with a small zoom, it is very hard to quess what the symbol is, so I would suggest dropping it completely

[tomachalek]

Hi, the "book" unicode character has been already replaced by a custom SVG icon in the "master" branch.

[Ansa211]

• [x] if, by accident, the attribute expected by the token-detail plugin does not exist in the corpus, some error warning should be given (currently, when I accidentally named the attribute valframe instead of pdtvallex, the PDT-Vallex (disambiguated) plugin always returned the first frame from the lexicon

• [x] CzEngVallex plugin: when a single verb has two different pairs, the "show details" buttons should probably be Show details for pair 1 and Show details for pair 2 (currently, both buttons say Show details for pair 1)

[Ansa211]

• [ ] with some low zoom levels, one of the horizontal lines separating lexicon header from the content is not displayed (probably we cannot address this issue, but reporting just to make sure; I can reproduce it both in Chromium and in Firefox, with the problem appearing at the same spot)

[Kira-D]

@Ansa211, I think this 'if, by accident, the attribute expected by the token-detail plugin does not exist in the corpus ..' is a matter of proper configuration since the attribute is assigned by a user in both places (token detail plugin config and corpus config). Therefore a user should know which attributes exist in a corpus and which of them he/she wants to use in the plugin.

[Kira-D]

• [ ] if, by accident, the attribute expected by the token-detail plugin does not exist in the corpus, some error warning should be given (currently, when I accidentally named the attribute valframe instead of pdtvallex, the PDT-Vallex (disambiguated) plugin always returned the first frame from the lexicon

@tomachalek Is it possible to implement some sort of validation and warning in the current architecture?

[tomachalek]

Hi @Kira-D, please see https://github.com/czcorpus/kontext/pull/2591 and my Slack post.

[Kira-D]

@tomachalek Thanks! We'll update our master this week and test it.

[Ansa211]

Retesting after the recent update of production. These issues persist: Multiword KWIC issues:

• [ ] clicking on non-first words inside the KWIC or on words to the right of a multi-word KWIC looks up a wrong word
• [ ] clicking on words inside the KWIC tries to look up the whole KWIC in the lexicon, which may be reasonable when the lexicon contains multiword entries, but is not reasonable for our choice of lexicons... I am not sure what would be a proper solution

New suggestions/comments:

• [x] Should the "Show less" button really be only at the bottom of the dictionary output? This means that if the output is long, and I click "Show more" and immediately decide I want to see less, I have to scroll.
• [x] PDT-Vallex: the links for individual senses are correct (they end in #senseid), but the page does not scroll down to the correct frame - I'll report this to Eva Fučíková.
• [x] CzEngVallex: there is not much point having a "Open in CzEngVallex" link for each verb pair when it is always the same link; either there should be a single link for the whole dictionary (with second_verb=ALL; maybe the dictionary title itself could be clickable?), or links to the pages limited to individual pairs, or even both.
• [x] The header of the Token detail shows the word form (in black bold letters in quotation marks), even though all of our dictionaries actually work with the lemma. Is this meaningful? (It would be meaningful if some of the dictionaries would look up the form; but we do not have such a case yet.) (EDIT: won't fix, it's like this in the core and we do not have strong enough reasons to change it.)