First of all, as some of you may have noticed, the beta page was displaying the old search box around 9am PST.
We had similar issues before ( and apparently the problem keeps coming back.
We'll try to improve this process.
In the meantime, please keep keeping us informed when this happens so that we can re-deploy as soon as possible.

- Moushira: I think most of your concerns are not related to this improvement (the new search box). 
If you are seeing these issues on too, I suggest you create Phabricator tickets or follow-up with Chris and Deb directly.

- Deborah: Thanks for finding this bug. I created

- Trey: Thanks for finding this bug, I created

- Moushira/Trey: This sounds like quite an important, legal concern.

I can't say much about this (I am not a lawyer either...), but I can say that:
- these images are returned by the search API, 
- this search API and these thumbnails are currently used in several places, like the mobile webpage ( and the mobile apps (iOS, Android).

Deborah, Dan, Chris: Please help figuring this out.

Per Deborah's request, I moved the deployment to Fri 3/11 - 00:00–01:00 UTC - Thu 16:00–17:00 PST.

Thanks for your engagement. It's very helpful.

On Wed, Mar 9, 2016 at 1:53 PM, Trey Jones <> wrote:
0. My work Mac has a retina display and I see it too. Probably looks the same on recent smart phones, too. The "blurry" bits are old low resolution images, that's all. But next to crisp fonts, they do look blurry.
4. I also have worried slightly about fair use images showing up in the type ahead. I think the problem is that fair use images should (perhaps) not be used in the type-ahead drop-down. Take the image on the page —it's not licensed under creative commons; it's copyright by The Rolling Stones, or their record label, or someone like that. It can accompany the article under "fair use" for purposes of identification, education, and/or criticism. Whether it can accompany the title in the type-ahead is unclear. The explanation for on the image's page ( ) says:

The image is used for identification in the context of critical commentary of the work for which it serves as cover art. It makes a significant contribution to the user's understanding of the article, which could not practically be conveyed by words alone. The image is placed in the infobox at the top of the article discussing the work, to show the primary visual image associated with the work, and to help the user quickly identify the work and know they have found what they are looking for. Use for this purpose does not compete with the purposes of the original artwork, namely the artist's providing graphic design services to music concerns and in turn marketing music to the public.

It seems reasonable that including it in the type-ahead also contributes to the user finding and identifying what they are looking for—and I know there was a lawsuit about Google showing thumbnails in image search that went in favor of Google—but "reasonable" is not really a legal category, and I am not a lawyer.


Trey Jones
Software Engineer, Discovery
Wikimedia Foundation

On Wed, Mar 9, 2016 at 4:18 PM, Jan Drewniak <> wrote:
Hi Moushira, 

0. I can't speak to the blurriness of the text, does it look blurry in that section only? 
1. Thanks for pointing out the Russian text bug. This issue is occurs because the cyrylic font on ubuntu seems to be slightly wider than on other operating systems. We hope our up-coming A/B test will make this a none-issue though :) 
2. We have plans to disable the 'find a language' feature since it has been broken for quite a while and nobody seemed to notice, but we will replace it with something better eventually.
3. We have localization on our road-map, but there is a lot of work to be done server/infrastructure-wise to make that a possibility. 
4. I'm not sure I understand the concern with using fair-use images (to be fair I don't know the slightest thing about what is and isn't fair-use). For the search-suggestions we use the thumbnail image associated with the wikipedia article, just like on mobile web, if the thumbnail is violating copyright, then it's probably as issue with the article content, no?  


On Wed, Mar 9, 2016 at 7:15 PM, Moushira Elamrawy <> wrote:
For c

On Wed, Mar 9, 2016 at 7:39 PM, Moushira Elamrawy <> wrote:
Hello,  I have a few comments:

0. Both Wikipedia text on the top and sphere are a bit blurred, no?
1. The Russian text is overlaying the Wikipedia sphere is kind of distracting.  I know this is how it currently looks like on stable, but possibley with the minor magnification, it just doesn't seem right. :)

For clarity, this is for Firefox 44.0 on Ubuntu! :)


2. What is the <find a language> field supposed to do?   Right now it on beta and stable it directs to incubator, even for existing languages.
3. When I hover with my mouse over the languages, around the Wikipedia sphere, I get the name and description in native language again, while it might be more interesting to have this displayed in the language of my browser.   Same applies to the list of languages below.
4. The dropdown menu shows fair-use images while searching in English, but I assume this will be figured out soon.


On Wed, Mar 9, 2016 at 7:01 PM, Deborah Tankersley <> wrote:

Things look really good! I haven't been able to fully test everything I want to, as of this morning, but looks very nice! :)

I did find something interesting on Safari (on a mac) and using a private browser (so I didn't have to clear my cache) the type-ahead didn't seem to work for me (with the meta data display). Can someone verify that they see the same thing?

Thanks - I'll test more later on today!


Deb Tankersley
Product Manager, Discovery
Wikimedia Foundation

On Tue, Mar 8, 2016 at 9:20 PM, Julien Girault <> wrote:
Hi everybody,

Following up on last week's email, the team has made significant improvements to the enhanced search box:
  • We developed a JavaScript-only version of the language picker, on top of the previous patch, so that users who have JS enabled (93% of our traffic) get a nicer version of the language picker.
    • Shorter language code is displayed, allowing more space for text within the search input.
    • Triggers the native selector on mobile devices.
    • The search box looks better overall.
Users who disable JavaScript, or are using old IE versions, get the native selector already presented in last email.  

It's merged into master, and deployed on beta!

Deployment to production 
(Phab ticket for reference: Epic T125472)

Last chance to enjoy the "good old search" !

Chris and Deborah will answer any question or concern related to this deployment

Some screenshots:

Modern browsers:

Chrome, no-JS: (basic language picker because no JS)

IE browsers:

IE8, JS: (basic language picker because old IE)
IE9, JS: (basic language picker because old IE)
Note: the CSS for the suggestions needs some attention, currently seeing weird padding.

Mobile browsers:

iOS, no-JS: (basic language picker because no JS)

Note that JS is required for the typeahead/suggestions feature (this is already the case with the current page, no regression).
If you don't have JS, you will have to submit the form in order to get results.

Next A/B test: Use language detection to re-arrange the primary links to suit the user better

Coming soon! 
The team has also made significant progress, stay tuned!

For the portal team,


discovery mailing list

discovery mailing list

discovery mailing list

discovery mailing list

discovery mailing list