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 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)

Yes, requests to change things should go to CA, I'd hope he'd take this discussion into account when making the changes, as some of what you have reqeusted now needs to stay in Common.css per the reasons below.

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:

1. Visit User:Lens0021/Sandbox
2. Open your browser's debug console. It can be commonly opened by pressing F12.
3. 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)

Yw, and thanks for elaborating. Ah, gotcha, and makes sense since click-spend can indeed be annoying, I agree with you. In this case, I think it is well justified, though. FrozenPlum (talk) 07:28, 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)

Template Styles

Lens0021, DPL parameters are now showing on all pages as escaped table syntax and have stopped working. Is that because a template style was added to that template without the corresponding style page it refers to being created? Or any idea what else might cause this to happen? It worked until the change to its template being done (its history showed just the template style being added, so I'm trying to figure out why it had this effect). Thanks FrozenPlum (talk) 08:27, 19 April 2022 (UTC)

I have reverted that template for now, until the solution is found, so the display isn't broken for every page it is used on. Please feel free to restore that edit if a solution is found. FrozenPlum (talk) 08:39, 19 April 2022 (UTC)

Apologies for the incident. I will retry carefully the next time. Lens0021 (talk) 09:11, 19 April 2022 (UTC)

Could it be that the style is in the wrong namespace? I see one located in the Template NS Template:DPL_parameter/styles.css --Soukupmi (talk) 09:14, 19 April 2022 (UTC)

No worries Lens0021, stuff happens. I'm not sure Soukupmi, I'd have to check the manual for that extension another day, I'm not familiar at all with it (and for now, it is bedtime for me so I can't look). Have fun folks! FrozenPlum (talk) 09:30, 19 April 2022 (UTC)

What exactly is the reason for having a different css anyway? TBH I was really confused by the sudden use of a template around a working example (yeah, I lurk around here because I want to learn more about the usages of DPL). And just for the reason of looks complicating an example unnecessarily with a template, that an unknown user looking for help with #dplmatrix would now think they have to use to get it to work.
For me examples should have a working code that I can easily understand and copy-paste (with adaptions to my need). No fancy stylesheets - if I want those, I'll do it on my wiki. KISS is the way to keep it, especially for examples, even more on a topic as complex as DPL.
Thanks, FrozenPlum, for making it clear again, and please, Lens0021, don't make them confusing - DPL is confusing me enough. --Soukupmi (talk) 09:54, 19 April 2022 (UTC)

Fresh eyes helped me to see the reason this broke: Table syntax must always begin on a new line to be correctly recognized and rendered, and apparently when a template styles reference is inserted at the beginning of a line, MediaWiki tables also seem to see it and not provide proper table syntax. In these cases either a new line is needed, or template styles inserted elsewhere. I undid my "undo" and added the line there, purged the cache for a page it's used on, and it now correctly displays, and enables template style use. Though I will say that this template is used in some examples (out of necessity), and template styles does then complicate users inspecting it (when the examples it is used in are already quite complex and thus should remain free of added complexity). For that reason, I will probably end up removing template styles from that example when I finish refining its description and linking to its template (I had done an initial few stabs at the example, but didn't finish and left it to finish later). If involved/used in an example, please don't include template styles for the reasons mentioned above and below. I left it for now so it could be seen that temlpate styles before a table interferes with the table rendering correctly (this was good learning for me also). FrozenPlum (talk) 23:06, 19 April 2022 (UTC)

@Soukupmi What I tried is moving styles from MediaWiki:Common.css to the /styles.css subpages. The appearance changes are not intended. I am sorry for confusing you. Lens0021 (talk) 10:59, 19 April 2022 (UTC)

