MediaWiki Stakeholders' Group/TechConf Input/Challenges

Gerrit

The Gerrit system for submitting patches is clunky, hard to work with, and generally unfavored in my office place. I was really hoping that with the moving to Phabricator another repository management system would have been implemented.

Alexia E. Smith (talk) 22:36, 3 August 2018 (UTC)[reply]

Endorsements

Comments

I would also prefer a move to GitHub --Krabina (talk) 11:51, 6 August 2018 (UTC)[reply]
Gerrit is unnecessarily difficult for new users to get used to. Moving to a service such as GitHub would allow new users to more easily contribute to existing projects by taking advantage of things like browser editing. Corey Chambers (talk) 00:11, 11 August 2018 (UTC)[reply]
I find GitHub's code review interface far easier to work with than Gerrit's. James Martindale (talk) 19:04, 13 August 2018 (UTC)[reply]
Anything would be better than Gerrit. GitHub is obviously the best option as far as UI and existing community, although politically it's problematic due to its commercial nature. Kaldari (talk) 21:47, 14 August 2018 (UTC)[reply]
We successfully run on GitLab for some of our code. Its UX is very similar to GitHub's. Plus it can be run locally, is open souce and (big plus), supports cherry-picking from the interface Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]
I first got used to Gerrit (which has improved quite a bit too), and when I have used GitHub I found some things complicated (like manually resolving a conflict on merge, protected branches that block i18n updates, review comments disappearing when force-pushed). I would request a fair evaluation instead of what one is used to. Nikerabbit (talk) 08:01, 20 August 2018 (UTC)[reply]
Having extensively used Gerrit, GitHub, and GitLab, I think Gerrit is the clear winner for collaborative projects with a shared ownership model. Seeing what Debian is currently going through in the transition to GitLab (which is very close to the same feature set as GitHub), I don't think it would meet our current needs. I do agree that we should do a proper re-evaluation every so often, and work with upstream to implement our feature requests / bug fixes (shout out to Paladox and Chad here!), potentially hiring contractors if necessary. Legoktm (talk) 17:30, 22 August 2018 (UTC)[reply]

Access restrictions and wiki synchronization

I know that MediaWiki is not designed to be a full-fledged content management system with fine-graind per-page or partial page access restrictions and probably never will be. But anyway, there two extensions that came quite far:

So a first wish is one of them / or both to be maintained better or another solution to this.

In corporate settings, there are also alternatives to access restrictions in one wiki, i.e. splitting content in two or more wikis. Therefore a better multi-wiki-management and content syndication between wikis could be a way to go. Here are some links to follow up on that:

Also, a very simple use case cannot easily be implemented: setting up 2 wikis with a shared user accounts (but different content). So single-sign-on between two or more mediawiki instances is important in this regard as well (without having to use several extension).

Krabina (talk) 12:01, 6 August 2018 (UTC)[reply]

Endorsements

Krabina (talk) 12:01, 6 August 2018 (UTC)[reply]
AdSvS (talk) 12:58, 6 August 2018 (UTC)[reply]
--[[kgh]] (talk) 11:20, 11 August 2018 (UTC)[reply]
RichardHeigl (talk) 12:09, 11 August 2018 (UTC)[reply]
(This challenge is related to my own below) Even Thorbergsen (talk) 20:28, 12 August 2018 (UTC)[reply]
--MGChecker (talk) 22:16, 13 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:23, 14 August 2018 (UTC)[reply]
·addshore· ^{talk to me!} 09:49, 14 August 2018 (UTC)[reply]
Remco de Boer 15:23, 14 August 2018 (UTC)[reply]
--Felipe (talk) 07:31, 15 August 2018 (UTC)[reply]
Ike Hecht 02:29, 16 August 2018 (UTC)[reply]
Rob Kam (talk) 08:44, 16 August 2018 (UTC)[reply]
Tenbergen (talk) 15:40, 17 August 2018 (UTC)[reply]
Tfellows (talk) 19:05, 17 August 2018 (UTC)[reply]
HakanIST (talk) 06:29, 18 August 2018 (UTC)[reply]
DuncanCrane (talk) 12:25, 18 August 2018 (UTC)[reply]

