Alright. So it looks like the last problem is the faulty display of these titles in a page's revision history. It's not a big problem, but perhaps the script could also correct the comments on the revisions?

In T195546#10063633, @Tacsipacsi wrote:

[...] That would allow people to rename pages in advance of the script run (without leaving redirects!) if they want, making the page history easier to understand and saving unnecessary renames.

I let you handle le reste. 😁

One more - https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Contributions/Carlb

[c6563a6a-a79b-4d54-96d6-fa31bb2608b3] 2024-08-14 23:18:13: Fatal exception of type "Wikimedia\Assert\PreconditionException"

There is no "move" nor replacement. There is well-complete external tool that I, as an advanced editor and lot of others, use regularly. And there could be a basic list of the most consulted articles within MediaWiki for the web readers, as available on Android/IOS apps.

I want to see the up-to-date topviews of the year/month/day on a wiki project and I can't without using an external tool or compute a list with a bot/APIs. It's not very accessible.

Thanks @Jdlrobson. I just created T372424 and T372422. I don't know if I can help more. NearbyPages seemed accessible... until the question of making it transcludable. Page expansion isn't a small topic.

In theory, since interface admins can edit the GrowthMentors.json page manually.

Do those changes allow also Interface administrators to enroll users as mentors? (I'm lacking behind with Community Configuration) .

Tool is cool, but it seems not entirely compliant with https://www.mediawiki.org/wiki/Recommendations_for_gadget_developers_on_Wikimedia_wikis

@Jdlrobson what would be the implications if a large wiki (frwiki) adapted a similar approach (dynamic content loaded with API)?

If the only proposed solution is to run chronically a bot and perpetually publish new versions of articles just to fix these URLs, I guess I will handle it on frwiki. Good luck for all the others linguistic editions!

Edit: new day, so the API is not returning the same results (since Wikipédia:Le Bistro/4 août 2024 is not displayed anymore).

Noted, @Dbrant. I will share the answers, thanks. I will look elsewhere for #WPWPRW2024, #WPWPRW, #WPWP.

Some French Wikipedia sysops are complaining about the use of these hashtags, which are also in English. So yeah, tags should replace them (currently in work).

Thanks for the merge @Jdlrobson.
Pinging @Escargot_rouge (e already have a theme-based concern at frwiki).

Thanks for the hardwork!

Do you have an estimate of when this will be resolved? Given the imminent night mode, onwiki documentation needs to be drawn up for contributors. It would be useful to have the class up and running to explain how it works.

Bump. For all the reasons given by @jpxg. This could even be used for other things, such as wrapping requests to administrators that become too long, thus facilitating reading on small screens.

Ping @Escargot_bleu for frwiki.

Sorry for the direct ping @ppelberg. Can you tell me if this functionality is planned in the short term (by the end of the year). If not, do you think it's feasible for a wiki to develop a short gadget to integrate this feature? Are there angles where we need to be extremely vigilant, or is it simply a bad idea? Some discussions are so long that it's hard to read them.

@CCiufo-WMF, as @Jdlrobson advised, frwiki should plan to work on its palette of colors until.

🩵

Because Pageviews is manually moderated. False positives are reported.

@Jdlrobson: I don't understand why the class should only affect SVG. Can you explain me your choice?

Any news? I can import them, I just need approval.

The video about Minerva night mode launch notification design is a good thing. It's certainly very technical, but I think this kind of initiative can help communities to understand the thought process and should be more promoted.

Adding new format options for images could be a solution instead of relying on HTML classes that make no sense to the regular editor.

A class to mean "this image needs a white background in dark mode" is appreciable if it's WMF handcrafted (could be useful in some years if you develop a new theme, etc.), but I maintain that some images don't need a white background, just a invert & rotation filter (as skin-invert) that don't affect the thumb, only the image element.

In T365330#9812920, @Jdlrobson wrote:

The main reason this was created in this way was for French who wanted to the night mode styles but not the infobox styles, and keeping these rules together make sense - as they are essentially a recommended night mode reset file at this point. I'd want to hear from @Lofhi on how this would impact French first.

T364798 is similar, but it doesn't seem to be closely related. One is using the base module JavaScript object, the other one is using OOUI?

Also, per this diff, it seems that you are advising that the communities should never use a white background (meaning using the Codex token preferably).

In T365102#9810018, @Jdlrobson wrote:

You can add notheme in addition to skin-theme to fix this issue. I've improved the guidelines on https://www.mediawiki.org/wiki/Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis#Overriding_night_mode_styles_/_disabling_the_night_mode_theme

Ugh. ~+100 users are importing https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-dark-mode.css&action=raw&ctype=text/css on frwiki. Two editors I came across who reported a catastrophic dark mode had CSS rules that conflicted. New job unlocked for interface administrators I guess.

frwiki is now also using the class .infobox. We should delete .infobox--frwiki in the future, but for now please keep it. The use of the standardized class means that the first introductory paragraph is also be moved on the top on the mobile version, so let's wait for possible comments.

Uhh... Totally missed this ticket. Several weeks ago I asked about night mode or dark mode, and now we have a feature called night mode internally and dark mode for the user... So the dark mode became a night mode in ~october-november and now we have a mix with a small rollback of terminology.

@Jdlrobson, per T351307#9353379, should you name this project night mode? The generalization of night mode is close and this seems to be unnecessary noise.

Eh, I think I hallucinated it from reading the same tickets over and over again...
T320322 adds the support of CSS variables in TemplateStyles.
T355244 adds the support of Codex tokens in in TemplateStyles.
If I remember correctly, the tokens are already available in MediaWiki:Common.css.
The recommandation is to always use a fallback for skins which do not support Codex (not sure it means everything except Vector 2022).

In T363142#9736276, @Theklan wrote:

Is there any working Main page using those?

Don't know if you know what is Codex, but you can reuse the Codex design tokens in TemplateStyles or CSS page content model (i.e. MediaWiki:Common.css).
https://doc.wikimedia.org/codex/latest/design-tokens/overview.html

Met one yesterday too on frwiki, but I confess I didn't think it could be a bug?

Damn, I had put my piece on the HTML comment, not the categories! I also think I was able before with this same wikicode layout to reply from the main page (the "faulty" version was the version of the page used since 2020), or at least open the reply tool. Except I can't say for sure.

Reproductible on my side.

Tried with "real" title of sections (i.e. == Test ==) and it didn't change anything. getThreadItemsHtml from the API put the HTML-comment in "othercontent" (which is good). So, somehow, this edge case fails within CommentParser.php in computeTranscludedFrom.

@Escargot_rouge, c'est bon.

Since I reported the problem, I've encountered it less than ten times. That's still 10 cases where the anchor is broken...

I'm just discovering that scope are not added with the Visual Editor, nor that it's easily possible to add them without switching to the classic editor. On frwiki, the community relies on a gadget to detect this type of inaccessible table. The impact is quite significant: we continue to generate inaccessible tables that have to be corrected by hand.

In T359644#9728041, @Jdlrobson wrote:

Anyway, thanks again for getting us to where we are now! It's definitely looking a lot more optimistic than it was a month ago so I want to make sure you know I appreciate your efforts in this space! I know consensus is hard to build!

So we haven't agreed on an approach yet but we have two options we are considering:

1. we target .infobox---frwiki. The benefit of this is it targets French only, the downside is all projects would get unused CSS and it wouldn't help other projects e.g. say italian adding infobox--it.
2. We target any class beginning with infobox-. The benefit is we could recommend other projects other than French follow suit, but on the downside code is less readable.
3. We target any class beginning with infobox. The benefit is we can minimize CSS rules. Downside is it would match infobox_v2 and infobox_v3 here (but it sounds like they already have infobox--fr so maybe that's okay?)

Does that make sense?

In T359644#9726811, @Jdlrobson wrote:

French Wikipedia should still work towards adding the infobox class on all its projects. If that's not the goal we need to talk and make sure we're on the same page :-). If all projects standardize to have the infobox class it's better for bots, screen scrapers (and thus SEO), crawlers, APIs, MobileFrontend etc.. as it allows all these things to identify what the infobox in the page is.

My understanding was that the reason French Wikipedia doesn't use the infobox class is because:

1. it dislikes the alteration of appearance that occurs via skins.minerva.content.styles/hacks.less
2. It believes the infobox should be at the top of the page e.g. we should disable MoveLeadParagraph.

In T359644#9724906, @Jdlrobson wrote:

@Lofhi French can also now adopt the infobox class and disable the styles associated with infoboxes if they want to use their own using the approach outlined at https://www.mediawiki.org/wiki/Extension:WikimediaMessages#Disabling_styles - I'm not 100% sure what was the outcome of the discussion @Trizek-WMF was having with Od1n on https://fr.m.wikipedia.org/wiki/Wikip%C3%A9dia:Questions_techniques/semaine_10_2024 but if that's a possibility that would fix this much quicker (days rather than weeks).

Hello, can you check if the file is filled properly on Commons? Thanks.
https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_appearance.svg

Some discussions about removing or not the uses of __NOTOC__ on frwiki articles in the main namespace : https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Sondage/2024/Supprimer_tout_masquage_de_la_table_des_mati%C3%A8res_dans_les_articles

.infobox--frwiki is now used for every infobox (ref).

In T361508#9707623, @CCiufo-WMF wrote:

I like the spirit of this, but there are no specific WCAG compliant colors. Rather, it's the contrast between colors that make them compliant or not. This is why we lean on decision tokens, since they come built-in with guidelines on how they should be used together, to avoid accessibility concerns.

The idea is rather as follows: for a proposed text color, also propose a background color with an acceptable contrast ratio.

No answer and the "image dimming" (not directly related of the initial report) is a official supported and customizable feature of the app, closing.