If anyone want's to hack on this but needs help finding where to start, whom to speak with or similar – starting this week there is now a weekly Technical Advice IRC meeting open for all volunteer developers: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting

This seems to be about the page: https://de.wikipedia.org/wiki/Gradient_(Mathematik)

I do not observe the reported bolding. It is therefor likely to be browser/operating system dependent, or depending on the fonts that the user has installed.

Please provide complete bugreports, so that people can investigate.

This will be dependent on browser (SVG) engines (but can usually be seen prominently in print previews).

I suspect this can be fixed by updating the configuration of MathJax-node (where the defaults changed a while ago).

@Physikerwelt I can still reproduce this but it seems more like expected behavior.

MathJax's SVG output uses SVG paths instead of text content for mtext elements. This could be changed in the MathJax configuration for mathoid but would require SVGs to be used as inline SVG (instead of using img tags) to inherit the font.

(Also note the bug in the screenshot that does not display the "ü" in "für alle" -- that was probably captured on Chrome where this is a bug specific to SVG text elements loaded via img tags.)

@Pkra is there an option to use the respective utf-8 symbols for mi and mo elements. I think developing a inline svg prototype would be suitable for a hackathon task.

is there an option to use the respective utf-8 symbols for mi and mo elements

No. The paths are a feature of the SVG output and they are an advantage in many situations; the HTML-based outputs use Unicode strings instead.

IIRC SVG output was favored by mathoid because of the advantages given by paths, i.e., they do not require specialized fonts (as opposed to all other solutions).

For completeness, MathJax's PreviewHTML output does not require specialized fonts, but it's still limited in terms of features and does not follow TeX layout rules.

@Physikerwelt I appreciate any efforts trying to improve the math rendering. However I am concerned that any custom Wikipeda solution will end up like texvc: Not working, unmaintained, full of bugs and nobody taking care - for sure not as good as everyone else (e.g. using my old android phone I just see broken image icons in Wikipedia while the client side MathJax rendering on math.stackexchange works perfectly).

Pre-rendered images will never be a good solution, even if they don't have problems with mtext elements. We should use MathJax out of the box once version 3 with common-HTML output is available. We just need someone that updates it now and then and we can be sure to have a working, state of the art rendering system. Then we can spend time on improving that for everyone instead of trying to fix bugs in outdated, inferior custom Wikipedia solutions.

@Debenben Which Android version is running on your phone?

@Pkra kernel version 2.6.29 (very old, I know)

@Debenben Please refer to the respective tickets that explain why WMF decided to use texvc to restrict the input grammar.
I am discussing with @Pkra how to improve the accessibility and visual appearance offline. I would like to focus on the objectives and measurable outputs rather than a technology discussion on a marketing level.

@Debenben thanks. Maybe you can file a separate bug on that with more information (e.g., browser or app version).