To solve this issue, we can use the current implementation of the input in Special:MessageGroupStats to search for a 'message group or prefix' as seen below. Instead of fetching all the groups at once, we can debounce the typing action of the user against the API to fetch whatever matches the search query. This should help with two things:

1. Feedback to the user
2. Faster response time to the searching action

In T331824#8689855, @Tacsipacsi wrote:

I tried to replicate the issue:
...
but I got an error message about the specified export format not being supported, not an empty JSON file. Please be more precise.

From testing, it appears of the 3 menu width options available (wide, middle, narrow), narrow was the one most affected by the crop of the placeholder text and this has not been fixed. The images below show the difference in the menu size. The wide version would have the same place holder as middle.

In T318633#8675772, @gerritbot wrote:

Change 895707 had a related patch set uploaded (by Wangombe; author: Wangombe):

[mediawiki/extensions/UniversalLanguageSelector@master] Remove padding from .uls-filterinput

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

In T331818#8685721, @Tacsipacsi wrote:

Do shell scripts in Git hooks work on Windows?

Maybe 'shell scripts' in their entirety may be a stretch. We should be able to use Git's port of Bash on Windows. The script should be stores in .git/hooks. The hooks should be platform agnostic given that the checks to be made are dependent on Composer and PHP as far as I know. Checks to be run include:

composer fix
composer test
php phpunit 'path/to/unit'

For the unit tests, we can focus on the tests that changed or simply run all unit tests. Integration tests are not in scope due to the time it takes to run them.

Tested on translatewiki.net

This ticket is currently awaiting security review. We shall resume after reviews are complete.

Deployed on Translatewiki, found a couple of issues:

• When displaying alert, the group names don't have namespaces.
• "Unselecting" a source language does not work. It retains the previously selected source language.

In T318633#8589967, @Pginer-WMF wrote:

• Avoid the input element to get cut before it is needed. Currently there is an unnecessary white gap that makes the placeholder to be cut earlier than needed.

At the moment, the current font-size of the text input is 1.143em (rendered as 16px). We could start by reducing the font size to about 1em (rendered as 14px) and removing the padding on all sides of the text input. This doesn't introduce any detrimental effects to the ULS from my testing.

The poimport.php file is used with the command line and not with the Special:ImportTranslations page.

So far, while the issue can be reproduced, we haven't been able to identify where the second !!FUZZY!! is added from. The poimport.php file is not called as the user interacts with the Special:ImportTranslations page so that might not be the culprit we are looking for. Will keep investigating.

In T326714#8516116, @Tacsipacsi wrote:
(P.S. I would’ve appreciated if you quoted me instead of copying my comment without attribution, so that others know which point was made by whom.)

This comment T301311#7714254 from @Nikerabbit might be the best option to go for as we don't need to complicate the source language selection with options like calculating the most common source language in an aggregate group. This brings up the question as to how we should handle a case where one of the message groups is in es and another is in fr; which, I also don't imagine would be an impossible scenario. Should we restrict that and ensure all message groups under the aggregate are in the same source language? How would that affect existing aggregate groups?

For Slack integration, we could use their web API to post external messages to a public or private channel.
Steps

1. Slack admin will have to create an App with perhaps the name translatewiki-bot
2. We'll need to select the 'Incoming Webhooks' feature and activate it for the App. From there, we should be able to post logs using a simple HTTP request to the webhook URL.
3. The app will then request permission to access Wikimedia Foundation workspace and subsequently, ask to which channel the webhook should be associated with (in this case, it would be #translatewiki)

In T63125#8509077, @Elitre wrote:

I wonder if there should be a specific flag instead.

Thanks!

All changes have been made. This will ride the train on the 9th of Jan 2022. Will mark as done if no issues reported.

I'm not sure, should this (given it's an RTL language) be aligned to the right as well?

Hi, It's Eugene Wang'ombe.

Done. I've updated my email address to my foundation email.

As tested on Vector Legacy Theme:

In T313126#8442453, @Tacsipacsi wrote:

Just a note (it probably doesn’t affect how the languages bar works), you seem not to have the latest version of Vector – the watchlist star has been black instead of blue for some weeks now.

Updated comment screenshot. We can also move the recommendations by @Pginer-WMF to another ticket as this particular one shouldn't be covering the functionality in which the conversation took direction.

In T313126#8430297, @Tacsipacsi wrote:

What about going in the other direction: infinite levels? I’m not entirely sure, but I hope it’s possible to achieve with some CSS magic that exactly that many percents of the circle are filled that are translated, making a 5% translated page look differently than a 10% translated.

Mistakenly resolved. Unresolving to test on prod after deplyment.

In T313126#8235146, @Nikerabbit wrote:

One thing that came to my mind was whether we should replace the colorful boxes–which indicate how complete the translation is–with single color circles where completion is indicated by how many degrees of the circle is filled.

In T63125#8404831, @abi_ wrote:

If possible it would be good to do this, but just having Selected languages/exceptions is better what it is now.

This was tested on Translatewiki.net and results are expected as per the ticket description.

@fgiunchedi signed.

In T286901#8119955, @Pginer-WMF wrote:

I explored some options to help with this issue. They are not exclusive, several ideas can be combined:

Tested on translatewiki.net