@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

@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:

• T30441#2637272, raised to normal only because it passed ~10 years;
• Likely, T10217#2173459, raised to high;
• T17294#2315909, raised to high because Your comment has no relationship with the status of the report...;
• T95309#2531368, raised to normal, maybe because that user merged more than one tasks?
• T55794#2530607, raised to high because What jimmyxu means is that an extra optional parameter is needed...;
• T68593#1791759, raised to normal without any reason, that user said sorry later;
• T125366#2624568, raised to normal because MW 1.27 destroyed the usage of all these hooks...;
• T62337#2015319, T61791#2525959, T23582#997301, T78157#2776649, T73383#2798525, and T77708#943717, raised to normal without any reason;
• T67190#938826, raised to UBN because Hi the steps to reproduce is go to...;
• T84163#1352851, raised to high because we keep getting "Slow CirrusSearch query rate" alerts for many months now...;
• T100896#2198073, raised to high because Is there a plan to actually resolve this ridiculous issue?...;

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.

In T106687#2964050, @Mattflaschen-WMF wrote:

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.

In T106687#2964054, @Catrope wrote:

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?

In T106687#2965312, @Trizek-WMF wrote:

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.

Cross-linking to T85581: Parsoid page views: need to do something about {{int:}}.