Thanks, @Cntlsn. That alignment is not a blocker for release, but is an important design element that we should fix. I am moving this to "In Progress".

@Dyolf77_WMF -- I added namespaces 100 and 101 to the list. Those are the Portal and Portal Talk namespaces. They are somewhat like reading behavior, so I think we should obscure them as well.

Okay, cool. For simplicity's sake, I'll move this to Needs PM Review, and we'll make a new task if we need to switch to toasts.

@SBisson -- the reason I felt strongly about this feature is because (according to my phone), all Czech mobile users would see the third tab wrap to the second line, which I thought was a really confusing experience.

This is ready for development.

Thanks @Volker_E. I modified the issue description to only be about the vertical alignment of the icon.

@Dyolf77_WMF -- when the features are enabled, you can:

@Cntlsn -- is this something we should fix?

@Cntlsn -- I think we should start with the option of the pulsing call to action, and I think it should only pulse during the first edit session that a user sees it. We should do it such that it pulses until it is opened. Could you please update the description with those specifications? After you do that, I'll move it to Upcoming Work along with specifications on timing and how we will be careful to detect the difference in open rate.

The next step is for me to write the copy for the new designs.

This has been working well in production for weeks.

Our initial EventLogging has been working well on desktop and we have our purging strategy under control.

The help module has been functioning well in production for weeks.

The mentorship module has been functioning well in production for weeks.

The impact module has been functioning correctly in production for weeks.

@SBisson @kostajh -- I see this working as desired in Test Wiki on both desktop and mobile. Is this still "In Progress"? Or have we kept it here because we still have open questions on whether it will be a dialog or a toast on mobile?

@Trizek-WMF -- do you know why the privacy policy on Meta says "100% complete" at the top, but there are still lots of messages on Translatewiki?

This is ready to be worked on once we bring it onto the sprint board. It can go straight to Ready for Development.

Looks good to me. Leaving in Needs PM Review until everything is all good in Czech and Korean Wikipedias.

This looks good to me. Leaving this in Needs PM Review until after everything is in Czech and Korean Wikipedia and working fine.

@SBisson -- we do not need to fix the old URLs. Is the fix for this issue the same as for T225661? If so, then both the task can live in Design Review so that @Cntlsn can verify that they work for him in Test Wiki when the code is there. These tasks do not block the mobile release.

This bug can go in Ready for Development.

@kostajh -- I just tried this out, and I understand it now. I do think we should have it high on the list of things to address, but it's not a blocker for the mobile release. I'm adding it to the "Desired" list in the MVP task.

After talking about this in retro today, we've decided to continue to use the current standardized component, but to modify it to reflect the desired design in spirit as best we can.

This is not urgent, but would like to do it by July 5.

@kostajh -- could you give us a feel for whether a lot of users are likely going to experience this, or a few? One of the considerations is that Czech and Korean are both different lengths than English, and I don't see the problem with those languages on my device. Trying to get a sense of whether this is something we should address in the near term or the medium term.

I tried it in private browsing mode and still see the same issue:

@kostajh -- if the user continues to see "posted 2 seconds" ago even when a minute has gone by, how long does it take to update?

@Etonkovidova -- I saw it on a real iPhone 6S running iOS 12.2 and Safari 12.1.

@SBisson -- we want it to be the 2nd option (opening the talk overlay), because we want the behavior to be consistent with what AMC is doing by default.

Thanks, @Inaki-LL. Tagging @Trizek-WMF to help coordinate translations.

@Cntlsn -- I think your theory makes sense (though I don't know if we have evidence that it's correct -- you could imagine it the other way around, that a red link is attractive). In any case, I think you should make a subtask of T220552 about this, and we can triage it later. I am eager to see the homepage discovery rate after we implement T222852 to see if it continues to need improvement.

Hi @Inaki-LL -- thank you for translating! We look forward to working with your community sometime soon. I'm tagging @Trizek-WMF, who is the team member who sets up pages for translation.

Re-opening because we are seeing this in a supported browser. @Cntlsn -- could you please attach a video of this happening? I am removing this from the MVP "Blocker" list and putting it in the "Desired" list because it is only in one browser.

Re-opening because we are seeing this in a supported browser. @Cntlsn -- could you please attach a video of this happening?

Thanks for these detailed thoughts and drawings, @Dvorapa. I think you bring up several good potential ideas for the future. The overall strategic thinking with bringing newcomers to the homepage is that there are many potential things we think newcomers might want to do, but those things are spread out all over the wiki. We see in our research that newcomers wander around being confused about where to start. We think that the homepage can be a clear place that leads them to the right places for them to get started. That's why we want to make sure all newcomers know about the homepage: because it can be the place where we show them many other things to do. For instance, we hope that a newcomer might discover a good portal or WikiProject from their homepage, if we put the right one in front of them.