Meta:Babel

 ← Index of discussion pages

Babel

archives (latest) →

This is the general discussion forum for Meta (this wiki). Before you post a new comment please note the following:

• You can comment here in any language.
• This forum is primarily for discussion of Meta policies and guidelines, and other matters that affect more than one page of the wiki.
• If your comment only relates to a single page, please post it on the corresponding discussion page (if necessary, you can provide a link and short description here).
• For notices and discussions related to multilingualism and translation, see Meta:Babylon and its discussion page.
• For information about how to indicate your language abilities on your user page ("Babel templates"), see User language.
• To discuss Wikimedia in general, please use the Wikimedia Forum.
• Consider whether your question or comment would be better addressed at one of the major Wikimedia "content projects" instead of here.

Wikimedia Meta-Wiki

• About Meta
• Discussion pages
• Request pages
• Policies and guidelines
• Information and statistics
• Categories
• Help pages

Participate:

• How to edit a page
• Meta-Wiki discussion page

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Change that breaks layout

See m:Tech#Change_that_breaks_layout.--GZWDer (talk) 02:10, 27 August 2020 (UTC)

Proposal to enable DiscussionTools on Meta-Wiki as an opt-in Beta Feature

Tracked in Phabricator:
Task T262984

Hello. I propose that we enable mw:Extension:DiscussionTools on Meta-Wiki and therefore benefit from the reply tool. Installation is subject to the WMF editing team approval but if we're happy with having this enabled here I guess we can get added to the list of wikis interested and get it enabled when they roll out the next batch of wikis. I suggest that DiscussionTools and its associated reply tool be activated as a Beta Feature (opt-in) for those users that want to test it/use it; so users not willing to remain unnafected. The last report at VisualEditor/Newsletter/2020/August appears to show good results and good reception. Note that the reply tool can be used both in Wikitext format and in Visual Editor format. If you want to test the feature before commenting, you can try to add this piece of code to your personal Skin .js subpage and try it out. Courtesy ping to @Whatamidoing (WMF). Best regards, —MarcoAurelio (talk) 21:14, 4 September 2020 (UTC)

•  Support as proposer. —MarcoAurelio (talk) 21:14, 4 September 2020 (UTC)
•  Support enabling it as a beta feature. Sgd. —Hasley 21:18, 4 September 2020 (UTC)
•  Support since it's a very useful and simple to use tool. Agreed it should initially be opt-in. Isabelle ^🔔 22:34, 4 September 2020 (UTC)
•  Support --Novak Watchmen (talk) 22:37, 4 September 2020 (UTC)
•  Support Ruslik (talk) 12:41, 5 September 2020 (UTC)
•  Support Sounds like a good idea: it can be helpful for cross-wiki discussions here and also for a more balanced development of the feature with feedback from a wider cross-section of the community. I understand that it's fully reversible, in that it uses standard wikitext and can be disabled at any moment without any damage to past discussions. (I have not yet checked the code, the development plans or the edits it makes though.) Nemo 12:59, 5 September 2020 (UTC)

  Hi @Nemo bis: I also understand, and support, that we have the last word here and that if for any reason we ain't satisfied with the result we can ask to have the feature undeployed. Indeed as of today the reply tool keeps using standard wikitext so existing talk pages, discussions, etc. ain't disrupted (this comment is being written with the reply tool fwiw) so undo, rollback, revision deletion, etc. works just as before. For now it's just a convenient UI change on the user's side. And in any case, once installed, or opted-in, you use it if you want to use it. The 'edit' links in the sections don't disapear or stop working. Code of the extension can be found at phab:diffusion/EDTO/. Regards. —MarcoAurelio (talk) 10:05, 6 September 2020 (UTC)

• Comment I would ask that if activated that its use on any talk-type be contingent on a consensus on any existing community page. Obviously that would not apply to users' talk pages.  — billinghurst sDrewth 22:08, 5 September 2020 (UTC)

  Hi @Billinghurst: the tool does not modify the working, aspect or configuration of any pages. It just adds a handy link (currently [ reply ]) to the user's UI after each comment that can be replied with the tool. It does not change anything on-wiki. This is not Flow or something like that. Adding it as a Beta Opt-In feature also guarantees that it won't be loaded for anyone but those willing to try the feature out. As Nemo mentioned above, it operates with standard wikitext, and does not harm existing talk pages as a result. I am replying to your comment using the tool, so you can see in the diff that it does nothing weird. Best regards. —MarcoAurelio (talk) 09:55, 6 September 2020 (UTC)

•  Support Yes, using it via js for some time and it works perfectly on user talk pages and other talk namespaces. It would be great if it also works on pages that are not in talk namespaces but used for discussion such as SRUC. ‐‐1997kB (talk) 03:11, 6 September 2020 (UTC)
•  Support I just tested it on ca.wikipedia, and it seems fine to enable (opt-in for now). PiRSquared17 (talk) 03:23, 6 September 2020 (UTC)
•  Support --Sakretsu (炸裂) 13:15, 6 September 2020 (UTC)
•  Support as opt-in. I've used it via the .js loader on w:en. It feels pretty solid once you're aware of its limitations and how it works. You can always cancel out and do a section-edit if needed.
  • You can also test by appending ?dtenable=1 to the URL which I'm doing now.
  • Reply box might not appear where expected if the thread has irregular indentation, but that's not the tool's fault.
  • You can't insert wikitables or other markup that needs to be outdented to the start of a line, or templates. mw:Extension:DiscussionTools/Reply tool visual mode limitations
  • Edit summary currently is set to "Reply" and is not shown nor editable. They are working on that for a future version iteration.
  • @1997kB: It shows [reply] links for me on SRUC but I don't know why. Outside talk namespaces it used to look for pages with Add Section, but they have probably refined the detection logic since I last checked.
  • Signature is appended at the end of the last line (listitem), unless you have embedded list like I've done here. If you want it separate then insert some punctuation after the newline.
  • @-mention name picker is only enabled in Visual mode, though an early prototype demo'd it in Source mode. I'm hoping that will be updated at some point.
  • Like 2017 NWE, it sends wikitext through Parsoid.
  • Right now as I type this, it doesn't appear to be auto-indenting and adding bullets in the way I was expecting. Not sure what's going on there. [Indented with : instead of *]

Hope that's not too much extra detail, --Pelagic (talk) 13:40, 6 September 2020 (UTC)

Weird, doesn't work for me on SRUC, SRGP, SRM. And just noticed that it also add -- in beginning of signature, which means if you have already added -- in settings it will duplicate. IMO it should only use raw signature as ~~~~. ‐‐1997kB (talk) 13:58, 6 September 2020 (UTC)

Just as a note, '--' prefix was added by Martin Urbanec at MediaWiki:Discussiontools-signature-prefix. Sgd. —Hasley 15:55, 6 September 2020 (UTC)

Oh, I'm sorry if that's an issue for anyone - feel free to delete the page. I thought the -- prefix should be added as per the custom, so I added it to the message. --Martin Urbanec (talk) 16:13, 6 September 2020 (UTC)

I think it would be best if it was optional, since not everyone likes adding those dashes. If not possible to make it optional, then better to erase that page. Isabelle ^🔔 16:28, 6 September 2020 (UTC)

Deleted. — xaosflux ^Talk 17:14, 6 September 2020 (UTC)

@1997kB: By default, the tool will only work on discussion, project & help namespaces, and pages using __NEWSECTIONLINK__. See the list of limitations. ESanders (WMF) (talk) 21:14, 7 September 2020 (UTC)

P.S. Using ?dtenable=1 will override these checks which is why it was working for @Pelagic. ESanders (WMF) (talk) 21:21, 7 September 2020 (UTC)

Oh, didn’t think of that, my bad. Thanks, ESanders (WMF). —Pelagic (talk) 17:30, 9 September 2020 (UTC)

•  Support for sure.--evrifaessa ❯❯❯ talk 18:33, 6 September 2020 (UTC)

•  Support. Yair rand (talk) 23:03, 6 September 2020 (UTC)

  Hm, it doesn't match indentation style to earlier comments. Eh, still... --Yair rand (talk) 23:04, 6 September 2020 (UTC)

  It actually used to do it, but we've gotten feedback from some wikis that it's wrong even if another person has already indented their comment with * (some of this is recorded in T252708), and no one has complained as strongly about always indenting with :. The discussion in which we're commenting right now is somewhat of a special case, since it's a poll rather than a "normal" discussion. Better handling for polls and votes is something we have in mind but haven't had time for yet (T259865). Matma Rex (talk) 22:20, 8 September 2020 (UTC)

  @Matma Rex: So my memory isn’t faulty! I think the old behaviour was more desirable. Pelagic (talk) 17:30, 9 September 2020 (UTC)

  Same, but it doesn't matter so long any more since the indenting became the same. Nemo 17:34, 9 September 2020 (UTC)

  Ideally, you would find the start and end of the previous sibling comment at the same indent level, and use the bullet or number style from the start. That way, if the previous comment wasn’t multi-paragraph, you’d be continuing the same HTML list. If there is no sibling, then user expectations will vary. . . . Actually, the truly ideal solution would be that we stop abusing list markup for discussions, but unfortunately that practice is heavily ingrained. Pelagic (talk) 17:56, 9 September 2020 (UTC)

