Project:Village Pump/Flow/2024/07

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

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

Voting to ratify the Wikimedia Movement Charter is ending soon

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello everyone,

This is a kind reminder that the voting period to ratify the Wikimedia Movement Charter will be closed on July 9, 2024, at 23:59 UTC.

If you have not voted yet, please vote on SecurePoll.

On behalf of the Charter Electoral Commission,

RamzyM (WMF) 03:45, 8 July 2024 (UTC) MediaWiki message delivery (talk) 03:45, 8 July 2024 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

U4C Special Election - Call for Candidates

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello all,

A special election has been called to fill additional vacancies on the U4C. The call for candidates phase is open from now through July 19, 2024.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members are invited to submit their applications in the special election for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

In this special election, according to chapter 2 of the U4C charter, there are 9 seats available on the U4C: four community-at-large seats and five regional seats to ensure the U4C represents the diversity of the movement. No more than two members of the U4C can be elected from the same home wiki. Therefore, candidates must not have English Wikipedia, German Wikipedia, or Italian Wikipedia as their home wiki.

Read more and submit your application on Meta-wiki.

In cooperation with the U4C,

-- Keegan (WMF) (talk) 00:02, 10 July 2024 (UTC) MediaWiki message delivery (talk) 00:02, 10 July 2024 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Website marked me as a vandal

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I was translating Help:Images page to bangla language.suddenly it says that it wouldn't save my edit as i could be a possible vandal.how to fix that. KEmel49 (talk) 20:01, 13 July 2024 (UTC)

The error message was because you translated a heading (== Requisites ==) as a non-heading (প্রয়োজনীয়তা). The equals signs should be preserved in the translation.

But this edit filter really needs a better error message. * Pppery * _{it has begun} 20:02, 13 July 2024 (UTC)

oops, i got it.and fixed it.thank you. KEmel49 (talk) 20:30, 13 July 2024 (UTC)

I've updated the abuse filter so the next time this happens it displays a clearer error message rather than calling you a vandal. * Pppery * _{it has begun} 04:51, 14 July 2024 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Looking for a better language switching solution for MediaWiki (was "Two language bars‬")

Two language bars are displayed on the Main Page. Shirayuki (talk) 11:15, 15 July 2024 (UTC)

Yeah seems far from ideal. This is a main-page, not some random page in the project and it totally breaks the aesthetic design. —TheDJ (Not WMF) (talk • contribs) 13:05, 15 July 2024 (UTC)

Yes! But it's problem template 'Main page'. I'm looking for the code that generates the bar. And I would say that the practical point of view takes precedence over the aesthetic point of view in this regard. Problem first must be analyzed. I am not motor-mouse. Want (talk) 04:34, 16 July 2024 (UTC)

CC: @Matěj Suchánek @Want for the relevant changes at https://www.mediawiki.org/w/index.php?title=Template:Main_page&action=history P858snake (talk) 21:28, 15 July 2024 (UTC)

I discussed this with Want intensively in the last days. The problem he is trying to solve is the fact that for anonymous users it is quite difficult to discover the way to switch the language. He believes there are many MediaWiki admins around the world who would benefit of having mediawiki.org as the place-to-go for documentation, yet there is a language barrier. Ideally, the user needs to do the switch only once (i.e, on the main page), then all links become language-relative and surfing the web is smooth. Special treatment for the main page is in my opinion acceptable, the wiki's main page will always be "special".

Note that I do not like having two language bars either. The original language bar (placed at the bottom which is even less accessible) links to "Template:Main page/...", this is somewhat weird. Matěj Suchánek (talk) 16:36, 16 July 2024 (UTC)

Ideally, the user needs to do the switch only once (i.e, on the main page), then all links become language-relative and surfing the web is smooth.

I agree this would be ideal. Unfortunately, mediawiki.org is quite far from this, because it uses the user interface language a lot – which defaults to English and cannot be changed by logged-out users:

• Main Page itself loads the main page translation in the UI language.
• Special:MyLanguage is used much (often through {{Ll }}), which redirects the user to the translation in the UI language (if that exists).

Those language-relative links are implemented by {{Pll }}, but that template is hardly used (353 transclusions vs 65k transclusions for {{Ll }}). For the main page, there are two possibilities:

• The current setup: Main Page itself is not translatable, transcludes a template in UI language. This makes language change and linking to translated main pages relatively difficult, but makes a reasonable guess for the user’s preferred language (at least for that of the logged-in user, since logged-out users always get English).
• What Meta does: the main page itself is translatable. This displays m:Main Page appear in English even for those who have set their UI language, but makes language switching and linking to translated main pages easier. (The languages bar is at the bottom there as well, but nothing would prevent moving it higher above.)

I prefer the latter because it doesn’t discriminate casual readers, but recognize that the former also has its advantages. Tacsipacsi (talk) 17:55, 16 July 2024 (UTC)

Solution used on Meta is optimal, because anonymous user can do switch into language prefered. If let be here as well, it be ok for all users.

But for now.

I looked at the {{Pll }} template. This alone makes 14 calls to demanding functions, and the template {{Ll }} 37. I use a similar template on my wiki which was inspired by the {{Ll }} template.

That linked page has 20 calls because it uses the trascluded man page as documentation, where it is used, including many other templates. But after commenting out the code that embeds the documentation, it has zero calls by itself and doesn't call any other template.

When I do the same thing on the {{Pll }} page, I still have one call to the heavy function and in addition the {{Page language link }}, {{Pagelang }}, {{Translatable }} templates are called , Lua Module:Template translation and call Special:MyLanguage page.

But that's still ok. I wanted to see how many calls the {{Ll }} template would have after the documentation was removed, and I was honestly horrified by them. I didn't expect that the number of calls would rise to 100 and the code would take 1.5 sec to process.

The {{Ll }} template is forgivably stupid. My version of the ll template automatically displays the translated page title if it exists, supports anchors, and also translatable alt descriptions.

But it is not applicable to MediaWiki because it uses the Extension:Variables extension.

Okay. There is another solution. The {{Ll }} template does nothing but display the translated page title if it exists, right?

The parameterized template {{Mt }} works with it – for example using this template goto my test subpage languagebar. I want do alternative for {{Ll }} in pure wikicode? Not problem!

I know where the page name is if it is translated. Want an example?

Page name the Template:Main page for czech language is Translations:Template:Main_page/Page_display_title/cs

Just test if it exists and then insert it. As here: Šablona:Main page

But the main page doesn't translate like the other pages. Its name is translated via the system message MediaWiki:mainpage ok. If I know this, I can make a very simple template for the main page:

{{#ifexist:{{ns:1198}}:{{{2}}}/Page_display_title/{{{1}}}
  |[[{{{2}}}/{{{1}}}{{!}}{{:{{ns:1198}}:{{{2}}}/Page_display_title/{{{1}}}}}]]
  |[[Special:MyLanguage/{{{2}}}{{!}}{{{2}}}]]
}}

This example code interpretation, for link to czech translation of the Template:Main_page whereis as second parametrem "cs" Šablona:Main page (Translation name of this template is not allow for translation.)

Sorry I won't be able to respond until Monday - I have to run to the train. Want (talk) 09:14, 19 July 2024 (UTC)

See also the other thread on Template talk:Main page/2024#h-Looking_for_a_consensus_design_that_improves_language_switching_discoverability-20240716180600. Jdforrester (WMF) (talk) 17:55, 18 July 2024 (UTC)

I prefer the latter because it doesn’t discriminate casual readers, but recognize that the former also has its advantages.

Is it possible to redirect though Special:MyLanguage and get a hybrid of both approaches? By that I mean could we setup a Main Page here that is #REDIRECT [[Special:MyLanguage/MediaWiki]] so that the default index.php entry point, logo, and wordmark all end up using the MyLanguage translation with fallbacks selection process to choose the real page to display? BDavis (WMF) (talk) 21:15, 18 July 2024 (UTC)

You may want to test it but I am pretty sure it isn't. Quick search in Phabricator gave me phab:T164357. Matěj Suchánek (talk) 07:12, 19 July 2024 (UTC)

Quick search in Phabricator gave me phab:T164357

The blocker is apparently that Wikimedia project wikis set $wgDisableHardRedirects to true. BDavis (WMF) (talk) 17:24, 19 July 2024 (UTC)

