Yes, the scrollbar remains visible for me.

@Aklapper indeed this seems to happen only when activating Twinkle. However, I believe this is just a manifestation, not the root cause: the same result is obtained by reducing the width of the menu or increasing the number of characters in one of the buttons. I believe this shows the issue is not linked to the desktop improvements, but rather on when is the "hiding" script run.

In T248418#6357064, @Iniquity wrote:

Blockers, I think:

• T258644: VideoJS audio player start button is misleading
• T258622: Poor display of media on Special:NewFiles
• T249249: Loading indicator renders in the top left corner instead of centre

I've seen this and I considered this a feature, not a bug, because it allows the user to see the video capture better. Anecdotic evidence from a discussion on ro.wp seem to suggest I'm not the only one. Seeing the videJs player vs the previous one, people reacted with "ah, that's slightly better [for infoboxes]"

15 years ago the community and the rules were different. You'll need some kind of consensus with the current rules and people.

Please note that rowiki does not have local checkusers since 2015.

It appears to work now: https://ro.m.wikipedia.org/wiki/Special:MobileDiff/13465214

Unfortunately we're too late: https://www.theverge.com/2018/7/1/17521456/500px-marketplace-creative-commons-getty-images-visual-china-group-photography-open-access

@Krinkle I was specifically asking about the visible data, such as the table with the CPU time and the lua logs. This bug was created when the logs had vanished because of the email linked in the description. They then reappeared, which made the bug less important. I would like to know how will we be able to access the Lua logs in the future.

@Krinkle just to clarify, will the current data shown at the bottom of the pages still be available or not?

In T129108#2110864, @lfaraone wrote:

I imagine for most purposes the auditability of the deletion log prevents abuse here. The amount of work involved to implement this request correctly makes me sceptical that it's worthwhile.

@Alicia_Fagerving_WMSE is this still an issue? Can I be of assistance?

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 case from the instructions: take any maplink and put a file in the text attribute.

<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.