Replaced the check-boxes with the radio buttons to make the UI more aligned with the actual behavior.

Moving this to under review.

I've been able to reproduce the problem. Saving translations for any new text that's been added to the page fails to save with the given error. Like @Elitre mentioned, if I edit a translation unit / text on the English page, and then go back and try to translate the message, things work again. I did not face this issue while saving translations for existing translation units ( or text on the page).

1. Future changes

A summary of the new functionalities is documented here. We've also introduced usage of namespaces on the Translate extension.

1. Test cases

Hi @elukey - Thanks for following up on this. I think the most straight forward change for now will be to apply the same serialization format to BannerMessageGroup and any MessageGroups that are big. This change will still be useful when we break up the key later on.

@Pginer-WMF - Thank you for your response.

@Pginer-WMF / @Nikerabbit - Need inputs from you for the UI changes on this task,

Since this task is deployed, moving it on the board to the appropriate status

That serialized structure looks good now. Thanks.

@elukey - Would it be possible to share the content of the file? Something similar to what Niklas pasted above?

Moving to QA.

Moving to QA

Hi Niklas,

@Nikerabbit was right. Did the following during today's export,

This was a small change. Updated the code in the specific function (ext.translate.base.js -> getMessageGroup) to use version 2. This is being called from two places,

In T213802#5017771, @abi_ wrote:

Updated previous comment with the latest changes made to the code after reviews from @Nikerabbit. (Thanks!)

Moved to QA.

To fix the underlying bug discovered during the analysis for this task, created - T218777: Show proper notice when translations to non-priority language is blocked

Niklas noticed an issue with the searchSuggestion plugin when using the Timeless skin. I've reported it here - T218565: Search suggestion appears in the same location for all searchSuggestion instances

Moving to QA.

Moving to QA.

Moving to QA

Moving to QA

This will require more work than I initially anticipated.

Added a method in ext.translate.base.js to determine if a language code is message documentation code. Using this to then show / hide the priority language notice in ext.translate.special.translate.js. Had to use the string literal qqq(for message documentation). This method should be useful in the future.

This was a simple fix. After fetching messages groups from the API, updated the code in the message table component to hide the workflow states if the source langauge = target language.

1. What was done?

There were two issues here,

This was being caused because fetching message collections from the API in the source language of the message group throws an error. Message collections in the source language are needed on the Special:PageMigration.

Updated previous comment with the latest changes made to the code after reviews from @Nikerabbit. (Thanks!)

Following changes have been made in-order to reduce the size of the data saved in the cache,

Moving to QA.

@Etonkovidova - Yes, you can find it here - T217637: Message group state dropdown sometimes appears for source language

This turned out to be fairly straight forward as the data needed to make the assesment on whether a page is being marked for the first time was already available in the function scope.

I wonder if the message could be simplified to: "You can [import pre-existing translation] for this page (if any)" making the link to the Special:PageMigration page be part of the action.

It was fairly straightforward to determine if the page was being marked for translation for the first time.

Moved to QA.

Moved to QA.

In addition, as mentioned in the patch - https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/486327/, also added exception handling around the Language::factory call in TuxMessageTable class.

Moving to QA status.

I reviewed the previous patch, and noticed that wrapper code was already added to the extension in this patch. Hence decided to abandon the previous patch mentioned here.