Page MenuHomePhabricator

CX-VE integration framework should have a way to use tools container for tools
Closed, ResolvedPublic


By default, the VE inspectors appear just above the editing context and does not match with CX design.

This ticket is to explore possible ways we can achieve this and develop it as part of integration framework.

(Some customization of the inspectors were done in but it is just a start)

Event Timeline

Pginer-WMF moved this task from Backlog to Priority backlog on the Language-2018-Jan-Mar board.

Change 413702 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ContentTranslation@master] Add editing toolbar to the tools column

Why is this in the priority backlog and not in in-review?

Change 413702 merged by Nikerabbit:
[mediawiki/extensions/ContentTranslation@master] Add editing toolbar to the tools column

Proof of concept code
The proposed approach(to be validated by VE team as well)

  • Define ve.ui.CXDesktopContext and set that as context to the target translation surface
  • ve.ui.CXDesktopContext will attach to the tools column. The inspectors from VE will be reused but with customization

We need a surface with a custom context. The current surface is ve.ui.surface and it creates a desktop or mobile context as follows

ve.ui.Surface.prototype.createContext = function () {
    return OO.ui.isMobile() ? new ve.ui.MobileContext( this ) : new ve.ui.DesktopContext( this );

If there is a way to set a custom context to this surface instance, we don't need to subclass ve.ui.surface. Currently no way to customize. Creating context require surface as argument. so it cannot be an option. But a setter. The issue here is the constructor starts to stuff with context before this setter is called. Need some refactoring fixes in ve.ui.Surface


  • How to support multiple context inspectors for same item? for example, a text selection can have dictionary and a link in CX

Screenshot from proof of concept:

image.png (714×1 px, 280 KB)

Hi, @Esanders , What do you think about the approach outlined above? Any suggestions for improvement or alternate methods?

cc @dchan

Change 419402 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ContentTranslation@master] Proof of concept: Place the inspectors in tools column

The point of contextual information is to keep it close to the relevant content. Moving the contexts further from the text doesn't solve any existing technical or usability problems, it is arguably going to be more confusing for the abundance of users who are familiar with VE, and creates potential issues with existing or future context items that weren't designed to fit in a narrower container.

I can see the argument for paragraph-level contextual information (e.g. the translation source selector), but for inline information you are just creating unnecessary problems for yourself.

The point of contextual information is to keep it close to the relevant content.

Translators need to focus on content while also being able to quickly check the context when translating. Having a separate column for context provides a richer context without causing distractions. For example, when selecting a word, a link card previews existing articles for the user to add a link in one click, and a dictionary card shows the definition for the selected word. When users are interested in such context, they can find it. When they are not, it is not getting in their way.

We have been using the tools column to provide contextual information in CX for a while, and issues with this pattern have not surfaced during user research or user feedback. In recent research, we have observed how translators use the tools column. Not only there was no confusion, but users praised the way it helps them (“I use this one a lot. [To check] the naming conventions and the context is correct.”, “This is very smart, the way it works with links [...] It points to the right one.” were some of the comments).

This is a topic that we have already discussed in the past, and reached a conclusion that we want to implement for the first iteration of CX2. We are open to revisit any interaction pattern of the tool in the future, and include the necessary checks on future user research. But in order to avoid major regressions for our users, we do not want to disrupt the patterns that have been working well for translators so far.

For the moment we would really like to check about the original question Santhosh posted in the earlier comment (T188072#4049486) to proceed with the prototype patch.

Regarding the size limitations of some inspectors, making sure these work on smaller spaces seems a good idea for mobile support in any case, but we can discuss the specifics as we find those cases.

Ping @Esanders , @dchan
This is one of the features we would look to have soon so that CX-VE integration is unblocked.

Making signifcant changes to the editing experience adds an extra burden on developers to maintain that interface, and on users to learn a new interface, so the bar for doing so must be placed high.


The development burden going forward will most likely fall on VE developers, but also other extension developers who have implemented VE support through our plugin architecture. As we manage an ever growing ecosystem of integrations, we must be responsible for minimising that.

It should also be noted that there are no know technical issues with the current VE inspector in the CX integration, so to make no changes would require no addition development time, or ongoing maintenance.


ContentTranslation is still in Beta, and when it comes out of beta we should hope for the user base to grow by orders of magnitude.

In this scenario, CX users will mostly likely already be experienced VE users, or go on to become VE users when they modify their newly published article, and so I think it makes more sense to prioritize not changing the user experience for this majority of users.


Translators need to focus on content while also being able to quickly check the context when translating. Having a separate column for context provides a richer context without causing distractions.

Conversely, the inline link inspector has been through several rounds of user research, and been used in millions of edit without any complaints of it being a distraction. It is also very similar to link inspectors used in much more widely used software such Google Docs, meaning it would've been user tested in those, and also will be familiar to anyone who has used those products.

Deskana moved this task from Incoming to Code review on the VisualEditor (Current work) board.

I'll put it in our review column, and mention it in the standup today.

As per the discussion with @Esanders the above approach is acceptable for VE and we will proceed with it.

Patch updated. Some screenshots:

image.png (447×949 px, 85 KB)
image.png (299×953 px, 64 KB)
image.png (364×429 px, 25 KB)
image.png (336×435 px, 24 KB)

Change 419402 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Tools UI customization: Place the VE inspectors in tools column

Pginer-WMF moved this task from QA to Done on the Language-2018-Apr-June board.