User:FrozenPlum

This is not my wiki, I'm just a Miraheze user helping to get some content moved over. Feel free to reach me on my Talk page.

Taking breaks
I’m having problems with spasm, focus, and needing to do frequent fixes to my mistakes (and not enough cognitive reserve to see or do them correctly the first time, without many repeated edits). As there is no urgency for the resource (I asked CA in discord and this was indicated to be fine), I will need to do contributions at an even slower speed. Hobby (slow) is about all I can manage, 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) if I try to do more. The good thing is, things are getting somewhat closer to being organized, working, and 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, taking more breaks. I apologize for this need to take more time, sometimes I forget my limitations for a short while, until my body reminds me of them again.

Self Reminders
.orange-box { background: #fff3e9; border: 1px solid orange; padding: 3px; }
 * Still need to go through and check consistency, clarity, style etc for text and examples (because I have a particularly hard time with this). Language or descriptions that aren’t quite right yet, especially in examples. I knew this would need to wait until last, because I wouldn’t be able to see the mistakes/problems/clunkylanguage before everything else was mostly working and simplified/separated. Takes me multiple passes to “see” what needs fixing.
 * Controlling output volume has several temporary hr sections until the heading colors for H4 are changed (I'd suggest the same size as H3 but maybe dark blue, or some other deeper color, just something that sets these apart better and gives a visual break to separate the subsections so they don't run together visually. This is because by default, Vector has H4 styles as indistinguishable from body text in bold (which is and has always been problematic, likely they didn't want to impose a color choice on people, however it creates a readability problem). Ideally, I'd like some kind of very faint, partial separator since this uses these sections extensively for long chunks of text with different headings that badly need differentiation.
 * VERY much need (because the examples are horrible with them in-line) to move all CSS styles used in,  ,  ,   to MediaWiki:Common.css (with intuitive names, like orange box, blue box, pink box, white box, so they don't need extra explaining). Also, this needs to be in Common.css because it's used across multiple pages and examples (and really shouldn't be edited). Also, the colors need to be toned down to the below visual example, I just used existing ones for now.

.pink-box { background-color: #f9dfe3; border: 1px solid #fe778f; padding: 3px; }

.blue-box { background: #e5edf8; border: 1px solid #6060fb; padding: 3px; }

.white-box { background: white; font-style: italic; border: 1px solid black; padding: 3px; }

For this:

Which would also simplify the syntax examples accordingly:
 * Self-reminder, MAKE SURE when you do the above ^ you also fix the syntax example sections.

---


 * Still need to work though Special:WantedPages to fix or change any of these that should or should not be there.
 * The pages for submitting a bug report, installing, getting extension (its MW page, github), giving feedback etc are not here yet and where this all goes might get juggled around depending on UO's feedback.
 * There probably should be a page explaining how to enable DPL3 on Miraheze (or linking to MH ManageWiki docs and at least saying what tab the extension is found in).
 * Still need to add notes to areas where there's code but a non-working examples.


 * Note: I still need to go back through to determine which templates/page (if any) require string functions to be enabled for Parser Functions extension. Once determined, should make sure it is also noted everywhere pertinent (some examples may rely on this, it is not default turned on at MH). See Examples for more info.
 * states that the required settings is.
 * states to use.
 * states the syntax is.
 * that needs to be added to docs (later). It too currently kicks fatal error with imagecontainer, logged on GitHub.
 * I'm tracking note use at Category:Development.

DPL3 Code Demos
I'm aware almost all use examples are currently broken, this is intentional until they can be replaced because this resource is in development. It is not ideal to have manual pages manifest inside the manual itself (this adds a level of unnecessary complexity for new users). Ideally, it would be optimal to have different example categories to draw from (e.g., fruit, pastries, countries, etc.) that are overly simple, and nearly impossible to confuse with other site content. Some time is needed to determine a solid instructional plan for this, it will likely be similar to the examples used in the Help:Tables page to explain tables simply, on MediaWiki.org. It is best practice to begin with the simplest examples possible to avoid ambiguity and any level of unnecessary complexity. This type of approach shifts the focus from the output to the learning at hand because the concepts used in the examples are highly intuitive and easily understood enough to mostly be ignored. It is best practice to use simple concepts in examples, and only add complexity to the learning itself (not the examples) as the complexity of the task increases. I need some time to think of a solid structure and organization for these "demo pages" (such as category:fruit, category:pastry category:coutries etc). Please be patient, until the examples are corrected, please use the Gamepedia DPL3 Manual.

Examples
It would be good to have "more examples" links in-line, in each parameter's page section, that display a full selection of examples specific to a given parameter. Ideally, these should be named with parameter name first, followed by "example" or "(Example)"; this allows examples to be quickly-skimmable from different entry points (there are practical reasons for this as-is). Different entry points, such as the Examples page and Examples category, will have different organization. Having the key words at the beginning of each page title makes readers do less work (not having to read past "Example:_" every time, to find what they want (they can ignore the word "Example/example" if placed at the end (while I don't love titles like "Parameter:_category" because it mimics a namespace, and if a "Parameters" namespace is created the blank space at the beginning will be removed and parameter name changed to title case, this is the only feasible way to have lowercase parameter names to avoid ambiguity, despite the unorthodox approach).

The logic to rejigging the examples, is to cater to different audiences and entry points to the information:
 * 1) Comprehensive – Audience: Average or infrequent visitors, needing to re-read parameter sections – Basic examples still stay in-line, but each parameter section links to a "more examples" page, for a larger selection of different use cases/examples for the given parameter.
 * 2) Task-based – Audience: Moderate to advanced and/or frequent visitors, already having read the parameter sections. – Allows a fast starting point, or quick copy/paste of example code to adapt, without having to sift though long pages/TOCs (a problem with the current Gamepedia DPL3 Manual).

An idea (that might not work), is that individual examples from "More Examples" may need their own pages, so they can be categorized by parameter use. If categorized by parameter use, these can be transcluded into the other pages mentioned ^ above. I'm still thinking about a system of sorts (and if this is even feasible) for this, it may take some time. Ideally, (also may not be feasible) I'd like a way to get each bit of code to go into a sandbox, with preloaded text, for someone to try manipulating.

From Creating pages with preloaded text for sandbox test links, from example pages. "default=Special:Mypage/parametername test" loads "User:Username/parametername test" (a reminder that if already existing, the preload won't work, and to enter a distinct name other than "test" might work.

The DPL2 site had an Examples category, but the examples had generic names like "Example 002" which made the task-based approach not feasible because you'd either have to click every one, or had to sift though manual sections like the Gamepedia Manual currently. Also, too many in-line examlpes can cause issues. Some titles are a little strange, like "Example:_Display_images_used" but that type of categorization and/or page might be a good idea for when users want to see different ways to display images! Relevant examples, to the task at hand, just need to be way easier to find, which is why I'd need some time to think about approaching this systematically.

Templates using Variables and Loops
The following were found to use other extensions, see Category:Templates to simplify or eliminate for which uses which. Variables extension's future is uncertain, so these templates may need to be simplified, adjusted, or eliminated:

Note: I still need to go back through to determine which requires string functions to be enabled for Parser Functions extension. Once determined, should make sure it is also noted where pertinent.
 * Merged with string functions and need it enabled:
 * len, pos, rpos, sub, replace, explode


 * Not merged, need to make sure not used:
 * pad, urlencode, and urldecode