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?

Removing myself as the Math(Search)? part is done

The parser splits the align cell between \int and \limits. Thus

<math>\begin{align}
{\int\limits_\mathrm{momenta}}
\end{align}
</math>

renders fine

Minimal example:

<math>\begin{align}
\int\limits_\mathrm{momenta}
\end{align}
</math>

fails error and limits is printed on the screen whereas

<math>
\int\limits_\mathrm{momenta}
</math>

renders fine

Maybe this also applies to extension MathSearch?

I also saw that when testing with docker T362030. However, I didn't find any match for JobTypeConf in the math extension.

Yes, it should. I don't know how. Maybe this is not even possible within extension.json and needs a special hook.

That makes perfect sense, as I don't run wikibase tests locally.

The only problem I see locally is the problem with dynamic property creation T314099.

There are 700 more problems. As it is triaged as unbreak now, maybe reopening this issue is not the right thing to do, but I guess sooner the problems will pop up.

@mmartorana can you share the raw output linked here with the MathJax team or link it from this ticket.

Thank you @mmartorana . @Jdforrester-WMF would you mind looking into the linked patch again, or should I search for another reviewer?

In T182041#9145058, @Physikerwelt wrote:

@Stegmujo what do you think of a public demo?

In the meantime, you can test this on any WMF wiki. https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering select MathML rendering mode.

It seems only a problem for math images. With the new rendering, I don't see the problem

In T358966#9662683, @Daimona wrote:

Thank you. I am convinced eventually, and I tend to run composer fix before each commit :-) Maybe the documentation could be reordered according to the structure of the PSR-12. Even if we have another convention for some aspects like 2.4, use tabs, not spaces.

For our project, we solved it by overwriting the name https://github.com/MaRDI4NFDI/portal-compose/commit/f10c191a7899a43b4c68e0ec8ee986460fefb65d . Would it be helpful to back-propagate this fix to https://github.com/wmde/wikibase-release-pipeline/blob/main/example/docker-compose.extra.yml ? If so, I can make a pull request.

@Daimona, while risking getting a bit off-topic, let me add one more comment: I think it would be better to adopt well-established rules instead of switching on or off inspections on a case-by-case basis. For example, if you have reserved one hour a week to work on Wikimedia-related activities, spending half an hour dealing with this new rule is quite a significant investment of time. Maybe I also overestimate the impact of that change. So maybe a good practice would be to accept all sniffs from the upstream code-sniffer and lower the warning level for the new rules that create problems. The change https://gerrit.wikimedia.org/r/c/mediawiki/tools/codesniffer/+/1008057 suggests that we act on a case-by-case basis and also I could not find in the documentation what upstream sniffer ideas we follow.

Ok. Do you think it is good enough to wait until then? If so we can maybe make this task a subtask of the migration of production migration task.

@Jdforrester-WMF did we eventually drop support for PHP7. If so this might be easy to fix, by upgrading the library that generates the code that produces the errors.

Thank you @Amire80 .