Community Wishlist Survey 2022/Translation/Make "translate" tags always render correctly

Random proposal ►◄ Translation The survey has concluded. Here are the results!

Make "translate" tags always render correctly

Problem: At Community Wishlist Survey 2022/Wikidata/Entity Draft Namespace and Community Wishlist Survey 2022/Miscellaneous/Create universal routinformationcode for railways, roads, etc in Wikidata, the <translate></translate> tags are not rendered correctly.
Proposed solution: Make "translate" tags always render correctly on pages transcluding other pages with <translate></translate> tags, regardless of whether or not the transcluded pages had changes marked for translation.
Who would benefit: Readers of the Community Wishlist Survey
More comments:
Phabricator tickets:
Proposer: GeoffreyT2000 (talk) 15:07, 22 January 2022 (UTC)[reply]

Discussion

Indeed, the problem even occurs right here on its own corresponding Community Wishlist Survey 2022 proposal page! GeoffreyT2000 (talk) 03:53, 26 January 2022 (UTC)[reply]
And now, the problem no longer affects the proposal page it is written on itself, nor does it affect the two proposals linked in the "Problem" statement. But, as of the time the list was added, it has affected the following seven proposals (which are now no longer affected):

GeoffreyT2000 (talk) 04:27, 28 January 2022 (UTC)[reply]

Congratulations for marking all of the affected proposals' "/Proposal" subpages for translation! Now, none of the above seven proposals are affected anymore. But the problem could still affect proposals created in future surveys. GeoffreyT2000 (talk) 05:40, 28 January 2022 (UTC)[reply]
Hehe, as you know by the time voting starts there should be no proposals left for you to use as an example. But thank you for keeping track of this for us! :) There is a more permanent example at User:MusikAnimal (WMF)/Translate example (so long as no one marks the subpage for translation). I'm not that familiar with mw:Extension:Translate internals, but it's possible this is an unavoidable bug. For a moment I thought there was a workaround we could build into our templates, but I see that even transcluding the page directly (and not a /en or /mylanguage subpage as is done with {{dynamite}}), the parser is not recognizing the <translate>...</translate> tags. The thing is, when you view the subpage directly, they are not visible. So this is unique to transclusions. One of the many translationadmins here on Meta may be able to explain this. MusikAnimal (WMF) (talk) 05:41, 28 January 2022 (UTC) MusikAnimal (WMF) (talk) 05:42, 28 January 2022 (UTC)[reply]
This opt-in behavior of transclusion is intentional to avoid breaking existing templates that rely on the previous behavior. It's possible though that this might change when Translate extension is updated to support Parsoid. Nikerabbit (talk) 18:25, 8 February 2022 (UTC)[reply]

Voting

Support * Pppery * _{it has begun} 18:55, 28 January 2022 (UTC)[reply]
Support Pratodellaspiaggia (talk) 17:31, 1 February 2022 (UTC)[reply]
Support Thingofme (talk) 02:43, 2 February 2022 (UTC)[reply]
Support --Ciao • Bestoernesto • ✉ 03:47, 6 February 2022 (UTC)[reply]
Support —Thanks for the fish! ^{talk•contrib} (he/him) 17:12, 6 February 2022 (UTC)[reply]
Support Ayumu Ozaki (talk) 02:24, 7 February 2022 (UTC)[reply]
Support Umar-askira (talk) 08:41, 7 February 2022 (UTC)[reply]