https://dumps.wikimedia.org/other/contenttranslation/20200214/cx-corpora.en2tr.html.json also has this problem

Removed that line using sed -i '1043441d' cx-corpora._2_.html.json and the json is valid. So that comma is the only issue.

Still not working.

Because of missing vector style, the font-family for all elements in dashboard were missing. This caused it to fallback to browser defaults. After Niklas' patch, we have font-family: sans-serif as the default inherited font. It will make sure dashboard has sans-serif fonts. But, it is nearly equal to not having any font-family styling - that anyway is a bigger problem with mediawiki frontend.

As part of T242006: Technical exploration to support Section Translation workflow on mobile and desktop, I did some research and I have a proposal when we redefine the framework.

I documented the results of this exploration in a public google document: https://docs.google.com/document/d/1XgjDad5VTljZYQqD-urlFmPFlrhLe7NQIlARVB7064Q/edit

Since the translation editor has improved over the last years and it is very easy to skip a section from translating. I don't think there is anything actionable here. +cc @Pginer-WMF

Generic invite is supposed to show only once and only for the user having no translations yet. Can you help me getting the following code executed for the second case in browser console?

>> mw.config.get( 'wgContentTranslationExistingTranslator' )
true
>> mw.config.get( 'wgContentTranslationNewByTranslationShown' )
"true"

In T237607#5788191, @Jpita wrote:

I should get the generic invite, but nothing appears.

In T233405#5771424, @Jpita wrote:

@santhosh I still see the issue translating this from German to Dutch.
@KartikMistry can you confirm this is deployed in production?

I have submitted a patch to upgrade the core library: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/561430
Once merged and deployed to wikis, it will be ready to use.

Patch merged and available as 1.0.7 version at npm ( https://www.npmjs.com/package/@wikimedia/jquery.i18n )

I did some debugging by creating a test user as mentioned in the bug report and doing different workflows. For the new user, the suggestions never showed up, untill I created a draft translation. This concludes that
the logic in isPotentialTranslator is not returning true for new user.

I was checking if there is bug that caused the 0 numbers. I found that it is not bug, but we were not logging shown event for every cta.

Updated - https://www.mediawiki.org/w/index.php?title=Extension%3AUniversalLanguageSelector&type=revision&diff=3563512&oldid=3328188

screenshot after the fix

In T218420#5726939, @Jonesey95 wrote:

It is my impression that "CTX" is the content translation tool, but I could be wrong. The rest of this post proceeds on that assumption.

In T218420#5516863, @Jonesey95 wrote:

This bug still needs action. Here's a more recent illustration of the problem.

After fix:

In T236662#5672473, @KartikMistry wrote:

• ContentTranslation: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ContentTranslation/+/546901/

https://github.com/wikimedia/language-data is now available in npm https://www.npmjs.com/package/@wikimedia/language-data

This is running at http://opusmt.wmflabs.org/

Thanks

@Bstorm bigram is 36 GB RAM image, we need 10 more GB to use it. Currently we have only 26 GB remaining

We would like to proceed with our explorations and it is depending on this. Will there be delay? @Bstorm

After the fix :

In T234323#5625864, @gerritbot wrote:

Change 547708 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/services/cxserver@master] Section translation test
https://gerrit.wikimedia.org/r/547708

We have enabled X-Parsoid-Variant: php in our cxserver labs instance so that our testing systems will use output coming from parsoid/PHP

The issue is appearing when we publish content specifically when html from cx is converted to Wikitext. But curiously the error contains the successfully converted wikitext.

In T229075#5613923, @mobrovac wrote:

@santhosh try again now :)

Ok, I get x-parsoid-variant: php now.

@mobrovac @ssastry How do I know that the response is coming from Parsoid/PHP? Am I doing this correctly here? I see x-parsoid-variant: js in the response and I guess we expect PHP there?

Screenshot after the above patch:

Today I built a web fontend for Marian MT with OPUS data models:

In T232986#5576061, @Jpita wrote:

@santhosh why does Google not show here

if it is available here https://cxserver.wikimedia.org/v2/list/mt/es/en?

As a start, I attempted to make the development and deployment of the system simple. I creaded a Docker container that takes care of setting up the system - https://github.com/Helsinki-NLP/Opus-MT/pull/1
It need more work. My aim is to get a webserver that abstract MT engines and complexities, and expose a web api that does translation

This topic was discussed in details and the current undestanding is given below:

<section id="cxTargetSection0" data-mw-cx-source="undefined">