Setting Main Page to #REDIRECT [[Special:MyLanguage/MediaWiki]] probably doesn’t work, but through phab:T345737 I realized that setting MediaWiki:mainpage to Special:MyLanguage/MediaWiki apparently does, and that also gives best of both worlds. Tacsipacsi (talk) 19:50, 20 July 2024 (UTC)

It's a good trick, but is not universally solution for this condition, because every language version mainpage use own translation from translatewiki net.

It be functioned only is message used is '''not''' translatable by translatewiki.net

I use redirect trick it on my multilanguage wiki (default wiki language is czech) . In MediaWiki code is default fallback for pages name 'Main Page' (<code>includes/Title.php</code>) I have redirect from 'Main Page/cs' to 'Hlavní strana' - it's czech translation of the 'MediaWiki:mediawiki' included from translatewiki.net If user call 'Main Page', do system (default) redirect to 'Main Page/cs', and it do redirect to 'Hlavní strana'.

If you want use Special:MyLanguage/MediaWiki, it must be included into every language subpage MediaWiki:mediawiki, by my mind.

I just solved it 10 days ago. Because I want use for Special:SpecialPages unify translatable manual, must was solved problem with a tranlationably target. Default use MediaWiki:Specialpages. But it do problem. I solved it by insert code into MediaWiki:Specialpages-doc and not MediaWiki:Specialpages (translationed by translatewiki.net) If you are interested in the effect of this, check out my SpecialPages page and try switching the interface language to a different. The code refers to the translatable how-to use parameterized links to special pages (not yet finished). Want (talk) 08:32, 22 July 2024 (UTC)

It's a good trick, but is not universally solution for this condition, because every language version mainpage use own translation from translatewiki net.

