Some logs from my local after merging Niklas' patch,

Export stats from core,

I've tested the instance setup by Kartik. You can view the test report in this Google sheet. I had to test some cases on Translatewiki.net.

@Jpita - This is now deployed on language-translate.wmflabs and can be tested.

Export stats from core on 21st Jan, 2020 - 144 seconds (~2.5 minutes)

[2020-01-21 06:52:45] translation-exports.INFO: Starting exports for groups - core... {"private":false} []
[2020-01-21 06:52:45] translation-exports.INFO: Calculating stats for group core {"private":false} []
[2020-01-21 06:52:45] translation-exports.INFO: Finished calculating stats for group core. Time: 0.019475936889648 secs. {"private":false} []
[2020-01-21 06:52:45] translation-exports.INFO: Exporting languages (304) for group - core. {"private":false} []
[2020-01-21 06:55:08] translation-exports.INFO: Done exporting languages for group - core. Time taken - 143.55314898491 secs. {"private":false} []
[2020-01-21 06:55:08] translation-exports.INFO: Time taken by 'collection' for group core - 123.1598918438 secs. {"private":false} []
[2020-01-21 06:55:08] translation-exports.INFO: Time taken by 'ffs' for group core - 20.390076875687 secs. {"private":false} []
[2020-01-21 06:55:08] translation-exports.INFO: Time taken by 'definitionFile' for group core - 0 secs. {"private":false} []
[2020-01-21 06:55:08] translation-exports.INFO: Finished export process for groups - core. Time: 143.77037096024 secs. {"private":false} []

We believe that the reason for failure is same as described here - T192945: Make EchoNotification job JSON-serializable . EmaillingJob accepts MailAddress class object as a parameters which is not JSON serializable and hence not supported by kafka-based queue.

I've submitted a patch to reduce the timeout back to the original 5 minutes. Resolving this task for now.

Here are some further logs from core exports from the 17th and 20th of Jan, 2020. The time has been below 3 minutes.

Following patches have been submitted for this,

Following are the details for the request,

reqId: XiDOGQpAICMAALtmgXkAAACJ

I see two issues,

Thanks @MarcoAurelio and @Urbanecm. I'll start investigating it.

The changes made for this have been deployed on translatewiki.net and we're seeing very promising improvements (340% improvement for the core group).

Please see comments here,

@Jpita - Yes, it has been, but Niklas subsequently found another issue (Closing the dialog via Esc or clicking on the overlay was not removing the setlang parameter from the URL) which was fixed in a separate patch - https://gerrit.wikimedia.org/r/564559. Lets wait for that to get merged and deployed too.

These changes have now been deployed on all the wiki's.

This patch has been deployed on translatewiki.net

In T63115#5787631, @Jpita wrote:

@KartikMistry can u deploy this on language-translate.wmflabs.org so I can test it please?

In T231181#5780904, @abi_ wrote:

We currently have a patch to add UnicodePlural validator for OpenStreetMaps (https://gerrit.wikimedia.org/r/c/translatewiki/+/562045) which is a Ruby project. Once we have deployed that, and tested it on translatewiki.net, I think this patch can be resolved.

This has been deployed on translatewiki.net.

Marking this as resolved since this has been deployed on Mediawiki since the 7th of January, and has not received any bug reported.

I ran some profiling on the translatewiki.net server today,

Noticed that we're having some random issues with reading repositories. This is happening with both Gerrit and Github.

Merged, I'll be tested on a new vagrant box later next week.

Possibly related - https://github.com/ruby-gettext/gettext/issues/66

In T230100#5783408, @gerritbot wrote:

Change 562585 had a related patch set uploaded (by Abijeet Patro; owner: Abijeet Patro):
[mediawiki/extensions/Translate@master] Reuse title conditions built using keys when possible
https://gerrit.wikimedia.org/r/562585

We currently have a patch to add UnicodePlural validator for OpenStreetMaps (https://gerrit.wikimedia.org/r/c/translatewiki/+/562045) which is a Ruby project. Once we have deployed that, and tested it on translatewiki.net, I think this patch can be resolved.

Did a couple of manual runs on the server,

In T239245#5764052, @Urbanecm wrote:

Done - Abi probably forgot to do that. Thanks for your patch and patience!

This is done and deployed on Translatewiki.net

Here are some of the logs that I saw,

In T63115#5755989, @Krinkle wrote:

In T63115#5755037, @Fomafix wrote:

• The dialog doesn't have a support for keyboard navigation.

Aye, yeah, using Tab goes through the entire page header body and footer before reaching the dialog. And then, it starts with the button, not the header. We'll want to start by programmatically moving the focus to the content of the dialog or its first child somehow.

Thanks @Fomafix for your inputs on the patch and the subsequent fixes that you did.

Claiming this, since I'm now working on this. @Eugene233, thanks for your initial patch.

This has been done and deployed on translatewiki.net

We've deployed this on translatewiki.net. For OpenStreetMap, the valid values for the html.direction message has been set to ltr, rtl.

We've deployed this on translatewiki.net. For OpenStreetMap, the valid values for html.direction have been set to ltr, rtl.

This is working well on translatewiki.net server.

@Jpita - We'd like you to double check this change to ensure that everything is working as expected. The Mediawiki API can return JSON data in different formats which you can read about here.

Did some general testing. Here are the things that I tested,

This has been merged and deployed on translatewiki.net.

In T237919#5741516, @Aklapper wrote:

@abi_: Patch merged. Is there more work to do in this task, or can the status of this task be changed to resolved?

In T237910#5739283, @Crutishnyk wrote:

...with a warning.

Does this mean that I need to enable an enforce property?