<p id="mwAg">While the evolution of sex dates to the prokaryote or early eukaryote stage,
    <span typeof="mw:Nowiki" id="mwAw">
        Bernstein H and Bernstein C (2013). Evolutionary Origin and Adaptive Function of Meiosis. In Meiosis:
        Bernstein C and Bernstein H, editors. Chapter 3: pp. 41–75 </span>
    <span typeof="mw:Transclusion"
        data-mw="{&quot;parts&quot;:[{&quot;template&quot;:{&quot;target&quot;:{&quot;wt&quot;:&quot;ISBN&quot;,&quot;href&quot;:&quot;./Template:ISBN&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;978-953-51-1197-9&quot;}},&quot;i&quot;:0}}]}"
        data-ve-no-generated-contents="true" about="#mwt2" data-mw-deduplicate="TemplateStyles:r886058088"
        id="mwBA">&nbsp;
    </span> <span data-segmentid="4" class="cx-segment">
        <a href="./International%20Standard%20Book%20Number" rel="mw:WikiLink" about="#mwt2" class="cx-link"
            data-linkid="5" title="International Standard Book Number">ISBN
        </a> <span about="#mwt2" typeof="mw:Entity">&nbsp;</span>
        <a href="./Special:BookSources/978-953-51-1197-9" rel="mw:WikiLink" data-linkid="6" about="#mwt2"
            class="cx-link" id="mwBQ" title="Special:BookSources/978-953-51-1197-9">978-953-51-1197-9
        </a> </span> </p>

</section>

Notes on how does section translation differs from full article translation

Technical implementation related notes:

Demo https://codepen.io/santhoshtr/pen/zjMMrG

https://cxserver.wikimedia.org/v2/list/mt/es/en lists all available MT engines now

For Quick QA: Using the content of

In my local testing I see that all params are adapted. Next step is to investigate the cxserver deployment related issues if any.

I think we need to recognize two extremes of category based suggestions. One is to find articles from a narrow category such as "rivers in serbia". Another one is "I am interested in Sports". The second type of users is more common because it is an abstract way of expressing an interest. The first one is about a specific search. If we try to serve both of these using a single interface, it is going to complicate. We should also see how this selection is done in non-wikipedia applications. I have used news reader applications, applications like magzter etc, where they provide a single flat list just enough to fill a mobile screen. For the first type of selection-narrow selection- a search box is given. If we enhance our source selector so that it can search in "Wikipedia article categories" we still can support such use cases. The nature of a second level or narrower topic is that, you can easily find one that is not in that list.

In T229242#5562697, @Pginer-WMF wrote:

I edited the description to capture a summary of the outcome and the design implications. Please, @santhosh and @Petar.petkovic, check and suggest any corrections.
I have some further questions about the implications of the approach:

• Is it possible to support the option to discard suggestions? Current suggestions have an option ("x") to discard them, preventing them to be shown again. I was wondering whether such system would work out-of-the-box with this new kind of suggestion, or they require further consideration (e.g., hiding such option for these suggestions, or support it differently).

In T232020#5551479, @Jpita wrote:

I just translated this article and is still not linking to wikidata
https://pt.wikipedia.org/wiki/Marianne_(serie_de_televis%C3%A3o)
https://www.wikidata.org/wiki/Q67521330

About the timeout of queries, one think I observed is, the time taken is a multiple of number of P31 values we use at a time. If we use only one topic at a time, I see that the time taken is in reasonable limits. This can be compensated by allowing only topic selection at a time as I did in my demo application.

I was exloring the Wikidata queries based on Property:P31 https://www.wikidata.org/wiki/Property:P31 and the subclasses. Here is a sample query https://w.wiki/9Cb - it tries to find all articles in a given wiki page with P31 or subclasses of P31 associated with.

@ssastry, when it is ready, let us know. We can do required testing and changes if any.

Screenshot from the above patch:

The VE config that shows the welcome dialog for first time editor is

After the patch https://gerrit.wikimedia.org/r/c/mediawiki/services/cxserver/+/537982

The adaptation happened correctly, but the en.wiki reference content has a te mplate style. - https://en.wikipedia.org/wiki/Module:Citation/CS1/styles.css. The templatestyle does not exist in he.wikipedia and MW parser is throwing that error in article page. yi and kab languages have corresponding template styles. To make it clear a ref with templatestyle is a valid markup. it becomes problematinc only when that template style does not exist in target wiki