I'm not talking about appearance. You literally wrapped the example into a template - for style reasons solely. People who aren't very familiar with how templates work (yes, I've met a few) could now think that they have to do it like this.
Also - I don't see any reason why you would want to move the styles to a different stylesheet - maybe you can enlighten me there. --Soukupmi (talk) 15:00, 19 April 2022 (UTC)

@Soukupmi: My answer to the first problem: I know some examples are still wrapped by tables. It is hard to expect that people who are not familiar with template syntax are familiar with table syntax. I think the fact that the manual shows raw wikitext can prevent users from having to view the source.
Second: The styles defined in MediaWiki:Common.css have a very massive effect, making it hard to expect the result of a modification and making it hard to edit the styles. It also decreases the performance of the whole wiki site. Readability also can be a reason. https://www.mediawiki.org/wiki/Help:TemplateStyles#What_problems_does_it_solve? can give more detailed backgrounds to you. Lens0021 (talk) 16:48, 19 April 2022 (UTC)

I can see now that the example styles need to stay in Common.css so as not to complicate and create problems with the examples and the learning. I'm sorry, Lens, other styles used in the manual can be in template styles, that's fine, but making all into template styles is not more important than the needs of people learning to use the extension (and not complicating examples unnecessarily for them as stated and explained numerous times above). I understand where you're coming from, though and in other situations I'd agree with you, this situation requires a different approach due to the subject matter and the needs of the resource. It goes against instructional/learning best practice to obfuscate examples in any way, this would do that (and did do that). Not being able to edit example styles will not be unexpected to users given all three DPL manuals had the styles in Common.css, the full original manual, the gamepedia/fandom manual, and the German Manual Hilfe:DynamicPageList). It is more disruptive to have examples and content that can't be easily understood, than it is to have a handful of styles locked down (I'd find it far more disruptive if the manual styles were changed randomly when visiting the manual, and if the examples were complicated by extra stuff--which they were on the fandom site and again, is the stated solid reasoning for not doing that here).

I need to be frank here, I'm finding the insistence to change everything I've been doing, as I've been doing it, to be very disruptive; as well as essentially forcing me to explain myself at every step, hindering my efforts and ability to finish the project I proposed, and that I told CA I would get established for him (and that he accepted as such). Especially after asking for patience, time, and understanding to get things solid, giving my unique neurological challenges (I am repeatedly not being afforded these accommodations, despite explaining my need for them and the nature of my challenges--that's not okay). The changes proposed have not been well-thought-out as to understand what it is I'm doing and why. They have not also been well thought out towards maintenance burden (or the utility of what I've proposed for the audiences it was proposed for being more important than other factors); nor towards instructional best practice, or towards the importance of the learning over the ability for individual users to control things of much lesser importance. Most new wikis are granted a period of understanding, that time is needed to get a coherent direction set and content fleshed out. I am not being granted that (even after stating why I especially need it), and I'm not sure why. I did not make the decisions I made lightly, I am fully trained in EdTech and Instructional design, even though I may have severe limitations based on my neuro-condition (my training is why I offered to CA to do this, he accepted--I'm fulfilling that). I explained my logic and reasoning soundly at every turn. I'd appreciate if I wasn't being pressed to continue to re-explain the same things in different ways after already having done so. If I was given the accommodations I need, I'd continue working here and finish what I proposed, instead I find myself essentially feeling forced to work off-site (to lessen such disruption) and move content back and forth later instead. I should not have to do that, I realized this morning that having to do that was essentially letting myself be "running off" from a project I proposed to CA and stated I'd do (which again, he accepted). Things are being changed in the meantime so that my efforts are nullified... So, I'm not going anywhere, I will continue to work here and fulfill my mandate. Please try to better understand the larger picture, the teaching/learning context, and my motivations and insights as an instructional designer, before making repeated requests, suggestions, or changes that can derail those efforts. I also feel it is inappropriate to seek to impose personal preferences on a wiki over the needs of average users and the goal set for the resource. Also, I'll point out that if you have preferences for styles or javacript that differ from what exists, you can apply these in your user styles or JS.

Could I take a time to understand your comment? I am using translators whenever I met unknown phrases, I need more time to read comments several times, to make sure what I understand is correct. Lens0021 (talk) 23:47, 19 April 2022 (UTC)

After quick reading, I see now that I have made pressure on you. I feel responsible and I apologize for what I did and do. I will take a break to review my actions and figure out what I had to do instead. Lens0021 (talk) 00:30, 20 April 2022 (UTC)

And yes, some examples are in tables, you make a good point that these must be separated out (I will do that and have already been doing that for some, but again I need to be given time to actually finish doing that). Also, I'd be a no-vote, again (already explained why), for enabling VE and structured discussions on talk pages because it is common for people to ask questions involving the use of DPL3 in talk pages, and to have those questions answered in-kind, with working examples as can be clearly observed here. Such also requires working in source, this too was part of the plan and my decision for disabling VE.FrozenPlum (talk) 21:44, 19 April 2022 (UTC)

