Project:Village Pump

This page is only for discussing issues related to MediaWiki.org site.

To get help with MediaWiki software, ask on Project:Support desk.

I can't translate "Developers wanting to install MediaWiki locally to have an environment for development of MediaWiki core or extensions should also read How to become a MediaWiki hacker for further instructions." from the Download page. What should I do?

I've made that text translatable

Hi there, I've been trying to implement namespace-removal for {{Ll }}'s translated link names. You can see a problem at User:Aaron Liu/sandbox. The first line produces a blank, while the second line, which is just the first line's both cases substituted, produces its stuff correctly. What's wrong here?

There seems to have been an issue with the pipes in your #ifeq:, which I've fixed.

Yes, due to improper conversion when the UI language differs from the language to convert to in certain cases such as Special:Permalink/5860177. Other reasons include the desire for translation units to be independent of each other.

Category:Pages using deprecated NoteTA template claims that {{NoteTA}} is deprecated and to use {{LC zh}} instead. But the latter requires repetitively adding conversions for the same thing, while the former replaces every instance while being able to include common conversions.

@Winston Sung Pardon the ping, but do you know why it's deprecated?

The tracking category was added to Module:NoteTA, with only the comment "Add tracking category", by 122.100.88.89 (talk · contribs) on February 25, and the same IP then created the category a few minutes later, without comment.

@122.100.88.89: can you explain the reasoning for this unilateral and undiscussed (as far as I can see) deprecation?

Since this was unilateral, could I revert it? The IP seems knowledgeable, though.

Please note that IPs cannot be pinged, so it’s unlikely that 122.100.88.89 will notice this topic.

I've put a talkback template on their talk page.

The IP seems to also have mass-edited translations to port them to LC zh. Should we nuke these?

I think very few people other than you and the IP know about this well enough to have an informed opinion so.

@Aaron Liu: It is because NoteTA would mess up translation memories, so to ensure the translation memory can provide correct results with proper language conversion, always specify the translation for different variants.

But isn't NoteTA the translation memory? I can see nowhere else with a translation memory.

No. Translation memory is separated from the NoteTA template/module.

Translation memories is where the translation suggestions came from.

(the right part in the page translation UI)

Oh wait, the translation memory means the one on the right, doesn't it? Would it still be messed up if every page used NoteTA?

Edit: Thanks Winston for confirming the former. But does being messed up mean it displays improperly or wouldn't convert like the original page? In the latter case, would using NoteTA on these pages too solve that?

Would it still be messed up if every page used NoteTA?

The problem would still exist:

• NoteTA being place on one of the translation unit on a page, causing page-dependent NoteTA template transclusions showing up in different translation units' translation suggestions.
• NoteTA cannot always placed in the first translation unit of a page due to different types of translation units (e.g., syntaxhighlight, template parameters like the Localized_link template).
• Translators ignore the one-to-multi conversion and use the translation suggestion with broken language conversion result.
• NoteTA template being used in templates causing duplicated page status indicator

Also, every translation unit should be able to give correct language conversion result regardless of what the previous translation units were.

Another reason is the broken syntax in cross-page-language transclusion.

I'm not sure why we would need to transclude a Chinese page onto a page of another language as long as the title of the page uses LC zh.

See Main Page as an example.

Shouldn't the main page always be viewed in the user's language?

The Main Page template /zh translation page has the page language code in 'zh'.

Sorry for dragging this out a bit, but could you clarify what the problem with the main page is?

The Main Page has been migrated to LC zh, but here's a brief explaination:

Conversion-zh use UI-language-only detection and output respective variant contents.

If users view the template (usually by clicking the "other language" link) while there are inconsistency between the output language (UI language, the 'en' when not logged in would output 'zh-hans') and the variant language ('zh-Hant-TW' / 'zh-tw'), it will give out incorrect conversion results (e.g., '信息' vs. '資訊').

At this case, you can neither add NoteTA (as it will become many directly-exposed '-{H' tags) nor using native syntax (same reason).

Here's the URL with the problem:

https://www.mediawiki.org/wiki/Template:Main_page/zh?oldid=5860177&uselang=en&variant=zh-tw

You could compare it with the latest version to see the correct conversion result:

https://www.mediawiki.org/wiki/Template:Main_page/zh?uselang=en&variant=zh-tw

