In T203711#4604440, @Niharika wrote:

I think we can skip this bit. I'm hoping we can use the existing instance (https://tools.wmflabs.org/svgtranslate/) to host the new tool. I pinged @Jarry1250 on Phabricator earlier but didn't get a reply yet. I'll try reaching to him on wiki.
For now developing on staging instance should be fine.

In T204016#4600034, @Bawolff wrote:

Yep, that sounds fine. Would you like me to make this ticket public as well?

@Bawolff A concern was raised in the team that this is potentially quite heavier than a relatively quick security fix; it involves some potential back-and-forth on how to handle the behavior.

In T191757#4574416, @PerfektesChaos wrote:

Well, selection of a region is actually not recommended. Ideally it is cursor position only with no selection span. If there is a span, yes, it might become disambiguous. One existing template transclusion only shall be identified, best in name span, and the current values are supposed to prefill the form. Otherwise a new transclusion might be inserted.

If cursor is in parameter value span a new template might be inserted into that parameter value.

thanks, @Niharika , this is super useful.

In T202759#4591620, @MaxSem wrote:

I'm personally opposed to turning this feature into Ft. Knox: this ticket is about making account creation easier, lots of safeguards being discussed here go against this. Even basic time constraints would prevent most attempts to abuse this, making it everything-proof will make it too inconvenient to use.

We should also include all development peripherals to the environment:

In T202768#4583417, @aezell wrote:

I'm sorry I missed the discussion. I appreciate your capturing this info.

While I did mention SnapSVG, before we decide to go all-in on it, it likely bears some research to ensure it can do what we need. Has anyone taken an in-depth look at it?

In T203604#4582253, @TheDJ wrote:

So from an Accessibility point of view, the best html for this url is:

<ul>
<li>
  Required parameter $paramName" for the required ones? 
</li>
</ul>
<ul>
<li>
  <span aria-description="long explanation">Param name</span> <button>add/remove parameter paramname</button>
</li>
<ul>

I note that while the required elements 'look' like a button, they never behave like a button and there is no situation in which you allow them to behave like that. As such it can be questioned if they are buttons at all...

After the engineering discussion, it seems we have two main options, that depend on the focus of the feature set.

My personal opinion is that it's probably sufficient. If we consider screen readers to represent the state of whatever the user is focused on, then we need to make sure the name of the field is there, as well as its state. If we add the action-related text for fields you can add/remove and have a string saying the name of the field (with its state) for required field, that sounds like it would be a good descriptor.

Overall, the code looks good, but I have one concern that I think product/UX should consider (pinging @Niharika )

In T203699#4568696, @Samwilson wrote:

In T203699#4564956, @Mooeypoo wrote:

I don't think that this feature is a must, but ULS is easy to integrate and exists with Wikimedia standards on it.

We're already using Wikimedia standards for language names and fallbacks, so it seems to really be the UI that ULS could provide us. It certainly looks nice, and I agree that it's good to have the same language-chooser in multiple products.

@Niharika there was a question raised during review by @Samwilson that requires your input: We've changed the titles/tooltips of the +/- field buttons, as per spec, but we also have "required" buttons that have the checkmark, and cannot be added or removed.

In T203699#4566918, @Niharika wrote:

We should look into what benefits ULS provides here, given that the language labels are already translated.

In T203699#4564606, @aezell wrote:

Right now, languages are sorted alphabetically, and exist in English only

Whoops, it looks like we may have overlooked the focus when there are no fields. I opened this T203722: TemplateWizard: Only fallback to focus on 'add all' button if it actually exists to follow up.

In T202768#4547220, @Samwilson wrote:

As for no-JS, I don't have an opinion other than preferring not to switch to React or similar (because most of our projects are PHP with progressively-enhancing JS).

One news item we might want to pay attention to is that Chrome is planning to disable scripts for what it deems are "slow connections" (2G) which might make our "no-JS" experience more relevant. See the news item on Chrome status: https://www.chromestatus.com/feature/4775088607985664

