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.

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.

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.

The original proposal was just about User namespace, not about User talk.

In T39314#1220989, @Nemo_bis wrote:

The problem is that most of CentralNotice banners

I had no idea this was about CentralNotice banners, because they were never mentioned. In the meanwhile I've discovered and reported what needed, see T96549.

In T39314#1220208, @Nemo_bis wrote:

Showing English strings instead of Russian is not less of a surzhyk.

In T387#1181038, @Jalexander wrote:

As an example of something I could see a good use for:

---

Your most recent actions come from:

IP	Location
198.73.209.1	San Francisco, CA
5.63.151.148	London, England

If you notice anything unusual we recommend you immediately change your password [linked] and then log out [linked] and log back in to ensure someone other then you is unable to use your account.

---

I also wonder what problem whe are solving.

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.

Is it possible to resolve T73953 ASAP?