Page MenuHomePhabricator

Flow does not support varying language of parts of content based on user interface language (e.g. {{int:}})
Open, LowestPublic

Assigned To
None
Authored By
He7d3r
Jul 23 2015, 2:42 PM
Referenced Files
None
Tokens
"Heartbreak" token, awarded by Mormegil."Heartbreak" token, awarded by Hsarrazin."Pterodactyl" token, awarded by Liuxinyu970226."Hungry Hippo" token, awarded by Tubezlob."Pterodactyl" token, awarded by Ash_Crow."Cup of Joe" token, awarded by Framawiki."Heartbreak" token, awarded by VIGNERON."Pterodactyl" token, awarded by Sylvain_WMFr.

Description

Although

all pages below show the "pt" version:

Changing the user language directly in the preferences doesn't work either.

Also problematic on Wikidata, where to call properties and/or elements and are not displaying the content into the user language.

Related Objects

Event Timeline

He7d3r raised the priority of this task from to Needs Triage.
He7d3r updated the task description. (Show Details)
He7d3r subscribed.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DannyH set Security to None.
He7d3r renamed this task from URL parameter "uselang" does not work on Flow comments using {{int:...}} to {{int: ... }} magic word does not work on Flow comments.Jul 30 2015, 1:08 PM
He7d3r updated the task description. (Show Details)
He7d3r renamed this task from {{int: ... }} magic word does not work on Flow comments to Make {{int: ... }} magic word work on Flow comments.Aug 17 2015, 11:52 PM
Mattflaschen-WMF renamed this task from Make {{int: ... }} magic word work on Flow comments to Flow does not support varying language of parts of content based on user interface language (e.g. {{int:}}).Dec 2 2016, 6:31 PM
Trizek-WMF added subscribers: hoo, daniel, VIGNERON.

That issue may be a blocker for communities that use variation of interface language and want to have Flow deployed.

For instance, on Wikidata, templates {{Q}} and {{Property}} are not displaying the content into the user language.

Thibaut120094 raised the priority of this task from Lowest to High.EditedJan 20 2017, 4:53 PM
Thibaut120094 subscribed.

Setting this as high instead of "lowest" as this is something very important for non-English speaking communities on multilingual wikis like Wikidata.

See also Trizek's comment above and this discussion.

@Thibaut120094: As priority reflects reality and does not cause it, do you plan to fix this problem or have Flow developers confirmed that this task indeed is more urgent? Please do not change priority if it does not confirm with Setting Task Priorities. Resources of teams are limited when it comes to working on requests. We want to be realistic about communicating what is being worked on, to maximize the impact of changes. Practically, this often unfortunately means assigning a low priority to many tasks.

If the priority was increased because you plan to work on this task please claim the task by setting yourself as assignee. Thank you for your help!

If you do not plan to work on this task yourself but feel that this task is urgent but being ignored by those with the actual power to put the task on their agenda, please discuss with the responsible developers, product managers and budget holders. Further contact information can be found on the corresponding team wiki page. Thanks for your understanding!

Liuxinyu970226 lowered the priority of this task from High to Lowest.EditedJan 21 2017, 2:30 AM

@Thibaut120094: As priority reflects reality and does not cause it, do you plan to fix this problem or have Flow developers confirmed that this task indeed is more urgent? Please do not change priority if it does not confirm with Setting Task Priorities. Resources of teams are limited when it comes to working on requests. We want to be realistic about communicating what is being worked on, to maximize the impact of changes. Practically, this often unfortunately means assigning a low priority to many tasks.

If the priority was increased because you plan to work on this task please claim the task by setting yourself as assignee. Thank you for your help!

If you do not plan to work on this task yourself but feel that this task is urgent but being ignored by those with the actual power to put the task on their agenda, please discuss with the responsible developers, product managers and budget holders. Further contact information can be found on the corresponding team wiki page. Thanks for your understanding!

Since most of such actions are really abuse happened, I suggest to create an acl*priority-changer to limit users who have right on it?

Since most of such actions are really abuse

@Liuxinyu970226 “Never attribute to malice that which can be adequately explained by incompetence”

Please assume good faith next time, and I don't think this task is the place to discuss acl changes.

but feel that this task is urgent

