As I said above, it makes no sense to me for sysops to already having patrol but not review, while both are effectively the same stuff, just implemented by different parts of code. I merely fixed what I consider to be an inconsistency in code.

The logic "sysops can grant those rights, therefore they should have them by default" is kinda flawed. Would you apply it to bureaucrats or stewards as well? I don't like to see such a drastic change being implemented without consulting or even notifying the communities that actively use the FlaggedRevs extension.

In T264766#6711986, @Tgr wrote:

Would that help? The vandal could still create new accounts and vandalize the talk pages of the mentors of those accounts.
Some custom defense based on IPs or other characteristics might have more chance of succeeding, IMO.

@aezell indeed, we didn't update the relevant gadget, while its enwiki counterpart fixed the problem quite quickly (they had this discussion, where it was suggested to use a restrictions property for the bkprop parameter, as described here). Anyway, the problem seems to be solved now, thanks!

@dom_walden, @Niharika Everything looks fine now, thanks! You may close this task as solved.

I confirm that all the ukwiki templates on those Wikidata items correspond to their enwiki counterparts. But if "Add links" needs to use a template that literally encourages users to add links (instead of performing some general cleanup), then Q13107723 ("Underlinked" for enwiki) might be a better choice (there're not so many transclusions for the relevant template on ukwiki though).

@Tchanders thanks for the clarification, and yes, I think that a different class for partial blocks would be the best solution for this issue (provided that it also allows for a different text message, i. e. "this user is currently partially blocked" instead of "this user is currently blocked")

Yes, indeed, there seems to be a similar local setting, but I'm not sure if it corresponds to the message in question (I'll explain it below), and even if it does, this doesn't resolve the issue with the possibility to distinguish between the full and the partial blocks. Say, we want the warning for the full blocks to remain red, while for the partial ones to both display a different text message and have a different color styling. Is there a way we could possibly achieve this locally? I assume there's none, since the reasons mentioned by NickK: the same message and the same styling are being used for both types of blocks.

Why is the "month" word capitalized in the translation? E. g.: the current translation says "Минулий Місяць" instead of "Минулий місяць" for Ukrainian. The same goes for "last two years" string ("Останні Два Роки" instead of "Останні два роки"). Is it somehow connected to this task?

@Niharika I've partially blocked my test account, so you can take a look at the message in the red box on the contributions page. We're proposing to change its look to something like this.

I do keep an eye on the list, it's just that if a user gets renamed, you don't see that in your watch list for that page. I've added all the mentors' pages to my watch list, so that I could notice any changes of that kind too. As for the wikitext warning, it's already there, added by @Ata at the very moment of creation of that page.

@MMiller_WMF: thanks for the explanation! Yes, it makes sense, and we're currently thinking about a workaround to shorten the message translation-wise. As for the suggestions, there're some, but I don't think they're technically feasible at this point. Like, it would be better to post the messages with the same heading in the same section instead of creating a separate one. Or to move the page link (indicating where the help panel question workflow was triggered) from the heading to the comment area, just before the newcomer question, and so on.

Hi! I've tried some of the features and everything seems to work fine so far (I didn't test the help panel though). The only downside I've found I already mentioned in T238319. Also I didn't notice any relevant feedback from the community so far.

Hi! Could you please at least remove the date from the topic names that are being created on the help page? See the page for a reference. The dates seem to be redundant, since they're already in the signatures, so why duplicate them? Besides, the page (and edit descriptions) feel somewhat cluttered and overly technical. It's best to simplify them somehow, and the removal of the date would be a nice starting point.

In T231720#5811842, @Catrope wrote:

On which namespaces it have to be deployed = 0, 2, 4

Just checking, this means the help panel would appear in read mode on pages in the main, User and Wikipedia namespaces, but not in the Help namespace. Is that intended? On every other wiki that has the help panel, we don't enable it in the main namespace, and do enable it in the Help namespace (in other words, we do 2, 4, 12). Note that this is just about where the help panel appears in read mode; in edit mode it will appear in every namespace.

So, the translations are ready, and everything else seems to be done as well. Is there anything else we should do here? If not - please deploy the feature at Ukrainian Wikipedia.

