Hello!
I'm very pleased to announce that we've updated the Wikipedia.org http://wikipedia.org/ portal page with a brand new search box that is more prominent and will now display meta data with images (as available) in the search results (link https://commons.wikimedia.org/wiki/File:New_searchbox_with_metadata.png).
This was a large effort by the Discovery Portal team to develop a JavaScript-only version of the language picker, so that JavaScript enabled browsers will see all the new meta data. Alongside that effort, we also ensured that in JavaScript (JS) disabled browsers (or older Internet Explorer versions), our visitors won't have a bad experience when choosing a language to search in. (Note 1: in older IE versions and JS disabled browsers, the type-ahead and meta data search results information will not be displayed.)
We also implemented a shorter language code (ie: EN for English, ES for Spanish, etc) to allow for more characters to be typed into the search box. When a user toggles the language selector, the full language name will be displayed in the dropdown for easy finding of the language you prefer to search in. For the more technical minded - I've also uploaded, to Commons, a screenshot https://commons.wikimedia.org/wiki/File:Sample_browsers_tested.png of one of the ways we test our code, visually.
We're interested in hearing your feedback or if you have any questions! (Note 2: My apologies for not getting this email out yesterday, but I had had issues with size limitations of my screenshots.)
On behalf of the very happy Wikipedia.org Portal Team,
Deb -- Deb Tankersley Product Manager, Discovery Wikimedia Foundation
https://en.wikipedia.org/wiki/Special:Search?search=%E0%B4%B6%E0%B4%95%E0%B5...
Failed my dream :(
Any string in any language in any wikipedia project. How far is my dream?
On 11 March 2016 at 23:48, Deborah Tankersley dtankersley@wikimedia.org wrote:
Hello!
I'm very pleased to announce that we've updated the Wikipedia.org http://wikipedia.org/ portal page with a brand new search box that is more prominent and will now display meta data with images (as available) in the search results (link <https://commons.wikimedia.org/wiki/File:New_searchbox_with_metadata.png
).
This was a large effort by the Discovery Portal team to develop a JavaScript-only version of the language picker, so that JavaScript enabled browsers will see all the new meta data. Alongside that effort, we also ensured that in JavaScript (JS) disabled browsers (or older Internet Explorer versions), our visitors won't have a bad experience when choosing a language to search in. (Note 1: in older IE versions and JS disabled browsers, the type-ahead and meta data search results information will not be displayed.)
We also implemented a shorter language code (ie: EN for English, ES for Spanish, etc) to allow for more characters to be typed into the search box. When a user toggles the language selector, the full language name will be displayed in the dropdown for easy finding of the language you prefer to search in. For the more technical minded - I've also uploaded, to Commons, a screenshot https://commons.wikimedia.org/wiki/File:Sample_browsers_tested.png of one of the ways we test our code, visually.
We're interested in hearing your feedback or if you have any questions! (Note 2: My apologies for not getting this email out yesterday, but I had had issues with size limitations of my screenshots.)
On behalf of the very happy Wikipedia.org Portal Team,
Deb
Deb Tankersley Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 11 March 2016 at 10:52, ViswaPrabha (വിശ്വപ്രഭ) vp2007@gmail.com wrote:
Failed my dream :(
Any string in any language in any wikipedia project. How far is my dream?
I share your dream! :-)
Unfortunately, the dream is quite far away from reality. Querying every search index would put a big performance strain on the search servers. Additionally, it would likely return you a bunch of really irrelevant results, so there's a lot of user experience implications that would need to be figured out as well. Discovery is not actively working on this at present.
Thanks, Dan
Lovely work.
On Mar 11, 2016 5:32 PM, "Dan Garry" dgarry@wikimedia.org wrote:
On 11 March 2016 at 10:52, ViswaPrabha (വിശ്വപ്രഭ) vp2007@gmail.com
wrote:
Failed my dream :(
Any string in any language in any wikipedia project. How far is my
dream?
I share your dream! :-)
Unfortunately, the dream is quite far away from reality. Querying every search index would put a big performance strain on the search servers.
Perhaps you could do this w two queries, one to a composite index that is only updated weekly.
Additionally, it would likely return you a bunch of really irrelevant
results,
Make this opt-in, add a different background color for results from the all-language index, & divide their search-relevance by a language-prominence factor...
+SJ
Good work :D
2016-03-11 19:39 GMT-04:30 Samuel Klein meta.sj@gmail.com:
Lovely work.
On Mar 11, 2016 5:32 PM, "Dan Garry" dgarry@wikimedia.org wrote:
On 11 March 2016 at 10:52, ViswaPrabha (വിശ്വപ്രഭ) vp2007@gmail.com
wrote:
Failed my dream :(
Any string in any language in any wikipedia project. How far is my
dream?
I share your dream! :-)
Unfortunately, the dream is quite far away from reality. Querying every search index would put a big performance strain on the search servers.
Perhaps you could do this w two queries, one to a composite index that is only updated weekly.
Additionally, it would likely return you a bunch of really irrelevant
results,
Make this opt-in, add a different background color for results from the all-language index, & divide their search-relevance by a language-prominence factor...
+SJ _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Let me elaborate my case a little bit:
Here is the scenario:
*I spent a lot of time luring fresh internet users into the terrains of free knowledge, principally WM projects, and specifically WP, in a bustling Global South region, interlaced with several local language projects. *I have always treated Wikipedia, first for the readers, next for the builders. Without more people becoming readers, there is no way more builders turn in.
*Most of these people are aware that Google will fetch them needed information quickly. *A nominal percentage of them are aware that there is Wikipedia, in English. *A thin percentage knows that there is wikipedia (however thin they may be), in their native language too. If only they knew, they would even be eager to explore more and venture into enriching it further (as new editors). (Editing English Wikipedia is too complicated, and bureaucratic, let's admit it!. esp. if a topic is only of local interest and notability)
*Many among them are quite good in handling their native language. Some are good in reading and comprehending English. But thin is the population who can use English as a creative writing language. *Most people use a PC or Mobile device which is not necessarily equipped with their native language IME and/or rendering features. Most often, they can read a web page in their language but can't type in (for want of a suitable IME). But they can copy paste a string into a search box!
*Many articles have a rather better expanded version in a local wiki than EN, if the topic is more notable in their community. But sometimes, it can be the other way too.
*People gets turned off from a web site they have encountered for the first time, if it gives them results not that encouraging. They might never visit it at least for a long time to come. They have no time to waste.
Now, how this may be helped off:
1. I know a portal wikipedia.org or even en.wikipedia.org 2. I see a news item in a local language web page about a local entity. I want to know more facts about this entity. 3. I get to the portal and inject this string (or type in this string) into the search box. 4. There comes a few links: The first among them is an article in my language about the entity. Following are versions of the same article (if they exist) in other language wikis. 5. I directly choose, click and get to read what I wanted. I am happy and decides to visit this portal again as a regular routine.
What, possibly, mediawiki / wikipedia can do behind the walls: 1. Gets a search string. 2. Identify the language. a) Pick up the index for that language and process. b)Goto Wikidata links and find an equivalent link / article in other language projects for this string. pick index and seek. c)Harvest and show case the results (optimized in certain ranks say first article titles, then inline occurrences, then media etc.)
I can vouch positively that this itself will boost our counts to a great extend, at least from regions where WP is yet to make a significant impact.
From a casual user's perspective, I have still not understood why our
computing resources should get strained for this simple extra steps.
-Viswaprabha
On 12 March 2016 at 05:40, Carlos Mora lcharles.mora@gmail.com wrote:
Good work :D
2016-03-11 19:39 GMT-04:30 Samuel Klein meta.sj@gmail.com:
Lovely work.
On Mar 11, 2016 5:32 PM, "Dan Garry" dgarry@wikimedia.org wrote:
On 11 March 2016 at 10:52, ViswaPrabha (വിശ്വപ്രഭ) vp2007@gmail.com
wrote:
Failed my dream :(
Any string in any language in any wikipedia project. How far is my
dream?
I share your dream! :-)
Unfortunately, the dream is quite far away from reality. Querying every search index would put a big performance strain on the search servers.
Perhaps you could do this w two queries, one to a composite index that is only updated weekly.
Additionally, it would likely return you a bunch of really irrelevant
results,
Make this opt-in, add a different background color for results from the all-language index, & divide their search-relevance by a language-prominence factor...
+SJ _______________________________________________ Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 11 March 2016 at 16:09, Samuel Klein meta.sj@gmail.com wrote:
Perhaps you could do this w two queries, one to a composite index that is only updated weekly.
Indeed, there are mechanisms that can make cross-wiki searching more feasible. In fact, one mechanism we are in the very early stages of exploring is merging all the projects in a given language into a single index, so that one could search *all* projects in a language, rather than just a single project in a given language. I have no timeline here; as I said, we're in the very early stages, and of course we have other work on the go at the same time.
Additionally, it would likely return you a bunch of really irrelevant
results,
Make this opt-in, add a different background color for results from the all-language index, & divide their search-relevance by a language-prominence factor...
I plan to worry more about the user experience implications that I mentioned once we're a bit closer to solving the technical feasibility questions. As you've shown, these are definitely solvable problems, but I don't want to put the cart before the horse, as it were. :-)
Thanks, Dan
On Mar 11, 2016 19:32, "Dan Garry" dgarry@wikimedia.org wrote:
I plan to worry more about the user experience implications that I mentioned once we're a bit closer to solving the technical feasibility questions.
Fair enough! Great once more to see this update. It makes this a much more engaging page to set as a browser default on public machines.
Sj
On 11 March 2016 at 18:18, Deborah Tankersley dtankersley@wikimedia.org wrote:
We're interested in hearing your feedback or if you have any questions! (Note 2: My apologies for not getting this email out yesterday, but I had had issues with size limitations of my screenshots.)
On behalf of the very happy Wikipedia.org Portal Team,
Deb
The image thumbnail thing fails to filter our fair use images along with the usual lack of author and licensing information.
The image thumbnail thing fails to filter our fair use images along with the usual lack of author and licensing information.
Hi there - speaking to one thing I'm familiar with, with respect to image selection, we believe https://phabricator.wikimedia.org/T124225 should address fair use ("non-free") images, although page reparses will happen gradually (pages are cached for up to 30 days or so).
-Adam
On 11 March 2016 at 11:35, Adam Baso abaso@wikimedia.org wrote:
Hi there - speaking to one thing I'm familiar with, with respect to image selection, we believe https://phabricator.wikimedia.org/T124225 should address fair use ("non-free") images, although page reparses will happen gradually (pages are cached for up to 30 days or so).
Indeed. I manually triggered a reparse on a page which I knew had a non-free page image (by adding a space https://en.wikipedia.org/w/index.php?title=Mario&diff=prev&oldid=709579986 to a part of the page where it didn't affect the layout), and the page image was recalculated and is now a free image. Working as intended! :-)
In reply to Geni's query, it is important to point out, however, that the English Wikipedia guidelines on non-free content https://en.wikipedia.org/wiki/Wikipedia:Non-free_content includes a list of exemptions https://en.wikipedia.org/wiki/Wikipedia:Non-free_content#Exemptions which explicitly allows non-free content to be surfaced in search results without accompanying fair use rationales. Additionally, English Wikipedia policy is not applicable on a global page such as wikipedia.org. Therefore, the portal was never actually in violation of any policy. Regardless, as Adam noted, for other reasons where this policy *did* apply, T124225 https://phabricator.wikimedia.org/T124225 was enacted which prevents non-free images from appearing as thumbnails in search results.
Thanks, Dan
Thank you to the Discovery team -- it seems to me that your work has been largely overshadowed by political concerns in recent months (which may have been necessary, but not pleasant).
I'm delighted to see working and useful software emerge, in spite of the challenging environment that has existed around your work. I'm delighted to see your substantive engagement (e.g., Dan and Adam, above) with feedback about the implementation.
Kudos! -Pete
On Fri, Mar 11, 2016 at 2:05 PM, Dan Garry dgarry@wikimedia.org wrote:
On 11 March 2016 at 11:35, Adam Baso abaso@wikimedia.org wrote:
Hi there - speaking to one thing I'm familiar with, with respect to image selection, we believe https://phabricator.wikimedia.org/T124225 should address fair use ("non-free") images, although page reparses will happen gradually (pages are cached for up to 30 days or so).
Indeed. I manually triggered a reparse on a page which I knew had a non-free page image (by adding a space < https://en.wikipedia.org/w/index.php?title=Mario&diff=prev&oldid=709...
to a part of the page where it didn't affect the layout), and the page image was recalculated and is now a free image. Working as intended! :-)
In reply to Geni's query, it is important to point out, however, that the English Wikipedia guidelines on non-free content https://en.wikipedia.org/wiki/Wikipedia:Non-free_content includes a list of exemptions https://en.wikipedia.org/wiki/Wikipedia:Non-free_content#Exemptions which explicitly allows non-free content to be surfaced in search results without accompanying fair use rationales. Additionally, English Wikipedia policy is not applicable on a global page such as wikipedia.org. Therefore, the portal was never actually in violation of any policy. Regardless, as Adam noted, for other reasons where this policy *did* apply, T124225 https://phabricator.wikimedia.org/T124225 was enacted which prevents non-free images from appearing as thumbnails in search results.
Thanks, Dan
-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 11 March 2016 at 14:22, Pete Forsyth peteforsyth@gmail.com wrote:
Thank you to the Discovery team -- it seems to me that your work has been largely overshadowed by political concerns in recent months (which may have been necessary, but not pleasant).
I'm delighted to see working and useful software emerge, in spite of the challenging environment that has existed around your work. I'm delighted to see your substantive engagement (e.g., Dan and Adam, above) with feedback about the implementation.
Kudos! -Pete
Thanks, Pete. In this area, I want to direct the praise to Chris Koerner and Keegan Peterzell who have helped Discovery immensely with community engagement, community feedback, and announcements of our work.
Dan
wikimedia-l@lists.wikimedia.org