In T234323#5712752, @Pginer-WMF wrote:

Please let me know whether the following is correct:

• It is possible to make the page title to be non-editable and adjust the styling to be presented differently (e.g., in a smaller size as the proposed design)
• It is hard for the section title to be presented above the language indicators (i.e., "English - view page. Tagalog" line)

So the new design you are asking for can adjust the style but not change the placement of elements. Is that correct? Is that a hard limitation or something that can be refined as part of follow-up tickets?

Making target title read-only is possible. We already do that for source title. Text can be styled to be smaller as well.

Let me write a roundup of current state of changes made for section translation support and ask questions coming out of it. Work is not merged, so this is preliminary.

This change has added visible scrollbar to all pages on Vector, regardless of page needing scrollbar or not. What @matmarex wrote above.

I tried loading this same translation in production, but you still hold onto it. Can you still see the problem if you load the draft?

The warning which can be seen is not expanded, but it still says "Missing reference", whereas no reference is missing.

In T234323#5649270, @Esanders wrote:

server-side section editing will give you less performance gains than you might think (if you are using attachedRoot instead): T206228#5330185. Parsoid HTML download is usually not a bottleneck, and more time is spent building and rendering the CE tree than the DM.

Does attachedRoot allow to use multiple adjacent <section>s or we need to wrap those which define a range between two <h2> headers?

Are there any articles where this behavior is reproducible? I tried (locally) en:Tensor_product, which is mentioned in the description, but it works fine (using Google and Yandex), without 548956.

lang and dir attributes of source page title are still not updated and wrong when switching source language.

Content Translation treats some API publish errors specifically, like:

• spamblacklist
• abusefilter
• invalidtitle
• badtoken
• assertuserfailed
• titleblacklist-forbidden
• readonly

Guided Tour was removed from Content Translation in 502671 and 500811.

In T234323#5630091, @santhosh wrote:

@Petar.petkovic Can you clarify why we need to fetch a single section from cxserver? Don't we need to fetch full article as I explained in above comment?

We don't necessary need to load full article. There is still no REST API which returns only one section using parsoid and maybe their team had a valid reason not to include such option.
There is a simpler version catered to mobile devices, which I wanted to try out. Loading whole article seems lazy to me. There are some challenges with cross-section content, like named references, but they can be expanded to full definition for that one section.

Can you please try again with your browser console open (by pressing F 12 key on your keyboard) and put the output here?

In T234632#5605128, @Jpita wrote:

@Petar.petkovic maybe your article with the installation instructions will be useful here?

I don't think this ticket is about creating tutorials. We already have that for Mediawiki core, which seems to be focus of this ticket.

In T89707#5597426, @Jpita wrote:

@Petar.petkovic can you tell me how to test this on local?

You need to run a script located at core/extensions/ContentTranslation/scripts.
When you are in that directory, run php purge-unpublished-drafts.php. You also need to pass some command line option to your script:

• age-in-days - This option was existing before changes made to the script for the purposes of this task. It determines how old are the drafts which are being removed from DB.
• notify-age-in-days - This option was introduced for this task. It determines how old are drafts that you notify users to "continue their translations before they get deleted"
• really - Unless this option is included, you get log of drafts which users are notified about or which get purged and actions are not performed really. Without this option is what we call "dry run".

You can use something like php purge-unpublished-drafts.php --notify-age-in-days=1 --really to notify users to continue their drafts which are one day old. I'm using one day since you probably don't have older drafts available locally. You can also use other parameters and tweak you calendar date on your OS to test this.

In T232372#5597606, @Jpita wrote:

Check self::isPotentialTranslator( $user ) looks if user ever started any translation using CX

This means the invite should only show to users that have NOT started any translation using CX, right?

Right now the invite is showing for users (example user: Testpitanormal) with translations done using CX, maybe the logic is inverted?

The name of the method is isPotentialTranslator. As name explains, method checks if user is a potential translator, to which we should show invites. @Pginer-WMF we're talking specific invite here. Anyway, the method can confirm that user is potential translator in two ways:

1. User has made some translations with CX before
2. User has edited more than one Wikipedia

Your Testpitanormal meets the first criteria, that is why you see the invite.

