MediaWiki Stakeholders' Group/TechConf Input/Conference topics

How can we create a governance model?

There is no clear decision making process for MediaWiki. I would love to see us start on a process whereby we could predict what was happening with the software in the next year. We have some vague ideas, but no unified driving force.

☠MarkAHershberger☢(talk)☣ 19:45, 3 August 2018 (UTC)[reply]

Endorsements

☠MarkAHershberger☢(talk)☣ 19:45, 3 August 2018 (UTC)[reply]
Alexia E. Smith (talk) 22:36, 3 August 2018 (UTC)[reply]
--Krabina (talk) 11:47, 6 August 2018 (UTC)[reply]
--[[kgh]] (talk) 11:06, 11 August 2018 (UTC)[reply]
RichardHeigl (talk) 11:56, 11 August 2018 (UTC)[reply]
「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:49, 14 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:19, 14 August 2018 (UTC)[reply]
Nischayn22 (talk) 08:31, 14 August 2018 (UTC)[reply]
·addshore· ^{talk to me!} 09:50, 14 August 2018 (UTC)[reply]
Remco de Boer 15:22, 14 August 2018 (UTC)[reply]
Jayprakash12345 (talk) 08:11, 17 August 2018 (UTC)[reply]
MarcvHoof (talk) 14:04, 17 August 2018 (UTC)[reply]
Mglaser (talk) 21:15, 17 August 2018 (UTC)[reply]
HakanIST (talk) 06:29, 18 August 2018 (UTC)[reply]
DuncanCrane (talk) 11:17, 18 August 2018 (UTC)[reply]
--Toniher (talk) 10:48, 18 August 2018 (UTC)[reply]
James Martindale (talk) 19:01, 19 August 2018 (UTC)[reply]
Rudolf.Grossmann (talk) 21:16, 7 September 2018 (UTC)[reply]
...

Comments

A text suggestion tool

It's helpful to have a text-editing tool that helps contributors write better sentences

Endorsements

Although I don't know who said this section, I support this. --Liuxinyu970226 (talk) 01:20, 14 August 2018 (UTC)[reply]

Comments

Activate Grammarly. Grammarly is the best grammar editing tool out there. Zzmonty (talk) 10:34, 14 August 2018 (UTC)[reply]

Lack of templates in MediaWiki

Templates are missing from Wikimedia. These are a headache to disentangle, understand, install and maintain for the end user who would rather be concentrating effort on adding wiki content. Individual wiki admins are forced to either write their own templates or export them from elsewhere e.g. Wikipedia.org. This is a wasteful dispersion of effort in place of collaboration. The templates that are exported from Wikipedia or Mediawiki are not universal and the target wiki then includes references to these sites instead of to itself.

Rob Kam (talk) 08:21, 8 August 2018 (UTC)[reply]

Endorsements

「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:49, 14 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:21, 14 August 2018 (UTC)[reply]
nBarto (talk) 15:31, 15 August 2018 (UTC)[reply]
Rob Kam (talk) 17:22, 15 August 2018 (UTC)[reply]
Awangba Mangang --Awangba Mangang (talk) 04:37, 16 August 2018 (UTC)[reply]
• speedy • 🔔︎ • 🚀︎ • 13:24, 16 August 2018 (UTC)[reply]
DuncanCrane (talk) 11:17, 18 August 2018 (UTC)[reply]

Comments

This could be provided by a wiki repository, similar to Wikia/Fandom's Starter Wiki. This repository would have to be licensed as CC0, and there are open questions about maintaining multiple versions of templates, mostly in regard to whether the target wiki has installed features such as Scribunto or TemplateStyles. Since not all templates are of interest to all wikis, some sort of template pack feature, above and beyond just listing things on Special:Export, would be desirable (if designed/implemented correctly, this would also simplify and streamline selecting the correct version of templates for a given installation). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:49, 14 August 2018 (UTC)[reply]