Privacy policy/Proposed Revisions/uk on Meta-wiki is broken, the bug is still there (just sayin')

Yesterday I encountered a message on Meta-wiki that'd been showing a wrong content. Unlike other previously reported messages, it wasn't properly purged after the hotfix was deployed. I managed to purge it with a real edit instead of a null one (added a character > saved, removed the character > saved), if this info helps in any way.

But it seems it's not a TWN only issue. The bug has been reported also on Meta-wiki and mediawiki.org, i. e. the projects which use the Translate extension.

@Ata That's a good point. Though I'm seeing the chunk of text instead of a single word in this message (yesterday it said just "Захист", while the chunk of text was visible in the history only). Also it doesn't explain how that exact chunk of text ended up here (it is displayed on the target page now in the header where the "Welcome!" message should be)

I tried to translate the Privacy policy today, but the translation extension seems to be broken right now. It does some really weird stuff, which makes the translation generally impossible at this moment.

Thanks for finding the root of the problem. And I apologize for wasting your time.

This is what it looks like in plwiki (see the eye icon on the right). In ruwiki it's completely different (the same look as for the registered users in ukwiki)

The downward pointing arrow is on the far left, the dropdown message is on the far right. The whole thing looks like an empty box taking so much space at the top of the article for no reason.

Is there a way to place the link before the "edit" link? Because if I simply change the .after values to .before, the link is created correctly, but for some reason it duplicates the "edit source" label, so I get something like (edit source | edit source), or (ред. код | ред. код) if I'm supposed to be precise. I don't know what causes this, because in English Wikipedia such a change works as intended.

I have closed this task, since it seems to be an intended behavior, per this enwiki page. Still doesn't make much sense to me, since when you block a separate IP address, you don't have to prevent the registered users from editing (even though there's an option for it). I don't get why autoblock does work that way.

Today I was struggling with a page on Commons, as there were some changes made to the original, so I had to restore the translation tags (wasn't aware of the problem), and mark the page for translation for the changes to apply to the translated pages. Then I saw that the sections of the page are being transcluded faultly. At first it said that "no information is available" under the relevant section. Then I removed the section header comment, and noticed that it's displaying the <translate> tags and refuses to display the rest of the transcluded sections (the ones that go below) on that page. So I removed the page from translation system. Indeed, it's impossible to work with those pages right now.

Hello? Anyone? There are more people complaining about the abuse filter being triggered on headers. Is there any workaround or something?

It's not only about long reference lists (which I confirm, see point 3 here T214333, there's my error console screenshot too), I had this issue with some short paragraphs too. They just wouldn't load, and then the message "Automatic translation failed" appears on the right.

I reported this here T214333 too (under point 2), and it's good to have a separate report about this issue. AFAICT, to open the third report, you have to locate the paragraph that's triggered it first. Place the cursor there and you'll be able to open the problem details.

Ukwiki is affected too, so I would support the mention in the Tech news for other wikis.

I'm using Chrome on Windows, and the inspector shows me the same - font-family is sans-serif, coming from body (the sans-serif coming from html is stroke out for some reason - idk if this matters, I'm not a coder)

A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?

Thanks! I've fixed it (I didn't know the bot uses TemplateData)

There is one more problem: for some reason the IABot interface adds another "accessdate" parameter while there already exists "access-date" parameter. It should remove the latter one (diff). How can we fix this?

In T151446#4550808, @Cyberpower678 wrote:
Templates are not advised in edit summaries. Can you replace that with suitable words so I can properly update the configuration?

The IABot interface provides strange edit description, see here. Can you fix it, please?

Hi,
You can start a new request for a bot flag here. This process should be quick.

I didn't like FF while on Linux - it used to be very slow. On Windows it runs much better, indeed. As for a mouse wheel - I, personally, never use it's click function, and tbh, I didn't even know it can open links in new tabs as well, so thanks for the info.

Please read the comments carefully and take into consideration the other browsers as well. It still doesn't work on Firefox, and I installed that browser solely to confirm this.

I'll clarify: I suggest to stop moving the page itself up or down. Let the filter search bar stay where it is the moment one clicks on it (leave it static, but preserve the scaling of the list of filters). And let the users decide where they want to see it by using a mouse wheel

As can be seen from the discussion (link), there's a clear consensus to enable IABot on ukwiki. We'd like the bot to add archive urls to all the urls, including the live ones. And also we'd like the bot to leave messages on the talk pages if it encounters some dead urls that haven't been archived and cannot be fixed.

Thank you, @Cyberpower678 . I've translated your message into Ukrainian. I hope you don't mind ;)

In T165238#3261451, @Acagastya wrote:

@TheDJ, T165132 is due to the New Editor which I did not enable. I am facing this issue when I try to use the old editor.

Hm... didn't notice this issue yet with 2017 editor disabled

https://cs.wikipedia.org/w/index.php?title=Loremipsumdolorsitamet&action=edit&redlink=1&uselang=en&venoscript=1
in order to work.