In T188634#5590284, @Jpita wrote:

Issues found:

• removing article from "new translation" doesn't update list - needs reloading of the page video, the same for adding to the list, requires reloading

When you have Suggestions view open, adding/removing items using bookmark icon will require refresh. Popup notice with message saying that article is added for later is what we settled for. If you perform same actions when your In progress or Published lists are opened, and then navigate to Suggestions without reload, those new additions will show.

• T194476 happens on this feature as well - if we change the target language on the "new translation" the bookmarked article doesn't show on the bookmarks: example video

The reason is that article you selected exists in Catalan and when you reload, Catalan is selected as target language. Thus, article is considered as existing and removed from the list of favorites. Patch 537781 is meant to deal with this problem.

It was reported by @Jpita that new users on Javanese Wikipedia (on which CX is out of beta) are not seeing invite. I instructed him to edit articles on some non-Javanese Wikipedia and try again. The invite was not showing after that, so we did some investigation. Without a clear cause, I went on to investigate on my own.

I have double checked and Wikidata linking is working automatically after publishing again.

In T234417#5586389, @Pginer-WMF wrote:

In T234417#5577823, @Petar.petkovic wrote:

Also tried steps with different articles and language pairs on both production and localhost. @Jpita, @Pginer-WMF can you recheck if jump still happens? I also saw some jumps happening in the past, but I don't know when the last time was.

The jump does no longer happen for me. I selected different options on the MT card with the viewport at different positions and was not able to reproduce the jump. Before it was very hard not to find it, so I guess it no longer happens. But @Jpita, feel free to do further checks.

I also did checks using various viewport positions and MT options.

In T188634#5586156, @Jpita wrote:

@Petar.petkovic were you able to see this working on local?
on cx2-testing and prod I see the bookmark button but nothing is added to the for later list

Yes, I tested quite extensively on localhost during development.
Now I checked in production as well, using Serbian Wikipedia. First, while I was on dashboard suggestion view, I opened New translation dialog, found some random article which is missing in Serbian and bookmarked it. Popup message appeared. Page needed to be reloaded to see the changes.

I tried the same steps from the description and only got Javascript errors being logged in console.
Message "Machine translation failed" was not shown and jump did not happen.

I have looked this up, and there is a protein in human body called GATA4, which is also known as ASD2. We got this suggestion from GATA4 having ASD2 alias on Wikidata.
English Wikipedia page also lists ASD2 as an alias to GATA4. This is valid suggestion.

@Jpita, the fix is not yet deployed to cxserver.

With discarding feature, we have following workflow: 1) Load CX, 2) Open suggestions, 3) Discard unwated, 4) Open CX next time, 5) If nothing changed for seed articles, we get same suggestions, minus discarded one.
Without discard feature, when we get same set of articles, we need to reload all to get rid of some that we don't want to see. Maybe the behavior where we see a lot of the same suggestions is the problem here, but it annoyed me as a user.
What I propose is try to have discard for free or with minimal effort inside new suggestion system. If it requires more effort to modify than to remove (removing also takes some effort, usually minimal), abandon the feature.

I have made required changes. Here are the results:

Suggestion with image	Suggestion with no image

I would like to point out that for title "Incumbent", proposed article is a disambiguation page - Titulaire. Description says "We may want to filter out disambiguation pages, not showing them as a suggestion". @Pginer-WMF, you may want to create separate ticket to capture this. API introduced in T227571 offers disambiguation page as suggestion, this ticket is just about presentation.

@Pginer-WMF have you considered allowing users to choose where their published section translations should end up? In your mock ups, there was a way to choose which section to translate from source. Similar to that, we may enable users to choose between which sections in target article to insert newly translated one.

I used to make some efforts personally to determine articles with most languages that are missing in Serbian, regardless of topic. Tried Wikidata first, but without any additional filtering, query would timeout every time. Then, I started querying with instanceof and similar properties, which yielded some results. Some topics with large amount of items would still timeout, like movies, actors, etc. Many others complete successfully, like entrepreneur or bank.
I tried modifying your query slightly, most notably adding ORDER BY DESC(?linkcount) and running it for all categories you defined in topics.json. Some topics returned low quality (and quantity) suggestions, like Q1071 (Geography). Others worked nicely.
I see this approach could be useful. It depends strongly on Wikidata inter-item connections. We will need to make additional efforts to make some topics usable, maybe combining multiple categories.
Also, there is a question of how generic or specific we want our topics to be and how many of them. Do we want them configurable? Those are questions for @Pginer-WMF.

