Hello!
Quick status (mainly for Tomasz). We took some time with Stas to go
over what needs to be done on WDQS. Blazegraph seems robust enough and
standard enough. I'll start playing around with it...
The list of open points that I should address seems fairly thin. No
upgrade planned in the short term, no specific maintenance, ... I can
try to take care of incidents on the service, but it does not seems
that there are many.
In short: I should not have any problem starting to work on WDQS, but
I'm not sure it will free all that much time from Stas...
We'll see...
MrG
--
Guillaume Lederrey
Operations Engineer, Discovery
Wikimedia Foundation
Hi Sam,
We're glad you're using the Portal page more than usual and we hope that
with upcoming future enhancements, you'll continue to enjoy it!
For your first question - we are currently focusing on the wikipedia.org
portal page at this time. We have no immediate plans to update the
individual wiki's with this code but that doesn't mean that anyone in the
community can't use our code to update another wiki to use the meta data
and images as we did, in the search results.
For your second question, we actually have a ticket
<https://phabricator.wikimedia.org/T129627> open to look for input exactly
like that. When a user types in a few words that are not in the language
that has been previously selected, we're hoping to be able to switch to
that "new" language on the fly. I agree that it'll be a very neat feature
for us to have on the portal!
Thanks for your input!
Cheers,
Deb
--
Deb Tankersley
Product Manager, Discovery
Wikimedia Foundation
On Tue, Mar 15, 2016 at 4:27 PM, Sam Klein <sjklein(a)hcs.harvard.edu> wrote:
> I'm using the portal much more these days! Two thoughts, a few days in:
>
> = Is there a way to turn on thumbnailing on the individual language wikis
> too?
>
> = Auto-suggesting language based on charset would be nice. when searching
> in multiple languages I always forget once to switch to the target language
> and end up getting search results for kanji on he.wp or for hebrew on ja.wp
>
> Thanks, SJ
>
> On Tue, Mar 15, 2016 at 4:25 AM, Michael Jahn <michael.jahn(a)wikimedia.de>
> wrote:
>
> > I've played around a bit. Feels very cool!
> > Michael
> >
> > 2016-03-11 3:27 GMT+01:00 Deborah Tankersley <dtankersley(a)wikimedia.org
> >:
> >
> > > 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 (see attached image).
> > >
> > > 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: 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 attached a screenshot
> of
> > > one of the ways we test our code, visually.
> > >
> > > We're interested in hearing your feedback or if you have any questions!
> > >
> > > 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(a)lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> >
> >
> >
> > --
> > Leiter Kommunikation
> > Head of Communications
> >
> > Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> > Tel. (030) 219 158 260
> >
> > http://wikimedia.de <http://www.wikimedia.de>
> >
> > Stellen Sie sich eine Welt vor, in der jeder Mensch freien Zugang zu der
> > Gesamtheit des Wissens der Menschheit hat. Helfen Sie uns dabei!
> >
> > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> > Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter
> > der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> > Körperschaften I Berlin, Steuernummer 27/029/42207.
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > New messages to: Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
>
>
>
> --
> Samuel Klein @metasj w:user:sj +1 617 529 4266
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
In today's departmental weekly checkin, I asked if it might be worth
spending more effort on documentation (e.g. TextCat). That brief discussion
generated the following notes (which are already on wiki[1]):
- Should we have a semi-formal policy about the importance of
documentation?
- Concerns about over-documenting (e.g. not agile)
- Move this conversation to email
- Dan is willing to prioritize phab tasks to write docs on specific
topics
- Chris can alert us if he is answering the same question multiple times
(feature-level)
- Multiple audiences (onboarding new staff, end-users on Wikimedia
sites, end users on third party sites, other devs)
For now, it seems that our immediate next steps could be to create a phab
task whenever you notice (or are informed of) a shortcoming with our
documentation. That task can be prioritized by whoever manages the workflow
of the person/people who would do the documentation.
If we end up in situations where documentation work ends up as eternal low
priority, of if using phab proves unproductive, we can adapt and adjust.
Feel free to continue the discussion here, if there are additional
questions, concerns, or suggestions.
[1]
https://www.mediawiki.org/wiki/Wikimedia_Discovery/Checkin_meeting_minutes/…
Kevin Smith
Agile Coach, Wikimedia Foundation
Yuri,
Great news! I'm glad to see the progress and look forward to helping work
with the Wikivoyage and other map-loving communities.
Not to be a pain, but shouldn't the IRC channel be #wikimedia-interactive ?
:)
--
Yours,
Chris Koerner
Community Liaison - Discovery
Wikimedia Foundation
Hi All,
The portal team has had some discussions about what browsers we support on
the wikipedia.org portal over the past week. Currently, our browser support
is all over the map (in regards to IE anyway, almost literally any other
browser release in the past 10 years works fine).
- The typeahead suggestions work on IE6+ (but very slowly)
- The baseline event logging works on IE6+
- A/B test event logging works on IE8+ (requires localStorage)
- The JS language-picker works on IE9+ (requires CSS capabilities)
- The upcoming A/B test (localized top-links) work on IE8+ (hasn't been
test on lower versions)
I think we should standardize on browser support. Currently our
browser-usage from our dashboard
<http://discovery.wmflabs.org/portal/#browser_breakdown> shows
IE7 at ~ 1%,
IE8 at ~1.5%
IE9 at ~ 1%
and IE6 isn't even on the map.
Mediawiki, and by extension wikipedia.org, *has* browser compatibility
standards, published here:
https://www.mediawiki.org/wiki/Compatibility
I think since the wikipedia portal is a gateway to the rest of wikipedia,
it makes sense to follow the same guidelines as the rest of wikipedia. This
would mean dropping JS support for IE8 and lower. We would still provide
'basic' support to IE8 and below, meaning the non-js version of the portal
would still work for these browsers. This change would slightly change our
dashboard metrics, but it would certainly speed-up our development time,
allowing us to do more with our limited resources.
Any objections or concerns with this approach?
-Jan
Hello!
I'm trying to put some order into what I'm doing / want to do. If you
have a few minutes to have a look (especially Dan) and let me know if
I'm missing something big or if you have some idea on the priorities
of all that...
T124444 - Look into encrypting Elasticsearch traffic (in progress,
*should* be done for codfw switchover)
T128786 - improve robustness of es-tool (limitation were seen during
elasticsearch 1.7.5 upgrade)
T128000 - Refresh elastic10{01..16}.eqiad.wmnet servers (waiting for
the hardware)
T128616 - Remove hostname from elasticsearch log messages (minor point
but shoudl improve visibility on logs)
T128433 - Estimate hardware requirements for relevance lab
elasticsearch servers (I'm mainly following, Erik is the brain on this
one)
T129254 - Put elasticsearch upgrade scripts under version control
(small task, but should be done)
T129256 - Implement proper orchestration mechanics for elasticsearch
upgrade (we should at least investigate and see if we want to invest
in better orchestration or not)
I have a few more things in my head that are not clear enough yet to
be written down.
Feedback welcomed!
MrG
The quest to bring maps to Wikipedia continues:
* Kartographer has launched for WikiVoyage
* Julien Girault will help maps with his UI expertise
* Talk to us at the FreeNode IRC channel #wikipedia-interactive
https://www.mediawiki.org/wiki/Help:Kartographer
Last week we enabled Kartographer extension for Wikivoyage sites, allowing
users to add maps to wiki pages without any additional wmflabs and
JavaScript tricks. Now you can simply add a <mapframe> or <maplink> to a
wiki page, or even use the Visual Editor to insert a map. Additionally, you
can:
* add markers and polygons visually
* edit geojson and see how it changes the map on each keystroke
* add auto-numbered markers (either numbers or letters), and have multiple
counters
* have multiple "groups" of markers/polygons and showing them on the same
map or on separate maps (e.g. all food and all drink maps and one combined
map)
* markers can be of any color, 3 sizes, and contain many different icons
* markers and polygons can be clicked and will show popups with wiki text
and images
* very fast full screen popup map
Feedback: https://www.mediawiki.org/wiki/Talk:Maps
Bugs & TODOs: https://phabricator.wikimedia.org/tag/kartographer/
All maps-related tasks: https://phabricator.wikimedia.org/tag/maps/
== What's next? ==
There will be plenty of cleanup and polishing work to make Kartographer
work seamlessly. We will need to address the missing functionality reported
to us by the community, and help migrate existing wmflabs-based maps to the
new platform. Lastly, VE editing will need some more work to become
indispensable.
Yet, our site is still set on the bigger target - maps for all of
Wikipedia. For that we are waiting for more hardware, plus we will need to
improve our static maps service to be able to handle wiki-load.
Hardware task: https://phabricator.wikimedia.org/T125126
Thank you Max Semenik, Ed Sanders, Alex Kosiaris, Brandon Black, Chris
Koerner, Chris Steipp, Tomasz Finc, and Wes Moran for making this possible.
Hi all,
Just a quick announcement that Julien will now be supporting Max and Yuri
on the Maps team. I'm looking forward to all the great things the Maps team
will build now with the additional help of Julien!
Jan and Julien will still be reviewing each others code for the next little
while.
Quick announcement over :)
Moiz
Food for thought:
http://www.seattletimes.com/business/smartphone-voices-not-always-helpful-i…
I wonder if Wikipedia search should have some enhanced capability to help
people who perform searches like these. There may be ethical and legal
limits to what Wikipedia should provide in the way of "medical advice", but
I think if our search tool gets queries like the ones mentioned in that
article, Wikipedia Search might suggest to people that they contact their
local emergency services rather than try to do self-help via Wikipedia.
Pine