User:PPelberg (WMF)/sandbox
| sandbox | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | Cscott, DChan (WMF), DLynch (WMF), ESanders (WMF), Matma_Rex, SSastry (WMF), PPelberg (WMF), Whatamidoing (WMF) |
| Document status | Draft See Phabricator. |
List items are fragile in wikitext, and there are many things (e.g., tables and images) that cannot be effectively embedded in lists. The Editing Team and Parsing Team are seeking your input on a proposal to introduce new wikitext syntax that will eliminate the aforementioned constraint and unlock new possibilities for people using wikitext talk pages.
You can find information about what is being proposed and how you can help shape it below.
Participate
[edit]The teams need to know what you think about this proposal. Specifically, the team is curious to know how you will answer the following questions:
- Of the proposals listed below, which do you think would best satisfy the requirements?
- What alternative approaches do you think should be considered?
- For each of the proposals listed below, what other advantages, disadvantages and/or unknowns do you think should be considered?
In addition to the above, the teams would also value hearing what other questions and ideas the proposals lead you to think about.
You can provide input by doing the following:
- Posting on this page's talk page: LINK.
- Posting to this ticket in Phabricator: LINK.
Decision-making process
[edit]The purpose of the technical decision-making process is to make a technical decision about MediaWiki or related software. If you are an active participant in the Wikimedia movement, then the technical decision-making process is probably very different from the RFC ("requests for comment") process used on your home wiki. If you are new to technical discussions, then you can read about Technical decision making. It is normal for technical questions to be discussed simultaneously in multiple places. There is no minimum or maximum number of days for a technical discussion. This particular discussion might be open for approximately five to ten weeks.
Please follow the Code of Conduct for technical spaces and bug management etiquette (e.g., provide practical information, not just votes for your favorite).
Who makes the decision
[edit]A technical discussion is not a vote, and outcomes are not decided by consensus among participants. The final decision is made by the developers responsible for doing the work, in accordance with the developers' view of what's best for the integrity, consistency, stability, and performance of the software and server systems.
Motivation
[edit]This section contains information about why this particular change is necessary and why making this change now is a priority.
Existing problems
The lack of explicit syntax for multi-line comments makes it hard to add complex content types within lists, including discussions that use list formatting for visual indentation. Specifically, this means:
- Contributors are limited in the types of things (e.g., tables and images) they are able to include in properly formatted lists (read: talk page comments). This inhibits them from being able to communicate about and collaborate on components like navboxes, series templates, and infoboxes within indented comments on talk pages. When contributors really need to use such features, they'll sometimes break out of the indentation structure. This makes it harder for readers, bots, and software to understand the structure of a conversation.
- Contributors face a higher risk of markup errors contained with talk page comments posted using DiscussionTools "leaking out" and corrupting content elsewhere on the talk page.
- Contributors are not able to create visual line breaks within the list structure without using HTML code or local templates.
- Contributors who use screen readers have a more difficult time understanding conversations, and subsequently participating in them, because the tools they use are not able to properly narrate/speak/announce the comments in a talk page conversation. Source
- People using features like the new Reply Tool are not able to use templates, tables and extensions in the tool's
visualmode.
New opportunities
In addition to the resolving the issues listed above, introducing syntax for multi-line comments would enable people to:
- Edit specific comments on talk pages. This is functionality that had been planned, but became blocked because of this lack of syntax. For more information, see: T242562#5897905.
- Build new gadgets that extend talk page functionality because comment parsing would become more reliable.
| What people type | What it looks like | The goal |
|---|---|---|
# {{Support}} Let's use that picture. [[User:Example|Example]] ([[User talk:Example|talk]]) 19:28, 9 September 2020 (UTC)
# {{Oppose}} I don't like that picture. [[User:Username|Username]] ([[User talk:Username|talk]]) 19:28, 9 September 2020 (UTC)
# {{Neutral}} I propose using this picture instead:
[[File:50M@2x.png|thumb|100px|Let's use this one instead!]]
[[User:New user|New user]] ([[User talk:New user|talk]]) 19:30, 9 September 2020 (UTC)
# {{Support}} any picture. [[User:MediaWiki default|MediaWiki default]] ([[User talk:MediaWiki default|talk]]) 19:30, 9 September 2020 (UTC)
# {{Oppose}} the first picture. [[User:Username2|Username2]] ([[User talk:Username2|talk]]) 19:30, 9 September 2020 (UTC)
|
 New user (talk) 19:30, 9 September 2020 (UTC)
|
|
This example uses a numbered list to make the problem easy to see, but the same problems appear in all lists: bullet lists made with *, numbered lists made with #, and definition lists made with ; and :. This problem is seen in many thousands of pages, especially talk pages.
Requirements
[edit]This section contains the requirements any proposal must need for it to be adopted.
- The new syntax must enable people to include components[1] that span multiple lines within an indented list item.
- The new syntax must not break existing content on talk pages.
- The new syntax must be interoperable with existing and future list-item talk page markup.
- The new syntax must work across all languages and be reasonably convenient to input using different text input methods.
- The new syntax must be compatible with the core parser.
- People looking at a diff or the wikitext source for a page must be able to recognize the new syntax as being part of the comment's formatting, and not part of the content.
Proposals
[edit]This section contains the different approaches
A) "Heredoc" <<< ...>>>
[edit]- Example
::::<<< line 1 line 2 >>>
- Advantages
- Generalizes an approach that was already adopted in a previous RfC. See: T114432#5411306.
- If the
<<<construct were found to be common in existing wikitext, these strings would be easy to lint away. - Interoperable with existing talk page markup.
- Would allow for nesting.
- Disadvantages
- Syntax for further nesting might be considered awkward.
- Editing and reading talk page source could become more difficult since a multi-line comment's "inner lines" would not be indented.
- Unknowns
- How general/widely applicable would this syntax be?
- How would attributes be attached to list items?
- What would happen if the software were unable to find a corresponding closing bracket?
- Example
:::{: line 1 line 2 :} - Advantages
- No special reply syntax needed.
- Interoperable with existing talk page markup.
- Disadvantages
- Perpetuates the idea that replies are list items.
- Not obvious how to add attributes or extensions.
{:syntax may already have meaning in some wikis.- Editing and reading talk page source could become more difficult since a multi-line comment's "inner lines" would not be indented.
- Unknowns
- Where would list item attributes go?
- Would the default directionality of the "start" / "end" construct work in RTL languages?
C) Email-style lines starting with >
[edit]- Example
>>>> line 1 >>>> >>>> line 2
- Advantages
- Follows the pattern email has established for quoting.
- Many people are likely to be familiar with how to use the syntax and what it means.
- Reply-specific; does not perpetuate the idea that replies are list items.
- Repeated brackets make it easy to understand a comment's level of indentation.
- No closing symbol required, avoids the risk of unclosed replies impacting the rest of the page.
- Disadvantages
- Is not compatible with heredoc syntax, so templates and replies will conflict.
- Not interoperable with existing talk page markup. Read: may not be possible for someone to use existing syntax to respond in a thread containing replies written with this "new" syntax.
- Unknowns
- What syntax would be used for attributes?
- How would multiple replies be posted at the same level? E.g.:
>>> line 1 >> >>> Is this paragraph 2 of the âblah blah blahâ comment, or did the previous line separate this into two replies (maybe with an empty reply in between), or what?
D) Use what already exists
[edit]- Example
::: <dd> line 1 line 2 </dd>
- Advantages
- Almost works already.
- Attributes will work.
- Disadvantages
- Mixing
:and<dl>doesnât work right now; block tags would be necessary for every indent level (but this could be fixed). <dd>without an opening<dl>doesnât work right now, and it would have to be allowed.
- Mixing
- Unknowns
- Pre-save transform (e.g.
~~~~) doesnât work inside normal MediaWiki âXML-style tagsâ, so it would have to be fixed somehow, or the tag would have to be implemented at the preprocessor level (like)
- Pre-save transform (e.g.
- MediaWiki âXML-style tagsâ also canât be nested.
Notes
[edit]- â Components: a table, template or an extension (including references).