Page MenuHomePhabricator

Provide easy access to advanced publishing settings from the Content Translation columns interface
Open, MediumPublic

Description

Although publishing directly to namespace has shown to work well as the default (T76618), we want to provide more detailed alternatives that respond to the different user needs when publishing.

This ticket proposes to include a settings menu next to the publish button (e.g., a cog icon) that provides the following options:

  • Publish in user namespace/main namespace. This will adjust the article title accordingly for the article to be published in the right place.
  • Include a translation template. For those communities where translations are required to be marked with a template, this can avoid some additional steps editing the published article.
  • Mark as work in progress when published. For those articles that need some fixing that cannot be done in Content Translation, we may want to allow users to signal that the editor is still working on them. Some communities may have templates we can use for that purpose on the published article.
  • Custom edit summary. Allows to customise the edit summary to be used when publishing. This would allow editors to indicate their contribution is part of an editathon/campaign by using a hashtag. The user contributed text may appear after the default one if the default is needed for attribution (i.e., point to the original article translated).

Proposed solution

A settings menu next to the publish button would help with the discovery of the settings. This shows a dialog with three sections (individual tickets will describe them in more detail):

  • Publish destinations (T197701). Changing the selection in the menu will update the article title. Changing the article title will keep the setting selection consistent. The option to publish in the Draft namespace, will be available only for those wikis where the draft namespace is available.
    • Publish destinations will have descriptions.
    • Publish destinations will include the draft namespace when it is available in a wiki.
  • Summary (T193727). The content provided should not replace the automatic publish message but be added after it.
  • More options (T197696). This should be customisable by each community, each checkbox results in the addition of a specific template that is useful to mark some relevant information regarding the translation.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Amire80 renamed this task from Provide easy access to advanced publishing settings to Provide easy access to advanced publishing settings from the Content Translation columns interface.May 1 2016, 1:43 PM
Amire80 moved this task from Needs Triage to Bugs on the ContentTranslation board.
Amire80 triaged this task as Medium priority.May 19 2016, 5:46 PM

This discussion illustrates some of the issue mentioned in the ticket: user not being aware that the article can be published under the user namespace by changing the title, and uncertainty on how to edit it to achieve that.

This discussion illustrates another scenario where the options described in this ticket could help the user to do post-publish actions before making the article available to everyone.

Pginer-WMF updated the task description. (Show Details)Oct 24 2016, 10:42 AM

Being able to add edit hashtags is a related usecase also mentioned here. I added the example in the description.

Pginer-WMF updated the task description. (Show Details)Mar 27 2017, 10:40 AM

During the template translation research (T161188) a participant described the urgency of fixing pending aspects of the article quickly before it gets deleted. In addition to the option to publish as a draft, the possibility of flagging that the user is still working on the content, could be of help too, which I added in the description.

Pginer-WMF updated the task description. (Show Details)May 12 2017, 8:51 AM

I created a mockup to illustrate my initial thinking about this. Check the updated ticket description.

Change 353527 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ContentTranslation@master] WIP: Add publishing destination options

https://gerrit.wikimedia.org/r/353527

First iteration:

Arrbee moved this task from Bugs to Oct-Dec 2017 on the ContentTranslation board.Oct 27 2017, 8:26 AM
santhosh removed santhosh as the assignee of this task.Apr 11 2018, 11:52 AM
Pginer-WMF added a comment.EditedMay 3 2018, 10:19 AM

Based on @Volker_E comments on T193255, I illustrated how the settings would work when presented as part of a flyout and a dialog:

FlyoutDialog

The flyout has the advantage of being more in-context (does not feel like a separate place) and fluent (does snot require a confirmation step, just changing the settings).
The dialog version has the advantage of providing more focus (the document fades away), and has less space constraints (extra room is available for more detailed descriptions).

Given that dialogs are currently available as standard widgets, and these actions don't benefit much from being in-context or are expected to be changed frequently, I think we can go with the dialog version. I'll update the description to reflect this.

Pginer-WMF updated the task description. (Show Details)May 3 2018, 10:26 AM
Pginer-WMF updated the task description. (Show Details)May 3 2018, 10:34 AM

Thanks @Pginer-WMF for the updates and the visual comparison!
After looking at those, I'm actually not as sure about the dialog option any more. Especially as I think your point about not requiring confirmation step is in this context stronger than the possibly gained focus.
Before opening the discussion between those two (the menu option has technical constraints, as you mentioned, width issues, no clear handling of widgets within menus yet in the standard library, etc.) again: Why not taking the Notifications way and provide a popup, extended from @santhosh's first iteration. This would also provide you with a flexible wrapper for future extensions and is in some ways an already familiar UI concept as well in contrast to the extended menu.
What were the reasons for you to move away from this?

Why not taking the Notifications way and provide a popup, extended from @santhosh's first iteration. This would also provide you with a flexible wrapper for future extensions and is in some ways an already familiar UI concept as well in contrast to the extended menu.
What were the reasons for you to move away from this?

My intention with the original design (F17612966) was for it to be supported as a flyout/popup. Since the only part currently implemented was the destination selection, @Esanders (probably unaware of the future plans for it) proposed a menu to be used in T193255 instead, and submitted a patchset. I tried to clarify the next steps in T193255#4171262, but developers were already in the process of reviewing the patchset and it got merged since technically it seemed correct.

The decision of which widget to use for the implementation may require to undo some of that work. I'd have preferred those discussions to happen before effort was put on coding to save time to everyone, but in the current situation I think it is better to focus the discussion on how is better to support the proposed functionality, and once that is decided to update the code accordingly.

One of the reasons I reconsidered the use of a dialog was that in terms of standardisation the building blocks are more clear. There are examples of dialogs in OOUI demo page and existing products, while the popups I've seen from the OOUI demo are very basic (showing just text), and creating a more complex UI requires to define many other aspects that may or may not become part of the recommendations when those are standardised.

Pginer-WMF updated the task description. (Show Details)Jun 19 2018, 3:12 PM