Let us start the VE behavior for the source artilce:

The reference is defined inside the synonym param value of Infobox medical condition (new) template

Since VE does not parse the parameter values and just use as wiki text, the internal list that keep track of these references has no info about this reference.

In T209266#4752860, @santhosh wrote:

Let us start the VE behavior for the source artilce:
...
Since VE does not parse the parameter values and just use as wiki text, the internal list that keep track of these references has no info about this reference.

I guess this means we cannot do much to support this until VE provides better support for this (T52896: VisualEditor: Support editing citations defined within a template). Is that right? or is there any improvements (within a reasonable development effort) that can be done from Content translation side?

For templates buried in infoboxes, I doubt there is much you can do at the moment. For simple template generating references you might be able to extract the HTML, but it won't be easy:

If I have a simple template {{echo}} that just prints {{{1}}}, then

{{echo|<ref>''foo''</ref>}}

produces

<sup typeof="mw:Transclusion  mw:Extension/ref" about="#mwt2" class="mw-ref" id="cite_ref-1" rel="dc:references" data-mw="{'parts':[{'template':{'target':{'wt':'echo','href':'./Template:Echo'},'params':{'1':{'wt':'<ref>''Foo''</ref>'}},'i':0}}]}">
  <a href="./Main_Page#cite_note-1" style="counter-reset: mw-Ref 1;"><span class="mw-reflink-text">[1]</span></a>
</sup>
...
<div class="mw-references-wrap" typeof="mw:Extension/references" about="#mwt6" data-mw="{'name':'references','attrs':{},'autoGenerated':true}">
  <ol class="mw-references references">
    <li about="#cite_note-1" id="cite_note-1"><a href="./Main_Page#cite_ref-1" rel="mw:referencedBy"><span class="mw-linkback-text">↑ </span></a> <span id="mw-reference-text-cite_note-1" class="mw-reference-text"><i>Foo</i></span></li>
  </ol>
</div>

Parsoid helpfully tags the <sup> as both mw:Transclusion and mw:Extension/ref, so you could use this to identify these problem references. Once you have done that you need to work out the HTML contents of the reference. At the moment you only get the wikitext (params.1.wt). (There is HTML in the references list, but it is read-only HTML, not full Parsoid HTML, with all the extra semantic information). Depending on how many of these there are on the page, you could make a separate Parsoid calls to convert the ref wikitext to HTML. This would need to be injected back into the page as a reference.

This is just a basic outline, but I imagine the detail of the implementation will make it a fair bit more complicated.

So does this mean that this problem is not easily fixable? Can work on a work around.

In T209266#4759138, @Doc_James wrote:

So does this mean that this problem is not easily fixable? Can work on a work around.

