Initial state:

• Button text: "Select section to translate"
• Button state: Enabled, color: Decision tokens/background-color/progressive
• User taps "Select section to translate" button

Processing state:

• Button text changes to: "Checking recent activity..."
• Button state: Slightly dimmed, color: Option Tokens/Blue/400 (#6D8AF2)

Outcome A: user not eligible for translation

• Display "Review your last translation" dialog
• If user clicks "Review translation":
  • Close dialog
  • Redirect to previous translation for review
• If user clicks "Close":
  • Close dialog
  • Return to main screen with modified button state

Outcome B: User eligible for translation

• close "Checking recent activity..." button
• proceed to section selection interface
• allow user to choose which sections to translate
• once selection is made, begin translation process

Post-dialog button state(for outcome A)

• Button text: "Next translation in: MM:SS"
• Button state: Disabled, color: Decision Tokens/background-color/disabled
• Timer: Countdown from 10:00, updates every second
• Ensure clock icon is visible next to countdown text

Timer Completion:

• When timer reaches 00:00, change button to “Select section to translate”

Technical Considerations:

• Use ellipsis (...) or truncate text if necessary to maintain button width
• Ensure the timer persists if user navigates away and returns

Button base width:

• Use the english version of "Select section to translate" as the baseline for button width.
• Set a maximum width (e.g., 120% of the base width) to prevent excessive stretching.
• If text exceeds the maximum width:
  • Truncate text and add ellipsis (...) at the end.
• For disabled button with limited space, use this truncation hierarchy:
  • "Next in: MM:SS" with clock icon

Thanks for sharing your exploration @SGautam_WMF.
The general direction proposed makes sense. Here are some thoughts:

1. I think that using the button as shown in the proposal works well to communicate the waiting without adding additional complexity.
2. The last step provides no easy way to access the path to review the article, since the previous dialog is unreachable then. At this point, we want users to use the time to review their translation, not wait for the time to pass to start the new one. I was wondering whether simply returning to the first step from the dialog could be more effective for this.
3. On the second step, the button text (Checking recent activity) makes sense for the scenario where the user gets to the dialog, since the information in the dialog complements the button label well. However, for users reaching the translation editor, it may be a bit unclear why their "recent activity" was being checked. Maybe something along the lines of "Checking contents..." can apply better to both cases.
4. On the second step, the color adjustment makes sense, but this represents a new one-off state for the button component. We can consider whether any of the existing states could make sense (conceptually and visually), and ping Design Systems team in case the new one is needed for them to be aware of this use case.
5. Side note: The main call to action in the Confirm step can be "Select section to translate" (for articles that do exist in the target wiki and can be expanded) or "Start translation" (for articles that do not exist in the target wiki). So the width of the button will depend on the case.

Thanks Pau for all the thoughtful feedback.

The last step provides no easy way to access the path to review the article, since the previous dialog is unreachable then. At this point, we want users to use the time to review their translation, not wait for the time to pass to start the new one. I was wondering whether simply returning to the first step from the dialog could be more effective for this.

What do we mean by first step here?

On the second step, the button text (Checking recent activity) makes sense for the scenario where the user gets to the dialog, since the information in the dialog complements the button label well. However, for users reaching the translation editor, it may be a bit unclear why their "recent activity" was being checked. Maybe something along the lines of "Checking contents..." can apply better to both cases.

Thanks, we can go with "checking contents", I was even thinking even just using "Processing..." or "Please wait..." is enough but that might not be enough to set the content when we translate it. Other option I liked was "Processing translation request..." but I dropped it due to its length.

On the second step, the color adjustment makes sense, but this represents a new one-off state for the button component. We can consider whether any of the existing states could make sense (conceptually and visually), and ping Design Systems team in case the new one is needed for them to be aware of this use case.

I asked a clarifying question to DST. Lets see what they recommend.

Side note: The main call to action in the Confirm step can be "Select section to translate" (for articles that do exist in the target wiki and can be expanded) or "Start translation" (for articles that do not exist in the target wiki). So the width of the button will depend on the case.

Nice suggestion.

In T373509#10136435, @SGautam_WMF wrote:

Thanks Pau for all the thoughtful feedback.

The last step provides no easy way to access the path to review the article, since the previous dialog is unreachable then. At this point, we want users to use the time to review their translation, not wait for the time to pass to start the new one. I was wondering whether simply returning to the first step from the dialog could be more effective for this.

What do we mean by first step here?

I was referring to the sequence of steps illustrated in the mockup you shared. To clarify, I added labels and the arrows to illustrate a potentially simplified workflow.

Side note: The main call to action in the Confirm step can be "Select section to translate" (for articles that do exist in the target wiki and can be expanded) or "Start translation" (for articles that do not exist in the target wiki). So the width of the button will depend on the case.

Nice suggestion.

To clarify, the different labels ("Select section to translate" and "Start translation" ) are already implemented. I wanted to share this, since the proposal mentions aspects such as: Use the english version of "Select section to translate" as the baseline for button width., but the original button may say "Start translation" instead in some cases.

@Pginer-WMF could you please re-share the image? it seems like some format issue over there.