Feedback from Waldir
Waldir gave me some really good and thorough feedback on Telegram. I'll paste them here (in comments to this thread) to keep track of them & the progress with fixing them in a somewhat less ephemeral place than a chat.
The plus button needs a tooltip
Done
Nice! But IMO "Add term" is a little too terse. How about something more explicit, like "Add this word to the terminology.js glossary"?
How to enter more than one possible translation? E.g. one for the verb form of a term, and another for the noun form.
Adding new terms from the terminology page itself doesn't seem to work (nothing happens).
I am now able to add terms from the terminology page. I'll report back if I get the errors again.
The Portal:Kea/terminology.json page flashes the underlying table when first loading the page, and when adding new terms.
The gadget should dynamically add a link to the terminology.json page from the Portal:kea page.
Done
Why dynamically? If it depends on {{Portal}} anyway (as it currently does), the template could add the whole link on its own, avoiding client-side JS and parts below the link moving down after the first paint.
@Tacsipacsi: Yes, I actually want to do that eventually when (fingers crossed) the gadget is ready to become a default gadget. But now in the beta stage, I think it is better to only show the link for those who have the gadget switched on. Users who don't have it switched on would only see the raw (well, prettified/tablified) JSON when visiting the terminology.json page, so I'm afraid that would just confuse people.
Then what about adding it in the template with display:none, and unhiding it in the gadget’s CSS? That would still cause a flash after first paint as gadget CSS is loaded with JavaScript, but the hiding is easier and less error-prone to remove when the gadget becomes default, and it’s also faster as we can save the AJAX request loading the necessary MediaWiki messages. (The flash could be resolved by using a peer gadget, but I don’t think it’s worth the effort for this temporary solution.)
Suggested aliases should be smarter: I got the following as suggestions for "settings" → "settingses", "settingsed", "settingsing".
Suggested aliases don't show up in the new entry box when adding terms directly in the terminology.json page.
After adding a term to the glossary, it should become green. Right now that only happens after a page reload.
Done (but please test)
I can't test it; after adding a term, the "Add term" dialog never disappears. The browser console shows the following errors:
Uncaught TypeError: termlistParsed[word] is undefined popupBuilder https://translatewiki.net/w/load.php?lang=en&modules=ext.gadget.HoverPopTools,terminology-beta&skin=vector&version=1gx2o:21 processSourcemessage https://translatewiki.net/w/load.php?lang=en&modules=ext.gadget.HoverPopTools,terminology-beta&skin=vector&version=1gx2o:22
@Waldyrious: I think I've fixed this one now., please check when you are able. Making stuff happen in the right order is no joke. 😜
Yep, it now seems to work as expected, and it's a much more streamlined experience! Thanks :D
I tried using a mediawiki list in the translation box, but the first line was not treated as bullet (the asterisk appears literally).
This is because of the way parseTermlist() lumps everything together. Introducing a line break or two before it parses it (and removing the entire dummy paragraph) should fix this.
I tried adding a blank line before the list, but it had no effect. Two lines didn't work either. The resulting edit only changes the timestamp.
I keep getting edit conflicts, not sure why. (Same as the issue mentioned by Xiplus elsewhere on this talk page.)
Done (but please test)
At the moment, edit conflicts only occur when I add terms from one tab and then try to do the same from another tab that was open before the first edit. So, only in expected circumstances. Seems resolved. That said, I wonder if the JSON format might be more prone to conflicts due to the delimiters being all the same... I know it tends to confuse regular diff tools.
I should be able to select multiple words to be added as a translatable expression (e.g. "terms of use").
IMO the hover animation that highlights the terms and the one that makes the plus button appear are too slow.
The reason I added a delay to the one with the plus button is so that translators won't get distracted if they happen to hover the text without intending to add a term. I could shave off 100–200ms off of it though, if you think that's better? (The current delay is 500ms for the blue outline to appear and another 500ms for the plus to appear).
500ms is definitely too slow IMO. Especially when combined back-to-back to make it a full 1s of delay. (Why not show the plus sign at the same time?)
Perhaps if one could have per-language lists of stop words, the gadget could offer a way to add those by the translator so they won't be highlighted in the future. This might prevent the distraction effect.
Just a small UI issue: perhaps the help button in the "Add term" dialog could be always in the leftmost side, instead of jumping around when the advanced options are toggled and the delete button appears/disappears.
In the terminology pages like Portal:Kea/terminology.json, the text "This is the terminology definition page" could perhaps be "This is a terminology definition page".
Done
I'd still insist on using "a terminology definition page" rather than "the terminology definition page". Or at least, it should say "the terminology definition page for language X", or something like that.