Which page?

For review

Tested on itwiki on mobile and desktop site.

I see an unexpected item on itwiki mobile:

Just noting that it still overlaps the scrollbar, definitely for me because I am using a style with bigger scrollbars.

I would lean on not showing on suggested languages as I see that this preference should override that.

Per our maintenance table (in Language and Product Localization) this area is unsupported which means there is no guarantee/timeline for code reviews.

Tested locally.

Tested locally in Chrome.

In T412474#11899897, @andrea.denisse wrote:

Hi folks, I'm sorry we missed this task. @KartikMistry brought it to my attention during the hackaton. I'll add it to my team notes so we can take a look at it.

Feel free to add the SRE Observability tag so we don't miss future o11y tasks. :)

Tested locally.

@lucamauri Could you give translatewiki commit access:

The command "cd 'mwgitlab/lucamauri/recent-activity'; git add .; if ! git diff --cached --quiet; then git commit -m 'Localisation updates from https://translatewiki.net.'; git rebase 'origin/main' && git push origin 'main'; fi" failed.

Do we know what caused the regression?

@SBisson I think signature would be solved easily if we direct to discussion tools using https://www.mediawiki.org/wiki/Help:DiscussionTools#Preloading_message_content

Thanks for the work!

I observed a small "shake" (movement) of the page when the language selector is opened. It's very minor so not treating it as a blocker.

Removing tag as this is not actionable for translatewiki.net

I am fairly sure we have fixed on cause of this. For the other one, I have created T427756: Cannot read properties of undefined (reading 'getTitleForLanguage') at getCurrentTitleByLanguage.

@SGautam_WMF Please review when you have time to decide if this is good enough for now or whether we explore a better solution.

Curiously, it actually works as it should for me in a normal broser window (Firefox 146.0 on Ubuntu, FWIW), but when I try the same when logged in with the same account in an incognito window, it doesn't work.

I did action=purge and now I see it on https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/Mid-year_review/ar too. At least it is self-correcting.

I made a null edit to https://meta.wikimedia.org/wiki/Translations:Wikimedia_Foundation_Annual_Plan/2017-2018/Mid-year_review/342/ar and https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/Mid-year_review/ar exists now. One oddity is that arabic is not on the language list on this page:

@abi_ Please clarify status of the open patch before moving to pending deployment. It should either be merged, abandoned or untagged for this task.

If search matches a language code, that result should be the first one suggested.

In T380749#11959609, @stjn wrote:

Can we at least do this for logged-in users, please? It’s a very bad experience to type in https://translatewiki.net/ in the browser bar and end up on a page that doesn’t have a sidebar, any notification indicators, or a normal search bar, as well as no easy way to go anywhere else other than through my user page. As a semi-regular user of the website, I really struggle to understand who is helped by the main page functioning like that.

At least the lowest hanging fruit.

We have upgraded PHP and memory limit might have changed as well.

Tested on local development environment. Thanks a lot!

Works fine locally, but I don't have minerva skin installed so I cannot test that part.

Works fine, apart from the main pages. Opening separate task for that.

No longer opening unexpectedly, but when using it, the search bar moves around because the bottom is anchored to the element. By default it would be good to open it below the button if there is space to avoid this unwanted behavior.