[06:34:30] Nikerabbit: a user noticed a glitch with translate blocks including multiple paragraphs, but with the closing tag being inside a paragraph. Here they made edits to undo this, not yet marking for translation: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F24.8&type=revision&diff=756149&oldid=756054 [06:35:22] If the block is not yet translated, the bit after the closing tag goes to its own paragraph, see "(László Németh) tdf#158885" here: https://wiki.documentfoundation.org/ReleaseNotes/24.8/sl#Compound_constituent_characters_at_line_end [06:35:46] On this German page the block is already translated and looks fine: https://wiki.documentfoundation.org/ReleaseNotes/24.8/de#Zusammengesetzte_konstituierende_Zeichen_am_Zeilenende [06:35:50] Does this ring a bell? [06:38:20] I could not find anything on Phabricator [06:52:07] I tested that the behaviour is the same with the latest git version of MW & Translate [07:06:57] buovjaga: I don't know what I should be looking at. Do you have a minimal example? [07:13:12] buovjaga: I think I got it. Untranslated/outdated text gets wrapped in tags. Tags depend on whether they are inline (span) or block elements (div). Since page has not been marked for translation, it's still treated as block element and getting wrapped in div which changes rendering [08:18:56] Nikerabbit: yes, summary: https://dpaste.org/ME0ER [08:20:34] btw. different topic: MediaWiki devs might like this feature for easy web editing I added to Gitiles with the help of more experienced hackers: https://gerrit.googlesource.com/gitiles/+/84fb315541de4364c63a55bda7b96a1a44e0637a%5E%21/ [09:53:31] I have a short question about MediaWiki 1.42.0. I am probably not the only one to ask. The release was tagged a fortnight ago, but so far, there has been no announcement, neither via the mailing list nor on the wiki, etc. [09:53:49] Do we have a realease? [09:54:09] Reedy You probably have insights. [09:55:32] No issues here. Just curiosity. :) [10:14:16] sounds like https://phabricator.wikimedia.org/T359849 [10:19:32] Thanks for the info. Looks like a matter of backlog work. In turn, this is already official but not announced. Thanks a bunch for the information. [10:47:18] buovjaga: yeah, I'm afraid that is working as intended [10:53:48] thanks :) [10:54:58] Another one, I asked this last month: How can the "Add languages" interwiki navigation be disabled? This one: https://phabricator.wikimedia.org/source/Vector/browse/master/resources/skins.vector.js/languageButton.js [10:55:33] I don't think you can [10:55:38] aww [10:55:53] it was another user complaint [10:56:10] you can move all the language links there [10:56:12] ie. confusing duplication [17:17:06] join /lxc [17:17:54] oops... sorry! [21:47:53] if I have this extension https://www.mediawiki.org/wiki/Extension:EditAccount and I have a wiki farm will it apply globally or only locally [22:28:02] Hello. I've been working on a project to upgrade our six MW 1.39 wikis' databases from MySQL 5.7 to 8 (Amazon Aurora MySQL 2 to 3, due to v2 support dropping on Oct 31). Their pre-upgrade validation checks reported a couple of errors (two tables in the shared tablespace, I've got that fix) but also a bunch of utf8 columns recommended changed to [22:28:03] utf8mb4. I've written and done basic testing of a script that runs about 270 ALTER TABLE statements to update all of the affected columns across all of our wikis. However, one other concern is that the default charset of most of the tables is utf8, per my current setting of $wgDBTableOptions. I'm going to change that variable from utf8 to binary, [22:28:03] per the current default for that variable, but should I also change the existing default charset for all utf8 tables to utf8mb4, in case future core or extension upgrades add new columns and don't specify a column charset, relying on a table's default? [23:43:59] https://www.irccloud.com/pastebin/oQtYOe8m/ [23:44:13] hi guys we are trying to add global abuse filters but don't know which table we need for it to work can anyone guide us