Yes, and we should do this concurrently with T202768: Decide the tech stack for the SVG Translate tool so we can set things up correctly.

We should explore using the data part of ULS for this, or, alternatively, at least as a first step, use ULS itself.

In T202181#4559330, @MaxSem wrote:

@Mooeypoo: I don't understand what ResourceLoader has to do with this, please clarify.

I added the 'focus on load' to this ticket, since it was a quick fix. Requires review.

In T201340#4539425, @IKhitron wrote:

The bottom line: The global preferences show X and off. The local preferences show Y. I expect Y to work. Instead, X overrides Y in local preferences. And when I open local preferences, fix them and save, after some time they return back to the global values.

The use of keyboard actions (once we're already on any button) is solved through this ticket T203287: TemplateWizard buttons (-/+ fields and 'add/remove all') do not activate on "enter"

Where should the focus be when you just load the template? I'd think it should be consistent, and focus the first available field (or 'add all' if no field is visible) but right now it has no useful focus until you start adding fields.

We have not yet made a decision, but we started a conversation about possible options.

In T201340#4536678, @IKhitron wrote:

In T201340#4536659, @Niharika wrote:

@IKhitron Are you looking to stop using global preference for notifications? If you are using global preference, you should not be affected by this bug. Local exceptions should work as expected.

Day A: I opened Special:GlobalPrefs on my bot account. I changed one non-notification preference and saved. I opened Special:Preferences and saw it really works. I reopened Special:GlobalPrefs and removed the only change I did. I do not use the global preferences on that account any more.

In T202759#4530963, @Krenair wrote:

There is a process for requesting an exemption to the limit, but it [...] relies on volunteers to make the patch correctly and in time—which apparently doesn't always happen.

In my experience the main problem with this process is that event organisers neglect to give enough information (e.g., IP address) before the next eligible deployment window.

I played around a bit (language'd stuff always pique my interest) and just a couple of quick comments that I've noticed:

I ran an investigation to try and understand the impact of this, and what exactly happened. Here's the results (findings and recommendations at the end)

@Hagarshilo wonderful work.

In T200970#4489279, @aezell wrote:

In reading through some of the documentation, it appears that there are recommended ways to build dashboards on top of this data. I'd like to see us give that a shot if you think you'd find value in it. I think it beats having to re-run reports and queries.

In T194797#4483457, @MaxSem wrote:

What's an edit flag? The code's live so if we are satisfied by how it's working, there's nothing left here.

Let's try to see if there's a good way to test it once translations are in.

This was tested by running 'recheck' on this: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/GlobalPreferences/+/449375/
(extra job ran and passed)

@Samwilson I've merged and moved this to QA/Product -- I just realized, though, do you know of any template structure we could add to local wiki (or comm tech wiki if this is tested there) that can feature this field type, so it can be tested?

I went over the code, it looks okay to me; is there anything to actively QA or Product-chceck in this one?
@MusikAnimal It seems like it's mostly a prep-work for the actual feature -- should we close the ticket, or move to Product review?

@MaxSem this is already merged -- I see 'markasbot' and 'minoredit' in the options, but not edit tag (I may have missed it?)

@MaxSem Now that the patches are merged -- are we missing anything to review/merge, or are we done with the quick way?

In T190714#4481763, @Trizek-WMF wrote:

Thank you for those updates, @Mooeypoo. That's unfortunate while those filters are really expected, from the feedback I can read.

If that GoSC is not going to happen, that task should be declined, don't you think?

This task will not be done as part of GSoC after all; during development, it became clear that the development of a new asynchronous operation inside RCFilters is more complex than we'd realized, and would not fit in the scope of a GSoC summer project. Please see the update on the GSoC proposal task for more information.

Update on this project:

I am wondering if the OOUI method may still be better here. It might not give us 100% what we want, but since it's used in so many other places, I have a bit more confidence in its stability...

Wait, sorry, I just realized something.

Yeah, <bdi> won't help if we're talking about <input> fields, I just saw the screenshots and thought we're working with spans.