•  Support for sure.Déjà vu • ✉ 01:24, 10 September 2020 (UTC)
•  Support, yes please. Rehman 05:50, 10 September 2020 (UTC)
•  Oppose until the content corruption problem is fixed.
  The design basically cloned Flow's backend wikitext corruption design problem. Rather than simply inserting the new comment into the page, the page content is translated through VE's engine Parsoid, then everything gets re-translated back before saving. This round-trip double translation is unnecessary, and it results in a complex unpredictable array of corruption to page content. Examples:
  A simple plaintext reply "Reply 2."[1] The diff should be a simple one-line insertion, but the Discussion Tool deleted a </span> from a previous comment. The Discussion Tool can corrupt pre-existing content on the page. This corruption causes the red font styling to spill to the end of the section, turning any and all further comments red.
  I copied-pasted a random table from an article to the talk page.[2] The table is corrupted during posting, but more seriously it demonstrates another case where trying to reply corrupts existing page content. I tried post a plaintext comment "A simple reply."[3] As you can see in that diff, the pre-existing comment got completely mangled and the new comment was posted as part of the previous comment at the beginning of the line.
  Here's another failed attempt to copy-paste a table.[4] However more significant is the widespread corruption to the page when I try to make a simple plaintext reply "Reply to reply 1".[5] Note that the diff not only shows the previous comment getting mangled, it shows several comments in multiple different sections of the page all getting mangled by the Discussion Tool.
  The fundamental problem is that they needlessly send everything on a round-trip double-translation through VE's Parsoid engine. Not only does the round trip double-translation cause a variety of corruption issues, the round trip translation process is so complex that there is no realistic way to even find all of the cases that will trigger corruption. The fix is simple - just insert the new comment into the page without sending everything through a round-trip double-translation. I raised the content corruption issue with the Dev team. They could fix it, but they don't want to. In fact when I said "It's like you didn't even bother testing it with anything other than basic text-comments",[6] the Code of Conduct Committee said that post was a conduct violation. I was banned from talking to the team.
  I'll ping the previous RFC respondents, to consider the posted evidence and possibly revise their !vote to say that this must be fixed prior to any deployment.

Alsee (talk) 08:32, 10 September 2020 (UTC)

