I suggest accepting that those corner cases are no longer supported.

We accept that only the start of the problem is given.

@Pppery, thank you. If you had access to https://logstash.wikimedia.org/goto/686d5921e518f09de649a8bbc8ff1c0c you could maybe check if more wikis are missing in restbase.

The MathML rendering was implemented.

This is now possible with MathML rendering (not yet default)

^^ that wiki doesn't have any math tags https://btm.wikipedia.org/w/index.php?search=insource%3A%2F%5C%3Cmath%2F&title=Husus%3APencarian&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns710=1&ns711=1&ns828=1&ns829=1

@thcipriani, can you create a list of wikis where this problem persists? It seems for those, the connection to restbase is broken. See for example here

I guess this is fixed, please reopen if not.

OK. Here the problem is that invalid user input might lead to a logged exception. The error should be caught as it is expected behavior.

In T18491#9954070, @Ladsgroup wrote:

@Physikerwelt Hi! This proposal (T18491#9950713) is really similar to how math extension works. I wonder if you have some insights about this.

I am changing the status to invalid, as the task was worked on (for months) but not completed in a measurable way. From previous discussions with @Aklapper I understand that investing effort alone doesn't justify resolving a task. In that sense, I am now getting the impression that this is more a discussion thread than a task with a measurable outcome.

I think the discussion up to now was very technical and detailed.

Could you please elaborate on how consensus was achieved to resolve this task? So that I can learn how to reach consensus for changing the status to declined. I could not find this information here.

It seems that the community feedback was rather ignored than taken into account. Thus I think decided is a better status for this task.

Thank you.
I still don't fully understand what will happen to

In T365112#9921762, @Jdforrester-WMF wrote:

This can still be triggered in wmf.11, e.g. https://test.wikipedia.org/wiki/Special:MathShowImage?hash=9ab0347369b93587a1fc8dbd6c6a8862&mode=5 ->

We have now prepared the Math extension for Restbase sunsetting. However mathoid will remain stateless and be discontinued eventually.

This patch did not help.

this should fix it.

Thank you. This is very helpful. I think one of the problems is that we are also writing to the wiki simultaneously.

MariaDB [(none)]> SELECT table_name AS `Table`, round(((data_length + index_length) / 1024 / 1024 / 1024), 2) `Size in GB`  FROM information_schema.TABLES where table_name like '%links' order by (data_length + index_length) desc;
+---------------+------------+
| Table         | Size in GB |
+---------------+------------+
| pagelinks     |      22.43 |
| externallinks |       9.92 |
| templatelinks |       7.45 |
| categorylinks |       0.09 |
| iwlinks       |       0.01 |

And it is a bit faster than originally expected. So maybe only 6 days.

In T366220#9904149, @Jdlrobson wrote:

When MathML is enabled, yes.. but not for anonymous page views.

I am running MW 1_43-wmf9 and started running update.php yesterday night. It seems that the updater is very slow (running migrateLinksTable on pagelinks). I now started to run this migration in a separate process. Do you have any idea how long the migration might take? My first estimation is 12 days for our 12M pages. This seems very slow, does that make sense?

It was shut down for a while and has now been deleted.

As I did deploy the MathSearch extension on quite a few instances, it makes sense to add a patch. From looking at the Translation patch, I guess it would SET foreign_key_checks = 0; before running the updater and reactivate it after it is completed.

The temporary problem vanished.

There are only very few people who have access to mathoid-mathjax on npm;-)

Tests on https://www.mediawiki.org/wiki/Extension:Math/T366983 show that it does not even reach mathjax.

In mathoid, we use mathoid-mathjax. The code can be found here https://www.npmjs.com/package/mathoid-mathjax and here https://github.com/wikimedia/mediawiki-services-mathjax. It was forked from mathjax2.7, and is not (yet?) migrated to gitlab per T348384 .

Thank you, @cscott, for the quick review.

I am considering implementing a prototype for this (as part of the non-WMF deployed extension MathSearch). I am worried this might cause a heavy load on the current SPARQL endpoint backed by blazegraph.

@MSantos can the Content-Transformer-Team review the proposed solution (demo) ?

@MikhailRyazanov Does https://en.beta.math.wmflabs.org/wiki/User:Admin look as expected.

In T182041#9872844, @MikhailRyazanov wrote:

I suppose that you have access to the source code and test builds, so maybe it will be more productive if you try to implement the change and then share the results here and with those who can test for accessibility issues?

Thank you this is perfect for defining the goal. I would personally prefer if formulae were centered (or indented).

Yes. One or two formulae are enough. I used https://jsfiddle.net in the past. You have live preview and it is easy to share the result.

@MikhailRyazanov I suggest we continue the discussion about :<math> at T111712 and (T268922 summarizes the current status).

I did propose <dmath> when this feature was originally developed. However, it was not supported by anyone, thus I had to drop it. We can add dmath as an alias for math display=block if that is useful. However, this is offtopic here and should be a new issue. Keeping the long standard form seems to be a good idea to me, though.

This ticket was super helpful.

In T366220#9847941, @Jdlrobson wrote:

When we switch to MathML (T271001) this will not be a problem and we may want to consider undo-ing this rule .

It seems to not happen on en https://en.wikiquote.org/wiki/Special:MathStatus . Maybe there is a difference in the restbase config for those URLs.

In T363081#9835863, @Malparti wrote:

@Physikerwelt I've found another work-around that does not require mixing the rendering (namely, use \mathrel{\overset{d}{\longrightarrow}} instead of \xrightarrow{d} in the LaTeX code).

@Malparti Thank you. Now, the problem is clear. I also created a test page https://www.mediawiki.org/wiki/Extension:Math/Bug:T363081. It seems the calculation of the size of the image is incorrect, while the actual rendering is correct https://wikimedia.org/api/rest_v1/media/math/render/svg/c39ec41d3916a57b0702237a4eddb3e529da0e11.

It's a bit complicated as there were few tests, and the parse tree was more complicated than it should be. I imagine the production error does not impact a lot of people, thus I would rather take the time to fix it properly.

Likely related to https://phabricator.wikimedia.org/T362344

Sorry, my local copy of the integration config was outdated... php8 tests only run when running check experimental and the behavior is the same for all extensions... so we can just wait until the PHP8 tests run by default

Reopening, as it was still disabled. See for example https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/1035851 it failed only in the gate-and-submit phase because the php8 tests were not run in the test phase.

Thank you. Is this the equation

Unfortunately, I can not see the screenshot. Can you guide me to the section, please?