Project:Village Pump
Change to translatewiki.net/Miraheze-Meta page translation target languages
[edit]Currently, the page translation target language configuration on mediawiki.org were 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 "translatewiki.net page translation model"/"Miraheze Meta page translation model" instead on mediawiki.org after the related proposal had been discussed, supported and approved and 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 zh part: The old configuration can only translate into zh while the new configuration can translate into zh-hans (for zh-Hans-CN, zh-Hans-MY, zh-Hans-SG), zh-hant (for zh-Hant-TW) and zh-hk (for zh-Hant-HK, zh-Hant-MO).
Note: "translatewiki.net page translation model"/"Miraheze Meta page translation model" refer to the same translation model.
-- Winston Sung (talk) 08:02, 30 July 2025 (UTC)
- Pinging @Aaron Liu @Anterdc99 @AromaTake @Cookai1205 @Diskdance @Lakejason0 @LowensteinYang @MilkyDefer @SolidBlock @Stang @Xiplus @魔琴 -- 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. 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. -- Lakejason0 (talk) 17:03, 2 August 2025 (UTC)(edited at 17:05, 2 August 2025 (UTC))
- Without using /zh-hans, /zh-hant, /zh-hk, we have to pass the language tag every time using message bundle messages.
-- 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()
-- 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()
- With this change, every Lua module using translation bundles can be simplified:
- :t( message_key ):params( lang_tag ):plain() + :t( message_key ):plain()
- Without this change, every Lua module using translation bundles need to:
- :t( message_key ):plain() + :t( message_key ):params( lang_tag ):plain()
- -- Winston Sung (talk) 04:44, 5 August 2025 (UTC)
- This is a problem, but more one for something like T196501 or something else that allows for fetching the current page variant under Lua. Aaron Liu (talk) 22:33, 6 August 2025 (UTC)
- Even if T196501 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
$1instead of{{{lang|}}}, which make the message bundle messages to be something different like{{{lang|$1}}}. -- 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. Aaron Liu (talk) 21:42, 9 August 2025 (UTC)
- There might be some misunderstandings.
- You can only get "template arguments" like
{{{1|}}}after T196501 being solved so we no longer need to write{{LC zh|lang = {{{lang|}}}| - However, "system message arguments"/"interface message arguments" like
$1are never something can be get fromframe:getParent().argswithout either creating new methods to theframeobject or still writing{{LC zh|lang = $1|in Wikitext. :t( message_key ):params( lang_tag )use the "system message argument API" instead of "template argument API".- -- 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. 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. -- 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? Aaron Liu (talk) 22:31, 2 January 2026 (UTC)
- Sounds like a good solution. That could fix many things. -- 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. -- Winston Sung (talk) 15:02, 3 January 2026 (UTC)
- The SEO is also broken and only indexing unconverted content instead of indexing converted content. -- Winston Sung (talk) 16:20, 3 January 2026 (UTC)
On Template:MW file, the legacy= parameter is used for phabricator.wikimedia.org links in both 1.44.3 and 1.43.6.
Because of this, on pages for files moved in 1.44 (e.g., Manual:ZipDirectoryReaderError.php), one of the links ends up broken.
- Manual:HttpStatus.php
- Manual:Message.php
- Manual:MessageCacheUpdate.php
- Manual:MessageFormatterFactory.php
- Manual:RedisConnectionPool.php
- Manual:RedisConnRef.php
- Manual:SearchUpdate.php
- Manual:SerializedValueContainer.php
- Manual:TextFormatter.php
- Manual:UserOptionsUpdateJob.php
- Manual:ZipDirectoryReader.php
- Manual:ZipDirectoryReaderError.php
-- Shirayuki (talk) 08:52, 4 January 2026 (UTC)
- I think I've fixed (Special:Diff/8123777) Ciencia Al Poder (talk) 14:20, 4 January 2026 (UTC)
- @Ciencia Al Poder:
Done Thanks. I’ve updated each page to match the new specifications.-- Shirayuki (talk) 11:06, 5 January 2026 (UTC)
- @Ciencia Al Poder:
Wikisource navigation broken in Page namespace
[edit]I have suddenly lost navigation tabs in Wikisource: English, Spanish, and Greek Wikisource are all having this issue, so I assume it is a general one. In the Page: namespace, I am only seeing the tab for the page itself and the associated discussion page. Gone are the forward and back tabs that permit moving through an Index, and gone also is the source tab linking to the Index: associated with a particular set of Pages.
This issue has manifested with about the last hour. --EncycloPetey (talk) 19:42, 14 January 2026 (UTC)
- Besides the above, I've also noticed the tab to the styles subpage on index pages is also missing. This is in the "legacy" Vector skin. They are present in the Vector 2022 skin, however, but I will categorically refuse to switch to it if that's the solution. DarkShadowTNT (talk) 20:39, 14 January 2026 (UTC)
- @EncycloPetey: Hey there.
- Just to check, you're on a page like https://en.wikisource.org/wiki/Page:Haunted_Man_(Dickens,_1848).pdf/121 and there's no "Image" tab at the top of the page linking to the source image (in this case, this one), and also no "Index" linking to the index (this one), nor "Forwards" and "Backwards" tabs, but the "Page" and "Discussion" tabs are there?
- I note that I see all four links to Forward, Backwards, Image, and Index in Minerva, but only Image in Vector 2022, and none in the old, less-supported skins: in Vector or in Monobook.
- Filed as T414630: [Regression, 1.46.0-wmf.11] ProofreadPage navigation tabs on Page pages are missing in some skins, Jdforrester (WMF) (talk) 20:40, 14 January 2026 (UTC)
- Vector 2022 is dreadful for Wikisource editing, which is why I do not use it. It compresses the screen content horizontally, wasting valuable space to either side of the screen with links. It reduces display space for side-by-side window editing that is the core of Wikisource content creation. The 2022 skin was designed for Wikipedia without considering the needs of Wikisource editors. --EncycloPetey (talk) 20:45, 14 January 2026 (UTC)
- 100% agree with EncycloPetey. ProofreadPage needs to be tested across the base MediaWiki skins before receiving updates like this. The site's proofreading interface is substantially less usable now. Mathmitch7 (talk) 20:53, 14 January 2026 (UTC)
- Just read @Jdforrester (WMF)'s bug report, thank you for filing that and hopefully this gets fixed shortly. Thanks for all your hard work! Mathmitch7 (talk) 20:55, 14 January 2026 (UTC)
- (On V22: With the right setup and CSS to hide all the excess cruft, you can get a tidbit more space than you'd get in V10. Of course, there's also the issue of how much one is fine with everything being in dropdowns.) — Alien 3
3 3 21:02, 14 January 2026 (UTC)
- 100% agree with EncycloPetey. ProofreadPage needs to be tested across the base MediaWiki skins before receiving updates like this. The site's proofreading interface is substantially less usable now. Mathmitch7 (talk) 20:53, 14 January 2026 (UTC)
- Vector 2022 is dreadful for Wikisource editing, which is why I do not use it. It compresses the screen content horizontally, wasting valuable space to either side of the screen with links. It reduces display space for side-by-side window editing that is the core of Wikisource content creation. The 2022 skin was designed for Wikipedia without considering the needs of Wikisource editors. --EncycloPetey (talk) 20:45, 14 January 2026 (UTC)
- @EncycloPetey (and others): This is now fixed, with the premature patch un-deployed from production. Sorry for the disruption! Jdforrester (WMF) (talk) 22:35, 14 January 2026 (UTC)
- Thanks for the quick fix. January is public domain month, so we're quite busy with new transcriptions. Being able to again navigate from page to page will help that process greatly. --EncycloPetey (talk) 22:36, 14 January 2026 (UTC)