Project talk:Terminology gadget/LiquidThreads
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Signature | 1 | 11:11, 13 February 2023 |
The Plus icon | 4 | 15:27, 26 April 2022 |
Parasite "+" symbols with the copying to clipboard | 3 | 12:51, 20 February 2022 |
Extra unneeded whitespaces appeared in zh-* translations | 1 | 08:48, 3 February 2022 |
Doesn’t update language when I select another one in the language dropdown | 6 | 02:07, 14 January 2022 |
Feedback from Waldir | 47 | 10:49, 9 January 2022 |
Gender support broken | 4 | 00:17, 28 December 2021 |
Add link to source code | 1 | 16:50, 7 December 2021 |
read properties of undefined error when creating terms in Special:Translate | 2 | 11:49, 7 December 2021 |
edit conflict happen when creating second term in Special:Translate | 2 | 01:28, 7 December 2021 |
Page keeps reloading with this gadget on | 1 | 15:20, 28 November 2021 |
@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. "~~" + "~~"
.
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.)
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.
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 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.
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.
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.
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.