I think part of the issue here is addressed in T115847, but we need more to make sure we can keep up with various limitations (templates, tags etc. that need to be skipped) that currently exist and the ones that can appear later on (new templates etc.).

In T153315#3699104, @Deskana wrote:

How would you detect that a user is copying wikitext? There are heuristics that you could come up with, but such a heuristic would frequently fail, be incredibly fragile, and hard to maintain properly.

I've done some more testing and it seems there is a difference between pasting text and html, which makes sense. Perhaps we're approaching this use case by the wrong end: would it be easier to detect when the user is copying wikitext and keep only the text, without the HTML "garbage"? This way we would help at least the js-enabled users (which are probably the vast majority anyway).

I'm pretty sure this is a regression - pasting template wikitext in the Visual Editor used to work (that is, the template would be introduced) and now, following the steps from the description in the Visual Editor, I get the wikitext (with a link to the template). As i said in May, please take into account the fact that we are still requiring users to copy-paste wikitext in many places, so this should have priority over pasting a link (which is nice indeed, but did not work in the classic editor).

Isn't it possible to determine the data used and segment the RC feed based on that? For instance, very few articles make use of the language links except the article linked to the item. On the other hand, many articles use only the localized labels of items, which means it's probably not interesting to push changes to item properties to those articles.

What was the original idea behind pushing changes to an item to all linked items? This doesn't happen for MediaWiki and seems useless to me (N=1 seems perfect to me right now), but perhaps I'm missing something.

Oh, sorry for the omission. It's a JS file: https://ro.wikipedia.org/wiki/MediaWiki:Diacritice.js . Specifically, the ones in saveNewDiacritics() (I've only tested the one for the edit form)

In T171027#3594737, @Bawolff wrote:

:are you referring to Răzvan Socol (WZ0f2wpAMCYAAEJrINAAAAAP)? Because that was attempting to delete his watchlist, which is slightly different from viewing the watchlist (nonetheless taking more than 4 seconds to delete only 2700 rows seems excessively long. Maybe that server was just overburdened at the time(?)). In any case i think ill unmerge that bug as the reading and writing issues will need separate fixes i think.

In T171027#3594086, @Bawolff wrote:

• Based on people who are complaining at commons, problems seem to start to arise with watchlists > 20,000 entries.

In T171027#3484400, @Aklapper wrote:

I don't see "Unbreak now" priority here due to the number of affected users and workarounds available. Please see
https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities

@Johan Yes, at least rowiki and commonswiki are affected, which means that very likely all the wikis from the same group (using the same server) as those 2 are affected. For these groups no workaround has been put in place, so the issue is still a problem for many experienced users.

There is a very interesting suggestion in that discussion that should be taken into account: use mw.wikibase.label. I can confirm that using mw.wikibase.label takes basically no memory (504K with the call, 503K without the call) compared to 42M+ when loading the whole page for tens of countries.

@yuvipanda: Yes, absolutely, I could reproduce it just now. I lauched Strainu's server, then tried to log in as Strainubot and I get a
"500 : Internal Server Error
Failed to start your server. Please contact admin."

@Trizek-WMF, should the deployment of advanced filters to watchlist (planned Sep 5th) be postponed until this is solved? The beta feature is slow as it is, deploying it over this issue might make the symptoms worse for affected users.

It was also reported on rowiki for users with as few as 2K followed pages: https://ro.wikipedia.org/wiki/Wikipedia:Cafenea#Pagini_urmarite

I don't have the time or resources needed to do the investigation myself. Thanks for your help on this, I believe we can now close the ticket.

I'm sorry, but I'm a bit skeptic about this explanation for several reasons:

• ro.wp did not have that peak in July 2016; it had some other peaks which probably account for the slight rebounds in monthly pageviews and which could be caused by the same issue
• it seems highly unlikely that low-level errors would only occur on one page. Despite that, the second most visited page, Search, did not see any spike or drop except normal summer vacations. Nither did the most visited article.

So are you saying that it's just "random" browser traffic that used to be targeted at the MainPage and now it's not? What kind of script could have generated that?

@Nuria, are the stats you show the pageviews for the whole project or for the main page? They don't look anything like the pageviews tool. There is no seasonal variation there, only decreases from March 2016.

Here is an image of the issue. The prefix was 'Tisa ', input text was 'Mara'

Actually, during the review, I noticed a case when the pageimages API call and pageprops return different values, see https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=pageimages%7Cpageprops&meta=&titles=File%3ALasalumic.jpg&piprop=name&pithumbsize=50&ppprop=page_image%7Cpage_image_free

@Framawiki , thanks for the pointer. It seems a bit of an overkill to load all the page properties only for this.

Re-adding @yuvipanda since I believe he was accidentally removed.

In T155538#3490759, @Basvb wrote:

Hi Strainu, whose work are you referring to?

I'm very interested in seeing some of the work you're doing. I've personally invested some time last year to detect monument signs using opencv's templateMatch algorithms, but I haven't followed up recently on this.

@Andrei_Stroe: All translations are available at translatewiki.net. I used 'p' per your suggestion.

