Sep 16 2021
Feb 28 2021
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.
Dec 26 2020
Apr 9 2020
@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!
Mar 29 2020
Mar 25 2020
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).
Mar 18 2020
@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.
Mar 10 2020
Mar 5 2020
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?
Mar 1 2020
Feb 26 2020
Feb 11 2020
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.
Feb 6 2020
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.
Jan 17 2020
Nov 14 2019
Oct 27 2019
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.
Oct 22 2019
Oct 17 2019
Oct 16 2019
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.
Oct 13 2019
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)
Oct 12 2019
Jul 15 2019
Thanks for finding the root of the problem. And I apologize for wasting your time.
Jul 14 2019
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.
Jun 1 2019
Mar 24 2019
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.
Feb 11 2019
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.
Feb 2 2019
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.
Jan 31 2019
Hello? Anyone? There are more people complaining about the abuse filter being triggered on headers. Is there any workaround or something?
Jan 22 2019
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.
Jan 21 2019
Jan 19 2019
Ukwiki is affected too, so I would support the mention in the Tech news for other wikis.
Jan 13 2019
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)
Dec 15 2018
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?
Sep 5 2018
Thanks! I've fixed it (I didn't know the bot uses TemplateData)
Sep 3 2018
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?
Sep 1 2018
The IABot interface provides strange edit description, see here. Can you fix it, please?
Jun 7 2018
You can start a new request for a bot flag here. This process should be quick.
Mar 3 2018
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.
Sep 12 2017
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
Jul 10 2017
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.
Jul 3 2017
Thank you, @Cyberpower678 . I've translated your message into Ukrainian. I hope you don't mind ;)
May 31 2017
May 15 2017
May 14 2017
Hm... didn't notice this issue yet with 2017 editor disabled
@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.
Apr 14 2017
The Special:AggregateGroups slowness can be solved using pagination, as mentioned in T90511
Apr 1 2017
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)
Mar 31 2017
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.
Mar 29 2017
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:
or something similar.
Mar 27 2017
Thank you all. I'll remain silent from now on.
Obvious is obvious. Your examples are irrelevant.
Mar 24 2017
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.
Mar 23 2017
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?
Mar 22 2017
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.
Mar 20 2017
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?
Mar 19 2017
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).
Mar 17 2017
I think I've ruined stats for Italian too