[00:38:48] SMalyshev: the whole approach of firing off multiple requests and then discarding the responses when the search term does not match seems rather weird [00:39:00] why not just keep track of the request properly? [00:39:24] I realize that's not a one-line fix either... [01:11:07] legoktm: SMalyshev: I would assume unicodeJS might help with a polyfill for that, and VisualEditor/Parsoid may or may not already be doing that [01:11:23] https://github.com/wikimedia/unicodejs [02:14:11] tgr: I have no idea, I didn't write that code [02:14:40] Krinkle: thanks, I will take a look [02:15:35] tgr: I am just trying to fix a bug in it :) But you are welcome to comment on the patch so that other reviewers (who did write most of it :) will see [02:16:25] Krinkle: don't see any mention of normalization in unicodejs [02:19:13] SMalyshev: Yeah, me neither. The underlying logic is there, though. [02:19:19] SMalyshev: But VisualEditor does normalise them afaik. [02:19:28] Not sure exactly how or where. [02:19:43] edsanders in #wikimedia-editing would know [06:29:36] bd808: https://github.com/wikimedia/WikimediaDebug/issues/10 [06:54:01] bd808: the mediawiki-errors logstash dashboard gives me "Could not locate that index-pattern-field (id: backtrace.file.raw)" [06:54:25] a few hours ago it was working, and that field has been around forever - any idea what could have happened? [07:05:00] (on second thought, we had backtrace.file for a long time, not so sure about .raw) [07:09:12] seems like this was something from the exception-json channel? and the trending backtrace widget is configured to use it but now nothing in the index has that field anymore so it is complaining? [07:09:22] most of logstash is still black magic to me [07:21:23] ...apparently the .raw part is some elasticsearch magic and not having it there makes the whole dashboard blow up [07:21:43] anyway, replaced with exception.file.raw and that seems to have done the trick [15:54:37] legoktm: "fun". since we are using the exact same source for both that sounds like an upstream bug with FF [17:40:20] If any of the "old timers" who hang in this channel have thoughts about T179461, we'd like to hear them. [17:40:20] T179461: Use the term "developer account" for Wikimedia LDAP accounts - https://phabricator.wikimedia.org/T179461 [17:55:29] bd808: "technical contributor account" probably would be the most accurate, but as you noted doesn't abbreviate well. [17:55:42] yeah :/ [17:56:11] at best people would call it a "contributor account" and that is very confusing with SUL accounts I think [17:56:42] Developer Unified Login, unless you're a designer in which case it's Designer Unified Login [17:56:49] heh [17:56:58] or Debugger Unified Login [17:57:10] "Wikimedia infrastructure" [17:57:11] DULL accounts [17:58:17] I've had a lot of staff make comments about "LDAP account" being confusing because that's what OIT docs call their accounts [17:58:31] "a lot" == >1 [17:59:17] * anomie tries to figure out if ">1" could be an emoji like "<3" [18:00:29] its an alligator defending the numeral one [18:00:43] But you have to turn it on its side! [18:00:56] the alligator always eats the bigger numbers :) [18:01:43] Commented on the ticket [18:01:54] The best I can come up with after rotating it 90° counterclockwise is either a camera or a gun on a tripod. [18:02:16] a telescope! [18:03:16] Yay bikesheds [18:03:52] Demon Unified Login [18:07:55] Good thing demon doesn't ping me anymore :p [18:09:03] 😂 Unified Login* my bad [18:11:10] lol [18:11:55] Luckily that's not my IRC nick so I don't get pinged here either for that ;-) [20:13:01] ruh roh: [{exception_id}] {exception_url} BadMethodCallException from line 119 of /srv/mediawiki/php-1.31.0-wmf.6/extensions/Echo/includes/UnreadWikis.php: Call to a member function getTimestamp() on a non-object (boolean)