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.

The filter is working correctly.

I was trying to add back a talk page section on Writ Keeper's talk page (Re: IRC) that was reverted by XXBlackburnXx but it got stopped by the global abuse filter

I haven't been able to get into an agreement with P858snake (Topic:Y8gnvyzbtx9d9ugw), but I'm concerned with this change. I don't know of another wiki that takes such a punitive approach (i.e, allowing very few users to create a local userpage), and in my opinion, suitably established users (say those with 100 edits at least) should be able to create local pages here. Hence putting this here for discussion.

I support having the filter in its current state. My impression from watching the abuse log is that filter 95 blocks of attempts at creating user pages that are meaningful are rare, and blocks of attempts at creating user pages that specifically meaningful and relevant to this wiki in particular and wouldn't be better off in meta or elsewhere are pretty much non-existent. To back that up somewhat at least I looked at the filter 95 blocks currently showing in the first page of the abuse log:

• 31 were new users, less than a few days old
  • 16 spam
  • 9 nonsense/gibberish/test
  • 6 personal info (name/cv/email)
• 5 were from older accounts, at least a few weeks old (but only 1 had a large number of edits overall)
  • 1 blank
  • 2 off-topic article
  • 1 personal info (street address)
  • 1 spam

From that sample it does seem that a weaker filter would still mostly be effective, but it also does not support any particular need to weaken the filter either.

Hi all, I would need of someone with the proper rights to mark correctly this page for translation, as of now only the titles can be translated to other languages, thanks

Shirayuki has taken care of it

Hi, I'm here because I read

"If you believe you received this message in error, please file a request at Project:Village Pump, explaining what you were trying to do."

I've been on Translate - MediaWiki

It would be very helpful is you could support me to continue. ~~~~

This was due to the page being prepared for translation incorrectly, in a way that caused an abuse filter false positive when new editors tried to translate it.

I've fixed the translate syntax so this shouldn't happen again.

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

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.

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!

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.

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?

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?

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!

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.

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

Dear all,

The voting period for the Universal Code of Conduct Coordinating Committee (U4C) is closing soon. It is open through 10 August 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility. If you are eligible to vote and have not voted in this special election, it is important that you vote now.

Why should you vote? The U4C is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community input into the committee membership is critical to the success of the UCoC.

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

In cooperation with the U4C,

-- Keegan (WMF) (talk) 15:29, 6 August 2024 (UTC)

As a new admin to my wiki site, I am failing to figure out how to enable a proper approval process.

I see that a few extensions are available, and Extension:FlaggedRevs seems the best suitable. However, its page has a warning advising against its usage, but does not provide an alternative choice. I also see a few others:

• Extension:Approved_Revs (seems to be incompatible with some extensions, as it is stated on their page)
• Extension:ContentStabilization (it produces some errors in the wgDebugLogFile, and on their pages it says that they use FlaggedRevs)

The main site, Wikipedia, also has Extension:FlaggedRevs installed as shown on their page: Special:Version.

So, what MediaWiki is using on their site? I would like to install and use an appropriate extension that will be eventually in use everywhere. Could you advise?

Thank you so much!

--~~~~

This wiki does not use any of the aformentioned extensions. It just lets edits get published unapproved and relies on humans patrolling recent changes to revert those that shouldn't be made. You can see what extensions are installed on a given wiki at special:Version.

So, what would you recommend to use, the one which would likely be most popular in the future? Open source concept might be working fine for MediaWiki, because it is a special site, but I need some CMS.

Page https://meta.wikimedia.org/wiki/Flagged_Revisions#Enabling claims that FlaggedRevs are abandoned by the developers, but page https://gerrit.wikimedia.org/r/q/project:mediawiki/extensions/FlaggedRevs shows recent activity up to today.

Was FlaggedRevs abandoned, but now revived? What other wiki sites most commonly use? What would you recommend?

This is not really the right place to ask.

Both flaggedrevs and approvedrevs are popular. ApprovedRevs is a bit simpler which some people like. FlaggedRevs is not really being actively developed anymore, but ocassional fixes are still made when issues pop up. Ultimately its up to you. Both are reasonable choices.

Seems to be an unnecessary extension.

what do you mean ?

This site really doesn't benefit from the extension. Why would one find nearby places on a wiki that does not deal with locations?

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.

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."

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

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.

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.

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.

Copying the Wikibase Suite Deploy documentation on GitHub to Wikibase/Docker and then making it translatable could be useful for users of other languages.

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.

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.