With the latest code, it is not possible to have different content for references with same name:

@Pginer-WMF Is there any other example with this issue? This particualr example is functioning correctly now.

This seems to be wrong - According to Wikidata ( https://www.wikidata.org/wiki/Q6242419#sitelinks-wikipedia ) the equivalent of sk:Harvbz is cs:Harvnb. Source language is Slovak (sk) and target language is Czech (cs). Will check

In T220752#5266162, @Vladis13 wrote:

How large performance issues can will? Will it a noticeable? From that link it not clear. AFAIU, the webfonts downloads once then caching for alltime.

As you can see non-English source languages also get ExternalGuidance features now:

Go to the first paragraph (after templates) that starts with "Józef Klemens Piłsudski..." When translated, the template will look like text without any formatting.

This plain text reference links are fixed in T216809: CX2: Wrong template is added despite being connected in Wikidata using https://gerrit.wikimedia.org/r/517796

In the master version of cxserver, the issue was not about mapping Harvnp to Sfn, but the translated content did not had any template. The reference link was coming as plain text

Enabling this in Wikisource seems ok, The webfonts feature when enabled by default in wikipedia, will cause large performance issues and this is the reason it is not enabled and left as a preference for user(See https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts).

For the purpose of review/test, I am going to explain a template and its mapping using the databse here.

I will clarify my question. We wanted to use a threshold score. Any mapping below that score wont be used. When referimento and referencia has a d value 0.40, and nom, nombre has 0.29, What does these numbers mean? Can they be interpreted as quality of match between 0 and 1? Which is best matching, which is bad matching based on these values? Are they really an indicator of good or bad matching or just an internal system value that is not useful?

After a brief analysis of the generated JSON mapping, this is what I am planning to do:

@diego I was processing the JSON files and trying to understand the values.

In T219819#5239785, @gerritbot wrote:

Change 506043 merged by Ema:
[operations/puppet@production] Redirect Google Translate any wiki source to mobile

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

through other entry points that are not the Contributions page or menu,

I removed the home wiki check - I think it does not say much about whether user is translator or not.

We don't have any other blockers for this puppet patch. Once this puppet patch is deployed, we have a configuration change https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/504261 to deploy.

Remaining: https://gerrit.wikimedia.org/r/513030 Added the preference, but the value is not used anywhere.

Minerva does not have the personal tools rendered on the screen. An invalid assumption about the presence of personal tools was causing a js error while rendering the (custom) header. This was resulting blank page. In this patch, I check for the presence of personal tools and render it. It it is not present, like the case of Minerva, in the place of personal menu, just add a button that shows user name and icon. Clicking on that takes the user to user page.

ok, it is done as general improvement in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/511865

@Pginer-WMF, do we need this feature as general enhancement irrespective of CX is beta or not?

One way to prevent the conflict is for the dot to take precedence. That is, if the dot is showing, the "Translate anytime" popup can be shown on both click or hover, but not the contributions menu. Once the dot goes away, the usual behaviour applies (hover for the menu, click to access Contributions).

@Pginer-WMF, did you consider that fact that the dropdown from Contribution link and the blue dot will play hide and seek when mouse pointer approach it?

The blue dot is implemented in VE using ve.ui.MWEducationPopupTool, but does not look like a reusable compoent. Will try to build something generic out of it

Will reassign when I return to this ticket.

Adding Language-Team tags for visibility in our phabricator boards

Screenshots from above patch:

@Pginer-WMF This sticky dialog at the bottom - is a non standard UI. The closest one in OOUI is
https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.PopupWidget

In T198205#5169527, @Pginer-WMF wrote:

In T198205#5169227, @santhosh wrote:

@Pginer-WMF confirm.

Ok so we are restricting the search to the main namespace when there is no ":" and searching everywhere where there is a ":". That sounds good, but I'd like to confirm this would lead to the following behaviour:

• Typing "Signature" will show among the results the Signature article but not the "Wikipedia:Signatures" documentation page.

Yes

@Petar.petkovic commented in this patch:

> > Presence of ':' in article title does not guarantee it is in non-main namespace. Take en:Terminator_2:_Judgment_Day for example.

https://gerrit.wikimedia.org/r/508790 allows search in all namespaes. Note that this patch did not implement any exclusion or inclusion checks.

Yes, we do. I'm moving the ticket back to the priority backlog for the remaining parts to be completed. Thanks for checking, @Etonkovidova

The problem of unwanted scrollbar for Math is a different issue - T222699: Edits in mw:Extension/Math content is not saved

The events to re-align the sections are fired correctly. In debounced manner, ve.init.mw.CXTarget.prototype.alignSectionPair is also invoked. But in in ve.init.mw.CXTarget.prototype.alignSectionPair we had done an early evaluation to see if alignment is correct. This is done using

mw.cx.ui.TranslationView.prototype.hasMisalignedSections = function () {
	return this.sourceColumn.$content[ 0 ].offsetHeight !== this.targetColumn.$content[ 0 ].offsetHeight;
};

We are checking if the source column height is same as target column. If so we assume that every section inside these columns are of equal height. If this method return true, we are not doing alignment.

As of today we have 106 RL modules. So as part of this ticket we reduced 25 RL modules. I am moving this ticket to done, but we need to actively look for more opportunities to reduce RL modules as we refactor or enhance featues.

In https://gerrit.wikimedia.org/r/506611, I started the first step towards this goal.

In T111000#5134693, @Ladsgroup wrote:

It keeps coming back https://hy.wikipedia.org/w/index.php?title=%D5%80%D5%BD%D5%AF%D5%A1_%D5%A2%D5%BB%D5%BB%D5%A1%D5%B5%D5%AB%D5%B6_%D5%A1%D6%80%D5%BF%D5%A5%D6%80%D5%AB%D5%BF&action=edit&oldid=6287353

@Esanders Instead of specific inspectors, generic inspectors are appearing for reference in source article column. Is this because Cite not able to find the mappings in target language wiki for the source language? Translations are always done in target language wiki.

The problem is with our html conversion of nodes as explained in screenshot.

This ticket is about an algorithm to find match between sections. We need to implement first and then discuss the UX and messages around the result of that matching, and edge cases we need to take . If we discuss all at once and keep the iterations blocked, we are not progressing. I had clarified this in https://phabricator.wikimedia.org/T204308#4987605 already.

Unassigning myself since @Petar.petkovic self assigned the patch