or just add it to http://commons.wikimedia.org -- make a new section called "Template-repository:" and "Module-repository:". Although the templates would need to be organized between general use templates and templates with information specific to a specific project. I like the infoboxes, but I do not need many of the other templates that get included when I say "export referenced templates". Also, the export would need a feature to rename "Template-repository:" to "template:", so the end user does not need to do that themselves. Zzmonty (talk) 10:38, 14 August 2018 (UTC)[reply]

To expand on the OP, a lot of Wikipedia/Mediawiki templates are dependent on Scribunto (which users struggle to debug after importing). The Module namespace at Wikipedia has quite a bit of overengineered code as well. Think mobile too - all extension infoboxes on mediawiki.org look awful there. • speedy • 🔔︎ • 🚀︎ • 13:24, 16 August 2018 (UTC)[reply]

I'm using a wiki farm to provide a 'software as a service' environment to my users. Ideally they should have identical functionality with their content stored in unique wiki databases for each user (or group of users). The functionality I create uses templates a lot - Page Forms, Cargo, SemanticMediaWiki - so it would be great to be able to share templates in a straightforward way. Currently I am duplicating the functionality in each wiki which makes it difficult to maintain. Perhaps it would be possible to set a configuration variable to always transclude templates from a particular wiki? Alternatively, it would be useful if, when transcluding a template from another wiki, all templates referenced were also transcluded from the same wiki. If this is already possible it would great to know how? The suggestions I've seen so far appear quite complex to implement. DuncanCrane (talk) 11:18, 18 August 2018 (UTC)[reply]

You'd also have to transclude any modules the templates use. Rob Kam (talk) 16:18, 18 August 2018 (UTC)[reply]

Somehow this topic was split into several variations of the same topic. I guess I endorsed one of them. --[[kgh]] (talk) 08:52, 19 August 2018 (UTC)[reply]

Also a solution to this issue is listed at Meta:Community Wishlist Survey 2019/Miscellaneous/Shared Multilingual Templates and Modules available to all wikis, please support it. Rob Kam (talk) 09:01, 18 November 2018 (UTC)[reply]

Release management unclear. Is there still one?

It appears that doing point releases when it comes to maintenance was apparently abandoned along the way. During the past nine months we have only seen two feature releases with unreleased fixes now piling up for both of them not to speak about the other older LTS branch and the regular branch still active sharing the same fate.

I suggest to reinstate doing point releases for maintenance purposes and to e.g. have a point release every quarter of a year - something somewhat predictable and plannable.

Endorsements

[[kgh]] (talk) 11:16, 11 August 2018 (UTC)[reply]
— AfroThundr ^{(u · t · c)} 00:26, 14 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:21, 14 August 2018 (UTC)[reply]
--Felipe (talk) 07:36, 15 August 2018 (UTC)[reply]
MarcvHoof (talk) 14:05, 17 August 2018 (UTC)[reply]
DuncanCrane (talk) 11:19, 18 August 2018 (UTC)[reply]
Mglaser (talk) 21:32, 19 August 2018 (UTC)[reply]

Comments

Figure out why scribunto has issues when trying to install from a 1.27 release to a 1.31 release on a shared host. Maybe I did something wrong, but if I can't get scribunto to work (requirement for using current templates and modules), I can't upgrade to 1.31.

Maybe the solution is to create two install versions. One is basic install with the bare bone minimums, and one is an enhanced version (the end user is planning to import templates, so they need all of the extensions that make the templates work properly). If that was provided, I would upgrade from 1.27 LTS to the 1.31 LTS. I am sure that I am not the only end user in this position.

Finally, have an auto LTS upgrade that will automatically upgrade the source code and extensions, similar to the way that WordPress does it. Maybe this can be restricted to just the extensions that are included in Wikipedia (and its sister project installs).

The easier the upgrade process (end user does not worry they are going to mess up their site and be down), the more likely the end user will upgrade and the less need their will be to maintain old releases. Thbis does not need to be done for every release. Just the long term releases, because those are the releases that less technical users should be sticking to. Zzmonty (talk) 10:45, 14 August 2018 (UTC)[reply]

Improved Translate - VisualEditor integration

