Sat, Jul 11
Having a compact language list unchecked globally, I am getting different behaviours.
Interwiki order seems to be correct in Ukrainian and Russian Wikipedia, but is nearly random in English, German and French ones - to the point that I can hardly find if the article is available in the language I am looking for.
Thu, Jul 9
I happened to see this 5000 lines limitation relatively frequently, probably a few times a year.
May 28 2020
May 26 2020
Looks like this is getting worse. Multiple reports from users today on ukwiki who can no longer add articles, while it work for them as late as yesterday.
May 9 2020
Is there any progress on this?
I have just had an issue with a user indefinitely blocked from the Wikipedia namespace: I blocked him sitewide for an hour, I had to restore his Wikipedia namespace block right after.
This is not an expected behaviour at all. A sitewide block was due to an additional rule violation in a different namespace, and this is definitely not a good reason to remove the indefinite Wikipedia namespace block.
As is, an AbuseFilter is a better solution than a partial block: I would also need two actions (full block, edit AbuseFilter VS full block, restore namespace block) but the solution would be permanent.
Apr 7 2020
Looking at https://www.wikidata.org/wiki/Special:NewPages , creation of duplicate items seems to be the main source of new items on Wikidata at the moment :(
Logging here an unfortunate consequence: it is now possible to create a duplicate item linked to the same page.
Behaviour to reproduce:
- https://uk.wikipedia.org/wiki/Кнайпа displayed as not linked to any Wikidata item.
- https://de.wikipedia.org/wiki/Kneipe displayed as linked to https://www.wikidata.org/wiki/Q19754932 (the ukwiki article is linked to it as well)
- A null edit on ukwiki does not help it link to Wikidata (still not linked)
- To force linking I used a link on the sidebar in ukwiki and I add link to Kneipe on dewiki. The result is https://www.wikidata.org/wiki/Q89610534
Mar 29 2020
Yes, I confirm that this was solved. Please also fix T246571 which also negatively affects the way we label partially blocked users.
Mar 20 2020
Mar 9 2020
Mar 1 2020
Feb 26 2020
Nov 6 2019
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: