Looks like the translate extension is stripping the `<translate>\n" there and causing the string on the following line to collapse which then causes the bold tag to take effect. @Nikerabbit is this expected or accidental behaviour?

Is there a reason not to decline this on the Parsoid end and have editors not add that unnecessary newline break?

Or, should Parsoid strip (all? one?) newlines / whitespace after <translate> and before </translate>? @ihurbain / we could read the translate source but you may have a quicker response here.

I believe we don't want to strip these newlines after/before because
<translate>
stuff
</translate>
has block semantics and <translate>stuff</translate> does not, and as far as I understood, that makes a difference for translate.

Hmm, an interesting edge case. To avoid whitespace build-up in the rendered output, when removing tags, Translate removes one newline (if present) after opening tag and one newline (if present) before closing tag. The removal happens after determining whether the content is block vs. inline.

Those two behaviors are intentional, but the combined behavior in a case like this... I don't think I can say it is intentional.

To make things more complicated, I think that before making the block vs. inline separation like it is today, the Translate extension would add a newline after the translation unit id comment, as in the examples. It does not do it these days, but I expect a lot of existing content has that kind of newline there.

Old Translate

Input:
"<translate>Bunny</translate>"

After marking:
"<translate><!--T:1-->
Bunny</translate"

Old parser sees:
"Bunny"

New Translate:

Input:
"<translate>Bunny</translate>"

After marking:
"<translate><!--T:1--> Bunny</translate>"

Old parser sees:
"Bunny"

Also, if that old Tech News issue used syntax version 2 (implemented in T254484) and there was an incomplete translation,

'''<translate><!--T:25-->
Problems</translate>'''

turned into

'''<div lang="en" dir="ltr" class="mw-content-ltr">
Problems
</div>'''

which is clearly broken wikitext. (Inline '''<translate><!--T:25--> Problems</translate>''' turns into inline '''<span lang="en" dir="ltr" class="mw-content-ltr">Problems</span>''', which is fine.)