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

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.