@mpopov those events sound good to me. In regards to the wprov we'll be using a modified version of the serp:N format (as discussed on IRC) with just _es appended to the end.

Also, the reason this was breaking no wikisource specifically, and not wikipedia,
was that someone somewhere added a CSS class that adds extra margins to all the <ul>'s on the site.

I think this was a CSS issue due to me using display:inline-block to vertically position the top of the sidebar with the top of the search results. Reducing the margin from 10% to 8% seems to fix it.

The monitor might be very high res like 4K, or it might be a resolution in between 1 and 2x, in which case it would still receive the 1x image. In any case, replacing the icons with SVG's T129634 would fix this

Regarding the UI concerns

Based on the screenshot in figure 1, it seems that only one interface was being tested, without any of the suggested tweaks of https://lists.wikimedia.org/pipermail/discovery/2017-March/001464.html. Correct?

The grunt-sketch npm module caught my eye once, is that what you have in mind with this task?

Multiline text

Initially I preferred the 'full-bleed' thumbnails, but now I see how the rounded corners (and necessary margin/padding) add finesse to the design.

Just to reiterate my thoughts on the 1rem=10px idea.

Recently the WMF has discontinued JS support for IE8, meaning we only serve JS to ES5 compatible browsers. Opera 10.6 doesn't have full ES5 support, so if we serve the non-js version to Opera 10.6, that might fix this issue (off the top of my head I don't know how we'd target ES5 browsers only... right now we only target IE specifically as non-js...)

The icons we originally made to represent generic 'content types' such as quotations, definitions, textbooks etc. This was meant to help readers who might not know what the sister projects are. However, it turns out that it's hard to make icons that clearly represent these concepts (like a book icon vs textbook icon vs definition icon, they're all book-ish in the end) and an icon alone without any other visual distinctions doesn't convey this meaning. So I think moving away from these generic icons and using the project icons is the right move here. Then at least then, like @Gryllida says, users will be able to distinguish the project names easier.

@Dzahn we monitor the performance of the wikipedia portal carefully here:
https://grafana.wikimedia.org/dashboard/db/webpagetest-portals?from=1458474417000&to=1490010417359

Why focus on pixel output values when using rems? Personally, when using ems & rems I tend to set measurements like 0.75rem, 0.25rem etc, because those are much easier to calculate relative to 1rem.

A recent patch by @JGirault https://gerrit.wikimedia.org/r/#/c/342296/ changes the highlight color on the portal typeahead to light blue instead of grey. The patch would change the portal typeahead from this to this:

With the changes to the server config and the full list of URLs in the urls-to-purge.txt, I think we can mark this issue as done.

This issue should be resolved now.

With this patch https://gerrit.wikimedia.org/r/#/c/339631/ (deployed March 14)
the sister project icons for RTL have been improved.

I think there's a lot more CSS that can be removed here.
There's a nifty chrome devtools feature that highlights what it thinks is unused CSS. These results need manual review because it picks up things like the 'no-js' and typeahead styles as unused, but I think it provides a good starting point.

@MaxSem @demon
That's the idea :)
https://gerrit.wikimedia.org/r/#/c/341379/1/gulpfile.js

This seems like a useful feature, especially on mobile where language features are often buried in some OS settings.

This seems related to the work WMDE is insterested in doing related to the advanced search UI
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Advanced_Search_Workshop

@JGirault the above patch should fix that

oh weird I guess https://www.wikipedia.org/portal/wikipedia.org/assets/js/index-non-existing.js is also cached...
A different fake URL like https://www.wikipedia.org/portal/wikipedia.org/assets/js/index-non-existingX.js does produce a 404 like intended.

before the patch the following answers are expected:

• https://www.wikipedia.org/ -> 200 OK
• https://www.wikipedia.org/portal/wikipedia.org/assets/img/sprite-icons.png -> 200 OK 815
• https://www.wikipedia.org/portal/wikipedia.org/assets/js/index-non-existing.js -> 301 Moved Permanently
• https://www.wikipedia.org/portalx-> 301 Moved Permanently
  
  after the patch:
