[00:03:45] matt_flaschen, my attempted quickfix to the human readable names is U.G.L.Y. [00:04:05] I am starting to think we should just go ahead and do the full 900 messages and be done with it [00:06:37] mooeypoo, that's the right solution, I think, and the sooner we kick it off for translation the better. [00:06:56] mooeypoo, only question is whether to do quick fix in addition afterwards, while we wait for translation. [00:07:12] mooeypoo, I haven't read that thread yet, are people disagreeing with the translate everything approach? [00:07:25] Well, while we wait for solutions, the content will fallback on English, that's not a bad thing [00:07:42] A little? I was worried that it turns into a bit of a philosophical what's-better-long-term approach [00:07:59] Right [00:08:15] The autonym idea (I did see that post) is clearly not enough, since it only handles same-project (both Wikipedia). [00:08:19] but yeah, I am starting to think I'm wasting my time here... plus, the fix is UGLY -- we add exceptions for commonswiki and wikidatawiki and metawiki and the code doesn't supposed to have wmf-projects-specifics in it [00:08:38] Even if it was enough to display, it's A MESS to implement, as I am seeing now. [00:09:04] I'll put this fix as a [experimental wip] or something, just so we have it out there (and I can get some assistance on some of the crappier stuff in there) but it really sucks [00:11:50] (03PS1) 10Mooeypoo: [EXPERIMENTAL] [WIP] Hack a human-readable temporary solution for wiki names [extensions/Echo] - 10https://gerrit.wikimedia.org/r/265876 (https://phabricator.wikimedia.org/T121936) [00:11:53] I am reluctantly sharing this code [00:12:13] matt_flaschen, also, this specifically isn't working right now for me because of the vagrant wiki names issue [00:12:22] but it should (eh...) work in production. [00:12:30] I would advise against it, though. It is crap. [00:13:56] We can probably make it marginally better by using more backend tools I might be unfamiliar with, but the method *itself* is crappy. Fallback on MediawikiMessages and then on proj + lang and then on dbname when none of those is consistent, even inside the WMF messages! [00:14:18] "wikibase-otherprojects-meta" doesn't help when the dbname is "metawiki", goddamnit. [00:14:20] (03CR) 10jenkins-bot: [V: 04-1] [EXPERIMENTAL] [WIP] Hack a human-readable temporary solution for wiki names [extensions/Echo] - 10https://gerrit.wikimedia.org/r/265876 (https://phabricator.wikimedia.org/T121936) (owner: 10Mooeypoo) [00:14:34] WikimediaMessages, but yeah. [00:14:45] Yeah, WikimediaMessages [00:15:01] mooeypoo, Vagrant has the same thing of being inconsistent in using wiki name vs. db name. [00:15:12] mooeypoo, anyway, I'm almost done my hack to support your hack. [00:15:17] yeah I saw that too in your comments in echo.pp [00:15:19] :D [00:15:58] matt_flaschen, I'm thinking about working on a script (external) that produces a list of key: msg lines based on https://noc.wikimedia.org/conf/highlight.php?file=all.dblist [00:16:03] mooeypoo, the reason *this* is a hack is https://phabricator.wikimedia.org/T124487 , which is the same thing I mentioned in that comment. [00:16:26] ha [00:16:34] that explains commonswiki and wikidatawiki [00:16:43] and frwiktivoyagewiki [00:16:45] ... [00:16:57] mooeypoo, commonswiki is the same in prod, not sure about wikidata. [00:17:31] Yeah, but not the wikivoyage, that's my workaround to Vagrant weirdness. [00:17:42] wikidata is wikidatawiki in prod, though. [00:17:45] hm yeah, i think you're right about wikidatawiki too [00:18:00] yeah, but still ,those are hard with the WikimediaMessages [00:18:27] my initial plan of having "key-str-" + dbname is not working, because the key is not the same as the dbname [00:18:34] which is one thing that I want to fix in the new list [00:20:31] (03PS2) 10Mooeypoo: [EXPERIMENTAL] [WIP] Hack a human-readable temporary solution for wiki names [extensions/Echo] - 10https://gerrit.wikimedia.org/r/265876 (https://phabricator.wikimedia.org/T121936) [00:22:23] mooeypoo, hmm? [00:22:47] I thought it was just going to be something site 'site-description-dbname' where 'site-description-' would be fixed. [00:22:59] Not quite [00:23:06] WikimediaMessages' keys are these: [00:23:07] (03CR) 10jenkins-bot: [V: 04-1] [EXPERIMENTAL] [WIP] Hack a human-readable temporary solution for wiki names [extensions/Echo] - 10https://gerrit.wikimedia.org/r/265876 (https://phabricator.wikimedia.org/T121936) (owner: 10Mooeypoo) [00:23:25] "wikibase-otherprojects-meta": "Meta-Wiki", [00:23:35] "wikibase-otherprojects-wikidata": "Wikidata", [00:23:40] (those aren't dbnames) [00:23:46] mooeypoo, oh, you mean part of the fallback, not the 900 plan. [00:23:53] "wikibase-otherprojects-commons": "Wikimedia Commons", [00:24:01] yeah no the *current* situation is that they're not dbnames [00:24:06] the 900 plan should be consistent [00:24:26] as in, use the dbname as the suffix of those keys, not some conveniently-human but not convenient-to-code key [00:25:00] mooeypoo, yeah none of those are site names. They're all either families or multilingual projects. [00:25:30] but at least "wikipedia" and such are given by the "siteFromDB" method [00:25:46] commons isn't. wikidatawiki isn't quite. metawiki isn't either. [00:25:51] Right, you can use the famlies from siteFromDB. [00:26:06] Yeah, I don't know a way to avoid hard-coding a list of the mulitilingual projects. [00:26:20] But for those it's always just 'remove wiki'. [00:26:20] It's just so inconsistent throughout, that whatever we do we'll have to have very hacky hard-coded stuff [00:26:23] unless we do the 900 list [00:26:32] mooeypoo, it's really not if you consider the original purpose of wikibase-otherprojects. [00:26:43] What was the original purpose? [00:26:57] It is to refer to a related sister project for the current topic. [00:27:17] Why wouldn't we want to always go by the same "key" of the wiki or project, though? [00:27:23] why is it sometimes commons and sometimes commonswiki [00:27:30] sometimes meta and sometimes metawiki, etc. [00:27:41] (I'm out for a bit, bbl/tomorrow. Have a good weekend :) [00:27:48] quiddity, good weekend! [00:28:18] mooeypoo, yeah, for the multilingual wikis they could have done that. [00:28:29] Yeah [00:28:42] But then it would look inconsistent with the family ones even if it wasn't really. [00:28:47] anyways, I hope this at least serves that ticket as a "we really shouldn't do this" point [00:29:34] But only for some -- and, imho, minor -- operations. Whatever we do, even if we kept the 'commonswiki' so it's consistent, stick to that as the key to commons, always [00:29:49] it's less the naming that bugs me, it's more that it's inconsistent throughout different pieces of the code [00:29:58] 3Collaboration-Team-Current, 10MediaWiki-Revision-deletion, 7Easy, 5MW-1.27-release-notes, and 3 others: Button option to 'choose all/none/reverse' for revdel - https://phabricator.wikimedia.org/T92230#1958379 (10PeterBowman) It turns out that the change-tags buttons and checkboxes are hidden through CSS o... [00:31:23] Yeah, I'm just saying it's probably because for wikibase-otherprojects most of them refer to families, and they probably just made the other ones look the same. [00:37:51] mooeypoo, I'll put up the Vagrant one as a EXPERIMENTAL as well, and we can merge it if we merge your fallback inception one. [00:37:59] 3Collaboration-Team-Current, 10Notifications, 7I18n, 5Patch-For-Review: Display human-readable wiki names for cross-wiki notifications - https://phabricator.wikimedia.org/T121936#1958450 (10Mooeypoo) >>! In T121936#1957502, @Nemo_bis wrote: > The task needs requirements to be clarified. For instance, what'... [00:38:40] matt_flaschen, I dislike my fix so much.. :\ not in the least because it hard codes WMF projects in it [00:43:38] (03CR) 10Alex Monk: [C: 04-2] "Yeah, per commit message this is indeed a bad idea... This can't go in with something wmf-production-cluster-specific like $exception_proj" [extensions/Echo] - 10https://gerrit.wikimedia.org/r/265876 (https://phabricator.wikimedia.org/T121936) (owner: 10Mooeypoo) [00:43:54] mooeypoo, yeah, probably not as bad as https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FGettingStarted.git/master/GettingStarted.php#L387 (What about the other projects ending in wiki? Oh, it's not causing problems there), but still wouldn't want that hard-coding permanently. [00:45:11] ha [00:45:28] yeah [00:45:29] wtf [00:45:43] that should never have been allowed [00:45:57] Yeah way too wmf-production-specific [00:46:51] found the commit that did it back in april/may 2014 [00:46:55] revertign [00:47:47] ... wait, uhm, probably needs a fix first? alternative? [00:48:13] I mean, if it was in there since 2014, we can wait to see if we can find an alternative way of doing it before we break something in production? [00:48:33] it was added in april 2014 and hasn't been removed, I think it's safe to say it's been there too long [00:49:20] I think it's safer to say that it might be needed, therefore we should open a task (mark it as urgent if you want) and make sure what you revert doesn't hurt anything in that for production [00:49:31] ugly or not (and I agree it shouldn't be there) -- it's there for *some* reason [00:49:58] Krenair, I remember the problem (siteFromDB returns the wrong result), let me see if I can remember if that code is actually needed. It might have been due to the possibility we would deploy on Commons. [00:52:43] Krenair, yeah, it is not deployed on Commons, there are no plans to, and after the revert there is a warning about it. I'll +2 revert. [00:52:50] Krenair, as far as [00:53:27] "that should never have been allowed" IIRC we were considering deploying to Commons, so better solutions would have been welcome 21 months ago had we done that. :) [00:54:30] If I had seen it at the time, it would have been -2'd regardless of whether there was an alternative. [00:55:22] Of course, there actually is an alternative. [00:56:31] These types of MessageCacheGet hacks go in the WikimediaMessages extension. [00:58:00] Krenair, registering the hook unconditionally would mean there would be overhead for every single message access. [00:58:59] yeah, that's how WikimediaMessages works [00:59:09] you'd just modify the existing hook [01:02:29] normal extensions (i.e. not the Wikimedia* stuff) should never be doing site-specific stuff like this [01:04:16] Krenair, the fact WikimediaMessagesHooks::onMessageCacheGet is just a grab bag of different extensions is also hacky. Maybe the best solution, but still hacky. [01:14:09] * ebernhardson always felt wikimedia messages overrides felt like a complete hack [01:15:37] Krenair, the VE extension has a whole citation categorization system designed for Wikipedia. This is narrowly hidden by keeping the category i18n in the extension, but the actual definition of cite news -> news outside. So I'm not buying the moral absolutism. [01:16:37] ebernhardson, it used to be easier. (Assuming you didn't need special handling), you could just define later translations (e.g. in your wiki farms i18n PHP file) that overrode earlier ones. No need for a hook. [01:16:38] Simpler times. [01:17:00] alex@alex-laptop:~/Development/MediaWiki/extensions/VisualEditor (T123457)$ grep -i wikipedia modules/ve-mw/i18n/en.json [01:17:00] alex@alex-laptop:~/Development/MediaWiki/extensions/VisualEditor (T123457)$ [01:17:21] the fact that the citation system was designed after the existing wikipedia system is fine [01:17:44] wikipedia having customised messages is fine [01:17:51] checking specifically whether you're being run by wikipedia is not [01:19:49] your code should never care which site it's being run by, just get told how to behave by the site's config [01:23:10] Krenair, I'm going to port it to WikimediaMessages. That is not a good use of my time, but neither is arguing about this. [01:24:07] indeed, it should have been done properly in the first place [01:26:06] Krenair, and good catch for catching the mistake, but with due respect, the right thing to do is to write a task -- accompanied by an annoyed email, if you insist -- and insist it be prioritized high and dealt with. Not to jump and break the table with the revert hammer, after 21 months, without first checking if it will have any sort of reprecussions over code that lives in production. [01:27:21] I don't see a need to write a task for this one since I can make the revert myself [01:27:34] what you are failing to do is make sure anything actually still works [01:27:36] if I needed other people to do it, I might've made a task. wouldn't bother people with email [01:27:47] you are just throwing arround 'revert things and let other people deal with the fallout' which is unacceptable [01:28:05] Krenair, so youd revert something without letting anyone know, potentially having it break something in production? [01:28:12] it's not like the revert has been merged yet [01:28:42] Tasks are not just meant to be done by other people -- phabricator is where we collaborate on decisionmaking and code decisions [01:28:49] broken stuff up for review is fine, problems happen when it reaches master [01:29:15] Yes, and this problem was in master for 21 months. Not a single person, code bit or production server would've suffered had it waited a week more. [01:29:31] not even. [01:30:17] It does not need to go in Phabricator [01:30:22] No extra decision making is necessary [01:30:30] That change should never have been merged [01:30:32] Because you decided...? I'm.. confused. [01:30:41] It should go [01:30:46] Krenair, fine, but it was merged, and reverting it may have produced issues. [01:31:13] No one is arguing that you're wrong to say it shoudln't be there. You should not be the AbsoluteAuthorityOfAll and revert what you want without letting people know about it, at the very least. [01:31:16] yeah if someone merged the revert without reviewing the situation and looking for issues [01:31:20] And giving them TIME to fix it. [01:31:35] They'd be at fault as well. [01:31:43] Anyways [01:32:04] There's a reason why we're a collaborative movement and not a one-person-show. [01:32:13] I will put any revert commit up for review that I like [01:32:19] Just keep in mind that people may want to be aware -- and search for proper solution -- to fix their mistake or issues. [01:32:28] I am not demanding the authority to then go and merge it in any case [01:32:59] "broken stuff up for review is fine, problems happen when it reaches master" [01:33:09] Then why didn't you say in the commit message, "Don't let this reach master"? [01:33:30] It's not necessarily broken? [01:33:35] It might be. [01:33:48] yeah, so might everything else up for review [01:33:51] It doesn't matter whether they see a 503. It's still a regression. [01:33:58] You are risking breaking something on a WHIM. On your own conviction that this shouldn't have been there in the first place, and you dislike it there, so boom -- gone. [01:33:59] I'm not going to put "Don't let this reach master" on every single commit I ever make [01:34:16] c'mon. We're supposed to be collaborating. Collaborate. [01:34:27] Krenair, you should be either putting Depends-On or -2, or at least a note if it's not safe to review and merge in isolation. [01:34:36] Nothing I am doing is against collaboration [01:34:49] ... okay, this is going nowhere. [01:34:51] matt_flaschen, nope, not unless I think it's broken [01:34:55] mooeypoo, indeed [01:35:16] I have to leave my coworking place. I am going to get dinner then go home and put up the WikimediaMessages patch. Not interested in discussing further and don't think it's productive. [01:36:06] I wish I could say we can agree to disagree, but I doubt we can on this case. This isn't collaborating. [01:36:17] And I need to go too. Lucky we solved today's issue without having to hammer-revert. [01:36:31] I'm not sure why you think it's not collaborative [01:36:51] I'm just saying the fact that I put a revert commit up for review is perfectly fine [01:37:32] Because it's you making a snap decision (an unnecessary one -- no one would've been hurt WAITING a little) *regardless* of people who actually know the potential issues in reverting the code [01:37:38] that's not collaborating, that's you thinking you know better. [01:37:56] a snap decision is fine for putting stuff like this up for review [01:38:06] anyone can put stuff up for review [01:38:13] pre-merge review is supposed to catch issues [01:38:31] The minimum is to let someone know. The revert would've appeared in the queue, someone would've approved it, because you're right, it looks like it does not need to be there -- all the while the extension maintainers and the people responsible will have zero idea about it. [01:38:33] If I had immediately merged the commit, yes, you'd be right. But I didn't and never planned to [01:38:36] As an aside, not everyone who should be reviewing this is necessarily in gerrit, which is why just doing stuff on gerrit isn'thelpful. [01:38:45] Phabricator is better, then. [01:39:05] Ok, I need to go... have a good weekend, everyone, I must run (late already,meh) [01:39:18] mooeypoo, I did tell people in this channel I was reverting the commit [01:39:39] extension maintainers watch projects to catch stuff like this [01:39:43] yes, implying "DROP EVERYTHING YOU'RE DOING krenair wants to revert right this minute, without checking if it's affecting anything or not" [01:39:49] lucky we had matt who knew the codebase best [01:39:58] mooeypoo, I never implied that and I don't want anyone to do that [01:40:08] phabricator would've been better -- would've worked best, and been actually given us time to check if something can be fixed before reverting [01:40:10] I don't know why you think I would [01:40:20] Because yoiu said you're reverting right now [01:40:21] Deskana, who else should be reviewing it? [01:40:37] ... and if we ignore that, we're risking someone else, unfamiliar with whether it's good revert or not, will have merged it. [01:40:37] mooeypoo, yeah, and I pressed the revert commit button and it put a revert commit up for review for me... [01:40:55] that's basically harmless [01:40:59] without commenting that it should wait for anyone... which would've meant it has a lot of potential to be merged [01:41:15] just because I put a commit up for review doesn't mean I want you to immediately merge it without discussing and check it [01:41:23] Anyways, really, I must run :P I keep answerinb but I am really actually late... [01:41:38] I don't understand your objection to the revert commit [01:41:42] I'l have to cut the discussion here. Have a good weekend! If you want, we can continue discussing later. [01:41:48] sure [01:42:12] hope your weekend is good too [01:43:21] it's actually somewhat worrying to me that people might just come along and merge my changes without properly reviewing them [01:43:48] I depend on the code review system a lot to find any mistakes that I mised [01:43:54] that's why it's there [01:54:57] maybe we should disable people being able to upload changes without being whitelisted [01:57:55] hi Deskana [02:08:38] Krenair: Hey! [02:08:58] so, Phabricator? [02:10:33] Oh, yes. [02:11:26] Phabricator is our issue tracking system. "Extension X messages are incorrect and should be fixed" is an issue which should be tracked. [02:11:48] That way you don't end up having arguments about the actual task on gerrit, which is supposed to just be for review of the relevant code. [02:12:01] We don't require all issues to go into the tracker, they can go straight to gerrit commits, and often do. [02:12:26] I know some people prefer it but I don't always see the need. [02:12:43] If they're purely technical changes, it can be okay to just put it in gerrit. I'd say almost anything that actually affects user should have a task. [02:13:03] well this case is purely about technical changes [02:13:12] There are varying schools of thought on that, yes. [02:13:43] I wouldn't know. :-) [02:14:02] Anyway, that's my bit said. [02:14:21] seems like a bit of a tangent to the debate, but okay [02:15:29] Krenair: Well, Moriel was mentioning it should be in Phab, and I was agreeing with her. I don't agree that that's a tangent, but also have zero interest in arguing about that. [02:15:42] I've already spent way more time talking about this than I think is worth it, so I'll just leave it there. :-) [02:16:49] true, it wasn't you who went off on that tangent [02:16:55] ok [05:17:59] mooeypoo, forgot GettingStarted brings in ElasticSearch on MediaWiki-Vagrant. [05:18:18] This might be a while, or I might just short-circuit it and enable it manually... [05:18:48] I think it already installed all the dependencies, though. [05:31:03] ebernhardson, how much RAM does CirrusSearch really require on Vagrant. It only asks for 512, but I keep getting OOM. [05:31:24] matt_flaschen: hard to say, JVM is greedy :( [05:31:26] lemme look [05:32:17] so, at least on my current vagrant instance top reports es using 360MB. The java heap is set to 256M and then JVM always uses a bit more... [05:32:22] but that means 512 should be a reasonable guess [05:33:43] Hmm, yeah, I don't know why 1500 isn't enough, but probably a combination of stuff. [05:33:54] i have mine set to 2.5G of memory, probably due to similar issues [05:34:05] but at this exact moment, it reports only actually using 1G of that including disk caches [05:34:05] I don't really need it for what I was testing, I was just wondering if I could make gettingstarted (which depends on ES) provision cleanly. [07:01:04] [17:14:09] -*- ebernhardson always felt wikimedia messages overrides felt like a complete hack <-- YES. [07:01:47] yeah it's because they are [07:04:45] I thought I remember swalling distinctly saying that GettingStarted was a Wikipedia-specific extension? [07:08:53] * legoktm grumbles about https://gerrit.wikimedia.org/r/#/c/124826/ not having bug links [07:10:15] unfortunately, "getting started" is a pretty hard thing to search for xP [11:14:07] (03CR) 10UltrasonicNXT: "This is breaking all history and diff pages on our wiki," [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/262869 (https://phabricator.wikimedia.org/T88056) (owner: 10Ananay) [11:21:27] (03CR) 10TTO: "More likely to have been ee7ca911f226a15b0c3435d7036dbb32cdacb148...?" [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/262869 (https://phabricator.wikimedia.org/T88056) (owner: 10Ananay) [11:23:04] (03CR) 10UltrasonicNXT: "My apologies, posted that comment on the wrong commit" [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/262869 (https://phabricator.wikimedia.org/T88056) (owner: 10Ananay) [11:23:15] (03CR) 10UltrasonicNXT: "This is breaking all history and diff pages on our wiki:" [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/260342 (https://phabricator.wikimedia.org/T121369) (owner: 10Mhutti1) [11:24:40] 6Collaboration-Team-Backlog, 10MediaWiki-extensions-Thanks: Thanks extension breaking all history and diff pages - https://phabricator.wikimedia.org/T124532#1958911 (10UltrasonicNXT) 3NEW [11:25:50] 6Collaboration-Team-Backlog, 10MediaWiki-extensions-Thanks, 7Easy, 3Google-Code-In-2015, 5Patch-For-Review: Thanks: Take advantage of new parameters passed to HistoryRevisionTools and DiffRevisionTools hooks - https://phabricator.wikimedia.org/T121369#1958921 (10UltrasonicNXT) This is breaking history an... [11:27:29] 6Collaboration-Team-Backlog, 10MediaWiki-extensions-Thanks: Thanks extension breaking all history and diff pages - https://phabricator.wikimedia.org/T124532#1958928 (10UltrasonicNXT) Sorry should say, we are MW 1.16.2 and thanks 1.2.0 (2ee8d58) [11:33:03] 6Collaboration-Team-Backlog, 10MediaWiki-extensions-Thanks: Thanks extension breaking all history and diff pages - https://phabricator.wikimedia.org/T124532#1958930 (10TTO) I'm guessing you mean 1.26.2... You should be using the REL1_26 branch, then, shouldn't you? That commit was only on master. Master isn't... [12:53:31] (03CR) 10Florianschmidtwelzow: "I suspect, that you don't use a wmf-version, so you shouldn't use the latest master branch of the Thanks extension. You need the following" [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/260342 (https://phabricator.wikimedia.org/T121369) (owner: 10Mhutti1) [12:55:44] 6Collaboration-Team-Backlog, 10MediaWiki-extensions-Thanks: Thanks extension breaking all history and diff pages - https://phabricator.wikimedia.org/T124532#1958962 (10Florian) 5Open>3Invalid a:3Florian I copy my comment from the gerrit commit ([[ https://gerrit.wikimedia.org/r/#/c/260342/ | link ]]): >... [12:56:19] 6Collaboration-Team-Backlog, 10MediaWiki-extensions-Thanks, 7Easy, 3Google-Code-In-2015, 5Patch-For-Review: Thanks: Take advantage of new parameters passed to HistoryRevisionTools and DiffRevisionTools hooks - https://phabricator.wikimedia.org/T121369#1958966 (10Florian) See {T124532} [18:18:09] 6Collaboration-Team-Backlog, 10MediaWiki-extensions-Thanks: Thanks extension breaking all history and diff pages - https://phabricator.wikimedia.org/T124532#1959111 (10UltrasonicNXT) My apologies guys. [18:18:17] (03CR) 10UltrasonicNXT: "My apologies." [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/260342 (https://phabricator.wikimedia.org/T121369) (owner: 10Mhutti1) [18:48:59] 3Collaboration-Team-Current, 10Notifications, 7I18n, 5Patch-For-Review: Display human-readable wiki names for cross-wiki notifications - https://phabricator.wikimedia.org/T121936#1959137 (10Nemo_bis) As for (3), that's something we have to fix anyway; cf. my SiteMatrix patch https://gerrit.wikimedia.org/r/... [19:32:49] 3Collaboration-Team-Current, 10Notifications, 7I18n, 5Patch-For-Review: Display human-readable wiki names for cross-wiki notifications - https://phabricator.wikimedia.org/T121936#1959174 (10Mooeypoo) >>! In T121936#1959137, @Nemo_bis wrote: > As for (3), that's something we have to fix anyway; cf. my SiteM... [21:16:18] 3Collaboration-Team-Current, 10Notifications, 7I18n, 5Patch-For-Review: Display human-readable wiki names for cross-wiki notifications - https://phabricator.wikimedia.org/T121936#1959266 (10Nemo_bis) > Indeed -- but it's not fixed yet, so it joined my list of annoyances-in-creating-the-quickfix... Fair en... [21:27:22] 3Collaboration-Team-Current, 10Notifications, 7I18n, 5Patch-For-Review: Display human-readable wiki names for cross-wiki notifications - https://phabricator.wikimedia.org/T121936#1959284 (10Mooeypoo) >>! In T121936#1959266, @Nemo_bis wrote: >> "English Wikipedia" is translated differently [...] "Hebrew Wik... [22:54:19] 6Collaboration-Team-Backlog, 10Flow, 7Design, 7Easy: Flow: Topic history page doesn't reflect action in h1 heading or tag - https://phabricator.wikimedia.org/T72472#1959408 (10dg711) So, I started from the scratch to avoid any error caused by myself earlier . Cloned it as -> ssh://dg7@gerrit.wiki... [23:49:30] <wikibugs> 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review: Flow\Exception\FlowException from line 159 of Flow/includes/Formatter/ChangesListQuery.php: Revision not found in revisionCache - https://phabricator.wikimedia.org/T122329#1959464 (10Southparkfan) Didn't really get more information: ``` root@mw1:/srv/me...