The translations are good, but now I'm a bit confused at what we're trying to achieve. Looking at the diff vs the current output (see screenshot), it looks to me that the old version is closer to what we want. I believed that the sections are fixed, but if they're fully customizable, I would suggest that knowing how to edit and how to work with images is far more important than uploading an image (especially the cross-wiki uploader that is offered by the visual editor). I propose the json below. @FonAfon do you have an opinion on that?

Yep, sounds good.

@Trizek-WMF Does it need to be a local page? We haven't figured out the help pages completely, but VE has pretty good help pages on mw.org and I preferred to translate those rather than creating new pages.

In T274778#6831759, @Aklapper wrote:

The logos I get are https://ro.wikipedia.org/static/images/project-logos/rowiki.png and https://en.wikipedia.org/static/images/project-logos/enwiki.png .
Screen resolution on this one 1960x1080, scaling is 100%.

Looks like a good plan. :) Let's work backwards from it.

Meh, sounds like pngs are difficult. If we had vectorial logos we could convert them to pngs and reasonably expect the result to be similar regardless of language.

Does this mean they should be deleted from the wikistats table?

I hit the same problem just now. Any updates on a possible solution?

The advantage is the formal correctness of the output. The disadvantage is it will break things in templates (well, might, but this being Wikimedia it's almost a certainty).

@Huji beware that you cannot be notified in wikis where you don't have an account (e,g. ro.wp)

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.