Comments

This would be useful for hiding rough drafts of articles while they're being worked on, until they're ready enough. Rob Kam (talk) 10:07, 8 August 2018 (UTC)[reply]
for this you should look into Extension:Approved_Revs --Krabina (talk) 09:23, 10 August 2018 (UTC)[reply]

Indeed the "Lockdown" extension is more or less causing issues since MW 1.27 due to a bug apparently in core. --[[kgh]] (talk) 11:21, 11 August 2018 (UTC)[reply]
ACL is a missing core feature that does not contradict the Wiki idea, because you can - and should - deploy flat authorization hierarchies. But the lack of this configuration option complicates often development projects and the introduction of MediaWiki in organizations outside of Wikimedia.RichardHeigl (talk) 11:08, 15 August 2018 (UTC)[reply]

Maybe allowing restrictions by namespace may be enough. But then if a person needs to move a page from one namespace to a different namespace, there should be an easy way to update all of the references to that page. Zzmonty (talk) 15:49, 15 August 2018 (UTC)[reply]

I have one wiki that's split private/public, and another that looks to be heading that way. It would be great if there was a very straightfwd way to designate a page public or private. Mind you, we also use SMW, and I can see where integrating properties and queries into this sort of thing would be hard. Tenbergen (talk) 15:38, 17 August 2018 (UTC)[reply]

Documentation needs a lot of improvement

I don't think I'm saying anything controversial here, but the documentation on mediawiki.org is often incomplete, outdated and sometimes misleading. I'll give one recent example: I was looking for how to view the current status of the job queue, other than just going into the database and looking at the "job" table. I went to the page Manual:Job queue, and the information there about viewing the job queue is in the section called "Special:Statistics" - which is odd because, as the text there notes, job queue information hasn't been available at Special:Statistics since 2010. The section then describes the API action to get the current number of jobs - which is helpful. However, there's also a script to see more information on the job queue, showJobs.php, and that one is only listed in the "See also" section. (And isn't there a way to call it from the web interface? I thought there was, but I don't see it now.)

Looking at the "Manual:Job queue" page, it looks like a lot of it could be overhauled. Why is a description of the asynchronous jobs setting contained in the "History" section? Why is there a "History" section at all? The average user has no interest in hearing about, for instance, job-related bugs that were fixed in 2014. This seems like it would be better kept in a subpage.

I think it would be great to have people whose full-time or part-time job is to maintain the documentation, and make sure that there's a consistent structure to it.

Yaron Koren (talk) 18:32, 6 August 2018 (UTC)[reply]

Endorsements

Yaron Koren (talk) 18:32, 6 August 2018 (UTC)[reply]
Bryandamon (talk) 18:14, 8 August 2018 (UTC)[reply]
Corey Chambers (talk) 00:12, 11 August 2018 (UTC)[reply]
--[[kgh]] (talk) 11:23, 11 August 2018 (UTC)[reply]
--MGChecker (talk) 22:16, 13 August 2018 (UTC)[reply]
— AfroThundr ^{(u · t · c)} 00:30, 14 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:35, 14 August 2018 (UTC)[reply]
·addshore· ^{talk to me!} 09:49, 14 August 2018 (UTC)[reply]
Alangi Derick (talk) 13:03, 14 August 2018 (UTC)[reply]
Remco de Boer 15:24, 14 August 2018 (UTC)[reply]
Kaldari (talk) 21:48, 14 August 2018 (UTC)[reply]
--Felipe (talk) 07:33, 15 August 2018 (UTC)[reply]
Winged Blades of Godric (talk) 10:28, 15 August 2018 (UTC)[reply]
Ike Hecht 02:26, 16 August 2018 (UTC)[reply]
Tenbergen (talk) 15:41, 17 August 2018 (UTC)[reply]
Tfellows (talk) 19:05, 17 August 2018 (UTC)[reply]
nBarto (talk) 22:48, 17 August 2018 (UTC)[reply]
HakanIST (talk) 06:29, 18 August 2018 (UTC)[reply]
DuncanCrane (talk) 12:27, 18 August 2018 (UTC)[reply]
Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]
Vedmaka (talk) 12:15, 8 September 2018 (UTC)[reply]

