Capacity has been increased, without apparent issues. When the experiment is launches, we'll hopefully have higher chances of faster request responses and lower chances of servers going out of capacity.

In T400565#11246409, @hueitan wrote:

i agree with the "All external links at a single place", seems all the links are external links, what about the title in "External links" or "Resources"?

Here're the different title example:

In T400565#11246247, @hueitan wrote:

@Pginer-WMF 5 months ago we have the stats link in the Help panel, do you think it is a better place to have it?

In T351748#11244679, @santhosh wrote:

This proposal is intended to support corrections for exact sentences.
...
if a user fixes a typo in one specific sentence, it gets fixed only for that instance (even if similar sentences exist).

In Wikipedia, what is the chance of a specific sentence appearing again in another place in exactly same way? According to one study it is 0.02% for wikitext-103 corpus. There is chance of repetition in boiler plate text or template or short phrases(example: proverbs). Since a number of combinations you can generate out huge vocabulary(in the scales of 100k) with 10 or so words is huge and chance of seeing that sentence again is near 0.

Making the panel (or its contents) clickable may not be very discoverable (especially on mobile). It may also generate an expectation of continuity (e.g., I click on "3 translations this month" and expect to reach a page that is about those translations, which is not the case).
I'd propose to add a link at the bottom of the panel with icon and label (similar to those in the help panel). For example, using the "cdxIconChart" icon with an "All translation stats" label.

In T351748#11208845, @santhosh wrote:

Notes:

• Does not work with words in sentences since it require “fitting” that selection of word in to the original sentence and keep grammar accurate.(in localization we call this “avoiding lego messages”.) -This limitation also applies to translation memory for phrases(incomplete sentences). Chances of encountering the (exactly) same sentence again less in general prose.

The proposal makes sense. It would be great to check that:

• Info on the parameters is respected (i.e., source/target languages are pre-filled accordingly).
• The preview card gets the input focus automatically. Allowing users to (a) identify it as the next step, and (b) be able to just hit enter to continue.
• Make sure that we are still allowing users to access links from machine translated content directly. That is, when reading a machine translation of article X, a user can still click on a link to article Y and get a machine translation of it directly without having to access the Confirm step (in the future we can consider a more subtle link preview: T359824).
• For instrumentation, it would be great to be able to identify how much crawler access these links get. Ideally, helping to distinguish crawlers trying to access translations from real users that access the Confirm step and drop-off.

We have observed no issues with global preferences so far. If there are specific issues, they can be captured in specific tickets.
In addition, we are in the process of graduating Content Translation out of beta. So the issues related to beta system should impact fewer and fewer users over time.

In T392753#10957227, @SGautam_WMF wrote:

Moving it to product signoff as we have documented some minor updates in following tasks - T398154, T395307

Wiki objecting have been captured in T398283, to keep the context at hand so that we can ping them once the feature has been improved based on their feedback.

Wiki objecting have been captured in T398283, to keep the context at hand so that we can ping them once the feature has been improved based on their feedback.

In T353244#10955272, @SBisson wrote:

There are still dashboard improvements subtasks, I propose to unlink them (make them independent tasks instead of children of this task) and resolve the current task.

The button was intended to be shown for the user own contributions page. I filled a separate ticket: T398169: Show the button for new contribution only on the user own Contribution page

In T388503#10953810, @SBisson wrote:

Should this task include adding the "Add content to existing section" option in the Publish options dialog?

Thanks for this analysis, @KCVelaga_WMF. This is really useful. Some minor comment: for the "Survey responses" section it may be useful to have (a) an overview of the responses, and (b) a screenshot of how the survey questions look like (or a link to T381886).

The recent report for the initial MinT for Wikipedia pre-pilot wikis (T391365) shows high loading times for machine translation views:

• Over 3s for 68% of the views
• Over 2s for 90% of the views.

The recent report for the initial MinT for Wikipedia pre-pilot wikis (T391365) suggests that the localization completion can be a factor that affects the usage of the tool:

Based on the data, this is the current status of localization for the UI in the languages of the 13 pilot wikis:

In T260115#10875612, @SBisson wrote:

In T260115#10874680, @ngkountas wrote:

@SBisson I believe that @Pginer-WMF in the last part about "Styling flickering" is referring to the changing font-weights of the sx-content-comparator-header__article-title and sx-content-comparator-header__section-title, which would be nice to get fixed.

I thought this dynamic styling was on purpose, giving more prominence to the content in the selected tab. When the first tab is selected, the source section is shown and the section title is larger, but when the second tab is selected, the full article in target language is shown and the article title is bigger.

In T327063#10929262, @SBisson wrote:

@Pginer-WMF the current CTA's label is "View missing pages". It makes sense for Special:Wantedpages but as we make the link target configurable, do you think we need text that is a little more generic? Something that would still work for Special:Watedpages, which remains the default, but also Wikipedia:RequestedArticles and other possible entry points about the creation of new articles that may exist on different wikis.

For cases where sections already exist, the idea was to let user control how contents were combined at the time of publishing.
From T252542, the options proposed were:

In T327063#10860064, @Nemoralis wrote:

T29311: Add a "create a page" interface to MediaWiki core might be a solution for this problem. I don't think this will require that many resources since it is just a special page with edit box.