I have been exploring how to do this. My first idea was to extend ve.dm.MWTransclusionNode, but it has a matchFunction that makes it difficult:

// HACK: This prevents any rules with higher specificity from matching,
// e.g. LanguageAnnotation which uses a match function
ve.dm.MWTransclusionNode.static.matchFunction = function () {
	return true;
};

Maybe we could do something like add rel=cx:Transclusion that we could match instead, but I am not sure that would work as it works for cx:Figure. In our DM we could check data-cx.adapted == false and register a warning.

Another option I was thinking to just check for the outer block element in ve.dm.CXSectionNode or in ve.init.mw.CXTarget:setSectionContent. That would not handle inline templates though.

@santhosh Can you advice?

You are correct about the implication of ve.dm.MWTransclusionNode.static.matchFunction. Adding any rel to Transclusion won't fix the issue. The reason is ve.dm.modelRegistry while trying to find a matching model class for the DOM element has some defined order. In that, the order of matching is like this

1. tag names + rdfaType + func
2. rdfaType + func
3. tag + func
4. func

etc.

So, MWTransclusionNode has rdfaType and match function is always matched for mw:Translcusion. Adding another rdfaType like cx:Translusion does not change this priority. The only way a class can get priority on top of MWTransclusionNode is by defining matchTagNames like this

ve.dm.CXTransclusionNode.static.matchTagNames = [ 'table', 'span' ];

So you get tag names + rdfaType + func

I just tried this and it is working. But the problem here is this array of tags that can be a transclusion is not a small set (I don't think it is a large set either).

@Esanders This hack of matchFunction was introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/218620 At this point of time is there a better way to do the same so that we can sub class it easily? If no, is there any other method other than defining ve.dm.CXTransclusionNode.static.matchTagNames

Registration always puts newly registered nodes at the front of the queue, so if you re-register with the same settings, it should match first (this is what ve.dm.MWHeadingNode does).

Change 454817 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/ContentTranslation@master] DNM: Trying to extend a transclusion node

https://gerrit.wikimedia.org/r/454817

I'm not sure whether I am doing it right in the above patch, but it isn't working.

MWTransclusionNode is actually a mixin - it matches all types, then in toDataElement it decides whether to return 'mwTransclusionInline' or 'mwTransclusionBlock', which are the concrete types.

So I think you need to override all three types, and the static inlineType/blockType values of the abstract class.

There is also the rarer ve.dm.MWTransclusionTableCellNode :/

Based on recent testing of CX2, one particular aspect to consider is the case of templates inside references. I'm not sure if the current efforts in this ticket cover that case partially, but I created a specific ticket for that specific case: T203160: CX2: Highlight (and skip) references with a template that could not be adapted

Change 454817 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Communicate that block template could not be adapted

https://gerrit.wikimedia.org/r/454817

The merged patch only adds warning for block level templates. Implementation of other specs is in progress.

Change 461282 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/ContentTranslation@master] Communicate adaptation status of inline templates

https://gerrit.wikimedia.org/r/461282

The task assumes behavior that is not currently happening. My patches add the warnings to communicate about unadapted inline and block templates, but unadapted block templates are not automatically removed nor unadapted inline templates substituted.

@Pginer-WMF Also, what is the criteria for an incomplete template? No parameters adapted at all? One parameter not adapted? What about templates without parameters? What about templates in target language needing more parameters than present in the source language? It feels hard to me to put in any kind of reliable heuristics.

In T192271#4597095, @Nikerabbit wrote:

The task assumes behavior that is not currently happening. My patches add the warnings to communicate about unadapted inline and block templates, but unadapted block templates are not automatically removed nor unadapted inline templates substituted.

The behaviour is not happening currently, but was expected to be supported as part of the current ticket. If you prefer to do so in follow-up patchset or as part of separate tickets we can organise it that way. If there are technical issues that limit the way we can apply such behaviours, please share the details and we can find a way forward.

@Pginer-WMF Also, what is the criteria for an incomplete template? No parameters adapted at all? One parameter not adapted? What about templates without parameters? What about templates in target language needing more parameters than present in the source language? It feels hard to me to put in any kind of reliable heuristics.

It is a good question to ask how strict we need the criteria to be, and I agree that it is hard to find a perfect answer. I think it is ok to be a bit flexible with having some false positives (unless these become too common). Note that the warning message is just telling that some information could not be transferred to the target template, and encourages the user to check it with more detail.

I think we want to focus on whether we were able to transfer the source parameters info into the target template, we should not consider whether the target template has additional parameters or not. That would be consistent with the warning message (some information was not transferred). I'd start by showing the warning when there is at least one parameter present in the source template that could not be transferred to the template in the translation.

If this results in too many false positives, we can adjust the criteria later to target only those cases where there are parameters in the source template but none of them are transferred into the translation. The proposed approach may also need some adjustments when dealing with Wikidata-based templates, but we can consider that as part of T199310.

Does this seem a reasonable approach?

@Pginer-WMF I would very much like to have those in separate tickets. That work should be possible to do independently and avoid this becoming one of those tickets which takes ages to complete.

In T192271#4600678, @Nikerabbit wrote:

@Pginer-WMF I would very much like to have those in separate tickets. That work should be possible to do independently and avoid this becoming one of those tickets which takes ages to complete.

I created these follow-up tickets:

• T204937: CX2: Don't add block templates to the translation if equivalent template is missing
• T204942: CX2: Convert inline templates into text if equivalent template is missing
• Also one issue I found while creating the above tickets that may be related to how we deal with inline templates: T204940: CX2: Possible template adaptation issue preventing paragraph to be added to the translation

Change 461282 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Communicate adaptation status of inline templates

https://gerrit.wikimedia.org/r/461282

Should "Mark as resolved" be progressive blue?

In T192271#4688371, @Esanders wrote:

Should "Mark as resolved" be progressive blue?

I'd prefer keeping it neutral. In some cases it represents the user completed a task (which could be a reason to consider making it blue) but in other cases it represents discarding a warning because it was irrelevant. We don't want discarding the warnings to be presented as the next logical step, since that could encourage ignoring the message instead of understand what it is about and fix the issues in the translation.

The "Template exists but mapping cannot be done" part seems not to be supported, I created a separate ticket to capture it with more details: T209473: CX2: Communicate template exists in the target wiki but mapping could not be completed