This ticket seems done to me! @Jpita could you confirm?

@Pginer-WMF I understand that since the information for both MT abuse warnings and errors is available inside Preview Translation screen, we want to display MT warnings/errors immediately to the user (inside the review info section). Warnings can be suppressed (by clicking the check icon) so that user can be proceed with publishing but MT errors cannot be suppressed and will block publishing (unless user modifies translation to fix MT issues). Am I correct? Should the "Publish" button be disabled until user suppress MT warnings or fix MT issues?

@Pginer-WMF as Santhosh noticed it may be better to change 'Section translation features' to 'Section translation feature' inside the Full description of meaning of the tag. What do you think?

Could you please give some steps to reproduce as per my testing page suggestions are empty (not being fetched)? Code inspection lead to the same conclusion, page suggestions should be loaded from what I'm seeing at least.

Indeed it seems there is a UI glitch when clicking the menu on Chrome. I think that this is a minor, non-blocking issue for us, so we could fix it in a separate patch. @Pginer-WMF do you agree?

@Jpita Wikimedia REST Api is not available for some wikis (like "alt" wiki that you tried to use in the example above). This is the exact issue described in T275389, as you mentioned.

I think that when we are talking about sandbox in our application we are just talking about user namespace. So when we publish a section to the article page, we are in fact publishing to the main namespace. When user selects "publishing in sandbox", the section is being published in the user namespace. As far as I am concerned, the sandbox page you are referring to, is just another page in the user namespace with title "sandbox" (i.e. its title is User:myUsername/sandbox). Thus, I think that the published section will be published in this sandbox page only if the target article's title is "sandbox".

@Jpita I'm not able to replicate this one on test server.

Pau described the issue accurately. In general API to check for sections has currently serious limitations in finding missing and present sections.

Please feel free to create new tickets about these issues, I think these are not important blockers for this task.

A fix following the first approach has been submitted in this patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/661911

I suggest to create a new ticket for that but I'll leave it to Pau

about the second request error: recommendation rest api seems to be down, not sure why. However, this request is needed only for page article suggestions, which is something that won't be supported at this point. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/657564 is taking care of it, and requests to fetch page suggestions won't be sent after it is merged.

About en-gb requests: there is a related patch that will be deployed to test server very soon

Just for clarification: the algorithm used for calculating MT percentages on the client side is far from optimal. We are using a quite naive implementation with fast-levenshtein algorithm to calculate distance between active and suggested translation. Since this is only the first version of this feature, it was a trade-off so that we can have something working properly as early as possible. We can always refine our logic afterwards. For now I would agree about rounding up MT percentages.

Each CX3 build patch includes a reference to last commit on master included to this patch. We generally do not move tickets to QA column before they are deployed, but this was a confusing edge-case and I inadvertently moved it there.

@Pginer-WMF this is not yet deployed because also test server is not really in sync with our master. Functionalities are deployed on server only after we include a patch inside a CX3 build patch. As you can see from our last CX3 build patch, this patch was not included so it's not yet visible on server.

The first issue seems like a mediawiki core issue. @KartikMistry is it something that can be fixed by pulling latest updates for objectcache package? About the second one I'll take care of it, no need for additional ticket.

@Pginer-WMF I was not aware about this. Please create a new ticket about it.

@sbassett Thank you a lot for your answers!

@KartikMistry do you think this is an infrastructure or application software issue? In any case, if this is not something obvious, I think that it's not a big priority and can be moved to backlog, if no quick fix available. @Pginer-WMF do you agree?

Suppose a user enters "Pick a sentence" step, translates a couple sentences, then go back to "Compare contents" step, checks something they need, then go back again to "Pick a sentence". At that point the translation will be as the user left it. So we may need to actually reset the translation in such cases, so that there is no mismatch between messages and application behavior.