User Details
- User Since
- Oct 24 2014, 1:27 PM (508 w, 2 d)
- Availability
- Available
- IRC Nick
- physikerwelt
- LDAP User
- Physikerwelt
- MediaWiki User
- Physikerwelt [ Global Accounts ]
Yesterday
Thank you, @Lucas_Werkmeister_WMDE, for the fix https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseLexeme/+/1055401 . Maybe you can link this ticket?
Fri, Jul 19
As announced on the mailinglist. gerrit will continue to exist. Thus, it's probably best to only use gitlab for mathoid, which has an elaborated build process. Moreover, all of the above will not be developed further.
Thu, Jul 18
Wed, Jul 17
Tue, Jul 16
I don't understand the patch. Would that interfere with our intention to switch to native MathML rendering by default?
Fri, Jul 12
Thu, Jul 11
Thank you. It would probably be too much effort to create restbase tables for all of them. With the merged patch, no new log entries should be created.
Thu, Jul 4
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)
@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.
Wed, Jul 3
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.
Fri, Jun 28
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.
Tue, Jun 25
Thank you.
I still don't fully understand what will happen to
We have now prepared the Math extension for Restbase sunsetting. However mathoid will remain stateless and be discontinued eventually.
Jun 19 2024
This patch did not help.
this should fix it.
Jun 18 2024
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. (Edit: It was actually much faster real 1510m58.783s)
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?
Jun 16 2024
It was shut down for a while and has now been deleted.
Jun 14 2024
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.
Jun 13 2024
Jun 12 2024
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 .
Jun 11 2024
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.
Jun 9 2024
Jun 8 2024
@MikhailRyazanov Does https://en.beta.math.wmflabs.org/wiki/User:Admin look as expected.
Jun 6 2024
Thank you this is perfect for defining the goal. I would personally prefer if formulae were centered (or indented).
Jun 5 2024
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.
Jun 4 2024
@MikhailRyazanov I suggest we continue the discussion about :<math> at T111712 and (T268922 summarizes the current status).
Jun 3 2024
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.
Jun 2 2024
This ticket was super helpful.
May 31 2024
May 30 2024
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.