Page MenuHomePhabricator

Multidirectional language conversion for content pages using LanguageConverter should be prevented on multilingual wikis
Open, Stalled, Needs TriagePublic

Description

Multidirectional language conversion for content pages using LanguageConverter should be prevented on multilingual wikis.

This was caused by T39338: $wgTranslateBlacklist of zh-* on metawiki .

This is not an issue for monodirectional language conversion; however, this had caused several issues:

  • Search engines didn't index pages in language variants
  • The {{ll template cannot recognize LanguageConverter syntax in the page display title
    • Especially for MediaWiki.org
  • 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.
  • The Translate special page become a mess because:
    • Badly mixed translation memories (TM)
    • There are no proper places to place page-wide conversion rules
    • There are many manual conversion tags in the translation unit
    • The preview cannot handle LanguageConverter syntax properly
  • T39557: Untranslated units should not be converted to script variants
  • (to be addressed)

Former discussions:

Related Objects

StatusSubtypeAssignedTask
In ProgressWinston_Sung
In ProgressWinston_Sung
OpenNone
StalledNone
StalledNone
ResolvedNone
OpenNone
OpenNone
StalledNone
OpenNone
OpenNone
OpenNone
Resolvedcscott
Invalid GWicke
Resolvedliangent
Resolvedthiemowmde
OpenNone
Resolvedcscott
Resolvedcscott
Resolved Elitre
Resolvedcscott
Resolvedcscott
Resolvedcscott
Resolvedcscott
Resolvedcscott
OpenNone
DuplicateBUG REPORTNone
Resolvedcscott
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedBUG REPORTJgiannelos
OpenNone

Event Timeline

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.

Func changed the task status from Open to Stalled.Feb 23 2023, 3:00 PM

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.

Winston_Sung renamed this task from Language conversion for content pages using LanguageConverter should be prevented on multilingual wikis to Multidirectional language conversion for content pages using LanguageConverter should be prevented on multilingual wikis.Feb 23 2023, 3:15 PM
Winston_Sung updated the task description. (Show Details)
Winston_Sung updated the task description. (Show Details)

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.

guessing their variants

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

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?

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.

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?