samtar merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/264

Rename WishlistTranslation.vue to WishlistTranslationBanner.vue

Change #1074321 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/CommunityRequests@master] Add translation button DiscussionTools threads

https://gerrit.wikimedia.org/r/1074321

Change #1074733 had a related patch set uploaded (by Samwilson; author: Samwilson):

[integration/config@master] Add DiscussionTools as a dependency of CommunityRequests

https://gerrit.wikimedia.org/r/1074733

Change #1074733 merged by jenkins-bot:

[integration/config@master] Add DiscussionTools as a dependency of CommunityRequests

https://gerrit.wikimedia.org/r/1074733

samwilson closed https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/265

Draft: Add talk page translation to WishlistTranslation gadget

Hey @Samwilson it sounds like there are some open questions, dependencies, or decisions needed to keep working on this task. Last I remember, we had a patch for review, and we were able to move forward. Did I misunderstand?

If we think there's a dependency on LPL team, or something else let me know!

Change #1074321 abandoned by Samwilson:

[mediawiki/extensions/CommunityRequests@master] Add translation button to DiscussionTools threads

Reason:

This functionality is being added to the DiscussionTools extension.

https://gerrit.wikimedia.org/r/1074321

@Samwilson In the description of that change (would be really useful) it says "When the page loads, a request is made to the Lift Wing API to get
a prediction of each thread's language. If the result is different from the current interface language, the translation button is shown." but wouldn't that lead to many unnecessary requests, longer page-load and server costs? I think it would be better if it just always showed that button or if talk page comments were labeled with the language just once (probably when users post a comment with the Reply tool).

it would be better if it just always showed that button or if talk page comments were labeled with the language just once (probably when users post a comment with the Reply tool).

This is totally true, but currently comments do not get marked with what language they're written in. People do not always write in the same language that either the wiki, page, or interface is set to, and we don't ask them. The Liftwing API is pretty fast, and from what I've heard there's no concern at the moment about too many requests to it. You're right that it slows things down (although not in page-load, but afterwards), but there's not really another way to do it.

Anyway, this task is about adding this functionality only to the wishlist, and it now seems like it's going to be better to add it more broadly to all DiscussionTools talk pages, and that's tracked in T309920 I think.

@Samwilson I suspect this would need to be revisited at some later point then. Most EN talk pages get quite a few views per month so it would make much more sense to only load and set the language the first time it's loaded and then store/cache it somehow. It has been already loaded when the next user visits the page. It's relatively rare currently that people comment with nonenglish comments and there probably will be doubts whether so many duplicate API requests are adequate.

I don't imagine this would be enabled on English Wikipedia, as you say almost all comments there are in English. It would only make sense on multilingual wikis where people are likely to need to comment in multiple languages.

Yes; should have removed EN, I meant to refer to English Wikipedia but then changed it to mean multilingual wikis mainly Wikidata, Commons, and MetaWiki where also most comments are in English and quite a fraction of talk pages get quite many pageviews. If this was being used on Commons VillagePump, it would result in thousands of the same requests where it would be sufficient to just check once with the subsequent same requests being redundant.

I think the current design is for the translate button to be in the 'more options' menu after every DiscussionTools comment, so it'll only be operating on the current section and only on request.

Anyway, it's not going to be part of the Wishlist specifically, so let's close this task and the discussion can continue on T309920. Unless @ngkountas have you created a separate task for the specifics of what you were working on?

Yes I confirm it from the design side. It has been decided keeping in mind scalability in the future and the proposal came from the Editing team. So the first acceptance criteria needs to be updated in the description.

@Samwilson I haven't created a separate task, I think updating the task description and the acceptance criteria of T309920 will be enough.