https://en.wikipedia.org/w/index.php?title=User:Arlolra/sandbox&oldid=837381819
https://en.wikipedia.org/api/rest_v1/page/html/User:Arlolra%2Fsandbox/837381819

Sorry, word-wrap is an alias for overflow-wrap, and seems to depend on having a fixed width, so isn't exactly what we're looking for.

See T187235 for an explanation about this log message.

Is there anything that's going to work on Firefox though?

@Volker_E any thoughts on this?

Placing word-break: break-word on the <figcaption> might be acceptable for webkit based browsers.

It doesn't respect a "width" attribute, so adding it won't have any effect.

"height" was bumped to 32 in that patch, and a new "mw-default-audio-size" class was added that can be targeted to override it.

Yes; I still hope to revive that tool sometime soon.

Dupe of T180611

That seems more of an issue when uploading, that the derivatives aren't produced.

https://en.wikipedia.org/w/api.php?action=query&titles=File:Chromatic_Fuge_(Bach_BWV_903).ogg&prop=videoinfo&viprop=derivatives

In Firefox, it seems that they're hidden when the "height" property is less than 40.

In the patch above, we went with a fixed height of 20px, which seems to match TimedMediaHandler, but @cscott was arguing that audio content should respect a defined height. Any thoughts on that?

I'm not seeing this anywhere.. The only mention of the audio tag inside "Minerva" is in the css reset file.

Parsoid currently relies on the php parser for template expansion. Some of the most popular templates are implemented as invokations of lua modules.

Things are more insidious than just the file size limitations. To address the problem statement directly, any non-trivial parse requires fetching state from the server. So, concretely, template resolution wouldn't be possible with that limitation.

Not to mention the latency / throughput tradeoff of making a parse request vs the first time cost of having to download the entire parser.

But the spike is from parses new pages or what?

enwiki User:Shengwei95/首页 822246901

But the spike is from parses new pages or what?

This is from https://gerrit.wikimedia.org/r/#/c/411293/

I can't find any examples in the lint errors where the Arabic units are being marked as bogus. @Bawolff is of course correct that the recognized forms are,

I don't think that's true

For example, https://ar.wikipedia.org/w/index.php?title=%D8%A7%D9%84%D8%A3%D8%B3%D8%B1%D8%A9_%D8%A7%D9%84%D9%85%D8%B5%D8%B1%D9%8A%D8%A9_%D8%A7%D9%84%D8%AB%D8%A7%D9%84%D8%AB%D8%A9_%D8%B9%D8%B4%D8%B1&action=edit&lintid=1699264

Remove the hack from T185266 when this gets done.

See T179082 for a proper solution.

https://en.wikipedia.org/w/index.php?title=User:Arlolra/sandbox&type=revision&diff=834271300&oldid=823914820&diffmode=source

Think we timed out on this one since HTML was already enabled.

Going to consider this round of investigation resolved. We can always reopen when this rears its ugly head again.

For posterity, these diffs were taken with,

The imagemap extension looks like it uses timestamps in various places,

http://localhost:8000/ba.wikibooks.org/v3/page/html/%D0%92%D0%B8%D0%BA%D0%B8%D0%B4%D3%99%D1%80%D0%B5%D1%81%D0%BB%D0%B5%D0%BA%3A%D0%91%D0%B0%D1%88_%D0%B1%D0%B8%D1%82/18994 renders fine for me locally, so maybe this is a RESTBase issue.

https://en.wikipedia.org/wiki/Brazil_at_the_2016_Summer_Olympics uses a template that invokes Module:Sports_table, which has the following,

http://localhost:8000/es.wikipedia.org/v3/page/html/Cleveland_Cavaliers/106401442 has duplicate template arguments, that get normalized in the first roundtrip,

All this is relevant to T93715

Maybe consider using a word diff?

For https://parsoid-rt-tests.wikimedia.org/resultFlagNew/16ced345bee068b73f8e129dd66a8dea3bee0cc3/ce4ffddfd42db404ee1f405a5abb583f5a732d61/dewiki/Robin%20Thicke

Submitted https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion%3ALua%2FModul%2FZitation&type=revision&diff=175479422&oldid=172499057

I'm not sure who's job it is to remove the strip markers

Dupe of T156099, no?

while we can get the PHP parser expansion by relying on action=parse temporarily

Batch API returned http 503 ...

https://gerrit.wikimedia.org/r/#/c/415910/ was also relevant here.

http://localhost:8000/en.wikipedia.org/v3/page/html/User_talk%3AIridescent%2FArchive_8/807012459

An example, http://localhost:8000/pt.wikipedia.org/v3/page/html/Usu%C3%A1rio(a)%3AYanguas%2FArquivo_9/31923007

There haven't been any incidents since deploying that patch so, for the moment, the low priority seems justified.

This is your friend tidy introducing newlines,

Lowering the priority but leaving it open so that when we got looking for places to optimize it shows up.

This seems to have been resolved by https://gerrit.wikimedia.org/r/#/c/412611/

StoneChariot (parsoid) vs Stone Chariot (php)

These look they render identically to me,

From https://github.com/wikimedia/parsoid/blob/master/lib/ext/Gallery/index.js#L68-L71