Thank you for solving this @TheDJ.

@Aklapper, this discussion is not very productive, so I suggest we end it here. I understand you need to follow your checklist but I still maintain that the original description was perfectly actionable. Can we now return to discussing the bug please?

@Aklapper It's trivial to create a repro casefrom the instructions:

<maplink zoom="16" latitude="44.43237" longitude="26.13845" text="[[Fișier:Information.svg|15px]]">
</maplink>

Sorry for nagging you folks, but patrolling wikidata is becoming increasingly important and doing so from my home wiki is just so much easier (if it works). I would very much appreciate it if we could find a solution to this problem in a timely manner.

In T155456#5968422, @Aklapper wrote:

@Strainu: The request is to provide clear steps to reproduce, step by step, which don't leave room for interpretation, and potentially also a full URL where to see/reproduce that problem. See https://www.mediawiki.org/wiki/How_to_report_a_bug - thanks!

In T155456#5966153, @TheDJ wrote:

this ticket needs the context that triggered it added

@Bugreporter could you please take a look at your code? It would really help with patrolling if the bot's changes are properly marked as bot-made.

Thanks @Jdlrobson you suggestion worked with minor changes. If you also have suggestions for the bottom 2 sections (categories and other projects) which render badly, it would be great. :)

We definitely need more time to fix this at rowiki, since apparently I'm the only one with both the knowledge and access to be able to fix the main page and I currently don't have more that 5-10 minutes at a time to devote to wiki. I would appreciate it if you could push back the deadline to Jun 2nd or later in the hope that I will be able to look into the design on a national holiday.

In T243701#5884801, @Ladsgroup wrote:

I have been thinking about this and I think I have a suggestion. bots and tools, should respect maxlag before it reaches the threshold. We need to return the value of the maxlag in the API as well but tool developers should check the maxlag, even if it's 3 or 2 seconds, then wait for that amount and make the next edit after that (or just sleep exactly after the edit is made). This way they slow down before "they reach the threshold and then have to back off the let go back to normal and then they start the flood of edits again and so on and so forth."

In T243701#5834731, @Addshore wrote:

Should tests be using the production api and site?
What are these tests doing?

@Jrogers-WMF @Urbanecm I've implemented suggestion 2. The bot is set to run daily. A test message was posted at https://ro.wikipedia.org/wiki/Wikipedia:Afi%C8%99ierul_administratorilor#[Test]Recuperare_nerealizat%C4%83_de_un_administrator - it's for a real operation made by a user who no longer has sysop rights, so you can check the links work.

Unfortunately abusefilter seems to only handle article deletions (not even undeletions, let alone revision visibility)

In T234051#5582768, @Jrogers-WMF wrote:

That said, could you tell me what kind of review there would be for a policy against undeleting by patrollers? If violations of that policy would be noticed fairly quickly, I think that would address the concern because they'd be given the right only for helping to clean up content, but if an undeletion might go unnoticed for a long while, I'd be more hesitant.

In T234051#5578226, @Jrogers-WMF wrote:

Hi all. A couple thoughts. I note from the original ticket that there's a note that patrollers were all selected through an RFA style process, which would satisfy the need for community review before giving people rights. It's not clear to me from this thread if that's the process for all patrollers or if it's just coincidence that it applies to all patrollers right now. If the latter, I would suggest that you formalize that the process to get patroller rights requires a community review and then this is fine.

As far as I understand from docs and throughout the code, the ability to see the deleted content is actually controlled by the 'deletedtext' right, not 'deleterevision'.

@DannyS712 I can't find any such policy on meta. Could you please provide a link with the mentioned requirements?

Ah, I think I found the original issue: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/533482/ (T221812)

In T233392#5512600, @Dvorapa wrote:

What about internamespace redirects?

In T214230#5482731, @AlexisJazz wrote:

Enabling a feature that causes this much of a mess is not a solution for anything.

Disabling cross-wiki uploads instead of working on new tools to help curate and cleanup those files is a huge step backwards for the good faith newbies who want to contribute pictures to articles.

@Urbanecm thanks for noticing, I uploaded a new patch.

@Tulsi_Bhagat sorry for not claiming sooner, I already have a fix for it.

In T230185#5415997, @phuedx wrote:

When saving, I was not given the option to see or edit the section in the summary.

Did you see the "Previewing <foo>" overlay? If so, then it sounds like the API request to generate the edit preview failed silently. If not, then this is a serious bug.

I think you should use July, not June data, if you plan on running the survey in July :)

@Isaac , I believe the approach you took to calculating the sampling rate is misleading and you might end up with a low number of responses, at least for Romanian. Since you extrapolate directly based on 2017 data, you seem to assume the differences in pageviews between May 2019 and June 2017 are all due to the normal evolution of the wiki, with no seasonal variation. However, looking at the available pageview data for ro.wp ( https://stats.wikimedia.org/v2/#/ro.wikipedia.org/reading/total-page-views/normal|table|all|~total|monthly ), one can see there is a decrease in PV each June on the order of 15-20%, followed by another decrease in July of more than 20% compared to June. These are caused by school recess, people taking vacations or simply going out more and will likely affect your potential audience.

This is also happening on ro.wiki since I enabled it in InfoboxSettlement. As more and more pages use mapframe, we will need a solution, so trying to raise priority.

Wrong PD license on flickr.

In T52399#5038992, @Krinkle wrote:

The user story as I understand it is as follows: The user is on a desktop device and intentionally browsing the website via the m-dot domain to use the Minerva skin. They then follow an "external link" to the same wiki, and which to remain in the same mode (e.g. mobile mode).

@Etonkovidova this has nothing to do with VE. The bug was reported on CX v1, which had no common code with the VE as far as I can tell. If it does not appear in v2, it can probably be closed.

In T178961#4917934, @Liuxinyu970226 wrote:

@Strainu To avoid DDOS attacking, I would really love to confirm that, are the source codes that powered this site free licensed? If yes, which license? GPL? MIT?...
If not, then I would still oppose it, as per T211464#4808574.

Looks like VE believes that this is an inline template. See if this change helps: https://en.wikipedia.org/w/index.php?title=Template%3AInfobox_economy%2Fdoc&type=revision&diff=878588064&oldid=854770844

In T86151#4842911, @Pginer-WMF wrote:

the old one will be deprecated soon

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?