@ovasileva @RHo here are the first sketches regarding what the top of article would look like after shifting things around to make room for the language button.

In T263511#6535155, @Proc wrote:

May be of interest for enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Move_good/featured_article_topicons_next_to_article_name

additionally noting that we're currently auditing indicators on desktop (T263511) in preparation for moving the language switcher. Once we've gotten a bit further along we'll have a better sense of which indicators are present on various wikis, and will probably be more opinionated about if/how to show them on mobile.

In T260738#6509950, @Jdlrobson wrote:

@alexhollender can you take a look at what's proposed here and highlight any red flags? We'd like to make a start on this move to unlock other conversations with language team. We'd disable it to begin with to allow us to iterate so don't worry if it doesn't feel polished.

In T258974#6512785, @SBisson wrote:

In a follow-up task (T262289), we need to load localized SVGs from somewhere, we can't have our own private SVGs bundled with the Wikipedia Preview component for performance reasons. We could load them as assets from any of our server or from commons.

Were you planning on using them in any site or app? If so, maybe we could collaborate on making them available in a place that works for everybody.

Thanks!

@MichaelMaggs it seems clear that this issue is related to some kind of configuration within your account, rather than being a general issue. I would suggest reviewing any gadgets you have enabled, also look into global settings. Going to close this out. Sorry we couldn't be more helpful in locating your specific issue.

@MichaelMaggs did you try the links I provided in an incognito window?

@MichaelMaggs you can see the new desktop version as a logged-out user by adding ?useskinversion=2 to the end of the URL, or by viewing a page on one of our test Wikis (e.g. French). Sorry for not mentioning this before.

@MichaelMaggs thanks for posting the video. That looks to me like the result of some custom CSS. Would you mind trying as a logged-out user, and also in an private/incognito window to see if the same thing happens?

In T263950#6502339, @MichaelMaggs wrote:

Sure, happy to do that. Is there somewhere else I can upload the screen capture? It's 40 seconds, and comes out at 114MB which is apparently too big to upload here.

Thanks. People often use this tool and then provide a link to the upload: https://imgur.com/upload

@MichaelMaggs thanks for flagging this. Would you be able to do a video screen capture as you increase and then decrease the width of your browser? For me the width of the column remains consistent (also using Firefox on a Mac). I wonder if there are any user scripts or gadgets you have enabled that could be affecting this?

In T254695#6500519, @nray wrote:

Latest patch from @Jdrewniak fixes the tab overlapping the loading box. I did notice a somewhat interesting state when the viewport is resized to the point that the personal tools drops to the next line. When that happens, the loading indicator overlap the personal tools but that might be the expected/desired behavior (see below)? /cc @alexhollender

I'm assuming that is okay though and signing off

My initial thought was that we could shift any elements to the area just below the border, opposite from the title, like this:

In T256043#6491676, @Volker_E wrote:

@alexhollender The design spec is currently missing the menu dropdown box-shadow. We've unified it, while using only a very subtle one, for anything that is above the page content: @box-shadow-menu: 0 2px 2px 0 rgba( 0, 0, 0, 0.25 );. Please verify.

@Jdlrobson assets have been added to the description

@Jdlrobson here are some assets for you to try out:

I've merged this into T259331 because:

1. There is an extra line appearing at the end of the article

this is expected, the line is from the footer

In T260243#6466991, @MNeisler wrote:

@alexhollender - Any follow-up questions about these results?

In T258643#6440848, @Jdrewniak wrote:

Source files

I think we should upload the version of the files that are minified and in production, from the wmf-config repo (here). That will let us keep track of which logos have been uploaded to production, and which haven't.

Should the link always go to the article tab? Or should the history tab point to the history tab of another language?

@Johan I think this is the main question. Can you frame this request from a user need / workflow perspective? It may help clarify some of the open questions.

@TJones I was wondering if you have any opinions regarding the question I raised here: T255603#6416710?

@ovasileva @Jdlrobson I've added some QA tasks. Please feel free to add others. Also @ovasileva can you add the list of browsers to check?

Everything is looking good here: https://patchdemo.wmflabs.org/wikis/8ffa80ac67d564b7881bfe79d77691cb/w/index.php/Main_Page?useskinversion=2

In T252580#6433211, @Gilles wrote:

I guess that since the logo is separated out, that's just https://en.wikipedia.org/static/images/mobile/copyright/wikipedia.png for all Wikipedias, right?

After starting a session begins, if a user presses the search button again (or presses enter) with the search box empty, they are taken to the Advanced Search Page with no results shown (this is recorded in the dataset)

@MNeisler do we have any sense of how this happens? Is it someone typing something, deleting it, then pressing Search/enter?

In T257247#6428413, @Jdlrobson wrote:

@alexhollender I'm not really sure what's being asked here. Are you asking a developer to implement the designs in the description or is this something you want to work with a developer to do? I likely have bandwidth this week for prototyping if it's of interest.

@MNeisler @ovasileva
Ok, well currently this is totally speculative on my part and I think would only be worth investigating if we think do-over searches are somewhat common. @TJones any chance y'all have thought about, or know about, do-over searches (see above comments for context)?

@ovasileva I think T260091 is about removing the max-width from pages(?). This one is about adding it to Preferences.

Perhaps a better example to look at since there is more variety in where the icon appears (middle of a line, end of a line, etc.)

In T255603#6422156, @ovasileva wrote:

@alexhollender - just to make sure I'm following. This is the current behavior:

• Search that goes directly to the page - search results does NOT appear in the search box
• Search that goes to the advanced search page - results does appear in the search box

Yes that's correct.

thanks for fixing those two @Jdlrobson & apologies for putting the wrong tagline for Thai in there initially

@ovasileva @RHo please see the test results in the description. Nothing surprising here.

was just noticing that it's common for the search term to remain in the search box once the search has been submitted. I think this makes sense for search experiences where search leads you to a list of results. I'm not sure if it still makes sense in our case where you land on a specific result (rather than a list). Thoughts @RHo @Volker_E @ovasileva? I feel like it might help to reinforce what has just happened, though I'm not sure there's an issue with how it currently works.

@Esanders great point about the icon blending in with the text. I wonder if it needs to be blue?

In T258277#6413490, @Huji wrote:

All: some folks on fawiki have shown interest in reading more about the research that is the basis of "narrower reading pane" change. Which paper/book/website would you suggest?

@Jdlrobson sorry about that, just replaced the Thai tagline

@Jdlrobson I've replaced the Greek tagline SVG in the task description. You should now be good to go to make the final fixes:

• Thai tagline
• Greek tagline