Page MenuHomePhabricator

Parsoid page views: need to do something about {{int:}}
Open, LowPublic

Description

Currently, {{int:}} is (ab)used to localize content, either directly by showing a localised message or by using e.g. MediaWiki:Lang to achieve conditional transclusion à-la {{sometemplate/{{int:lang}}}}. However, Parsoid always assumes content language for this parser function. This is generally not a problem for VisualEditor where it even makes sense to display a "canonical" version of text, but page views on multilingual projects like meta and commons are different because these sites rely heavily on user language to display content in it. A few examples:

We need to develop a strategy to mitigate thiese problems for Parsoid-based pageviews.

Event Timeline

MaxSem created this task.Dec 31 2014, 1:41 AM
MaxSem raised the priority of this task from to Needs Triage.
MaxSem updated the task description. (Show Details)
MaxSem added a project: Parsoid.
MaxSem added a subscriber: MaxSem.
GWicke set Security to None.

Hmm .. interesting ... this could be tricky. How do we get user state into the parsing because without user state, it will return the default lang.

[subbu@earth lib] echo "{{int:lang}}" | node parse --normalize --dump tplsrc --prefix commonswiki
=================================
pf_int
---------------------------------
en
---------------------------------

<p>en</p>
ssastry triaged this task as High priority.Dec 31 2014, 10:29 PM
GWicke added a subscriber: GWicke.EditedDec 31 2014, 10:36 PM

@ssastry We could pass a language in as a parameter (and then forward that to expandtemplates), but would also need to store that separately, effectively replicating the current parser cache fragmentation.

Some of the use cases for {{int:}} like commons metadata will probably go away soonish with the move to wikidata. The remaining ones seem to be typically individual transclusions, often really small ones (like the 'thanks' template).

I think it's worth thinking about moving more of the remaining work to the client. We could compile a list of such elements in each page after parse, and then deliver translations to be applied client-side to users who requested it. This should be a good performance win if translations are small relative to the overall page size. It would reduce the per-language storage needs on the server to fragments rather than entire pages. It might even be possible to share such fragments between pages if we can establish that the output does not depend on the actual page name.

In any case, I think the current result of returning the content language is tolerable in the short term. There are bigger issues to tackle right now.

ssastry lowered the priority of this task from High to Medium.Feb 3 2015, 9:55 PM
ssastry added subscribers: Mooeypoo, siebrand, dchan and 2 others.

I think it's worth thinking about moving more of the remaining work to the client. We could compile a list of such elements in each page after parse, and then deliver translations to be applied client-side to users who requested it. This should be a good performance win if translations are small relative to the overall page size. It would reduce the per-language storage needs on the server to fragments rather than entire pages. It might even be possible to share such fragments between pages if we can establish that the output does not depend on the actual page name.

However, this will not work when {{int}} is used in esoteric templates to control transclusion.

Nemo_bis added a subscriber: Nemo_bis.
Pchelolo moved this task from Backlog to watching on the Services board.Oct 12 2016, 7:24 PM
Pchelolo edited projects, added Services (watching); removed Services.
ssastry moved this task from Needs Triage to Read Views on the Parsoid board.Jan 11 2018, 9:49 PM
Reedy edited projects, added Parsoid-Read-Views; removed Parsoid.Sep 17 2018, 7:25 PM
Aklapper edited projects, added Parsoid; removed Parsoid-Read-Views.Feb 29 2020, 5:14 PM
LGoto lowered the priority of this task from Medium to Low.Jun 25 2020, 6:11 PM