DynamicPageList3 Manual talk:Feedback

Place to discourse

Hello, it could be good if there is a place to discourse something on this wiki. For example, requests for enabling extensions. --Lens0021 (talk) 11:13, 26 March 2022 (UTC)

Requests for enabling Extensions currently may be easiest by asking Cosmic Alpha (CA) on MH Discord. Which extensions are you wanting enabled (I can add them to my existing ask if they make good sense)?

At this moment, I'm just starting to get content brought over for CA, and some unnecessary templates cleaned up/replaced (I'm not importing because I'm not sure we need all of Fandom's templates, instead I'm manually copying and stripping out some unnecessary bits to simplify). It may be a bit early for feedback as of yet, given we don't even have all the content here. I'm also rejigging the page structure, since on Fandom the content was in a custom Extensions namespace and had nested as subpages, which isn't needed here. I don't have access yet to put the necessary CSS in MediaWiki:Common.css, so the navigation template is going to look very strange to anyone else but me (the styles are missing that I have in my user common.css that need to be moved to MediaWiki:Common.css). I also plan to suggest a "more examples" link for each parameter section, as modelled after one of the older manuals to help users better understand different ways a parameter might be used to achieve specific goals). Though CA doesn't want the old manual format, this one bit can be a very useful carryover perhaps (their examples were easier to follow because there were many more of them, plus users could test and ask questions on each example's talk pages). FrozenPlum (talk) 21:46, 26 March 2022 (UTC)

To be clear, CA has said he wants the Gamepedia manual format as a starting place (that he will edit/change etc afterwards), so that's what I'm doing. Until all the content is here, rearranging everything is just going to complicate those efforts. Please be patient, thanks. FrozenPlum (talk) 21:50, 26 March 2022 (UTC)

I've been granted (temporary) ManageWiki permissions now to enable extensions, so I'm not being a pest to CA lol, and I'm happy to enable as desired. Per your question here, ~~I believe CA said he wanted to avoid putting things on main page or in the nav, until the content is fleshed out (understandable, he mentioned this in Discord)~~. I think it's so he can rearrange, correct etc., as desired first (and right now, I'm just moving over old content). This page works great to discuss things if it works for you, thanks for creating!

At the moment, I realized in my copying I forgot to attribute in edit summary (as is required of copy/pasting content) so had gone back to rectify that. I haven't filled out template documentation in some templates in case they're overhauled (but you're welcome to add template data regardless or simplify too). Or, if there's anything specific you'd like to work on, that's great, perhaps we can coordinate our efforts here? I haven't begun to look at what parameter information will need updating yet, CA just mentioned to not add anything to documentation relating to %EDITSUMMARY% because that doesn't work right now (and he's not sure he'll be able to fix it). Also, he said he recently added a feature for |openreferences=missing to only show redlinks, that isn't in the Fandom/Gamepedia documentation either (possibly we may need to avoid that until more is known, but I'm not sure on that one). Cheers FrozenPlum (talk) 01:45, 27 March 2022 (UTC)

Apologies, I misread his discord comment, we can add stuff to the nav bar, though I'd personally prefer to do that when the pages exist and function correctly, if that makes sense. FrozenPlum (talk) 02:01, 27 March 2022 (UTC)

Which extensions are you wanting enabled

I have several ideas and am not sure that listing all extensions is good, anyway:

DiscussionTools - Tools to enhance discussion pages. Includes auto signature, real-time preview of wikitext, and subscription of each topic. This is also being used on Wikimedia projects.
Linter - Dependency of DiscussionTools
VisualEditor - Dependency of DiscussionTools
TemplateStyles - It reduces the need for editing MediaWiki:Common.css by users.

It may be a bit early for feedback as of yet, given we don't even have all the content here.

I named this page lightly. It is OK to pick up another word and move this page.

I don't have access yet to put the necessary CSS in MediaWiki:Common.css, so the navigation template is going to look very strange to anyone else but me (the styles are missing that I have in my user common.css that need to be moved to MediaWiki:Common.css).

I believe it is a good practice to get rid as possible of contents of MediaWiki:Common.css that are for templates, in favor of TemplateStyles. See Help:TemplateStyles for futher infomation.

To be clear, CA has said he wants the Gamepedia manual format as a starting place (that he will edit/change etc afterwards), so that's what I'm doing. Until all the content is here, rearranging everything is just going to complicate those efforts. Please be patient, thanks.

Thank you for clearfiyng. I will.
Thank you --Lens0021 (talk) 06:18, 27 March 2022 (UTC)

You're welcome, and thanks for adding the extension names! These are now enabled. I see they are also enabled on meta, so I felt comfortable enabling here. My apologies, I'm being over-cautious only because it's not my wiki and my bureaucrat privileges are temporary. This no doubt makes me too overcautious towards changing too much while its owner is away, lol. Ah, thanks also for the link to clarify about template styles, we don't use it on our wiki because our templates are locked down, so I wasn't familiar with why it would be desired in this context. Makes much better sense now though, cheers. :) FrozenPlum (talk) 07:01, 27 March 2022 (UTC)

License incompatibility

The contents of Gamepedia Help Wiki is available under CC BY-NC-SA 3.0 and this wiki is under CC BY-SA 4.0. So the license of this wiki should be transfered to CC BY-NC-SA 3.0 (configurable in here). And I have another concern: In the future, we should document the features that are added to the CA's fork of DPL3, and maybe have to copy the documentation from the source code to this wiki. But the source code is under GPL-3.0 License. I do not know how to deal with this type of issue. Lens0021 (talk) 11:42, 27 March 2022 (UTC)

Thanks for letting me know! (It hadn't occurred I'd have access to do it, and, when granted temporary permissions, it still didn't occur to me, so is much appreciated!). I looked in ManageWiki; however, there is no option for CC BY-NC-SA 3.0. I've changed it to CC BY-NC-SA 4.0 for now, but I'm waiting on a reply on the Community Noticeboard to find out if this is acceptable (and if it is the only usable license going forward).

As for documentation relating to source changes, I'll leave this to CA to address, as I have no idea on either side of the issue (and certainly not both).

I think what you mention would be exceptionally helpful for users migrating from one version of the extension to another, my main points for clarification are:

How and where do you envision this being done on the wiki?
Would a "Key changes" and/or "Migration guide" page (or something along those lines), in addition to the normal in-line (brief) mentions of, and links to changes, sound appropriate to you? --I'm pretty excited by the idea. :)

If so, I'd want to add its link to on-page navbox and sidebar nav, once an appropriate title is decided.

Another suggestion would be to continue the practice of brief change mentions in-line (maybe with a harder to miss notice for them?), then I'd suggest providing a link to the relevant Changes/Migration page (and its subsection) for the fulsome details. I'd also propose not doing DPL extension code in-line, on the existing pages, for 2 reasons:

It could confuse new users who begin with the forked version of DPL3, to see code change blocks.
It may fragment general usage information further (a common complaint with the existing manual). A funny, unrelated side note, I also added the invocation syntax page to the navbox after reading the manual page where it said invocation syntax was most important page (ironically left from the main nav) lol... I'd add your "key changes"/Migration guide (or whatever it ends up being called) in the same space because I think it's of similar importance.

Questions regarding the extension code blocks are:

Would large extension code blocks be necessary (for the average user) to see, to migrate successfully from one version of DPL3 to the other?
Could shorter references from the code, with a citation and link to the full code on GitHub, be a feasible alternative to copying larger chunks of the extension's code (I have no idea if this is sufficient, I'm just wondering if it needs duplicating, or if perhaps function names, citations with links, and line number(s) could be an alternative if the MH licenses are incompatible, since I've seen that sort of approach elsewhere)?
Would the code sections need to be updated between different versions (if I understand correctly, though I probably don't, the code sections may change between versions)?

FrozenPlum

Sorry for the late I have not known this wiki was re-opened to the public as notifications didn't work.

Would a "Key changes" and/or "Migration guide" page (or something along those lines), in addition to the normal in-line (brief) mentions of, and links to changes, sound appropriate to you? --I'm pretty excited by the idea. :)

It sounds great to me and I even didn't know that the readme does not include that information, unlike the PortableInfobox.

I'd also propose not doing DPL extension code in-line, on the existing pages,

I can't understand this sentence. Does 'DPL' mean the original DPL for Wikinews? Wikitext code or PHP code? I think we should not show end users the PHP code at all. Do you mean administrators of wikis and the installation guide?

Would large extension code blocks be necessary (for the average user) to see, to migrate successfully from one version of DPL3 to the other?

Same, I am not sure what 'extension code blocks' means. PHP code? What I tried to write in my last post is the documentation of the code, not the code itself. I Apologies if I confused you. README.md#configuration provides many resources and we expect it to be always up-to-date and it is why I thought we should carry it to the wiki. Another example is something like below comment from here:

/**
 * category= Cat11 | Cat12 | ...
 * category= Cat21 | Cat22 | ...
 * ...
 * [Special value] catX='' (empty string without quotes) means pseudo-categoy of Uncategorized pages
 * Means pages have to be in category (Cat11 OR (inclusive) Cat2 OR...) AND (Cat21 OR Cat22 OR...) AND...
 * If '+' prefixes the list of categories (e.g. category=+ Cat1 | Cat 2 ...), only these categories can be used as headings in the DPL. See	 'headingmode' param.
 * If '-' prefixes the list of categories (e.g. category=- Cat1 | Cat 2 ...), these categories will not appear as headings in the DPL. See	'headingmode' param.
 * Magic words allowed.
 */

Reusing the documentation would reduce efforts to start from scratch and the possibility of the wrong description, but with license concerns. (I don't mean we should to include code in this way, we should remove /** etc and use normal paragraphs)

Lens0021 (talk) 13:45, 16 April 2022 (UTC)

The CC license was changed back btw, as it turns out (as confirmed by MH staff) that it was fine and was compatible all along as it was. Yes, for some reason I had thought you meant including code samples, which I really couldn’t understand why that would be even necessary, I misread that bit, so thanks for clarifying. I think paraphrasing text or changing its wording or order a bit, is good enough (as it is in most contexts to constitute a change) it does not need to be copied/pasted in its entirety, as-is from the readme and would need to be reformatted, reworded, and fitted into appropriate sections anyhow). The examples given can also be changed (and I’d probably want to change them anyway, since I generally have a plan for examples that I’m still fleshing out). Before updating things, my personal approach was to import, rename, reformat the text and fix bad/dead links and naming etc, and generally get the past examples working before integrating the new stuff; I’m still in the process of doing the former because it is also helping me to find some old bugs for reporting, and identify bits that were missing in the first documentation altogether. So far there have been 3 bug reports identified but I still have a long way to ggo in finishing off reformatting and fixing the old pages.

Request for ManageWiki settings

Could I use 1) wikitext mode in Visual Editor? It can be found in Special:ManageWiki/settings#mw-section-editing 2) Extension:PortableInfobox to reduce the effort to implement infoboxes. I think CA is also familiar with that because CA is the maintainer of the extension. But this may be an overkill solution. Feel free to about this. Lens0021 (talk) 13:59, 16 April 2022 (UTC)

After some thought on this, I’m actually going to disable VE and discussion tools on this wiki. When looking at pages and examples (and especially having links to pre-load examples into ‘’’source edit’’’ for people to test and try), the source code really needs to be worked in; VE complicates that. I get that a lot of people get used to working with VE so they don’t need to use, learn or type wiki syntax, but since DPL3 use itself relies on wiki syntax, and knowledge of it, it doesn’t make good sense from a teaching/learning perspective to enable ways around that. There comes a point where knowing and working with wiki syntax is important, this context is part of that.

As far as portableinfoboxes goes, since this site is intended as documentation for the DPL3 extension in general, which will eventually be linked from the MediaWiki manual site (and not just for Miraheze or Fandom wikis, where portable infobox use is wider), I’d like to stay away from portableinfobox formatting. I’d like to keep all examples as simple and as universal as possible. In this sense I do feel it is overkill, sorry. FrozenPlum (talk) 03:56, 17 April 2022 (UTC)

I forgot to mention, given you're familiar with template styles, if you're willing to copy the existing styles from MediaWiki:Common.css and get them set up as template styles instead, I'm happy to remove them from MediaWiki:Common.css after that. I'm so busy trying to get the rest of the examples and stuff sorted that I I don't really have time to do that bit. Cheers FrozenPlum (talk) 05:44, 17 April 2022 (UTC)

I can do but if I understand correctly, as you are not an interface administrator now, I should request for removing to another admin? (Just now CA is the only member of admin) Thank you, anyway! Lens0021 (talk) 13:08, 17 April 2022 (UTC)

I’ll just add a note that if VE is only for ease of short term revamping, I’d be completely fine to turn it on again temporarily then turn it off later when we’re mostly done. I just don’t love the idea of adding a layer of viewing/testing complication or swapping for the long-term if that makes sense? I have examples preloading content in source edit, users would have to know how to switch, though with preview right there I’m not sure why they would want/need to? I’m not a big VE user though, only using it for complex tables with multiple colspan and rowspans, so maybe there’s some essential component to it that I’m just not seeing at current? Perhaps you can help me to better understand why you think it is essential and if you see that as a short or long term need? Some of our users can’t even figure out how to switch between VE and source edit, or they use VE so much elsewhere that they cant grasp working with wikitext for tables etc, though that is very necessary for understanding a lot of DPL3 examples. FrozenPlum (talk) 08:54, 17 April 2022 (UTC)

Some of my requests were just my personal flavors and I am not frustrated whether it is accepted or rejected. I agree that improving user experience is important. Lens0021 (talk) 13:08, 17 April 2022 (UTC)

JavaScript for live examples

Hi, I've written JavaScript for live examples. You can try out this by following steps:

Visit User:Lens0021/Sandbox
Open your browser's debug console. It can be commonly opened by pressing F12.
Paste the content of User:Lens0021/Sandbox.js or below code. (pasting unknown code in the console can be dangerous, anyway)
```
mw.loader.load('/wiki/User:Lens0021/Sandbox.js?oldid=1968&action=raw&ctype=text/javascript');
```

I hope to make it a gadget on this wiki. But editing site-scope JavaScript is not permitted to me. Lens0021 (talk) 09:51, 17 April 2022 (UTC)

Sorry Lens0021, sounds interesting! Though I have given back my temporary reins (I'm having cognitive issues that are making things hard to manage and edit at the same time). CA should be able to see requests you make, though. Have fun and cheers! :) FrozenPlum (talk) 10:56, 17 April 2022 (UTC)

I'll just add my personal opinion on using gadgets/js for the examples - having gone the gadget and JS route for other things before, I've seen both JS convention change and resource loader method change resulting in broken features and scripts often, sometimes every MW update. For us (users on different wikis) this causes extra maintenance items to be maintained that can have a cascading effect across the site. I'm still personally leaning towards what I mentioned before, keeping things as simple as possible, using built-in MediaWiki features wherever possible, to reduce any extra maintenance overhead. I have been converting templates away from third-party extensions not bundled with MediaWiki for this same reason (Variables extension was formerly relied on for a number of templates and all important links, but its future is uncertain, loops also used which has recently been limited for causing issues). I feel, if there's a way to do these things using built-in methods, or extensions packaged with MediaWiki itself that are expected to maintain long-term functionality without breaking changes on updates, this is the way I'd personally prefer to go over the js/gadget route, given, I've been down that route a number of times before (and contacted CA about some JS stuff before for the same reason). FrozenPlum (talk)

Agrees. Maintaining code is not an easy thing to do and broken very long javascripts are disasters. And I also do not prefer the extensions have a lower bus factor than 2. I searched for an extension before I had written my script, but failed. Maybe I will file a feature request for, for example, Extension:TemplateSandbox. Thank you for telling me your story. Lens0021 (talk) 08:18, 18 April 2022 (UTC)

The built-in MediaWiki method I'm currently using for Template:Example (used for examples) works fine out of the box, and it doesn't need scripts nor extensions. It automatically adds a section to a user's personal "User:Username/Sandbox" page (using Special:Mypage) for them to test in if desired. Is there a reason why you think this needs to be done differently? It functions well (I thought, on testing), and preloads the examples into an edit page, with a preview button handy there for changing/testing examples without affecting their actual example pages. Also, separating the examples allows editing the manual to be easier, plus examples categorized per parameter use gives CA an easy way to find what things need to be updated when a parameter's behavior is changed. Separation and categorization was also intended to help users more easily find examples of what parameter (or parameters) they want to work with. Though I haven't finished that. FrozenPlum (talk) 02:49, 19 April 2022 (UTC)

Extensions like Extension:SandboxLink essentially do what I've already done in Template:Example. Most users create a Sandbox at the location I've created because it's the only way to preserve their experiments (as many want to be able to do, and as can be seen on meta as having been done by a number of users). FrozenPlum (talk) 03:07, 19 April 2022 (UTC)

@FrozenPlum: I wanted to just reduce the number of clicks required and the number of page movements. I don't disagree with your goal. I think the example system is the coolest. Lens0021 (talk) 05:01, 19 April 2022 (UTC)

But it is true I underestimated the separation. Thank you for the details. Lens0021 (talk) 05:13, 19 April 2022 (UTC)

A few other notes

I was intending to convert most examples to parser function syntax, given most want to be able to do more than the parser tag method allows (I have not run into one person yet who this hasn't been the case for). This was a common complaint with the old manual that I intended to rectify (that examples weren't a good starting point because it didn't present content in the most-needed syntax). From a teaching/learning perspective, it's easier to learn the best-practice/more-flexible parser function syntax first, and then simplify from there if desired, than it is to learn the simple syntax and have to essentially re-learn how to do things in parser function syntax afterwards (easier to give a horse their head to run, than it is to take it away while tring to run). Also:

I intentionally didn't add syntax highlighting to examples, since parser function syntax would make little to no use of this (and there is one part in the manual that explicitly states, "you can also use HTML syntax for the tags, although this is discouraged", though I don't know the reason for that, I had intended to ask CA if he knew why that was the case). If HTML tags should be removed, there'd be no sense to add HTML syntax highlighting, as it would highlight nothing.

More importantly, I also didn't add syntax highlighting to the examples because the examples are preloaded into source-edit sandbox sections for users to manipulate, and I wanted them to be able to focus on the examples and not get caught up in any extra unexplained wiki formatting, divs, tags, classes etc., (which is why I would recommend not adding anything other than a <pre></pre> around these (otherwise would need to be explained in the examples and could confuse the learning at hand, which is why I left it off intentionally--though I did initially consider it). Some also have little to know knowledge of divs etc., which are harder to explain.

I also wouldn't recommend placing the results of examples in blockquotes (or any other formatting) for appearance’s sake. I'm aware this would be nicer to look at, however since blockquotes are part of wiki syntax, and wiki syntax is used in examples (and preloaded to sandbox too)... it would cause a need to explain these or explain that blockquotes are not part of the result, which could quickly become cumbersome and redundant or confusing (nor would doing in one place or once per page suffice, since few read manuals in their entirety, rather more often using them for reference). I had concerns about even doing this for "pre" tags, but that's a bare necessary (that I still need to explain somewhere, but forgot to). This is the reason I'm keeping these as simple as is possible, unless the example itself is complex, in which case the focus should ideally be only on the complexity of the matter to be learned itself (the example, and nothing extraneous). Another complaint with the old manual was that users couldn't coherently source-edit to see the contents of an example, and better understand what it was doing because there was too much either added/extra "stuff" going on, or unexplained stuff not explained/linked that needed to be (what's essential to inspecting the example components and nothing more/less). Many gave up on the extension as a result, citing the manual was too hard to understand. I'd like to (hopefully) avoid those same pitfalls.

Given I have cognitive and communication problems, it's very hard for me to stop and explain my rationale with each idea/suggestion. My working memory and multitasking ability is frankly terrible, stopping and starting to do so is very hard for me (a personal flaw from my difficulties, that I wish I could change, as I know it's not ideal). I know the logic behind why I'm approaching things a certain way, unfortunately my ability to stop, think about, synthesize, and communicate this coherently in writing is also impaired, it takes more time than I have to sit down and just edit a bit each day, since I also have problems doing that for length of time (or writing at all). It can take me longer than an hour or two to write a reply like this due to my neuro-thing, which is then hard for me to continue the other work. My apologies for not having the bandwidth (nor ability) to explain better and switch between tasks (I hadn't anticipated this need so early on this wiki, and maybe I should have). These are the reasons I'm needing to hit pause, it's better if CA or someone else oversees, and I can work on bits and pieces on my own wiki at my leisure. I can always copy things I'm working on over later if they look useful, and if the content hasn't substantively taken a different direction meanwhile. If it has, I can keep my version for my own (and my wiki's) personal use, so the effort is good either way. :) FrozenPlum (talk) 04:49, 18 April 2022 (UTC)