[10:05:42] The most important wiki is 1.33, but now upgrading another wiki from 1.32.1 -> 1.33, I experience the exact same error as this one. https://phabricator.wikimedia.org/T227662, but browsing the ticket I don't quite find how to fix the situation of function MigrateComments failing with "Error: 1054 Unknown column 'ar_comment_id' in 'where clause'" [10:10:29] I'm going to try running patch-comment-table.sql manually and see what happens [10:15:06] progress (maybe) ... the patch-comment-table.sql run without problems and the update.php ran without problems, but now when logging in into wiki I get "Auto-creation of a local account failed: You have not specified a valid username.". Username and password are from Firefox Sync's autofill. Any ideas? [10:18:17] ahhh.... a 'sudo service apache2 graceful' seems to have fixed that [11:30:46] Now I'm trying to upgrade yet another wiki, but Extension:Translate isn't behaving as expected after 1.32.1->1.33. I have a test page, I edit it, I tag the newest revision for translation, click on translate, but the new parts do not show up as things to translate [11:34:58] oh now I remember... I need a background runner for the jobs that is set to run at all times [11:35:18] .. that was needed before Extension:Translate would work [11:44:56] Now running inside a tmux 'sudo -u www-data php maintenance/runJobs.php --wait', but I cannot get the Translation to work regardless [11:49:29] mobijubo: seen anything similar on https://phabricator.wikimedia.org/project/view/271/ ? [11:49:58] Flagging for translation works (I think, at least it shows up in RC), but then when hitting "translate" the new additions are not visible anywhere [11:50:59] I haven't used translate for years [11:51:07] so I barely remember the UI [11:54:44] mobijubo: anyway, did you check PHP error logs and do you have $wgDebugLog enabled? [11:55:18] Not as of yet [11:56:07] I should perhaps roll back the wiki to 1.32.1 and try if the Translate works int the first place [11:59:13] From my manual logging I see that Extension:Translate was installed on 2019-04-01 and the wiki was upgraded to 1.32.1 on 2019-05-29. I guess I need to apologize for having been sloppy. I should have tested the extension to work after the updatea [12:02:52] no worries mobijubo it happens to all of us [12:13:16] it seems that the thing that was wrong was that I added the new contents after the -tag. Moving edits inside of the -tag and it seems to work fine [12:32:15] Nikerabbit: Hey! Can we coordinate on the remaining for for the MCR migration on Translate? [12:32:41] Some core changes that are supposed to go into 1.34 are blocked on the open patches against the TRanslate extensin [12:36:22] Hi duesen. Vielen Danke für Hilfe mit wiki family problem [12:36:48] The wiki family is now 1.33 :D :D [12:37:14] mobijubo: No problem, I didn't do much... I saw that Anomie was able to help you out. [12:37:16] Excelellent! [12:37:38] mobijubo: great to hear stuff is running now! [12:37:46] hi duesen long time no see [12:38:01] saper: hey! yes, indeed! good to see you around ;) [12:40:22] With Wikistudy I ran into this exact same issue https://phabricator.wikimedia.org/T227662#5325853 which was resolved by running the patch-comment-table.sql [12:40:39] and BCM! wiki upgrade ran without problems at all [12:43:45] duesen: umm why are they blocked in that direction? [12:52:39] Nikerabbit: because core will stop writing data into rev_text_id. The field will be 0, and soon get dropped [12:52:47] We can't do that as long as Translate still needs that field [12:53:40] Nikerabbit: 1.34 will still suport legacy "write both" mode, but it will not be the default, and we will not use it in production. 1.35 will drop is completely [12:55:58] Nikerabbit: i suppose translatewiki.net could still use legacy mode; we are not using the export scripts on the wmf side, so things should still work. But that feels rather brittle. I'd prefer that all wmf supported extensions to be fixed before we change the default. [12:56:35] otherwise, Translate's export would break for third parties that use vanilla settings [13:00:14] duesen: wouldn't it only break for people running core master... it will take a while before 1.34 stable is released [13:02:25] duesen: I'm having a bit of a cold, so I'd avoid merging stuff today myself. On the other hand I'm fairly confident about the proposed patches based on last week's testing and review [13:02:55] Nikerabbit: yes. translatewiki could work on legacy settings until then. this is not super urgent, but it blocks the 1.34 release. also, the team is supposed to move on and work on other stuff, so it would be great to get the patches in before they are stale [13:04:00] Right, "some time this week" is fine. I'm off on Thursday and Friday, but Petr should be available for follow-ups. [13:04:26] duesen: yeah I was just going to ask... are we talking about today, or longer period of time [13:05:30] Nikerabbit: This week would be good, end of next week would still be ok. Later than that is still not a catastrophy, but getting annoying :) [13:06:47] duesen: I'll talk with Abijeet. Not sure how long this cold will last. [13:07:18] Nikerabbit: Aet better soon! Go and rest if you don't feel well. [13:12:03] duesen: yeah I'm resting with a laptop xD [23:53:35] https://www.mediawiki.org/wiki/Manual:$wgResourceModules is missing info on "targets" [23:53:50] Would be awesome if someone that knows about this thing could document it [23:56:26] I'm wondering if I need to add both mobile and desktop to all my modules or if that is the default