Jump to content

Project:Village Pump

Add topic
From mediawiki.org
(Redirected from Project:Current issues)
Latest comment: 6 hours ago by EncycloPetey in topic Wikisource navigation broken in Page namespace
This page is only for discussing issues related to MediaWiki.org site.
To get help with MediaWiki software, ask on Project:Support desk.

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.

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

Pinging @Aaron Liu @Anterdc99 @AromaTake @Cookai1205 @Diskdance @Lakejason0 @LowensteinYang @MilkyDefer @SolidBlock @Stang @Xiplus @魔琴 -- Winston Sung (talk) 15:02, 2 August 2025 (UTC)Reply
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)Reply
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))Reply
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)Reply
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)Reply
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 $1 instead of {{{lang|}}}, which make the message bundle messages to be something different like {{{lang|$1}}}. -- Winston Sung (talk) 08:41, 8 August 2025 (UTC)Reply
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)Reply
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 $1 are never something can be get from frame:getParent().args without either creating new methods to the frame object 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)Reply
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)Reply
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)Reply
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)Reply
Sounds like a good solution. That could fix many things. -- Winston Sung (talk) 15:02, 3 January 2026 (UTC)Reply
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)Reply
The SEO is also broken and only indexing unconverted content instead of indexing converted content. -- Winston Sung (talk) 16:20, 3 January 2026 (UTC)Reply

Template:MW file

[edit]

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.

-- Shirayuki (talk) 08:52, 4 January 2026 (UTC)Reply

I think I've fixed (Special:Diff/8123777) Ciencia Al Poder (talk) 14:20, 4 January 2026 (UTC)Reply
@Ciencia Al Poder: Yes Done Thanks. I’ve updated each page to match the new specifications.-- Shirayuki (talk) 11:06, 5 January 2026 (UTC)Reply

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

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)Reply
@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)Reply
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)Reply
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)Reply
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)Reply
(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)Reply
@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)Reply
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)Reply