Project talk:Terminology gadget

From translatewiki.net
Jump to navigation Jump to search

Doesn’t update language when I select another one in the language dropdown

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.

Tacsipacsi (talk)11:27, 27 November 2021

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?

Jon Harald Søby (talk)02:06, 28 November 2021

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.

Tacsipacsi (talk)09:41, 28 November 2021

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.

Jon Harald Søby (talk)22:40, 28 November 2021

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 (talk)23:52, 28 November 2021

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

Jon Harald Søby (talk)23:29, 14 December 2021
 
 
 
 
 

Feedback from Waldir

Edited by author.
Last edit: 23:26, 6 December 2021

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.

Jon Harald Søby (talk)23:22, 6 December 2021

The plus button needs a tooltip

Jon Harald Søby (talk)23:22, 6 December 2021

Done Done

Jon Harald Søby (talk)01:26, 7 December 2021

Nice! But IMO "Add term" is a little too terse. How about something more explicit, like "Add this word to the terminology.js glossary"?

Waldyrious (talk)10:19, 7 December 2021

How about "Add a terminology definition for this term"?

Jon Harald Søby (talk)00:08, 14 December 2021

Sounds good!

Waldyrious (talk)22:55, 26 December 2021
 
 
 
 

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

Jon Harald Søby (talk)23:22, 6 December 2021

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.

Jon Harald Søby (talk)23:27, 6 December 2021
 

Adding new terms from the terminology page itself doesn't seem to work (nothing happens).

Jon Harald Søby (talk)23:23, 6 December 2021

I am now able to add terms from the terminology page. I'll report back if I get the errors again.

Waldyrious (talk)22:37, 8 December 2021
 

The Portal:Kea/terminology.json page flashes the underlying table when first loading the page, and when adding new terms.

Jon Harald Søby (talk)23:23, 6 December 2021

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

Jon Harald Søby (talk)23:28, 6 December 2021
 

The gadget should dynamically add a link to the terminology.json page from the Portal:kea page.

Jon Harald Søby (talk)23:23, 6 December 2021

Done Done

Jon Harald Søby (talk)01:12, 14 December 2021

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 (talk)07:28, 14 December 2021

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

Jon Harald Søby (talk)10:45, 14 December 2021

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

Tacsipacsi (talk)18:08, 14 December 2021
 
 
 
 

Suggested aliases should be smarter: I got the following as suggestions for "settings" → "settingses", "settingsed", "settingsing".

Jon Harald Søby (talk)23:24, 6 December 2021

Update suggestions dynamically when typing in the first term.

Jon Harald Søby (talk)23:29, 6 December 2021

This should be all Done Done now. 😊

Jon Harald Søby (talk)23:19, 14 December 2021
 
 

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

Jon Harald Søby (talk)23:24, 6 December 2021

This is Done Done.

Jon Harald Søby (talk)10:49, 9 January 2022
 

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

Jon Harald Søby (talk)23:24, 6 December 2021
 

After adding a term to the glossary, it should become green. Right now that only happens after a page reload.

Jon Harald Søby (talk)23:24, 6 December 2021

Done Done (but please test)

Jon Harald Søby (talk)01:26, 7 December 2021

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 (talk)10:27, 7 December 2021

@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. 😜

Jon Harald Søby (talk)11:56, 7 December 2021

Yep, it now seems to work as expected, and it's a much more streamlined experience! Thanks :D

Waldyrious (talk)22:38, 8 December 2021
 
 
 
 

I tried using a mediawiki list in the translation box, but the first line was not treated as bullet (the asterisk appears literally).

Jon Harald Søby (talk)23:25, 6 December 2021

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.

Jon Harald Søby (talk)23:36, 6 December 2021

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.

Waldyrious (talk)10:31, 7 December 2021

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

Jon Harald Søby (talk)13:36, 7 December 2021

This should be Done Done now. 👍

Jon Harald Søby (talk)14:20, 14 December 2021
 
 
 
 

I keep getting edit conflicts, not sure why. (Same as the issue mentioned by Xiplus elsewhere on this talk page.)

Jon Harald Søby (talk)23:25, 6 December 2021

Done Done (but please test)

Jon Harald Søby (talk)01:27, 7 December 2021

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.

Waldyrious (talk)22:41, 8 December 2021
 
 

I should be able to select multiple words to be added as a translatable expression (e.g. "terms of use").

Jon Harald Søby (talk)23:25, 6 December 2021
 

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

Jon Harald Søby (talk)23:26, 6 December 2021
 

IMO the hover animation that highlights the terms and the one that makes the plus button appear are too slow.

Waldyrious (talk)10:25, 7 December 2021

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

Jon Harald Søby (talk)12:01, 7 December 2021

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.

Waldyrious (talk)22:44, 8 December 2021
 
 

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.

Waldyrious (talk)10:33, 7 December 2021
 

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

Waldyrious (talk)00:06, 9 December 2021

Done Done

Jon Harald Søby (talk)13:29, 10 December 2021

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.

Waldyrious (talk)14:14, 13 December 2021

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

Jon Harald Søby (talk)14:27, 13 December 2021
 
 
 
 

Gender support broken

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

Tacsipacsi (talk)00:33, 1 December 2021

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

Jon Harald Søby (talk)22:20, 1 December 2021
Edited by another user.
Last edit: 16:34, 27 December 2021

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.

Tacsipacsi (talk)18:24, 21 December 2021

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…

Jon Harald Søby (talk)16:35, 27 December 2021

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.

Tacsipacsi (talk)00:17, 28 December 2021
 
 
 
 

Add link to source code

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

Waldyrious (talk)10:17, 7 December 2021

Done Done

Jon Harald Søby (talk)16:50, 7 December 2021
 

read properties of undefined error when creating terms in Special:Translate

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 (talk)09:26, 7 December 2021

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

Jon Harald Søby (talk)11:47, 7 December 2021

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.

Jon Harald Søby (talk)11:49, 7 December 2021
 
 

edit conflict happen when creating second term in Special:Translate

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

Xiplus (talk)12:58, 29 November 2021

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

Jon Harald Søby (talk)14:43, 30 November 2021

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

Jon Harald Søby (talk)01:28, 7 December 2021
 
 

Page keeps reloading with this gadget on

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

Lakejason0 (talk)04:21, 28 November 2021

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!

Jon Harald Søby (talk)15:20, 28 November 2021