@Prtksxna Flagging this for your attention. You can expand on the design and interactions in the ticket description. Let me know if there's anything more I should add from the product perspective. Thanks.

@Mooeypoo Flagging this for you too. Before we work on this ticket we need to decide if we use ULS or ULS-backend-only like in VE. Also perhaps it will be good to include the ULS integration work in T203711: Prep work for SVG Translate tool.

In my discussions about ULS, I've considered that we should include it in the Symfony bundle we are creating.

Given that this project will use that bundle, it would be available.

Am I creating too many dependencies between all this work with that approach?

In T204849#4599358, @aezell wrote:

In my discussions about ULS, I've considered that we should include it in the Symfony bundle we are creating.

Given that this project will use that bundle, it would be available.

Am I creating too many dependencies between all this work with that approach?

That sounds fine to me. Can you/Moriel create a ticket about ULS integration in the bundle and make sure we can estimate it next Tuesday? It wasn't included in T204631: Create Symfony "ToolforgeBundle" with OAuth, i18n, OOUI, Addwiki, etc..

I don't mind the dependencies. I think this is a good way to approach the Symfony bundle work - grow it organically while working on a project (i.e. include features as and when they come up) instead of doing everything at once. In fact I think the work outlined in T204293: Investigation: Create a development environment for Event Metrics could also be approached the same way.

@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)?

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)?

You can definitely open ULS on top of an OOUI dialog, but it's not ideal; it doesn't quite look the best, but last I checked, it works; we might need to play around with some z-index of the overlays, or order of the DOM so the ULS popup appears above the dialog, but it's doable.

We can do that as a first step, and later consider taking a page from VE's book and use parts of their language dialog that uses the OOUI interface with ULS' data only.

We can do that as a first step, and later consider taking a page from VE's book and use parts of their language dialog that uses the OOUI interface with ULS' data only.

Sounds good.

As ULS is JS-only, I don't think it makes sense to add it to the bundle (everthing there is primarily PHP). I think we'd just install ULS with npm, and package it as normal (with webpack). That all looks pretty straight forward, except that https://www.npmjs.com/package/jquery.uls isn't actually registered. Is that something that could be rectified? Or should we just copy the required files in (in which case, putting them into the bundle probably does make sense).

(I've raised the registration issue here: https://github.com/wikimedia/jquery.uls/issues/325 .)

Interesting point. I like the idea of keeping it as simple as possible and letting the right tool be used for the right libraries.

It's something we could note in the documentation pretty clearly.

The first part of this is ready for review: https://github.com/wikimedia/svgtranslate/pull/22

It adds ULS and jquery.i18n, with a simple link in the user-menu that opens ULS. The link will open the full settings dialog in a second patch (PR19). I wanted to get people's opinions on PR22 first though:

• Does it make sense to copy all the i18n files into public/assets/i18n/?
• Do we want to look at a way to merge i18n files? This will be more complicated than the current simple setup, and I think getting on with the rest of SVG Translate is more important at the moment.
• This patch ignores the jquery.i18n that's in the bundle, because the way that's set up we can't easily add extra directories of messages (i.e. from ULS). I don't think it should be in the bundle any more really; it's a front-end thing, and Symfony bundles (I'm learning) seem pretty poor at playing well with Webpack and frontend in general.

I've added most of the rest of this ticket to that PR as well now.

The last niggling bit is that the ULS dialog doesn't open on the first focus of the tag widget. Once you click into it, and then click again in the same place, it opens—and then, when you click away and back to it, it opens fine. Blasted thing.

Anyway, I've still got to go through the patch again and make it all as beautiful as possible, but it's fully functioning now.

PR19 is ready for review. I've not solved the open-on-focus problem, because I think its solution requires a bit of discussion, and this patch is already big.

I've made further comments on the PR in Github.

@Samwilson I looked at this briefly on the site and found another bug - if you open the dialog and click on the input to open ULS and then hit Cancel to close the dialog, the dialog goes away but ULS stays. It should close too. There's also a weird scroll but that's less prominent.

Good point @Niharika, will fix. The weird scroll thing seems to be by design within ULS; it has a 'scroll into view' thing (are you seeing it when the ULS dialog would otherwise be off-screen?).

@Prtksxna Are you happy with the addition of a button next to the preferred-languages multiselect? Rather than opening ULS when the focus is on the multiselect.

It'd look like this (I'm not sure what the button should say):

The button can start to look funny maybe, when we add lots of languages there:

The dialog also gets a scroll bar when that happens. Should we have it grow in height instead? Or start out bigger maybe?

Will some of these problems go away now that we are planning to T209900: Switch to using ULS as a backend for languages instead of using the ULS dialog?

In T204849#4761130, @Samwilson wrote:

The dialog also gets a scroll bar when that happens. Should we have it grow in height instead? Or start out bigger maybe?

Having a wider dialog might be better. If we can fit three languages (on an average) in a line we should have no scroll for up to 6 languages. I am guessing anything above that would be more rare and is fine to have a scroll for.

This is all merged now (including the larger dialog window), and is live on the test site https://tools.wmflabs.org/svgtranslate-test/