In T199534#4422963, @stjn wrote:

Can’t you just do a gadget please? I seriously don’t understand why all of this development is even needed.

We already have a tag for this ( Accessibility ). I would actually recommend this task get closed with new tasks opened for each of the bullets in the original, as appropriate.

In T50274#5012835, @gerritbot wrote:

Change 495451 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Edit summary autocomplete

https://gerrit.wikimedia.org/r/495451

Okay, I've triaged as lowest. No objection if you want to decline also.

Does that load the json each time you invoke the module on a page though?

If we wanted still to whitelist an entire domain on a particular Wikipedia (as opposed to the blacklist currently at Meta), that should still be at the MediaWiki version of the page.

As for completely failing, VE (and the apps which I think load VE/WTE17 these days) doesn't try to work with pathological behavior.

I'm sitting here feeling a bit puzzled about why we should support this (particular) use case with this as the (particular) fix. Imo it's a bit pathological to use nowiki to actually get content like this.

The aside is T32597: <section> tag name collides with HTML 5 <section> tag.

In T159837#4704715, @MMiller_WMF wrote:

This is a cool idea! The Growth team is attempting something similar in T206365, in which we will ask for email again after the user creates their account, if they don't initially include an email. If this feature exists, that would be redundant.

Seems like a good one for after T122924: Merge Extension:Theme into core.

Module:WikidataIB should already do this I think? @RexxS

I don't think that really fits in with the theme of Timeless though.

It is not visible in the default view for anyone any more in any skin unless you have enabled a script or gadget.

Is this T49145: Formally deprecate jQuery UI after we've stopped using jQuery UI in extensions and core (replacing it with OOUI).?

I realize this is a 4 year task... But Firefox works on my Android device (LG G5) with WTE17. It does still have the "unsupported" note in the edit notification pane.

Yeah, I'm probably just a bit grouchy today.

• Note these are restricted to #bodyContent (editor provided content) as these conflict
• with the Minerva skin. Remember .hlist is a class defined in core as well!
• See https://phabricator.wikimedia.org/T213239

In T144475#4897944, @Legoktm wrote:

FWIW, it's already possible to parse JSON in Lua by using https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#mw.text.jsonDecode

In T144475#4894427, @Anomie wrote:

In T144475#4894377, @Izno wrote:

@Anomie This strikes me in a similar sense to T200914: Allow creation of TemplateStyles in the Module namespace. What's your objection here that wasn't there? That the page is being moved as opposed to being created in the namespace?

In part, that is an issue of interoperation of two different extensions while this is proposing added behavior to Scribunto. And in particular that one came at it from the perspective of TemplateStyles rather than Scribunto.

In T144475#4894255, @jeblad wrote:

This is closed for a wrong reason, and blocks proper localization by using json files. It also blocks use of json-based configuration files, forcing such files into other non-related namespaces.

Anomie's objections above seem to be rather... uh... interesting.

This is a "it just works" feature to most people.

I'd guess this is T4700.

year and date are synonyms on en.wp.

The en.wp template is intelligent enough not to display it. The problem is that the hu.wp template is not up to date. See also discussion at T156548: Disallow adding Czech language tag (cs-CZ) into citation templates on cswiki and T115326: Many language wiki templates (pl, it, en, cs) don't accept xx-XX style language codes.

The English Wikipedia CS1/2 modules currently support by default what MediaWiki supports (mw.language.fetchLanguageNames). The module will trim to the first 2/3 letter code in language_parameter in the module proper. You can see this by experimenting with an English Wikipedia page that it does accept e.g. nl-NL with an output of "(in Dutch)". There are some overrides listed in lang_name_remap in the configuration file, but that's not directly relevant here.

In T210871#4814751, @Mvolz wrote:

Well- we ARE a robot. So probably technically the things that can be done would involve pretending we are not a robot...

In T182041#4813636, @Pkra wrote:

Div meets the intent of block math better. It might even be reasonable to mark it up as a paragraph in HTML 5.

While display equations may be block content that is not always the case.

That's true. But if you mark up your <math> wikitext with <math display=block>, you as the author of a wikitext document are *way* obviously meaning for the math to display as a block. Are you familiar with that functionality? That's what this task is about. Arguing without that context or seemingly without that context seems to miss the point of the task.

Div meets the intent of block math better. It might even be reasonable to mark it up as a paragraph in HTML 5.

