It is a regression from https://gerrit.wikimedia.org/r/c/mediawiki/services/cxserver/+/461386. The attributes are restored on wrong elements in the reduce-expand procedure. You can see the section tag getting the attributes of a reference. In lineardoc model, the references usually goes to a sub document. the counter we used as id for the attribute dump is reset to 0 in that case. Fixed now.

After the above patch:

It need to be better rewritten using OOUI now. This was written couple of years back

There may be something we can do to avoid highlighting sentence in non-connected sections(as shown in image above). But if we do, it need to be a new ticket.

@Petar.petkovic That is a general problem with any restore. We have not worked on such a sentence matching algorithm. Infact, we did not promise accuracy for the sentence highlight than 'as best as we can do'.
+cc @Pginer-WMF please confirm.

I think we will need a new event there to indicate alignement and not a section change for save.

In cxserver master, Yandex also able to translate this. It seems cxserver for production did not catch up the fixes. @KartikMistry please note,

Timing analysis for translate api for infobox of en:Vantaa

Looks like a problem in saving. If both unmodified and user translation in save queue. only the user translation get saved.

No plans to translate the content of template params. We don't do it for any templates.

While working on above patch, I found an opportunity for improvement. See the below section content

In T200683#4616099, @Petar.petkovic wrote:

@santhosh there is no patch attached to this ticket which is in review phase. What is the reason for moving the ticket?

Based on gerrit discussion, some changes are done

After the above patch, you can see that all params are mapped to target language(hu)

Inspecting the HTML markup https://en.wikipedia.org/api/rest_v1/page/html/Jony_Ive shows:

In the master version of cxserver, this error is not happening. I am able to translate. But the issue related to communicating the unadapted template remains( T192271 )

Current behavior is as follows. The reference list is a template. So it will go through the template adapatation and not content translation. The content rendered will depend on the references inlcuded in all translated sections.

Does not happen now.

No longer happens. Fixed in https://gerrit.wikimedia.org/r/c/mediawiki/services/cxserver/+/458780

This has a template with data-mw like this. The wt param value is causing "Invalid title" error from BatchedAPIRequest.prototype.get method

{
    "parts": [
        {
            "template": {
                "target": {
                    "wt": "formatnum: {{Infobox Finnish Municipality/population count|Vantaa}}",
                    "function": "formatnum"
                },
                "params": {},
                "i": 0
            }
        }
    ]
}

Uncaught TypeError: Cannot read property 'emit' of null

There are two scenario where a published translation can go to draft state unintentionally:

The current patch does not address the issue of waiting for save to finish. It disable autosave. That is what the task description also says.

Autosaving should not be triggered until the user makes further changes to the content after publishing.

MT percentage in the issue card no longer updates while the user types.

The same template after the fix:

I found that templatedata also has the citoid map which can be used to find the parameter mapping. For example, see the citoid map inside https://de.wikipedia.org/w/index.php?title=Vorlage:Literatur/Doku&action=edit (search for citoid)

This seems to be the cause for T204933: Wikibase related test errors for CirrusSearch blocking CX CI

I did not mean any change to CX1. Where is the summary? I corrected cxc_origin value

Changing priority high since this issue makes Yandex practically not usable with CX2

Extra: When the surface is ready, prefetch the translation for first section.

@Nikerabbit pointed out this issue while reviewing:

Doesn't this mess up parallel corpora even more badly now that sections ids get reassigned? I think all sections, where restoration does not have full match, should have new (preferably unused) id assigned and source text re-saved