Comments

This is a very key area in MediaWiki development and I must appreciate that of course there is a lot of documentation already which exist but since software changes are inevitable, it should be noted that as these changes are done periodically, their docs counterparts should be improved in order to keep everything up to date. It's a key way of technical contribution in the movement and while trying to do this, one will find his/herself navigating MW code and software etc. There are many advantages of improving MW related documentation especially to developers and newbies so it should be treated with priority. :) --Alangi Derick (talk) 13:07, 14 August 2018 (UTC)[reply]

For developers in particular, the documentation is often (usually?) missing or wrong. Sometimes developers follow the documentation and submit patches only to be corrected on code review. I wonder if there is more accurate and thorough documentation in Gerrit than in mediawiki.org. For each section of the MediaWiki code (or certain complex extensions, there seems to be a small group of developers who actually understand it. If somebody knows who these people are and has access to them, they may be able to encourage a representative of each of those groups to share their knowledge. That would make developing easier and code review more painless. --Ike Hecht 02:26, 16 August 2018 (UTC)[reply]

This is about core however there is also a big issue about extensions including the ones created and used by WMF. So we need a solution here, too.--[[kgh]] (talk) 08:19, 19 August 2018 (UTC)[reply]

Integration of an extension with VisualEditor (e.g. writing inspectors and tools, adding page options aka Magic Words or adding new toggles to the insert table dialogue) is really a lot of grepping through the code and trying to figure out how it is properly done. It this were documented better, I am sure much more extensions would have support for VisualEditor. Especially in 3rd party wikis, this would be a major improvement. Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]

Extension sustainability

For third parties it is very hard to decide if an extension is sustainable (long time experience is needed here which cannot be expected by new arrivals), e.g. is it compatible with the version of MW I use, will it be compatible or made compatible with the next version of MW, who is there to answer questions regarding its usage, who will comment on bug reports, help creating good bug reports, who is in contact with the maintainer etc. (all in due time) - somebody who is responsible for the communication around it. Thus I would like to see that every extension has a dedicated co-ordinator who will document it, answer questions and co-ordinate issue reports (not necessarily fixing the code). This may be the creator or maintainer but this is not required. However this must not be a group of people like an "editing department" or so. Currently it is a matter of chance (sometimes high, sometimes low) to get a reply. To cut it short: This person (co-ordinator) should be the documentator of the extension and at the same time the bug wrangler! In the end an extension without a co-ordinator is not sustainable and should be considered for use at ones own risk and marked as such. --[[kgh]] (talk) 08:46, 19 August 2018 (UTC)[reply]

Endorsements

Comments

Extensions being widely used but not actively maintained is a widespread issue. I suggest to have a group of people which have +2 rights on all extensions and who do have the standing and knowledge to review and merge patches submitted. Sure, all commiters with +2 on core are potential candidates, but they do not have the time to review extensions. So this should probably be a community driven process. Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]
Are you saying that the current process of granting +2 isn't community driven? In any case, there are multiple people who have +2 mostly for their work in extension maintenance. If there are people interested in doing such, they should apply for +2 rights. Legoktm (talk) 17:25, 22 August 2018 (UTC)[reply]
WordPress has a on their website an indication on which versions an extension has been tested on. Zzmonty (talk) 18:34, 20 August 2018 (UTC)[reply]

Keeping up with the upgrade debug cycle.

Every new release requires re-installation of extensions and checking that everything still works as expected. Most third party wikis stay at the original install version. Wiki users want to add content and keeping up with the upgrade debug cycle too technical a chore.

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

Endorsements

Comments

