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
Mar 15 2017
The group "Stewards elections 2016" doesn't show statistics for Italian either. And still no totals. Besides, that's not only my problem. Today I'd asked another translator to tell me how many untranslated messages there are, and she sent me a PDF with Special:LanguageStats and it contained no totals and no data on certain message groups.
Sometimes I need to purge Special:LanguageStats to update the statistics that doesn't want to update on its own. I do it this way:
- I add ?&action=purge to the page url and press enter
- if the purge was successful (sometimes there's an error) I press any of the message groups to open them in the translation system
- then I return to Special:LanguageStats by manually typing it in the search field and press Enter.
- there I get a red message saying "Some of the statistics on this page are incomplete. Please reload to get more statistics." I reload until it disappears. But if my connection is a bit slow, I get all or nearly all the message groups (including the 100% translated ones) with three dots instead of message count
Jan 12 2017
Reported here today.
Is there a way to show all the translation units if the title translation is disabled? Shouldn't there be some code that tells if it is enabled or disabled? If there is, can it be used to determine if the first translation unit should be hidden or not?
Jan 1 2017
Dec 28 2016
I think that the way the issue is described here is incorrect. See the correct and more detailed description in T154181
Now I can see that the description IS correct, but the issues are quite different. This is why I doubt that merging these was a good idea.
Dec 27 2016
Go to any Russian wiki (e.g. Russian Wikipedia) and follow any of the links I mentioned, except MediaWiki (it's still in English for some reason) – you'll get to the appropriate projects' main pages in Russian.
Dec 18 2016
Most likely the change was not deployed there yet when you asked. If it still happens, you please file a subtask with more details.
No, it's OK now, thanks.
Dec 14 2016
How about upgrading the button's priority in the "insert" dialog for talk and Wikipedia namespaces, and downgrading or completely hiding it for all the other namespaces?
That said I appreciate it is a very useful tool on talk pages, although I wonder how often it is actually used...
Dec 1 2016
I advise you to close this ticket as declined. You shouldn't implement any language fallbacks without obtaining the relevant community's consent. And you shouldn't restore Russian fallback for Ukrainian wikis after it's been removed (T39314)
And one more question – what about Wikimedia Commons? Its license templates still fallback to Russian.
Nov 30 2016
@EBernhardson This is the list of magic words in Russian to search for:
@thiemowmde Thanks for the info. Hope you're right and it will go away soon.
@EBernhardson Thanks for the adjustment. I've checked them all, found only 10 positives, 2 of which I didn't fix due to the context. I'll post the result on the "remove the Russian fallback" thread. If the language engineers agree to remove those aliases, the current patch wouldn't be needed anymore.
I have checked several pages from the list P4542 and it seems that most of them are false positives: four Ukrainian aliases had been included in the search query and some of Russian aliases, like "Журнал", also result in false positives (pages containing Special:Журнали, which is in Ukrainian). I'll count the pages with true positives, but even now I think that backwards compatibility is inconsistent for keeping all those Russian aliases.
I thank all of you for devoting your time and efforts to resolving this issue.
Unless, of course, you're ok with removing Russian ones completely, in that case the problem goes away naturally.
Nov 29 2016
I'm not sure if I understood everything correctly, but I doubt this could do any difference. The suggestions are ranked alphabetically, and same aliases usually use names that start with different letters in Ukrainian and Russian. So in the example described above, nothing would change. Of course, that's if I got you right.
If this could work somehow, I can assist with creating a list of Russian aliases based on that php file.
I can see that Wikidata still uses Russian as a fallback. Will this change after some time, or is this a separate issue that needs a separate ticket?
Nov 27 2016
No, Ukrainian uses cyrillic script, so you don't have to do anything with English. The problem is with Ukrainian/Russian results.