Page MenuHomePhabricator

CX2: Support for references added by name when the details are inside a template
Open, NormalPublic


In the "reuse reference" style, <ref name="name" /> is used in the text and the information for such reference is provided at a different place using the same name. Support for this kind of reference was provided in T206756, but there is one particular case not supported yet: when the reference details are inside a template.

For example, when translating the Morton's toe article form English to Spanish, the reference in the first paragraph (which is defined inside the infobox, based on Infobox medical condition (new) template) is not included in the translation when the paragraph is added to the translation:

The expected behaviour would be to get the reference added. If that were not possible, at the very least we should signal the reference as missing (similar to T203160) for the user to add it manually.

We need to consider that in this kind of scenarios the infobox/template containing the reference definition may be added in a different order than the paragraphs that use such reference, not be added at all or fail to adapt.

Related ticket: T52896: VisualEditor: Support editing citations defined within a template

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 12 2018, 9:58 AM
Pginer-WMF triaged this task as Normal priority.Nov 12 2018, 9:58 AM
Pginer-WMF moved this task from Needs Triage to CX2 on the ContentTranslation board.
santhosh added a subscriber: santhosh.EditedNov 16 2018, 6:16 AM

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.

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?

Pginer-WMF updated the task description. (Show Details)Nov 16 2018, 8:39 AM

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



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

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.

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.


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.

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.

Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptMar 29 2019, 7:25 PM

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?


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.