Perhaps users don't even realise they're expected to keep their installations up to date. --Rob Kam (talk) 11:41, 15 August 2018 (UTC)[reply]

As mentioned elsewhere, if these updates were further automated or at least facilitated that would be great! Making them like Wordpress where I don't even need to touch might be too much to ask, but turning them into something where I would at least be comfortable to hand it over to a less familiar technical resource would be great. I think if I left my work environment today our wikis' software might never be updated again. Tenbergen (talk) 15:45, 17 August 2018 (UTC)[reply]

Most people are not drawn to use wikis

Wikis needs collaboration to function well. The biggest challenge is lack of other wiki contributors with know-how to share. Most frequently when people announce (on email lists or forums) some information they’re organising and making available; even if they know of a wiki for that subject they do it their own way, e.g. posting on a forum, blogging, YouTube, file-sharing, Google docs, GitHub repository, etc. but rarely a new wiki article on an existing specialist wiki. While on the other hand some competent authors are repelled by the idea of writing on a topic and then having to allow anyone to make changes to their work.

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

Endorsements

Comments

I tried to contribute to Wikipedia, but I received threats, so I gave up. Now I am just a reader of Wikipedia, make an occasional small edit, but mostly working on my own personal wiki project.. — Preceding unsigned comment added by Zzmonty (talk) 15:53, 15 August 2018 (UTC)[reply]
Putting work into articles only to have them deleted because "not notable enough" also puts people off contributing to Wikipedia. Rob Kam (talk) 10:42, 16 August 2018 (UTC)[reply]

- I wonder if the definition of "Not notable enough" has changed since the start of Wikipedia. Unlike a regular encyclopedia, Wikipedia seems to have become a central location of general information about stuff. If I want to know the episodes of a TV series, I look at Wikipedia. If I am interested in reading about the history of school, I can usually find it on Wikipedia. What may have been considered "Not notable enough" when Wikipedia started, may not be as important today. Maybe this definition needs to be reevaluated. Zzmonty (talk) 18:40, 20 August 2018 (UTC)[reply]

Guarding against link rot

The unmaintained MW extension ExternalLinks is unsafe because of the risk of XSS. It was an easy and efficient way to easily maintain a wiki's external links. Wikis could/should have Special:External links where any broken external links get flagged up.

Rob Kam (talk) 09:47, 8 August 2018 (UTC)[reply]

Endorsements

Liuxinyu970226 (talk) 01:36, 14 August 2018 (UTC)[reply]
Rob Kam (talk) 17:20, 15 August 2018 (UTC)[reply]
Tenbergen (talk) 15:50, 17 August 2018 (UTC)[reply]
--[[kgh]] (talk) 08:08, 19 August 2018 (UTC)[reply]

Comments

