Change 889616 had a related patch set uploaded (by Winston Sung; author: Winston Sung):

[operations/mediawiki-config@master] Update $wgTranslateBlacklist

https://gerrit.wikimedia.org/r/889616

This should be declined.
The Translate extension and other components should try to address the issues you mentioned, not asking translators to translate into multiple variants of Chinese.
And the ancient discussion on babel doesn't make any sense here.

In T328838#8641055, @Func wrote:

The Translate extension and other components should try to address the issues you mentioned, not asking translators to translate into multiple variants of Chinese.

I think there should always be NO badly mixed translation memories (TM). It's always a bad practice for translators.

And the ancient discussion on babel doesn't make any sense here.

Just addressing this is a long-time issue.

In T328838#8641098, @Winston_Sung wrote:

I think there should always be NO badly mixed translation memories (TM). It's always a bad practice for translators.

The Translate extension can try to categorize suggestions by guessing their variants, or maybe try to convert suggestions and label them with a "converted" warning.

In T328838#8641267, @Func wrote:

guessing their variants

The guessVariant function is already considered a bad practice and will not implement in Parsoid.

In T328838#8641267, @Func wrote:

try to convert suggestions and label them with a "converted" warning.

Then there's a problem:

• How to keep -{ tags from TM even after conversion to prevent missing context?

In T328838#8641322, @Winston_Sung wrote:

The guessVariant function is already considered a bad practice and will not implement in Parsoid.

Because that function so far was only used in the LanguageConverter itself.
And that function was never implemented for ZhConverter.

But as an extension that manages the translation, I think it's acceptable to have some guessing feature if we decided to go that path.

In T328838#8641409, @Winston_Sung wrote:

Then there's a problem:

• How to keep -{ tags from TM even after conversion to prevent missing context?

IMHO just skip converting it. Most translations didn't come with conversion markups.

I think it's acceptable to have some guessing feature if we decided to go that path.

I believe having all of them marked as specific "variants" is a better approach.

In my opinion, we shouldn't "guess".

IMHO just skip converting it.

Then that's not something "converted".

Let's talk about the mechanism issues:

What would you think about dealing these problems (any solutions that are not considered as bad practice)?

The {{ll template cannot recognize LanguageConverter syntax in the page display title

Introduce another PAGENAME parser function with language conversion? But how should it work in non-conversion pages?

LanguageConverter syntax exposed on pages without original converter and cannot easily choose the variant to transclude. For example, we cannot choose to transclude the converted zh-hant version from zh pages in non-zh pages.

I don't think passing a parameter would be the fix.

Badly mixed translation memories (TM)
try to categorize suggestions by guessing their variants
I think it's acceptable to have some guessing feature if we decided to go that path.

In my opinion, we shouldn't "guess".

There are no proper places to place page-wide conversion rules

Add a section for them?

The preview cannot handle LanguageConverter syntax properly

Add preview variant selection? List all variants at the same time?