Sep 3 2019
Aug 31 2019
Is anything being done on this?
It has been two months since we raised the issue, and three months since it was broken.
We have a school year starting this Monday (2 September), and all our education initiatives will end up in a fail: new users improving existing articles will not be able to show their edits to each other.
Could you please explain where is the delay coming from? If this is Declined, than please tell this so that we adapt our patrolling framework accordingly (e.g. assigning patrolling rights to all education programme trainers). If this can be done, what is the blocker?
Aug 24 2019
Setting as high priority because it break Ukrainian Wikipedia patrolling workflow.
Dec 7 2018
Dec 6 2018
Dec 3 2018
Is it possible to return it back to 5000? On busy wikis 1000 is not even one day of edits, thus it makes RC patrolling increasingly more difficult. In some cases (e.g. significant number of semi-automated edits) it is just an hour or two of edits, making such small limit barely usable. Thanks
Nov 21 2018
Is it there a guide on how to make a wikitext export? I would need it for ukwiki.
Aug 28 2018
Please do deploy it earlier than 4 September. We really need it for Wiki Loves Monuments to be ready on 31 August. All Ukraine's Wiki Loves Monuments list have a direct link to Upload Wizard that currently are not working. If it is absolutely impossible to get them ready by 31 August please give us the planned date so that we inform participants (and remove links that do not work). Thanks
Jul 10 2018
I see this might be an encoding problem, so:
Pages I could not edit are [[:w:uk:Груповий етап Ліги чемпіонів УЄФА 2011—2012]], [[:w:uk:Обговорення Вікіпедії:Заявки на позбавлення прав адміністратора]] and others (edits not saved).
I could edit the page [[:w:uk:Under the Ladder]] (edit saved correctly).
Looks like editing any page with non-Latin name is impossible now.
Same for me.
Jun 6 2018
Can you please announce how to opt out? I use Monobook a lot for administrating (I *need* an option to delete a page in one click from mobile), I see it deployed again on a non-Wikipedia wiki (uawikimedia to be specific) without any opt-out settings
Nov 15 2017
Уже все зроблено: комітет розглянув заявки, обрав стипендіантів, і ті з'їздили на Вікіманію та прозвітувалися
Jul 6 2017
Jun 30 2017
Jun 29 2017
I am rather disappointed to see this happen.
Jun 26 2017
May 22 2017
This happened again today, this time targeting checkuser-l and another user (will not disclose username here but one thing in common is that this user also uses mail on their own server). It is somewhat disturbing to receive spam on a non-public mailing list
Apr 4 2017
Mar 27 2017
Mar 26 2017
Mar 25 2017
Do I understand correctly that this will not be deployed before Monday due to "no deployments on Friday" rule?
Mar 24 2017
Yes, the thing in common is \x85 in UTF-8 encoding:
х = \xD1\x85
Ӆ = \xD3\x85
ԅ = \xD4\x85
Յ = \xD5\x85
օ = \xD6\x85
م = \xD9\x85
ׅ = \x20\xD7\x85
अ = \xE0\xA4\x85
অ = \xE0\xA6\x85
Thus other letters are also affected:
Ѕ (Cyrillic) = \xD0\x85
҅ (Old Church Slavonic) = \xD2\x85
څ (Pashto) = \xDA\x85
Update: Greek affected as well with
υ = \xCF\x85
On more character affected: م from Arabic alphabet (reported in T161297 )
Yes, it is a duplicate. The affected character of the Arabic alphabet is م
Mar 23 2017
Clarification: labels, descriptions and aliases are all affected. Editing a description already containing this letter (i.e. not adding this letter but just keeping a letter added before) is not possible either.
It clearly worked just a few days ago, as I and many other users did add labels or aliases containing this letter
Mar 18 2017
Oct 12 2016
I would like to clarify what is needed here. What we need is to make sure that a user typing any of these three apostrophes will be able to find the article they need.
Aug 20 2016
Aug 1 2016
UNESCO organised a contest.
Jun 29 2016
As an active interwiki user I am very surprised by this deployment. In the current state this extension is more harmful than useful for two main reasons:
- Weird priorisation of languages. For instance, I was surprised that https://en.wikiquote.org/wiki/Albert_Einstein has no visible German interwiki. It is obviously valuable to read this article in German, as it can contain both quotes originally in German and more quotes (as German users are more likely to be interested in the article). Instead, German is well hidden behind "worldwide" and "American" (Dutch for what it's worth) in the middle of Europe. Instead, I see an Urdu page which is completely useless: https://ur.wikiquote.org/wiki/%D8%A2%D8%A6%D9%86_%D8%B3%D9%B9%D8%A7%D8%A6%D9%86
I would propose to use the following criteria:
- content-related languages, e.g. language(s) of the country where the object is, where the person lives/d etc. These languages are more likely to have useful information
- languages with best-quality articles, e.g. good and featured. Those are more likely to be interested than stubs without sources, and this will motivate editors (your article is more visible on the interwikis if it is better written).
- for registered users, user-related languages, i.e. languages a given user speaks. E.g. I have German in my Babel, thus I expect to see it on the interwiki list everywhere as I can read it.
Jun 10 2016
We don't have any threesome yet though; that requires at least to define an order, hence I asked the reporter how to rank uk and be in similarity to ru in order to decide between "ru, uk, be" and "ru, be, uk".
May 31 2016
Even the simplest version (used machine translation or did not use machine translation) would be very helpful. The main goal is being able to check machine-translated articles for common machine translation mistakes that a human cannot make.
May 30 2016
Thanks, I confirm that the problem is resolved.
May 26 2016
My guess is that recently changed (or recently created) articles are not at the right place in these categories and are added at the beginning of the category instead of the corresponding sort key, but this might be a wrong guess.
Categories become unusable with this, thus unbreak now
May 21 2016
As I have already written in T133800, there is strictly no key that can close this dialog, and it is annoying to have to click on a pop-up each time. It is just necessarily to add a key to dismiss this dialog, the most obvious choice being "Esc"
I am currently making similar edits to multiple projects (I have editing all of them before), and I am very annoyed by this message. I have to close this message in each and every project, and I do not have a button to close it - I have to move my mouse to "Start editing" and click it on every wiki.
Wrote an email to the international team about it, waiting for reaction and involvement of others.
Mar 16 2016
Mar 9 2016
I confirm that this behaviour still occurs. While attempting to work with a very large cohort I get the following errors:
Feb 2 2016
Dec 10 2015
Nov 30 2015
Is it possible to change my skin preferences to Monobook only in wikis where I have edits? I changed my preferences (incl. skin) on each wiki when I made my first edit there, and it was very useful for me to be able to distinguish immediately whether my preferences in a given wiki are already configured or not.
Jun 18 2015
Sorry, I tried to raise priority but I this does not seem to be supported in IE8... too bad!
Please note that this is critical for ukwiki community. T96547 is not resolved for two months, which is not the delay people want to wait.
May 12 2015
The original proposal was just about User namespace, not about User talk.
Apr 20 2015
Apr 6 2015
Apr 5 2015
I also wonder what problem whe are solving.
Apr 3 2015
Please resolve this ASAP: as T91204 was closed, Ukrainian Wikipedia now displays Russian translations instead of Ukrainian ones. Despite Ukrainian translations were submitted back in October 2014 and Russian translations were submitted in March 2015, this request is still not resolved.