Topic on User talk:Jc86035

Would you take a look at User:PPelberg (WMF)/sandbox and let me know if it makes sense? If it's confusing to someone like you, then I need to re-write it entirely.

I'm not sure if I would be the right person to ask. Am I really representative of the target audience? If the text contains jargon that would only be understood by a subset of editors, I might not notice, but someone else might.

My open questions that weren't answered by the page:

• Who is the target audience?
• Who gets to modify the content of the RFC? Would non-staff members only be able to make changes to some sections, or would we be unable to make any changes at all?
• How concrete are the proposals? Primarily, for proposals B and C, is it likely that a different set of characters would eventually be used during implementation?
• If I don't like <dl> or <dd> tags (or some other part of the output HTML, as opposed to the wikitext) being used on talk pages, would that affect the RFC at all? In other words, is the scope of the RFC limited solely to the proposed changes to the grammar of wikitext?

The target audience is people with qualities that you combine: experienced editors who use wikitext and people who know something about wiki-related tech stuff (any level of technical skill). The one important quality that you don't have is using a non-English keyboard (because if typing certain characters is really difficult in some languages, they really need to know that).

"The RFC" happens in multiple places, several of which (e.g., e-mail) don't have any method for changing what other people wrote. Alternative proposals are welcome, and should be proposed in discussion (e.g., a reply e-mail message, a section on the talk page). There could be an option "E", or "C.2", etc.

The syntax for A and B is set in stone, because A and B connect to other work (e.g., T114432 for A). Deciding that you wanted mostly A but to use %% instead of <<< would amount to a (partly) new proposal. Proposal C is not set in stone; it's just a copy of a conventional approach used in e-mail, with no history in MediaWiki. Some e-mail systems turn that into an indentation (like a forwarded message). Changing the characters typed wouldn't change the nature of that proposal.

If you don't like HTML tags, then you should vote against option D. This won't affect only talk pages; any wikitext that works on talk pages will work in articles, and vice versa. I'm not certain that I understand the last question. The scope of the RFC is about expanding wikitext (unless you vote for option D, in which case they'll use the existing methods, which means scattering raw HTML across talk pages).

Essentially, the content of the last point was just about the concern that has been raised in previous discussions about how <dl> and <dd> have specific semantic meanings that don't really fit on talk pages. As an example, if option A were to be implemented without any additional changes, the project might well conclude without the replacement of the <dl> and <dd> tags, and either a parser change to interpret definition lists without any <dt> tags differently (T6521) or new syntax (the addition of option C) would be necessary to avoid that outcome. The presentation of the options sort of implies that at most one of the options will be chosen even though they aren't mutually exclusive.

I agree with you that <dl> and <dd> have specific semantic meanings that don't really fit on talk pages, but <dl> and <dd> are actually appearing in the HTML on talk pages, and there is no current plan to change that.

In this RFC, options A, B, and C would improve the current HTML (in which the <dl> is broken if you put a thumbnailed image in the middle of an "indented" thread) via the addition of a new wikitext "code"; option D would improve the current HTML via the addition of <dl> tags in the middle of the wikitext. All options would produce (approximately) the same HTML for the reader. The difference for editors is primarily in what you'd see in the diff.