Page MenuHomePhabricator

Indicate which source languages have Machine Translation enabled
Open, MediumPublic

Description

When chosing to start a new translation the user should be informed which 'source' languages have Machine Translation available. This could be a list in the right-hand column of the dashboard, or indicated within the "new translation" popup box.

The user should know BEFORE they start translating whether they will be supported by MT or not.

Event Timeline

Wittylama created this task.Jul 9 2015, 1:42 PM
Wittylama assigned this task to Amire80.
Wittylama raised the priority of this task from to Needs Triage.
Wittylama updated the task description. (Show Details)
Wittylama added a project: ContentTranslation.
Wittylama added a subscriber: Wittylama.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 9 2015, 1:42 PM
Amire80 triaged this task as Medium priority.Jul 9 2015, 4:22 PM
Amire80 set Security to None.
Amire80 moved this task from Needs Triage to CX6 on the ContentTranslation board.
Pginer-WMF moved this task from CX6 to CX7 on the ContentTranslation board.Jul 21 2015, 5:31 PM

I don't think this is good feature to have. It would bring clutter to UI. @Pginer-WMF, do we decline this?

Amire80 removed Amire80 as the assignee of this task.Mar 3 2018, 1:46 AM
Amire80 added a subscriber: Amire80.

Not sure. It's a very frequently asked question. It would be great to let people understand in the interface that MT for their language is not available, so they wouldn't have to ask about it at Talk:CX and email repeatedly.

Not sure. It's a very frequently asked question. It would be great to let people understand in the interface that MT for their language is not available, so they wouldn't have to ask about it at Talk:CX and email repeatedly.

Ok, but do we communicate availability of MT before starting the translation (like this ticket requests) or when the translation is started, on translation view, for which I saw some tickets as well?

Jorm added a subscriber: Jorm.Mar 3 2018, 2:53 AM

Okay so I'm gonna comment here and I expect Pau will back me up on this but:

First: NOT doing a thing because it might "clutter the UI" is just bonehead. That's bad design. It's lazy design.

Second: Your comment is infuriating to me, and you can believe me that I know exactly where you're coming from but: You can't dismiss people like that. You simply can't. "Do we decline this?" JFC.

I'm currently going through the ContentTranslation board, cleaning some tickets which are no longer relevant by resolving them. There are lots of open tasks and some look like overengineering to me, like this ticket. Many of them 2+ years old and are unlikely to be done. To some, I proposed decline, or declined myself.

Saying yes or no (by declining) to this feature would be improvement to no action for more than 2.5 years. Final decision should be made by PM, but this clearly wasn't a high priority ticket, hence no action so far.

"not high priority" and "should be dismissed out of hand" are two completely different things.

This is request clearly states an actual issue, makes it clear why it's an issue, and suggests a possible resolution. This is exactly the sort of ticket that should get an acknowledgement pretty soon after being filed, and not too long after that a comment about it's priority and any issues that it brings up. What it absolutely shouldn't get is a contemptuous dismissal two years after being filed as the first comment, let alone a contemptuous dismissal with a completely backwards reason for dismissal (UI design should follow required functionality, functionality should never be dictated by UI design) .

See T62513 for an example of a very low priority task handled correctly.

I don't think this is good feature to have. It would bring clutter to UI. @Pginer-WMF, do we decline this?

I think the ticket responds to a real need that we have observed from users. Having machine translation available is something users expect, and them finding out without further explanation generates confusion (i.e. users wondering if the tool is broken). So I agree we need to improve the way we communicate this to the users. Even if the final solution is not among those described in the ticket, keeping the ticket to capture the problem and discuss/refine the solutions seems the best way to go.

Regarding the specific solutions proposed, I think we need to consider some factors:

  • Some users may not have a clear idea of what "machine translation" means or how that is a piece integrated in Content Translation. Communicating earlier (which is good to anticipate issues) may be also communicating out of context in this case, which makes it less effective. We need to check that by marking some languages as lacking MT, users don't assume the whole tool is not available for those languages.
  • Machine translation is available based on specific languages (or even specific language pairs, depending on the MT service). Since the ticket was created, machine translation support has been added to many languages. So having a separate list for users to scan won't be very convenient because of its length. We also need to be careful not to convey that the MT availability depends on the specific article, since it is dependent on the language pair.
  • The availability of machine translation has only partial influence on the languages translators choose. It may encourage a user to pick a specific pair they know it it is better supported, but the user is unlikely to translate between two languages they don't speak even if they have machine translation support.

Exploring some options during our upcoming rounds of user research will help us to understand which ways to communicate this are more effective and verify that they don't prevent users to complete their tasks.

Okay so I'm gonna comment here and I expect Pau will back me up on this but:
First: NOT doing a thing because it might "clutter the UI" is just bonehead. That's bad design. It's lazy design.

The important thing is how well we support the user needs. If we can support them perfectly well with a solution that has less elements it is better than doing it with a more complex solution. But the number of elements should not be our measure of success, how well we support the user needs should be instead.

the way I'd like to interpret the "bring clutter to UI" comment is more along the lines on whether supporting better a secondary usecase (such as anticipating whether MT will be available) may have a negative impact on the main one of being able to start and complete a translation. That is something that is also worth considering when looking for solutions to the issue.

Second: Your comment is infuriating to me, and you can believe me that I know exactly where you're coming from but: You can't dismiss people like that. You simply can't. "Do we decline this?" JFC.

Petar provided a quick comment as part of his review of a long backlog of old tickets (many of those related to parts of the UI that have evolved and some no longer exists). He didn't provide an elaborate design rationale, but pinged a designer to discuss the issue further. We all can improve in the way we deal with the incoming influx of tickets and the way we provide feedback to each other, but I think it's important for our discussions to be aimed at helping each other to communicate more and better; and emphasising what not to do over what to do may be counterproductive (i.e., incentivizing to participate less instead of more+better ).

Arrbee moved this task from Bugs to Enhancements on the ContentTranslation board.Jun 22 2018, 1:41 PM
Arrbee moved this task from Bugs to Enhancements on the ContentTranslation board.