Page MenuHomePhabricator

CX2: Communicate template could not be adapted
Closed, ResolvedPublic

Description

Templates are not available in all languages, or keep the same structure when they do. This causes issues when translating articles and we want to communicate these issues as clear as possible using the system for communicating errors and warnings (T189488).

There are different circumstances to consider:

  • Type of template. Templates can be presented inline or as a whole block element. For inline templates, a fallback approach can be to use their rendered content when the template is missing.
  • Type of error. A template may have no known equivalent in the target wiki, or have an equivalent template but lacking mapping information to know how to adapt it.

Some examples are included to illustrate how to communicate each case:

Block template that does not exist in the target wiki

No template is added since we don't know the equivalent. the user can create content manually. The following message is shown:

Template unavailable
The original article uses a template that is not available in the destination wiki.
This template has been skipped, but you can add new content to capture the missing information.

( T196988 captures the initial step of showing the paragraph empty )

Inline template that does not exist in the target wiki

the rendered content for the template is added to the translation. It is highlighted a part of the issue card shown for the user to review:

Template unavailable
The original article uses templates to structure the content, but some of these do not exist in the destination wiki.
The content from the missing templates has been added as plain text. Make sure to review the result.

Template exists but mapping cannot be done

The target template gets added, and a warning encourage the user to complete the missing parameters:

Incomplete template
The information on the original template could not be transferred to the template in the translation since their structure is a bit different.
Please, edit the template in the translation to fill the missing information.

Related Objects

Event Timeline

Pginer-WMF triaged this task as Normal priority.Apr 16 2018, 11:34 AM
Pginer-WMF created this task.
Pginer-WMF raised the priority of this task from Normal to High.Jul 23 2018, 10:03 AM
santhosh updated the task description. (Show Details)Aug 8 2018, 6:05 AM
Nikerabbit added a subscriber: santhosh.EditedAug 8 2018, 3:16 PM

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

Nikerabbit changed the task status from Open to Stalled.Aug 21 2018, 6:52 AM

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 :/

Nikerabbit changed the task status from Stalled to Open.Aug 30 2018, 9:48 AM

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

Petar.petkovic moved this task from In Review to QA on the Language-2018-July-September board.
Petar.petkovic removed a subscriber: gerritbot.

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.

Pginer-WMF added a comment.EditedSep 19 2018, 9:42 AM

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.

@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:

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

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

Etonkovidova closed this task as Resolved.Oct 23 2018, 1:18 AM
Etonkovidova added a subscriber: Etonkovidova.

Checked in cx2 - both cases (the adopted template is missing in the destination wiki and the adopted template can be mapped only partially) are in the screenshots below:

@Pginer-WMF, the following text is displayed. You may check it whether they explanatory enough.

<p class="cx-ui-translationIssue-message">The original page uses templates to structure the content, but some of these do not exist in the destination wiki.

The content from the missing templates has been added as plain text. Make sure to review the result.</p>

<p class="cx-ui-translationIssue-message">The original page uses a template that is not available in the destination wiki.

This template has been skipped, but you can add new content to capture the missing information.</p>

Should "Mark as resolved" be progressive blue?

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