I think this makes the problem harder to solve. I added a comment into the original ticket (T52896#4776950) to clarify the effect on Content Translation, where the limitation is not only not being able to edit these references but preventing users to add them in the first place.

For now, the workaround we can work on from the Content Translation side is to mark these references as missing (as we plan to do for cases like T203160). That would still require users to create the reference manually until the underlying issue is solved, but at least they would be less likely for the missing reference to go unnoticed and less confused compared to the current situation where references just disappear.

Hum. I have asked Ladsgroup about building a simple tool that will move the metadata from within the infobox to the main body of the text in the lead.

Would than just need to run this tool on a 1000 or so articles. Have to do it manually unfortunately as it is a none visible change.

James

Can we get someone to build a tool to move the reference metadata out of the infobox into the body of the article if used in both places? Me doing it manually really really sucks.

That is if this issue is not going to be fixed any time soon.

Okay I have proposed the creation of a bot to build a work around. Am hiring someone to build it for me. https://en.wikipedia.org/wiki/Wikipedia:Bot_requests#Moving_Reference_Metadata_Out_of_Two_Infoboxes

Okay the bot is built and being trialed now. We plan to run it on medical articles within the translation taskforce. If people want it run on more articles after that that would be a possibility.

The current limitation of Visual Editor to edit this kind of content (T52896) seems to deeply depend on Parsoid changes that may take still significant time.

Even if Visual Editor cannot edit the contents, it seems that it is able to identify which of the templates are in this problematic situation (as illustrated in F29284489 ). So I was wondering if those can be identified in Content Translation to either skip or mark them as missing.

@Esanders, can you tell us more about how Visual Editor is doing this? In particular:

• Can VE identify problematic references?
• If yes, how can Content Translation use that information to “treat” those “problematic references” in a way that works best for volunteers? (Where “treat” could mean excluded from the source article, gray out the reference in the source article, etc.)
• Are the "problematic references" tagged in some particular way by VE or should CX replicate the approach that VE uses to detect them?

Thanks!

I'll try and get around to looking into this this week as I don't know the answer off the top of my head.

As part of the Boost initiative announcement in Tagalog, we got the following feedback which seems relevant to this ticket (original and translation copied below):

Nakatulong sa akin ang Pangsasalinwika o Content Translation Tool sa pag-ambag ng mga bagong artikulo sa Wikipediang Tagalog, at sa tingin ko makatutulong ang pagbibigay-suporta sa kagamitang ito sa paghihikayat ng mas maraming tagagamit na mag-ambag pa dahil pinapadali ng kagamitan ang proseso ng pagsasalin. Gusto ko na may pokus sa pagdaragdag ng nilalaman ng mga artikulong nailathala na - hindi ko ginagamit masyado ang Content Translation para rito, pero gusto kong subukan ngayon. Tingin ko rin na maaaring suriin ang pagsasalin ng mga sanggunian sa Content Translation, dahil may mga sanggunian na maisasaayos lang sa Source mode.

Automatic translation to English:
The Content Translation Tool has helped me in contributing new articles to the Wikipedias, and I think supporting this tool can help encourage more users to contribute as the process simplifies the process translation. I want to focus on adding content to the articles that have already been published - I don't use Content Translation very much for this, but I want to try it now. I also think it is possible to check the translation of references in Content Translation, as there are references that can only be configured in Source mode.

In T209266#5290007, @Pginer-WMF wrote:

@Esanders, can you tell us more about how Visual Editor is doing this? In particular:

• Can VE identify problematic references?

It has to identify them for the purpose of showing the "This reference is defined in a template..." message. That happens in ve.ui.MWReferenceContextItem.prototype.getRendering which just checks if the reference content can be found in the internalList data structure (ve.ui.MWReferenceContextItem.prototype.getReferenceNode).

• If yes, how can Content Translation use that information to “treat” those “problematic references” in a way that works best for volunteers? (Where “treat” could mean excluded from the source article, gray out the reference in the source article, etc.)

Those all sound reasonable, but it sounds like a product decision for CX.

• Are the "problematic references" tagged in some particular way by VE or should CX replicate the approach that VE uses to detect them?

They should be identifiable using the approach described above.

In T209266#5483983, @Esanders wrote:

In T209266#5290007, @Pginer-WMF wrote:

• Can VE identify problematic references?

It has to identify them for the purpose of showing the "This reference is defined in a template..." message. That happens in ve.ui.MWReferenceContextItem.prototype.getRendering which just checks if the reference content can be found in the internalList data structure (ve.ui.MWReferenceContextItem.prototype.getReferenceNode).

Thanks @Esanders, this is very useful info.

The Editing-team has provided our input on this task and there is no further action on our end so we are moving this to external.

Until the root cause (T52896) is solved, the scope of this ticket is to identify problematic references (using the approach described in T209266#5483983) to process them. I'll update the description with a proposal on how to present these references.

In T209266#5643388, @Pginer-WMF wrote:

I'll update the description with a proposal on how to present these references.

I added the details to the description. Feel free to provide any feedback or point to missing details.

@Pginer-WMF I somehow accidentally moved this project (see change above), can you please help me undo this?

In T209266#7029875, @MavropaliasG wrote:

@Pginer-WMF I somehow accidentally moved this project (see change above), can you please help me undo this?

It seems that the board structure of the Visual Editor board has changed, and the old column no longer exist. Maybe @Esanders or @ppelberg know the right column for this one.