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.

Is there a way to set which variant Chinese pages are converted to by default? Currently it's always "Don't convert".

Links at Extension status were not localized as they are supposed to be parameter names.

Could someone go and make the displays of the links in the table at Extension status translatable?

If you mean the Release status column: I believe it aims to list the possible parameter values, which are by nature untranslatable (since they’re always entered on the English translatable page rather than on the translation pages).

Ahh... that makes sense.

See Extension:DiscussionTools/Comparison/zh. Notice occurrences of "可视化". Click on "不转换" and select "繁體". Notice how two of the occurrences have been converted to "視覺化" yet another was converted to "可視化". Select "臺灣正體" from the dropdown. Notice that all occurrences have now been converted to "視覺化".

I believe this is because the first two occurrences are converted by {{LC zh}}, which was made for this wiki, and the last occurrence is converted by {{NoteTA}}, which was copied from zhwiki, which doesn't have "简体" or "繁體" as options for conversion. As a result, NoteTA probably doesn't recognize these two converting modes. Could someone fix that?

Everytime i try to publish a written piece, i am greeted with this error. The error says:

"Editing the main namespace is limited for new users. This site is for documenting the MediaWiki software. It is not the wiki that you set up for your class, workplace, or personal use, nor is it Wikipedia. "

How do i face this issue? I'm new to Mediawiki.

MediaWiki.org is for the MediaWiki software. See Project:About. Please go to Wikipedia to create your articles.

I read it, and i couldn't find anything.

Click this to start your article on Wikipedia

Although the content your tried to post was not suitable for Wikipedia either, among other things for entirely lacking references.

Please actually read the error you received. The content you are attempting to post is not appropriate for this wiki.

I don't understand, it's a fictional country.. How can it not be appropriate?

In Extension:TorBlock, there has been 3 edits by a user which seems to have messed up the page. I couldn't do a rollback since that seems to require admin (which I do not have), so I'm asking for someone to rollback the messy edits.

Thanks for the heads up, done.

Hi! For some time now, I've been slowly developing c:Help:TemplateScripts, a method for extending the functionality of templates with JavaScript. For obvious reasons, template scripts must be located at the MediaWiki namespace (and have the "TemplateScript-" prefix, see the code below) so they require community consensus and an authorized user to get there. Template scripts are currently available at the Spanish Wikipedia, Commons, and the Spanish and English Wikiversity. I'd like to propose enabling them here at MediaWiki.org too, for the following reasons:

• I'd like to turn the Synchronizer tool into a template script so that it loads automatically.
• I'd like to migrate and centralize here at MediaWiki.org the existing template scripts and documentation, per being more adequate than Commons.
• To attract more interest and developers, since MediaWiki.org is probably the most technically oriented of the Wikimedia wikis.

To enable TemplateScripts, the following code should be added to MediaWiki:Common.js and MediaWiki:Mobile.js:

// TemplateScripts are JavaScript scripts that extend the functionality of templates
var templatescripts = [];
$( '[data-templatescript]' ).each( function () {
	var script = $( this ).data( 'templatescript' );
	if ( script && !templatescripts.includes( script ) && /^[^&<>=%#]*\.js$/.test( script ) ) {
		templatescripts.push( script );
		script = encodeURIComponent( script );
		mw.loader.load( '/wiki/MediaWiki:TemplateScript-' + script + '?action=raw&ctype=text/javascript' );
	}
} );

Thoughts? Support? Objections? Cheers! Sophivorus (talk) 01:27, 12 July 2023 (UTC)

I’d like to rather have an official solution, e.g. phab:T241524. I’m not strongly opposed to using this script in the meantime, but I have the feeling that the more temporary solutions we have, the less likely is that someone takes the time and effort to create an official one.

By the way, I couldn’t find traces of this on Commons except for the help page, are you sure it works there?

Hi! You're right, it's not enabled in Commons (I think at some point it was). As to an official solution, I'd love to see one too! However, that may still require several years (or never come to be, like with global modules and now graphs). Also, by the looks of it, migrating from TemplateScripts to an official solution with a parser function that loads gadgets (as suggested by phab:T241524) seems rather easy. Finally, enabling and developing TemplateScripts now may actually help an official solution come about, by building a small community of involved developers and giving WMF developers some real world examples of its potential. Cheers!

If you want to pave the path for the official solution (and also in order to make template scripts more efficient by taking advantage of minifying), it’d be helpful if TemplateScript was also based on gadgets rather than random JS pages:

$( '[data-templatescript]' ).each( function () {
    var script = $( this ).data( 'templatescript' );
    if ( script ) {
        mw.loader.load( 'ext.gadget.templatescript.' + script );
    }
} );

Also, to make it compatible with VisualEditor, live preview etc., it should use the wikipage.content hook:

mw.hook( 'wikipage.content' ).add( function ( $content ) {
    $content.find( '[data-templatescript]' ).each( function () {
        var script = $( this ).data( 'templatescript' );
        if ( script ) {
            mw.loader.load( 'ext.gadget.templatescript.' + script );
        }
    } );
} );

(This doesn’t unload no longer necessary template scripts, but at least loads those that become necessary after the initial page load.)

Excellent ideas! I just implemented them at the Spanish Wikiversity to test them out, see es:v:Special:Gadgets, es:v:MediaWiki:Common.js and the [add objection] buttons at es:v:Wikidebate/Cannabis for the end result. I'll implement them at the English Wikiversity and Spanish Wikipedia soon, if no issues, concerns or further changes follow. These are exactly the kind of ideas for which I think bringing TemplateScripts to MediaWiki.org is the way to go.

@Legoktm @Bawolff @Pppery @Shirayuki @Ciencia Al Poder As some of the most active users here at the Village Pump, may I ask for your thoughts, objections or support on this? Kind regards,

Not involved enough here to have an opinion, so if nobody else objects then feel free to go ahead.

No objections.

I'd prefer using tracking categories for those templates. However, category information in JavaScript is missing from Minerva due to phab:T206337, and it's going to be removed from core too (phab:T206250), which means we're left with using inefficient DOM searches...

Done, see MediaWiki:Common.js, MediaWiki:Mobile.js and Synchronizer!

As to the idea suggested by Tacsipacsi, I implemented it at the Spanish Wikiversity but found it a bit cumbersome, since it requires the addition of each script to MediaWiki:Gadgets-definition, an extra prefix to each script (MediaWiki:Gadget-TemplateScript-Example.js) and an extra description page per script (MediaWiki:Gadget-TemplateScript-Example). Furthermore, it makes explaining the whole idea more complicated: "TemplateScripts are gadgets that can be loaded from templates"? Perhaps they should be renamed to TemplateGadgets then? Despite these difficulties, Tacsipacsi's idea may still be the way forward, but I'd like to hear some thoughts on these difficulties before fully committing. Cheers!

See Category:MediaWiki version information templates.

{{MW legacy lts branch number}} should return "1.35" instead of "1.39". The same applies to other templates as well.

No, 1.39 is correct. {{MW legacy lts branch number}} returns the oldest support LTS version, which was 1.35 until a few days ago when 1.35 went EOL and is now 1.39.

By the way, {{Upgrades from older versions}} states, 'Since Version 1.36, MediaWiki only commits to supporting upgrades from two LTS releases ago.'

I believe there is a need to revise the text in this template. What are your thoughts?

Translations:Content translation/2/tok is nonsense (it feels AI generated.) I don't have time to do a real translation so I tried to delete the page contents, but that got blocked by an anti vandalism rule that blocks replacing translation pages with short text. What should I do?

I've deleted it.

You can warn us here, or tag it for speedy deletion with {{Speedy}}

Please replace

{{#ifexist:Template:Main page/{{int:lang}}|{{int:lang}}|en}}

with

{{zh other|zh|{{#ifexist:Template:Main page/{{int:lang}}|{{int:lang}}|en}}}}

so that different Chinese variants (zh-hans, zh-hant, etc.) can correctly display the content of Template:Main page/zh (instead of Template:Main page/en).

I edited that page to add this.

Hello everyone

As you might already know, the Wikimedia Foundation works on changes to how IP editing is handled: IP Editing: Privacy Enhancement and Abuse Mitigation. Temporary accounts for unregistered editors will be a new type of user account. This requires changing how the features we use to contribute to the wikis' work.

This work concerns all features, and it raises some challenges. The case of StructuredDiscussions (also known as “SD” or “Flow”) is one of them. This extension is used at a few wikis, including yours. Flow is a complex piece of software that was never quite finished, fits poorly into the MediaWiki architecture, and creates a significant number of technical errors.

We considered several options to adapt SD: a full adaptation; a partial adaptation where Temp accounts can respond but not create new conversations. All of them would take a lot of time and effort for a short-term benefit. Also, the Wikimedia Foundation's long-term plan is to remove SD from the wikis, mainly due to the maintenance cost. As a consequence, we prefer to avoid adapting SD to Temporary accounts.

We take the opportunity of the work around Temporary accounts to question your community regarding the future of SD. Mediawiki community already decided to stop using this extension for new discussions on talk pages.

Discussion tools are the replacement for SD. They are the default discussion system at all wikis. They allow anyone to start, reply or subscribe to a conversation. They provide a visual experience on wikitext-based conversations, and they cover the vast majority of features StructuredDiscusions offer.

The goal with this conversation is to respond to your questions regarding the archival of StructuredDiscussions.

The idea is to proceed in two stages:

1. discussion pages using SD are archived as subpages. They are replaced by a classic discussion page. In this way, the most active pages will already be ready when we proceed to step 2.
2. SD are removed from the wiki. Existing pages (including archived ones) will be converted to a format yet to be defined.

StructuredDiscussions are used on some community pages

At mediawikiwiki, 17,380 pages still use StructuredDiscusions.

As we already mentioned, Discussion Tools cover the vast majority of features StructuredDiscusions offer, including an easy reply tool and topic subscription. Some new features, such as thanking comments or permalinking (even when the talk page has been archived) will be soon offered. Having one discussion system for all users and talk pages will unify the experience, in particular for newcomers.

It is up to your community to have a transition period: you can archive StructuredDiscusions pages, but keep them editable. Ongoing conversations will fade out, while new conversation will be using Discussion Tools. At a given date, all StructuredDiscusions boards would be converted. What do you think of this idea?

StructuredDiscussions are used by some users at their individual talk pages

We would like to reach an agreement, covering your questions and remarks, where removing StructuredDiscusions will apply to all users. The goal is to archive StructuredDiscusions-based pages, prior to their removal from your wiki.

If you use StructuredDiscusions at your talk page, we encourage you to consider switching to the default format of talk pages. You can do it by renaming your talk page.

For the case of users who turned StructuredDiscusions on but who don’t edit anymore, the conversion will be done later, along with all remaining pages, at a date yet to be defined.

What we expect from you

We have a few questions to answer:

1. Are the reasons given for archiving structured discussions clear?
2. Are the two steps outlined above for archiving and uninstalling structured discussions clear?
3. If so, what is a reasonable timeframe for archiving pages for deinstallation? At present, deinstallation is not planned on our side (even if the second quarter of 2024 is mentioned), as we are waiting for the end of these conversations, which take place on multiple wikis.
4. In your opinion, what format should pages currently using SDs be converted to when we proceed with the deinstallation of structured discussions?

If you need clarification, please ask!

I'll monitor this page until Friday. From what I observed with previous conversations, most replies will be posted until then. But this discussion will remain open until the 8th of January.

The justification for transitioning away from SD makes sense, but what does it have to do with hiding IPs?

As can be read in the first paragraph, Because of ip hiding, we are going from 2 major distinct user types, to 3 distinct user types. That means that essentially every single spot where SD is interacting with a user object will have to be adapted to take that extra type into account. As it is discussion software, you can imagine that there are a LOT of SD actions that have to deal with users.

Ok, thanks. (I was assuming there was already some form of indirection or encapsulation for the user representation that would make that trivial, but I guess it's not that straightforward.)

Working on SD to support the transition to temp accounts would take a lot of time and effort for a short-term benefit. And as we try to reduce technical debt, we take that opportunity to remove SD from all wikis.

Hence, we encourage communities to archive their SD boards to switch to discussion tools. A second step will cover the deprecation itself, which will include a content conversion to wikitext (which is a topic in itself).

1. As Clump says. From what I understand, temp accounts are just accounts, which Flow supports? Not sure what work is required... (edit: only seeing the last two replies now)
2. I'd recommend defining the "yet to be defined" format first. I think it's likely to be an afterthought otherwise once step 1 is finished.
3. The most heavily used pages are the support desks and the village pump. I don't think much time is required for those, since discussions for them are for the most part transient. That being said, I am not sure that DiscussionsTools is a good replacement for Flow, because (I think) it isn't easy to close threads on the former. Is there a plan to add that feature? It's pretty easy to close a thread using Flow; in traditional wikitext, one has to ask the bot to manually archive which does not work well (and setting a short archival period is not the solution either as some respond only after some time).
4. I suspect traditional wikitext, in the format of how DiscussionsTools, would work, assuming that the plan goes though in the end.

I agree that converting all the SD-based talk pages to wikitext is the only real solution. If/when that's done, that clears up a lot of other problems, no? Perhaps at that point, there wouldn't even be a need to archive?

I'm generally supportive of transitioning from flow to discussion tools. This seems as fine a reason as any.

1. Yes. It should have been removed since in my opinion.

2. Yes

3. To me, as soon as possible.

4. Wikitext. Really I don't even know what else is considered.

For me, DiscussionTools is great for talk pages generally. And it should also work for Village Pump too.

However, here on MWorg we have Project:Support desk, which uses SD heavily and, albeit it has it's own problems, it generally works better when there's high concurrency of new messages and people need to copy&paste large chunks of text (error messages and logs with stack traces, or snippets of configuration), which is usually problematic on standard talk pages.

The way SD uses threads that can be viewed independently and are indexed by search engines, makes them suitable for a "stack overflow" or Discourse-like forum where people can easily find the same problem and the solution using their favorite search engine, and even add a follow-up there. Whatever we do to those threads now and in the future will probably cause them to be less discoverable.

Maybe it's now the time to rethink if we should support Project:Support desk or should we close it for good and instead direct people to ask on other forums like stack overflow, IRC or mailing lists...

Thank you all for your feedback.

@Leaderboard:

I'd recommend defining the "yet to be defined" format first.

It is an important part of the conversation. Overall, there is a global consensus to switch to wikitext, so that we can reuse the contents. But actually -- ping @Ammarpad -- the question is really about how converting all these pages should look like: everything at one page? At pages split by month, year? I'm here to hear what you would prefer regarding how we would organize the converted contents.

I am not sure that DiscussionsTools is a good replacement for Flow, because (I think) it isn't easy to close threads on the former

What is your use of closing threads? Have you considered a template-based option?

@Yaron Koren, we have convert the contents. The first step, archiving, is suggested as a way to dry out all conversations. Then the conversion of contents to wikitext will be done. The latter is quite inevitable as we will remove the extension from all wikis.

@Ciencia Al Poder, I noted your concern regarding copy-pasting. What is blocking, in your opinion? How the design is to paste blocks of code/text? The lack of formatting options? We have other heavy-traffic SD boards at other wikis, and we want to work on a smooth conversion.

> how converting all these pages should look like: everything at one page? At pages split by month, year?

i'd just chunk it to 50 threads per subpage.

I feel like Support_desk will be fine in the end. Its not like flow is amazing forum software either.

@Trizek (WMF), templates could be used, but I don't think it's going to be as intuitive as Flow, since most users here are not familiar with Wikimedia and won't have a clue to how to use a template. Similarly, how do we consider archiving? We do have people that reopen threads that would be considered as archived on other wikis; it's very messy to do this on wikitext but simple on Flow.

I think the option to close a thread needs to be provided by the software (whatever it is).

We already often don't use the existing close a thread feature in flow.

We do have people that reopen threads that would be considered as archived on other wikis; it's very messy to do this on wikitext but simple on Flow.

We have two steps:

1. archiving the boards as sub-pages: traffic erodes as new topics are (theoretically) created on the new Support_desk.
2. removing Flow and converting its content to wikitext.

But then the question of people reopening old threads remains. Maybe a bot moving archived topics to a protected page would work locally. Permalinks would keep the notifications and mentions intact; they will be deployed in January.

I personally don't think closed threads should be a big concern during the SD-to-wikitext conversion process. Closing threads is a nice feature in SD/Flow that doesn't exist in wikitext talk pages; so be it. When closed threads get "re-opened" during the conversion, I would call that no more than a minor inconvenience; it certainly wouldn't be any worse than if the talk page had been in wikitext to start with. If you really want, you could add something like " [CLOSED]" to the topic name of those discussions, which is something that people sometimes do in wikitext talk pages. Anything beyond that, like archiving only closed discussions, starts to feel like a hack.