By default, MediaWiki:mainpage is loaded in the content language, because one usually wants to have a single main page, regardless of the current user’s language settings (usually wikis are single-language). This can be overridden using $wgForceUIMsgAsContentMsg, but as far as I see, it’s not overridden on mediawiki.org. (Try clicking on the MediaWiki logo on https://www.mediawiki.org/wiki/Manual:$wgForceUIMsgAsContentMsg/cs?uselang=cs: you get to MediaWiki, not on MediaWiki/cs, which would be set by MediaWiki:Mainpage/cs.)

However, it is overridden for MediaWiki:mw-mainpage-url, which is used in MediaWiki:sidebar. Maybe after the change, the sidebar should be switched to using MediaWiki:mainpage, and MediaWiki:mw-mainpage-url should be removed. Tacsipacsi (talk) 12:55, 23 July 2024 (UTC)

Nice find @Tacsipacsi! I think this means that the pattern used on Meta is what we should try to replicate here.

I think implementing that change might look something like:

1. Move the current MediaWiki out of the way to something like MediaWiki historic main page. We will want to merge the history of the current main page into the final main page later. Once that is done then I think (please correct me if I'm wrong) we would go ahead and delete the moved current main page.
2. Move Template:Main page to MediaWiki. Because of the translations involved, there are far too many subpages to move via the UI. We should instead use Help:Extension:Translate/Move translatable page#Moving_a_large_number_of_pages to move via the job queue.
3. Change MediaWiki:Mainpage to Special:MyLanguage/MediaWiki so that things that target the default main page will link to the version of MediaWiki matching the user's preferred UI language.
4. Merge the history of MediaWiki historic main page (the moved version of the current [[MediaWiki]]) into the newly moved MediaWiki (the moved version of the current [[:Template:Main page]]) so that browsing the history will start from Special:PermanentLink/2368 (or Special:PermanentLink/1) and proceed until the first edit of Template:Main page.
5. Delete MediaWiki historic main page to clean things up.

Is my reasoning correct? Is this too weird or scary to try? BDavis (WMF) (talk) 00:48, 22 July 2024 (UTC)

Is my reasoning correct?

Yes!

Is this too weird or scary to try?

No. The faster the change is made, the less it will hurt. It's my experience. My result: Your proposal it's the only right way. I support it. The current problems (with language bars for example) are caused by the fact that the main page is chasing the {{Zh other }} template, which is created only for Chinese language fallback.

Order points 1. (Move the current MediaWiki out of the way to something like MediaWiki historic main page.) and 2. (Move Template:Main page to MediaWiki) it's right. But watch out!

I have experience with moving translated pages. If a page is translated as before using Extension:Translate, existing language subpages can cause a problem. I made this change in my wiki a long time ago, when weren't that many pages. First, I gradually moved the language subpages to another namespace, and only then did I move the default translated page with translationed subpages to new name.

The point is that the Extension:Translate checks whether the move causes a problem. Maybe today it already allows existing language subpages to be replaced, but I'm not sure.

To point 3 (Change MediaWiki:Mainpage to Special:MyLanguage/MediaWiki)

Thought in links? Or where? In templates? Or in the MediaWiki code? Want (talk) 07:51, 22 July 2024 (UTC)

To point 3 (Change MediaWiki:Mainpage to Special:MyLanguage/MediaWiki)

Thought in links? Or where? In templates? Or in the MediaWiki code?

The change I am proposing is to the MediaWiki:Mainpage message which is used internally by MediaWiki to determine which page to serve when a URL without a page like https://www.mediawiki.org/ is requested and also to set the target page for the site logo and the "Main page" sidebar link. See Manual:Main Page for more information.

The use of Special:MyLanguage in the Mainpage message is what Meta does as @Tacsipacsi reported above. BDavis (WMF) (talk) 20:32, 22 July 2024 (UTC)

The point is that the Extension:Translate checks whether the move causes a problem. Maybe today it already allows existing language subpages to be replaced, but I'm not sure.

This is exactly why I suggested using the moveTranslatableBundle.php maintenance script recommended at Help:Extension:Translate/Move translatable page#Moving_a_large_number_of_pages rather than attempting the move via the MediaWiki UI directly. I am almost certain that a normal move will be blocked. If for some reason a normal move is not blocked, I believe it will timeout before actually moving all subpages. BDavis (WMF) (talk) 20:39, 22 July 2024 (UTC)

Template:Main page

This translatable page consists of over 500 pages. Due to reliability issues, moving translatable pages that consist of more than 500 pages cannot be done through the user interface. Please file a Phabricator task and fill in the fields of the form to request the system administrators to perform the page move on your behalf. Shirayuki (talk) 21:52, 22 July 2024 (UTC)

The point is that the Extension:Translate checks whether the move causes a problem. Maybe today it already allows existing language subpages to be replaced, but I'm not sure.

This point is about the subpages of the target page. I don’t think Translate got smarter in this regard; if there are pages in the way (and there are about a hundred of them), the move won’t produce the result you want, if succeeds at all. Probably all of these pages have to be moved away (but do make sure not to move non-language subpages like MediaWiki/test) and then merged back. Or not merged: the merge may cause more harm than good; I haven’t checked if the page histories are sufficiently apart. (If histories of two pages are merged that have been edited simultaneously, the result is a huge mess, with irrelevant diffs and IIRC even byte changes in the history not corresponding to the changes shown by the (prev) diff link.) Tacsipacsi (talk) 12:55, 23 July 2024 (UTC)

I tryed moving pages on my wiki. Subpages of MediaWiki (Main page) listed by Special:PrefixIndex/MediaWiki/ must be moved by moveBatch.php, because script moveTranslatableBundle.php from Extension:Translate functioned only if the page is translatable.

Must be prepared list for it and the MediaWiki moving realize do as last. I visited all subpages of MediaWiki page with other name then language code:

• Gallery of extensions - is only redirect
• Homepage improvements 2018 - is linked from Phabricator and talk pages
• Homepage redesign - is linked from Phabricator and talk pages
• intro - redirect from 31.8.2005, which is linked only from two user pages
• latest - redirect to MediaWiki 1.32 (last edit 14.4.2019)
• sandbox - invalid link, created October 2023 linked only from two topics

After move pages with languagecode name, can be used script moveTranslatableBundle.php from Extension:Translate which move 'Template:Main page' to 'MediaWiki'.

Count 'Template:Main page' subpages is 1520. It's scary because then translatable page use 22(!) translatable templates:

1. Template:Main page/admins text
2. Template:Main page/admins title
3. Template:Main page/current versions
4. Template:Main page/devs text
5. Template:Main page/devs text2
6. Template:Main page/devs title
7. Template:Main page/download
8. Template:Main page/howto contribute link
9. Template:Main page/include
10. Template:Main page/intro
11. Template:Main page/new opportunities
12. Template:Main page/news title
13. Template:Main page/old news link
14. Template:Main page/site news
15. Template:Main page/sitelink1
16. Template:Main page/sitelink2
17. Template:Main page/sitelink3
18. Template:Main page/sitelink4
19. Template:Main page/sitelink5
20. Template:Main page/users text
21. Template:Main page/users title
22. Template:Main page/welcome

See Special:PrefixIndex/Template:Main page/

I have only word for it – hegeš. By my mind, is better leaved the Template:Main page and create completly new translatable MediaWiki page. Want (talk) 13:49, 24 July 2024 (UTC)

Of course, with the use of existing translatable pages, used as templates now. Want (talk) 13:57, 24 July 2024 (UTC)

(If this is done, as a monolingual English speaker I'm not qualified to comment on its merits)

The right thing to do with the subpages is probably to use Special:MergeHistory to merge them to the new pages, then delete any edits that don't merge, then do the move. That ensures no harm can be done. * Pppery * _{it has begun} 16:32, 23 July 2024 (UTC)

There are also a bajllion unused templates at Special:PrefixIndex/Template:Main page from an old pre-Translate design of the Main Page. Those should not be moved to mainspace, and probably should just be deleted. * Pppery * _{it has begun} 16:37, 23 July 2024 (UTC)

Issue with changing user interface language

After changing the user interface language to English, I can no longer change it to another language. Shirayuki (talk) 22:39, 16 July 2024 (UTC)

Why? No option in Special:Preferences? Selecting another language does nothing? Ciencia Al Poder (talk) 09:57, 17 July 2024 (UTC)

When I try to switch languages using the Universal Language Selector, nothing happens. I just realized that I can change it in Special:Preferences. Shirayuki (talk) 10:33, 17 July 2024 (UTC)

I think this is related to phab:T368595. Leaderboard (talk) 06:46, 18 July 2024 (UTC)

Exception during translation administrator operations

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When attempting to perform translation administrator-related operations, I encounter the following exception:

[3a0b003a-e559-4ac7-9c2d-cd2e0c97b61e] 2024-07-16 22:40:32: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

Shirayuki (talk) 22:54, 16 July 2024 (UTC)

phab:T370219 * Pppery * _{it has begun} 22:58, 16 July 2024 (UTC)

This issue has been resolved. ADancy (WMF) (talk) 14:57, 17 July 2024 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Reporting problematic translation

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Special:Contributions/103.127.86.173 , probably vandalism - seems to be adding translations in different languages. --~aanzx · ✉ · © 03:53, 17 July 2024 (UTC)

Clump took care of it. Thanks! Ciencia Al Poder (talk) 09:55, 17 July 2024 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Wikimedia Movement Charter ratification voting results

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello everyone,

After carefully tallying both individual and affiliate votes, the Charter Electoral Commission is pleased to announce the final results of the Wikimedia Movement Charter voting.  

As communicated by the Charter Electoral Commission, we reached the quorum for both Affiliate and individual votes by the time the vote closed on July 9, 23:59 UTC. We thank all 2,451 individuals and 129 Affiliate representatives who voted in the ratification process. Your votes and comments are invaluable for the future steps in Movement Strategy.

The final results of the Wikimedia Movement Charter ratification voting held between 25 June and 9 July 2024 are as follows:

Individual vote:

Out of 2,451 individuals who voted as of July 9 23:59 (UTC), 2,446 have been accepted as valid votes. Among these, 1,710 voted “yes”; 623 voted “no”; and 113 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 73.30% voted to approve the Charter (1710/2333), while 26.70% voted to reject the Charter (623/2333).

Affiliates vote:

Out of 129 Affiliates designated voters who voted as of July 9 23:59 (UTC), 129 votes are confirmed as valid votes. Among these, 93 voted “yes”; 18 voted “no”; and 18 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 83.78% voted to approve the Charter (93/111), while 16.22% voted to reject the Charter (18/111).

Board of Trustees of the Wikimedia Foundation:

The Wikimedia Foundation Board of Trustees voted not to ratify the proposed Charter during their special Board meeting on July 8, 2024. The Chair of the Wikimedia Foundation Board of Trustees, Nataliia Tymkiv, shared the result of the vote, the resolution, meeting minutes and proposed next steps.  

With this, the Wikimedia Movement Charter in its current revision is not ratified.

We thank you for your participation in this important moment in our movement’s governance.

The Charter Electoral Commission,

Abhinav619, Borschts, Iwuala Lucy, Tochiprecious, Der-Wir-Ing MediaWiki message delivery (talk) 17:51, 18 July 2024 (UTC)

Add Chart.js as a hidden gadget

Hi! I'd like to add the (minified) code of https://www.chartjs.org as a hidden, disabled gadget here at MediaWiki.org, in order to be able to load it and use it for generating charts with other gadgets (first use case would be wikiprojects in the Spanish Wikipedia and then Wikiversity:Wikidebate). Sophivorus (talk) 13:06, 22 July 2024 (UTC)

I think there is a CDN on the toolforge repositories, avoiding that everybody touching the JS will submit fingerprint and IP address and context to an external website.

Basically there is no need to make an official MediaWiki.org gadget. You can establish a user script and load it wherever you want. Other people can load on their own risk your JS if they trust in you by .js preferences. PerfektesChaos (talk) 14:21, 1 August 2024 (UTC)

Ah yes, I found it, I didn't know about that! Just to clarify, I wasn't asking to load ChartJS from their CDN, but rather copy-pasting the ChartJS code into a new gadget. But anyway, loading from the toolforge CDN seems even better, so I think I'll go with that, thanks! Sophivorus (talk) 14:30, 1 August 2024 (UTC)

Note that hot-loading from the Toolforge CDN on a production Wikimedia site without user opt-in consent is a privacy policy violation, as the Toolforge privacy policy is different. Jdforrester (WMF) (talk) 09:46, 2 August 2024 (UTC)

Hmm, then how about copy-pasting the ChartJS code to a MediaWiki.org gadget (hidden and disabled by default) so I can load it from there? Sophivorus (talk) 21:20, 2 August 2024 (UTC)

Couldn’t cdnjs.toolforge.org have an own privacy policy, which is as strong as the production wiki one? Since its very goal is to be a privacy-friendly CDN, it would be a straightforward decision, allowing gadgets to use it. Or does the Toolforge infrastructure itself (i.e. bits that are out of the cdnjs tool’s control) do things that aren’t allowed on production wikis? Tacsipacsi (talk) 11:04, 4 August 2024 (UTC)

I just found out about the plans to enable Extension:Chart which would use Apache eCharts. Thus, I modified my code to use the eCharts library rather than ChartJS. When the extension is enabled, I'll be able to use the eCharts resource bundled with it. But in the meantime, I'd still like to copy-paste the eCharts minified code to a hidden, disabled gadget here at MediaWiki.org. Any concerns or objections?

Regarding Tacsipacsi's suggestion, allowing to use resources from the Toolforge CDN would be a huge lvl up for gadget developers! Sophivorus (talk) 13:27, 6 August 2024 (UTC)

On gadget: You could provide such external library (if license would permit, which would be required for official MediaWiki.org gadget as well) as your own user page.

On privacy issues: The CDN at our toolforge is avoiding that any external sysop could track IP address and browser fingerprint on every usage (accessing, verifying and loading the code).

• Inside such libraries there might be callbacks to the external origin. In the huge amount of CDN libraries nobody at WMF can check this for all frequent updates.
• If someone is using deliberately a toolforge tool it is taken into account that cookies for external might be created, and externals are contacted.
• However, toolforge developers should make it obvious if they know that non-WMF communication might happen, and no tool should be offered by the way on any WMF site if external access is known. PerfektesChaos (talk) 17:09, 8 August 2024 (UTC)

Can't un-blank

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I was trying to un-blank the page at

Reading/Web/Accessibility for reading/Reporting/en.wikipedia.org

but it told me

>We're sorry, your edit was not saved as it matched the rule: Crosswiki abuse and Anti-harassment. This usually happens because the type of edit you made is often done by vandals and spammers.

The blanking itself happens often and by brand-new accounts. Wizmut (talk) 08:50, 24 July 2024 (UTC)

I can't see the filter itself to see why, but I have rollback the edit. P858snake (talk) 08:57, 24 July 2024 (UTC)

I've set up a local edit filter to block edits that delete more than 10,000 bytes of content by new users, which will prevent this from happening again. * Pppery * _{it has begun} 15:42, 24 July 2024 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Copy documentation to Wikibase/Docker and make it translatable

Copying the Wikibase Suite Deploy documentation on GitHub to Wikibase/Docker and then making it translatable could be useful for users of other languages. Shirayuki (talk) 21:59, 26 July 2024 (UTC)

In theory you're right. In practice the devs unlikely to have the will or effort to maintain documentation in multiple places and if they prefer it on GitHub any local translations will just bitrot away. * Pppery * _{it has begun} 22:05, 26 July 2024 (UTC)

Shouldn't this thread be on that work's talk page, Talk:Wikibase/Docker? Whatever the rest of us may think, it's their documentation and their decision on what should live where. Jdforrester (WMF) (talk) 15:46, 29 July 2024 (UTC)

Vote now to fill vacancies of the first U4C

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Dear all,

I am writing to you to let you know the voting period for the Universal Code of Conduct Coordinating Committee (U4C) is open now through August 10, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

Please share this message with members of your community so they can participate as well.

In cooperation with the U4C,

RamzyM (WMF) 02:46, 27 July 2024 (UTC) MediaWiki message delivery (talk) 02:46, 27 July 2024 (UTC)

Help:Extension:Translate/Page translation administration

The following descriptions on Help:Extension:Translate/Page translation administration seem contradictory, don't they?

• The previously written "For translators these will show up only as $name, and in translation pages will automatically be replaced by the value defined in the translatable page (so they are global constants across all its translation pages)."
• The recently added "Note that variables are not shared between different translation units. If you want to use the same variable in more than one unit, you must repeat the code in each unit. You can use the same name." Shirayuki (talk) 22:57, 28 July 2024 (UTC)

It’s indeed confusing, but not actually contradictory:

• Translation variables are shared between translation pages, i.e. languages.
• Translation variables aren’t shared between translation units, i.e. parts of the source page (which, just to further increase confusion, is ‘officially’ called the translatable page). Tacsipacsi (talk) 23:11, 28 July 2024 (UTC)

It's a matter of terminology.

Translation variables are shared between language subpages

and to

... just to further increase confusion, is ‘officially’ called the translatable page

When I try someone explains how it works, I talk about the original page (translatable page) and the language subpages (translations).

Language of the origin page must be changed by content language, because the origin language is a key to translation direction. Language of my wiki is Czech, but some pages has a origin in the english or polish language and language of page must be changed. If you don't, it starts causing problems. Want (talk) 14:57, 29 July 2024 (UTC)

Got it. But calling something that is shared only between the source text and its translations within a single translation unit global constants seems like an overstatement to me. Shirayuki (talk) 21:23, 29 July 2024 (UTC)

Yes, I agree.

I've mentioned several times in various posts that I write my own documentation shere show the examples using of code and really effects on the content of the translatable page.

Translation variable as called here, is really a placeholder for a piece of code taken out of translation.

I must everytime found a optimal terminology of the new technologies, because I do parallel work with three different languages. The MediaWiki system changes over time, and I have to keep changing the content of the documentation accordingly.

Manual about preparing of translatable pages I was can able to change after MW 1.39 upgraded, because syntax of tag <tvar> changed and now is before me the upgrade to MW 1.43 (LTS) and I'm honestly dreading it because here I see what has been broken within a woke culture. Sometime I think if any developer thinks about consequences of changes.

For example, excluding the img tag from the wikicode meant for me looking a new solution, which of course I had to program myself. For it I started maitaining of the Extension:EImage, (which I was continually use), implemented functions which can do it now, and pushed changes into official git repository. Every can use this code, if want. But spended time by coding missing me. Want (talk) 10:35, 30 July 2024 (UTC)

Uninstall Extension:NearbyPages?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Seems to be an unnecessary extension. ToadetteEdit (talk) 08:47, 31 July 2024 (UTC)

what do you mean ? —TheDJ (Not WMF) (talk • contribs) 08:55, 31 July 2024 (UTC)

This site really doesn't benefit from the extension. Why would one find nearby places on a wiki that does not deal with locations? ToadetteEdit (talk) 09:27, 31 July 2024 (UTC)

They won't. But it isn't known to hurt having it enabled, helps testing functionality and most of all; Any exception to the general wikimedia configuration further complicates the already complex wikimedia setup. —TheDJ (Not WMF) (talk • contribs) 11:18, 31 July 2024 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.