Would be nice if internal links to headings were included in such a feature. For a link like [[Page#heading in page]], if the heading is changed in the page, there is no way to list pages affected by that (that I know of). Tenbergen (talk) 15:50, 17 August 2018 (UTC)[reply]
Is there a bug or extension request filed for this? Legoktm (talk) 17:26, 22 August 2018 (UTC)[reply]

Enabling public read access to specific pages of a private wiki

It should be easy to make specific pages of a private wiki publically available, while all other pages stay private. Setting a category display property is a possibility. This is related to Access restrictions and wiki synchronization above, and may possibly be solved by Extension:SplitPrivateWiki.

Even Thorbergsen (talk) 14:44, 12 August 2018 (UTC)[reply]

Endorsements

Comments

In a private wiki not behind a firewall, you can add pages you want the public to see with $wgWhitelistRead on LocalSettings.php. To easily do this, you can load the InternalWhitelist extension which provides a Wiki page (MediaWiki:Whitelist) to which you can add all pages you want publicly available. Making the MediaWiki:Whitelist page protected can limit who can make pages public. Bryandamon (talk) 06:01, 14 August 2018 (UTC)[reply]

If whitelisting was made much easier, this would solve my public/private wiki issues as well. Putting it into LocalSettings means I can not ask a content writer to do it, it has to be a technical employee. Is there a technical reason the whitelist can't live in a namespace or special page, or riskier but more convenient, in a switch that comes up at page save time, near the "minor" and summary components? Tenbergen (talk) 15:55, 17 August 2018 (UTC)[reply]

WordPress has an extension called "restricted-site-access". It would be great if that could be added to MediaWiki as a standard extension. I used this extension on WordPress when I was making blogs for kids where I wanted to restrict who can access the blog (even read the blog) to just a few domain locations. Zzmonty (talk) 18:47, 20 August 2018 (UTC)[reply]

Replicating templates and modules from Wikipedia to an Enterprise wiki

Could it be made easier to be able to copy over a template, its documentation, any of required templates, their documentation, those templates required template, their documentation, any requirement modules, and their documentation? I feel this could be done using Special:Export if you would specify the list of all of the templates and modules, but getting that list might be very time consuming and prone to errors. Thanks!

PhotographerTom (talk) 17:55, 13 August 2018 (UTC)[reply]

Endorsements

PhotographerTom (talk) 17:55, 13 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:37, 14 August 2018 (UTC)[reply]
Bryandamon (talk) 06:03, 14 August 2018 (UTC)[reply]
·addshore· ^{talk to me!} 09:49, 14 August 2018 (UTC)[reply]
DuncanCrane (talk) 12:33, 18 August 2018 (UTC)[reply]
--[[kgh]] (talk) 08:10, 19 August 2018 (UTC)[reply]
Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]
...

Comments

What is needed is a template store for rather basic templates which however can get a wiki already going without the need to learn wikitext "programming". --[[kgh]] (talk) 08:10, 19 August 2018 (UTC)[reply]

Work with documents within the wiki and export pages to PDF

Many organizations come from (MSOffice)-document centric environments. Even if they gradually migrate their content to web formats, some enterprize prozesses will keep beeing heterogenoulsly document based for years. Reasons are manifold and include complinace issues, local policies, system integration, personal content review preferences, need for physical printouts at work sites and a low digital literacy of staff in mission critical positions, slowing down transition.

Mediawiki should make its embedding in heterogenous environments easy and relaxed. These workflows would include intuitive upload interface and document previews (.xlsx, .docx, .pptx) within pages and full text search indexing.

When wikis are used for technical documentation, the creation of PDF-exportable "books/article collections" also is desirable. Optimally these would embrace mixed wikitext/document collections. -- 11-G3n (talk)

Endorsements

Comments

Save article selections to different formats in the order the user selected needs to work. This would allow more use of a wiki as a workspace for later publication. This should include save as PDF, epub 3.0, HTML, doc, and otd formats.

Wikimedia doesn't really support shared hosting.

Wikimedia doesn't really support economical shared hosting. Not everyone can afford to run a wiki on the infrastructure it seems to be written for. Trying to get e.g. Visual Editor running on shared hosting is so severe a challenge that regular wiki maintainers won't even attempt it.

Rob Kam (talk) 17:18, 15 August 2018 (UTC)[reply]

Endorsements

Comments

We are also still using the old-school wiki editor because the new one is not shared hosting friendly; I haven't even looked at the visual one in months because the need to install other stuff that may or may not run on shared hosting has completely put me off. In a related way, some of the changes that were rolled out with the latest update this summer (recent changes improvements) are really neat, but they appear to have seriously slowed down parts or our wiki so I have not applied them to all our wikis yet (granted this may be an issue with our specific wiki instance, but that's how it came across to me). While the visual editor is at least a choice, some of the other changes are not, and that becomes a problem. If a new version of mediawiki needs more resources to run than the old one, that should be transparent, and ideally be in line with what shared hosting can handle. Tenbergen (talk) 16:02, 17 August 2018 (UTC)[reply]
Visual editor is definitely a huge step forward to encourage non-IT literate authors to add content to a mediawiki based site. I have to agree, though, with the author of this comment. Setting VE up in my environment defeated me, so much so we are are now using an extension that uses TinyMCE which works great for our purposes. In order for mediawiki to thrive in the future we not only need to encourage content authors by making it simple and intuitive, we also need to make it easier for new (novice) technical authors so they don't bypass mediawiki for apparently more accessible alternatives. DuncanCrane (talk) 12:47, 18 August 2018 (UTC)[reply]
Another challenge with hosted environments is that a lot of the configuration is only available by editing the LocalSettings file. It would be great if it was possible to change more settings through the mediawiki interface, in addition to user based preferences, perhaps as a special page? DuncanCrane (talk) 13:14, 18 August 2018 (UTC)[reply]
Quiete franky. I think that there is no longer an intention to support shared hosting. Probable it will be best to announce this. An open question is however how people who would like to share knowledge beyond the scope of WMF-project can do so. --[[kgh]] (talk) 08:22, 19 August 2018 (UTC)[reply]

