Page MenuHomePhabricator

MediaWiki Developer stores different HTML output for different language variants in the parser cache
Closed, DuplicatePublic

Description

"As a MediaWiki Developer, I want to store different HTML output for different language variants in the parser cache, so that I can return the right formatting for the user to read."

This is for handling things like traditional Chinese characters vs. simplified Chinese characters. I have to admit that I'm not 100% sure how this works in RESTBase, but it's something that's important there so we should consider it for this work.

I think it's worthwhile to have this discussion on one ticket, so let's say that for this user story we need to make sure we cover:

  • get
  • set
  • purge

Event Timeline

Ok, in Mediawiki ParserCache this theoretically should be coming out of the box, since userlang is a cache varying parser option and I believe it will vary on lang variants. But have to double-check.

Change 636070 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[mediawiki/core@master] WIP: Support language variants in /page/html handler.

https://gerrit.wikimedia.org/r/636070

Change 636079 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[mediawiki/core@master] Support language variants in /page/html handler.

https://gerrit.wikimedia.org/r/636079

Change 636070 abandoned by Ppchelko:
[mediawiki/core@master] Support language variants in /page/html handler.

Reason:
git review operator error

https://gerrit.wikimedia.org/r/636070

Ok, in Mediawiki ParserCache this theoretically should be coming out of the box, since userlang is a cache varying parser option and I believe it will vary on lang variants. But have to double-check.

No, the content variant is independent of the user interface language.

As far as I know, variant transformation is done on the fly, on top of cached content. So we wouldn't need or want ParserCache to know about it.

But let's talk to @Amire80 and @cscott to make sure.

No, the content variant is independent of the user interface language.

Then we can add one more parser option.

As far as I know, variant transformation is done on the fly, on top of cached content. So we wouldn't need or want ParserCache to know about it.

With the old parser, afaik - yes. Same is happening in RESTBase now. However, in RESTBase we are experiencing problems with on-the-fly conversion into lang variants - this coversion is quite resource-intensive, so from time to time we crash some app servers doing those conversions. The patch I made is caching the variants and all the intermediate transformations, which I think is the end goal we want to move towards.

No, the content variant is independent of the user interface language.

Then we can add one more parser option.

Yes, we could do that.

As far as I know, variant transformation is done on the fly, on top of cached content. So we wouldn't need or want ParserCache to know about it.

With the old parser, afaik - yes. Same is happening in RESTBase now. However, in RESTBase we are experiencing problems with on-the-fly conversion into lang variants - this coversion is quite resource-intensive, so from time to time we crash some app servers doing those conversions. The patch I made is caching the variants and all the intermediate transformations, which I think is the end goal we want to move towards.

That sounds reasonable, but I'd want to first understand why we didn't go that route in the past. Also, this is not something I'd want to fold into the current initiative.