Project talk:Terminology gadget/LiquidThreads

This page contains archived discussions using the Liquid Threads extension. You can still participate in existing conversations, but you should start new conversations using the new discussion tools on the main talk page.

@Jon Harald Søby: In this edit, you added your own signature (line 360). I suppose it wasn’t intentional – yes, wikitext pre-save transform takes place on JavaScript pages as well (for historical reasons). Instead of "~~~~", you should use code that doesn’t get transformed, e.g. "~~" + "~~".

Thanks for the heads-up! It has been fixed. I was semi-aware of this quirk, because I've seen "~~" + "~~" used elsewhere, so I meant to double-check if ~~~~ worked when I saved, but then I forgot.

The Plus icon, which is intended to add a translation, fades very quickly and cannot be easily clicked.

@Mohammad ebz: Sorry about that. What browser (& version) are you using? It works as it should for me in Firefox 92.

In languages with rtl direction, when click on + mark, it will be hidden at once.

It appears that Terminology Gadget codes has not been well set for rtl direction.

@Mohammad ebz and Beginneruser: You're right, I forgot to check the revamped plus icon for RTL languages. It should be fixed now, please check. (You might have to do Ctrl+R or Ctrl+F5 if it still looks broken.)

Hi

The problem has been resolved. See this revision.

Thank you so much.

If gadget is enabled, that with the copying source texts (above edit box) to clipboard, i'm seen parasite "+" symbols after every word. This is unuseful with the using external translating tools.

@Kaganer: Thanks for the report! This should not be happening, thanks to the user-select: none; in the CSS. May I ask which browser (and version) you are using?

Yandex Browser (based on Chromium), v. 22.1.1.1544 (64-bit)

@Kaganer: I changed the way the plusses work entirely, so this shouldn't be a problem any more. Can you please check?

See MediaWiki:Gadget-terminology.js#L-994 , MediaWiki:Gadget-terminology.js#L-995 :

+ "</b> " +

There's a whitespace after the HTML b tag, which should be removed in zh-* languages.

@Winston Sung: Should be fixed now, please check.

Hi! When I select a new language in the “Translate to” dropdown in the upper right corner, it still shows suggestions for the old language. If it’s not possible to fix it (Translate itself has a similar bug, where the text directionality is not updated, so maybe the extension is unable to provide appropriate hooks), at least mention it on this page with the workaround of reloading the page.

Thanks for the report! I added a few lines that check if the &language= part of the URL changes. If it does, it reloads the page. I don't actually notice any real functional difference from the default behaviour, except making the script work as it should, and fixing the directionality issue as a bonus, so this should probably have been the default behaviour of Special:Translate in the first place. Do you know if there is a Phabricator task for the underlying issue already?

A real difference is that language switching is much slower now, which is annoying. Can’t you just reload the gadget instead of the whole page?

Yes, I remember having seen a Phabricator ticket for the directionality issue, but I couldn’t find it right now. Anyways, that should be fixed in Translate, not in this gadget at the price of annoying reloads.

I'm a bit confused. How often do you need to switch languages while on Special:Translate?

Anyways, "just reloading the gadget" isn't really that easy at the moment, because the gadget has already altered the HTML of the source message once it's been loaded, so doing that again would require keeping the original source message somewhere. Not impossible, but not a simple fix either – reloading the entire page is much easier.

Not that often, but that’s just because I don’t care enough about the formal address Hungarian translation (hu-formal). ;)

It may not be easy to change the already altered HTML, but there’s a solution: you don’t alter the HTML using the wrong language in the first place. :) Actually, I think you don’t even have to check the URL parameter, you can just query the target language when processing the message, and you’ll get the right language, even if there are messages with multiple target languages on the page (I don’t think it’s possible right now, but who knows, maybe it’ll be one time). Assuming $element holds a jQuery object for the <span class="sourcemessage">, you can get the target language with

$element.parents( '.tux-message-editor .editcolumn' ).find( 'textarea' ).attr( 'lang' )

@Tacsipacsi: I've submitted gerrit:745997 to add a hook when the language changes, which should hopefully make this a lot easier. I've also made some preparatory changes to how the processSourcemessage() function in the script works, so that it shouldn't be a problem to process the source message even after it has been altered. (This was also done to make the script update the markup immediately after saving a change instead of just after a reload, as mentioned in the other thread.)

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 about "Add a terminology definition for this term"?

Sounds good!

How to enter more than one possible translation? E.g. one for the verb form of a term, and another for the noun form.

My take is that this should be done "the wiki way", i.e. it is up to the translators. The same English spelling can be many different things (noun, adjective, verb etc). But any ideas for improvements and/or how to make that clearer are of course welcome.

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.

This is because of the way scripts/gadgets load in MediaWiki, with ResourceLoader and dependencies. Not sure if it is possible to solve this?

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".

Update suggestions dynamically when typing in the first term.

This should be all  Done now. 😊

Suggested aliases don't show up in the new entry box when adding terms directly in the terminology.json page.

This is  Done.

It should be possible to click the translated term to introduce it into the edit box.

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.

Ah yeah, sorry, I meant the message more as a note to myself. I need to add the blank lines in the source code.

This should be  Done now. 👍

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").

Some words should probably be exempt: "a", "the", "this", "of", etc.

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.

Ah, sorry, didn't notice that change, only the link addition. Edited the English source now.

This won’t work. See mw:Manual:Messages API#GENDER in JavaScript for how to use GENDER in JS code.

Thanks for the headsup! I think I've fixed it now. Can you check to make sure?

Sorry for the slow response. Yes, it works—I tested it on Portal:Hu/terminology.json by manually setting the message with mw.messages.set('gadget-term-json-intro', '{{GENDER:$1|he|she|they}}') on the browser console before the gadget loaded the missing messages (so it wasn’t missing by that time and thus didn’t get overwritten), and in logged in state I got he, while logged out it displayed they, as expected.

Great! Would you mind telling me how you set the message in the console before the messages are loaded? I am not aware of how to make sure something I put in console is done before anything on the page happens…

No magic here – I prepared the command in the console, hit F5 and hoped that I hit Enter at the right time, not too early (before mw.messages.set is available) and not too late. In logged out state it was even easier: since this is not a default gadget yet, I had to manually load the appropriate ResourceLoader module, so I simply set the message before I started loading the module.

There should be a link to the source code somewhere in the project page.

 Done

Uncaught TypeError: Cannot read properties of undefined (reading 'translation'). Thrown from Special:PermaLink/10428370#L-715.

When I create a new term in Special:Translate. A popup message said the edit was saved. But the form (window) is not closed. There is a JavaScript error as above.

@Xiplus: Yes, I'm working on making the changes reflect immediately in Special:Translate when you save an edit, but there are some quirks to fix still. But if the popup came, it means the edit was saved (you can check your contributions just to be safe) – the error is related to updating the page to reflect the edit.

In other words, it should be safe to just close the dialog (with the Escape key) and continue to translate or to add new terms, even if this error occurs.

Just as I posted this, I think I may have solved it actually. Let me know if you still find any issues related to this.

I think the gadget didn't reload terminology.json after the term created?

I will look into how to solve it, I have noticed it a couple of times myself.

@Xiplus: I think I have solved this problem now. Please let me know if it reoccurs. (I mean: You should no longer get edit conflicts with yourself, but it is still possible to get them if someone else edits the page in the meantime, as is normal elsewhere too.)

When I turned on this gadget, the translation interface keeps reloading, preventing me from submitting any translation.

Sorry, that's probably because of the lines I added to try and fix the other issue on this page. I removed them again now, please let me know if it works again!