I've had to move my simple hobbyist wiki to a wiki farm managed by others with far better resources than I'll ever have. Rob Kam (talk) 10:02, 19 August 2018 (UTC)[reply]

Considering spam and vandalism in feature design

Spam/vandalism management is harder than it needs to be due to the design of some major features, and it would be helpful if the need to address spam and vandalism was considered a critical, first-class consideration in future feature development. Tools such as the translation extension and flow, for example, obscure edits and histories and complicate the process of tracking and restoring revisions:

Translations

no history, let alone ability to revert is shown in the translation tool.
deleting translation spam/vandalism is awkward; specific translation units are not shown in a translated page's history.
no obvious way for users to indicate spam translations
reverting translation units does not fully restore the state---a removed fuzzy indicator is never restored

Talk pages/flow

edits to individual topics are mixed together, making identification of topic vandalism difficult
flow page descriptions do not have history, and multiple edits cannot be mass reverted, nor is reverting to older versions easy
flow page descriptions cannot be protected (and no progress on task T113902 has been made in 3 years)
topic titles, summaries, and visibility are trivially altered by vandals, and cannot be protected

These tools can be fixed (eventually, presumably) and/or replaced. More generally, though, easy tracking and tracing of revisions, access to histories and older revisions, and protection capabilities should be integral in the design of all features that allow user editing.

Clump (talk) 16:56, 16 August 2018 (UTC)[reply]

Endorsements

Clump (talk) 16:56, 16 August 2018 (UTC)[reply]
Rob Kam (talk) 18:47, 16 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)[reply]
Alangi Derick (talk) 20:50, 22 August 2018 (UTC)[reply]
...

Comments

Even when spam can be minimized with extension abuse filter the bots still fill the user list with noise. Rob Kam (talk) 18:47, 16 August 2018 (UTC)[reply]

stronger warnings when trying to edit old version

Our documentation process makes heavy use of the recent changes feature. Due to the breakdown by day, there is no easy way to only list a page's most recent edit, it will be listed for each day it was edited. This means that if I am away for a week, and then start reviewing changes from 7 days ago, I will likely look at a few diffs that have had additional changes since. It is easy to start editing the version that is not the current one, which is not usually what is intended. I make the mistake even though I am aware of it, and it is almost impossible to explain to less technical users that this is something to watch out for. This leads to later edits being clobbered, which is reducing buy-in in using the wiki. It would be nice if trying to edit a non-current version led to a far more "noisy" warning than that little line at the top. This might be something that I can change through interface edits, but I think the default should be more noisy in the first place. Tenbergen (talk) 16:24, 17 August 2018 (UTC)[reply]

Endorsements

Tenbergen (talk) 16:24, 17 August 2018 (UTC)[reply]
nBarto (talk) 09:01, 18 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)[reply]
...

Comments

@Tenbergen: IIUC you're asking for 2 things:

