In T257625#6298089, @NickK wrote:

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.

In T257538#6295594, @Huji wrote:

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.

I happened to see this 5000 lines limitation relatively frequently, probably a few times a year.

In T253912#6174486, @Jdlrobson wrote:

I understand hence the "short term fix" part :) - that will patch wikidata in the mean time.

A fix will be coming soon, but it will take a bit longer.

In T253912#6174332, @Jdlrobson wrote:

The gadget is there, it's just the menu is hidden

As a short term fix I suggest adding the following rule to the gadget:

#p-cactions.vector-menu-empty  { display: block; }

I'll look for a better long term fix.

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.

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.

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:

1. https://uk.wikipedia.org/wiki/Кнайпа displayed as not linked to any Wikidata item.
2. 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)
3. A null edit on ukwiki does not help it link to Wikidata (still not linked)
4. 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

Yes, I confirm that this was solved. Please also fix T246571 which also negatively affects the way we label partially blocked users.

In T227260#5456416, @Zache wrote:

Hmm, problem may be just because 'ukwiki' => false is missing from wgFlaggedRevsOverride setting in InitialiseSettings.php ?

@Reedy @Quiddity
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?

@Reedy @Quiddity is there any progress on this? In Ukrainian Wikipedia T227260 was caused by this change and is not fixed for over two months now. Thanks

Setting as high priority because it break Ukrainian Wikipedia patrolling workflow.

In T210897#4804369, @Etonkovidova wrote:

@NickK The task has been evaluated and will be triaged in the team's incoming meeting next week.

@Etonkovidova and @SBisson , could you please have a look at this? Thanks

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

Is it there a guide on how to make a wikitext export? I would need it for ukwiki.

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

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.

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

Уже все зроблено: комітет розглянув заявки, обрав стипендіантів, і ті з'їздили на Вікіманію та прозвітувалися

In T30856#3395495, @Whatamidoing-WMF wrote:

@NickK, if a volunteer turns it into a script, then you could use [[User:NickK/global.js]] to run it at all wikis.

In T30856#3393545, @Quiddity wrote:

With the new toolbar, in the dialog box, once you've typed the link text you can just tap the [return/enter] key on your keyboard to place the [[link text]]. You do not need to use the mouse to click on the "Insert link" ("Вставити посилання") button. Hopefully that works for you, and saves you a mouse-move and click. :-)

I am rather disappointed to see this happen.

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

In T161263#3130619, @Lydia_Pintscher wrote:

https://tools.wmflabs.org/pltools/rech/ should help. Filter by term and language code.

Do I understand correctly that this will not be deployed before Monday due to "no deployments on Friday" rule?

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
etc.
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 م

In T161263#3127769, @MaxBioHazard wrote:

Maybe it's because russian keyboard has russian lovercase "х" on the same key that "[" in English keyboard. I.e. some filter restricts adding "[" into parameters values, and it's affects all other language symbols that are on the same key with "[".

In T160829#3117467, @dcausse wrote:

I'm curious to know if it's a recent regression that may have been caused by elasticsearch 5 migration. I'm tempted to say yes since it's the second bug report in the few days following elastic5 roll out.

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

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.

UNESCO organised a contest.

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:

1. 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.

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".

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.

Thanks, I confirm that the problem is resolved.

In T136281#2329459, @Danny_B wrote:

Did your wiki by any chance recently asked for changing of category sorting (collation)?

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

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.

Done.

Done.

I confirm that this behaviour still occurs. While attempting to work with a very large cohort I get the following errors:

In T119206#1838886, @demon wrote:

No that isn't possible I'm afraid. It will only set the preference on wikis in which you have a local account on though, so if you go to a wiki you haven't been to before, you'd get the same effect going forward.