Page MenuHomePhabricator

SVG Translate tool: Language settings dialog
Closed, ResolvedPublic5 Story Points

Description

Value proposition (why do we need to do this)?

  • As a user, I want to be able to set the language I see the tool in so I can use it more efficiently.
  • As a user, I want to be able to set language(s) I prefer so the tool can show those near the top of the language list when selecting languages for translating and I don't have to scroll through the language list every time.

I combined these two user stories here because the functionality is very similar.

Functionality/software changes

  • Option to change the tool interface language
    • This uses ULS for selecting language.
    • The language user picks persists across sessions.
  • Option to set preferred languages
    • This uses ULS for selecting languages.
    • The languages user picks persist across sessions.
  • Save these selections in a cookie

User interface changes

Screenshots/mockups:

Interface text/changes:

See mockup for interactions.

Does this need QA?

Yes

Event Timeline

Niharika created this task.Sep 19 2018, 5:16 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 19 2018, 5:16 PM
Niharika triaged this task as Medium priority.Sep 19 2018, 5:23 PM
Niharika added a project: SVG Translate Tool.
Niharika assigned this task to Prtksxna.Sep 19 2018, 6:42 PM
Niharika moved this task from Untriaged to CL, QA, Data analysis backlog on the Community-Tech board.

@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.

aezell added a subscriber: aezell.Sep 19 2018, 7:49 PM

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

Niharika removed Prtksxna as the assignee of this task.Oct 9 2018, 1:43 AM
Niharika added a subscriber: Prtksxna.

@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.

Niharika updated the task description. (Show Details)Oct 9 2018, 5:18 PM
aezell updated the task description. (Show Details)Oct 9 2018, 11:32 PM
Niharika set the point value for this task to 5.Oct 9 2018, 11:34 PM
Niharika moved this task from To be estimated/discussed to Estimated on the Community-Tech board.
Samwilson added a subscriber: Samwilson.

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

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.

Samwilson moved this task from Ready to In Development on the Community-Tech-Sprint board.

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?

MaxSem moved this task from QA to Needs Review/Feedback on the Community-Tech-Sprint board.

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?

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/

Niharika closed this task as Resolved.Nov 28 2018, 9:39 PM
Niharika moved this task from QA to Q2 2018-19 on the Community-Tech-Sprint board.

@Samwilson This looks pretty good to me!