Page MenuHomePhabricator

Enable zh-hans, zh-hant, zh-hk on MediaWiki.org
Open, Stalled, Needs TriagePublic

Description

$wgTranslateDisabledTargetLanguages of zh (mixed-variant variant) on MediaWiki.org

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

This was caused by T39338: $wgTranslateBlacklist of zh-* on metawiki as it is not a Meta-Wiki-only configuration change.

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

  • 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)

On a translation management perspective, the way we translate MediaWiki.org should be like we translate system interface messages on translatewiki.net.

Event Timeline

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

[operations/mediawiki-config@master] Update $wgTranslateDisabledTargetLanguages for MediaWiki.org

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

Winston_Sung changed the task status from Open to In Progress.Feb 23 2023, 3:22 PM
Winston_Sung claimed this task.
Winston_Sung moved this task from Untriaged to Translation difficulties on the I18n board.
Func changed the task status from In Progress to Stalled.Feb 23 2023, 3:45 PM

You should have on-wiki discussions first.

You should have on-wiki discussions first.

I think it's already a long-time unexpected issues and side effects, especially for the main page problem.

I think it's already a long-time unexpected issues and side effects, especially for the main page problem.

If so, the community should be very welcome to your proposal.
But I personally can not accept this change as a translator or reader, you should not workaround technical debt with the manpower of translators.

On a translation management perspective, the way we translate MediaWiki.org should be like we translate system interface messages on translatewiki.net.

This is not true, interface messages are meant to be 100% accurate, while the translation of normal pages doesn't need that, and can be maintained like pages on Chinese sites.

you should not workaround technical debt

I would say it's not a workaround.

Novem_Linguae changed the task status from Stalled to In Progress.Jan 11 2024, 10:05 PM
Novem_Linguae changed the task status from In Progress to Stalled.Jan 11 2024, 10:08 PM
Novem_Linguae subscribed.

sorry, misclick

Winston_Sung renamed this task from $wgTranslateDisabledTargetLanguages of zh (mixed-variant variant) on MediaWiki.org to Enable zh-hans, zh-hant, zh-hk on MediaWiki.org.Mar 7 2025, 9:41 AM
Winston_Sung updated the task description. (Show Details)

Moving discussion from MediaWiki.org to Phabricator.