Implementation of the feature request in phab:T10681 ("Group changes across days in enhanced rc") (+1 from me!)
Making a more eye-catching default design of the core message-string MediaWiki:Editingold.
I think the difficulty there, is the message has to be skin-agnostic... I.e. able to fit in with any layout/color-scheme/design-elements/etc. You might want to look at other Wikimedia projects' designs for inspiration in tweaking your own, e.g. w:en:MediaWiki:Editingold, w:fr:MediaWiki:Editingold, w:de:MediaWiki:Editingold (3 designs, 3 implementation methods!). Or just wrap it in a few <big> tags and call it complete ;-)
@Tenbergen: Aha, I got better advice from some devs. I've filed a task at phab:T202248 ("Wrap `editingold` in a warning box to make it more visible"). :) –Quiddity (talk) 05:20, 20 August 2018 (UTC)[reply]

HTH. :) –Quiddity (talk) 03:23, 20 August 2018 (UTC)[reply]

Upgrading Scribunto

Upgrading Scribunto on a shared host. Extensions that are needed to easily copy and paste existing templates should be considered critical extensions. Zzmonty (talk) 16:00, 15 August 2018 (UTC)[reply]

Endorsements

Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)[reply]
...

Comments

Communication between pages

There is currently no satisfactory way to, when parsing a page, read data from a different page.

The PageVariable extension is experimental and appears to be no longer maintained. It is possible to achieve this with Labeled Section Transclusion, but the code will be inelegant, as it is not possible to embed <section> tags in a template. See phab:T39256 and phab:T179482.

nBarto (talk) 23:17, 17 August 2018 (UTC)[reply]

- I vote for fixing the Labeled Section Transclusion to be able to work in templates. Zzmonty (talk) 18:51, 20 August 2018 (UTC)[reply]

Endorsements

Comments

One situation where I was hoping for this functionality, is in creating more flexible page hierarchies: Organizing a set of pages using (multi-level) subpages is not very flexible: when a parent page needs to be moved, all subpages have to be moved as well. Also, it is not possible to assign multiple parent pages to one child page. By contrast, with an appropriate implementation of page variables, one could simply assign to each page a variable indicating one or more parent pages. The "breadcrumbs" containing the grandparents, great grandparents, ... can then be created by recursively reading the parent page's variable. --nBarto (talk) 23:28, 17 August 2018 (UTC)[reply]
Another use case would be when a user has a certain group, tagged information from a different page is automatically pulled into the page, to have a blended experience. e.g. Page A is a list with infos for different groups (that have different permissions), Page B describes the general workflow and depending on the group the user gets the corresponding information from Page A filled into the corresponding gaps in B

Skinning

It's 2018 and skinning still sucks.^{[thanks, Captain Obvious!]} It shouldn't be so. We should be encouraging people to write more skins and better skins, and a part of that would no doubt include making core more flexible in this regard.

Jack Phoenix _(Contact) 00:03, 20 August 2018 (UTC)[reply]

Endorsements

Comments

Making MediaWiki GDPR compliant

Setting up a GDPR compliant MediaWiki is currently a nightmare. There is a lenthy page: GDPR_(General_Data_Protection_Regulation)_and_MediaWiki_software where a lot of the hurdles are described. To be widely usable, MediaWiki should (be able to) comply with these regulations or at least support admins in achieving this. Currently this is only achievable by installing lots of different extensions and going through the GDPR themselfes, which for a lot of admins is a "no - I will just use something else then".

This could include:

dividing into username (not visible to anyone but yourself) vs displayname
explicit consent boxes
a GDPR guide and GDPR_LocalSettings.php preset to take admins by-the-hand
Let a user view all the data that a MediaWiki has on him -> XML or JASON output should be possible
Let a user delete all the data that a MediaWiki has on him (maybe with a delay to avoid abuse) -> merge deleted user's contributions to 'DeletedUser' dummyuser?
Anonymize (zeroing the last 2 tuples of) the IP on anonymous edits (immediately or after some time?)

Daniel schuerhoff (talk) 12:27, 20 August 2018 (UTC)[reply]

Endorsements

Daniel schuerhoff (talk) 12:27, 20 August 2018 (UTC)[reply]
...