@Aklapper Please read the description of the merged task: T165236 The issue's not the same for all the users. And it seems it has something to do with the wiki settings, since on enwiki I didn't notice any problems at the first glance.

Please merge T165236, it's on the same problem

I've made a test in dawiki – red links don't open instantly, but show the message suggesting to reload the page. The same as in ukwiki. In enwiki I see this message too, but the editor loads on its own, I didn't notice any major problems there.

The Special:AggregateGroups slowness can be solved using pagination, as mentioned in T90511

I don't get, why шлем is in this group.

It's a (poetic) form of "шлемо", can be found here under "слати". The same is generally true for all or nearly all the other words ending in -мо: пам'ятаємо/пам'ятаєм, пронизуємо/пронизуєм etc. (took too long for me to write this)

Is it rare to have words that differ only by stress?

I'd say it is for Ukrainian. I didn't find too many pairs. Besides, we seldom use stresses: the meaning of such words is understood from the context, and without the stress marks you won't be able to programmatically tell the difference.

As for the first sample of 100 groups, it looks OK. Some of the groups seem to contain a mix of abreviations and regular words (like [19 ПАР][2 Пара][1 Пари]... where the first one seems to be an abbreviation for the Republic of South Africa), but generally there are no errors.

I noticed this issue on Meta-wiki too, and resolved it on-wiki by putting the <nowiki> tags into the <translate> tags themselves like this:

<<nowiki>translate> </translate</nowiki>>

or something similar.

Thank you all. I'll remain silent from now on.

In T160902#3133148, @Nemo_bis wrote:

By the recurse to apodictic statements I consider you forfeit reasoning. Hence it's proven that nested groups are not generally positive. Thanks.

Obvious is obvious. Your examples are irrelevant.

I don't know who is "searching for affiliates' message groups". Do you know some such translators?

You got me wrong. I meant that the "Affiliates" aggregate group should contain the message groups for all the affiliates, not just some of them (while the others are kept outside as if they're special or smth). Being one of "such translators", when I open the "Affiliates" aggregate group, I expect to find there all the affiliate related message groups, including the one for Maithili Wikimedians User Group, because this is simply obvious.

TL;DR again or what? Because I don't think that my English is that bad for you to not understand what I write. Besides, I've been talking about working with Special:AggregateGroups and that it works extremely slow on Meta-wiki. How could I possibly know that without being a translation admin myself?

Is there a possibility to add a purge function for a separate aggregate group for a single language? I noticed that if I open such a group on Special:MessageGroupStats (for example, the mentioned "Affiliates" group which's been showing 1055 untranslated messages all the time) and purge that single page, the stats on Special:LanguageStats get updated too. But still if the group is a large one, it takes some time to populate the stats for all the languages.

Yes, I'm asking for the possibility of nesting. That would help to make Special:LanguageStats somewhat shorter in size (visually) on Meta-wiki, and would help to eliminate the clutter by clustering the related aggregate groups into larger parent groups.

The "low" and "normal" priority tasks you mentioned, created up to 1.5 year ago, don't seem to be fruitful either. I'm not a coder, I don't know how to formulate the current problem for someone to start working on the solution.

Well, I'm not looking for a workaround, I want a complex solution. If you provide some ways to update the statistics for separate aggregate groups manually or fix the automatic update – that would be really nice, but the problem is more complex than this.

Before I started to translate "Affiliates" message group yesterday, it'd been showing 1055 untranslated messages. I've translated several more messages today but it still shows 1055 untranslated messages. No need to purge you say? Special:MessageGroupStats shows the same. How am I supposed to see the actual stats? I don't overuse that "purge" feature – I usually use it only after the whole large message group or several smaller are translated. Do you want to remove that feature without addressing the problems mentioned or what? Something like "out of sight, out of mind"?

No, it's not about "updating faster", I'm purging the page to make the translated aggregate groups disappear. They just don't go away after I finish the translation, and if I don't purge, I have to wait for several days to see them vanish. Are you trying to tell me this is OK?

In T160565#3113368, @Nemo_bis wrote:

Yes, one shouldn't purge the stats pages without a good reason.

I guess the devs should do something about how the stats are collected. There's a noticeable lag in that. For example, if I open a separate but large aggregate message group, and press the tab "Message group statistics", I get the red message saying that the statistics is incomplete, and a lot of grey color with three dots instead of data. Then I reload and reload and reload – do that multiple times until the statistics turns complete (the page adds data for ~5 languages at a time).

I think I've ruined stats for Italian too
https://www.webpagetest.org/result/170317_7D_DTG/