It started happening with me right around Firefox 60 also, though I'm on 63.0.3 now and still affected. No issue before then. I mostly experience it with WTE17. It seems to impact the Linter extension also by not loading the linted wikitext, which does not load WTE17 but instead WikiEditor 2010.

In T92432#4772701, @Whatamidoing-WMF wrote:

This has been proposed as part of the 2019 Community Wishlist: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Citations/VisualEditor:_Allow_references_to_be_named It's too early to know whether it will make the top 10 (voting will be open until the 30 November 2018), but it's currently among the more popular items, which suggests that solving this problem has widespread community support.

On an aside, I don't find the original report compelling for allowing this behavior. That's its own issue (T3584: Need method for multiparagraph list items, continuing numbered lists, and assigning specific numbers to list items especially the first item in the title) and should probably have its own fix. (Which, I may have falsely closed one or another in that duplicate chain....)

I'm going to copy the description from my T202083: First-class wikitext support for ordered list item value:

W3schools points out that progress bars should use <progress>, not <meter>. A better use of <meter> would be for Template:Rating.

I know @TheDJ has poked around here. I'm pretty sure I've seen a task for this elsewhere (not just for Timeless).

In T210822#4798570, @PerfektesChaos wrote:

• The current purpose is to indicate that here is a link which is not coloured in blue as every other link does.
• There are people editing since 2005 with 100.000 edits who never noticed that some five or eight years ago a link feature has been introduced. They learnt it two weeks ago when it all became blue and a debate started whether it shall remain blue or grey again as within the years ago.
• The arrow has been blue the last years, but nobody discovered the colour of that little arrow.
• If you are new in Wiki world you have no idea that somebody is hiding a clickable link, something greyed out just before the user summary. That is signalling inactivity, used for deactivated things.
• The arrow is the only thing which might give you a clue to hover at this part of the interface.

In T211044#4798766, @Isarra wrote:

Okay! So we really just want the behaviour consistent with other skins - not necessarily bold, that doesn't matter one way or the other, but sizing/spacing.

; is for definition lists, it's supposed to act as the header for : items. We need consistent headeriness. https://meta.wikimedia.org/wiki/Help:Wikitext_examples?useskin=timeless#Organizing_your_writing should match https://meta.wikimedia.org/wiki/Help:Wikitext_examples?useskin=vector#Organizing_your_writing in terms of effect.

May also be worth looking into header styles in wikitables and fieldsets and such, too, as all of these should ideally behave the same.

1. What is the purpose of the arrow? Is it discoverability alone?
   1. Is that necessary? I don't think so. I don't think the arrow here does any good to serve discoverability, and conflates the discussion ongoing in T125657 anyway.
2. Is it only to demarcate "in <section of interest>: <summary>"?
   1. Is that necessary? I doubt so--clearly there are people who missed the usefulness of the arrow, which inspired the change that set off all this discussion.
3. Is it both?

In T210822#4791734, @AfroThundr3007730 wrote:

In T210822#4789323, @Dvorapa wrote:

It could also help to restructure the order of items. Currently we have (watchlist):

 diff    _ hist .. tag    _ page _ time   .. size   .. author _ talk   _ contribs _ ->section _ summary
(change _ page .. change _ page _ change .. change .. change _ author _ author   _ page      _ change )

I would restructure it like this:

 page _ section _ hist .. tag    _ summary _ size   _ time   _ diff    .. author _ talk   _ contribs
(page _ page    _ page .. change _ change  _ change _ change _ change .. change _ author _ author  )

In T210822#4789383, @Nirmos wrote:

If the diff link is not the first item in the list, or in different places depending on whether a section was edited or not, that would be the end of counter-vandalism.

I agree with Nirmos. This would indeed have a significant impact on those who have to regularly scan through those history pages to reconstruct an editor's actions.

The diff, date, time, etc. are the same length and line up consistently in the article history and contributions, and should stay at the beginning of the line. If they were re-ordered with variable-length data like page and section name first, the layout would become significantly more chaotic, and less easily parsed by the reader. The variable-length data should always appear at the end of the line to maximize legibility.

In T165189#4796030, @gerritbot wrote:

Change 477428 merged by jenkins-bot:
[mediawiki/core@wmf/1.33.0-wmf.6] Restore gray coloring for autocomments

https://gerrit.wikimedia.org/r/477428

Since the other task is making everything the same gray again, reopen this one.

I actually really like the serif font in these rather than the bold, though it does take some getting used to.

In T148701#4417283, @Izno wrote:

Is this still a problem with RemexHtml ?