@Aklapper, have you tried doing so with a bot account while having a server started on your main account? The bot probably has to have MainAccountBot as username (that's the case for me)

Totally agree with @MotokoCK, whatever path is taken, we would very much like to see this happen fast. More and more users are now going mobile and missing on many announcements from the community. I don't think the requests of ro.wp have changed since I logged this bug. We still need something with the capabilities of Central notice, but configurable locally and which doesn't look like a banner.

CLDR has an entry for ro_MD, in latin script. I have yet to find any difference between that and ro_RO.

In T171044#3453966, @matmarex wrote:

…I suggest that we should just delete this entry.

Yep, perfect, thanks!

Note: the similar change for 'ro' is tracked in T168711

Unfortunately it would seem the diacritics used in the letter headings are wrong. They should be "Ș", "Ț" (comma-below) and instead they are cedilla-below (Ş, Ţ). See for example https://ro.wikipedia.org/wiki/Categorie:%C3%8Embr%C4%83c%C4%83minte

@Urbanecm, thanks for the help, you really moved this forward.

Still no-one willing to do the review?

This is a site request that cannot be approved without cleat consensus obtained on the Romanian wikis first, and not on meta or here. I suggest you open a discussion on the Romanian Wikipedia and invite participation from the rest of the projects if you are really serious about pushing this.

OK, working on the content of the article [[:ro:Francilien]]:

• the article: https://ro.wikipedia.org/w/index.php?title=Utilizator:Strainu/Example1&oldid=11215016
• the introduction as HTML extract: https://ro.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=extracts&titles=Utilizator%3AStrainu%2FExample1&exintro=1
• the introduction as TXT extract: https://ro.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=extracts&titles=Utilizator%3AStrainu%2FExample1&exintro=1&explaintext=1
• the output of my code (which should be similar to the proposed feature): https://tools.wmflabs.org/paste/view/raw/5cb9264f

Any updates on this? Is it currently possible to run code in paws automatically?

@TheDJ : We're good on the numeric sorting, I've updated the patch accordingly

This hasn't been explicitly discussed, but I don't see why not. Will ask and come back as soon as possible (with a patch as well)

@zeljkofilipin , @FDMS: Could you please review this?

It works OK now, thank you for working on this in the weekend.

@leila, @schana I've just seen the survey myself. The text is translated, but the buttons are not. I think something went wrong with exporting the latest translations.

@leila : I updated the translation for Visit survey to use the same terminology as the rest of the translations ("chestionar"). I would appreciate it if you could re-deploy the translations.

{{done}} https://ro.wikipedia.org/wiki/Wikipedia:Cafenea#Chestionar_pentru_cititori

Romanians my age don't normally speak Russian. I kind of find this assumption offensive, especially since I have a babel box on my user page.

In T165540#3337819, @TheDJ wrote:

Eh. Markdown is like the defacto standard throughout the development world atm. (pretty much because it IS still readable even as pure text). Not only in Github, but also in Gitlab, phabricator etc. And lets not forget that we already use it all over the place.

I am personally against using the markdown (and implicitly the .md extension). The code is not maintained in Github, gerrit does not implicitly display markdown and having some weird syntax (however well-known) decreases the readability of the file in command line. I would much rather have it in plain text. With extension or not, that's bikeshedding.

Wikitext, since I need the markup. You can see what I'm trying to achieve at https://ro.wikipedia.org/wiki/Pagina_principal%C4%83 , under the heading "Conținut recomandat". It's the introduction of featured articles, processed using Lua in a very similar way to this extension. The same code is used in several portals to display the article of the day. These are not "classical" extracts, but longer ones, up to several paragraphs, which makes it dull to display without any links to other articles.

I can confirm that uploading a corrected file solved the generation.

@Jdlrobson, we should apply the same algo as for HTML extracts (i.e. no templates, markings do not count towards the number of characters from what I can determine). The idea here, if I get it right, is to obtain a short overview of the article to display in search results and articles list.

Presentation held in the demo session

I haven't seen this in a while. I think it can be closed if @XXN Hasn't seen it either.

During the hackathon we were able to implement a normal bot, as well as a Telegram bot (@clco_tester_bot)

Haha, did a patch myself, but gerritbot did not catch it: https://gerrit.wikimedia.org/r/#/c/354714/

@LegoFan4000 , can you try setting max_retries in user_config? The default seems to be 25, but considering the increasing timeout, it will probably seem like forever (around 43 minutes)

In T153315#3112275, @Whatamidoing-WMF wrote:

In T153315#3004592, @dialmove wrote:

Nice hypothesis you have there. How are you going to test it? How will you test that it matches the expectations of users who enter the Wikitext editor directly? (Which I'd estimate is a majority of experienced Wikipedia editors, the same ones who currently use the classic editor)

That's the $64,000 question, isn't it? I'm not an expert, but it's obvious to even me that this kind of test could be heavily influenced by anchoring and similar effects. You and I have the old wikitext editors as our anchor (as did the editor who formatted the template syntax that you copied), but new editors don't.

It's finally working for me too (no 502, I still need to stop the server on the main account).

I had the same issues in RecentChanges. Do note that while disabling categorisation works, disabling advanced recent changes (aka grouping by page) also makes the problem go away.

Actually, I tagged them just like @Milimetric :)

I've done updates every 2 weeks so far, but there was no progress since 4/6. But I thought there were 5K changes to review? If there are less than 4K (3650?), perhaps that would encourage people to contribute. We've been trying to decode http://labels.wmflabs.org/campaigns/rowiki/48/?campaign=stats , but the docs are not really enough.

Since this bug was submitted, we also have wikidata to worry about, with still more js that can crash a phone. Is there any chance this could be prioritized? Since most people seem to belive the user should be redirected to the mobile version, perhaps it's a configuration issue instead of a software bug?

I was able to make it work after stopping the server on my main account, but now I'm getting a 502 error when accessing https://paws.wmflabs.org/paws/user/Strainubot. Apparently there is an issue with accounts with the same prefix.

@yuvipanda, I get the same error as @Info-farmer on starting the server for my bot account. This is quite annoying, as most wikis require a bot account for pywikibot. I tried logging out and in, different browser&computer etc. I even removed the app from the wiki settings and then re-authorised it, but no change. According to stackoverflow, the 404 on starting the server seems to indicate an issue starting the VM.