• https://www.wikipedia.org/ -> 200 OK
• https://www.wikipedia.org/portal/wikipedia.org/assets/img/sprite-icons.png -> 200 OK 815
• https://www.wikipedia.org/portal/wikipedia.org/assets/js/index-non-existing.js -> 404 Not Found
• https://www.wikipedia.org/portalx-> 301 Moved Permanently

Patch https://gerrit.wikimedia.org/r/#/c/339631/ is by no means a complete RTL solution, but rather addresses the most basic readability issues.

Since the page has been localized and text-direction has been set on the HTML element (although at the moment l10n is slightly broken as we work out some caching issues), I've started work on some minor changes that should improve RTL readability

• correcting the direction of the search suggestions
• placement of the icons in the sister project links.

Given all the rationale above, it seems best to leave the cache-busting filenames as is, therefore marking this task declined.

@greg there was no updates to the portal today. This brief error today must have happened because the portal was rolled back yesterday, but the HTML page remained cached on our end for 24h (we didn't purge that url). In general the updates are done during SWAT, and should be visible in SAL (not sure why it says the last deploy was last week though).

I think the term chrome can be useful if we define it (Pau's option #1).

yup fixed

A static prototype of the 'explore similar' feature is available at this URL
https://people.wikimedia.org/~jdrewniak/SERP-sidebar/index.htm

We want to share the sistersearch demo (http://sistersearch.wmflabs.org/) on a few mailing lists to get feedback, so I wouldn't break it just yet. Once we run the A/B test on a few production wikis we won't need the labs instance, so then it should be fine to break then :)

The labs instance with relforge indices has been setup and is available at: http://sistersearch.wmflabs.org/

@Volker_E good point. Given how the related articles stack on mobile, I think they can be certainly be considered the same UI pattern (although they serve a different function )

I added a column for mobile front-end, because the usage of this UI pattern is very prominent on mobile. To be honest, when creating the portal typeahead, we based the style on mobilefrontend because that was the primary usage of this pattern (that we could find). I knew visualEditor was capable of this pattern, but wasn't sure where it was being used.

As @hashar mentioned in his comment:

@Reedy I don't know much about the server setup of the Portals repo, maybe @MaxSem can shed some light on why the symlink is necessary in the first place? (or knows who might know?)

@MarcoAurelio this looks like an error compiling lwip - the node image processor & optimizer we use to optimize the images (this thing has been a pain with Node 6 - and it cause CI to run for 15 min :/ ). The error your getting seems to be around node-gyp and the version of Python. Node-gyp documentation says to install it globally:
https://github.com/nodejs/node-gyp#installation
so first npm install --global --production windows-build-tools
and then you need to install Python 2.7 on your system, it looks like you have version 3.5.2 (I don't know much about Python version management, so I hope managing multiple python versions on one system isn't a nightmare).
After that, npm install -g node-gyp should work, as well as the local npm install

@abian I agree that this is a weird setup. But just removing the symlinks would break the page in production, and cleaning up the apache config has the potential of breaking a lot of things. I don't know enough about apache to say if the recursion can be limited in any way, @Gehel do you?

wow that looks great!

@Volker_E The patch mentioned above changes the language icon color to the M82 blue (#3366cc).
https://gerrit.wikimedia.org/r/#/c/320761/1/prod/wikipedia.org/assets/img/sprite-bookshelf_icons%25402x.png,unified

I think that was literally a matter of no one clicking on these links 😢

@Deskana that's certainly miles better than the current settings :). Design wise I don't see anything wrong with sticking to simple form elements for these setting. I like how the bullet points can help group the options together, maybe putting them in the same order could work, like the "No typo correction" point first maybe?

@JGirault your right that 'pure' black should be reconsidered for text. This'll be discussed with the design team because wikipedia itself gives little guidance ( headers for example, are #000, but body text is #252525 ) and M101 currently suggests #222 as a 'text black'.

@Silraks, our repo shows that we received this translation on August 15th, and when I change my browser language to Latvian (in chrome, on mac) I do see the correct tranlsation.

thank you @RHo! that mobile design looks great!