There is some usability issues with marking a Flow topic as patrolled from RC page. It was correctly described in feedback

I was able to validate the diff, but not the creations, even through the history tab instead of RC.

Re-checked in wmf.18 - the discrepancies are still present:

The issue with duplicates in 'For later' section and in Suggestions (# 2 on the list of issues) is covered in other phab tasks:
https://phabricator.wikimedia.org/T188138
https://phabricator.wikimedia.org/T117605
https://phabricator.wikimedia.org/T129203

Thanks, @Barbvd. Closing as Resolved.

In T179220#4971876, @kostajh wrote:

"Go to the next page in the queue" button when clicked does not do anything and becomes inactive although there are more items on the list.

I suspect that particular issue is related to T216674, let's follow up on that when T216674 is fixed.

The issue has been fixed (checked in betalabs).
@kostajh -I am wondering if the issue described below is a result of the fix:
"Go to the next page in the queue" button when clicked does not do anything and becomes inactive although there are more items on the list.

Checked in wmf.18.

@Pginer-WMF
It seems like a serious issue which is not straightforwardly reproducible. Below is an updated info for the queries in the ticket and some investigation for the most recently reported case.

Re-checked in wmf.17. The page for two urls is the same displaying

@Petar.petkovic I re-checked in `wmf.17 - both Special:CX and Special:CXStats have

body.mw-special-ContentTranslation, body.mw-special-ContentTranslationStats {
    background: #eaecf0;
}

Please check if someting else needs to be done.

Re-checked in wmf.17 with cx2 translation (https://cxserver.wikimedia.org/v2/translate/en/nb/Yandex) . No error was displayed. Since the error was observed with ContentTranslation v1 and also on another article, it could be the case of intermittent Yandex MT failure.
Since the original report refers to ContentTranslation version 1 and no errors were observed with ContentTranslation version 2, the issue is considered Resolved.

Questions:

• the articles' titles on the list are not links?
• "Unactivated state" mock has a reference to English wiki specifically. Cross-wiki contributions will be also displayed?
• should we modify the default view of https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org graphs, e.g. change 'Graph type' and enable 'Show values' to make visual data more understandable to a newcomer?

Checked in testwiki/kowiki - moving back to Ready for Development.

Checked in betalabs: search-focus and search events are recorded for both desktop and mobile.

Looking into log on eployment-eventlog05.eqiad.wmflabs

Checked in testwiki (wmf.17) - the positioning of Cancel button looks good and makes it easy to cancel the action. Although I support 'Confirm' instead of cancel as it was mentioned on the ticket (by @kostajh and me).

• I checked the problematic translations mentioned in the task en:Antonio Brunetti ->fr and de:Maaraue ->fr. In cx2-teseting div tags were not added anymore.
• https://quarry.wmflabs.org/query/32917 -- shows a noticeable increase in corrections
• https://gerrit.wikimedia.org/r/#/c/mediawiki/services/cxserver/+/486070/ -- I do not see deployment tag added to it. Will the fix be swatted?
• <nowiki/> I did not see it added in the translations reported in the ticket, but I see it added when translating in cx2-testing (the addition was correctly done, in my opinion).

The scroll will work if after the search results get displayed, a device would be turned horizontally (if the search was done in a vertical position) and then returned to a vertical position:

@Jdlrobson - please review the following.
Testing on betalabs:
(1) The state is of 'Thank' button does not persists - click on 'Thanks' , wait for the confirmation and finishing of the action (grey 'Thanked' button), go to the next edit, return - the 'Thank' button will be active again. Also, the desktop and mobile do not sync - actions on the desktop are not reflected on mobile.

We need to investigate why these false positives are happening (is user typed content counted as unmodified?

The issue is closely related to T117605: Double starring of Content Translation's suggestions which was merged into the issue as a duplicate.

Merging this task to T129203 as a special usecase (see the comments on T129203).

@Strainu - thanks for confirming that the bug does not exist in v2. Mentioning VE in my comment was more about seeing a possibly broader context for such issue. Closing the issue as Resolved in v2.

The issue is present only in CX1 - see the animated screenshot attached:

I marking the ticket as 'Resolved', but I'd like some feedback from @Nikerabbit on the following. My questions below may refer to just desired behavior.

The list of favorite and suggestions behaves differently now. When all items on the list of suggestions in viewport are added to 'For later', the list of suggestion does not automatically provides additional, new suggestions, e.g.

@Nikerabbit any additional work should be done on the task?

Special:NewPagesFeed will display the day of a page creation not a date when a page was moved.

Go to any page (e.g. https://m.mediawiki.org/w/index.php?title=User:Etonkovidova/sandbox&oldid=2760903#/editor/0) - switch to an edit mode - and switch between VE and wikitext (might take several switches).

• in Special:NewPages a page moved from User or User talk to the main space will be displayed on NewPages when all option is selected or, of course, if the namespace of creation is selected. There is the info about the page being moved:

The interesting point in the issue - the new translation is started, but the old translation attempts to load and triggers the warning  "The source page may have changed significantly".

Two improvements have been introduced since the issue was filed:

• • CX2 version handles loading (re-loading) saved translation versions in a better way generally.
• the warning functionality/visibility was changed T168287: CX2: Warning about article having changed too much

To summarize:

• I could not find a way to check the behavior of the reported issue.
• it seems that the issue is more for VE - since the input from the keyboard was somewhat misinterpreted.
• 'Language settings' option does not allow to add Romanian keyboard as an input (which is a limitation):

• I checked the following part of the comment in case it presents a more general issue of responsiveness of the buttons to the user input:

if you write a text with normal font, then click AltGr+I, the "button" does not change state (it's still inactive). However, if you continue to write, the new text will be italic and the button state is updated from the first new letter. If you click AltGr+I again, the button is still "on", but on the first keypress it changes state and the text becomes normal again. I would expectthe buttons to change state as soon as I input the shortcut.

Just to note: Special:ContentTranslation page allows to change the language of the content:

Here is a most straightforward case - a MT Google translation en: Truism to català with several problems:

• extra space added around a simple link - In [[philosophy]], a sentence
• extra space is added in place of the template: {cn|date=June 2017}}
• a missing template is displayed in place of {{spaced ndash}}

No additional work is required per @santhosh; re-checked for possible regression - all seem to be fine.

Re-checked in wmf.14 - translating de:Maaraue to fr using CX2 testing will preserve &nbsp;.

Some added spaces are added when &nbsp; is present (checked in wmf.14):

It seems that not much work is planned to be done by Language team on this task, so to keep the task and the ongoing discussion visible, I am not changing the status, only removing Lang team projects tags.

Checked in cx2-testing and in in wmf.14 - Szablon:Cytuj is used, so the reference looks as :
<ref name="Caponnetto2012">{{Cytuj pismo|issn=1747-6348|doi=10.1586/ers.11.92|pmid=22283580}}</ref>

I checked in cx2-testing (no MT translation) - unlike the case in T213275: CX2: Should not transform named HTML entites into numeric HTML entities, &nbsp; is preserved when 'Copy original content' option is used. I added the task to the list of issues to check after the deployment.

@santhosh - there are several issues that I'd like you to review:

(1) In CX2 selecting words in a source article will not display the link card anymore

Checked in cx2-testing (with CX2 version) the same article translation zh: 张纪南 -> en:Zhang Jinan.

Checked in viwiki (wmf.14)

• the links (including link to Privacy statement) seem to be in place
• new users gets assigned to "_group":"exp1_group1" or "_group":"exp2_target_specialpage"
• the survey forms function correctly and record the responses

Checked in wmf.14 - 'Mark all changes as seen' on the Watchlist with 8,635 pages does not trigger any exceptions; and no Watchlist related error were present (except the mentioned above Spezial:Beobachtungsliste

Thanks, @elukey yes, but I thought that such errors were supposed to be greatly reduced by the fix(es) on this ticket. My question is - whether the number of such errors is acceptable or not.

Ellipses have been added:

In T214527#4904459, @SBisson wrote:

Note: may https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Echo/+/461123/ cause it?

Very unlikely.

It's not a new problem, probably a duplicate of T203930: EchoDiscussionParser is slow, causes timeouts

Notes for testing after the fix:

• Deleting a Flow topic will be attributed to the person who deleted the topic
• Deleting a Flow post - Special:DeletedContributions will display it twice - for a user who deleted it and for a post author
• Rollback/undo will not be on Special:DeletedContributions
• MassDelete are on Special:DeletedContributions

@Nikerabbit there are still some SERVER ERROR (including WANCache:v:mediawikiwiki:translate-groups), but it seems that are on of somewhat smaller scale (https://logstash.wikimedia.org/app/kibana#/dashboard/memcached?_g=h@66534ad&_a=h@c822620). Anything else needs to be done?