Following some investigation, I've found that this message is parsed from the serverside. The target translation language could be sent to the API and parsed through APIQueryMessageGroups::formatGroup() in order to meet the requirements in the mockup (e.g when a user changes the language using the ULS on Special:Translate) but it is not. Looking at WikiPageMessageGroup::getDescription(IContextSource), we could essentially pass in the target language but it would require altering the MessageGroup::getDescription(IContextSource) interface to do so. The interface is implemented by the following classes:

In T305134#7966943, @Nikerabbit wrote:

For UserStatus, did you consider this option?

Make the HTML-lookalike characters use a different symbol, e.g. < Go back could be 〈 Go back.

As of this comment, I have managed to reduce the number of messages by ~13. There might be a bigger number due to the fact that one of the patches added a few items to the safe tags list.

As of this comment, the number or messages has reduced by >10. This patch handles a number of these messages by adding some tags onto the safe list.

In T240364#7938188, @Pols12 wrote:

Many thanks for this amazing work!

A minor issue: with French localization, relative timestamps overflow to a second line.

I have checked how Facebook is doing to keep timestamps as short as possible: the “ago” word is removed (implicit) and time units (“minutes”, “hours”, “years”…) are abbreviated (“m”, “h”, “y”…).
This would require a “short mode” for Language::getHumanTimestamp().

After some investigation, it appears that there is no way to keep track of reminders sent but not processed by the job queue. Once an admin clicks on 'Send reminder' an email job is sent to the queue through TranslateSandbox::sendMail();. In ManageTranslatorSandboxSpecialPage::makeList() there is a property reminderscount that takes count of the reminders that were successfully processed. The variable is used to display a count against how long ago a reminder was sent as shown below.

In T240364#7886682, @abi_ wrote:

Pending list of things to do on this task:

• Decide what to do here: https://phabricator.wikimedia.org/T240364#7886679
• Fix the issue mentioned here: https://phabricator.wikimedia.org/T240364#7886680
• Test with Legacy Vector theme
• Test with Timeless theme
• Use moment.js to render the duration and display the link.

This screenshot is from Timeless theme

In T240364#7882638, @Tacsipacsi wrote:

The page history link is also confusing IMO. Why not just drop those links? Edits without summaries aren’t important here anyway.

It looks strange. I suggest we add a greyed out text in it's place

In T240364#7872444, @Tacsipacsi wrote:

What makes sense in my opinion is either a link showing all the commentless changes at once (e.g. if revision 12345 has a comment, revisions 12346..12348 don’t, and revision 12349 again has, the link of the grouped commentless changes should be oldid=12348&diff=12345 instead of oldid=12346&diff=12345), or no link at all. If the first is chosen, the link text needs to be thought over as well; I think either the most recent of the n timestamps should be used, or a range in the format leastRecent – mostRecent (currently “last” actually means the least recent, as the revisions are in reverse chronological order).

Here are the results of previous comment.

After some testing, there are some items that we found that need some discussion.

1. As you can see from the image below, there might be an instance where summary may be long. The text wraps well but I propose we truncate it and add ellipsis.
   
2. In grouping of the summaries without a message, the image below is what I came up with. Which diffLink should be attached for the grouped messages? At the moment, I am using the diffLink of the last summary without a message (just by sequentially looping through the list of summaries that came from the API).
   

When a user uploads their translations and clicks on 'load file' button, both the diff and 'new messages' will be shown (If the user has modified or added a new translation).

It makes sense that the message appears after following the bug reproduction steps.
Importing the translation and clicking on 'Load file' button runs MessageWebImporter::execute()

1. Once the file is loaded, the next UI shows the list of new messages (translations).
2. But clicking on 'execute' runs MessageWebImporter::execute() again.

This call-stack suggests that the new messages will be imported [regardless] and saved before the messages are reviewed. Clicking 'execute' button which, I assume, is intended to allow the user to actually save the new messages after reviewing them, doesn't actually do what is intended of it. This issue might be bigger than just the message not showing correctly and is currently under investigation.

! In T240364#7759663, @Pginer-WMF wrote:
For example, the placeholder text could explicitly ask ("Optional summary: Why was the translation changed?"). This could make it more clear the purpose of the summary.

T193166 | Convert Translate to PSR-4 has a patch 724782 with classes that depend on some of the work done for this task such as MachineTranslationAid.php, QueryAggregatorAwareTranslationAid.php, TranslationAidsActionApi.php & TTMServerAid.php . As a result, I think the build for this task will always fail without making necessary updates to the aforementioned classes. I have made updates to the classes but haven't committed the changes since I don't believe they are part of the scope for this task. Could you advise on the best way to approach this?

1. I am concerned about the sorting of the suggestions using both the quality and count properties. Which one should take precedence?

One can no longer insert a translate suggestion into the translation editor without translator rights. I have added

cursor: not-allowed

when a user attempts to click on a translation suggestion to give a cue that the action is not possible/allowed without logging in

Task is now resolved

Message content now appears as intended.