Currently, the page translation target language configuration on mediawiki.org were [[gerrit:plugins/gitiles/operations/mediawiki-config/+/3630b918def79de3da490799b2dac77442ff140a/wmf-config/InitialiseSettings.php#7561|inherited from the "language converter page translation model"]].

However, this actually created several problems including the broken page transclutions with malfunctioned language converter tags exposed and using the workaround of [[Template:Conversion-zh]], [[Template:LC zh]]. More breakages could be found on [[phab:T328838]].

I would like to propose to use the [[gerrit:plugins/gitiles/translatewiki/+/a86463dad55cd8dc4697399537619643d23eee2d/mw-config/TranslateSettings.php#172|"translatewiki.net page translation model"]]/[https://github.com/miraheze/mw-config/blob/cca495152a9e4a2eac3ee911faa2501c8b652a74/LocalSettings.php#L6011 "Miraheze Meta page translation model"] instead on mediawiki.org after the related [[wikifunctions:Wikifunctions:Project_chat/Archive/2025/05#Change_to_translatewiki.net-like/Miraheze-Meta-like_page_translation_target_languages|proposal had been discussed, supported and approved]] and [[gerrit:1143697|changes had been done]] on Wikifunctions.

Below are examples of the proposed translation model.

* https://www.wikifunctions.org/wiki/Special:Translate?group=page-Template%3AMain+page&action=page&language=zh-hans&filter=
* https://www.wikifunctions.org/wiki/Special:Translate?group=page-Template%3AMain+page&action=page&language=zh-hant&filter=
* https://www.wikifunctions.org/wiki/Special:Translate?group=page-Template%3AMain+page&action=page&language=zh-hk&filter=
* https://translatewiki.net/wiki/Special:Translate?group=page-Project%3AAbout&action=page&language=zh-hans&filter=
* https://translatewiki.net/wiki/Special:Translate?group=page-Project%3AAbout&action=page&language=zh-hant&filter=
* https://translatewiki.net/wiki/Special:Translate?group=page-Project%3AAbout&action=page&language=zh-hk&filter=
* https://meta.miraheze.org/wiki/Special:Translate?group=page-Miraheze+Meta&action=page&language=zh-hans&filter=
* https://meta.miraheze.org/wiki/Special:Translate?group=page-Miraheze+Meta&action=page&language=zh-hant&filter=
* https://meta.miraheze.org/wiki/Special:Translate?group=page-Miraheze+Meta&action=page&language=zh-hk&filter=

More briefly for the <code>zh</code> part: The old configuration can only translate into <code>zh</code> while the new configuration can translate into <code>zh-hans</code> (for <code>zh-Hans-CN</code>, <code>zh-Hans-MY</code>, <code>zh-Hans-SG</code>), <code>zh-hant</code> (for <code>zh-Hant-TW</code>) and <code>zh-hk</code> (for <code>zh-Hant-HK</code>, <code>zh-Hant-MO</code>).

Note: "translatewiki.net page translation model"/"Miraheze Meta page translation model" refer to the same translation model.

-- [[User:Winston Sung|Winston Sung]] ([[User talk:Winston Sung|talk]]) 08:02, 30 July 2025 (UTC)

: Pinging @[[User:Aaron Liu|Aaron Liu]] @[[User:Anterdc99|Anterdc99]] @[[User:AromaTake|AromaTake]] @[[User:Cookai1205|Cookai1205]] @[[User:Diskdance|Diskdance]] @[[User:Lakejason0|Lakejason0]] @[[User:LowensteinYang|LowensteinYang]] @[[User:MilkyDefer|MilkyDefer]] @[[User:SolidBlock|SolidBlock]] @[[User:Stang|Stang]] @[[User:Xiplus|Xiplus]] @[[User:魔琴|魔琴]] -- [[User:Winston Sung|Winston Sung]] ([[User talk:Winston Sung|talk]]) 15:02, 2 August 2025 (UTC)

: I've added my comments on the associated Phabricator task you linked, which is basically about doing the same thing on every multilingual wiki. TL;DR: I'm opposed because as it currently stands, this proposal would quadruple the work of translators. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 16:18, 2 August 2025 (UTC)

: I'd say rather than doing this, we sort of finding a way to actually implement the NoteTA (manual conversion RULES, so not quadrupling the work but actively using the LC model) for content page. -- [[User:Lakejason0|Lakejason0]] ([[User talk:Lakejason0|talk]]) 17:03, 2 August 2025 (UTC)<small>(edited at 17:05, 2 August 2025 (UTC))</small>

: Without using /zh-hans, /zh-hant, /zh-hk, we have to pass the language tag every time using message bundle messages.
: <syntaxhighlight lang="lua">
-- Wrapping all of them under /zh using {{LC zh|, without using /zh-hans, /zh-hant, /zh-hk
tmb.new( mb_page_title, lang_tag ):t( message_key ):params( lang_tag ):plain()
</syntaxhighlight>
: <syntaxhighlight lang="lua">
-- Using separated /zh-hans, /zh-hant, /zh-hk, we no longer need to pass the language tag :params( lang_tag ) every time
tmb.new( mb_page_title, lang_tag ):t( message_key ):plain()
</syntaxhighlight>
: With this change, every Lua module using translation bundles can be simplified:
: <syntaxhighlight lang="diff">
- :t( message_key ):params( lang_tag ):plain()
+ :t( message_key ):plain()
</syntaxhighlight>
: Without this change, every Lua module using translation bundles need to:
: <syntaxhighlight lang="diff">
- :t( message_key ):plain()
+ :t( message_key ):params( lang_tag ):plain()
</syntaxhighlight>
: -- [[User:Winston Sung|Winston Sung]] ([[User talk:Winston Sung|talk]]) 04:44, 5 August 2025 (UTC)

: This is a problem, but more one for something like {{T|196501}} or something else that allows for fetching the current page variant under Lua. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 22:33, 6 August 2025 (UTC)

: Even if {{T|196501}} is solved, you still have no way to either get the requested language tag or pass the lang_tag parameter because we are currently using <code>$1</code> instead of <syntaxhighlight lang="wikitext" inline>{{{lang|}}}</syntaxhighlight>, which make the message bundle messages to be something different like <syntaxhighlight lang="wikitext" inline>{{{lang|$1}}}</syntaxhighlight>. -- [[User:Winston Sung|Winston Sung]] ([[User talk:Winston Sung|talk]]) 08:41, 8 August 2025 (UTC)

: I don't think I understand. As long as lang is set to the needed value somewhere, it should work if we can get all the parent frames, even if it is input by the parser. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 21:42, 9 August 2025 (UTC)

: There might be some misunderstandings.
: You can only get "template arguments" like <syntaxhighlight lang="wikitext" inline>{{{1|}}}</syntaxhighlight> after {{T|196501}} being solved so we no longer need to write <syntaxhighlight lang="wikitext" inline>{{LC zh|lang = {{{lang|}}}|</syntaxhighlight>
: However, "system message arguments"/"interface message arguments" like <code>$1</code> are never something can be get from <syntaxhighlight lang="lua" inline>frame:getParent().args</syntaxhighlight> without either creating new methods to the <syntaxhighlight lang="lua" inline>frame</syntaxhighlight> object or still writing <syntaxhighlight lang="wikitext" inline>{{LC zh|lang = $1|</syntaxhighlight> in Wikitext.
: <syntaxhighlight lang="lua" inline>:t( message_key ):params( lang_tag )</syntaxhighlight> use the "system message argument API" instead of "template argument API".
: -- [[User:Winston Sung|Winston Sung]] ([[User talk:Winston Sung|talk]]) 13:06, 11 August 2025 (UTC)

: I think the solution to that should be to expose the page variant to Scribunto Lua. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 17:37, 14 December 2025 (UTC)

: The current problem is there are no way to pass template parameter (and only can pass system messsage parameter) when calling system messages. We currently have the way to get the current user interface language but there is no way to properly pass it without extra work on every template calls. -- [[User:Winston Sung|Winston Sung]] ([[User talk:Winston Sung|talk]]) 16:08, 15 December 2025 (UTC)

: If any page can get the page variant through a Lua call, the page variant no longer needs to be passed through template parameters. Is there something else that needs to be passed? [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 22:31, 2 January 2026 (UTC)

: Sounds like a good solution. That could fix many things. -- [[User:Winston Sung|Winston Sung]] ([[User talk:Winston Sung|talk]]) 15:02, 3 January 2026 (UTC)

: But we still cannot make the Special:Translation user interface separating the preview of different language variants. -- [[User:Winston Sung|Winston Sung]] ([[User talk:Winston Sung|talk]]) 15:02, 3 January 2026 (UTC)

: The SEO is also broken and only indexing unconverted content instead of indexing converted content. -- [[User:Winston Sung|Winston Sung]] ([[User talk:Winston Sung|talk]]) 16:20, 3 January 2026 (UTC)