User:Retro/Testing 1

Here's a list of things my test pages have taught me:


 * I thought I'd solved all my linking problems, but then I remembered: we only have a tool for counting section links in redirects; it doesn't apply to piped or other section links, which very well may target to nonexistent section undetected. There should be a database report for this, but it'd probably be performance-heavy.
 * When I was standardizing the category order for Unicode character point redirects:
 * Wikipedia's documentation of category sorting is inadequate, and I will probably have to look at the source code to fully understand it.
 * When I was trying to fix a broken section redirect:
 * It appears that when a .## escape is used in a section link, all special characters must be escaped. Based on some experimentation, I have a strong suspicion that a special character is any character matched by the regex [^\-.0-9:A-Za-z]. Certain sections require these escapes; for example, if a section has the vertical bar character, it can't be included in a wikilink literally, as it has the function of piping in the wikilink syntax.
 * When I was investigating the usefulness of HTML comments in communicating information to editors:
 * The VisualEditor displays HTML comments.
 * HTML comments are not transcluded with templates (for obvious reasons; comments are often used to separate template coding elements to make understanding and altering the template code easier).
 * As far as I can tell, pings only work if they're added as part of a new section of contiguous text that ends with a signature. Anything else causes a ping to fail.
 * Whatever bug I found here can't be reproduced. It was probably a network or browser issue. I should have saved the HTML and tried the wikitext on another page when I noticed this issue. Or maybe there was an issue, but it was fixed since I noticed it.

Module testing
Substitution testing.


 * Fails (see this):
 * hello
 * Works:
 * So the take-home is: substitution doesn't work in every case where transclusion will work; magic word variables in particular apparently aren't interpreted earlier, so transclusions of variables will work, while substitution will fail. I should add this example to the Meta help page.
 * So the take-home is: substitution doesn't work in every case where transclusion will work; magic word variables in particular apparently aren't interpreted earlier, so transclusions of variables will work, while substitution will fail. I should add this example to the Meta help page.
 * So the take-home is: substitution doesn't work in every case where transclusion will work; magic word variables in particular apparently aren't interpreted earlier, so transclusions of variables will work, while substitution will fail. I should add this example to the Meta help page.
 * So the take-home is: substitution doesn't work in every case where transclusion will work; magic word variables in particular apparently aren't interpreted earlier, so transclusions of variables will work, while substitution will fail. I should add this example to the Meta help page.

I don't understand how  gives the wikitext " ". That means the example was well-chosen, but the explanation falters.

- Ah, so it substitutes the module as represented in the template; it doesn't substitute the module's output itself. I wonder about safesubst:?

- In this situation, safesubst: behaves identically to subst:. I guess I'm due for some more reading.



Foo (Baz) Qux
This is a (successful) test for a Rdcheck bug I recently noted on my talk page.

The bug is explain in more detail here; there's a related notice on 's talk page here.

!"#$%&'*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
I don't know whether this section will parse correctly, but I'm about to find out! This might trip the edit filter; I guess I'll find out.

Try &lt;nowiki&gt;&apos;&apos;&apos;this&apos;&apos;&apos;&lt;/nowiki&gt;!
I don't understand how link parsing works well enough; perhaps this will clarify. While the section above looks like has , it doesn't actually have the tags themselves.

The source below is representative of code and its output, but it's not encoded the same as it appears.


 * Infinite regression this way.
 * &lt;
 * I initially tried to surround the entire content with  (next bullet); is kind of magic; it's probably my favorite template currently.
 * BRD
 * Here's where it can break down. A collision.
 * BRD
 * Appending to the beginning won't change anything, no matter how many you add.
 * BRD
 * The prime exhibit: tags (or at least ones) interrupt link parsing, so it just displays plainly.
 * BRD
 * But comments don't interrupt; I assume they're removed from the source earlier in the parsing process.
 * BRD
 * The prime exhibit: tags (or at least ones) interrupt link parsing, so it just displays plainly.
 * BRD
 * But comments don't interrupt; I assume they're removed from the source earlier in the parsing process.
 * BRD
 * BRD
 * BRD

My edit summary when I edit this section reads Try &lt;nowiki&gt;&apos;&apos;&apos;this&apos;&apos;&apos;&lt;/nowiki&gt;!

But this makes me think the real bug with anchors is the edit summaries; the parser should be more discerning when it generates an edit summary, just like it's discerning when it generates a section link.

Really, the consistency of edit summaries needs to be improved in general; because I've added an anchor, it now generates the edit summary Try &lt;nowiki&gt;&apos;&apos;&apos;this&apos;&apos;&apos;&lt;/nowiki&gt;!, which is not actually a valid link to the section.


 * See this page for more information.

Whitespace in the middle
Consider:


 * This link works.
 * This link fails.
 * And surprisingly, the edit summary link works.

Subst test
Using subst on a template that doesn't exist: