Thank you @TheDJ , changing to jquery.textSelection solves the issue.

Thanks for the tips, I must have missed the mobile warning

There is a mention in the description of an "instigating security incident", which is probably the cause for this halt. @greg, is any data about it public yet? Could you perhaps add a link to whatever you can share in the description?

Well, from your mocks I also thought the label will be editable in the pop-up. By the time I tested, I already knew how to expect, but it still felt strange (mostly because the selection was done above the button, which is kind of counter-intuitive)

I just tried in FF 57.0.1 on Linux and can't even select the whole section but that's probably another bug. I have not investigated whether the issue is in the copy or paste step of the process.

@Evad37 : thanks, I wrote a similar module myself last year, but there are two problems with such a module: it needs to be regularly maintained by adding new templates to the exclusion list and it fragments the implementation between wikis potentially leading to slightly different results. Using the same codebase throughout Wikimedia sites seems preferable.

In T124305#4305816, @DLynch wrote:

We do already refer to the link text as "label" in other places -- e.g. a numbered link gets an "add label" button to swap out the "[3]" for text -- that said, if people think it's unclear and needs explanation in this situation, now would be a good time to quickly change that before people spend effort on translations.

No, please go ahead. Thank you.

Based on the comments from the review, I believe we should consider a different approach and since I don't see this as a high priority issue, we can take the time to discuss it a bit.

I should note that I personally considered this page as a fake when I first saw it, because of the encoding issues and Google search form. Users are used to a different level of polishing of pages.

I don't see how fair use has any relevance, since that is not a quote. Regardless, MediaWiki should accommodate all existing uses, especially since this change was made specifically to eliminate the need for the template.

Please note that this bug is causing some issues with AbuseFilter, because it's adding lines which are not really modified to the modified lines category. For instance, this change wouldn't have triggered the filter without this bug.

I see the wiki is now available. What is the process for having accounts on that wiki and what other steps are needed? Thanks

And one more. I seem to remember a brief period when creating your own translation was possible? Was that an experiment or do I just remember wrong? Currently there is no way to do this as far as I can see

I'm familiar with the development process, but I feel that somebody should properly investigate this situation (which is expected for older entries at Wikidata according to a talk page I can't seem to find anymore) and evaluate whether this fix is enough. I don't have the time to invest in that anytime soon, sorry.

Very similar actually. :) {{{0}}} is a generic solution to my problem, making getParent() work an unlimited number of levels is a Lua-only solution. No idea which one is easier to implement.

@Chicocvenancio , I was able to start the bot server while my user's server was on, so my steps to reproduce no longer apply.

Is there a way to know if there are any active wikis using this translation? At the very least, can we check how many users currently use this interface language on any Wikimedia wiki? Without those datapoints, it's hard to see if the effort (and drama, TBH) associated with maintaining this translation is worth it.

Thanks for the correction @Dereckson , wikipedia was indeed a typo from me. I'm not sure why the "i" in romid though?

I would personally prefer romd.wikipedia.org (we often use WMROMD as a short name). @Andrei_Stroe @Giku : any preferences from you?

It definitely needs to be configurable, as the name and location of the template differs. Ideally, it should be enforced at wiki level, with an (optional?) user override. This way new users will automatically follow the wiki rules with no effort from their part.

OK, so I tested with users Strainu, Strainubot and anonymous. The issue about the 500 limit getting lost is only reproducible with my main account, so it's probably caused by some script. However, the fact that the same images are displayed regardless of how many times I click on "older 500" is reproducible each and every time. I have updated the description to reflect this, hopefully you will be able to reproduce at least this part.

@Aklapper, are you logged in? If not, could you please try while logged in? I am unable to reproduce when logged out, so I disabled all user scripts and gadgets and I can still reproduce when logged in.

In T182542#3841603, @Aklapper wrote:

@Strainu: Clearer steps needed:

@Great_Brightstar: none of the examples given by you and others above work for me on mobile - they always redirect to the non-mobile URL.

@EddieGP, we're taking of about 400 pages on Wikipedia and a few dozen on wiktionary. I'm 99% sure that the ro.wiktionary does not have *any* Romanian words with Cyrillic spelling. IMO it's not worth the effort of redirecting articles to same-title articles on the Romanian projects.

In T169450#3836899, @Verdy_p wrote:

The comity can decide what they want. It was NOT requested to *delete* Moldavian but merge it to Romanian. Dropping all Moldavian user contents is very unfriendly and Romanian users should not have any problem if they see the addition of a variant selector in their wiki (and especially for user pages and user talk pages, which is NOT in scope of decision of this VERY SMALL comity which did almost no contributions to these wikis !)

You seem to be behind on the news: the language committee has decided that mo.wp should be deleted, not just closed, following the RfC at https://meta.wikimedia.org/wiki/Proposals_for_closing_projects/Deletion_of_Moldovan_Wikipedia_2

@Verdy_p , where is ro-latn defined and why do you expect it to work?

The transliterator is not active on the Romanian projects.

@Petar.petkovic Having elements overlap for whatever reason makes the page look broken. If there is really no way to solve both bugs, I would suggest that the situation described in T174728 is better than the current one.

I can confirm the redirects work as intended.

@Etonkovidova, thanks a lot for taking another look at those issues, this is really nice of you :) You might have misunderstood my main complaint, though: the bugs seem to have appeared in production due to a lack of testing with the "Group changes" option when introducing new features (labels, wikidata, etc.) and this situation seems to repeat itself for a while already. The solutions I see is to either have a release criteria for RC-related tasks on the lines of "test with option X, Y, Z..." or introduce automated tests that can detect differences between the output of the RC feed with various options enabled and continuously improve the tests when new bugs appear (aka the better regression I was talking about). The latter seems preferable to me, although it probably requires a significant time investment upfront.

In T182156#3823700, @Etonkovidova wrote:

Can you give specific links for ?

And yet, it's been ignored in almost every RC update in the last year - I remember at least 2 other bugs that were only reproducible with that setting.

And yet, it's been ignored in almost every RC update in the last year - I remember at least 2 other bugs that were only reproducible with that setting. Better regression testing should probably be a target, but oh well...

@Reedy , I think that the most important is to know if the Ops team is actively working on a solution for this and if not, when does the team plan to allocate the time needed for it?

Can we get some more details on why such changes would not be desirable? As time passes, chances are that the list of required closures will get bigger.

@Tgr, is WikipediaExtracts deployable or it needs more work?

The voting has started. Please feel free to announce the proposal to your respective communities and don't forget to vote yourselves.:)

I put in the proposal at https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Bots_and_gadgets/Provide_easy_interface_for_manipulating/replacements_in_the_Visual_Editor

It appears to be a bug in their code. The response I got was "You should be able to download any photo with a CC license, there is no special setting for this". I gave them a few examples of files in this situation and they promised to take a look.

In T178961#3711467, @Dereckson wrote:

Okay, so we've two files under CC, one with and one without, so I think the Download photo button is an option photographers can enable or disable.

500px.com is in the exact same situation as Flickr: it is a mix of free and non-free content, has clearly identifiable CC-BY/CC-BY-SA photos and an API to retrieve it. I proposed it because many photographers left Flickr for 500px. While GLAMs and specific sources are good, commercial websites are a much better source of random images. And as you said, the category is already present in the list. My specific interest is in pictures of villages in Romania that we don't have pictures of, but the fact that there is currently no uploader for images from 500px.com should be taken into account as well. I'm sure that once people here about the option, we will see a significant influx of images.

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 <s>the template</s>null). 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.