Thank you for letting me know you are using translate, that helps me to understand better. Yes, I have felt much pressure, that pressure caused me to resign my admin access and work elsewhere to avoid questions and requests (so that I can get work on pages done). When I asked you to be patient, what I meant was: please give me time to get the articles well written and examples working before making more questions, requests, suggestions, or making more changes (those things that can wait, they will be much easier to discuss/do/change after my initial work is done). Doing wiki things is already very hard for me because of my brain disease. When anyone adds more problems, questions, changes, or requests to that, it makes editing almost impossible for me. These things causes me to forget what I was doing often, or make it take 10 times longer to get things done. I am not well enough (in health) to manage with that added difficulty, it makes me suffer needlessly (stress, distractions, and interruptions all worsen my brain problems). When someone asks you to be patient, they usually expect to be left alone to finish their tasks before being asking to do/answer/change more, or do things differently (I expected to be left alone to finish my tasks). I have very little time to feel well each day and edit because of my brain disease, I need to use that small amount of time to fix the pages, I should not need to also reply to questions, requests, and check if your changes or suggestions make a problem for my plan or edits. I can edit pages, or I can respond to questions/suggestions/changes, but I can't do all of it, I need to edit the pages. Instead, please wait, please give me time to get the articles well written and examples working before making more questions, requests, suggestions, or before doing more changes that might create problems for my work (those things that can wait, they are easier after my initial work is done). FrozenPlum (talk) 06:23, 20 April 2022 (UTC)

@User:Lens0021 I can see your point - thanks for the link and explanation. Makes sense to do this for some parts of the wiki for sure. Yet I also see that you are trying to force a nice style (or nice way of applying and editing styles) to a half full wiki.
I was taught by years of programming that first comes the content and then the "making it nice".
When I go to a help page I don't care about what it looks like - important for me is readability and that I can understand it. (and maybe that it doesn't burn my eyes out). FrozenPlum sounds like she knows what she's doing and - even more important - why, so I'm confident that it will be readable after she's done with it. And I don't expect much more than this from a help-page-wiki, which I hope this will be in the end. Let's give her the time she needs to finish it, shall we? --Soukupmi (talk) 22:10, 19 April 2022 (UTC)

(This comment is hidden by lens0021) Lens0021 (talk) 23:47, 19 April 2022 (UTC)

I agree with your point. I had to consider the stage this wiki is on and which one is more important. Thank you. Lens0021 (talk) 00:43, 20 April 2022 (UTC)

Yes, content, writing and examples done first, then styles and formatting later, please. I didn't know there would be a problem using template styles (I don't use it). I thought you'd do it for manual parts like navigation, keys, DPL parameter first (I can't think of any good reason why users should be able to change example styles, honestly, that is not a necessity). Also, I apologize, I thought when you got to the examples, if template styles caused a problem that would complicate those examples, I thought you would know to stop there. I can clearly see now that template styles are impractical and problematic to be used on examples because of how the examples are done--this is exactly the reason I wanted questions, suggestions and changes to wait until after I was done fixing all the other content--the problem that happened explains perfectly why this stuff needs to wait; because all of the questions/requests and suggestions made will be easy to answer (or have been already answered) by the time I'm done that work. So, I'll say it again, please give me time to get the articles well written and examples working before making more questions/requests/suggestions/changes (those things that can wait, they will also be much easier to see/understand, discuss, do, and change after my initial work is done, but not before). Thanks for your understanding and willingness to wait until that's done, it is much appreciated. FrozenPlum (talk) 06:23, 20 April 2022 (UTC)

Thanks to you both! I agree the order of doing is important. I will try not to take a long time to get the changes done, but that being said I do need to do it in small chunks over time, I apologize in advance for this inconvenience. PS. Thanks for fixing the edit conflict, Soukupmi (I hadn't noticed it). FrozenPlum (talk) 08:12, 20 April 2022 (UTC)

Content Items that will need doing

There are some items that need doing in the content, that would be very helpful to have (if anyone feels like doing it, if not, we'll/I'll get to it eventually). This can serve as a reminder/checklist for later, too:

• If there are defaults for anything (which there should be for many things) they need:

• — ('''default''' is false) for this: — (default is false)
• Or — ('''default''') for this: — (default), (if the option at hand is the default).

We can refer this that Lens0021 linked, since that may have the rest of the missing defaults.

• Variable names should be in code blocks, and if not in close proximity to an already linked repeat or its own page section. These should also generally have the variable linked using the "DPL" template: <code>{{DPL|%PAGE%}}</code>
• Parameter names should also be in code blocks, and, if not in close proximity to its own section or another already linked repeat, should be also linked: <code>{{DPL|title}}</code>. The only thing to keep an eye out for is, if a value is specified, that value should be in italics (there are a number of places this is not yet the case), e.g., addcontribution=true should be addcontribution=true, though of course in templates such as {{DPL parameter}}, the equals characters needs to be {{=}} or use <nowiki></nowiki>.
• We do need to check the parameter descriptions (thanks Lens0021 for pointing this out) against the descriptions in the parameters.php to see if they still align, if there's missing/useful information that needs adding, or if functions changed; though, we can't just take that wording as-is (there's a license difference--again thanks to Lens0021 for noticing that), we need to describe that behavior in our own (different) wording, which shouldn't be a problem (I may tweak this wording a bit as it relates to other paramters).
• If there are concepts that are moderate to advanced MediaWiki knowledge ("sortkey" and magic words were examples I linked) would be nice to link these to the relevant MediaWiki manual page for easy understanding/reading.
• Anywhere we're referring to the DPL3 extension in the text (not in syntax or examples of course), ideally these can be swapped from "DPL" to "DPL3" (eventually this may also aid SEO, when it's time to look at such, later on).
• There may need to be a review for minor fixes, typos, spacing adjustments for readability; I'm making sure headings, syntax lines, examples, have the equivalent of 2 lines of space between each to increase scanning ability and readability (which is necessary from teaching/learning perspective, and also makes page editing far easier spotting things on longer pages).
• When the examples are more complete (apologies, I'm cross-referencing and testing examples from multiple pages when doing this and filing bug reports, so it's taking some time, especially for the complex ones) after that, they'll need to be reviewed/checked for any missing information and to make sure they're clear and concise. I may need a few run-throughs to refine some of these, and you guys will likely spot errors/problems I missed (please feel free to just fix these, I can look at refining later if there needs to be a writing style tweak.
• I forgot to add Other parameters into the sidebar below Controlling output volume, that'll need to get added later (this is more of a reminder for a later list to discuss). H4's also need a color (maybe deep blue or the MH logo dark brown) to set them apart from bold text (this has always annoyed me, that they'd make the default H4 style for vector to perfectly match bold text. A heading should never blend in with body text, that makes zero sense, probably they wanted to avoid imposing a color on people, so left it for customization). For now, I have an (ugly and temporary) {{hr}} style to separate these, it will need to be fixed/replaced later, when H4 is fixed (for now I need visual separation between these to finish working on and sorting out their complex include examples. I had to do that only as a temporary adjustment, to be able to work in a sane way). I'm still working through some of the harder to test and untangle examples.

Cheers FrozenPlum (talk) 21:32, 22 April 2022 (UTC)

Taking more breaks

I’m having problems with spasm, focus, and a number of other significant things. As there is no urgency for the resource (I asked CA in discord that there was “no urgency”, and this was indicated to be fine), I will need to do contributions at slower speed. Hobby (slow) is about all I can manage, but even doing things at that pace, I’m reminded I still routinely end up burnt out and not feeling well (as is the case atm). The good thing is, things are getting somewhat closer to being organized, working, and approaching ready, there’s just a bit more to go; so, I’ll try to finish the last section of my plan, I’ll just do that more spaced out and taking more breaks. I apologize for the length of time this is taking, and the need to take more time; I just can’t do normal-paced things due to my limitations. Sometimes I forget my limitations for a short while, until my body gives me a rather harsh reminder (it’s currently on strike XD). FrozenPlum (talk) 21:04, 25 April 2022 (UTC)

The other good thing is, most things that are not working are now marked as such here (the other things seem to be fixed and working well again, which is awesome), and the Gamepedia/Fandom DPL3 manual can be used in the meantime, as it is still the official manual on the extension page until this one is more ready. FrozenPlum (talk) 21:22, 25 April 2022 (UTC)