This would probably be very difficult but not impossible. The full page is treated as one text going through the parser. We might somehow flag untranslated parts as text that should not be converted, similar to how -{}- is not converted.

For the <languages /> however it should be easy to fix because it's separate from the page content. For the sentence above it, it's already correct.

(In reply to comment #1)

This would probably be very difficult but not impossible. The full page is
treated as one text going through the parser. We might somehow flag
untranslated parts as text that should not be converted, similar to how -{}- is
not converted.

For the <languages /> however it should be easy to fix because it's separate
from the page content. For the sentence above it, it's already correct.

and I want to say on https://meta.wikimedia.org/w/index.php?title=IPv6_initiative/2012_IPv6_Day_announcement/sr , I want a en font instead of a sr font (as specified in <div lang="sr">)

Liangent: Do you have any suggestions how to fix this?

Now it’s possible to mark up untranslated parts (T254484), and I’ve just updated the page so that English parts are within <div lang="en" …> blocks. From this point, I think it’s the language converter’s duty to skip these.

I think the language converter should skip all content that’s marked up using the HTML lang attribute to be not in the language-converted language, be this attribute added by Translate, another extension, a template, or directly by the editor.

If it’s blocked by T39617, then T39617 is by definition a subtask, not a parent task.