After updating the patch to match @Pginer-WMF's design, I did additional checks to verify all the specs are in place.
@Pginer-WMF, once you verify above screenshots look good and following two items are acceptable, I'm merging the patch:

• The invite does not go away after user starts typing inside the editor
• Blue dot and invite could be shown simultaneously:

In T232020#5552225, @Jpita wrote:

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

got this message a few hours after creating the article

, this was done manually by that user, right?

Yes, another user linked your new article to Wikidata item.
Patch 539222 to fix this problem for the second time was deployed with 1.34.0-wmf.25 and Wikidata linking is still not working.

I have made some visual adjustments to the patch from @santhosh. Here are some shots:

Generic invite	Suggestion with no image	Specific suggestion with image

In T205429#5528779, @Pginer-WMF wrote:

Petar, can you create the ticket? When checking the comments above the context seems to be a bit split through several comments and other tickets. So maybe you can collect the different pieces and put them together more easily.
Thanks!

I was not able to reproduce same errors, but actually got different one reported in T234220. Whether that cxserver error covers TypeError: Cannot read property 'shallowCloneFromRange' of null, when translating first paragraph of en:Vantaa to Spanish, is unclear.

In T206237#5533143, @Pginer-WMF wrote:

@Petar.petkovic, @santhosh, you worked in this area, is this ticket still relevant given the adjustments made to exclude content that we don't expect users to change?

Progress bar is displayed on dashboard. We take number of translated sections and divide that with total number of source sections, which includes those excluded from MT validation. Of that total progress, we mark percentage coming from MT. This calculation excludes sections blacklisted for MT validation.

In T205429#5527148, @Jpita wrote:

Final verdict: Problem with errors when clicking on reference is gone, but there are other errors when adding paragraphs. Should be fixed as part of a separate ticket.

@Petar.petkovic @Pginer-WMF is there a ticket for this?

Not that I know of.

We need to notify users about old drafts in 15 day windows. In order to avoid notifying same user twice or missing some draft, we decided to save timestamp of last notified draft in that run. That avoids saving and updating info per draft as well.
For purpose of saving this timestamp of last notified draft, new database table is introduced. Since this involves schema changes, by following guidelines, I've added Schema-change tag. Separate task will be created after patch is merged.
Patch which introduces this table can be merged before table is created, as new table usage is behind configuration.

The fix has landed with 1.34.0-wmf.24 (deployed on 18 Sep for group 1 wikis like Catalan Wikipedia), but linking to Wikidata is still not working.
Check out some of translations made on 25th of September. Timestamps of when article is created with Content Translation and when that article is linked to Wikidata are not matching. In the two examples, different user has added Wikidata link.

• Talal Derki is created on 01:21, 25 Sep 2019‎ (UTC+2), but article is linked on 07:11, 25 Sep 2019‎ (UTC+2) by a different user
• Similar example can be seen with creation of "Of Fathers and Sons" and its linking to Wikidata.

By looking at one of the last articles published before 1.34.0-wmf.20 was deployed, we see that time and author of article creation and Wikidata linking are the same.

I've tried reproducing this. Started translation of en:Vantaa to Spanish and added paragraphs starting with "Vantaa is bordered by Helsinki" and "The largest airport in Finland". Waited for save and reloaded the page. Clicked on only reference to see no error. Reference card was empty.

In T232583#5488235, @Jpita wrote:

@Petar.petkovic any hints on how to test this?

There were changes in how Abuse Filter sends data when publishing is prevented due to some filter being hit. Due to good communication, the changes were brought to our attention in time, before changes in Abuse Filter ended up in production. The changes are rolling out in 1.34.0-wmf.23.
We reacted and adapted our code to changes. That means, there is no environment (besides local) where you can see what would happen if we didn't adapt to changes.