In T275479#6862637, @Jdlrobson wrote:

This looks ready for estimation to me?

For existing projects the logo would be the same e.g. if we decided to add Klingon Wikipedia, we'd use the Wikipedia logo right?

create a new logo specifically for incubator

For new projects without a logo we can use the Wikimedia logo (as we do on meta.wikipedia.org) surely?

@alexhollender, @Pginer-WMF - where would "create translations" link to?

@Krinkle - see my comment in T261842#6759083. We would like to be able to determine the number of users that are opting in and out of desktop improvements on their own. Right now, PrefUpdate cannot distinguish between these users and the ones that are using the new version of vector by default (because we've changed the configuration on that wiki).

Since we'll be spending more attention to this area of the page later on in the project, I think we should only consider a quick fix for the time being. @Jdrewniak - I think the line removal you suggested in T275158#6842244 would be appropriate here. Moving to needs analysis for analyzing this fix only.

@alexhollender - would this be the implementation task for this or is there more conversation necessary from the design perspective?

From standup - will close this task and add note on new copy into T275147: Empty state for language button and menu (short-term solution)

Discussed this with @alexhollender today. I'm a bit concerned with the language used here: "0 languages" could be confusing to new users who don't have expectations for language switching, in particular on smaller wikis. Is it possible to go back to "Languages" without the switch from one to the other?

All done here, will set up a follow-up task for the point made above

Looks good! I think we're all done

all done

Looks good, resolving!

@alexhollender - looks like we all agree this is a good idea. Assigning to you for a few basic birthday logos. Once we have a few options we can start sending out some messages.

Thanks @nray! Tagging this as next-up, but medium priority. Not considering it a blocker for deployment.

In T259798#6846201, @Edtadros wrote:

@ovasileva please take a look at the following (they are linked in the description as well):

Functionality

AC	Status	Details
1	❓	T259798#6846157

Window Size

AC	Status	Details
1	❌	T259798#6846159

All done!

Looks good, resolving

Resolving, thanks @Edtadros!

@Jdlrobson - got it. So if we currently have more than 24 languages, the ULS would automatically expand into columns with no extra work required. This seems okay to me and I think we can go ahead and decline this. @alexhollender - what do you think?

Resolving. @ppelberg - feel free to re-open if there's still issues

Looks like it! Resolving.

@Jdlrobson - in that case, declining. Do we have a task for turning off the instrumentation later on?

In T269155#6843072, @Jdrewniak wrote:

Well the deadline in the description certainly seems to have passed :P

I have some thoughts on this one though.
Previously the prototypes were entirely artificial and created in Vue.js as an SPA.

The prototype has the following features (from T263693#6628486, visible here ):

• language switcher
• sticky header styling refinements
• search in sticky header
• larger width considerations (header)

These are largely additive and don't change the page layout in a significant way. Therefore, what I think we can do is build them into Vector itself and use the page content service to provide real-life content and multiple languages. We can host this on patchdemo (or similar cloud instance).

I think the HTML, CSS and JS that Alex has produced in his prototypes can largely be moved over into a Vector patch as is and external dependencies like headroom can be copy & pasted for these purpose.

In T274784#6841519, @BBlack wrote:

This seems pretty straight-forward operationally, I think we can replicate the techniques used in T256750 for more wikis in general.

I think all of these wikis can be invalidated like this, although a couple of them (e.g. Portuguese Wikipedia) are big enough in terms of traffic volume that we might need to take some care to avoid overlapping other risks, and do them separately from the rest.

Is it realistic to break up the set into smaller chunks and invalidate them serially (could be on the same day, assuming all goes smoothly), or does it have to be all of these at once for validity of your statistics?

In T275147#6841473, @alexhollender wrote:

@Pginer-WMF @ovasileva @Jdlrobson thoughts on the above?