I am still planning to enable intent in the future. Maybe we can keep a record of the intent-related features we remove in a dedicated ticket?

Do you have the url from which the first screenshot was taken @Christian1985

@Christian1985, is there any difference between \prime and '? If not, we could convert \prime to ' in the checking phase.

@Christian1985 do you know the name of the discussion extension?

It could do eventually but for now we're keeping all the checks inside /editchecks as it's still in early development.

@Christian1985 send an email to math user group https://lists.wikimedia.org/hyperkitty/list/math@lists.wikimedia.org/thread/LIDZOZIMMA6OXXXRH2UPZEKP2UJYELT6/

It works on testwiki

Thank you @FrederikHennecke1

Unfortunately, this is still open. https://codepen.io/physikerwelt/pen/RNGQpdv shows that adding accent=true destroyed the fix

MathJax needs tex class PUNCT here see https://codepen.io/physikerwelt/pen/vEXdmgq

@Esanders Do you think it could be possible that the extension js is not loaded?

Seems to work

Interestingly enough this are two separate bugs. MathJax needs to have the option stretchy=false set, and for native browser rendering we need to do the scale trick.

Unfortunately, this is not related.

I mean we can also remove the tests here. I am moving test generation code to MathSearch in T412658. The tests with all strings used in enwiki (which are very useful indeed to find seldom problems, which are reported as "production error" otherwise) could be moved to MathSearch as well.

Maybe this also causes T362091

It would be even better to find a way to get the files

I would guess that

It is somehow a bit different locally. I'll abort that and try https://github.com/wikimedia/integration-quibble/blob/master/doc/source/build-reproduction.rst instead.

I think it works by accident for the images generated by the SVG rendering mode. https://www.mediawiki.org/wiki/Help:Formatting/de links to the https://phabricator.wikimedia.org/T309778 . I think that's the problem to be solved here.

@Christian1985 thank you. I think it should not block us to move to client-side MathML rendering as default rendering.

Maybe we should find a way to make this reproducible?

This does not seem to be related to MathJax

See https://de.wikipedia.beta.wmcloud.org/wiki/Intbar

@Dginev posted a solution in https://codepen.io/dginev/pen/bNbbMmb

I started looking into it myself and it seems that the error might come from the step that edits the phpunit.xml so even before the problem that is caused by not using the new composer based entry point.

@jnuche thanks for the prompt reply. I'll find another reviewer.

@jnuche would you be able to review the suggested change?

In T268935#11725917, @Izno wrote:

Why would this be obsolete? There are some 20k instances on English Wikipedia articles alone (which is about half of all articles using <math).

There was a long discussion about display / block which dates back to 2015, but it seems that nothing was implemented after all.

Maybe this is obsolete?

Ok for me. https://marketplace.visualstudio.com/items?itemName=Naela.latex-shortcuts uses m as well. https://www.notion.com/en-gb/help/math-equations goes for e. I was under the impression that we already had a keyboard shortcut for VisualEditor but I can't find it at the moment.

Is what you're suggesting basically a shortcut to enter <math display="inline"> and <math display="block">? Perhaps Ctrl-m for inline, and Shift-Ctrl-m for block?

One option i see is to borrow the temml.org hack and apply

.tml-vec {
  transform: scale(0.75);
}

to the arrow. Not sure what do do in MathJax.

@Christian1985 what do you think, should we decline this?

https://de.wikipedia.beta.wmcloud.org/wiki/Intbar#Grenzwerte

https://de.wikipedia.beta.wmcloud.org/wiki/Intbar#Zweistellige_Operatoren

The default (legacy) rendering of math is a mix inline and display rendering. So for new math either inline '\(' or display '\[' rendering should be used. This is controlled by the display attribute which can be inline or block. If the display parameter is omitted math is rendered as \({\displaystyle so it generates large operators within the current text line. The reason for that is that traditionally formulae were placed on a new line with a colon :<math> However, that does not generate valid HTML with modern wikitext engines. See https://www.mediawiki.org/wiki/Extension:Math/Displaystyle for additional details.

https://www.mediawiki.org/w/index.php?title=Continuous_integration/Tutorials/Generating_PHP_test_coverage_for_a_MediaWiki_extension&diff=prev&oldid=7020917 vs https://github.com/wikimedia/integration-config/blob/96ead6520ecdab9e49e44ca76a48d884569d7438/dockerfiles/quibble-coverage/mwext-phpunit-coverage.sh does not hint at any obvious problem. Try to make the local coverage test fail as next step.

I had the problem before when generating coverage locally. I documented the fix in https://phabricator.wikimedia.org/T378434

Still a problem https://integration.wikimedia.org/ci/job/mwext-phpunit-coverage-publish/51824/console

17:16:19 ..........                                                    3365 / 3365 (100%)
17:16:19 
17:16:19 Detected 4 tests where the duration exceeded the global maximum duration (0.100).
17:16:19 
17:16:19 # Duration Test
17:16:19 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
17:16:19 1    0.470 MathParserIntegrationTest::testParserCacheIntegration
17:16:19 2    0.278 MediaWiki\Extension\Math\Tests\WikiTexVC\AllTest::testRunCases with data set "Big" (array('\big(\big)\big[\big]\big\{\bi...r\uarr', '{\big (}{\big )}{\big [}{\big...rrow }'))
17:16:19 3    0.224 MathParserIntegrationTest::testMathParserOption
17:16:19 4    0.109 MediaWiki\Extension\Math\Tests\PreferencesIntegrationTest::testMathOptionRegistered
17:16:19 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
17:16:19      0.000
17:16:19       └─── secondsKey "JobTypeConf" not found in input sources
17:16:19 + set -e
17:16:19 + '[' -f /workspace/log/junit.xml ']'
17:16:19 + phpunit-junit-edit /workspace/log/junit.xml
17:16:19 Traceback (most recent call last):
17:16:19   File "/usr/local/bin/phpunit-junit-edit", line 66, in <module>
17:16:19     main()
17:16:19   File "/usr/local/bin/phpunit-junit-edit", line 44, in main
17:16:19     tree = etree.parse(args.junit)
17:16:19   File "/usr/lib/python3.9/xml/etree/ElementTree.py", line 1229, in parse
17:16:19     tree.parse(source, parser)
17:16:19   File "/usr/lib/python3.9/xml/etree/ElementTree.py", line 580, in parse
17:16:19     self._root = parser._parse_whole(source)
17:16:19 xml.etree.ElementTree.ParseError: no element found: line 1, column 0

In T387924#10603802, @Ejegg wrote:

I've looked through the integration/config repo and I don't see any php8.2 version of the coverage job defined yet. We could just comment out the failing jobs for now at this line of layout.yaml: https://phabricator.wikimedia.org/source/integration-config/browse/master/zuul/layout.yaml$4231