I (personally) think this task is of the uttermost importance for Flow !
I would tend to suggest to desactivate Flow everywhere if it can't deal with such simple and basic need. As one of many people spending a lot of time translating, I feel really disrespected (sacrebleu !).

I also think this task should have a higher priority, especially now that an important community page (https://www.wikidata.org/wiki/Wikidata:Bistro) uses it. Right now, the message sent by this "Lowest" priority is that the only language that matters in the community is English.

And I could also say that any tasks which are opened for more than 5 years (e.g. T21986 and blockers) should also "have a high priority because it affects a lot of compatibility issues"? As someone called in their question that why such "raised the priority" are abused:

So why do we think that those raising are valuable? So the default priority value should be normal INSTEAD OF "Needs Triage"? So if these are not abuse, then what's the actual abuse? Or what are these?
I also believe that this bug can be multilingual, but aren't T43475 and T11436 the examples of Lowest priority tasks which also multilingual?

Short answer: There might be a way to fix this without changing the architecture. It's a bit ugly, but not completely terrible.

Long answer:

This can't be tested properly locally due to T156097. In Beta (and presumably everywhere properly configured), it uses the content language, and generates Parsoid metadata, like:

<p data-parsoid="{"dsr":[0,52,0,0]}">underline-default: <span about="#mwt1" typeof="mw:Transclusion" data-parsoid="{"pi":[[{"k":"1"},{"k":"2"},{"k":"3"}]],"dsr":[19,52,null,null]}" data-mw="{"parts":[{"template":{"target":{"wt":"int:underline-default","function":"int"},"params":{"1":{"wt":"1"},"2":{"wt":"foo"},"3":{"wt":"3"}},"i":0}}]}">abhängig von der Benutzeroberfläche oder Browsereinstellung</span></p>

As you can see, it preserves all the data needed to regenerate the int:. This can be done in a Flow ContentFixer. So there is a (not-pretty) solution without completely changing the architecture.

As you can see, it preserves all the data needed to regenerate the int:. This can be done in a Flow ContentFixer. So there is a (not-pretty) solution without completely changing the architecture.

To clarify, are you suggesting we write a ContentFixer that finds usages of {{int:}} and runs them through Parsoid's html2html operation? I suppose that would work.

To clarify, are you suggesting we write a ContentFixer that finds usages of {{int:}} and runs them through Parsoid's html2html operation? I suppose that would work.

I'm suggesting decoding the {{int:}} call (probably inline in the Fixer, not by actually calling Parsoid), then running that through the standard PHP parser (or even just calling wfMessage-equivalent directly). We do similar things for links in WikiLinkFixer.

That task has been raised up because of Wikidata, where Properties are not displayed in the language used by the user. But on Wikidata, as far as I understand how Template:Properties works, it is not using a magic word. Would it be a separated problem?

That task has been raised up because of Wikidata, where Properties are not displayed in the language used by the user. But on Wikidata, as far as I understand how Template:Properties works, it is not using a magic word. Would it be a separated problem?

Wikidata boils down to int as well: https://www.wikidata.org/w/index.php?title=Template:Label&action=edit

Also, I tested better, and my suggestion above will not work, since real-world use cases don't usually call int: directly from the top-level comment.

E.g.

<nowiki>{{int wrapper|underline-default}}</nowiki>:

{{int wrapper|underline-default}}

becomes:

		<p data-parsoid="{"dsr":[0,51,0,0]}"><span typeof="mw:Nowiki" data-parsoid="{"dsr":[0,50,8,9]}">{{int wrapper|underline-default}}</span>:</p>

<p about="#mwt1" typeof="mw:Transclusion" data-parsoid="{"dsr":[53,86,0,0],"pi":[[{"k":"1"}]]}" data-mw="{"parts":[{"template":{"target":{"wt":"int wrapper","href":"./Template:Int_wrapper"},"params":{"1":{"wt":"underline-default"}},"i":0}}]}">Skin or browser default</p>

That's just a trivial wrapper (https://en.wikipedia.beta.wmflabs.org/wiki/Template:Int_wrapper) that does nothing but call int, but it shows the problem well enough. We have no way to detect which templates (directly or indirectly) use int:, so we would have to do this on all templates.