Extension:Translate is a great tool but it does not work very well with Extension:VisualEditor. VE can not handle the ‎<translate> tags. As a result, the user can not edit text in WYSIWYG but in a little dialog box with wikitext...

This has also been reported by others more than two years ago. See:

https://phabricator.wikimedia.org/T131516: Lots of pages on mediawiki.org have "‎<translate>" and "" bits strewn about, making them hard to read and edit in source, and hard to edit in Visual Editor. Translation should not rely on making large parts of pages uneditable! Per discussion it looks like some small tweaks to VE's treatment of the extension tag may simplify things without introducing too much breakage, until a more VE-native solution is available.

https://phabricator.wikimedia.org/T55974: ‎<translate>...‎</translate> and the related ‎<tvar>...‎</tvar> are currently un-parsed and shown as plain wikitext in VisualEditor because they're not recognised, per T50891; however, once that is fixed, the blocks won't be editable except as alien nodes (in wikitext), and won't be createable. Making a proper VisualEditor plugin to translate these in-page as a rich editor shouldn't be particularly hard (he says…).

Planetenxin (talk) 15:12, 16 August 2018 (UTC)[reply]

Endorsements

Comments

Solving this issue would also have positive effect on enterprise use of MediaWiki.

Replace this line with your response.

197.156.115.144 17:52, 18 August 2018 (UTC)[reply]

Endorsements

Comments

Easier upgrade and extension manager

Comments

I use Wordpress a lot and have noticed MediaWiki is lacking somewhat when it comes to management for non-technical people compared with Wordpress, even Joomla! can do it. I have experienced the following issues:

unable to install Visual Editor with dependency of Parsoid,
initially had issues installing Semantic MediaWiki due to dependency of Composer, I did find a workaround, but not ideal,
when updating it is very frustrating having to delete all the files from the server and reloading the latest version of MediaWiki, can this not be done similar to how Wordpress ad Jooma do it?

The fact that you need access to the command line to run maintenance scripts and other functions like composer, those on shared hosting environments won't be able to do this. I am using a virtual machine with access to the command line, but I have other hosting where this is not possible. Other opensource scripts such as Wordpress and Joomla allow easier installation of extensions, is it possible that MediaWiki could follow these examples?

The server I am working on is not Internet facing, so a lot of the time I am having to take the server off line, transfer the MediaWiki installation to a local server I have built on an Internet facing machine, do what I need to do, then migrate it back over. This entire process can take two days, that's two days where my contributors are unable to contribute.

--Squeak24 (talk) 12:00, 19 August 2018 (UTC)[reply]

Endorsements

Visual Editor

Comments

I have tried to install Visual Editor a few times now, I was able to get it working without issue on my Internet facing machine, but when I tried to get it working on the server that is not Internet facing I was not able to get it working. I tried to migrate the internet facing version on my development server to my production, non-internet facing server, but for some reason it wouldn't work. It worked fine on the new pages, but not the legacy pages that require Parsoid. I tried in vain to get Parsoid working correctly on the non-internet server. Is there anyway it may be easier to use Visual Editor without Parsoid?

I did try the TinyMCE extension, this worked fine even with the old pages. Unfortunately it is still very buggy hence I was unable to have it on a production site. I want to make it as easy as possible for the contributors, I need them to edit the pages they manage, hence such a tool would be fantastic to have.

-Squeak24 (talk) 12:00, 19 August 2018 (UTC)[reply]

Endorsements

-Squeak24 (talk) 12:11, 19 August 2018 (UTC)[reply]

Full support for read protected wikis

VisualEditor is still not fully usable on read protected wikis, as Restbase does not forward authentication cookies or provide an alternative way of promotion session data. This is just an example for the neglect of wikis that do not have full access for the public. For 3rd party wikis are often read protected for valid reasons, it is an important issue to make these wikis work just as open wikis work.

Mglaser (talk) 21:32, 19 August 2018 (UTC)[reply]

Endorsements

RichardHeigl (talk) 19:50, 21 August 2018 (UTC)[reply]