@ovasileva that sounds good to me! (and I agree with the approach of always keeping the talk link in the dropdown regardless of the notification status)

In T274428#6820477, @alexhollender wrote:

@ovasileva @Jdlrobson: @RHo just pointed out to me that the yellow notice doesn't get added to the user links, it is actually the Talk page link transformed into (or replaced by) the yellow notice. In other words the yellow notice IS a special version of the talk page link. I'm noting this because it might mean that option #2 in the description is more complicated than we thought (since in new vector the Talk link isn't exposed on the page, it's inside the user menu).

It was my understanding following our team conversation that we'll retain the position of the yellow bar /after/ notifications icons rather than before.

@MNeisler A fix for the final_state: vector bug has been deployed to all wikis. Can you please verify that the data you see is free of anomalies?

Okay, with the helpful context that the recently added logging code sent, I was finally able to reproduce the final_state: vector bug locally.

There are several options I've thought of with this ticket (please feel free to add others!):

I need to add QA steps

This is the only case that I can think of and we should defend against it. We should also defend against the skin field being bogus data too.

@MNeisler Thank you for letting me know.

@MNeisler I'm thinking about the patch associated with this ticket a bit more - can you confirm whether or not we only want to send an event when the user clicks on a sidebar language while on modern vector? I ask because currently the patch we have sends an event when a user clicks on a language in the sidebar for both modern and legacy vector (and possibly other skins) which I assume is undesirable?

^^ I'm taking my name off this ticket as I've merged the patch related to this ticket yesterday

I need to add QA steps

@cjming Since the beta config currently sets the wgVectorLanguageInHeader to a boolean in InitialiseSettings-labs.php (the config for Beta), I see an opportunity for a small backport to set it to use the new array format introduced in this ticket:

@MNeisler As I mentioned in slack I believe all the config necessary to see the opt-in/opt-outs has been setup and deployed. I think it will be presented to you either as mediawiki.pref_diff or analytics/pref_diff (if you don't see anything with the name "pref_diff", that's probably a bad sign

^^ sorry for the noise, please ignore the above patches which I attached to this ticket by mistake

Config patches have been created, I'll plan to backport Thursday

For clarity, I'm defining option 1 as having the server make the html for one of the language widgets but that widget would be hidden until our javascript either reveals it or moves it/transforms it into the other language widget based on the A/B bucket determined by our javascript.

In T277315#6992102, @Anishdutta11 wrote:

Apparently, as you can see the issue was fixed with a minor change. I removed the max-width and min-width property from CSS and kind of worked. @nray do have a look at this.

In T218835#6966613, @Mholloway wrote:

The fixed patch finally rolled out on Tuesday 3/30 with 1.36.0-wmf.36. It looks like it's almost completely eliminated duplicate PrefUpdate events, down from several hundred duplicates per day prior to the change. Yesterday there were no duplicate events, and today so far there is only one duplicate popupsreferencepreviews event.

The new schema and instrumentation have now been deployed (thank you @phuedx for deploying!) . I believe additions to config (involving wgEventStreams and wgEventLoggingStreamNames) are necessary in order to see the events though which is why I've moved this back to doing