(permalink: https://www.mediawiki.org/wiki/Template:Main_page/zh?oldid=6306128&uselang=en&variant=zh-tw )

Also, using the LC_zh template in the page display title translation units is meant to solve the Localized_link template problem.

Wasn't the problem with removing namespaces?

Both the Main Page cross-language-page transclusion problem and the hide namespace problem.

As you can see, most of them were to ensure all translation units having consistency, always giving correct conversion results independently (instead of relying on other translation units with NoteTA).

Could Module:Used by/data.json be adjusted to include the RealMe extension in the Miraheze portion? I have tried to do it myself, but I am filtered by "Operator873's Filter". This was confirmed by a Miraheze engineer in their Discord. Unfortunately, I am unable to link to that discussion without being filtered. ~~~~

Done.

You can find this message translated into additional languages on Meta-wiki.

More languages • Please help translate to your language

Dear all,

This year, the term of 4 (four) Community- and Affiliate-selected Trustees on the Wikimedia Foundation Board of Trustees will come to an end [1]. The Board invites the whole movement to participate in this year’s selection process and vote to fill those seats.

The Elections Committee will oversee this process with support from Foundation staff [2]. The Board Governance Committee created a Board Selection Working Group from Trustees who cannot be candidates in the 2024 community- and affiliate-selected trustee selection process composed of Dariusz Jemielniak, Nataliia Tymkiv, Esra'a Al Shafei, Kathy Collins, and Shani Evenstein Sigalov [3]. The group is tasked with providing Board oversight for the 2024 trustee selection process, and for keeping the Board informed. More details on the roles of the Elections Committee, Board, and staff are here [4].

Here are the key planned dates:

• May 2024: Call for candidates and call for questions
• June 2024: Affiliates vote to shortlist 12 candidates (no shortlisting if 15 or less candidates apply) [5]
• June-August 2024: Campaign period
• End of August / beginning of September 2024: Two-week community voting period
• October–November 2024: Background check of selected candidates
• Board's Meeting in December 2024: New trustees seated

Learn more about the 2024 selection process - including the detailed timeline, the candidacy process, the campaign rules, and the voter eligibility criteria - on this Meta-wiki page, and make your plan.

Election Volunteers

Another way to be involved with the 2024 selection process is to be an Election Volunteer. Election Volunteers are a bridge between the Elections Committee and their respective community. They help ensure their community is represented and mobilize them to vote. Learn more about the program and how to join on this Meta-wiki page.

Best regards,

Dariusz Jemielniak (Governance Committee Chair, Board Selection Working Group)

[1] https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_elections/2021/Results#Elected

[2] https://foundation.wikimedia.org/wiki/Committee:Elections_Committee_Charter

[3] https://foundation.wikimedia.org/wiki/Minutes:2023-08-15#Governance_Committee

[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_committee/Roles

[5] Even though the ideal number is 12 candidates for 4 open seats, the shortlisting process will be triggered if there are more than 15 candidates because the 1-3 candidates that are removed might feel ostracized and it would be a lot of work for affiliates to carry out the shortlisting process to only eliminate 1-3 candidates from the candidate list.

MPossoupe_(WMF)19:56, 12 March 2024 (UTC)

I asked an available Steward for a Glock, that was granted. Now there's some cleanup needed: Special:Contributions/Furkan.4730. Ciao, M7 (talk) 20:37, 12 March 2024 (UTC)

Ok, seems ok. Thanks to User:JJMC89. --M7 (talk) 20:38, 12 March 2024 (UTC)

Special:Contributions/2409:40E1:106F:AA47:8000:0:0:0 --M7 (talk) 07:55, 20 March 2024 (UTC)

Gadget has been de-listed from the definitions configuration page, and emptied to disable its functionality for people cross-loading it, but not deleted.

What it does is CamelCase the page title. It seems to be some admin having some fun in 2014, and is ancient cruft in 2023. I suggest it be disabled. Any objection?

Pinging @Krinkle as the creator.

Do you mean "delete" instead of "disable"? The gadget was created as a demo during a MediaWiki workshop, I believe. It is disabled by default. I don't think it was ever enabled.

Strangely, it is enabled by 1000+ users per Special:GadgetUsage, though fewer than 10 of which are active users. In any event, I've deleted it now, since it was indeed not meant as a useful tool by itself.

What you did is what I meant - the use of the term delete IMO would have implied the page MediaWiki:Gadget-workinprogress.js be deleted, which isn't necessary.

Hello. This is to notify the community that there is an ongoing global ban proposal for User:Slowking4 who has been active on this wiki. You are invited to participate at m:Requests for comment/Global ban for Slowking4 (2). Thank you. Seawolf35 (talk) 19:48, 14 March 2024 (UTC)

Tracked in Phabricator
Task T355445

Hello! It seems to me that it is a little wrong that 'user' users can edit manual tags, since such vandalism is easy to overlook and quite difficult to rollback: https://www.mediawiki.org/w/index.php?title=Special:Log&page=Special%3ALog%2Fpagetranslation&type=tag

I support this. There's another right called "applychangetags" that won't affect the ability to tag their own edits when using gadgets to perform actions.

Agreed. We've had a years-long history of vandalism using this feature not being noticed or reverted.

+1; I blocked the most recent user vandalizing via tags but didn't go further with cleanup when I saw how many tags were added, we definitely shouldn't allow the cleanup problem to be compounded further.

Also as a general note, it's not just pagetranslation stuff that gets vandalized with tags: Special:Log/tag.

Support. And I feel this should probably be removed from 'user' user group by default. Is there a reason to enable it for users when we already have 'applychangetags'?

Tracked in Phabricator
Task T355639

@94rain, I agree with you, the right should be removed from regular users by default.

I've been wondering the whole time why we can do that 🤣

I noticed that many translatable templates use code like {{#invoke:Template translation|renderTranslatedTemplate|template=<!--Template name-->|noshift=1|uselang={{int:lang}}}}. However, then translation will not show properly when using interface language like zh-cn or other variants of Chinese (zh), because templates were translated to Chinese only in zh.

For example, the Chinese translation of sandbox header only shows in (zh) but not in (zh-hans), (zh-cn), (zh-hant) etc.

I thought of two maybe practical solutions:

1. Replace all {{int:lang}} with {{Zh other}}. This may be a big project.
2. Edit Module:Template translation. When uselang input variants of Chinese(like zh-hans, zh-cn, zh-hant etc.), automatically change it into zh. This works like {{Zh other}}, and may be easier.

Hope someone would help with this problem.

(Sorry for my poor English)

I think there are some other languages with variants too (File:MediaWiki fallback chains.svg). I'd prefer a more generalized template name. Full support can be added over time.

Oh, maybe you are right. I did't noticed that.

You can edit Module:Template translation/sandbox and I can review and deploy.

Sorry, but I can't write Lua… Besides, according to the words of 94rain, I think maybe we need a separate template or module to deal with the Language fallback, and maybe I'm not able to make it.