Yes, this is done. We're continuously adding some methods to the API, but we should create new tickets as they come.

For reference, PR is here: https://github.com/wikimedia/svgtranslate/pull/20

This is a future enhancement for sure, not really something we should deal with for the MVP.

In T203559#4723569, @Samwilson wrote:

It seems to work fine sharing the popup overlay that we're already injecting for the calendar etc. @Mooeypoo did you say there was a problem with doing that? The two sorts of popups can never be open at the same time, so I don't think things will overlap or anything.

@Samwilson I tried to merge the patch (looks good) but it fails:

In T205561#4692418, @jmatazzoni wrote:

@MusikAnimal @Mooeypoo, I need answers re. Participants and New Editors. Specifically, can we calculate these if there is not Participant list supplied?

I'm totally fine with not calculating Retention figures if you don't supply a Participant list. But I know that projects like Wiki Loves Monuments—which is not going to have a Participants list—would love to be able to say that ten-thousand people contributed (based on a category, I imagine).

Now, if we can't say how many of those Monument lovers are New Editors, that would be OK, since I don't think content drives like that are really designed with membership as a goal...

I guess the product review should be done when we add the feature into the CSV or display. Closing as resolved.

In T208636#4725861, @jmatazzoni wrote:

In the Steering meeting yesterday, Moriel made a decision to go with CSV. But we should keep an eye on this; if it becomes clear that it's a big job we can reverse course.

There's an idea to split the way we serve the data to users for better support, but we should look into this further. The personal account data should be straight forward and will probably not require any storage solution or any heavy database access, but the contribution data can be very heavy both on Database queries and the resulting file (be it a CSV or XML or JSON or whatever other format we choose to use).

Sweet! This fixes the specific bug.

A couple of problems:

@Anomie, your input will be super helpful; I suspect (according to the code) that switching to MenuTagMultiselectWidget (or any other *TagMultiselectWidget) may not be as trivial, since the popup contains mutiple *types* of fields that can be added.

This was raised again, this time with partial blocks. My newly proposed design is simpler than the other and, hopefully, will pass the scrutiny of UX so we can have a fix for this: If there's text left over in the widget, it becomes invalid, and the text is emphasized.

FYI, see this task with a discussion of what is the best UX; it's not completely straight forward what the best solution is for the widget: T188886: TagMultiSelectWidget misleadingly leaves uncommitted input text visible when unfocused

This is great. Thanks!

It should be ready for estimation.

Proposed API modules:

It seems to work when adding safemode=1. There seems to be a problem with a gadget (default one probably) that interferes with the parsing into the dialog. @eranroz can you help? I'm having trouble figuring out which one.

@Samwilson any progress on this? Is this stuck somewhere? Are we collecting data?

Update: When using Firefox, the network tab DOES show a response, but the dialog still shows the entire template as if TemplateData doesnt' exist.

My suspicion is that this will take a bit of creative cheating as well as a storage method (cookie or local Storage), so I'd say let's split that part up to another ticket. This one can deal only with implementing uls and having it apply the chosen language.

The reloading of the SVG will be round tripping from the server. It should be quick, but we will be asking the server for the new svg output each time with Ajax, so there might be a need for a loading animation of the fetching takes a noticeable amount of time.

I agree with @aezell's analysis.

In T203711#4668393, @aezell wrote:

@Mooeypoo Didn't you just set this up? Can you confirm that the last checkbox in the requirements for this task is complete?

Let me try and provide some clarity from the technical perspective of the team, and see if that makes more sense:

Gotcha, thanks!

I have a question regarding the filtering for the report. Right now, you get the option of "Filter by"

In T204849#4604531, @Prtksxna wrote:

@Mooeypoo I was wondering if opening ULS on top of an OOUI dialog is going to be a problem. Also, how hard would it be for us to have the VE language selector (the one that @Niharika linked in the description)?

When I use a color picker on the screen, it gives me #4775d1 for the LTR, and ##3366cc for the RTL one, so it seems to not just be an artifact of our eyes. It might be some weird way these two render, specifically, on Phab?

In T205172#4617027, @MusikAnimal wrote:

This is new to me! I need to do the same thing for all my other tools. On Pageviews, specifically, we put a lang="en" and dir="ltr" attributes where the page titles are, since we know the source language. That seemed to do the trick but it requires a little more logic. If <bdi> works forever and always that seems most preferable!

In T205991#4643303, @matmarex wrote:

(Please @mention me if you need my input. Looks like the main issue is fixed and everything @Mooeypoo and @Niharika wrote above is correct, so I assume I have nothing else to do here.)

In T205363#4634179, @MusikAnimal wrote:

Agreed that this will slow things down noticeably. But if we do get to it, I find parsing HTML content to be more exacting in getting word counts of prose, as then it is easier to exclude things like infoboxes and references. We do the same thing in XTools, available via the page/prose API endpoint. The MediaWiki text extracts API does something similar but we do not need content, just numbers.

Sorry, my computer almost died so the above was a bit of a quick hit-and-run comment. Let me be more clear:

The infusion fails on '.mw-input-wpcirrussearch-pref-completion-profile-global' -- it cannot find an associated widget, because the search completion has a group of widgets, not just one, so the infusion fails.

• Format: The report will be downloadable as a CSV file. Do we need to let users pick a delimiter? What does Grant Metrics do now?

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.