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:

1. It could confuse new users who begin with the forked version of DPL3, to see code change blocks.
2. 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 from the readme). 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 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, 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)