Have you ever seen anyone type something like {{#if:x|<span style="color:red;|<span style="}} font-weight: bold">This should be red.}}</span> in a discussion on wiki? I've made more than more than 100,000 edits over the last 14 years, and I don't ever remember anyone typing {{#if: to format their comments on a talk page, even without trying to stick a span tag halfway in, and halfway out, of the conditional parser expression.

The Reply tool has been used on multiple wikis more than 20,000 times so far. Enterprisey's very popular reply-links script, which has been used thousands of times by about 500 editors at the English Wikipedia, is also using Parsoid. I think that if Parsoid was causing real problems with page corruption, rather than just someone repeating his favorite illustration of the mw:Parsing/Notes/Two Systems Problem as a demonstration case, we'd have seen them by now. Whatamidoing (WMF) (talk) 19:19, 10 September 2020 (UTC)

So, the code in that first example is horrifying.

Anyway. The issue with the tool choking on tables is quite significant, but I don't think it's a good enough reason to not enable it for opt-in testing as proposed. Certainly I don't think it should be enabled by default on any major project until it's fixed, but that's not what's being proposed. Yair rand (talk) 21:36, 10 September 2020 (UTC)

It doesn't seem to break on actually valid tables (example). It does choke on the broken table wikitext that Alsee used, but that seems like an adversarially-crafted pathological example rather than something that would naturally arise in a discussion. PiRSquared17 (talk) 05:47, 11 September 2020 (UTC)

PiRSquared17 there was nothing adversarial or pathological about the tables I grabbed. The diffs from your example show that you posted your example table using the wikitext editor.[7] Try posting your table with Discussion Tools. You'll find that it mangles your table.[8] That's bad, but that's incidental to the point I'm making. My real point is what happens when anyone tries to make the next reply.[9] You'll find that Discussion Tools spectacularly corrupts the existing page content, even if you try to post a plain one-word reply.
The point is that I have documented two completely-unrelated cases where Discussion Tools will corrupt existing page content. There is a systematic content corruption design flaw, there is a vast and unknown array of other cases where Discussion Tools replies will corrupt existing page content. They could fix the flaw and avoid all of the corruption issues, they just don't want to. Instead they want to keep the flaw and claim they will play whack-a-mole addressing specific cases of corruption. That's exactly what the Flow team advocated, and it doesn't work. Alsee (talk) 12:16, 11 September 2020 (UTC)

Ah, okay, you're right. It seems the problem occurs when you try to write a reply using a table, not when a table is already present. Maybe the Reply editor should give a warning if it detects table markup in the code you're trying to write. PiRSquared17 (talk) 12:26, 11 September 2020 (UTC)

@PiRSquared17 Currently it is not possible to indent a table in wikitext with or without this tool. This is part of the reason we implemented the live preview: so that users could see issues caused by invalid syntax in real time. We also have checks in place to warn about using the tool on pages which may have ended up with this invalid syntax on them. Longer term we hope to introduce new syntax that will make it possible to indent tables, and we are consulting with the Parsing team on an RfC for this. ESanders (WMF) (talk) 21:45, 14 September 2020 (UTC)

@ESanders (WMF): Eh?

Testing indented table

Seems to work? --Yair rand (talk) 22:23, 14 September 2020 (UTC)

Yeah, I tested this on the same example I used before, and it seemingly works fine: [10]. PiRSquared17 (talk) 23:19, 14 September 2020 (UTC)

Sorry, my explanation was overly simplified. The parser's handling of tables in lists is quite hacky, indeed it is commented as "Definition Lists: Hacky use to indent tables". It uses a regular expression to match colons preceding the table open, so there are cases where this would break, for example if you were replying to a bullet or numbered list (e.g. in a !vote context):

*:{|

|foo

|}

The hack is also part of the table parser, not the list parser, so it will also create a new list context in the middle of your comment for the table, which could cause confusing styling on places like French Wikipedia (have a look at the DOM generated by your example for what I mean).

There is also the problem of detecting this while in source mode. You would essentially need to re-implement parts of the wikitext parser to work out which lines to indent with a colon, and which ones to skip. Consider cases where the the table has content before and after it, or nested tables.

Again, we hope to fix this my enabling wikitext to support complex content inside list items more generically, which would remove all these limitations from the tool. ESanders (WMF) (talk) 16:01, 15 September 2020 (UTC)

Limiting it to opt-in testing is a credible option, so long as the team does get the message that it needs to be fixed before deployment as a default feature. Whatamidoing (WMF), there are three big problems with your argument. First, mw:Parsing/Notes/Two Systems Problem is completely irrelevant. The problem is the Parsoid round-trip-translation, eliminating our wikitext engine would do nothing to fix this. Second, I'm saying that there's a minefield of corruption issues. I documented that the minefield exists with multiple examples. Criticizing the location of a specific mine is hardly an argument in favor of putting minefield in our workplace. Third, you're defending the indefensible. Any first-year programming student can tell you that inserting string A (a new comment) into string B (the page) should never have any corruption issues at all. It's like translating an article into Japanese before applying each edit, then retranslating it back to English for saving. And doing that round trip retranslation for each and every edit. That's obviously an absurd. The obvious fix is to eliminate the unnecessary round-trip double-translation. If the dev's answer is "We don't wanna fix it", well, we don't imagine we're going to force them. But we do imagine we can reject a product unless&until it's fixed. Alsee (talk) 05:38, 11 September 2020 (UTC)

I have editted the title of this thread to make it clearer that my proposal was indeed to enable DT as an opt-in Beta Feature only. I am aware that the tool as it is now is not perfect, but it seems to work fine for regular conversation which I think it's what mainly happens here. I hope that the developers can get some more feedback, stats and examples of problems from the usage of the tool here at Meta-Wiki if the proposal passes, and sincerely hope that they work in addressing the issues. The team seems responsive and willing to engage with us in the development of the tool (I get frequent pings in mediawiki.org asking for our opinions on existing or proposed new features at mw:Talk:Talk pages project/replying). If however we signal issues or problems, and the team starts to ignore them, or the tool is abandoned, or for whatever reason after a time we decide this is not for us etc. then I won't hesistate in asking that the feature be disabled and removed as I've done before. Best regards. —MarcoAurelio (talk) 11:26, 11 September 2020 (UTC)

There is a realistic way to find cases that trigger page corruption, and it is phab:T261998, which adds a (hidden) tag to every edit that is detected as having corrupted the page. You're opposing deployment because of a bug that active effort is being expended on fixing, which seems a bit silly. (Removing the </span> tag is reported as phab:T262448, and I can't find a bug ID for the table corruption)* Pppery * _{it has begun} 21:07, 15 September 2020 (UTC)

•  Support —TheDJ (talk • contribs) 10:57, 11 September 2020 (UTC)
•  Support Useful. Camouflaged Mirage (talk) 18:49, 14 September 2020 (UTC)
•  Support * Pppery * _{it has begun} 21:07, 15 September 2020 (UTC)

---

There is a pretty clear consensus here. I have filed phabricator:T262984. --MF-W 21:53, 15 September 2020 (UTC)

Thanks for filing the Phabricator task, MF-Warburg. I'll make sure that it's on the team's list. I don't know when it will happen. They're still talking about who's next (after the Japanese and Vietnamese Wikipedias, which are tomorrow). If there's a particularly good or "normal" page for the team to test the tool on, then please add a link to that page to the Phab task.

As a reminder, the setting will be "opt in". That means that you will have to go to Special:Preferences#mw-prefsection-betafeatures after the team turns on the Beta Feature, and enable it if you want to use it. (If you have the auto-enable setting, then you'll have to wait until your preferences update on their own.) Whatamidoing (WMF) (talk) 17:44, 16 September 2020 (UTC)

Clarification of policy regarding removal of unblock requests (declined) by user when being blocked

I was reading through the RC where I see this. Basically the user removed all the unblock declined messages and then Cabayi reverted and then GZWDer reverted Cabayi reversion. This is basically a mess. I search through the meta policies, can't see any hard policy / guideline that prevents the removal, but then the block notice is very clear not to remove. How shall we proceed, remove the message on the block notice, or codify it per GZWDer suggestion on my talkpage? For me I am ambivalent per my rationale on the user talkpage of the user, " I actually don't care if users remove that or not (personally only) as we admins can still see in the history when dealing with unblocks (and we will carry out such due diligence)," but for this particular user I am more of the fact they shouldn't remove per my rationale "do not remove decline unblock notices while being blocked. It's written in red very clearly in the declined template" ... " but given that your issue is that you don't read documents and get blocked, this is disturbing". Shall we clarify here the approach. One other alternative is to use common sense which I am a strong proponent of (i.e. case by case basis). Hope we can have some clarifications here.Camouflaged Mirage (talk) 18:46, 14 September 2020 (UTC)

I'm not so prolific on meta that I could contradict GZWDer but I'd assume that a template like {{unblock declined}} that's baked into the unblock request process would accurately state the requirements. The text Do not remove this unblock review while you are blocked. has been unchanged (except for review/request and its capitalisation) since July 2013 so it doesn't seem controversial. There was some text about admins removing notices covering expired blocks, but the core principal, that blocked users should leave the notice in place, has been rock solid. Cabayi (talk) 20:02, 14 September 2020 (UTC)

(Sorry for) I did not notice such message while remove it, but in some largest wikis I am active (such as Wikidata and Chinese Wikipedia), it is allowed to remove declined block appeals. Also, Meta seems not to have a blocking policy yet.--GZWDer (talk) 20:09, 14 September 2020 (UTC)

Heads-up about MassMessaging for annual survey

This is a gentle note to mention that I'm posting some messages in a couple of wikis. I apologize if these messages are viewed are disruptive. The intent here is to request users attention about an e-mail they received earlier this month and which may have been marked automatically as spam. The annual survey is an important way for the communities to share their views and concerns with the Foundation. Based on community feedback from the previous years, we’re considering moving away from the three repeated pings historically used. The e-mails we've sent request the consent (opt-in) of contributors so that, moving forward, we can e-mail them instead of sending on-wiki messages. So the plan is to eliminate the annual disruption and rely only on opt-in email recipients. You may read more about the discussion surrounding this survey here.

Should you have any questions or suggestions, please leave me a note.

Many thanks for your understanding. Samuel (WMF) (talk) 17:15, 25 September 2020 (UTC)