Page MenuHomePhabricator

Untranslated units should not be converted to script variants
Open, LowPublic

Description

See https://meta.wikimedia.org/w/index.php?title=IPv6_initiative/2012_IPv6_Day_announcement/sr&variant=sr-ec

All untranslated strings (in English) are converted to unreadable text (though I cannot read sr but I believe that's not correct sr).


Version: unspecified
Severity: normal

Details

Reference
bz37557

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:21 AM
bzimport set Reference to bz37557.
bzimport added a subscriber: Unknown Object (MLST).

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?

Nikerabbit lowered the priority of this task from Medium to Low.Feb 1 2015, 5:07 PM
Tacsipacsi added a subscriber: Tacsipacsi.

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.