Portal stats were updated on Oct 19, 2017:

Portal translations were updated on Oct 19, 2017

As the errors have gone away over time, I'll close out this ticket; mostly because it's not happening on our MediaWiki site and/or within CirrusSearch.

Unfortunate, but I agree with you, @TJones, this ticket is now moved.

I've scheduled a meeting for Wednesday, Oct 25. If you'd like to attend and you don't have a calendar invite, please let me know.

This seems like a good topic for a blog post, with a title along the lines of "So -happy to meet you."

Sounds like it'd be a great blog post, @TJones! :)

After we switch to node.js, we won't have this issue any more. We'll check again after the conversion as detailed here: T174103

This error is still happening, but the amount of events is less than 100 in the last 30 days; not super urgent.

We should still take a look at this - as it is nice to know when things fail.

Moving this to later, as we just don't have time for this right now and Analytics is still working on their portion of this type of work.

Once we're done with GC on WDQS, let's see if this is still needed and/or still effecting latency.

Hey @brion - is there still anything to be done on this task? If nothing, I'd like to close it or at least take off our board. Thanks!

Let's see if we can look at this issue, this quarter, @Jdrewniak, when you have spare time from the Portal automation tasks.

Taking off the Discovery-Search tag, as there isn't much we can do, but we'll continue to monitor using the Discovery tag.

We typically only make sure that we're compatible with Core and nothing else, but we'll need to look at this and edit the wiki page as well.

Marking as stalled...not sure if any movement has been occurring on this.

I'll set up a meeting to go over the concept and details of this ticket and functionality.

Yikes!

Thanks, @dcausse, I've moved it to up next.

Awesome! :)

In T178321#3692716, @Evad37 wrote:

en.Wikivoyage's {{maplink}} is a different template to en.Wikipedia's {{maplink}}. As well as having different parameters, it uses voy:Module:Map to create the <maplink> tag rather than creating it directly, like enwiki's version.

Moving to the sprint board, as we have a couple other related issues that this issue might be able to piggy-back onto as community work is being done: T178370 and T178321

Sounds like a plan — let it run for a bit with increased logging and see if we see more of these errors. Otherwise, we can go ahead and close this out.

Does this block anything or is it just annoying?

Ah...I see the conversation now (where this ticket came from): https://en.wikipedia.org/w/index.php?title=Template_talk:Maplink&oldid=805751717

Hey @Gareth - can you give us more details and specific links on how/where this is happening?

Yay! :)

@Pnorman is this something you can take a look at?

Let's scheduled a meeting to go over responsibilities for doing this work.

We could add in an exclusion filter, but we're not sure that is the best way to do this. Maybe the Readers-Community-Engagement can help determine what to do here. Maybe @CKoerner_WMF can help with the community conversation.

This isn't on our mediawiki site and most likely not related to CirrusSearch.

Moving to later, as we won't be able to get to this anytime soon. but we'll need it if we want to do new things with the translation server.

@mpopov - is this still needed?

We'll finish this after the rolling restart of servers happen...a few things yet to be done (security patch, etc).

We might want to do this test in French, as we have a few people that know that language to be able to help with translations and PII review.

This is still blocked on a merge...waiting.

We need someone with admin rights on this wiki in order to fix this. Moving this to the backlog until someone from rowiki can help — @AdiJapan and / or @XXN ?

This is fairly tricky and no obvious solution right now. We might want to wait for the next version of Logstash.

We'll get start this next week on Monday.

This will happen next week, after the test is completed.

This test can be run at the same time as other tests, as long as we get bucketing separated.

I've been testing this out...and I'm not sure why some work on Wikipedia and some work on Wikivoyage, but not both.

Woohoo, thanks @Gehel and @MaxSem -- lets get this into production!

Hi @Amire80 and @Nikerabbit - we're running into a few translation / context issues with some of the testing we'd like to do on wiki's other than English.

With today's merging of the code for adding namespaces to Bengali Wikisource, I think we've done everything that the community has wanted us to do for this ticket and moving it to the done column.

In T170099#3683458, @TJones wrote:

In T170099#3436560, @debt wrote:

Let's take a look at this in ElasticSearch parser and see if we can change the UI display of using negative symbol before a word - to make the UI display nothing if we don't have any results.

I think this is a case where we need more documentation. Maybe we should look instances of potentially confusing power-user syntax and catch them and give documentation hints. So, if you search for -happy then you get the standard results but also a message that says "Did you mean to search for articles without happy in them? If not, try searching for insource:/-happy/." (Another obvious one is a question mark: "Use \? as a single-character wildcard".)

@Ramsey-WMF, @Abit, and @Capt_Swing - can you take a look at the findings in this ticket and let us know if this satisfies the concerns or would you need / want more clarification?

Looks nice @chelsyx -- here's my notes:

In T176428#3684625, @EBernhardson wrote:

• The wording for privacy statement / opt out were just too wide to fit in the notification.

Yup, this is fine

• The do not show same article to same user, ever, has the requirement that it only works for a logged in user.... With the 2 day timeout that should also take more than a year.

This is good, and we shouldn't add in a bunch of JS that would be slowing down every page for anon users.

• Anonymous opt out is also on a best effort basis, the information is stored in local storage same as the timeout for how long until we can show a survey again. Logged in users have their opt out tracked on the backend which has stronger guarantees.

Sounds good!

One thing i'm indecisive on, this new version now requires logged in and anonymous users to make an api request before the survey is shown to them. That could be a reasonably large number of new api requests. I don't think it's problematic, but if others do i could rework things so only logged in users have to make the api request.

Could we run a test on this for a day or two and see what the servers do? If we think it'll be an issue, let's only do the api request for logged in users.

Hello @Base - I've setup a meeting tomorrow to talk with our Legal team about this issue. I hope we can have a response to this issue soon.

@Yurik - could you expand on how this could be fixed with 'a few lines of code'?

@Sabas88, there has been no movement on this issue, unfortunately.

It looks like @dcausse will be able to do the re-indexing after next week's train deployment and because we really don't want to start the re-indexing on a Friday, the earliest we'd be able to do it is Monday, Oct 23rd.

Very nicely done, @TJones!

This is actually deployed in production now: http://discovery.wmflabs.org/metrics/#mobile_events (not only on beta)