In T306246#8008801, @AlexisJazz wrote:

because nobody wants images from the bad image list to show up in search results.

I am… getting impatient enough to ask: how hard is it to, really, just make our own statically-compiled rsvg-convert binary into a deb package and then deploy it? I mean:

The font-family may encode not only the font family, but also the font-style or the font-weight.

For showing the original source on hover, we can maybe instead just display the a trimmed tree down to the base ref (in the beta extends proposal). That is, for:

Bit surprised to see the book-reference / extends system cancelled after all the advertising on Template:rp and such. Ouch. Should’ve went to the vote.

Some scattered suggestions, wishes, and questions.

Subscribing in case someone makes a comment about a bot being made available.

Appreciate the heads-up, but I am pretty sure the very relevant follow-up would be: which version is Debian stale on? The hesitancy of the team to even backport testing/unstable source packages has been a persistent roadblock to us getting good things.

Putting a +1 here because someone on zh.wp telegram group asked for a way to not list navbox-introduced links. I agree that these links don't make sense to be counted and add unnecessary noise to "most wanted" and similar stats.

At least the 2.51.1 result makes more sense and works in non-extreme scales...

Every time I hear a librsvg bug, I can't help but ask: "is it a Debian stable librsvg bug or an actual librsvg bug?" (urgh) And indeed, a quick test using rsvg-convert from libsrvg 2.50 shows the red and black text on the last line overlapping fine.

In T50032#6979865, @Physikerwelt wrote:

Package inputenc Error: Unicode character 甲 (U+7532)(inputenc) not set up for use with LaTeX. $\sin(甲

FWIW, it seems that texvcjs, not MathJax, is the one blocking the characters from mathoid. The problem is in turn thrown from pegjs.

For those curious about KaTeX, you can use it with the JS below, either in common.js or from a brower userscript:

This issue also affects wikis using a black background by default, which is... a lot of video game wikis. Let me describe the T279181 issue in more detail:

I agree that it's a dupe of T111222. I think it's invalid status... right?

Heredoc looks nice for its consistency and general-ness, but I do hope we come up with something for LISTGAP. The definition-list is still a very bad idea, but then we can also just use ** <<< now.

Agree with the Quiddity bold suggestion. The "indent" name is very unfortunate.

Converted the additional observation to notes. Did some reading in the source, and I think it's could be a librsvg bug or a misconfiguration. Either way, this can be worked around in the environment.

1. The rasterize() part of SvgHandler.php seems to set LANG only when there is one. That makes sense.
2. librsvg falls back to LC_MESSAGES then LC_ALL [[https://gitlab.gnome.org/GNOME/librsvg/-/blob/2.40.21/rsvg-cond.c#L145 |when there is no LANG]]. That is not really a bug.
3. librsvg falls back to en when the locale [[https://gitlab.gnome.org/GNOME/librsvg/-/blob/2.40.21/rsvg-cond.c#L148 |is exactly "C"]]. This is very not good. And it's fixed in their Rust version because they used a locale_config crate that doesn't do this.

okay, editing the bug now.

I disagree with the merge. This report is related but not identical, since the SVG Tool is not part of MW proper. Instead there should just be a reference to each other.

Appears to be affecting the example presentation of multilingual images on a Commons template. See https://commons.wikimedia.org/wiki/Template_talk:Translate#New_Template%3A_Multilingual_Gallery.

I would recommend a post-processing for PNG thumbs by way of color reduction to 256. This usually gives a very signification reduction in file size at little cost to quality for drawing and text content. In ImageMagick, this is done by prefixing the output file name with PNG8:. Their handling of transparency is not good, but documents don't have that issue.

Yes, make this task about -sharpen on JPEG then. Editing.

Currently the enabling/disabling of the availability of language converter is made across the entire wiki, however it might not always suit every needs.

The autoprefixer thing using caniuse looks good. -webkit-text-emphasis is especially a pain in the alias for Chinese/Japanese, as 71% of global users only get support via this prefixed version. Chrome, ya know.

I made a quite mention to Ctrl-F'ing the source for $props in https://www.mediawiki.org/wiki/Help:TemplateStyles#What_CSS_rules_are_recognized?, so folks can at least know how to find a list.

By the way, is the IPSet ($proxyListIPSet) always created anew when User::isLocallyBlockedProxy is called? I am not sure what to make of that...

There we go, I guess. Simple as mw.language.findVariantLink(link : string) -> string.

I was trying to introduce Wikidata-based annotated link to zh.wp the other day, and mw.wikibase.getEntityIdForTitle was not working too well for this exact reason. Anyone want to triage this task?

I partially agree with calling this GIGO too. Those sort of things are not supposed to appear in pages anyway.

I am thinking about using some preprocessing for Hans/hant -- we can flatten the text to one of the variants (character-by-charcter; no word based things so it is more predictable) and then perform the match.

Sorry for the late reply.

和（he2）by itself typically means “and”, so please treat it as a stop word as it is. Do not attempt any filtering on it.

There are some precompiled zh-pinyin database at https://github.com/mozillazg/pinyin-data (MIT license, although the Unihan derivatives may be taken otherwise), as well as for phrases (https://github.com/mozillazg/phrase-pinyin-data).

A thing @Shizhao has voiced concern about is the data overhead caused by "unconditional" loads as opposed to skin attribute-defined loads, per https://zh.wikipedia.org/wiki/Wikipedia_talk:%E9%A6%96%E9%A1%B5/styles.css. This might be the rationale behind T197617#4439270.